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.
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.
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.
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...
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.
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 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.
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.
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?
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).
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.
"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++.
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.
"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.
"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?
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.
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.
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.