There's some truth to that: JavaScript's execution model was Scheme, with the syntax swapped out relatively last-minute in response to corporate pressure. What I genuinely don't remember anymore is whether LiveScript shipped with the Scheme syntax at any point. If it didn't, then yes, I'd say it's fair to say they shared an influence.

We can keep on adding...

JavaScript, "We want a scripting language in our web pages."

TCL, "It should be easy to extend your scripting language in C."

SQL, "We need a standard way to talk to our databases."

PL/SQL, "We want to push complex logic into our databases."

BASIC, "We need an easy language for absolute beginners."

And so on.

But one historical comment. The ACTUAL problem that Ruby was created to fix was that Matz needed a scripting language that could handle Japanese text. People may adopt it now for different reasons, but that is not the historical inspiration.

    The ACTUAL problem that Ruby was created to fix was
    that Matz needed a scripting language that could handle
    Japanese text.

That's why it's on my enhanced chart.

Perl can handle Japanese just fine nowadays. Back in 1995, though, Unicode support was... iffy at best.

Now, Ruby must be differentiated by other things.

The issue was much worse than Unicode support.

Ruby natively supports multipleincompatible Japanese encodings, including Unicode and shift-JIS. This is a lot harder than just marking off a Unicode checkbox.

Perl was made for processing text too, and for some reason he thought Perl was not good enough for the task.

The "some reason" that I gave is that handling Japanese byte encoded text in Perl was very hard in 1995.

Haskell: other languages make making mistakes too easy.

Haskell: My proofs are correct but my code is wrong. I just want to execute my induction proofs.

That's probably more Coq.

More like Agda or Coq?

Haskell: programming is math but other languages make that unnecessarily hard to see

Agda: programming is math but other languages (even haskell) make that unnecessarily hard to see

FTFY

Haha, yeah. Or

Agda: when Turing completeness gets in the way of your mathematical logic.

Haskell: what every Scala baby wants to be when he grows up

Ruby: Perl has crap OO, and Lisp syntax is scary.

Perl did a lot of things right, e.g. regex literals, wide range of terseness possible (one-liners vs. large modular programs), CPAN, but I could never get over its ugly, hacked-in implementation of objects that kinda-sorta behaved like hashes and didn't do information hiding well.

Yes, but Perl has better libraries for that now (e.g. Moose)

You can't have good OO "outside" your language. You can't duct tape some OO to a language and consider it done.

That's classic: PHP guy say, "we have objects in PHP5 so now it is Object Oriented". It's not. To say that language is Object Oriented because it has classes is like to say that language is Functional because it has functions.

So, Moose is a clever thing, but does it make every hash an object (I genuinely wonder)? Does it provide OO API for I/O? With exceptions? Does it make everything behave consistently? Because consistency seems to be the main reason that Perl did not become the final stop.

Because consistency seems to be the main reason that Perl did not become the final stop.

Everyone's using Smalltalk now? Consistency seems to be overrated; most of the popular languages these days seem to be multi-paradigmatic.

CLOS did a stellar job of adding OO to a non-OO language.

There are all kinds of opinions about this: http://steve-yegge.blogspot.ru/2006/04/lisp-is-not-acceptabl... Yes, it's wonderful that you have the band-aid — or maybe duct tape is a better analogy — certainly you miss them dearly when you're working in other languages. But you don't want to have to build your entire object system with duct tape.

I don't quite think the Smalltalk one is fair. Smalltalk-80 definitely went to the extreme with everything-is-an-object, but PG is glossing over the history of Smalltalk-76 and Smalltalk-72, which betray the actual purpose: "Programming accessible by the everyman should be just as powerful as a 'real' language, not like BASIC."

VB: Programmers are too expensive. Business Process people are more necessary.

MUMPS: All other languages weren't written for/by medical doctors/professionals.

Lua: Python and Ruby are each too big to embed.

Lua is as old as Python and Ruby. The alternative was Tcl, and the problem with it wasn't embeddability:

In 1993, the only real contender was Tcl, which had been explicitly designed to be embedded into applications. However, Tcl had unfamiliar syntax, did not offer good support for data description, and ran only on Unix platforms.

http://www.lua.org/doc/hopl.pdf

Crap, you caught me on that one. I thought it was a 2000's era language.

C# 1 --- Java is controlled by Sun

C# [n] (where n > 1) --- C# [n - 1] would be more awesome if it had...

PHP: I wanna create a goddamn webpage, like right fucking now.

Javascript: the "java" name is very cool. PHP: let's pretend it doesn't exist by not adding it to our cool list.

PHP: Your language is trying too hard.

Common Lisp: There are N dialects of Lisp, and N is too many. Now there are N+1 dialects of Lisp.

Erlang: Concurrency should be easier

Brainfuck: Assembly provides too much, and obfuscated C is still readable

Malbolge: Other languages can be used to write programs by a human being.

http://en.wikipedia.org/wiki/Malbolge

I'd say, Ruby: Smalltalk is scary and Perl is a kludge

Anyone who thinks Smalltalk is scary has never used it, and I doubt that is what Matz thought of it.

Well, I don't think that's what anyone has ever said about any of these languages. :D

I was just trying to stick with the form of the essay.

Not sure when this came out, because none of these essays are dated - this one is near the bottom of the list. But I like it!

web.archive.org has its first snapshot of it from Feb 2002, so it's at least 10 years old.

http://web.archive.org/web/20020210063149/http://paulgraham....

Thanks to whoever updated the title.

Go: concurrent programming is too hard

Or rather: C++ & friends suck, Python & friends are too slow. Quoting from the Go FAQ:

>Go was born out of frustration with existing languages and environments for systems programming. Programming had become too difficult and the choice of languages was partly to blame. One had to choose either efficient compilation, efficient execution, or ease of programming [...]

>Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language. It also aims to be modern, with support for networked and multicore computing.

Go: software engineering at Google is too inefficient.

Groovy: Java is not Python enough

Groovy: We don't control Rails.

Missing my couple of my favorite languages: PHP, Objective C, Scala and JavaScript

JavaScript: UI code should be asynchronous and throw as few errors as possible.

JavaScript: Web pages aren't interactive enough.

Assembly: binary is too low-level.

Binary: Ternary is one thing too many.

[:|||||||||||||:]

Reply on news.ycombinator.com