What are five things you hate about your favorite language? [closed]

Question

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

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

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

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

---

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

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

Answer 1

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

Answer 2

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

Answer 3

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?

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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)

Answer 8

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.

Answer 9

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

Answer 10

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

Answer 11

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.

Answer 12

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)

Answer 13

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.

Answer 14

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.

Answer 15

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

Answer 16

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.

Answer 17

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.

Answer 18

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

Answer 19

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.

Answer 20

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)

Answer 21

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.

Answer 22

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

Answer 23

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.

Answer 24

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.

Answer 25

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.

Answer 26

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

Answer 27

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)

Answer 28

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

Answer 29

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

Answer 30

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