What are five things you hate about your favorite language?

Wow, I'm surprised that SQL hasn't made it up here yet. Guess that means nobody loves it :)

• Inconsistent syntax across implementations
• Subtle code differences can have massive performance ramifications for seemingly obscure reasons
• Poor support for text manipulation
• Easy cost of entry but steep learning curve towards mastering the language
• Minimal standardization across the community for best practices, this includes syntax style.

...And a few bonus reasons to hate it, at no extra charge

• the WHERE clause goes last, making it easy to prematurely execute an UPDATE or DELETE, destroying the whole table. Instead, the WHERE should go somewhere up front.
• It's difficult to implement relational division.
• I can set a value to NULL, but I can't test it for equality with NULL. I can check IS NULL, but that just complicates code -- needlessly so, in my opinion.
• Why do we need to completely respecify the formula for a GROUPed column, rather than setting an alias on the column and then GROUP BY the alias (or column index as with SORT)?

Ruby has many flaws related to its speed, but I don't hate those. It also has flaws with the community evangelism going overboard, but that doesn't really bother me. These are what I hate:

• Closures (blocks) have 4 different creation syntaxes, and none of them are optimal. The elegant syntax is incomplete and ambiguous with hashes, and the full syntax is ugly.
• The community tends to be against real documentation, favoring ‘read the code’. I find this childish and lazy.
• Metaprogramming abuse, particularly in libraries, makes bugs a nightmare to track down.
• On a related note, pervasive metaprogramming makes a comprehensive IDE difficult, if not impossible, to make.

• The way block passing to functions is done is silly. There is no reason blocks should be passed outside the parameter list, or have odd special syntax to access (yield). I am of the opinion that blocks should have been given a less ambiguous syntax (or hashes could have used different delimiters; perhaps <> rather than {}), and passing as parameters to methods should have been just like all other parameters.

  object.method(1, {|a| a.bar}, "blah")
  

  These oddities, like the block must be the last parameter passed and passing more than one block is different with longer syntax, really annoy me.

C (OK, it's not my favorite, but it hadn't been done yet.)

• Socket library syntax.
• No function overloading.
• C-style strings.
• Buffer overruns.
• Cryptic syntax. I don't know how many times I've looked up stuff like atoi, slapped my forehead, and shouted "Of course!"

EDIT: I could probably come up with more if I resorted to more library code (like I did with sockets, but those are particularly bad), but I already felt like I was cheating for picking on C. So many languages exist only to take the good parts of C and replace the bad that it's kind of like beating a dead horse.

BrainF*ck

• Your highlight is that you're Turing complete?! I can do more in Perl regular expressions!

• Lack of objects. C'mon, people! It's like, hello...

• No networking libraries. All I want is to scrape a web page, GOSH.

• No first-class functions. Congratulations — you get to commiserate with your Java friends.

• An infinite tape for storage and nothing else. This is so anally pretentious that we might as well be writing Lisp.

JavaScript

1. numbers as strings - Math can be frustrating when numbers are intpreted as strings. 5 + 2 = 52? Grrr...
2. permissions - all the best stuff requires permission from the user!
3. screen updates - The browser must be in the steady state to update the screen. There doesn't seem to be a way to force the screen to update in the middle of a script.
4. Slow - although Google's Chrome is nice...
5. Browser differences make using the language a [censored].

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.

JavaScript

• Every script is executed in a single global 'namespace'...something which you have to look out for when working with scripts from different sources

• If a variable is used but hasnt been defined before hand, it is considered a global variable

• Browser vendors making up standards as they please, making coding for us developers using such a beautiful language harder than it should be

• Case-Sensitivity - considering that there is no decent IDE for developing js with compile-time checking

• Workarounds (such as the use of hasOwnProperty method) to perform some, otherwise simple operations.

Haskell:

1. Space leaks from lazy evaluation.
2. Numeric Hierarchy not constructed with regard to mathematical abstractions.
3. Strict monadic IO can make it harder to debug.
4. The big implementations handle I/O in ways that don't seem quite compatible with the standard. (In particular, outputting characters only outputs the low 8 bits -- and then code gets built that uses this assumption to do binary I/O. Ick.)
5. Associativity of ($) operator could be changed to make some expressions prettier.

Most of these don't rise to the level of hate, and there are people trying to fix or construct solid workarounds for each of these.

Edit: There's been some confusion about point 5. In particular some people seem to think I meant the order of arguments, which I don't. Rather than explaining what I meant, I'll just point people to the following link, http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity , which expresses it well.

My language du jour is Java. Here is what I hate about it:

5.) Lack of pointers
4.) Exception catching
3.) The Boolean type
2.) BigDecimal type
1.) C# fanboys and Java fanboys

Boolean can be null. I find this counterintuitive.

BigDecimal is a library and not a language feature. My annoyance with BigDecimal and Exception catching stems mainly from writing test classes that have to jump through a bunch of hoops to get actual work done. I should clarify I'm annoyed by these things, I'm not about to lobby for changes.

Groovy/Grails

1. Duck-Typing
2. Convention over Configuration, assuming you know the Convention
3. Everything you hate about Spring
4. Everything you hate about Hibernate
5. [Groovy] common operations across collections aren't (but recent releases improve this)

ColdFusion

1. Compile Time for large Flash Forms.
2. Dynamic Variable Types (Sometimes I hate them.)
3. Lack of features in CFScript.
4. CFTable (Can never get it to display right).
5. The lack of chart types left out of CFChart.
6. Complete lack of NTLM support (enterprise ready - yeah right)
7. Moronic var scoping in CFCs
8. No concept of a true NULL - your variable just vanishes!
9. No way to test for the existence of certain things (like scopes, just members inside them)

C#

It's a great language, especially with LINQ, but generics support is poor compared to C++. It had so much potential, but the current implementation is only useful for strongly-typed collections and similar trivial things. Some examples of where it falls down:

• A generic argument cannot be restricted to enums (only classes or structs).
• A generic argument cannot be a static class. Why? This seems like a completely artifical restriction.
• You cannot specify that a generic type must have a constructor with a certain signature because you cannot have constructors on interfaces. Why not? It's just another method with the special name ".ctor".
• Similarly, you cannot specify that a generic type must have a static method, because those also cannot be declared on interface. Something like static T Parse(string s) would often come in useful.
• The compiler is too eager in prohibiting some casts which the programmer knows would actually work, so they require uglyness like (TheRealType)(object)value
• No covariance, eg. IList<string> cannot be converted to IList<object>, even though string[] can be converted to object[]. (Microsoft might be fixing this in C# 4.0, though.)

Perl 5 In order from most annoying to least.

1.) Backwards compatibility police. Yes backcompat is a strength but Perl 5 takes it too far. Now we don't really even get new features in our language without having to enable them explicitly. I'm much prefer the inverse, if a new feature causes a problem let me disable it or enforce old behavior. e.g. perl 5.10 added say I'd rather have no feature 'say' if I have my own say implemented than have to put use feature 'say'; or use 5.010; also if 5.8 worked but 5.10 didn't. I'd rather have use 5.008; to restrict my code to only use features available up to and including 5.8 if no use version; was defined then it should be defaulted to whatever version you're running, and a recommended practice of not to restrict it unless you have to.

2.) Excessive Boilerplate.

#!/usr/bin/perl
use strict;
use warnings;
use utf8;
use autodie;
use English '-no_match_vars';
use 5.010;
package Package::Name;

BEGIN {
    Package::Name::VERSION = 0.1;
}

sub somesub {
    my $self = shift;
    my ( $param1, $param2 ) = @_;
}
1;

now you may start coding. This won't change due to #1. of course there are shortcuts to this stuff like use common::sense; or use modern::perl; which will shorten the above and you may want some slightly different modules or pragma's. But because of #1 we'll never be able to reduce it to.

#!/usr/bin/perl
package Package::Name 0.01;

sub somesub ( $param1, $param2 ) {
}

some modules are helping with this, and there is the new package version in 5.0.12 which allows exactly that syntax though I think it requires use 5.012; first, and Method::Signatures but it'll never be completely resolved, (in language).

3.) Poor variable choices

slurp

Self

• No real code browser, instead hundreds of small windows flying around.
• Only a research project, not stable enough, no active community.
• No decently fast version for Linux or Windows. Only Mac OS X.
• No support of standard keyboard commands.
• Oh! And the documentation on writing native plugins is so outdated!

C++:

• Lack of symbolic import.
• Over-obsession with C compatibility.
• Ridiculously complicated preprocessor.
• Template errors are nearly incomprehensible.
• No garbage collection.

C#

Python, again:

1. No switch keyword. And NO, dictionary is not a replacement for it. Not even a bunch of elif statements.

2. Inconsistent line break handling. Why can I do:

    test = (1,
            2,
            3)
   

   And not:

   from itertools import cycle,
                         islice,
                         izip
   

   Why can't I do:

   if stuff \
      and foo \
      or bar:
       return "Formated string with %(arg)s" % \
              {'arg': "bloody slash"}
   

   without using slashes?

3. There is not one obvious and only one way to do it. Python fails on its motto just like Java failed on "Write once run anywhere".

   # what somebody from an another language would do
   if not test.has_key('foo'):
       test['foo'] = 0
   n = test['foo'] = test['foo'] + 1
   

   vs

   # what an agnostic beginer would do 
   try:
       test['foo'] += 1
   except KeyError:
       test['foo'] = 1
   n = test['foo']
   

   vs

   # what you end up after looking for dictionary default value in the python doc
   test.setdefault('foo', 0)
   n = test['foo'] = test['foo'] + 1
   

   vs

   # what I would do
   n = test['foo'] = test.get('foo', 0) + 1
   

   And the worst is that they don't do exactly the same thing. There are subtle differences.

4. Choice between spaces and tabs. There should be no choice. Pick on, set it in stone and stop fighting.

5. Why can you do that:

   test = {}
   test['foo'] = 0
   

   but not:

   test = []
   test[] = 0
   

P.S: " ".join(l) is fine people. Stop complaining about it, it's not obvious but with the iterator pattern in mind, it's just the right way to do it.

Python

1. There is no Django for Python 3.
2. Static typing. Yes, dynamic typing is great thing, but sometimes I do want to make it static.
3. Proper unicode support (fixed in Python 3)
4. Construtors naming. I hate all this underscores __in__ my code.
5. Threads are not very efficient

I can add another one for Python:

Given a list l = [l1, l2, ..., ln], then repr(l) = [repr(l1), repr(l2), ..., repr(ln)], but str(l) != [str(l1), str(l2), ..., str(ln)] (str(l) = repr(l)). This was decided because there could be obscure entries in the list like l = ["foo], [bar,", "],["] and str(l) would return "[foo], [bar, ], []" which "could confuse users". However, this makes str impossible to use for just dumping data, since list kills the "just dump data in a readable format". Augh!

C#

The number one all time pet hate of C# has to be:

(1) Events have strong references to all listeners thus preventing garbage collection of anything that listens to an event. If you want to see the problems this has caused just search on the net for all the people who have tried to solve the problem by creating some sort of "weak referenced event handler".

(2) Needing to check if an event equals null before you call it seems like something that should be handled by the language.

(3) The XML serializer has no way of reading/writing comments in an XML file. Not great in an environment where XML files are modified both by hand and by the tool written in C#. Can be worked around by just using a raw XmlDocument, but would be nicer to be able to abstract that away to a class.

(4) The build process doesn't let you directly access things like xsd files, instead you need an intermediate step where you create a C# partial class. This also causes issues with XAML files where you need to rebuild twice sometimes to get changes to flow through properly.

(5) No support for CPU intrinsics like MMX and SSE 1,2,3,4 and thus these valuable CPU features go unutilised when running C# apps.

Others that didn't make my top 5:

(6) Can't tag fields as properties, all properties have to be explicitly implemented from the get go:

E.g. currently has:

public class MyClass {
    private int someInt;

    public int SomeInt {
        get {
                return someInt;
        }
        set {
                someInt = value;
        }
    }
}

Would like

public class MyClass {
    [IsProperty(public, get, set)]
    private int someInt;
}

(7) No support for multiple return values e.g:

public int, string, d