Go and Brand X: A language comparison(cowlark.com)
cowlark.com
Go and Brand X: A language comparison
http://www.cowlark.com/2009-11-15-go/
21 comments
effective vs. good
I see 'effective vs. good' as an opportunity to satisfice.
http://en.wikipedia.org/wiki/The_Paradox_of_Choice
Let's take the notion of satisficing and apply old 80-20 rule. About 80% of your life is not going to matter that much in 5 years. Your choice of toothpaste, the car you drive, which couch you buy -- these can be complex decisions, but they aren't going to have as big an influence on your life as the town you live in, the jobs you take, or your closest friends. It's a minority of decisions you make which will matter the most, so spend your maximum effort optimizing those. For the rest, let's just find something that will do the job.
I think the Go team decided that compilation time, efficient execution, conciseness, and concurrency were the areas that mattered the most for a systems programming language. Most of the programming world understands "Algol-derived" syntax, so why not stick with that? In fact, given that the majority understands that sort of syntax, this should also be considered an optimization -- one which is aimed at achieving as large a user base as possible.
(I wonder if one can consider Python to be an 80-20 satisficed language?)
I see 'effective vs. good' as an opportunity to satisfice.
http://en.wikipedia.org/wiki/The_Paradox_of_Choice
Let's take the notion of satisficing and apply old 80-20 rule. About 80% of your life is not going to matter that much in 5 years. Your choice of toothpaste, the car you drive, which couch you buy -- these can be complex decisions, but they aren't going to have as big an influence on your life as the town you live in, the jobs you take, or your closest friends. It's a minority of decisions you make which will matter the most, so spend your maximum effort optimizing those. For the rest, let's just find something that will do the job.
I think the Go team decided that compilation time, efficient execution, conciseness, and concurrency were the areas that mattered the most for a systems programming language. Most of the programming world understands "Algol-derived" syntax, so why not stick with that? In fact, given that the majority understands that sort of syntax, this should also be considered an optimization -- one which is aimed at achieving as large a user base as possible.
(I wonder if one can consider Python to be an 80-20 satisficed language?)
If you haven't got around to it yet, google 'worse is better'.
I've also responded to 'worse is better" numerous times on HN. I don't think people are aware that what they want is satisficing in most of their design so that they can spend more effort on the the most important 20%.
> It's an oddly syntax-focused comparison
Specially given the many syntax mistakes on the Go examples he uses for comparison.
He is comparing two languages he has clearly never used to do any substantive programming. The whole thing is ridiculous.
Specially given the many syntax mistakes on the Go examples he uses for comparison.
He is comparing two languages he has clearly never used to do any substantive programming. The whole thing is ridiculous.
Excellent article. It pleases me that an important language that turned out not to be very widely used is nevertheless remembered by some -- if not by the creators of Go, who were apparently doomed to reinvent Algol 68 badly.
I'm also reminded of C.A.R. Hoare's famous quip about Algol 60: "Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors." (Sourced at http://en.wikiquote.org/wiki/C._A._R._Hoare .)
I'm also reminded of C.A.R. Hoare's famous quip about Algol 60: "Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors." (Sourced at http://en.wikiquote.org/wiki/C._A._R._Hoare .)
Do you really think the creators of Go do not know Algol 68? They know it much better than does the article author, who admits he's "not an experienced programmer in either Algol-68 or Go".
[deleted]
The author admits that one feature present in Go and missing from Algol-68 is proper closures. I would consider this an extremely significant deficit in Algol-68, not just one item to bury in a laundry-list comparison.
I don't think the article is so good. I got the impression that the main article centers around the part:
Take a deep breath. This may shock you.
Brand X is Algol-68.
That sort of sounds cool, so why not write an article to show that Algol-68 is more consistent than Go? Then the author just tries to compare features not honestly, but with the intention of making Algol-68 look better than Go, so that he builds up to his cool Brand X is Algol-68. His criticism of Go is mosly unfair, for example, how can he say that Go syntax can look ambiguous? I don't think I've seen a more explicit and unambiguous language than Go.
Take a deep breath. This may shock you.
Brand X is Algol-68.
That sort of sounds cool, so why not write an article to show that Algol-68 is more consistent than Go? Then the author just tries to compare features not honestly, but with the intention of making Algol-68 look better than Go, so that he builds up to his cool Brand X is Algol-68. His criticism of Go is mosly unfair, for example, how can he say that Go syntax can look ambiguous? I don't think I've seen a more explicit and unambiguous language than Go.
In my own personal opinion, the fact that Google have brought to the forefront the need for a new systems language is way more important than the exact feature set they have chosen to include. Even things like garbage collection and array bounds checking make life better.
One thing I find interesting is that I've seen several people claim that Go is all but useless until they implement generics. Java has only had generics for the last 5 years, C# had them after that, and the languages Go is intended to compete with still don't have them (well C++ has templates and I guess C has void *)!
One thing I find interesting is that I've seen several people claim that Go is all but useless until they implement generics. Java has only had generics for the last 5 years, C# had them after that, and the languages Go is intended to compete with still don't have them (well C++ has templates and I guess C has void *)!
Personally, I couldn't believe that they put generics in Java, after the weirdness with C++ templates, and all the problems they buy you.
Java very definitely jumped the shark when they added generics.
Java very definitely jumped the shark when they added generics.
I hate to break it to the author, but programming language design in general hasn't evolved much since ALGOL. It's not just Go. Sure, we have object-oriented programming, but that's really not anything earth-shattering from a language design standpoint.
I find it hard to make any "system" language that will be better than C or maybe C++. Go or Algol are just going to be C with some features tacked on. If someone is going to overtake C it will need to be a whole new approach. I think that is what the author is trying to get at.
You are aware that Algol predates C, yes? This would make it hard for Algol to "just [be] C with some features tacked on", according to any reasonable interpretation of those words.
It does seem more like C is Algol with some features cut out.
Wow, the Algol-68 spec really is impenetrable.
Hard to invent anything new.
Finish the sentence.
Hard to invent anything new if you need to keep backward "knowledge" compatibility.
Industrial PL design has always been about doing what programmers already know, but gradually "better". Not challenging them and introducing them to new concepts. As far back as the first Fortran; language designers were told to defer to the programmer's expertise, so much so that the #1 requirement for Fortran was to be an algebriac syntax over assembly language. Fortran didn't dare to do anything different than assembly (that job was left to Lisp.) That's why you see dangerous low-level constructs left in every major HLL: this is to allow the previous generation of programmers the freedom to circumvent the abstraction to get work done. It's a subtle admission of distrust of high-level concepts, because management, and studies in "pragmatics" tell us that programmers need to fall back on sheer muscle and primitive operators to deliver quality software.
PL designers and compiler hackers can wax poetic over their achievements in advancing the art, but the market prefers to keep its investment in time, money and expertise in current technologies. So what you often see is a lousy compromise between the Ideal and the Material. Inline assembly, longjmp, pointer arithmetic, unboxed immediate values, compiler directives and promises to allow the programmer to tell the compiler how to do it's job, etc.
The people behind Go are industrial PL designers; everything they have ever done was for immediate, pragmatic reasons. They cloned Multics to make it cheaper and simpler, doing away with much advanced time-sharing OS research and taking the bare minimum; what they produced was a multitasking OS for minicomputers that wasn't that much more sophisticated than the microcomputer OSes of that day: it was CP/M with a login screen. You can see that theme of "simple, familiar, fast" running through every piece of software tool Bell Labs has ever touched after that. They might appropriated a few technologies from academia, Tcl, SML/NJ, etc. but those were done by researchers brought on board from the outside. When Bell Labs got too ambitious they produced C++, not a change in tone, but a crescendo of everything they have been doing. Worse is Better.
Hard to invent anything new if you need to keep backward "knowledge" compatibility.
Industrial PL design has always been about doing what programmers already know, but gradually "better". Not challenging them and introducing them to new concepts. As far back as the first Fortran; language designers were told to defer to the programmer's expertise, so much so that the #1 requirement for Fortran was to be an algebriac syntax over assembly language. Fortran didn't dare to do anything different than assembly (that job was left to Lisp.) That's why you see dangerous low-level constructs left in every major HLL: this is to allow the previous generation of programmers the freedom to circumvent the abstraction to get work done. It's a subtle admission of distrust of high-level concepts, because management, and studies in "pragmatics" tell us that programmers need to fall back on sheer muscle and primitive operators to deliver quality software.
PL designers and compiler hackers can wax poetic over their achievements in advancing the art, but the market prefers to keep its investment in time, money and expertise in current technologies. So what you often see is a lousy compromise between the Ideal and the Material. Inline assembly, longjmp, pointer arithmetic, unboxed immediate values, compiler directives and promises to allow the programmer to tell the compiler how to do it's job, etc.
The people behind Go are industrial PL designers; everything they have ever done was for immediate, pragmatic reasons. They cloned Multics to make it cheaper and simpler, doing away with much advanced time-sharing OS research and taking the bare minimum; what they produced was a multitasking OS for minicomputers that wasn't that much more sophisticated than the microcomputer OSes of that day: it was CP/M with a login screen. You can see that theme of "simple, familiar, fast" running through every piece of software tool Bell Labs has ever touched after that. They might appropriated a few technologies from academia, Tcl, SML/NJ, etc. but those were done by researchers brought on board from the outside. When Bell Labs got too ambitious they produced C++, not a change in tone, but a crescendo of everything they have been doing. Worse is Better.
The problem was not that they invented this stuff, but that people took it seriously. Let's break the cycle with Go.
The other points raised:
'effective' vs 'good' - seems like a narrower case of the plentiful and in-depth literature available about 'worse is better' (and the converse).
'can't spot any language feature that was invented after about 1985' - at this point the Lisp crowd should probably be reaching for their pitchforks and lighting their torches. Perhaps formalized systems for hygienic macros came a bit later?