English:

• Inconsistent spelling
• Multiple-use tokens ("She's said 'Bob's Bob's "own worst enemy."'", e.g.)
• Swear words are kinda worn out
• Lack of non-gender-specific pronouns ("he/she", "they" or "it" are the only choices)
• Shared with Canada et.al.

Add more in the comments if you've got 'em.

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)?

Five things I hate about Java:

• No first-class functions.
• No type inference.
• Lack of sane defaults in eg graphics.
• NullPointerException not containing more information about what is null.
• The proliferation of pointlessly "configurable" frameworks/service provider interfaces/factory classes/dependency injection systems. The configurability is almost never used, DRY is violated egregiously, and code quadruples in size and halves in legibility.

I know, I should check out Scala.

JavaScript:

1. It's fugly

2. 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

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

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

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

6. Did I mention that it's fugly?

7. 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 :)

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 hidiously 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.

C++

• Far too easy to randomly corrupt memory and create almost impossible-to-find bugs (although, Valgrind ^[1] goes a long way towards fixing this).
• Template error messages.
• When using templates it's easy to end up having to include everything in one file, and then get stupid compile times.
• The standard library is a joke in the modern age (still no threads or network by default?)
• Lots of nasty little bits of C poking through (in particular, all the conversions between short/int/unsigned/etc..)

C# / .NET:

• Classes should be sealed by default
• There should be no lock statement - instead, you should have specific locking objects, and there should be methods such as Acquire which return disposable lock tokens. Corollary: there shouldn't be a monitor for every object.
• GetHashCode() and Equals() shouldn't be in System.Object - not everything's suitable for hashing. Instead, have an IdentityComparer which does the same thing, and keep the IComparer<T>, IComparable<T>, IEqualityComparer<T> and IEquatable<T> interfaces for custom comparisons.
• Poor support for immutability
• Poor way of discovering extension methods - it should be a much more conscious decision than just the fact that I'm using a namespace.

Those were off the top of my head - ask me tomorrow and I'll come up with a different 5 :)

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.

How about five things I hate about "Things I hate about some language" lists? :D

5- Painting an orange red doesn't make it an apple.

When a language is designed, the designers typically have in mind what it's useful for. Using it for something completely different can work, but complaining when it doesn't is just dumb. Take Python. I'm sure either someone has or someone will some day make a utility to create exe's from Python code. Why on God's earth would you want to do that? It would be neat—don't get me wrong—but it has no use. So stop complaining about it!

A well-designed project would likely contain code from multiple languages. That's not to say you cannot complete a project with only one language. Some projects may be well within the abilities of whatever language you are using.

4- Are you standing on wooden legs?

The platform can be a large influence of what the language can do. With nowadays garbage collectors, or well even pascals early attempt at "garbage collection", can aid in memory fade (maybe malloc more ram??). Computers are faster and so of course, we expect more out of our languages. And quite frankly, we probably should. However, there is a huge price to pay for the convenience of the compiler to create hash tables or strings or a variety of other concepts. These things may not be inherit to the platform of which they are used. To say they are easy to include to a language just tells me you may not have a leg to stand on.

3- Who's fault is it really?

Bugs. You know. I love bugs. Why do I love bugs. Because it means I get to keep my job. Without bugs, there would be many closed pizza shops. However, users hate bugs. But here is a little splash of cold water. Every bug is the programmers fault. Not the language's. A language with such a strict syntax that would significantly reduce how many bugs were possible to generated would be a completely useless language. It's abilities could probably be counted on one hand. You want flexibility or power? You've got bugs. Why? Because you're not perfect, and you make mistakes. Take a really identifiable example in C:

int a[10];
for (int idx = 0; idx < 15; idx++) a[idx] = 10;

We all know what that's going to do. However, what maybe some of us don't realize is.. that functionality can be very beneficial. Depending on what you are doing. Buffer overruns are the cost of that functionality. That code above. If I actually released that to the public. That's again.. say it with me.. "My fault". Not C's for allowing me to do it.

2- Shouldn't we put that in the recycle bin?

It's very easy to point at a feature in a language we don't understand because we don't use it often and call it stupid. Complain that it's there etc. Goto's always entertain me. People always complain about goto's being in a language. Yet I bet your last program included a type of goto. If you have ever used a break or a continue, you've used a goto. That's what it is. Granted, it's a "safe" goto, but it is what it is. Goto's have their uses. Whether "implicit" gotos like continue or break are used or explicit gotos (using the actual keyword "goto" for whatever language). Not that language developers are flawless, but typically... if functionality has existed since the dawn of time (for that language). Likely that aspect is a defining quality of that language. Meaning.. it's being used and likely is not hanging around because of backwards compatibility. It's being used today. As in 5 minutes ago. And used properly. Well.. arguably someone is using it improperly as well, but that relates to #3 on my list.

1. - Everything is an object.

Ok.. this one is really a subset of #2. But this is by far the most annoying complaint I see in hate lists. Not everything is an object. There are a great many of concepts that do not belong or need to be objects. Putting things where they don't belong is just ugly and can decrease efficiency of a program. Sure. Maybe not much depending on the language. This also relates to #5. This means... yes. Global are ok. Functions as apposed to static methods are ok. Combining OO programming with global functions is ok. Now.. that doesn't mean we should all go out and "free" our code from it's object models either. When designing a section of code or a whole project, what happens behind the scenes should be considered when putting it together. Not only where that concept lives and many other factors. Why wrap global functions within classes or name space concepts if it serves no purpose? Take static member variables. That greatly amuses me because.. well..Depending on the language and implementation of course, but generally speaking, you just declared a global. Yes, there are some reasons to wrap these non-OO concepts in OO wrappers. One of course being self documenting code. That can make sense. So.. like I say. Don't go out and "free" your code. But any good modern language will have a global concept outside of it's OO modeling. Yes I'm specifically meaning to point out that an OO programming language without a global concept most likely has a serious design flaw. Again though.. depends on the intention and design of the language so I'm not attempting to pick on any specific language and there are far too many to analyze right here. Anywho, Consider where the code should live and be the most effective. Adding a bunch of flare to something which doesn't add functionality or support just wears down the keyboard faster. It doesn't do anybody any good. Well.. unless you like brownie points from the person who probably incorrectly taught you that everything is an object.

In short, programming isn't just mindlessly tapping on the keyboard. There are a lot of design considerations to any project. I know it's cliche, but you have to look at it from every angle. Even with nowadays type-safe languages. You don't just chuck code out and expect it to work well. Sure.. it may work, but it may not be the right way to go about it. Overall, pick the language and format that is best suited for the specific job AND the environment. But no language takes away the thought behind it. If you're not thinking.. you're just typing.

Five things I hate about Java (which, presently, is my favorite language) in no particular order.

1. As much as I am a fan of Java Generics, there are a lot of oddities that arise from the way it was designed. As such there a myriad of annoying limitations with generics (some of which are the result of type-erasure).
2. The way Object.clone() and the Cloneable interfaces work is totally broken.
3. Instead of taking the high-road and making everything an object (a.la. SmallTalk), Sun wimped out created two distinct categories of data-types: Objects and primitives. As a result there are now two representations for fundamental data types and wierd curiosities such as boxing/unboxing and not being able to put primitives in a Collection.
4. Swing is too complex. Don't get me wrong: there's a lot of cool stuff one can do with Swing but it is a great example of over-engineering.
5. This final complaint is equally the fault of Sun and those whom have written XML libraries for Java. Java XML libraries are way too complicated. In order to simply read in an XML file, I often have to worry about what parser I am using: DOM or SAX? The APIs for each is equally confusing. Native support in the language for easily parsing/writing XML would be very nice.
6. java.util.Date sucks. Not only is it unnecessarily complicated but all the useful methods have been deprecated (and replaced with others that increase complexity).

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.

Perl

• Mixed use of sigils

  my @array = ( 1, 2, 3 );
  my $array = [ 4, 5, 6 ];
  
  
  my $one  = $array[0]; # not @array[0], you would get the length instead
  my $four = $array->[0]; # definitely not $array[0]
  
  
  my( $two,  $three ) = @array[1,2];
  my( $five, $six   ) = @$array[1,2]; # coerce to array first
  
  
  my $length_a = @array;
  my $length_s = @$array;
  
  
  my $ref_a = \@array;
  my $ref_s = $array;
  

  • For example none of these are the same:

    $array[0]   # First element of @array
    @array[0]   # Slice of only the First element of @array
    %array[0]   # Syntax error
    $array->[0] # First element of an array referenced by $array
    @array->[0] # Deprecated first element of @array
    %array->[0] # Invalid reference
    $array{0}   # Element of %array referenced by string '0'
    @array{0}   # Slice of only one element of %array referenced by string '0'
    %array{0}   # Syntax error
    $array->{0} # Element of a hash referenced by $array
    @array->{0} # Invalid reference
    %array->{0} # Deprecated Element of %array referenced by string '0'
    

  In Perl6 it is written ^[1]:

  my @array = ( 1, 2, 3 );
  my $array = [ 4, 5, 6 ];
  
  
  my $one  = @array[0];
  my $four = $array[0]; # $array.[0]
  
  
  my( $two,  $three ) = @array[1,2];
  my( $five, $six   ) = $array[1,2];
  
  
  my $length_a = @array.length;
  my $length_s = $array.length;
  
  
  my $ref_a = @array;
  my $ref_s = $array;
  

• Lack of true OO

  package my_object;
  # fake constructor
  sub new{ bless {}, $_[0] }
  # fake properties/attributes
  sub var_a{
    my $self = shift @_;
    $self->{'var_a'} = $_[0] if @_;
    $self->{'var_a'}
  }
  

  In Perl6 it is written ^[2]:

  class Dog is Mammal {
      has $.name = "fido";
      has $.tail is rw;
      has @.legs;
      has $!brain;
      method doit ($a, $b, $c) { ... }
      ...
  }
  

• Poorly designed regex features

  /(?=regexp)/;           # look ahead
  /(?<=fixed-regexp)/;    # look behind
  /(?!regexp)/;           # negative look ahead
  /(?<!fixed-regexp)/;    # negative look behind
  /(?>regexp)/;           # independent sub expression
  /(capture)/;            # simple capture
  /(?:don't capture)/;    # non-capturing group
  /(?<name>regexp)/;      # named capture
  /[A-Z]/;                # character class
  /[^A-Z]/;               # inverted character class
  # '-' would have to be the first or last element in
  # the character class to include it in the match
  # without escaping it
  /(?(condition)yes-regexp)/;
  /(?(condition)yes-regexp|no-regexp)/;
  /\b\s*\b/;              # almost matches Perl6's <ws>
  /(?{ print "hi\n" })/;  # run perl code
  

  In Perl6 it is written ^[3]:

  / <?before pattern>  /;   # lookahead
  / <?after pattern>   /;   # lookbehind
  / regexp :: pattern  /;   # backtracking control
  / ( capture )        /;   # simple capture
  / $<name>=[ regexp ] /;   # named capture
  / [ don't capture ]  /;   # non-capturing group
  / <[A..Z]>           /;   # character class
  / <-[A..Z]>          /;   # inverted character class
  # you don't generally use '.' in a character class anyway
  / <ws>               /;   # Smart whitespace match
  / { say 'hi' }       /;   # run perl code
  

• Lack of multiple dispatch

  sub f(   int $i ){ ... }  # err
  sub f( float $i ){ ... }  # err
  sub f($){ ... } # occasionally useful
  

  In Perl6 it is written ^[4]:

  multi sub f( int $i ){ ... }
  multi sub f( num $i ){ ... }
  multi sub f( $i where $i == 0 ){ ... }
  multi sub f(     $i ){ ... } # everything else
  

• Poor Operator overloading

  package my_object;
  use overload
    '+' => \&add,
    ...
  ;
  

  In Perl6 it is written ^[5]:

  multi sub infix:<+> (Us $us, Them $them) |
                      (Them $them, Us $us) { ... }
  

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 ^[1]). String functions often take the haystack first, needle second (see strpos ^[2]). Other functions just use different naming schemes: bin2hex ^[3], strtolower ^[4], cal_to_jd ^[5]

  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 ^[6] vs. mysql_real_escape_string ^[7]).

• 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...

Spanish

1. Irregular verbs. All the common ones are irregular, too. First person of "ir" is "voy"?? That does not follow the "o" "as" "a" "an" "amos" rule at all.

2. What is up with the subjunctive? "El que tenga sed" - he who is thirsty, hypothetically speaking. Do we really need to conjugate this differently?

3. Venezuelans. How come Venezuelans are always leaving out the s in the middle of words like "mosca?" Come on people, it's right there in the spelling. I thought your language was phonetic.

4. Vocabulary. "Peel" and "rind" and "skin" and "husk" and "shell" are all "cascara" to you? Just "the outside part, who cares about the texture or edibility?" Sloppy.

5. Corazón. OK, so this is not so much linguistic as cultural. Why do all Spanish songs contain the word "corazón" (heart)? I mean seriously, even in Spanish 1101 I could understand half the song lyrics, because I knew this one word. You've got to come up with some new subject matter. Somebody start translating They Might Be Giants into Spanish - they sing about all kinds of weird stuff.

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 '='

C++

1. Template Syntax
2. Diamond Inheritance issues
3. The plethora/lack of standard libraries that modern languages have (though boost comes close).
4. IOStreams
5. The syntax used around IOStreams

Python

1. Spaces are meaningful (sometimes)
2. underscored keywords
3. Limited thread support (at least currently)
4. "self" instead of "this"
5. Spaces are meaningful (sometimes)

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.

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.

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.

Python:

• Lack of static typing
• Default argument handling (specifically the fact that you can change the default argument ^[1] for future callers!)
• Too many required underscores (constructors must be called __init__)
• Lack of proper private members and functions (convention just says that most things that start with underscore are private, except for all the stuff like __getattr__ that isn't)
• Funny syntax for printing to a file (but they're fixing that in Python 3)

C#

• I wish I could switch() on any type, and that case could be any expression.

• Can't use object initializer syntax with 'readonly' fields / private set autoprops. Generally, I want language help with making immutable types.

• Use of {} for namespace and class and method and property/indexer blocks and multi-statement blocks and array initializers. Makes it hard to figure out where you are when they're far apart or mismatched.

• I hate writing (from x in y ... select).Z(). I don't want to have to fall back to method call syntax because the query syntax is missing something.

• I want a do clause on query syntax, which is like foreach. But it's not really a query then.

I'm really reaching here. I think C# is fantastic, and it's hard to find much that's broken.

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

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.

Common Lisp:

1. Keywords are often too wordy.
2. Library support is pitiful.
3. Doesn't work well in OSes that want to handle memory more strictly.
4. Doesn't have good facilities for interacting with the OS.
5. The "loop" facility is not well defined, and sure doesn't look Lispy.

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].

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. ;-)

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.

Ruby is my favourite language, here's what I don't like:

• Green threads + blocking C libraries = giant fail
• SO PAINFULLY SLOW
• The standard library itself is inconsistent with its use of bang! methods
• Module include + extend is messy.
• "Open Classes" can't be scoped - I want to add a String#dostuff, but I don't want that to leak into all the third party libraries
• No binary deployment packaging solution.

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.

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.

Chinese (as written language)

Inspired by hilarious (yet to the fact) answer ^[1] on English. I feel like posting something not as original as fun facts.

• There are over 47,000 characters vary from 1 to 64 strokes per character.
• Characters/words can have multiple pronunciations, meanings and written form.
• Characters/words can be region specified (eg/ Hong Kong, Taiwan), disregard of Traditional/Simplified system. Some only exists/understandable in certain region(s).
• Swear words are not swear words if they are not in context, therefore it is difficult to screen rude posts/comments. (eg/ character for 'f*k' can also interpret as 'do')
• Confusion caused by Traditional-Chinese system vesus Simplified-Chinese system doubles the complexity of already-complex language.

I know I'm late to the party, but hate is timeless!

Java

• Runtime.exec(). So, if I don't manually clear the STDOUT and STDERR buffers, my code will hang? Wow. Die, plz.
• Null Pointer Exceptions. Responsible programming means I have to treat most objects like they're unexploded bombs, which is kind of a pisser in an object-oriented language. And when the inevitable happens I kinda need to know which object blew up in my face, but Java apparently feels telling me would be cheating.
• File I/O. Why do I have to jump through this many hoops to read a dang text file? And when copying files, I have to funnel the source file into my code and manually handle the output byte buffer? You're serious?
• Primitives vs. Primitive Wrappers. Note that Java now has a number of features that allow you to treat primitives and their wrapper objects as interchangeable in some places, but not in others; don't worry, the compiler will let you know which is which. This feels like a hack to work around a fundamentally broketastic design decision. And it is. (EDIT: Actually, the compiler is a much crappier safety net than I thought, particular when doing equality checks. If `a` and `b` are integers, `a == b` is guaranteed to behave as expected only if at least one of them is of type `int`. If they're both type `Integer`, then that statement will do what you think only if the two numbers are between -128 and 127. `Integer a = 1000; Integer b = 1000; return a == b;` will return `false`. Really.)
• XML. I have this dirt-simple little XML file I need to create and I have to do what?

Smalltalk

• I don't want to develop in java, delphi, c#, or ruby anymore (which is impractical as the main development languages in my company are c#, delphi and java).
• Left-to-right evaluation.
• Has a class comment but no method comment (at least in Squeak)
• No real standard library, lots of differences in details
• Lack of namespaces

Lua

I love this language, but there are some things that bug me for years!

• No (built-in) support of binary operations (as of 5.1, it might come with 5.2).
• Should have a built-in binary buffer implementation, allowing for example in place long string concatenation.
• I know it doesn't fit well in the syntax, but sometime I miss longVariableName++ or verboseVariableName += 5.
• Reference assumes knowledge of C (I have it but it is a minus for newcomers) and defers some help to C reference! And sometime it is too terse.
• It is starting to have a good deal of libraries, but you have to get them from various places. On the other hand, the download is very small! ;-)

VB.NET

• The behavior AndAlso / OrElse and And / Or seems backwards. Perhaps they should be switched.
• When can only be used for exception catching. The ability to do a When conditional would be nice for some other things.
• There is no friggin Refactoring in the VS IDE (not really the language's fault) like there is with C#
• Not <obj> Is Nothing. Yes, this has been remedied by IsNot, but for some reason I see the Not Is being used too often. (I see it much more frequently with devs who speak english as a second language, does it make better sense from that angle?)
• It doesn't require the () on ToString() and most functions. (Leads to sloppy coding habits)
• Having to do _ when breaking a line.
• It allows optional parameters. (Leads to sloppy coding habits)
• declaring an array is done by UpperBound and not by capacity. "Dim arr(2) as String" will actually hold 3 elements.
• Having = be a comparison and assignment operator.

Python

• 1-3: There is no one obvious choice of packaging/build/documenting system (such as Perl's cpan, POD or Ruby's gem, rake, rdoc).

• 4: Python 3.0 is incompatible enough to require two source branches (2.x and 3.x) for every single Python project. But Python 3.0 is not incompatible enough to justify it. Most py3k advantages are too subtle.

• 5: Jython, IronPython, CPython are incompatible.

Objective Caml

1. Non-concurrent garbage collector. I can write multi-threaded programs all day long, but they're only ever going to get one of my eight cores at a time. This makes me sad.

2. No type classes (or their moral equivalent). There's Furuse-san's GCaml ^[1], but it's A) not quite as good as type classes, and B) not in the INRIA distribution.

3. Badly in need of a Cocoa bridge. Seriously. If I wrote more code with actual interfaces to DNA-based life forms, then I'd probably break down and write the damned thing myself. Why hasn't anybody else done this yet?

4. Functors are abominable. Seriously, modules ought to be first-class values. There should be only one kind of function. Read Montagu and Rémy ^[2] before you flame me for this.

5. Should use LLVM for its back-end. Who do I have to murder to get OCaml to compile for my stupid little ARM6 core?

So yeah, I have some issues. I still love the language to pieces. It's totally awesome.

VBA (including MS Office IDE):

1) Poor Documentation
2) Poor Error Messages
3) Inadequate Array Manipulation Routines
4) Having to repeat types for DIM statements
5) Won't print in color (have to buy 3rd party addin)

Delphi (aka Object Pascal), I'll talk about the native version, not .NET.

• Var blocks!
• Interfaces in the language are designed with COM usage in mind - thus more complex than say in C# or Java. ie. Reference counting involved unless you disable it explicitly.
• No try except finally end;

• Object creation too explicit:

  var obj: TMyObject;
  ...
  obj := TMyObject.Create;
  try
    ...
  finally
    obj.Free;
  end;
  

Instead something like

auto obj: TMyObject; // compiler adds the default constructor call and the destructor call in a try/finally block.

• OK, the language is so good I can't really think of any more so I'm pushing myself here: Builtin types such as string, integer.. or enums would better have methods. ie. i.ToString instead of IntToStr(i).

My own top-5 "what do I really hate in c++":

[5] Automatic generation of constructors, destructor and assignment operator. Man, whenever I don't declare something in the class, it means I DON'T NEED IT, not I FORGOT IT. Do you, compilers, hear me?!

[4] Template syntax. Oh, do I really need to type all these "<" and ">", whenever I decide to extract definitions from the class body?

[3] Strings. Jeez, I am fed up with "const char*", I have to handle NULL situations, I have to waste O(N) to get its length, I have to allocate a buffer for concat operations.

[2] Macroprocessing. Whenever I do not understand, what is going on with my compiler, I start looking for a macro.

[1] Operator overloading. I see the code "A + B * C" and I cannot say a word what this code is about, until I see the actual types of A, B and C.

C

1. No parametric polymorphism (i.e. C++ templates). It makes writing reusable data structures and algorithms a pain (and there's hardly any static checking). See for instance the comparator argument to qsort and bsearch: the comparator takes void pointers :(
2. No library of data structures. I really hate writing my own hash table. I also really hate scouring the web for a library of reusable data structures. Especially if it turns out to be incomplete.
3. Strings. Inefficient representation, unwieldy if you make it sane, too hard to safely input a string. No standard for snprintf. Too hard to create a format string with sprintf, then use that to create a string with sprintf again, in a safe way.
4. Only lexical macros. If different compilers expects function annotation in different places, I have to put the same HAS_NO_SIDE_EFFECTS in different places. Why can't I just grab the function, switch over the compiler type, and then insert it at the right place by a macro call?
5. No portable libraries for common functionality. For sockets and threading, I use SDL---a frigging game library. For .ini-style parsers, the only library I could find which was packaged for ubuntu, I posted on the daily wtf (it calculates an array of hash values, then does a linear scan through it...)

C++

1. Template syntax is heavy and unweildy. Let's see, for(map<string, int>::const_iterator it = mymap.begin(); it != mymap.end(); ++it).
2. Design errors in the STL. Should changing allocation strategy for your vector really change its type?
3. Overly complex type system. Type T1 has a convert-to-T2 method, and T2 has an implicit from-T1 constructor. Which is called? How does overloading, overriding and multiple inheritance interact? Poorly, I guess...
4. Incredibly long and unwieldy error messages from templates. You know what I mean...
5. References means you can't see output parameters at call sites. In C, you can guess what foo(bar, &baz) can and can't modify.

Lua:

• I understand the reasons, but seriously. Variables should be local by default, with a global keyword, not vice versa.
• I'm in general not a huge fan of the do/end style semantics. I much prefer C-style braces.
• Dynamic typing. I know, some of you go "Huh?" but I've been entirely spoiled by knowing exactly what type of data will be in a given variable. Constant if (type(var) == "string") then stuff() end is a pain.
• Variables need not be defined before they're used. I would much rather be explicit about what I'm trying to do than risk a typo causing what I like to call "wacky beans".

PHP:

• Again, dynamic typing.
• Lack of closures. I know, you can do $function($arg); but that doesn't count.
• Yet again, variables can be used before being defined. I have a personal policy of always explicitly initializing any variable to a known value before I use it, and I extend that to whatever best practices documents I have any sort of control over.

C/C++:

• Headers = pain in the neck.
• No support for closures. (I'm excited for C++0x, which has them.)
• Static typing. "Wait," you say. "You just said you don't like dynamic typing!" Yes, I did say that. But static typing can be a pain in the butt too. (If given a choice I'd still pick static typing.) Optimally I'd like a language that was statically typed by default, but supported a dynamic type as well. (And I'd also like a pony, and fifty billion dollars, and the world, please.)

Ruby:

1. It's damn slow
2. The egotistical community
3. It's not quite smalltalk
4. Errors when calling methods on nil rather than just returning nil à la Objective C
5. Non-native threading

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.)

Python.

Although the weird way python deals with scope has been mentioned, the worst consequence of it, I feel, is that this is valid:

import random

def myFunction():

    if random.choice(True, False):
        myString = "blah blah blah"

    print myString

That is, inside the if block is the same scope as the rest of the function, meaning that variable declaration can occur inside condional branches, and be accessed outside of them. Most languages will either prevent you doing this, or at least offer you some kind of strict mode.

This function will sometimes succeed, and sometimes throw an exception. Although this is a contrived example, this could lead to some subtle problems.

Haskell:

• Space leaks - a price paid for laziness by default - maybe too high a price?
• Even pure functions like head and tail can invoke error and boot you out to IO.
• fail from Monad - bring back MonadZero.
• The Num class - (+) should have been in AdditiveGroup or similar.
• That Monad is not an Applicative.

ActionScript / AS3

• No abstract classes
• No private constructors (so singleton is a hack)
• No typed arrays before FP10
• Compile/publish time is ludicrously slow in Flash IDE
• Performance of built in functions (e.g. Math) is slow

Otherwise it's actually a good language - much better than JavaScript, contrary to popular belief, and a million times better than something like PHP.

JavaScript

1. Function object syntax:

   f = new Function( "foo", "bar", "return foo+bar;" );
   

   (It takes n arguments, the first n-1 are arguments for the function, then nth is the actual function, in string form. Which is just silly.)

2. Function arguments can be repeated.

   f = new Function( "foo", "foo", "return foo;" );
   

   The last repetition is the only one ever used, though:

   f( "bye", "hi" ) // returns "hi"
   f( "hi" ) // returns undefined
   

3. E4X should just die. My users are always complaining that it doesn't work the way they think it will. Let's face it, when you need a page and a half of psuedocode for a setter, it's time to rethink things.

4. A standard notion of stdin/stdout/stderr (and files!) would be nice.

5. null != undefined

   It's irritating to have to handle them both. Sometimes it's useful, but most languages manage to limp along fine with one.

Python

• __init__
• some libraries are awkward, like smtplib
• 'self' has to be in the method declaration !!!
• (for pre-3.0) somewhat poor unicode support
• lack of inline try-catch
• no direct reference to "this"/current module (instead have to use sys.modules[__name__])

Not that I hate my mother tongue but a couple of points that humour me.

Spelling! That is, English spelling is revenge for German grammar!

Oh, and different sounds for the same spelling! Cough, bough, through, rough, thorough, thought, and hiccough.

This is why ghoti spells fish!

• gh from rough
• o from women
• ti from nation

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)

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)

Python:

1. Too slow!
2. list operations don't return the list, so you can't do list.append(4).append(5). (I mean a reference to the same list, not a copy). This is a minor gripe; it's only come up a few times.
3. statements don't return values (if, print, while, for, etc). This is only a problem when dealing with lambdas.
4. lambdas can only be one expression. There's no real need for this restriction, as they are equivalent to functions in every other way. What if I want a button press event which calls two functions? I'd need to create a named function to supply that functionality to an action listener, while doing "lambda: f1(); f2()" would not hurt.
5. you can only put standard a-zA-Z_0-9 as names. Having functions like "true?" and "+" would be great. Of course, this could lead to terrible obfuscation, but I'm not saying we immediately rename all functions to "p@$%3". Which do you find clearer to read: "dec2bin" or "dec->bin"? ("store_results" or "storeResults") or "store-results"?

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.

Here's some more for Perl 5, from the perspective of someone who's created a lot of Perl modules, and in particular worked on Moose ^[1].

1. The horrible brokenness that is overloading and tied variables. Both of these features are a failed attempt to allow transparent extension to the built-in types.

   They both fail in various ways, and require module authors like myself to either implement horrible hacks to support them, or to say "never pass an overloaded object to the foo() method". Neither alternative is really acceptable.

2. Lack of proper hooks into the compilation process and the meta-model. Moose in general, and role usage in particular, could be made much safer if the Perl core allowed us to affect the compilation process via a sane API that allowed us to hook into the meta-model (packages, classes, etc.)

3. Lack of named parameters built into the language. Instead, everyone reinvents this. It's annoying.

4. Similarly, lack of optional types. I don't want a static language, but the ability to specify types and constraints, particularly on function/method parameters, would be great. Perl 6 gets this right. Types are optional, but very rich, and there's no fundamental difference between built-in and user-defined types.

5. The backwards compatibility police. This is more of a cultural issue. A number of the above issues can never really be fixed, since Perl 5 has a very strong commitment to backwards compatibility. So even if something were to be added that effectively replaced the current ball of shit that is tie and overloading, those features will never be removed. Of course, backwards compatibility is also one of Perl 5's greatest strengths.

6. Bonus hate: Perl's built-in exception mechanism is a joke. The fact that exceptions may be a string or object makes for an eternity of fiddly exception-catching code, and the lack of a catch in the language syntax is the wart on the wart.

Scala is my favourite language. Five things to hate? Easy:

1. Takes a long time to learn properly. I know you can write Scala as a 'better java'. That is what we used to say about C++ and C too. I agree this is an inevitable consequence of the deep ideas in the language. But still ...

2. Methods vs. Functions: def f(x: Int) = x*x defines a method f, not a function f. Methods are not functions despite a lot of early Scala tutorial material blurring the distinction. The language tries to blur it too because if you supply a method in some places where a function is expected it is accepted. Do we have to have both methods and functions? Yes it is fundamental. But it was initially confusing to me.

3. Composing classes or objects from mixins in the 'cake' pattern is prone to NPE's. e.g. trait X { val host: String; val url = "http://" + host } is a mixin that will NPE on instantiation, or not, depending on its position in the class declaration. The compiler could tell you if it will fail but doesn't. (In 2.7 anyway.) It is hard to diagnose the problem in complex inheritance graphs.

4. Arrays in 2.8 rely on implicits to mesh with the main scala collection types. But implicits are not applied everywhere. An Array can be supplied where a Seq is expected. But an Option[Array] cannot be supplied where an Option[Seq] is expected. I know there are no completely 'right' ways to handle java Arrays.

5. Type erasure. Enough said.

German

My native language... Though it can sound even more beautiful than Klingon it's a grammar hell...

1. conjugations: even regular verbs have different forms for each person and time (with few exceptions)... Example: I see, you see, he/she/it sees, we see, you see, they see translates into: Ich sehe, du siehst, er/sie/es sieht, wir sehen, ihr seht, sie sehen.
2. polite form of address: equals 3rd person plural, used to equal 2nd person plural in the middle age... I really hate the concept of distinguishing between "Du" and "Sie" for my philosophy is that each human being should be considered equal in the amount of respect for it deserves (I mean, what are swear words for, hm?)
3. punctuation: show me a language that uses more commas regularly!
4. missing suitable words: eg. there's no real German equivalent of "convenience" or any derivate of this word... in almost every case you just can't translate it into another German word and keep the meaning... instead you would have to make up a whole subset to describe it somewhat adequate...
5. Anglicisms and Denglish ^[1]: Sure, the English language has "Kindergarten" or "Poltergeist" and what not but the German language is overflowing with Anglicisms nobody needs... Even worse: We redefine some words we adopt, eg. in German "Handy" means a cell phone and has nothing to do with the adjective it is in English... There are influxes on grammar as well, leading to "Denglish" expressions (see linked article at Wikipedia) There's more, but I don't want to exaggerate this and those are my personal Top5 of what I hate about the German language...

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 a file

#!/usr/bin/perl
use strict;
use warnings;
open my $fh, "< foo" or die $!;
local $/; # enable localized slurp mode
my $content = <$fh>;
close $fh;

wtf is $! and $/? rewrite to be legible.

#!/usr/bin/perl
use strict;
use warnings;
use English '-no_match_vars';
open my $fh, "< foo" or die $ERRNO;
local $INPUT_RECORD_SEPARATOR; # enable localized slurp mode
my $content = <$fh>;
close $fh;

and lest not forget that the '-no_match_vars' must be there if you don't want to take a performance hit.

How 'bout no direct way to create an anonymous scalar?

#!/usr/bin/perl
my $scalar_ref = \do{ my $anon_scalar };

couldn't they have come up with something?

#!/usr/bin/perl
my $scalar_ref = <>;

oh and how about how perl is thread unfriendly because all the variables (including special ones) are global by default. At least now you can use my $_; to lexical scope that and use local on the others.

4.) really ugly syntax

MooseX::Declare is a much nicer syntax. Also I wish for -> to be replaced with . (personal preference doesn't matter much)

5.) Too much TIMTOWTDI or Too many best practices Seems like you have to read 3-5 books just to figure out all of how you should be doing things.

6.) Previous (no longer applies). Un-sane releases. 5.10.0 had features 5.10.1 had features no set time 'till the next release. Now it's yearly feature releases with quarterly updates.

7.) Ivory Tower perspective. community problem, seems to be a large number of devs who want high barriers to entry and thinks it's ok to treat n00bs ( or really anyone who disagrees with them ) disrespectfully.

8.) Insane Version Numbers/Strings Perl has floating point version numbers and they're ugly. Oh and the dev's don't know that not all downstream deals with version comparison the same way. Not really a language problem

0.012 # simple
5.012001 # semantic 
4.101900 # time based + version (for multiple versions in a day)
0.035_002 # prerelease

all valid versions in perl.. can't we just use like...

0.12 # simple
5.12.1 # semantic
20100713 # time based (just use the date and be careful not to need to release more than 1 a day)
0.35-beta2 # prerelease

addition

9.) No obvious way to reinstall all XS modules after an upgrade

Python (3.1)

• The weird out-of-order T if C else F syntax for conditional statements.
• bytes literals look too much like str literals. We should have had something like x'414243' instead of b'ABC'.
• str is UTF-16 on some platforms and UTF-32 on others. (Although at least it's an improvement over 2.x strings.)
• Having the same operator for addition and concatenation. This hurts with types like numpy.array.
• Runs slowly.

Python:

• You usually have the entry point of the program at the end of the file. (Because if it calls any function defined in the module, it has to occur after those functions in the sources.) I hate it when you have to spend time looking for the entry point of a program, so I always have a simple main.py file with:

  def main():
      ...
  
  
  if __name__ == '__main__':
      main()
  

• When an exception is raised, it can only be catched by the main thread. Or something like that.

• Destructors are quite useless, because when written in Python they may break garbage collection IIRC.

• I've never figured out how relative imports work in Python 2.

• I'd like to see more collections in the standard library. For example: linked lists, thread-safe collections, ...

I have a book exploring all sorts of projects in SNOBOL ^[1]. The first chapter explores the history and culture around SNOBOL programming and language and spends some time making the argument that a good programmer likes a language not because of its flaws but in in spite of them.

My favourite language is Icon ^[2]/ Unicon ^[3]. But there are still things that annoy me about it:

1. It's not well known or all that popular.
2. It has a much smaller library compared to PHP, Perl, Java, etc. Database access is done via ODBC, which is actually quite annoying.
3. For all it's otherwise excellentt list handling, I miss PHP's built-in explode() and implode().
4. It doesn't have a table constant. Lists, yes, tables, no.
5. It is a compiled (actually translated) language.

F#

1. Type inference is limited.

   1. It propagates forward only.

   2. F# won't try to infer an object type based on the methods and properties used: you'll get "lookup of indeterminate object type" errors when it doesn't have a clue.

2. One cannot mix floats and ints: 1 + 2.3 is a type error.

3. It's a little awkward to have to create a builder object in order to define a monad or computation expression. In Haskell or Scala, you can define the monad operations directly on the monadic object.

4. Though the #light syntax is preferred, the indentation rules are sometimes not very intuitive or become cumbersome.

C++

• The inconsistencies in the libraries related to char* and std::string. All C++ libs should take std::strings.

• Characters are not bytes with respect to iostream. I do a lot of byte-oriented work. Having a "byte" type and a "character" type would significantly make it simpler. That, too, would permit scaling to Unicode somewhat easier.

• Bit operations should be easy on a value. I should be able to access and set the n'th bit of a value without playing AND/OR dancing.

• The lack of a standardized interface for GUIs. This is where Microsoft has really been able to position themselves well with C#. A standard interface binding that OS makers provide would go really far for my work.

PHP

1. No constructor overloading
2. Inconsistent function naming (str_replace, but strtolower)
3. define() does not replace the global variable literally like C++ does.
4. When combining with XHTML, statements like the if-statement must start out with no indentation, even though the XHTML is indented if you want to keep the XHTML indentation consistent.

Ex:

You must type:

<?php
if($x == NULL)
{
?>
                     <p><?= $x . ' is null' ?></p>
<?php
}
?>

1. Error catching is awful

(not sure why SO changed #5 to #1 again but whatever)

C:

• Lack of distinction between function pointers (executable) and data pointers (you really don't want to execute this).
• Extreme unreadability. Making code look like it does what it does is orders of magnitude more difficult than making it do the task in the first place.
• Lack of clear support for lisp-think. Doing functional things is possible, barely, but it's not clear.
• Serious inconsistency between libraries about how error codes are returned.
• Antiquated string handling. The strings aren't strings, they're null-terminated blobs. This is all manner of wince-worthy.

Lisp:

• () involves hitting the shift key. Every time I'm doing a lot of lisp, I swap it and [].

Emacs Lisp

• There is not enough of a commercial market to be coding in elisp full time
• GNU Emacs vs XEmacs incompatibilities
• Nested functions in Scheme are neat, I wish elisp had the concept [1]
• The do loop or some other facility for simply looping over a list is not standard (granted, you can now mapc with a lambda) [1]
• There should be a shorthand for (function (lambda (...))) [1]

[1] Of course, one of the beautiful things about Lisp is that it's not hard to fix these things in your own code with a one-liner. Still it irks me that it's not built in.

Good question; I'm a bit embarrassed that I couldn't come up with better things to hate, but honestly, your honor, there is not much to hate.

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# (well, part of it is the VisualStudio IDE, I guess):

• No covariance (yet), like Class<D> cannot be used in place of Class<B> even though type D derives from type B.
• Graphic designers don't support generic based inheritance (or inheritance from abstract classes), even though the inheritance itself works just fine if you work around the designer problems by adding extra inheritance levels just so designers always see concrete non-generic variants of your code.
• No constructor inheritance
• No constructors in where clauses of generic type parameters
• VisualStudio seems to have a tendency to mysteriously check out files (like project files and/or unit test definitions) when opening a solution, even though the files do not seem to actually get altered.

Could be different list if you ask me again tomorrow. Even though the covariance and designer trouble will be in my top 5 until they are solved (with variance added to C# 4.0, this seems to have happened for at least one of them...).

Oracle SQL

1. The DUAL table.

2. Can't GROUP BY an alias.

3. I can never remember the syntax for analytic functions and so I forget/am too lazy to use them.

4. Lack of combined LIKE and IN conditional operator. (After 10g there's a REGEX_LIKE operator that could do the trick, though.)

5. Awkward concatenation syntax.

SQL isn't really my favorite language, but it's one of the top three I use everyday. There are probably more items, but these are the ones at the top of my mind.

I have a whole slew of problems with SQL*PLUS. I wrote a Perl replacement that does what I'd like from the command line and I use sql.el ^[1] in Emacs for interactive SQL sessions. These tools help me work around my SQL*PLUS issues.

Speaking of which:

Perl

1. "Only perl can parse Perl." (But this is mostly an issue in syntax highlighting, which I don't prefer to use much anymore for any language.)

2. I'm sometimes surprised by "the simple (but occasionally surprising) rule...: It looks like a function, therefore it is function, and precedence doesn't matter." (From perlfunc(1))

3. Dereferencing complex data structures can be confusing at times. I can't decide if this is a true flaw in Perl or just a consequence of having really powerful data structure facilities. Either way, I can normally get it right by taking a few minutes to think about what I'm doing.

4. No option to cause system calls to raise their errors like the DBI module. (Thanks to brian d foy, I now know the autodie module on CPAN does this, but I'd like it built-in.)

5. Warnings and strictures not enabled by default in scripts. (The -e option would turn them off for command line use.)

Again, there are bound to be more things, but these are issues I've noticed recently. I'd add the need for =over and =back and the quirky L<...> syntax in POD, but maybe that ought to be a separate list.

Now for the trifecta:

KornShell

1. Sourcing a file with arguments replaces the values of the parent script's arguments. (Executing . file arg1 puts arg1 in $1.)

2. ksh is not an ideal interactive shell and defaults to vi key-bindings, rather than emacs. (My solution is to use bash for interactive shells.)

3. Common utilities (such as grep) are implemented differently across different platforms thereby preventing perfect portability. Some useful commands need to be installed on some platforms and are part of the OS core on others.

4. The syntax for conditionals is overly heavy. (if [ ... ]; then ... fi)

5. Although it is Turing Complete, you are eventually going to want to move up to a more expressive language like Perl.

One solution for #4 is to get used to short circuit evaluation:

[ ... ] && ...

D

• we have in operator, but no !in operator?
• dynamic array 'length' property - ya canna do

  array.length += 512;

• no exit statement - as in python's sys.exit(), etc. Sure, you can call C's exit, but unflushed output don't get flushed
• associative array literals + string literals suck

  string literals found as is inside an associative array literal are interpreted as static, thus this

  char[][char[]] hash = ["hello":"world","goodbye":"angels"];

  doesn't work without some extra casting due to different length string literals despite
  a. I didn't ask it to be interpreted as static arrays
  b. static arrays aren't allowed in associative arrays anyways

• cyclic dependencies disallowed (want to port that java lib? Have fun redesigning the class hierarchy)

Someone check me on these; not sure if they are all still relevant.

First post, so take it easy on me :) ... Awesome community site, btw!

I tried reading all other C# replies just so mine doesn't overlap

C# ... In no particular order:

1) No fallthrough for cases in switch statements. And if there is no fallthrough ... why does one have to explicitly type break; anyway? It's just retarded and confusing since it implies the ability to not have the break;!!!

2) Can't declare a variable with the same name in a child scope, but you can declare a variable by the same name as a class variable? Either allow both or disallow both. Otherwise, it doesn't make sense.

3) No optional/default parameters in functions

4) Exceptions in finally{} should be implicitly caught for every line. Or at least, just the NullReferenceException exception. For instance, after accessing a db, one should always clean up. So, the finally block should look something like this:

finally
{
  if(par1 != null)
    par1.Dispose();
  if(comm != null)
    comm.Dispose();
  if(conn != null)
    conn.Dispose();
}

It would be so much cleaner if it could be written as:

finally
{
    par1.Dispose();
    comm.Dispose();
    conn.Dispose();
}

But, no ... you have to check if you are accessing a null object, otherwise it may throw a NullReferenceException from the finally block .. and who really needs exceptions in the finally block anyway?

5) Generics: you can specify new() to be able to instantiate your generic objects, but that object needs to have a default constructor. Why can't you specify a signature instead so one doesn't need to create empty constructors if it doesn't already have them and just use the constructors it does have.

Haskell.

1. The Prelude is imported by default.
2. The scope of type classes is universal.
3. Modules are not first-class.
4. Types cannot depend on values.
5. Monad does not unify with Functor.

Java

1. checked exceptions
2. type erasure
3. missing operator overloading (e.g. for BigInteger/BigDecimal)
4. missing regexp/date/durations/complex literals
5. poor support for immutability

I can't believe it, my favorite Python pet peeves still haven't been mentioned:

1. (Prior to 3.x) Relative imports look like absolute imports.

   import foo
   

   Does this import foo from the directory you're standing in or from the sys.path?

2. Zipped eggs, leading to a sys.path full of shite. Zipped eggs means you can't use grep and find (to among other things debug problem 1)! Fortunately, there's pip. Use pip.
3. Some of the included batteries are unpythonic. It grates to use them.
4. Might be the fault of distro's and packagers, but still: sourcefile-encoding set to fscking ASCII on install/compile. WTF? Means I have to put the "# coding: UTF-8"-stuff in every single .py I ever make.

Py3k fixes several of my other pet peeves, by for instance insisting that strings are unicode and that 8-bit-stuff are treated differently...

C++:

1: Header files.

Linking your code is harder than compiling it. Also, the requirement of templates to have the full source in that translation unit is absurd. It's over in that other file there .. the one you compiled two seconds ago. Go look there. Stupid compiler.

2: Empty standard libraries.

I mean, yes, there's std::thread in C++0x, but no std::socket or anything of the sort. The primary reason there's no cross-platform code is because you have to learn a new library for every function that you want to perform on more than one platform. Without OS headers or OS functions provided as standard, C++ is only good for pushing bits around.

3: No multiple returns or return value overloads

double x, int y, char z = func(); is just as valid as void func(double x, int y, char z);. Please. The only reason ever given for no return value overloading is because we "might" write ambiguous code. Might! Please, give me grief when I actually write ambiguous code, not before.

4: No reflection

It's ok to make reflection compile-time. It really is. Not having any makes writing a lot of libraries difficult, at best, and seriously annoys me. I could abuse the preprocessor but..

5: Duck typing on templates

Yaargh. Please, concepts and proper template error messages. It's practically impossible to use a library like Boost, just because if you get it wrong, you're shooting in the dark.

Python:

• Slow for number crunching. This wouldn't be much of a problem except it...
• Doesn't come with an easy way to include C code with your program that automatically gets compiled when imported.
• We still have to live with stupid integer division rules until py3k takes over.
• We still have to live with goodies like imap and izip being in a separate module until py3k takes over.
• We have to do a lot of work before py3k can take over.

Python

• Errors/Exceptions are vague when debugging
• I don't use it at work
• using __init__, __repr__, __str__, etc in classes
• Can't simply compile an executable (.exe or otherwise)
• Some other thing that I haven't tried doing yet, but I'm sure will bug me

And to all those C-ish language programmers, self makes more sense to me than this, because the object is referring to its self

Lua:

• Metatables are sooo confusing until they "click"
• Lack of assignment operators like a += 20 is a pain
• No integrated object oriented solution means everyone and his dog uses his own flavor
• The syntax used for commenting (--) precludes the possibility of pre- and post- increment/decrement operators
• Not possible to have any sort of pre-emptive multitasking system without hacking the C side

Erlang is absent from this list. Among my favorite languages, but a few flaws for sure:

• Syntax. This includes the 3 terminating tokens (,;.) and aesthetics, but more generally on how the semantic meaning of the code is expressed in text. An example is on how all lowercase tokens are atoms, so to refer to a function you can't just name it, you have to fun my_function/1, and ?PRECEDE_CONSTANTS_WITH_QUESTION_MARKS. Coming from Scheme, Haskell, etc. you just wish you could use a name.

• Library support is lame. This is mostly external libraries, but even the old standard library. Newer versions of Erlang have sensible POSIX regexes, but the old one had a pretty horrible library for basic string manipulation. You also never know when you're getting the value, or {ok, Value}.

• Related: non-uniform tools for building and distribution. Ruby has gem and rake, RSpec. Perl has CPAN. I'm unaware of decent equivalents in Erlang.

• The few Erlang specific tools are pretty strange. Mnesia is a great database, but coming from SQL you have lots of trivialities to learn. Same with the documentation @spec, which has a strange way of describing signatures.

• Often the functional paradigm hurts when you just want that little bit of mutation. Supposing you want a Hash Table, you can't just hack it as in Scheme, or SML. ets and dets alleviate some of the pain, but not much.

Sixth, bonus:

• Import and export syntax for modules is a pile of fail, not unlike Java's 80+ lines of import statements.

All that being said, Erlang is a joy ^_^

R

Not my favorite language, but I use it a lot and there is plenty to complain about...

• S3 objects are just glorified lists and S4 classes still keep all data exposed to user
• The assignment operator can be <- -> or =, see Mike Dewar's rant ^[1]
• my.var is a very confusing variable naming convention for an OO language, see Google's style guide ^[2]
• I should not have to regret using a loop
• Cryptic error messages

Five things I hate about all languges (that I know of at least):

1. Does what I say/type, not what I mean
2. Will undoubtedly meet people who think they are experts in the language, but just make a mess of it (e.g. people who insist that removing comments/unused local variables will speed up execution time for a program)
3. Unless the language is obsolete, then it will probably continue to evolve (either the actual language, or the concepts behind using it effectively) requiring you to actively develop with it so as to not fall behind.
4. Can't modify the lexer/compiler (add in own context sensitive grammar)
5. No perfect language (every language is missing some sort of useful feature that usually is either impossible to simulate, will unavoidable have an ugly interface or just require far too much time to implement and get it right)

C#.

What I hate most:

1. No multiple inheritance - imagine you could provide whatever GUI framework base class (Control, Window, whatever) with MVC - related stuff, etc... framework / base class agnostic!

2. No "friend" keyword... I know, the RAD - victims would abuse it for all kinds of stinky code and for hilarious malpractices, but it would be nice for the OOD - guys to enforce the law of demeter

3. No language integrated DBC features, there are the Contracts, but I would rather have that Spec# - style with a general purpose "!" - postfix operator

4. No AOP (I don't get it... this language has attributes, it would have been SO EASY to add interception code in the compiler!)

5. No weak event delegates - the observer pattern becomes nothing but a memory leak bait as it is now... :-(

Another vote for C++ here... still my favorite with a few close followers - C and Python. Here's my current hate list in no particular order:

• Plethora of integer types inherited from C - way too many problems caused by signed vs. unsigned mistakes
• Copy constructors and assignment operators - why can't the compiler create one from the other automatically?
• Variable argument madness - va_list just doesn't work with objects and I'm so sick of problems created with sprintf(), snprintf(), vsnprintf(), and all of their relatives.
• Template implementation is required to be fully visible at compile time - I'm thinking of the lack of "export" implementations or at least usable ones
• Lack of support for properties - I want to have a read-only member like "a.x" that can be read publicly and only assigned internally. I really hate the "val=obj.getX()" and "obj.setX(val)". I really want properties with access control and a consistent syntax.

.NET framework (the libraries)

• Nested types rarely used (e.g. MessageBoxButton should be MessageBox.Button)
• Mutable structs (Rect, Point)
• Too much stuff in System namespace
• Too many different notions of equality (Object.Equals, Object.ReferenceEquals, operator ==, operator !=, IComparable.CompareTo() == 0)
• Arrays have mutable members but immutable length.

And one more:

• XmlSerialization doesn't work with immutable types

C#

Most of my gripes have to do with assuming C++ conventions were automatically the best choice for C#

• No statics allowed in Class interfaces. It's still part of the class. Why can't it be part of the interface?! I've had to create such stupid hack-y work-arounds for this.
• Case sensitivity. I know it would ruin legacy apps at this point but why wasn't case-insensitivity not the rule from the beginning

Bonus one for .NET (not C# specific)

• Compiler not smart enough. In .NET 3.x, the compiler can figure out "var" at compile time so why not other common optimizations? We all know the string vs. StringBuilder / immutable vs. mutable thing. Why doesn't the compiler convert it for you when in many cases it's obvious that StringBuilder is better than multiple concat.s? i'm sure there are tons of other optimizations that the compiler could do for us by default (with option to overrule) and save us tons of time.

C/C++

1. Lack of integral SWAP functionality
2. Template Syntax
3. You can not #define a #define (no multi-pass)
4. Structure packing incompatibilities between compilers
5. char is signed or unsigned ?

Java

1. Immutability on the edge
2. No ref keyword like C#
3. try/catch blocks everywhere
4. Poor runtime performance
5. All string related stuff

Python

1. No "main" (I'm used to it !)
2. underscored keywords
3. Limited thread support
4. "self" instead of "this"
5. Lack of C/C++ like syntax

Erlang

• doesn't have static inferred typing like one found in Haskell. This can lead to runtime errors and one have write code carefully or use dialyzer(1) to discover discrepancies. Dynamic typing is also considered to be slow;
• is almost unknown compared to C, Java etc.;
• 's lists(3) module is pretty lean, sometimes I lack useful functions for list processing (like ones in Data.List in Haskell for example);
• makes me put , at the end of an every statement within clause, and . in the end of the latter.

Common Lisp

• Lack of standard libraries for more modern features (sockets, threads, ...)
• Could use a standardized UI that maps to the native windowing system
• Scheme's ability to assign a lambda expression to a variable and use the variable directly as a function call looks neater that APPLY for FUNCALL. Side effect of having multiple name spaces, I guess
• Standardized source-level packaging system for libraries so that they could be easily used from multiple implementations

I wonder what a strongly-typed lisp would be like

Haskell (with all GHC extensions, not just the base Haskell'98 spec).

There's exactly one thing that I hate about it: it's not mainstream.

My favourite is really C#, but there are already a ton of answers for C#, so I'll go with my next "favourite":

T-SQL

1. The GO statement, and the fact that you need it for all manner of DDL/DML scripting, and the fact that it also breaks transaction semantics, making it far more difficult than it needs to be to write an atomic script, which you really need to have in order to upgrade a production database.
2. Inconsistent semicolon semantics. 99% of the syntax doesn't need it, MERGE statement has to end with it, WITH statement has to begin with it... make up your mind!
3. WITH CHECK CHECK / WITH NOCHECK CHECK. Uuuu-gly.
4. Optional parameters in UDFs aren't really optional. Caller must specify DEFAULT (and don't even try using NULL instead). Compare to SPs where they are truly optional.
5. "...may cause cycles or multiple cascade paths." HATE HATE HATE HATE HATE HATE HATE HATE HATE HATE HATE

TCL

This is my absolute favourite language for doing almost everything. Over the years it has evolved (slowly, very slowly) to address most of the things that annoy me. And the language is so flexible it's easy to implement syntax sugar to cover things that still annoy me. But there are things about the language that can't easily be changed just breaks its Zen:

• Arrays (of the associative kind, what Perl calls hash) don't have proper value semantics. This makes them awkward to pass to and return from functions. Also, this means that they can't be nested. For this reason dicts (dictionaries) were invented but too late, the nice array access syntax:

  $array($foo)

  is now forever taken by stupid arrays for backwards compatibility. We're now stuck with:

  dict get $dict $foo

  which is much more verbose and to me feels less readable.

• No real closures. Though it can be emulated somewhat by globals or namespaces but that defeats the reason for closures in the first place. Although, I can't really see for now how closures can be implemented in a pure value semantics system.

• Teacup is hard to use and is not at all intuitive compared to all other repository tool out there. This is more ActiveState's fault than tcl-core and doesn't really break tcl's Zen when coding but it is still very annoying.

C++

(Except for lambda functions, I've avoided things that will be available in Cpp0X)

• Doesn't force the use of "this" to access member variables, ::GlobalFunction to access the global namespace.
• Everything in (to be more specific, the lack of lambda functions in algorithms, will be fixed in 0x thou)
• Taking care of dependencies/header and source files
• Stupid names on basic data types (should be named uint8, int16 etc)
• The const_cast functionality

1 - indentation

2 - indentation

3 - indentation

4 - indentation

5 - indentation

I'll let you guess the language. :-)

Perl

I love this language, and I don't want to add things that have already been used, but no one has mentioned this yet, so I'll throw it on the pot. When I used this feature, I found it to be the most horrible experience of my life (and I've worked in assembly language):

• The write() and format() functions.

They have the single worst, ugliest, most horrifying syntax imaginable, and yet they don't manage to give you any more functionality than you could already achieve with some (infinitely prettier) printf() work. No one should ever try to use those two functions to do any output, simply because of how bad they are.

I'm sure someone will disagree, but when I looked into them, hoping they would solve my problem, I found them to be a "world of pain" (to quote the Big Lebowski), and hope that Perl6 has either done away with them or, better, completely rewritten them to be somewhat more usable and useful.

Objective-C / Cocoa / Cocoa Touch:

• Lack of namespaces
• Difficulty using primitive values with any of the interesting and powerful techniques of Cocoa, e.g., distributed objects, notifications, KVO
• Inconsistency with the use of the shortcut dot syntax for accessing properties, often having to use the full length accessors
• No GC on the iPhone, and generally GC came rather late to an otherwise highly dynamic language
• Inconsistent library support, at least in Cocoa Touch; some very basic things have only recently gotten high level support, e.g., audio handling.
• Lack of blocks!

C#

1. The foreach command bombing out when an object in the collection being enumerated changes,
2. UI controls spitting the dummy because they were accessed on the wrong thread. Surely all the dispatcher.invoke calls can be moved into the CLR plumbing,
3. PInvoke, marshalling etc.,
4. The wasted two years I spent learning remoting,
5. It's not as sexy as Ruby.

C

• It's so flexible and powerful that it's really easy to write really awful, or downright dangerous code (or, if you prefer, "with great power comes great responsibility").
• '=' for assignment, and '==' for equality; easy to confuse in 'if' statements.
• The implementation of a number of fundamental parts of the language are compiler-dependent; e.g. the size of the basic types, order of bits in bitfields, padding and byte order in unions.
• Bitfields aren't parameterisable (i.e. you can array of ints, but you can't have an array of bits).
• String handling could be improved.

C

1. bit fields -- they aren't well specified by the language and how they work is compiler dependent and architecture dependent.
2. It's often hard to find where a particular symbol is defined in a large mass of code, esp. if that symbol is produced by a macro. Which reminds me...
3. The preprocessor is a rather ugly hack, amenable to all sorts of abuse.
4. lack of standard sized integers (remedied by uint*_t lately, but there is lots and lots of old code floating around out there with custom typedefs or #defines for DWORD, WORD, BYTE, etc.)
5. Lack of something akin to Perl's cpan.org (would love to be wrong about that one.)

Edit: While thinking about a CPAN for C, I thought... what would I call such a thing, and thought of "ccan", and googling it, I came across this: http://ccan.ozlabs.org/

It seems to be as yet in its infancy though.

I'm going out on a limb since I can't really use it full time, but I'll try anyway!

Perl 6

1. func("frew") != func ("frew")
   • It annoys me, but there is good reason for it. In Perl 5 print (5 + 6) * 10 still gets me every now and then
2. It may be easier to parse than Perl 5 in a lot of places, but it still kills my editor sometimes
3. It still has a lot of the line noise Perl 5 which scares a lot of people. That means it's harder to get them excited etc.
4. There are no libraries yet.
   • This will be a non issue if Perl 6 does indeed end up supporting Perl 5, but that may be a burden not worth bearing.
5. There's no REPL, or what rubyists would call irb.
   
   • A solid interactive Perl 6 with tab completion, color coding, etc, would make using and learning it so much nicer.
6. Currently the documentation ^[1] is basically the English spec. Not exactly an easy read.
7. I know it's a stupid cliche, but it's not out yet!
   • (I am allowed to complain because I am helping :-P)

The first three are the language; the rest aren't really the language itself but the fact that it's not out yet.

R (R-Project for statistics)

1. Terrible, terrible string support
2. Surprisingly difficult for some simple descriptive tasks, like cross-tabulation
3. Large data set manipulation is done in-memory.

PHP

• Almost every standard function is in the global scope
• Inconsistent function argument order
• Inconsistent function naming
• Case insensitive functions
• Script may behave differently depending on the php.ini file
• Being able to use undefined variables
• In some cases having to assign a result to a variable before it can be used in a function

And far more subjectively:

• Dynamic Typing

C++ lack of good refactoring tools, lack of checked exceptions

Java lack of templates, lack of const keyword

c#:

1) static methods must be a member of a class

2) static extension methods can only be added to static classes

3) The implementation of interface functions are not marked with something like 'override' to show they are from a base class or interface (making it hard to ensure you're overriding the method you expect (with correct signature) with just code review).

I just have 3. I guess thats pretty good.

Python:

I am still a moderate user for python, so my complaints might just well be lock of knowledge or mis-usage. Comments are welcome. I do love this language.

1. Poor thread support and GIL. If you'd like to take use of multicore platform, most of the python programmers would probably recommend multiprocessing or some sort, don't use threading. It wouldn't give you the performance you are expecting.
2. property only for instance variable. _class_var = property(classmethod(some_method)) just wouldn't work. How can I get a property wrapped class variable?
3. no access control. All access controls are syntax mangling. Like private is __private, protect is _protected, etc... And hope that everyone programs python follows the naming convention. Come on, we can do better than that.
4. I agree the python philosophy of being simple and clear syntax but some simple and clear syntax not being supported seems lock of good judgement, in my opinion. Such as, a++, ++a, a-- and --a, self-de/increment, what's wrong with those? foo = (a > b ? a : b) unary operation, what's wrong with those? (I know py2.6 has something similar introduced, but given the massive support of almost every other language for those simple syntax, why reinventing the wheel? why not just follow the best practice? Shouldn't a good thing just keep in its good "form"?)
5. Program to interface. Python has no interface or abstract class concept (py3k has something called abc), everything is concrete. Providing an "interface" or "abstract" keyword to build class skeleton and guard class inheritance and extension wouldn't be a bad idea I think. It helps on top-down design. Currently, I just have to fill the each of methods with NotImplementedError, quite a tedious job.
6. I have to add this. version less than 3.x has str and unicode types. This is a true nightmare. It makes ascii and non-ascii/unicode mixing most likely to fail (bad, bad)

I saw people complains about speed. I don't get that. Its an interpret language, code not compile to machine code until runtime, that's just the nature of it. You can't compare speed from an interpret language to a compiled one. As far as I can see, among the interpret/scripting languages, python isn't slow.

VBA (because you thought your language was bad)

1. Whitespace inside a line is rigidly enforced.
2. Statements just end, and require a " _" to break to the next line, but not every line can be broken.
3. No ++,--,+=,-= statements. Seriously?
4. Arrays can begin at any index, not just 0.
5. Some types (i.e.: fixed-point "Decimal" value) must be subtypes of Variant, and aren't available as their own type.
6. != and <>.
7. "=" is used as both comparator and assigning, instead of splitting into "=" and "==".
8. "Option Explicit".
9. UI hasn't been updated since 2000.
10. Office2k7 didn't upgrade to VB.NET
11. Most object models are non-sensical and overly verbose.

Python

• No statements in lambdas. GRRRR
• foo( a for b in c if d ) feels wrong, it surprises me every time I get away with it. Shouldin't it be foo( (a for b in c if d) )?
• Can i have a dict comprehension?
• map and filter operators have special syntax in list comprehensions, how about something for reduce? or sort?
• Just by having a yield statement in it, a function is magically transformed into a generator, and its interface changes completely. Also, that generator cannot do any work before the first next(). at least, not without using a function that returns a generator.

JavaScript

• No brief syntax for making modular code libraries. You have to call a function that returns a dictionary of public methods. And you have to edit that in (at least) two places every time you alter the interface of your module.
• Creating closures involves returning it from a function that returns a function from ('sup dog) yo' function. Clutter!
• for each ( foo ) syntax and behavior feels like an afterthought.
• Knowing when your code will actually run (and in what order) is more of a dark-art. The only way to get it right for sure is put everything (yes, that too) in one big file. and even then you still need to wait for a document.onload
• Am i missing something? is there no trivial way to get json serialized values without building them by hand? (yes jQuery can do this, sort of).

Quenya

• Community is too small. It's next to impossible to get a good language-immersion program going when there's no easy to find another speaker nearby.
• Irregular verbs. Yes, I know English and Spanish mentioned them, too, but Quenya was invented. Why does there still need to be irregular verbs?
• No Unicode support. I have to have three different Tengwar fonts on my computer before I can read most messages, and several of them are poorly kerned. This wouldn't really be a huge issue given the existence of a Romanized transcription, but Tengwar is so beautiful, you don't not want to use it.
• Not all concepts can be easily referenced in Quenya, leading to annoying circumlocutions, or resorting to Sindarin, Númenórean, or (Manwë save me) Klingon to get my point across.

C#

Common Lisp

• conditions aren't classes (since classes came later), even though their interface is almost identical
• some of the names are just weird, e.g., flet / labels (only difference: scope), and defvar / defparameter (only difference: behavior when already defined), or any of the bit-twiddling functions (dpb, ldb, etc.)
• packages are ... really hard to get right -- every time I think I understand them, they don't do what I want
• built-in data structures and functions aren't as generic as they could be (e.g., why can't I define my own hash function portably?)
• multiple namespaces for functions, variables, etc. (I'm not opposed to this in principle, but CL made it too complex; Norvig has said he can't tell from the spec but there appear to be at least 7 namespaces)

C#

• Reference types are nullable by default; in-language null keyword is untyped.
• Lack of discriminated unions
• Exceptions as default, non-exceptional error handling method - there's not much of an alternative.
• archaic switch statement syntax and limitations
• Needless distinction between constructors + static methods
• Static methods can't be part of an interface
• Lack of by-shape interface implementation rather than explicit interface implementation - leading to numerous language design hacks such as the linq query syntax, foreach, collection & object initializers -- none of which can be flexibly reused. For example, the object initializer syntax may be nice, but plays poorly with immutable objects.
• Cannot inherit "interface" of a class independently of implementation - leading to code duplications and overarchitected code that provides interfaces, abstract base classes, a few common implementations, and no way to pick and choose the bits of each to use. Also; leads to too many code that's tightly coupled to a particular implementation since it's common to explicitly refer to the implementation type rather than an interface.
• Cannot multiply inherit via composition since a classes "interface" is tightly coupled to it's implementation; effectively lack of mixins.
• The above limitations of interfaces lead to a proliferation of virtually identical interfaces that don't overlap naturally in any kind of type hierarchy. IComparable vs. IEquatable vs. IComparable<T> vs object.Equals vs. operator == etc. etc. By extension, making a custom type that satisfies all these things is a lot more work than necessary (in particular for collection classes). Obviously, the language designers realize this, hence the various workarounds for things like linq, foreach and collection initializers which work by-shape rather than by-interface.
• Redundant use of parentheses and braces rather than layout-is-structure.
• Return values can be ignored, limiting the effectiveness of type inference.
• Enums aren't a normal type and can't have methods. Also, enum values aren't typesafe and may be initialized to 0 despite not having a 0 value. Mixing metaphors by lumping flag and non-flag enums together.
• Lack of proper value type support. Value types can't be inherited, have different constructor semantics, and perform poorly due to CLR limitations. Also, confusing semantics regarding value types: some values are really values (and can't be modified), and others are really non-aliased, non-null references (variables). This gets particularly confusing with regards to the next issue:
• Semantic distinction between fields and properties, particularly in conjunction with lack of mutability modifier (ala C++'s const)
• Can't specialize generics
• Cannot provide default generic type parameters (e.g. factory generics)
• lack of typedef makes generics a pain to use (using is a limited but good-to-know substitute!)
• Can't genericize over things other than types (e.g. functions, plain values, or names). This means you can't do something like make a generic implementation of a dependancy property leading to, well, nasty implementations of things like dependancy properties and the overuse of code-snippets and poorly readable code as a result.
• Limited capability to specify generic type requirements e.g. generic sum method that takes both int, double and a bigint (without tricky and often slow hacks).
• An interface method implementation or virtual method override cannot return a more specific type or accept a more general type; i.e. limited co/contravariance support even in C# 4.

Five things I resent in Nemerle:

• Local functions can't yield
• Ability to compile a lambda sometimes depends on whether it gets inlined
• Inconsistent value/reference type semantics for tuples
• Occasional ambiguity between array indices and type arguments
• Lack of general adoption

Clojure

• Lack of built-in syntax for optional and keyword parameters in function definitions. Sure, you can add it easily enough, but that means library writers don't use it. Pervasive destructuring hasn't proven to be a good substitute yet
• Lack of method combination (before/after/around methods of the sort found in Common Lisp)
• Too much reliance on Java interop, e.g. there's no built-in file IO
• Sometimes I want static typing. This one isn't pure hate; I usually prefer dynamic, and attempts to mix the two have been largely unsatisfactory
• There's no built-in fast binary serialization format for the built-in data structures, though I hear people are working on it

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.

Japanese

This was inspired a bit by the Chinese and English responses

1) Has not one, not two, but three writing systems.
2) For every verb you can do about 50 conjugations to mean almost 50 different things
3) Sooooooo many double negatives
4) Particles
5) on-yomi and kun-yomi

Funny enough 1, 2, and 4 are reasons I also like it.

Objective Caml

1. Lack of namespace facilicty.
2. Wordy class and object nortation.
3. Complex build system.
4. Inconvenient to make infix.

I use Java, and my biggest beef is the inefficiency of string operations. when you use the + operator. Seriously, can't the compiler figure out how many strings I'm adding and then generate the StringBuffer stuff in the background for me?

Often code that uses + is more readable than a sequence of StringBuffers operations.

Also, I hate the redundancy between native arrays and the collection framework. The syntax for .toArray() is extremely ugly.

C++:

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

Javascript;

1. the dynamic binding of "this" is very confusing and dangerous if you don't know exactly what you're doing.
2. a function declaration requires the keyword "function". It's not the typing I object to, it's the reading it when I want to do something slightly clever. Hrm now I think of it maybe that's a plus. Discourages me from doing clever things.
3. As a result of number 2, it's often less code (in terms of characters) to just copy/paste a code segment than to declare it as a function, if it's a fairly short idiom. This unfortunately promotes bad practice, especially in my own code.
4. Javascript makes motions at being a functional language by having first class functions and closures, but there's no way to verify referential transparency in a function, at either runtime or compile time. Without this, some architectures become either risky or bulky.
5. Its fantastically bad reputation, and thus my inability to say "I program in javascript" to anyone without being laughed at.

Perl 5:

1. All the really good stuff nowadays seems to require mod_perl, which has low availability everywhere I want to go.
2. Some really incredible functionality can be encapsulated in modules, but what is under the hood is often fragile or frightening: source filters, typeglobs, whatever Moose is doing...
3. DateTime is brilliant but still made some very bad design decisions ( not returning a stopwatch duration when subtracting two DateTime objects ^[1])
4. Dual-lifed modules in core and on CPAN still cause conflicts
5. module authors still put interactive stuff in their module configuration scripts so that they can't be automatically installed

Scheme

• Lack of static typing
• No static function overloading (due to the above) leading to long names for field accessors
• No unified object system
• Kinda slow
• Relatively small community

Lua

I love programming in Lua, but here's what burns me:

1. There's no way to write down an API in the language---nothing like a C .h file or Java interface
2. The language has first-class functions but somebody forgot to tell the people who designed the libraries.
3. The syntax for writing a function is way too heavyweight.
4. Syntax is split between statements and expressions.
5. The expression form is impoverished: there's no 'let' form, there's no true conditional expression, ...

Despite all of which I will insist that Lua is fabulously great :-)

Scheme:

• Lack of users/small community

Python:

1. Global Interpreter Lock - Dealing with this complicates parallel processing.
2. Lambdas functions are a bit clunky.
3. No built-in ordered-dictionary type.
4. Depending on how Python is compiled, it can use either UCS-2 vs UCS-4 for the internal Unicode encoding, many string operators and iterators may have unexpected results for multi-byte characters that exceed the default width. String slicing and iteration depend on the bit width rather than checking and counting characters. (Most other programming languages do similar things as well and have similarly odd behavior with these characters.)
5. There are inconsistencies surrounding GUI frameworks for Python.

EL - Expression Language, the ${...} and #{...} thing in JSP pages and JSF 2.0 Facelets which is used to pull data up from the underlying Java code.

• All the fun things, like method calls with parameters and annotation based naming is only present in the EL in Java EE 6 which is only available in Glassfish v3.
• It is a royal pain to 1) get the right jars for an earlier Servlet 2.5 container, and 2) getting them to work without interfering with any previous implementation available in the container.
• Having only an earlier version of JSF like 1.2, takes away the method calls and leave you to work with f:setPropertyActionListener - http://weblogs.java.net/blog/2009/07/22/say-sayonara-spal - which, trust me on this, is not very nice.
• The EL parser has no idea of where the snippet it is to parse and interpret came from, so you tend to give everything an id so you at least can identify which tag made it grumpy.
• Eclipse gives a warning at every EL method call as it is JSF 1.2. only too.

Regarding C#:

1. I hate that there is no keyword to specify which exceptions are thrown from a method like in java. Its a much better way to document exceptions than using an XML comment.
2. I would also want a much better syntax for generic constraints like oring and anding of constraints.
3. Why a method can't return more than one value?
4. Lack of support for aspect oriented programming in the language.
5. Why can't you annotate each one of the property accessors with an attribute?
6. Lack of builtin regexp support like in perl.

Python 3

• both tabs & spaces allowed for indentation
  And you'd think people learn from the past (Makefile). Just pick spaces and forbid tabs. YAML got it right.
• lack of popular third-party libraries
  The standard library is great, but a lot of what makes Python 2 so powerful lies in the third-party realm. Python 2 got this right :-).
• IEEE floats
  Floating points in programming languages are confusing because they're different from the way we use them in math. Instead, the number operations should be viewed as expressions that are only converted to a decimal point format when needed (i.e. printing to a screen). Maple and Mathematica did this right I think.
• the character set for identifiers is too restricted
  list.empty? is better than list.is_empty or even len(list) != 0. Similarly, process.kill! would be better than process.kill. Ruby and lisp got this right.
• when calling a function you must always write parentheses
  It would be nice if we could omit them in unambiguous cases. How is it again? dict.items or dict.items()? Ruby got this one right, too.

Python

1. Standard library disobeys their own style guidelines in many places. (PEP-8)
2. Py3k's super keyword is full of unwanted magic (you can't assign it to a different name, works without self, why do we have this explicit parameter at all?)
3. Unicode support is incomplete in Py2k and sucks in Py3k (standard input in unicode, no binary data! WTF? Creating a new WSGI standard is hacky.)
4. The GIL. Very limited multi-threading support (with CPython)
5. PyPI (Python Package Index) sucks. Envious glance at rubygems

PHP:

• Absurd assert() function... it runs eval() on the code inside
• ?> tag removes any newlines following it ?!
• Strange handling of numeric strings (try them as array keys)
• Painful unicode support that seems no longer will be resolved by PHP 6
• Low cost of entry means 95% give PHP programmers a horrible name - and trying to find someone in the 5% to hire is crazy.

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

C++

• cryptic error-messages when templates are involved
• lack of template constraints (many cases can be worked around with template metaprogramming, but this will result in unreadable code (at least for average programmers) in most cases)
• pointer to member-function syntax
• c++ standards committee should release offical standards more often (or at least release separate updates to the standard library itself), i mean really TR1 was released 2005, and we still dont have a shared_ptr, bind and alike in the standard library.
-

Five things I hate about C++

• Link times. With distributed builds I can rebuild our entire project in the same time it takes our linker to run.
• No standard way to prevent reordering of memory operations. Using write-combined memory typically requires abuse of the volatile keyword. Preventing read reordering (often critical for optimization when dealing with SIMD math pipelines) is typically accomplished via injection of a null ASM block in the middle of a routine.
• Multi-step macros to work around stringification issues:

#define STR_LINE2(x) #x
#define STR_LINE(x)   STR_LINE2(x)
#define LINE_NUMBER STR_LINE(__LINE__)

• It's just generally painful to do string manipulation.
• Proliferation of non-standardized printf variants (vsnprintf_s vs _vsnprintf_s).

Haskell

1. Sometimes the type system feels backwards. What if I don't want the compiler to infer types for my variables? What if I want the opposite, where it does constraint checking on said variables? For example, instead of inferring the type of the elements of a list, it instead makes sure that they all belong to a particular typeclass. This is a subtle but huge difference that makes it difficult for me to program UIs. It can be done, but it takes more effort than it does in some other languages. Haskell rocks for the non-UI parts, but the UI I leave to an untyped language.

2. Allowing the construction of infinite values leads to some really frustrating errors sometimes.

3. NoMonomorphismRestriction.

4. Bytestring handling bites me in the ass sometimes and you don't know it until your program crashes because you mixed them up improperly. Something is wrong here, when we are losing type information that should have prevented this.

5. Typeclasses should be automatically derived for trivial cases, like witness types, but there's a strong potential for abuse there.

C#

I know its stupid, but I'd like datatypes to convert to what I want on their own, without me having to add (int) or Convert.ToInt32 or whatever. It would just save me time. And it annoys me that if I write something to output an int and then it turns out that I need a long, then often I have to go through and change everything I've done to make it work. Just do it for me!

Sorry, couldn't think of five, but I'm new to it, so maybe I'll come back and add more later :P

By far the thing that I hate most about my favourite language is that my choice keeps changing. Every time I think I've found The One, I find five (or more) things that I hate about it. And then the grass looks greener over there...

C#

1. No easy way to check if a type is Numeric
2. It means you are probably stuck using most of the microsoft stack, IIS and MSSQL
3. Instead of being a specific tool for a specific problem, C# tries to be a language for every paradigm.
4. Lack of community. Sure, there are starting to be open-source frameworks and libraries for C#. The same ones that have been available to Java developers for years.
5. Hard to find good help. The internet is littered with poor examples of how to solve problems with C#. This goes back to problem #3.

VB .NET, but only because VB6 poisoned an entire generation of programmers

I work in a VB .NET shop that used to be a VB6 shop, and every person working here who used to be VB6 developers stubbornly refuses to learn anything about .NET. They code as if it’s still VB6, and their apps suck just like VB6 apps did. My boss actively discourages any use of LINQ because she fears it’s too difficult for others to understand, which is true because nobody wants to understand it.

I think we would have all been better off if MS just went with C#, which kills me to say because I think curly braces are far inferior to VB’s verbose closing statements.

JavaScript

From the ECMAScript 5 spec:

• 7.6.1.2 Future reserved words:

  class, enum, extends, super, const, export, import

  In strict mode: implements, let, private, public, interface, package, protected, static, yield

• 11.9.4 The Strict Equals Operator (===) vs. 11.9.1 TheEqualsOperator(==)
• 11.9.6 The Strict Equality Comparison Algorithm (NaN === NaN is false)
• 8.5 The Number Type - No real Integers, everything is a float.
• 4.2.1 Objects - prototypal inheritance

OK, I kinda enjoy the last one, but it's 7 kinds of confusing

Python:

1. No standard GUI toolkit (the community goes round and round about this but never seems to settle on anything).

2. The evolution of tools and methods to distribute and install Python apps and libraries has been, well, rocky. (Although lately this seems to be moving closer to getting fixed.)

3. CPython is still slow as interpreters go (although PyPy is looking pretty good these days, if it becomes the "standard" Python this problem goes away).

4. You can't subclass built-in classes (e.g., list and dict) without overriding a lot of methods, even if all you want to do is a simple hook into an event (e.g., to hook into an item being added to or removed from the list, you need to override delitem, append, extend, insert, pop, and remove--there's no subclassable "change" event notification, nor any "protected" methods that factor out common code used by all the above methods).

5. Up until virtualenv was invented, keeping separate Python environments for different purposes on one machine was a real pain.

Ruby.

1. Strange scoping rules - variables, constants, and methods each behave differently from each other. The rules change also depending on which keyword you used to create a closure. Or on whether you're in a class, eigenclass, object, module, or module's self. Then there's instance_eval, which changes the rules to a different set of rules. And they change again when a module is "included" or "extended", which themselves do different things to scope. And some sets of rules can't be emulated by metaprogramming, so you have to use eval. Unless you're on ruby 1.9, where all of this is different.
2. Namespacing is basically useless. If you have Foo::File, then the stdlib File is probably broken for all of Foo.
3. require statement is broken. If two files require eachother, the behavior of those files can change dramatically depending on which is loaded first from elsewhere.
4. libraries change APIs dramatically and suddenly, so you have to require specific minor revision numbers of all of your dependencies. For every single ruby application on your system.
5. The rubygems package system overrides "require" rather than putting files in the search path - because why use a system when you can replace it?

Java - no support for composition on language level

Java:

1. Very inconsistent.
2. Graphics APIs are sometimes a pain to use
3. NullPointerExceptions don't tell you what's null
4. Programs I write sometimes don't work on a different JVM which is a huge pain and contradicts Java's "Write once, run anywhere" statement.
5. Swing isn't as good as it should be.

Ruby

1. No type inference
2. Methods/functions are not first-class objects
3. Scope of variables is not lexical although scope of block variables is lexical
4. def inside def
5. the difference between super and super()

Ruby:

• Significant whitespace. For the interpreter, end of line = end of statement, unless it looks like the statement ought to continue (or you explicitly escape the newline).
• Slow
• Online documentation not as good as Python's (in defense, Python's is excellent)
• Did I mention slow?

I feel that a favorite language is impossible to choose. Dynamic typing and static typing can't quite be compared, so I'll just list which of which I use

C++:

• Template metaprogramming syntax is ugly. An implicit ::value would make it much more concise
• ->. Why can't the compiler figure out that I'm doing a ptr.thing and just do -> for me?
• I hate whitespace. So the whole vector<vector<int>> has to be vector<vector<int> > makes me get the jitters and then I can't focus whenever I see that line of code and I end up trying to figure out a way to use int[][] or something
• Macros. I personally love the concept of macros. But with C++, I that the system is a hack
• I'm a hater of ;

Python:

• Strings being immutable. Makes it so I can't just do string[4]="b"
• Lists being implicitly copied by reference. Which leaks into [[0]width]height issues
• Lack of tail recursion (I had to rig IDLE to not spit out 1000s of error messages whenever I mistyped a recursive function)
• Dictionaries keys not accepting lists/dicts
• Lack of deep scopes. When I do a list comprehension, I don't want the variable in it to affect the outer scope

MEL (Maya Expression Language):

• Single dimensions arrays: Forcing me to manually sync two or more lists, or use delimited strings to simulate more complex data structures. Naturally, they're immutable too.
• Single threaded and slow: Causing the entire Maya application to hang while it completes a task. Bonus points for not being able to kill long operations, instead having to close and re-open Maya.
• Script sourcing paths aren't recursive: Meaning every directory you want to store scripts in must all be added to the script path.
• No namespaces: Forcing the inconsistent use of naming conventions to make sure global procedures don't collide.
• Modal commands: Each command is modal, meaning the Create, Modify, and Query operations are all handled by setting flags. This also forced the developers to cause most of the commands to return arrays
• Inconsistent command style: Most array commands actually return arrays, but the Tokenize command has to take an array as a reference which it then populates, rather than spitting out an array. This among other inconsistencies.

These and several other reasons are why AutoDesk adopted Python as a secondardy scripting language, which brings up a few other annoying factors:

• Not all MEL commands are supported: Most are, but every now and then you find yourself having to use the mel() function to execute some arbitrary code. What's worse is all the annoying escaping you have to do to it.
• Inherited the modal command style: Gotta use the same create=True, query=True, edit=True stuff.

C is my favorite but it is also horrible.

• It has the worst pre-processor ever. Why didn't they use something like m4?
• The whole header vs source file model is broken. Pascal got it right with units.
• It needs case ranges in the switch statement.
• Unions and casts from void* break the type system. This makes garbage collectors impossible.
• No nested functions. GNU C has this, but it should be standard.
• No boundary checking for allocated memory. There are tools that discover this but they don't detect errors where a piece of code miscalculates an address and writes to an allocated region which isn't related at all. I hate the whole pointer arithmetic.
• No bounds checking for arrays.
• Too many issues regarding portability. Even wchar_t differs across platforms.

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!

Python: Array part-selection doesn't give you what you asked for.

a[1] gives you one element
a[1:2] gives you one element, not [ a[1], a[2] ]
a[1:3] gives 2 elements

I hate that, but maybe that's just because I mostly work in Verilog.

Python:

• speed
• static analysis (lack of)
• anonymous functions limited to one expression

C#

• Generic parameters are invariant C# 4.0 introduced covariance and contravariance for generic types
• Overridable class members must explicitly be marked as virtual

Java

• Missing unsigned numeric data types
• Primitive data types aren't objects

C++

1. It takes so much time to make a simple snippet of code.
2. for(std::vector::const_iterator iter = [...]
3. vector.remove() doesn't remove.
4. vector.push_front() doesn't exist.
5. header files
6. No lambda
7. No automatic empty virtual destructor if there is at least one virtual function.

Rewrote this after some more thinking ...

Five things I hate about PHP although I love it (in no particular order):

• Inconsistent naming and parameter order in the built in functions.
• Object oriented approach to arrays thanks to the SPL but sadly not to strings (yet).
• No real concurrency in PHP itself, only via the hosting webservers multiprocessing
• No asynchronous calls like in JavaScript
• Opcode caching only via extensions. Not really bad but just annoying.

Those are the language features (or lack of) that annoy me but the much bigger problems are these more people/community related things:

1. The fact that a lot of people who use PHP, don't know anything about programming and good practices in general and produce really messy code. JavaScript has the same problem.

2. The huge amount of tutorials/book that teach really bad practices and style. This may be the main cause of #3.

3. The bad reputation it has developed mostly because of #3 and #4.

C#

I'm very happy with C# but these two really annoy me:

• Constructor-based initialization for immutable classes is less convenient, less intuitive (when you read the code you don't understand what you assign to what), has less IDE backing than inline object initialization. This makes you lean towards mutable classes inevitably. I know this has been mentioned before, but I strictly have problems with initialization syntax for immutable classes.

• switch is too verbose. Whenever I see a situation where a switch would be proper, I'm really inclined to use an if..else if.. just because it's more terse (~30% less typing). I think there should be no fallthrough for switch, break should be implied, and case should allow comma separated list of values.

Having to assume we have a language. Do we?

Java is slow according to many but I agree to a certain to degree of usage.

Java is dramatic. They have lots of classes just for a single thing you wanted to do. But you know flexibility property XD.

Java is hard at first but fun as always.

When you are writing a simple code for printing "Hello,World!" PLEASE DO NOT USE JAVA! XD I'm sure I am justified.

Java is a mixture so don't say it is purely an OOP language.

There's many more but I am only restricted to five XD. Thanks!

My 5 for Delphi:

1. Procedures and functions aren't necessarily distinguished from variables if not parameterized (eg, I can have statement such as x := GetPositionOnScreen; instead of x := GetPositionOnScreen();)
2. Try/Finally and Try/Except needs to be nested (stated once before, but it's still one of mine as well).
3. Not case sensitive.
4. Can have a multiple objects (functions, global variables, local variables) named the same and Delphi will happily try to figure out what you mean. names should be unique.
5. Odd if condition rules. a single conditional check doesn't require a () around it, but if I do multiple checks, I need a () around each one, and sometimes multiple nested sets for bigger checks.
6. No inherited includes. If I need to reference functionality from the Windows unit in a base and an inherited form, I have to include Windows in both.

HyperTalk:

• Died long long ago
• No simple assignment (you can't just say a := 3, you have to say put 3 into a
• No nested functions
• No real data structures, just strings. To make "lists", you delimit items with the itemDelimiter and escape them manually. You can also get lines and words like get word 2 of line 5 of txt

As an aside, I think one of the coolest features unique to HyperTalk is the special it variable:

ask "How many years old are you?"
answer "You are " & it*12 & " months old."

Python

Ones that I just don't understand ...

• math.ceil() and math.floor() return floats, not integers (probably to avoid an integer overflow in the underlying C function - but why not cast to a Python long?)
• len() is a function not a method
• reload() is very limited, does not reload a module 9 times out of 10, only reloads an imported label if it is a module - i.e. cannot do from bar import foo; reload(foo) if foo is not itself a module
• Mutable default arguments have a single reference (why not a new instance each function call?!)
• All these underscored variables - if they are so private, how come we see inbuilt ones so much in code? Get a namespace!
• Strings are not mutable - maybe there is a good reason for this but I have come across many situations where I would like to tweak one particular character ...

Ones that make sense based on the implementation but are annoying ...

• array.sort() does not return an array (I suppose it happens in-place)
• List/generator comprehensions don't define a new scope (Is just syntactic sugar for a for loop, right?)

and a couple that are fixed in Python 3

• Integer division by default
• global can only refer to the top level namespace

Scala:

• standard library weirdnesses: it does not always show best practices, and is way underdocumented
• the hard-coded FunctionX, TupleX classes
• lack of properties: getters and setters are separate, which violates DRY, and makes things such as FRP nearly impossible
• need of = _ to initialize properties

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, double MyFunction()
{
    ....
    return x,y,z;
}


public void TestMyFunction()
{
    int x, string y, double z = MyFunction();
}

(8) No support for covariant return types

I have some gripes about the generics implementation, but I'll cut it there. I think C# is a great language for doing all the GUI, networking and configuration plumbing and is my number one language for getting things up and going quickly in a way that can be supported in the long run.

C#

1) Lack of practical ability to write generics for value types. For example, any idiot (well most idiots) can write a routine that calculates the standard deviation of a list of int, float, double, etc in C++, it is straightforward to write, easy to read and performs as fast non-generic code. I think if you can write something in C# that is close to hitting any one of these 3 without being ridiculous on the other 2, you are a really great programmer.

2) Covariance and contra variance, although this is being added to 4.

3) Extremely poor documentation of LINQ (alright, not really part of the language).

4) Trying to use foreach/iterators when I want to do the same thing every time except something slightly different the last time (such as concatate a bunch of strings with commas between them and the word and between the last two). If I write it with an IEnumerable, it is hard to write and read, and with a for (int i=0 i < ...) it isn't much better and it is less efficient.

5) I know I am going to get complaints about this, but lack of checked exceptions. This does not need to be implemented the way it is in java (The framework developers do make some very good points on why they didn't do this), but I would be happy with a compiler warning users who don't like checked exceptions can turn off.

REBOL

REBOL is among my favorite languages. I can't say that I have a favorite, though Haskell ranks pretty high as well.

1. Its odd syntax scares off many developers before they even give it a try.

   use [email rules url] [
   
   
   

   ; A small DSL that sends email to people about URLs.
   rules: [
       some [
           into [
               set email email!
               set url url!
               (send/subject email url reform [ "Check Out" url ])
           ]
       ]
   ]
   
   
   ; Global context
   notify: func [ [catch] dsl [block!] ] [
       unless parse dsl rules [
           throw make error! "You screwed up somehow."
       ]
   ]
   

   ]

   notify [ [ a@b.com http://www.google.com ] [ b@c.com http://www.yahoo.com ] ]

2. Recursive dialects are very easy to validate with PARSE but very difficult to evaluate. (Stacks can be helpful here.)

3. REBOL has very poor integration with many popular technologies, particularly XML. I suspect this is partly arrogance, because the REBOL BLOCK! datatype can do almost everything XML can do. However, the real world has XML in it.
4. No Unicode.
5. Thanks to AltMe, REBOL's user community is very insular. I can understand why they want to use AltMe. It's written in REBOL and shows off its strengths. Unfortunately it also puts them off on their own little island.

The upcoming REBOL 3 will hopefully fix many of these issues, except for the last one.

Python:

1) It's a scripting language and not a fully compiled one (I'd prefer to be able to compile binaries—I don't care about bytecode). This is very annoying if I have to use very many libraries (i.e. everyone who uses my program has to install all the libraries, and this basically means no normal people will be able to, or have the patience to, properly set it up—unless I do a ton of work that should be unnecessary). I know ways to make binaries, but they don't always work, and I'm guessing they bundle the interpreter in the binaries anyhow (and I don't want that). Now, if I could get a bytecode compiler that would include copies of all the files that I imported (and only those) to be placed in my program's folder, that might be a suitable compromise (then no one would have to download extra libraries and such). It would also be nice if the compiled python files could be compressed into a single file with one specified as the file to run the program before this is done.

2) It seems a bit buggy at times; there have been a few times when code that was supposed to work simply did not (there were no programmer errors), particularly code relating to such as "from moduleX import *", and other import-related issues, as well as some issues pertaining to global and local variables.

3) Maximum recursion depth could be higher. There has been at least one time when I felt that I needed it to go higher.

4) No switch statement (let alone one that allows for numbers, strings and ranges)

5) The newer Python versions seem to be doing away with a lot of useful string operations, and they don't seem to have simple documentation on how to do the same things without them.

6) Forced automatic garbage collection (I'd like to be able to do it manually, although not necessarily forced to do so).

7) No pre-made Timer class without the use of a GUI (well, there might be one, but after all the searching I've done, it's sure not convenient to find! I actually did find something, but it didn't work at all when I tried it.) By a timer, I mean the sort that will execute a specified function every x seconds, with the ability to turn it off when desired, etc.

8) People in the community who give examples rarely tell what modules they imported, and how they imported them.

9) There's not a lot of support for integration with Lua.

10) There doesn't seem to be a way to add an extra function to a particular instance of a class (and not the entire class at large), unless you dynamically add an object variable to that class with the object having the needed function (but still, you have to make another class just for that).

Java:

• No procedural coding, it compiles into procedural code, So let me Use it!
• No multiple inheritance, trying to do the same thing with 15,000 intefaces suck.
• Date class, do I need to say more.
• That I cannot use polymorphism to it full extent. Java will not override with different parameter types being to trigger.
• I cant think of a fifth reason,if I do i'm come back and edit this post.

C#

5. The null-coalescing operator

The ?? operator allows you to write:

x = y ?? z;

instead of:

x = (y == null) ? y : z;

I like this operator, but I want another one:

x = y ??? y.foo() : z.foo();

instead of

x = (y == null) ? y.foo() : z.foo();

I use this kind of thing all the time, and I find it annoying to type the == null part.

4. Equals should have better support

I have having to start every Equals(object obj) method with: MyClass other = obj as MyClass; if (other == null) return false;

You should only have to write:

public override bool Equals(MyClass other) {...}

And the language should take care of providing the Equals(object obj) method.
NOTE: other should be guaranteed to not be null.

3. Cannot use ternary operator with different types

This doesn't compile, and I think it should!

string foo = "hello";
int bar = 4;
object baz = foo == null ? foo : bar;

2. Lack of namespace private

I like the internal protection, but I wish there was a protection which would only allow access from within the same exact namespace. This would be nice to better control access in large class libraries.

1. No multiple inheritance

I really only use implementation (class) inheritance for default implementations of an interface, but there are plenty of times when I want to do just that.

• The length property is easily confused with the length() function; use size() instead
• The syntax to interpolate variable in selector strings('" +$.month+ "') stinks
• $(event.currentTarget) does not always work for bubbling and capturing
• attribute syntax works ("[class='foot']") in places where selector syntax (".foot") returns nothing
• Contains selector ([class~=done]) sometimes fails where JavaScript (this.className.search("done") > 0) works

Python

• No namespaces.
• Pseudo-private attributes / name mangling (mostly with getattr).
• Filepath manipulation is spread across multiple modules. Stringing together os.path calls is ugly, difficult to read, and in most cases, violates DRY. Common filepath operations still don't have convenience functions, like getting a list of files in a dir. The path - type module to fix this was rejected.

([f for f in os.listdir('/file/path') if os.path.isfile(os.path.join('/file/path', f))])

• Python documentation (I'm very, very, very grateful there is documentation at all, and that it is formatted so nicely, but I hate wading through 5000 lines of quick-start usage examples to find the individual function documentation for particular modules (I'm looking at you optparse and logging)). Built-in types are documented piecemeal in nearly 10 different places.

Lua

• If you do foo.bar(1,2) then 'self' is nil inside the bar method. You must remember to do foo:bar(1,2) instead. I'd rather have that switched ('self' should be defined by default unless you use the ':' operator, or you call a function that isn't a method).
• Variables are global by default. I'd rather ditch the 'local' keyword and have a 'global' one instead.
• Undeclared variables are assigned the nil. I'd rather receive an error message. You can sidestep this by manipulating the global env's metatable, but I'd rather have it implemented by default and be able to deactivate it.
• Multiple returned values on parameters are not handled very nicely. Say you have a function foo() that returns 1,2,3 (three values) and bar() returns 4,5 (two values). If you do print(foo(),bar()) you will get "1,4,5" ... only the "last" tuple is expanded on calls.
• The # (table length) operator only works in tables indexed with continuous integers. If your table isn't like that and you want to know how many elements does it have, you need to either parse it with a loop, or update a counter each time you insert/remove an element from it.

I just discovered I cannot use Enum as a type constraint when creating a Generic method in c#.

Microsoft has a good enough explanation as to why, but still. I'm MAD

public static T MyFunc<T>(string arg) where T:Enum //wont work :(

JavaFX

• Type inference sometimes doesn't behave like you would expect, so you often need to explicitly declare the type.
• def behaves likes const in C and not final in Java
• you can insert a value in a sequence by accessing an index >= seq.length, which should actually throw a compiler error (according to the reference).
• if you assign null to a String, it defaults to "". If you assign null to an Integer, a compiler error is thrown (in contrast to what the reference says).
• handles CheckedExceptions the same way as RuntimeExceptions

C#

• Cannot create a reference (var &t = struct)
• No local scope destructors (IDispose comes close but its not the same)
• ToString, i almost dislike that every object has it but it turns out i dislike everything using it like string.format does. I rather have things that accepts a certain type (like ints, floats, text, chars only). So instead of passing in any object i need to pass in something with a implicit typecast or interface. I ended up writing something like this to safely escape text for html which worked great.
• Cannot use a virtual typecast (blah)obj; does not work if obj does not inherit/has an interface of blah. Simple workaround is to supply an interface with a convert function.
• Has no local creation. Instead of writing var o = new Item(); i would like to write (something like) Item o() (with an automatic dispose if it has one).

VB.NET

1) If Not x Is "foo" (instead of <> "foo")
2) "OrElse" and "AndAlso" short circuit (instead of simply "Or" and "And", which act differently)
3) Nothing (instead of Null)

The lack of a preprocessor in C#.

I know they left it out because some folks can abuse it, but I think they threw the baby out with the bathwater. Code generation is regarded as a good thing, and in C++ the preprocessor was my first-line code generator.

Python:

1) line continuation syntax: "...\" works, but "...\ " does not, and that trailing space is generally invisible, without unusual eol-marking by editer.
2) a bare 'raise' is invisible in the stack trace, as the stack trace looks like the previous raised exception.
3) slow
4) poor integration into web-servers (mod_python: dead, mod_wsgi: limited scope of operation). This is complicated by 3], requiring daemonization or some sort of memory-persistance to perform well.
5) overly tolerant of mixed tabs and spaces, allowing changes to control flow to sometimes remain hidden. (maybe fixed in recent versions)

Lua:

• The built-in error system is absolutely horrendous

  You can implement a try-catch system by modifying the Lua interpreter; but it has no compatibility with the errors that are thrown by the built in functions.

• The fact they have __newindex instead of __setindex as the setter

  ... and __newindex is only fired when the key doesn't already exist. If it does, no metamethod is called at all.

• No good type comparison system.

  There's the type() function but it only handles the basic types (all tables are tables). It really needs to have a metamethod for type comparisons. I've implemented this before with an 'is' operator and a __type metamethod and it works really nicely.

• It's a bitch to define new keywords.

  You can do it, but the code inside Lua isn't well documented so it's kind of trial and error to find out how to get the result you want. This is a major issue when you want to implement the things I mentioned above yourself (not so much __setindex though, that's an easy modification).

• I can't use it in a web browser.

  Yeah not really a problem with the language itself, but damn, would I love to be able to use Lua instead of Javascript... :)

C

• String handling
• Memory management (making a decision about who should allocate and who should free it)
• No namespaces (the biggest)
• No lists/arrays and other basic DS in standard library

JavaScript

• Using a variable without var automatically makes it global
• Semicolons are not mandatory
• Comparison operators "==" and "===" and confusions about their usage
• No proper support to work on binary data
• Again.. No namespaces
• Variables don't have block scope. (Quite irritating coming from C world)

Object Pascal:

• There's a lot of jumping back and forth in the file you're editing since the interface and implementation are split into two parts but still jammed into the same file.
• Dynamic indexing of arrays, strings start at 1, you specify the starting index when declaring fixed arrays and dynamically allocated arrays always start at 0.
• Classes and objects (not to speak of interfaces) are bolted on top of the language and among other things can't be stack allocated like records can.
• When calling functions without parameters the () are optional, leading to a lot of pain when you are dealing with function pointers or trying to refer to the result of a function using the function name.
• Parameter lists can't handle fixed array types or function pointer types without external type definitions.

This is just the language, the sorry excuse for a standard library and flaky IDE deserve their own lists.

I have only one but I believe it worth sharing.

CSharp / .NET

We have Length property to get number of elements in array and Count property to get number of elements in collection. It looks more stranger if you consider the fact that CLR automatically adds IList, ICollection, IEnumerable to zero-based one-dimenssonal arrays behind the scene.

I believe CLR team and BCL team had hard times discussing this subject ;)

Objective-C 2.0

Sticking strictly to the language and runtime, and not the libraries, and not in any particular order:

1. Lack of cVars.
2. No modules. I'm not terribly unhappy with a lack of namespaces, but modules would be nice to have.
3. Ivar-based property syntax requires declarations using the variable name in 3 places. It's fairly hideous.
4. C heritage. Anything to hate about the C language, except for OO and GC, is present.
5. Objects can't live on the stack. Not a problem with Obj-C so much as what it does to programming practices in other languages. I find it strange when I get a return value on the stack in C++, for instance. If I'm not actually looking at the library documentation when I write the code, I'll assume that every function returns a pointer, which often makes for some siginificant cleanup later.

Python:

• no delimiter signaling the end of blocks introduces ambiguity such that automatic indentation will not work with poorly formatted code.
• no macros (decorators don't count)
• no library auto-fetch like haskell's cabal, or perl's CPAN
• can't declare variables const (yeah it's possible to role your own but ... )
• meta-programming is nerfed
• almost forgot the Global Interpreter Lock

C# 4.0

The "dynamic" keyword, ripe for abuse. If you want/need to use Reflection, use and make it obvious that you're using it, don't try and disguise it with dynamic.

VB.NET

• Weakly typed by default (Option Strict fixes this, but it's not on by default)
• Does not require parentheses on methods (myFunction instead of myFunction() and so on)
• Does use parentheses for array definition/use (myArray(12) instead of myArray[12])
• Does not support direct incrementation (i++)
• Does support legacy On Error keywords and the whole VB6-Namespace

Python

• slow
• I finally got used to the print statement, and now there's this print function??? (py3k)
• never got py2exe or cxFreeze working
• not standardized (minor nitpicking)
• recursion depth only 100 (iirc)

Things I hate about Python:

• there's no compiler
• it's not taken seriously

Things that annoy me about Python:

• (self,
• no private
• breaking compatibility

• "working as intended" when it's plainly a bug
• no goto
• bugged references (foreach $arr => &$val ... foreach $arr => $val)
• no multiple inheritance
• no compiler that really works without having to sacrifice a lamb to a dark god

SAS ^[1]

• Never has own ideas (every thing is borrowed).

• Greedy for huge datasets.

• Uses Java, but never learned what it is to be an object.

• Steals Perl, but hide it in its data step.

• Lie always with statisticians!