Rob Pike frustrated by Java, C++ complexity(pcworld.idg.com.au)
pcworld.idg.com.au
Rob Pike frustrated by Java, C++ complexity
http://www.pcworld.idg.com.au/article/354210/google_executive_frustrated_by_java_c_complexity/
Interestingly these two languages are Google's official languages.
13 comments
I am bothered that Rob Pike's name can't carry its own weight, and instead he is referred to just as a "Google Executive".
People wouldn't be super surprised to find out one of the members of the UNIX team, a designer of Plan 9 and the author of editors like sam and acme dislikes aspects of Java and C++. Oh well, I guess "google executive" gets hits.
People wouldn't be super surprised to find out one of the members of the UNIX team, a designer of Plan 9 and the author of editors like sam and acme dislikes aspects of Java and C++. Oh well, I guess "google executive" gets hits.
I see this as somewhat more targeted at Enterprise Software type readers, or even non-tech people, where it makes a little more sense to pitch it that way. Something like: executive at big-but-iconoclastic company Google says the way other big companies write their software sucks.
Why would non-tech people be interested in Java, C++ complexity?
Probably not the languages specifically, but possibly interested in the general narrative of, "the two programming languages all the big companies use are too complex, and Google is doing things differently". But I could be wrong; PC World probably does have more software-engineering readers than non-programmer readers.
I would point out that it's not so much "other big companies" as it is what we've learned from our own sucking.
Google primarily write code in C++ and Java (with Python)
yes it's the Paul/Ringo effect. You know, that guy that was in Wings, and that other guy with the beard who wrote a children's book?
also note that "executive" becomes "distinguished Engineer" right in the first sentence!
Video of his talk: http://www.youtube.com/watch?v=5kj5ApnhPAE&feature=playe...!
imho, arguing that java and c++ both have the same deficiencies is not totally accurate. java seems to be no where as complex as c++ even with generics. however, java to me seems more complex because it is verbose. and it is verbose because it is too simple. when the language is made simple, the complexity gets pushed into the user code a.k.a the "waterbed theory of complexity".
not sure if Go programs would still read like "quiet conversations between a well-spoken research worker and a well-studied mechanical colleague" in a decade or so of some real world usage. a fine line to walk between increased sophistication & noise...
not sure if Go programs would still read like "quiet conversations between a well-spoken research worker and a well-studied mechanical colleague" in a decade or so of some real world usage. a fine line to walk between increased sophistication & noise...
Go might have a chance, I think, particularly because of its interface system. Defining interfaces based on an object's methods gives the programmer compile-time assurance that objects can do what they'll need to without requiring an unstable, ever-growing tower of types. It may be simple like Java, but its central abstraction is less rigid.
More info: http://golang.org/doc/effective_go.html#interfaces_and_types
Add to this Go's garbage collection and clean built-in concurrency model, and you've eliminated much of what bugs me in day-to-day C++. Go could still blow it with a poor treatment of generics, but I think it stands a good chance of doing Java and C++'s jobs in a much more concise, 'quiet' style.
More info: http://golang.org/doc/effective_go.html#interfaces_and_types
Add to this Go's garbage collection and clean built-in concurrency model, and you've eliminated much of what bugs me in day-to-day C++. Go could still blow it with a poor treatment of generics, but I think it stands a good chance of doing Java and C++'s jobs in a much more concise, 'quiet' style.
This is a horrible quality article that should be below the standards of news.yc.
I agree with you.
This article mentions Java and C++ as languages that have become too complex, but without actually stating what this complexity is. Maybe it's just the summary-like nature of the article, but it talks as if we're all meant to just agree with it.
I do agree on the merits of Go (especially relating multi-core processors), but there's surely a better way of expressing these merits than bagging out Java & C++. Just seems a little tacky to me.
(Sorry for the tone of my comment.)
This article mentions Java and C++ as languages that have become too complex, but without actually stating what this complexity is. Maybe it's just the summary-like nature of the article, but it talks as if we're all meant to just agree with it.
I do agree on the merits of Go (especially relating multi-core processors), but there's surely a better way of expressing these merits than bagging out Java & C++. Just seems a little tacky to me.
(Sorry for the tone of my comment.)
Guys... It's IDG. It's not for hackers, but for PHBs.
"Google executive"... Come on...
"Google executive"... Come on...
"Rob Pike digs his own language".
The languages tend to be interpreted rather than compiled, meaning the programs written in such languages aren't compiled before running....
Thanks for that brilliant bit of journalism there.
Thanks for that brilliant bit of journalism there.
also (paraphrased):
a. Javascript is less than 10 years old
b. It was developed in response to the growing complexity of Java/C++
a. Javascript is less than 10 years old
b. It was developed in response to the growing complexity of Java/C++
One of the points Larry Augustin makes is that languages become more complex as they adapt to a wider range of use cases. The fact that people end up using languages outside of their intended contexts strikes me as a case of not using the right tool for the right job. This is why learning a wide variety of languages is important -- it gives people perspective and opens up new and better ways of solving the problem at hand.
I think programmers, in general, aren't comfortable creating their own DSLs or language-level abstractions to problems, and this often leads less than ideal workarounds.
I think programmers, in general, aren't comfortable creating their own DSLs or language-level abstractions to problems, and this often leads less than ideal workarounds.
Gmail is written entirely in Javascript? Even on the server side?
The article is frustratingly inaccurate on many, many counts.
Well, that sure seems to be what Adam de Boor said at USENIX. Googling for reports on his talk and the Q&A session, it sounds like someone asked him if Java would have been better, and he said that Javascript's perceived shortcomings are largely due to the implementations people see in browsers, implying that he was indeed talking about server-side Javascript.
Aren't there Javascript implementations for serverside that run on the JVM?
Aren't there Javascript implementations for serverside that run on the JVM?
Rhino can be used to run JS server-side atop the JVM, although maybe by this point they've switched to V8.
I still find it hard to believe they built the whole thing in JS. If it really is so, well... that's actually really, really cool.
I still find it hard to believe they built the whole thing in JS. If it really is so, well... that's actually really, really cool.
[deleted]
I sure have my doubts. I have a friend at Google who works closely with that team; I'll ask him about it. He spends most of his day writing Java (not Javascript).
"At the USENIX annual conference last month, Gmail engineer Adam de Boor surprised the audience by noting that the company's Gmail service was written entirely in JavaScript, and that all of its code, around 443,000 lines worth, was written by hand."
Ignoring the inaccuracy regarding Javascript, what is so surprising about writing code "by hand"? Am I missing something?
Ignoring the inaccuracy regarding Javascript, what is so surprising about writing code "by hand"? Am I missing something?
A lot of the JavaScript at Google is written in Java and then compiled down to JS with GWT[1].
1. http://en.wikipedia.org/wiki/Google_Web_Toolkit
1. http://en.wikipedia.org/wiki/Google_Web_Toolkit
Google has an open source product that compiles Java to JS.
I'm familiar with GWT, but I'm not sure that really answers my question.
Personally, I think the surprising part is such a large codebase (including server side code?) being written completely in Javascript.
Google or not, Gmail or not, writing a 440KLOC Javascript server-side program seems like a really bad idea to me.
Every time I read one these "Java, C++..." articles, I wonder, is the world getting dumber or the problems we need to solve simpler?
Or maybe the world is getting smarter and seeing actual problems (or non-solutions) for what they are?
The world is building ever more complex things, and as such needs better abstractions provided by the programming language.
So new languages with different abstractions come along and things are simpler to do in it. That simplicity is then used to build even more complex things, which then expose how the abstractions doesn't work in the formerly new language.
Repeat ad nausum.
So new languages with different abstractions come along and things are simpler to do in it. That simplicity is then used to build even more complex things, which then expose how the abstractions doesn't work in the formerly new language.
Repeat ad nausum.
"So new languages with different abstractions come along and things are
simpler to do in it. That simplicity is then used to build even more complex
things, which then expose how the abstractions doesn't work in the formerly
new language."
This is true for mathematics, but not in the same way for computer languages, because we haven't unlimited computing power and memory space.
Yes, with a more abstract language you can solve a problem easier on the implementation, source code side.
But with every abstraction you're loosing flexibility, because to get an abstraction you're putting the lower parts in a concrete combination. Thus every abstraction has it's costs.
Yes, you could use two computing languages, one for the performace/memory critical part, and one for the other parts of the programm. But in practise it's not that easy to combine the two.
There's a reason why people are still using C/C++.
This is true for mathematics, but not in the same way for computer languages, because we haven't unlimited computing power and memory space.
Yes, with a more abstract language you can solve a problem easier on the implementation, source code side.
But with every abstraction you're loosing flexibility, because to get an abstraction you're putting the lower parts in a concrete combination. Thus every abstraction has it's costs.
Yes, you could use two computing languages, one for the performace/memory critical part, and one for the other parts of the programm. But in practise it's not that easy to combine the two.
There's a reason why people are still using C/C++.
> But with every abstraction you're loosing flexibility, because to get an abstraction you're putting the lower parts in a concrete combination.
I don't think this is true. You might lose some, you might get some, in a different place, with greatly lowered brainload.
Or are you going to argue that lisps are less flexible than C?
I don't think this is true. You might lose some, you might get some, in a different place, with greatly lowered brainload.
Or are you going to argue that lisps are less flexible than C?
C is more flexible on the performance and memory usage side.
That's my point. Abstractions are great, I love Lisp and Haskell. The problem of more complexity isn't completely solved by using better abstractions, because you still need to look at the performance and memory usage, as long we have a limit there.
That's my point. Abstractions are great, I love Lisp and Haskell. The problem of more complexity isn't completely solved by using better abstractions, because you still need to look at the performance and memory usage, as long we have a limit there.
Note that I didn't state that there would be MORE abstraction, only that it would be DIFFERENT abstractions.
You can have different abstractions compared to what C has and still retain the granularity of control you want.
You can have different abstractions compared to what C has and still retain the granularity of control you want.
"Note that I didn't state that there would be MORE abstraction, only that it
would be DIFFERENT abstractions."
That doesn't makes sense. What should be a different abstraction of C? If you've an other syntax for the C pointer arithmetic it's still the same abstraction.
If you can do still the same things, then it's still the same abstraction. You can only combine multiple abstractions in one language, but I think that's not a good idea.
"You can have different abstractions compared to what C has and still retain the granularity of control you want."
I don't think so, because you would add the complexity of both, the higher abstraction parts and the C parts. You would generate a language which is harder to master than their component parts.
That doesn't makes sense. What should be a different abstraction of C? If you've an other syntax for the C pointer arithmetic it's still the same abstraction.
If you can do still the same things, then it's still the same abstraction. You can only combine multiple abstractions in one language, but I think that's not a good idea.
"You can have different abstractions compared to what C has and still retain the granularity of control you want."
I don't think so, because you would add the complexity of both, the higher abstraction parts and the C parts. You would generate a language which is harder to master than their component parts.
Just drumming up support for GO by dissing other languages.
To be fair, Rob's (like most of the Unix room) always disliked Java and C++. Bjarne was their colleague for a time.
In this discussion on Java in 2004 http://groups.google.com/group/comp.os.plan9/browse_thread/t...
object-oriented design is the roman numerals of computing.
-rob
Or this one from the same year on manual pages !
http://groups.google.com/group/comp.os.plan9/browse_thread/t...;
when ken and i described the new features we were proposing for plan 9 C, including inherited structure elements, to bjarne stroustrup, he said, "if you want C++ you know where to find it." and stormed from the room.
i don't think he understood exactly why we were proposing these features.
In this discussion on Java in 2004 http://groups.google.com/group/comp.os.plan9/browse_thread/t...
object-oriented design is the roman numerals of computing.
-rob
Or this one from the same year on manual pages !
http://groups.google.com/group/comp.os.plan9/browse_thread/t...;
when ken and i described the new features we were proposing for plan 9 C, including inherited structure elements, to bjarne stroustrup, he said, "if you want C++ you know where to find it." and stormed from the room.
i don't think he understood exactly why we were proposing these features.
You know you're getting old when Java people complain about speed of scripting languages.
I am expecting F# people in the next year to say that Go is a very complex language and that it doesn't address the problems we are facing in enterprises.
That is every big house has a horse in the language race.
That is every big house has a horse in the language race.