Slashdot Mirror
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."
This guy has a lot of nerve telling other folks what programming language to use.
You should bash Java, and C++ devs will agree. You should bash C++, and Java devs will agree.
Now you bashed both languages that has probably the most devs. Except some dynamic languages, of course (PHP and JS comes to mind).
Oh, you insulted them, too.
OMG...
Shorter Rob Pike: all those other languages suck, but the one I invented rocks. It's elegant and simple just like Lisp was back in the sixties!
I'm reminded of this blog post I read, where the author described it as "The Hurricane Lantern Effect". You look at someone else performing a task, and you think "geez, what an idiot! I can do it better in ten different ways!".
Then they hand the task off to you, and you slowly realize that each of your ten improvements isn't actually any better.
I bet you that if it's still around in ten years, someone else will decry Go 10.0 as being a "bureaucratic programming language".
I kinda miss those days--easy to learn and embedded 6502 machine code subroutines to make things move faster.
"The only legitimate use of a computer is to play games." - Eugene Jarvis
I'm not saying that that would be it, but I would not mind a programming environment where the text files have gone the way of the dodo. With Eclipse we use a rather strong "Clean Up" where missing keywords (e.g. final) are added and statements are reformatted (etc.). Wouldn't it be easier to do without that kind of stuff? What about comparing the differences of two branches (or new code with the head) where the actual semantic changes are compared vs lines of text? What about an environment where you can easily hide complexity and meta-information? Or, possibly, add new literals? Where the base of the language is shifted to the Abstract Syntax Tree, not so much the syntax.
Thank you, I do agree. I was about to write to the authors of Go, but I thought better of it: simply because I cannot see Go go anywhere.
Basically, they do really weird things:
- no exceptions
- half assed immutability concepts
- focus on compile time (compile time? really? yes really!)
- no modularization system (it's like the micro-kernel vs mono-kernel fight all over)
It's got some good ideas that make it interesting for small, fast, secure applications, but not so many that it becomes interesting. I could see technically make some headway for small monolithic kernels. But their market placement is lacking to the point that it is non-existent.
C++ done right with scoped classes doesn't need garbage collection. No, really it doesn't, most people have just never worked with scoped classes, and it's mind-boggling that they don't show up in C++0x (other than the half-useless auto_ptr we've always had). I have a real problem with garbage collection in production code, because it's freaking hard to find and plug resource leaks. If you forget to close a file in a garbage collected language, it will probably get closed eventually when the garbage collector cleans up, but the program likely has some bug anyhow, and the GC has made it a horrible intermittant bug that changes behavior in a lab environment!
C++ has two key abilities that any good language needs, but few have: scoped resoruces (but only in that it allows you to add them yourself!), and const references. Why are people still making high level languages where references aren't const by default?!? In C# I can't (usually) tell from the function signature whether changing an argument will change the caller's copy, nor can I be sure from an interface that a given function won't alter what I pass to it - what insanity is that? (And Java is only slightly better.)
Socialism: a lie told by totalitarians and believed by fools.
It's why COBOL was invented, with syntax like.
SUBTRACT DEBIT FROM BALANCE GIVING NEWBALANCE.
I kid you not, Adm Hopper actually thought that would make programming easier, and she was no moron.
COBOL was designed like this so it could be read and understood by corporate auditors and accountants - and for the recruitment and training of accountants as COBOL programmers.
It makes perfect sense when you remember that modern bookkeeping rules are the product of hundreds of years of law and practical experience which the neolithic geek did not have.
Nearly everything I was unhappy about in C++ is better in D.
I suppose it's worth expanding my polymorphism comment slightly. People who think that objecitve C's Messaging concept is just semantic sugar are not understanding it clearly.
In objective C you don't "call an object method" but rather you pass a message to the object. THe object, if it chooses to reply, does not "return" a value but instead sends back a reply message.
What's the difference? Well in implementation very often nothing. The message that is sent is a message name and a list of calling args and their names. 99.9% of the time the object chooses to resolve this message by finding a method that corresponds to that prototype. So that looks just like C++. But the thing is, it does not have to do that. It could choose to re-interpret the message. And in particular it might use some other recently method added later than "linking" time to the object. Thus how the method calls are bound does not happen at link time. They often are prebound then for efficiency, but they do not have to be. The same is true of the return values.
THis makes it more like java in a way.
But the nice thing is that the overall syntax is just a thin layer on basic C.
Another reason that Objective C is so nice now is that it had a chance to mature and modernize out of the spotlight. Having lived mainly in the apple ecosystem it has a lot of standard libs now with dictionaries and core data tied to persistent storage, MVCs, and so forth that are all (mostly) self consistent and not the tower of babble on finds in java. THings like get-set commands can be handled by decorators rather than explicit coding. That's cool because by letting the compiler pre-processor define what is in a get set you can inherit all sorts of things like listeners binding to your variables that you did not explicitly encode. Just recomoile your code and poof you inherit all the new features.
Some drink at the fountain of knowledge. Others just gargle.
Even [XYZ]-modem used a similar setup.
Not quite. Xmodem and Ymodem use SOH and STX to denote start of sectors and ACK/NAK, but after that it's just a raw 8-bit file dump to the checksum/crc bytes with no concern for character set encoding. Zmodem uses DLE and escapes out most of the C0 bytes (XON/XOFF and CAN must be escaped regardless of session flags), but doesn't use the rest of the codes for anything.
Most of C0/C1 codes mixed right in with the text for formatting/presentation, e.g. embedding backspaces followed by underscores to get underlined text. Some of the others did link-level too. It was a mess, so much so that parsers for ANSI X3.64 / ECMA-48 style escape sequences take a LOT of work to get right (passing 'vttest' is not trivial).
UTF-8 isn't bad. It specifies that character decoding be done before any other processing including C0/C1 and ANSI escape sequences, which makes it very easy to integrate on the reading side. Harder is dealing with wide chars on the screen and user I/O. Compared to Avatar's repeat character and ANSI fallback features, it's much more bang for the buck. And let's not talk about "ANSI Music" and it's use of SO (Ctrl-N) because it's the "music symbol" in CP437!
(Disclaimer: I've written a console-based terminal emulator that does a decent VT102/220, UTF-8, X/Y/Zmodem/Kermit, and lots of other things.)
Actually, English is a very easy language to learn, to a certain degree. It's a lot like learning to play guitar. Any moron can learn to play a few chords on a guitar and make a simple song. However, only really talented people can become true virtuosos of the instrument and play like Joe Satriani or Steve Vai. English is like that: it's easy to learn it to a minimal degree and become somewhat conversant. The words are short and simple, you don't have to worry about silly things like word gender, etc. However, becoming truly fluent in it (so that you can read and write advanced literature, for instance) is difficult and time-consuming because you have to memorize so many things, and learning some Greek and Latin is very useful for understanding many larger words.
The main problems of the major languages are known, but not widely recognized by many programmers.
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.
And that's where we are today.