What are five things you hate about your favorite language?

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

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

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

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

---

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

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

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. All the coolest things are insanely complex, but then, all the coolness is also wrapped up in such a small amount of code that you feel stupid for struggling to follow it

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

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

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

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

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

PHP:

1. Forces me to make unnecessary variables:

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

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

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

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

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

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

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

C++

• Far too easy to randomly corrupt memory and create almost impossible-to-find bugs (although, Valgrind 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:

   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:

    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:

    / <?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:

    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:

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

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

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

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

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

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

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

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

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

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?

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

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.

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

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

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.

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.

Python:

0. Too slow!
1. 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.
2. statements don't return values (if, print, while, for, etc). This is only a problem when dealing with lambdas.
3. 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.
4. 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"?

Groovy/Grails

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

ColdFusion

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

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__])

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.

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.

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

I have a book exploring all sorts of projects in SNOBOL. 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/Unicon. 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.

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.

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.

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

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

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

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

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

• 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

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.

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

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

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.

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.

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

C/C++

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

Java

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

Python

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

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.

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

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

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.

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!

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

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.

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
• my.var is a very confusing variable naming convention for an OO language, see Google's style guide
• I should not have to regret using a loop
• Cryptic error messages

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.

C#.

What I hate most:

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

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

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

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

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

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)

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.

Objective Caml

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

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.

Scheme:

• Lack of users/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 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

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.