Google Engineer Decries Complexity of Java, C++

snydeq writes "Google distinguished engineer Rob Pike ripped the use of Java and C++ during his keynote at OSCON, saying that these 'industrial programming languages' are way too complex and not adequately suited for today's computing environments. 'I think these languages are too hard to use, too subtle, too intricate. They're far too verbose and their subtlety, intricacy and verbosity seem to be increasing over time. They're oversold, and used far too broadly,' Pike said. 'How do we have stuff like this [get to be] the standard way of computing that is taught in schools and is used in industry? [This sort of programming] is very bureaucratic. Every step must be justified to the compiler.' Pike also spoke out against the performance of interpreted languages and dynamic typing."

Comments

Re:Maybe because programmers like to be clear

[ciggieposeur]

Nearly everything I was unhappy about in C++ is better in D.

What's wrong with the main languages

[Animats]

The main problems of the major languages are known, but not widely recognized by many programmers.

• C Started out with only built-in types, to which a type system was retrofitted. (You have to go back to pre-K&R C documents to see this, but originally, there was just "char", "int", "float", and pointers to them. "struct" was just a set of offsets, with no type checking. You couldn't even use the same field name in two different structs.) Bolting a type system onto this took a long time, and resulted in problems ranging from "array=pointer" to cascading recompilation because "include" files contain implementation details of included modules.
  
  The killer problems with C today mostly involve lying to the language. "int read(int fd, char* buf, size_t bufl);" is a lie; you're telling the compiler that the function accepts the address of a pointer, while in fact it accepts a reference to an array of char of length "bufl". This lie is the root cause of most buffer overflows. The other big problems with C involve the fact that you have to obsess on who owns what, both for allocation and concurrency locking purposes, yet the language provides no help whatsoever in dealing with those issues.
• C++ Was supposed to fix the major problems with C. A few bad design decisions in the type system made that hopeless. The underlying problems with arrays remained. An attempt was made to paper that over with the "standard template library" collection classes. Collection classes were a big step forward, but they were really just papering over the moldy type system underneath, and the mold kept coming through the wallpaper. The C++ standards committee keeps adding bells and whistles to the template system, but after ten years they still don't have anything good enough to release.
• Java Was supposed to fix the major problems with C. Java itself isn't a bad language, but somehow it got buried under a huge pile of libraries of mediocre quality. Then a template system was bolted on top, along with ever more elaborate "packaging" systems. Java ended up as the successor to COBOL, something that surprised its creators.
• Python Python is an elegant language held back by painfully slow implementations. Some of the implementation speed problems come from the most common implementation, which is a naive (non-optimizing) interpreter, but some of them come from bad design decisions about when to bind. Late-binding languages are not inherently slow, but Python has lookup by name built into the language specification in ways which make it almost impossible to speed up the language as defined. (The Unladen Swallow team is discovering this the hard way; they're getting only marginal speed improvements with their JIT compiler.) Python also addresses concurrency badly; everything is potentially shared and one thread can even patch the code of another. The end result is that only one thread can run at a time in most implementations.
• JavaScript A painful language which, due to massive efforts to speed it up, is starting to take over in non-browser applications. JavaScript is the object model of Self expressed in syntax somewhat like that of C. This is ugly but adequate.

And that's where we are today.