TagUrIt posted:

code:

sb.append(String.format("%10d", suffix));

Edit: Okay, not a horror. Just an odd piece of code.

Flobbster posted:

Java should have C# envy, because C# shows how to do a Java-like language that isn't complete poo poo.

HFX posted:

It could be a bug, but would be very likely in a pre 1.5 environment. I was unaware of the format on String until you mentioned it. Now, I feel terrible for some places where I used while loops on String buffers to pad them.

npe posted:

No, this guy is just crazy, this is all recent code (within the last year) and we regularly use StringUtils (which has a leftPad() function) all over the place. He also likes to pack multiple variables into a single comma separated string so it can later be picked apart via substring() to get at the relevant parts. This is to "work around" java's lack of multiple return values as he puts it.

HFX posted:

Couldn't he just use a list to do the same thing, thereby forming a tuple?

HFX posted:

Couldn't he just use a list to do the same thing, thereby forming a tuple?

npe posted:

His response to all of these types of questions is "this works pretty well."

He's crazy. I just try to keep him away from anything I'll have to work on.

HFX posted:

No, C# is what you get when you try to add features to attract every developer to your platform without designing for the features originally in mind. C# has turned into a mess of a language with some many features I am not even sure why they exist.

shrughes posted:

What features are these? I was going to assume that you're a moron, but first, I'd like to know how you are a moron.

Crazy RRRussian posted:

It's pretty inefficient tho. If you had to do that a poo poo load of times it would probably slow down your program's performance by quite a bit versus using a list or your own Pair class or something.

Zhentar posted:

If you were using a language with serious string capabilities like MUMPS your packed strings would be efficient

Crazy RRRussian posted:

What the gently caress is MUMPS? Isn't that a nasty disease that kills kids?

shrughes posted:

What features are these? I was going to assume that you're a moron, but first, I'd like to know how you are a moron.

Hoborg posted:

I wouldn't be surprised if some programmer made a mistake in it that indirectly lead to the deaths of several children seeming as it doesn't even do arithmetic normally (strict left-to-right evaluation, no operator precedence).

shrughes posted:

What features are these? I was going to assume that you're a moron, but first, I'd like to know how you are a moron.

Hoborg posted:

My perception is a lot of developers think the addition of things like Linq, Lambda expressions, and the new classes added in later framework revisions amount to bloat.

Of course, the good thing is that these features are implemented using context-sensitive keywords, so you can continue to call some variable "select" and not have it conflict with the select Linq keyword.

I personally feel C# is getting bloated. I've only ever used Linq when doing data-access (using Linq-to-SQL because I was feeling lazy). I hope they devise a formal way to modularise the language so we can add our own language extensions in a portable and compatible manner. I'd love to introduce some new keywords and constructs to take the pain out of writing ORMs.

Smugdog Millionaire posted:

In before shrughes calls you a moron.
My only comment: it's pretty trivial to imagine a scenario where partial classes are useful. Any generated code that could be extended by hand-written code can be trivially combined via partial classes with no chance of your work being clobbered by a regeneration.

HFX posted:

Partial classes (This one in particular.. give me a good reason for it)

quote:

Support for only unchecked exceptions. (Random crashing ahoy. Almost as bad as Java Programmers who have empty catches.)

quote:

LINQ's (Now you are mixing languages. Makes your life easier, but I don't think it should be a first class feature)

quote:

The use of virtual keyword to allow polymorphism. (Why not just do virtual by default? For the type of language C# is, it would have made more sense).

quote:

Structs (Why? You have classes. This is for C/C++ programmers)

quote:

Dynamic Typing (Doesn't this break the original idea of C#? See below for why it can be good)

Ryouga Inverse posted:

Generated code where you want the user to be able to add to the class, but also want to be able to re-generate the generated part without destroying changes.

I don't even know what the hell you mean here. How do unchecked exceptions cause "random crashing"? Mandatory checked exceptions are terrible.

Not sure how I'm mixing languages when I use LINQ to query IEnumerables. It's not LINSQL.

You might as well ask "why is there a sealed keyword?" - explicitly declaring what methods have different behavior if you have an instance of Derived instead of Base is important.

A struct is a value type. It's fundamentally different from a class.

Dynamic types in C# exist pretty much exclusively to provide a way to handle other actual dynamic languages running in the CLR.


I'm not going to go so far as to call you an idiot, but you're pretty much entirely wrong. This really belongs in "Things you love/hate..." though.

lumberjack4 posted:

Structs are a hell of a lot better than classes performance wise. Why go through all the overhead of creating a class when a simple struct will suffice?

HFX posted:

Partial classes (This one in particular.. give me a good reason for it)

Hoborg posted:

micro-optimizations, something Knuth speaks out against

Hoborg posted:

Depends on context. It would be misguided of a developer to swap all occurences of 'class' with 'struct' in code.

Most of the only cases you'd see a performance benefit are examples of micro-optimizations, something Knuth speaks out against. You should focus on ensuring your program is correct, not that you're preventing a few bytes on the heap from being fragmented by putting structs on the stack instead.

HFX posted:

Partial classes (This one in particular.. give me a good reason for it)

HFX posted:

Support for only unchecked exceptions. (Random crashing ahoy. Almost as bad as Java Programmers who have empty catches.)

HFX posted:

LINQ's (Now you are mixing languages. Makes your life easier, but I don't think it should be a first class feature)

HFX posted:

The use of virtual keyword to allow polymorphism. (Why not just do virtual by default? For the type of language C# is, it would have made more sense).

HFX posted:

Structs (Why? You have classes. This is for C/C++ programmers)

HFX posted:

Dynamic Typing (Doesn't this break the original idea of C#? See below for why it can be good)

HFX posted:

The rest of my complaints is the C# does not straight jacket the programmer enough. I've learned if you give most programmers the ability too, they will optimize way to early and use every construct they can to make their life easier but not necessarily a better running or maintainable program. I prefer a smaller core language with libraries to handle many special features. Even better is being able to create DSL's inside of the language.

HFX posted:

Edit: I'd really like a language that makes things as simple as possible to begin with. If needed for performance or algorithmic reasons, I could then use more advanced / dangerous concepts. I sort of found this with OCaml and Haskell.

shrughes posted:

and a reliance on compiler optimizations that change big-O properties of the code

shrughes posted:

First, I'd like to say, thank you for informing me of the ways that you are a moron. Since your estimates of reality are not completely identical to mine, I'm afraid that you're a moron.

Also, as has been said, partial classes are useful when you want to generate some code and then gently caress with it.

shrughes posted:

This is one area in which I agree with you, not with regard to your spergtification about random crashing (which is dumb because Java has its whole RuntimeException hierarchy, ergo you are a moron), but rather, to add that I don't like Java's implementation in which you have to declare your exceptions on every method (instead of having the exception checking types inferred, which seems like it would be pretty easy). It would be better if you only had to declare it on certain methods, and for those it was checked, and for the rest it was just inferred.

shrughes posted:

All I can say is, yawn. Everybody just uses the extension methods anyway, nobody uses the weirder LINQ syntax except in the cases where it makes things clearer, like when doing joins. It really does make expressing joins easier, and so it's a feature that has helped making code more readable. I'm talking about the use of LINQ libraries and expressions for the purpose of operating over ordinary collections.

shrughes posted:

The pattern of design in which methods are haphazardly overridden is a bad one. You are a moron. Explicitly declaring which methods are virtual forces people to actually say what can be overridden and thus makes it easier to reason about the behavior of an instance of a base class.

shrughes posted:

You think having reference types for everything is better or the primitive type haphazardry of Java is better? Then you are a moron.

shrughes posted:

Arrays of structs are more memory efficient and cache efficient than arrays of references, and sometimes you just need a struct.

shrughes posted:

Interestingly enough, the struct type and reference type dichotomy is a fairly natural result if you tell somebody to design a garbage collected, memory safe language with only value types with no RAII where fields are generally mutable. What you get is some kind of primitive "pointer" type being included in the language, and a "reference type" design pattern naturally emerges, in which certain value types' implementations involve containing only a ptr<Something>, where Something is a mutable object. Purely functional, nonlazy, immutable objects, on the other hand, don't need to be reference types (you can safely make shallow copies of immutable values for any level of shallowness). Or they can be partly reference, partly not -- maybe a reference to some mutable stuff with some locally stored mutable information, for example. So you could just as easily say that C#'s real problem is that it has reference types, not that it has value types.

shrughes posted:

What original idea? I thought C# 2 was approximately the original idea. Doesn't C# 3 break that?

shrughes posted:

You complain about the lack of straight jacketing, yet you want to have every method be virtual. (Ergo, you are a moron. What are you going to do, call me a jackass? The best revenge is coding well.) C# does a fine job of directing the programmer towards good design. IDisposable and using blocks direct the programmer towards managing resources properly, instead of the hell that is Java. The fact that IEnumerable<T> : IDisposable, with the way generator functions work, does too. Writing a complicated IEnumerable, that acquires resources and releases them safely, is trivially easy to do in C#. I bet people get that wrong all the time in Java, or they just don't try. In C#, you can just put a yield statement inside a using block inside a foreach block, while wearing dark sunglasses at night just to look cool.

shrughes posted:

C#'s LINQ features encourage programmers to avoid manually writing and rewriting loop-based wizardry over and over again. And so instead of doing some loop that happens to filter elements while keeping some counter and other odd things, programmers can just say what they are doing. When it comes to increasing the probability of correct code, LINQ is worth it. Its main downside is that you have to learn a bunch of new words like Select, Where, Skip, GroupBy, and such, instead of manually implementing loopy constructs yourself, over and over again. The cost of having to know what Where means is less than the cost of incorrect code. Also, LINQ makes it more difficult to gently caress things up by having strange side effects in strange places, without feeling bad about the code you've written.

shrughes posted:

Also, almost every single feature since the initial release has given programmers more ways to straightjacket themselves, with more ways to talk about the types they are using and the things that they are doing, instead of saying "I give up, just cast," or "I give up, just modify this variable," or "I give up, return an object[] with two elements." The biggest contributor to good software design in C# has been clean lambda expressions, and second after that is generics. As far as I can see, there isn't any bloat, there's just stuff that's there. LINQ expressions are there, but I can ignore that option, but sometimes they're useful. You know, to most sane people, list comprehensions are considered a normal language feature, if not an essential one, and that's all LINQ expressions really are.

shrughes posted:

Haskell and OCaml are more complicated than C#, and when it comes to reasoning about the performance of your code, Haskell is borderline dangerous. I don't know OCaml, are you still limited to 4 million element arrays? It's more complicated than F# is, I know that.

shrughes posted:

Do you complain about do notation in Haskell, the way you complain about LINQ? What with do notation, scoped type variables, list comprehensions, stand-alone deriving declarations, postfix operators, view patterns, pattern guards, data families, n+k patterns, recursive do notation, generalized list comprehensions, record puns, rank n types, local fixity declarations, existentially quantified data constructors, GADTs, functional dependencies, overlapping/undecidable/incoherent instances, arrow notation, bang patterns, and a reliance on compiler optimizations that change big-O properties of the code, you mentioned Haskell after criticizing C# for getting too much bloat.

shrughes posted:

You are a moron.

Crazy RRRussian posted:

shrughes, chill out man, everything will be ok! All your custom gcj language needs is love, sweet love.

On serious note C# does sound pretty cool. I should probably look into it as java replacement. Can somebody comment on the state/quality of mono nowadays? Also does C# have something similar to java webstart?

niteice posted:

Wait, what?!

Crazy RRRussian posted:

On serious note C# does sound pretty cool. I should probably look into it as java replacement. Can somebody comment on the state/quality of mono nowadays? Also does C# have something similar to java webstart?

HFX posted:

shrughes posted:

Strictness optimizations change memory usage.

HFX posted:

This is great until you are working with several companies where you don't have source code to the upper class and you realize you need to override just one behavior. Implicit virtual is also simpler.

GrumpyDoctor posted:

So this is a consequence of Haskell's laziness, and doesn't afflict languages that don't try to do that? Or do languages with fold (and the like) generally not specify anything about their implementation? (I really want to understand this correctly.)

GrumpyDoctor posted:

So this is a consequence of Haskell's laziness, and doesn't afflict languages that don't try to do that? Or do languages with fold (and the like) generally not specify anything about their implementation? (I really want to understand this correctly.)

quote:

do notation, list comprehensions, pattern guards