What are five things you hate about your favorite

Question

There's been a cluster of Perl-hate on Stack Overflow lately, so I thought I'd bring my "Five things you hate about your favorite language" question to Stack Overflow. Take your favorite language and tell me five things you hate about it. Those might be things that just annoy you, admitted design flaws, recognized performance problems, or any other category. You just have to hate it, and it has to be your favorite language.

Don't compare it to another language, and don't talk about languages that you already hate. Don't talk about the things you like in your favorite language. I just want to hear the things that you hate but tolerate so you can use all of the other stuff, and I want to hear it about the language you wished other people would use.

I ask this whenever someone tries to push their favorite language on me, and sometimes as an interview question. If someone can't find five things to hate about his favorite tool, he doesn't know it well enough to either advocate it or pull in the big dollars using it. He hasn't used it in enough different situations to fully explore it. He's advocating it as a culture or religion, which means that if I don't choose his favorite technology, I'm wrong.

I don't care that much which language you use. Don't want to use a particular language? Then don't. You go through due diligence to make an informed choice and still don't use it? Fine. Sometimes the right answer is "You have a strong programming team with good practices and a lot of experience in Bar. Changing to Foo would be stupid."

---

This is a good question for code reviews too. People who really know a codebase will have all sorts of suggestions for it, and those who don't know it so well have non-specific complaints. I ask things like "If you could start over on this project, what would you do differently?" In this fantasy land, users and programmers get to complain about anything and everything they don't like. "I want a better interface", "I want to separate the model from the view", "I'd use this module instead of this other one", "I'd rename this set of methods", or whatever they really don't like about the current situation. That's how I get a handle on how much a particular developer knows about the codebase. It's also a clue about how much of the programmer's ego is tied up in what he's telling me.

Hate isn't the only dimension of figuring out how much people know, but I've found it to be a pretty good one. The things that they hate also give me a clue how well they are thinking about the subject.

Answer 1

Objective-C

1) No namespaces, just manual naming conventions - I don't mind the that in terms of class separation, but I do miss being able to import all class definitions in a namespace in a single line (like import com.me.somelibrary.*).

2) Libraries still have some holes in important areas like RegEx support.

3) Property syntax is a bit clumsy, requiring three lines (in two separate files) to declare a property.

4) I like the retain/release model, but it is easier than it should be to release a reference and then accidentally make use of it later.

5) Although not really a language feature, Xcode is so intertwined with use of Objective-C I can't help thinking about that aspect... basically the autocompletion, is very iffy. It's more like a system that rewards you for finding something you want exists, and then presents it as a choice afterwards. But then I suppose I never have liked autocomplete engines.

Answer 2

VB6

1. Windows only.
2. No longer supported.
3. Arrays can start at any number, rather then all being normalized to 0.
4. compiled applications depends on many dll's to run properly.
5. Many complicated controls like a browser control or complicated pieces of code tend to break the IDE when you run code uncompiled, but work just fine when compiled.

Answer 3

JavaScript:

1. All the coolest things are insanely complex, but then, all the coolness is also wrapped up in such a small amount of code that you feel stupid for struggling to follow it

2. '+' is an absurd choice of operator for concatenation in a weakly-typed language. Were they trying to scare off the noobs?

3. It's a cross-browser compatibility minefield (never mind if it's even turned on or not)

4. It's generally untrusted - associated with scummery such as blocking the back button, pop-ups that never die, etc.

5. It's nearly impossible to debug because there are only a few different error messages and a few different types (Number, String, Object, etc.)

If it wasn't for jQuery, I'd probably still hate it as much as I used to :)

Answer 4

C

• string manipulation.

Having to deal manually with the string buffers is an error-prone pain. Since so much computing is really moving and modifying strings (computers aren't used quite as much for big number-crunching stuff as people thought they'd be way back when), it's really nice to be able to use managed languages or C++'s string objects to deal with these. When I have to do it in straight C, it feels like swimming in quicksand.

Answer 5

Here are some things I dislike about Java (which is not my favorite language):

• Generics type erasure (i.e. no reified generics)
• Inability to catch multiple exceptions (of different types) in a single catch block
• Lack of destructors (finalize() is a very poor substitute)
• No support for closures or treating functions as data (anonymous inner classes are a very verbose substitute)
• Checked exceptions in general, or more specifically, making unrecoverable exceptions checked (e.g. SQLException)
• No language-level support for literal collections
• No type-inference when constructors of generic classes are called, i.e. the type parameter(s) must be repeated on both sides of the '='

Answer 6

JavaScript:

• The Object prototype can be modified. Every single object in your program gets new properties, and something probably breaks.

• All objects are hash maps, but it's difficult to safely use them as such. In particular, if one of your keys happens to be __proto__, you're in trouble.

• No object closure at function reference time. In fact, no object closure at all -- instead, this is set whenever a function is called with object notation or the new operator. Results in much confusion, particularly when creating event callbacks, because this isn't set to what the programmer expects.

  • Corollary: calling a function without object notation or the new operator results in this being set equal to the global object, resulting in much breakage.

• Addition operator overloaded to also perform string concatenation, despite the two operations being fundamentally different. Results in pain when a value you expect to be a number is in fact a string.

• == and != operators perform type coercion. Comparisons between different types involve a list of rules that no mortal can remember in full. This is mitigated by the existence of === and !== operators.

• Both null and undefined exist, with subtly different, yet redundant meanings. Why?

• Weird syntax for setting up prototype chains.

• parseInt(s) expects a C-style number, so treats values with leading zeroes as octal, etc. You can at least parseInt(s, 10) but the default behaviour is confusing.

• No block scope.

• Can declare the same variable more than once.

• Can use a variable without declaring it, in which case it's global and probably breaks your program.

• with { }.

• Really difficult to document with JavaDoc like tools.