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

Delphi:

• IDE is a bit unstable.
• Code insight is sometimes confused.
• Debugging is sometimes buggy.
• Updating several project files can be cumbersome.
• If starting up when one or more packages are unavailable, the error message is popped several times.

Answer 2

I'll do PHP as I like it at times and Python will be done way too much.

• No namespace; everything is in a kind of very big namespace which is hell in bigger environments

• Lack of standards when it comes to functions: array functions take a needle as a first argument, haystack as second (see array_search). String functions often take the haystack first, needle second (see strpos). Other functions just use different naming schemes: bin2hex, strtolower, cal_to_jd

  Some functions have weird return values, out of what is normal: This forces you to have a third variable declared out of nowhere while PHP could efficiently interpret an empty array as false with its type juggling. There are near no other functions doing the same.

  $var = preg_match_all('/regexp/', $str, $ret);
  echo $var; //outputs the number of matches 
  print_r($ret); //outputs the matches as an array
  

• The language (until PHP6) does its best to respect a near-retarded backward compatibility, making it carry bad practices and functions around when not needed (see mysql_escape_string vs. mysql_real_escape_string).

• The language evolved from a templating language to a full-backend one. This means anybody can output anything when they want, and it gets abused. You end up with template engines for a templating language...

• It sucks at importing files. You have 4 different ways to do it (include, include_once, require, require_once), they are all slow, very slow. In fact the whole language is slow. At least, pretty slower than python (even with a framework) and RoR from what I gather.

I still like PHP, though. It's the chainsaw of web development: you want a small to medium site done real fast and be sure anybody can host it (although configurations may differ)? PHP is right there, and it's so ubiquitous it takes only 5 minutes to install a full LAMP or WAMP stack. Well, I'm going back to working with Python now...

Answer 3

C++

• Strings.
  They are not interoperable with platform strings, so you end up using std::vector half of the time. The copy policy (copy on write or deep copy) is not defined, so performance guarantees can not be given for straightforward syntax. Sometimes they rely on STL algorithms that are not very intuitive to use. Too many libraries roll their own which are unfortunately much more comfortable to use. Unless you have to combine them.

• Variety of string representations
  Now, this is a little bit of a platform problem - but I still hope it would have been better when a less obstinate standard string class would have been available earlier. The following string representations I use frequently:

  • generic LPCTSTR,
  • LPC(W)STR allocated by CoTaskMemAlloc,
  • BSTR, _bstr _t
  • (w)string,
  • CString,
  • std::vector
  • a roll-my-own class (sigh) that adds range checking and basic operations to a (w)char * buffer of known length

• Build model.
  I am sick to death of all the time spent muddling around with who-includes-what, forward declarations, optimizing precompiled headers and includes to keep at least incremental build times bearable, etc. It was great in the eighties, but now? There are so many hurdles to packing up a piece of code so it can be reused that even moms dog gets bored listening to me.

• Hard to parse
  This makes external tools especially hard to write, and get right. And today, we C++ guys are lacking mostly in the tool chain. I love my C# reflection and delegates but I can live without them. Without great refactoring, I can't.

• Threading is too hard
  Language doesn't even recognize it (by now), and the freedoms of the compiler - while great - are to painful.

• Static and on-demand initialization Technically, I cheat here: this is another puzzle piece in the "wrap up code for reuse": It's a nightmare to get something initialized only when it is needed. The best solution to all other redist problems is throwing everything into headers, this problem says "neeener - you cannot".

---

Granted, a lot of that is beyond strict language scope, but IMO the entire toolchain needs to be judged and needs to evolve.

Answer 4

PHP:

• One can never be sure that certain almost common extensions are available on all webservers.
• tries to be everything in future ( goto, closures, ... )
• many security risks for unexperienced users
• more operator overloading would be nice
• all the poor programmers that don't learn how to make it work properly, and give it a bad name

Nevertheless PHP is the (scripting) language. ;-)

Answer 5

PHP

1. No debugging features if you don't control the server, and even then they kinda suck
2. The extreme amount of bad PHP code floating around gives all PHP programmers a bad name
3. Inconsistent function naming
4. Inability to have a static typed variable if I want one (I'm a big fan of dynamic typing 90% of the time)
5. REGISTER_GLOBALS is the devil

Answer 6

PHP:

1) Forces me to make unnecessary variables:

$parts = explode('|', $string);
$first = $parts[0];

2) An implementation of lambdas so lame it is roughly equivalent to using eval() and so hideously wrong I have never used it (see http://www.php.net/create_function).

3) A try/catch system which can only catch about 80% of errors that might occur.

4) Regex support just as lame as lambda support because it has to be written inside regular strings, making one of the most hard-to-learn programming tools about three times as difficult. And PHP is supposed to be an "easy" language?!?!?

5) No way to safely pull stuff out of $_POST without writing it twice or building your own function, or using the '@' operator:

$x = isset($_POST['foo']['bar']) ? $_POST['foo']['bar'] : null;

6) Bonus answer: '@'. If you can't be bothered writing your code correctly, just add '@', and too bad for anyone who has to debug your code later.