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."
Pike detailed the shortcomings of such languages as a way of describing the goals that he and other Google engineers have for a new programming language they developed, called Go.
Oh, so he's pushing a competing product and denigrating his competition? Nothing to see here, I think.
Google Engineer promotes Google language Go and claims it addresses weaknesses of existing languages, including Java and C++.
Democracy Now! - your daily, uncensored, corporate-free
These sorts of languages (and the underlying religious cults they bring with them) are probably appropriate for some uses. But what I see done in my life-critical real-time processor applications borders on criminal. Data hiding? How the f'ing hell do I check what is going on to the bit level is some twit determined to "hide the data". This is particularly apt right now, because we are adding a feature to our code that was almost trivial to add to our FORTRAN simulations, and because of the "cult of classes" C++ programming it's damn near impossible in the final product, and completely impossible to look at and tell what the heck it's doing. Trying to test it like a black box is never going to get to the level we need.
We started having peer reviews of the code, and my colleagues and I are the designers of the system, so we would hypothetically need to sign off on it. We went for two hours to get 10 lines into it, no one could explain how it was working but that we should just "trust the compiler". That didn't fly with us, so the solution was to *not have us present at the peer reviews* since we were "disruptive"
What we need is someone that can write straightforward procedural code, but no one seem to be willing or able to do it any more. It has all the features of a cult or a secret society, even when you get someone to understand and agree, they won't deviate from their dogma.
This same rant has apeared generation after generation, and often from peope smart nough to know better. It's why COBOL was invented, with syntax like.
I kid you not, Adm Hopper actually thought that would make programming easier, and she was no moron.
Guess what guys? The reason programming is hard is because you must clearly and unambiguously state what you want to have happen. Yes, the languages could surely be better - the syntax and intricacies of C++ are pretty nightmarish, and Java only fixes some of those issues while introducing others. There's surely a better way to do resource management, and multi-threading, that are less error prone without making you give up needed control. But it's still going to be hard to solve hard problems, and you're still going to need to be very precise and detailed in describing how to solve a problem.
Irreducible complexity is irreducible.
Socialism: a lie told by totalitarians and believed by fools.
The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions.
We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.
- Bjarne Stroustrup
No sig today...
Even though for most people that's the first hurdle (and one that they fail), I'm not sure that this is the main reason programming is hard. I know plenty of people who've mastered the basic mechanics of doing that, and yet still don't program too well because they can't make their problem-solving ability scale to larger, more complex problems. You can understand at a fairly low level every single step that will be carried out to execute your program, yet be completely unable to write a large, modular and maintainable software system.
Are you adequate?
One of C's great advantages is not only that it is simple and very fast, it is also very close to the hardware -- when you make local variables, structures, assignments, etc... you have a good idea what the compiler needs to do. Likewise control structures, statements and so on.
That’s exactly the point... it’s too close to the hardware. Yes, it gives you really fine-grained control over what happens, and you can tweak it to make it as fast as possible. With the speed of today’s computers, though, you shouldn’t (usually) need that amount of optimization. Plus, the compiler should be robust enough to optimize the program nearly as well as you could anyway.
You don’t want to tell the computer every nitty-gritty detail. The computer is fast enough and powerful enough to do what you want it to do without you needing to exercise that level of control over how it actually does it. You just want to call a function that does what you want without worrying about the underlying hardware or algorithm that does it.
As programs get more and more complex, more and more abstraction is needed between the programmer and the hardware. This is not surprising. Someday, instead of saying “that’s like coding an entire application in assembly”, we might be saying “that’s like coding an entire application in C++”.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
C's closeness to the hardware is probably why it has stayed relevant in the era of mobile computing and battery life. Some developers do need to tell the computer every nitty-gritty detail.
"Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."
This is because a C fragment turns into something very efficient
No it _can_ turn into something very efficient. But usually it is too much bother or the programmer is not competent enough and the program ends up being no more efficient than something coded in a different language.
Take a look at the programming language shootout. The C programs usually win the contest, but they do it by doing crazy things like looking up the cache size of the CPU and implementing their own version of malloc to fit a page size. The run of the mill C program is not like that.
For many or even most tasks stability and security is more important. Other languages provide those properties better than C.
Pike and Thompson are not computer scientists, they are practitioners. The difference between Thompson's contributions and Knuth's contributions, for example, illustrate this exact point.
--#