Why ... Sucks

Why C sucks

Quite easy:

    * Primitive type system
    * No overloading
    * Limited possibility of data abstraction, polymorphism, subtyping and code reuse
    * No metaprogramming except preprocessor macros
    * No exceptions

Why C++ sucks

    * No garbage collection
    * No reflection
    * Type system excessively complicated
    * No support for variadic functions and variadic templates
    * Really hard to write efficient, object oriented mathematical code
    * Not even compile time reflection (ie in a template you cannot inspect the parameter type)

Why C# sucks

    * Way too prolix
    * It has many special purpose constructs (such as yield/foreach)
    * Not so powerful generic system
    * No compile time metaprogramming facility

Why Java sucks

    * No data pointers nor function pointers
    * No templates (java 1.5 templates are a fake)
    * No operator overloading
    * No anonymous methods (C++ operator())
    * Extremely verbose to write - and slow to run

Why Haskell sucks

    * Indentation dependent syntax
    * Types and values live in completely different worlds
    * No metaprogramming (solved by Template Haskell)
    * It is quite difficult to learn and to use for simple things, expecially if you come from an imperative/OO background. Sometimes, language features, extensions and design patterns are best documented by research articles, instead of tutorials written in an informal style.

Why Nemerle sucks

Some reasons as C#, except first and last.

Why Ocaml sucks

    * Too many keywords
    * Ugly syntax
    * No templates and oveloading (unless you are using a still a bit limited and incompilete gcaml)
    * Strange behavior of '_a and 'a types.

Why Ruby sucks

    * Slow
    * Complex
    * Surprising
    * Inconsistent
    * Bad embedding
    * No native threads
    * No m17n

High-level languages offer built-in solutions to commonly encountered
problems. For example, it’s well known that the vast majority of program
errors have to do with memory mismanagement. Before you can use an
object, you have to allocate some space for it, initialize it properly, keep
track of it somehow, and dispose of it properly. Of course, each of these
tasks is extraordinarily tedious and error-prone, with disastrous consequences
for the slightest error. Detecting and correcting these mistakes are
notoriously difficult, because they are often sensitive to subtle differences
in configuration and usage patterns for different users.
Use a pointer to a structure (but forget to allocate memory for it), and your
program will crash. Use an improperly initialized structure, and it corrupts
your program, and it will crash, but perhaps not right away. Fail to keep
track of an object, and you might deallocate its space while it’s still in use.
Crash city. Better allocate some more structures to keep track of the structures
that you need to allocate space for. But if you’re conservative, and
never reclaim an object unless you’re absolutely sure it’s no longer in use,
watch out. Pretty soon you’ll fill up with unreclaimed objects, run out of
memory, and crash. This is the dreaded “memory leak.”
What happens when your memory space becomes fragmented? The remedy
would normally be to tidy things up by moving the objects around, but
you can’t in C++—if you forget to update every reference to every object
correctly, you corrupt your program and you crash.
Most real high-level languages give you a solution for this—it’s called a
garbage collector. It tracks all your objects for you, recycles them when
they’re done, and never makes a mistake. When you use a language with a
built-in garbage collector, several wonderful things happen:
• The vast majority of your bugs immediately disappear. Now, isn’t
that nice?
• Your code becomes much smaller and easier to write and understand,
because it isn’t cluttered with memory-management details.
• Your code is more likely to run at maximum efficiency on many different
platforms in many different configurations.
C++ users, alas, are forced to pick up their garbage manually. Many have
been brainwashed into thinking that somehow this is more efficient than
using something written by experts especially for the platform they use.
These same people probably prefer to create disk files by asking for platter,
track, and sector numbers instead of by name. It may be more efficient
once or twice on a given configuration, but you sure wouldn’t want to use a
word processor this way.
You don’t even have to take our word for it. Go read The Measured Cost of
Conservative Garbage Collection by B. Zorn (Technical Report CU-CS-
573-92, University of Colorado at Boulder) which describes the results of a
study comparing performance of programmer-optimized memory management
techniques in C versus using a standard garbage collector. C programmers
get significantly worse performance by rolling their own.
OK, suppose you’re one of those enlightened C++ programmers who wants
a garbage collector. You’re not alone, lots of people agree it’s a good idea,
and they try to build one. Oh my, guess what. It turns out that you can’t add
garbage collection to C++ and get anything nearly as good as a language
that comes with one built-in. For one thing, (surprise!) the objects in C++
are no longer objects when your code is compiled and running. They’re just
part of a continuous hexadecimal sludge. There’s no dynamic type information—
no way any garbage collector (or for that matter, a user with a
debugger) can point to any random memory location and tell for sure what
object is there, what its type is, and whether someone’s using it at the
moment.
The second thing is that even if you could write a garbage collector that
only detected objects some of the time, you’d still be screwed if you tried
to reuse code from anyone else who didn’t use your particular system. And
since there’s no standard garbage collector for C++, this will most assuredly
happen. Let’s say I write a database with my garbage collector, and
you write a window system with yours. When you close one of your windows
containing one of my database records, your window wouldn’t know
how to notify my record that it was no longer being referenced. These
objects would just hang around until all available space was filled up—a
memory leak, all over again.