Go: C is too low-level, C++ is too complicated, and neither is adequate for concurrency.
(That's an attempt at summarizing Rob Pike and fitting it into Graham's framework, not necessarily what I believe, although I believe something close).
It would be nice if there was a date attached to this. It appears to be 10 years old judging by the list of languages and the sentiments attached (although time probably wouldn't alter the sentiments greatly).
This list hints at something interesting:
The intent behind the creation of a programming language does not always match up with the result, or the culture around it.
For example, you might say;
Lua: SOL (our data language) doesn't have enough programming constructs.
which is historically accurate, but in a modern context you might also say:
Lua: Game engines and other apps need a really easy to integrate, reusable embeddable scripting language library.
which is a vastly different problem that lua didn't necessarily set out to solve.
Isn't "+." an ocaml thing rather than ML in general?
I think SML had overloaded numeric operators, though I think that's a special case (i.e. type classes are still better)
Yep, you're right :). I opened the Standard ML book, and there on p75 they list * :: num * num -> num. Then at the bottom they say each function declared as such really has two definitions, one with num replaced by int and one with num replaced by real.
So yes, +. is just an ocaml thing. Not sure about caml.
Haskell is a far cry from just lazy ML. Oddly enough, your summary of go would be far more appropriate for haskell, which makes go's concurrency handling look primitive.
If we're going for why Python appealed to its early adopters as opposed to the actual motivations for creating it in the first place, something more like 'other languages are all hard to read' would be fair. You could even reintroduce the Perl rivalry in the form 'Perl is too hard to read', if you insist. But it really wasn't Perl's kludgeyness per-se.
I'm never liked this list, mostly due to Python but I think other languages are also incorrectly characterized. Guido worked on ABC and wanted something for scripting tasks on a Unix machine. Python was mostly inspired by ABC but some of the syntax was inspired by Modula 3.
Python is certainly not a reaction to Perl, I'm not sure Guido was aware of it when Python was born (they are close to the same age, actually).
> I think other languages are also incorrectly characterized
Agreed. This stems from a neat idea, but I think it's an after the fact rationalization (except for a few that are provably correct, like J). For example, C++ didn't stem from a direct frustration with C:
"Stroustrup found that Simula had features that were very helpful for large software development, but the language was too slow for practical use, while BCPL was fast but too low-level to be suitable for large software development."[0]
This list is cute, and provides good "taglines" for the languages, but I think it'd be met with a larger grain of salt if it hadn't been written by PG. :)
I would put it as "Rust: C++ is unsafe, and all other attempts to make C++ safe have made it too high level." (Alternately, "concurrent programming with data races is a kludge, and all other attempts to fix data races have ruled out too much.")
APL: Errors increase in proportion to the amount of code typed; therefore, decrease amount of code typed while keeping expressiveness and power unchanged.
For Ruby, I would suggest "Smalltalk doesn't like Unix" instead. What attracted me to Ruby is that it was a Smalltalk-style pervasive OO language that could be used for scripting and didn't require persistent images.
I don't think the historical evidence supports this. PHP was invented as a templating DSL for C programmers. I'd propose:
PHP (version 0): C is not an HTML templating language; Perl and Python are too heavyweight as embedded templating languages, given that all of our logic is in C anyway.
PHP (version N): PHP works fine, except it's missing function F.
...and so on, ad infinitum.
PHP doesn't really fit the paradigm of the original essay. It's hard to even pretend that PHP was deliberately designed as a reaction to other existing languages. Rather, PHP evolved. Hence, explanations of PHP tend to be circular: "PHP exists because PHP's design, documentation, and community were tightly focused on web publishing", or "PHP exists because it's backwards-compatible with PHP".
Guy Steele didn't actually design Java. He was hired after the language was designed to write the spec. Of course, writing a specification exposed problems with the design, and those problems had to be fixed, so he had some influence on those parts of the language.
Dragging out that quote doesn't really answer the question. What about Java makes it like Lisp? The ability to (painfully) implement closures with objects and vice-versa? That's also shared with every other OO language, includes ones that would not normally be considered Lisp-influenced.
What other OO languages? Ruby is Lisp-influenced for sure. :)
Anyway, the context is explicitly Java vs C++, not Smalltalk or Ruby or Python. I imagine if Smalltalk were the dominant platform this would've turned out differently. So let's do a compare and contrast.
Java has the following properties: methods are all virtual; single inheritance; inheritance isn't public/private; final instead of const; GC and references w/o memory alloc or pointers; a package system exists; generics instead of templates; no operator overloading. And Java 6 does have a limited form of closures, believe it or not-- you can access a variable declared as final with an anonymous inner class.
None of that is true of C++, and just about all of those substantially increase the complexity of the language. I don't even like Java, mind you, but after reading Effective C++ the influence of higher-level languages like Lisp was pretty obvious to me, even if Lisp might not have been the only or even primary influence on Java.
Maybe I'm overstating, and maybe there are other languages in between I don't know about. If you look at what's in memory at a given moment, how objects are connected to one another, and how they're connected to code, I don't think Java looks that different to Scheme; apart from continuations, macros, and TCO, you can write Scheme in Java if you're bloody-minded enough and don't mind your lambdas disappearing into masses of curly braces.
Actually, looking at http://en.wikipedia.org/wiki/History_of_programming_language... it turns out a lot of languages with the properties I'm describing came before Java, so while Java clearly descends from Lisp in a lot of ways, the connection isn't as direct as I was imagining.
Java is a cleaned up version of C++. The JVM is an implementation detail, albeit an important one. The language itself though is about removing the necessity to manually manage memory, but staying within the OOP paradigm (or the OOP paradigm C++ proposed).
90 comments
[ 3.0 ms ] story [ 146 ms ] threadSQL: Tuple relational calculus is too low level?
Julia: Hadoop is a kludge for data science?
Clojure: We need Lisp for the JVM?
Dart: JavaScript is a kludge?
Go: C/C++ are kludges for systems programming?
(N.B., I think Scala is a great language. But it is certainly one that has never seen a feature that it didn't like...)
SQL: "humans should just say what they want, not how to get it"
Octave is almost certainly "MATLAB is expensive, and non-unixy"
Julia is "octave is slow and poorly designed"
(That's an attempt at summarizing Rob Pike and fitting it into Graham's framework, not necessarily what I believe, although I believe something close).
Clojure: lisp promotes mutability too much.
- jvm needs a good lisp
- lisp needs libraries and a little cleaner keywords
https://web.archive.org/web/20020210063149/http://paulgraham...
For example, you might say;
Lua: SOL (our data language) doesn't have enough programming constructs.
which is historically accurate, but in a modern context you might also say:
Lua: Game engines and other apps need a really easy to integrate, reusable embeddable scripting language library.
which is a vastly different problem that lua didn't necessarily set out to solve.
This article came up about a year ago[1], so I'm just reusing my comment :P. Now I'd also add:
Go: C is the prefect language, except it's too low-level.
Ermine[2]: Scala is not functional (enough).
[1]: https://news.ycombinator.com/item?id=4954663
[2]: https://github.com/ermine-language/ermine
I feel go is more like "It would be nice to have a Python-like C that would also be a C-like Python"
Go: callback hell is hard to manage, but threads are too expensive.
So yes, +. is just an ocaml thing. Not sure about caml.
If we're going for why Python appealed to its early adopters as opposed to the actual motivations for creating it in the first place, something more like 'other languages are all hard to read' would be fair. You could even reintroduce the Perl rivalry in the form 'Perl is too hard to read', if you insist. But it really wasn't Perl's kludgeyness per-se.
Python is certainly not a reaction to Perl, I'm not sure Guido was aware of it when Python was born (they are close to the same age, actually).
Agreed. This stems from a neat idea, but I think it's an after the fact rationalization (except for a few that are provably correct, like J). For example, C++ didn't stem from a direct frustration with C:
"Stroustrup found that Simula had features that were very helpful for large software development, but the language was too slow for practical use, while BCPL was fast but too low-level to be suitable for large software development."[0]
This list is cute, and provides good "taglines" for the languages, but I think it'd be met with a larger grain of salt if it hadn't been written by PG. :)
[0] http://en.wikipedia.org/?title=C%2B%2B#History
In fact it would make more sense reversed.
PHP: Perl is a kludge.
Because that's what PHP mostly replaced - Perl.
Alternatively:
APL: Programming should be more like math.
APL: Other languages are verbose and irregular.
https://news.ycombinator.com/item?id=4954663
PHP (version 0): C is not an HTML templating language; Perl and Python are too heavyweight as embedded templating languages, given that all of our logic is in C anyway.
PHP (version N): PHP works fine, except it's missing function F.
...and so on, ad infinitum.
PHP doesn't really fit the paradigm of the original essay. It's hard to even pretend that PHP was deliberately designed as a reaction to other existing languages. Rather, PHP evolved. Hence, explanations of PHP tend to be circular: "PHP exists because PHP's design, documentation, and community were tightly focused on web publishing", or "PHP exists because it's backwards-compatible with PHP".
Python: Is cute to prefix everything with "py"
Javscript: Haha not as cool as suffix it with "js"
Ruby: Pff i have the coolest nickname and it is "Rails"
Clojure: Oh please, you aren't as classy as "La Clojure"
C: The power of soul and possibility control!
Go:tta Catch 'Em All!
Erlang: ErrrrrrrLang!!!
LiveScript: I'd rather be writing Perl-flavored Ruby, with a Haskell syntax. ( http://livescript.org/ )
Java as essentially Lisp's bastard child is I think undermentioned in language history.
In fact, his classic talk "Growing a Language" is among other things a very polite and implicit, but devastating critique of the design of Java.
"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."
- Guy Steele, Java spec co-author
Reasonably original-ish source: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m....
Relative to C++, Java is actually a lot like Lisp. Don't forget that objects are a poor man's closures (and vice versa).
Dragging out that quote doesn't really answer the question. What about Java makes it like Lisp? The ability to (painfully) implement closures with objects and vice-versa? That's also shared with every other OO language, includes ones that would not normally be considered Lisp-influenced.
Anyway, the context is explicitly Java vs C++, not Smalltalk or Ruby or Python. I imagine if Smalltalk were the dominant platform this would've turned out differently. So let's do a compare and contrast.
Java has the following properties: methods are all virtual; single inheritance; inheritance isn't public/private; final instead of const; GC and references w/o memory alloc or pointers; a package system exists; generics instead of templates; no operator overloading. And Java 6 does have a limited form of closures, believe it or not-- you can access a variable declared as final with an anonymous inner class.
None of that is true of C++, and just about all of those substantially increase the complexity of the language. I don't even like Java, mind you, but after reading Effective C++ the influence of higher-level languages like Lisp was pretty obvious to me, even if Lisp might not have been the only or even primary influence on Java.
Actually, looking at http://en.wikipedia.org/wiki/History_of_programming_language... it turns out a lot of languages with the properties I'm describing came before Java, so while Java clearly descends from Lisp in a lot of ways, the connection isn't as direct as I was imagining.
1) Garbage collection
2) Dynamic typing
3) No distinction between primitive values and general values - a value can be used everywhere
4) Lexical closures and higher-order functions
5) A hygienic macro system
6) First-class continuations
7) Space safety guarantees for tail calls ('tail call optimization')
8) A numeric tower
9) S-expression syntax
10) A focus on cons cells and lists as primitive data structures
There's probably something I'm missing, but the only feature that Java shares is the first.
Java: not only those MIT/Stanford smart-asses can code.
Java EE: the way to avoid a drop-out from the field.
Javascript: just learnt .getElementById() now I can write an OS.
Go: Java is too bloated.
Forth: all the other languages were written by somebody else.
As they say: if you've seen one version of Forth, you've seen... one version of Forth. And also: standards are a good thing, everyone should have one!
PHP: getting Perl and CGI to work on my web server is too damn hard.
Or perhaps:
PHP: I can never remember the difference between %, @ and $.