
What languages fix - cadalac
http://paulgraham.com/fix.html
======
TheZenPsycho
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.

------
cturner
I'm delighted by the way that TCL-like languages and Perl-like languages grew
towards one another.

The experience that motivates TCL: you'll be working on your compiled codebase
and think, "damn - it should be easier to glue blocks of this together."

For perl - you'll be working in shell, and then move to awk, and find yourself
using the function structures and ignoring the pattern matching. And you'll
think, "damn, I wish this had more powerful programming structures in it".

In the middle you get ruby and lua, which are very similar, but came from
opposites.

In an earlier draft of this post I wrote python and lua above, but then I
checked some history. Interesting - it's kind of an accident that python
evolution to challenge the shell/awk/perl scripting space. ABC was created
from academic motivations. Python 1 didn't quite know what it wanted to be. If
you joined python at 1.4 and stayed through the release of 2.0, it's easy to
imagine that it would have evolved with a more functional emphasis than it
did. By 2.2 (new classes) it had solidified as a objecty response to perl5.

------
tikhonj
Haskell: other languages make making mistakes too easy.

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](https://news.ycombinator.com/item?id=4954663)

[2]: [https://github.com/ermine-language/ermine](https://github.com/ermine-
language/ermine)

~~~
sesm
Haskell: ML is eager.

Go: callback hell is hard to manage, but threads are too expensive.

~~~
arh68
If we're 'fixing' ML, type classes are a huge fix for the kludgy-yet-precise 2
+ 3 => 5, 2.0 +. 3.0 => 5.0 .

~~~
riffraff
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)

~~~
arh68
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.

------
cturner
Only slightly relevant, but an insight I had recently.

I'd noticed that all programming languages were tree-oriented. You kind of
group logic into branches. This sounds obvious, but work with me here.

This reminded me of the early days of yahoo: it was a big directory (a tree
structure). Then we had this revolution where everything became about loose
data that was tagged. You'd have tagged data, and then search on the tags.
This tag structure was better for scale than the tree structures we'd brought
with us from personal computing problems.

I thought, "I wonder if you could build a tag-based programming language". And
then I realised - that's what prolog is.

~~~
lambdasquirrel
Typeclasses were probably a killer feature for Haskell. I remember using
functors in OCaml and they were pretty sweet, but typeclasses let you "label"
types with functions and values _after_ the fact. Sure, ghc would complain
about orphan instances (if you "labelled" the type outside of the file where
it was declared), but it was so darn useful.

------
webmaven
I would dispute the description of Python, at least as an 'origin story'. The
actual impetus was 'ABC doesn't have libraries or exceptions':
[http://docs.python.org/2/faq/general#why-was-python-
created-...](http://docs.python.org/2/faq/general#why-was-python-created-in-
the-first-place)

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.

~~~
nas
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).

~~~
GuiA
> 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. :)

[0]
[http://en.wikipedia.org/?title=C%2B%2B#History](http://en.wikipedia.org/?title=C%2B%2B#History)

------
schmichael
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).

~~~
rbanffy
More or less right:

[https://web.archive.org/web/20020210063149/http://paulgraham...](https://web.archive.org/web/20020210063149/http://paulgraham.com/fix.html)

------
djur
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.

------
ptwobrussell
Would be helpful to see this list be updated with a few others. A couple of
that come to mind:

SQL: 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?

~~~
tptacek
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).

~~~
frou_dh
A sane module system was a big part of it, according to the SPLASH talk.

------
vijucat
Had to add this because I thought it was fairly obvious, but all the other
Scala mentions were either snarky or seemed to miss the core point of the
title of the post : "What languages fix"

Scala : functional programming without leaving the JVM

Because enterprises have spent a decade or so building up JVM expertise in the
form of Java.

~~~
seanmcdirmid
Scala is much more than a functional language, its more like Java done much
better, not all of its useful features are functional. Maybe you meant
clojure?

~~~
vijucat
You're right! It's not AS simple as I made it out to be.

------
ColinWright
Way back when, I knocked up a graph of this:

[http://www.solipsys.co.uk/new/EveryLanguageFixesSomething.ht...](http://www.solipsys.co.uk/new/EveryLanguageFixesSomething.html)

There is also an enhanced version that brought it a little further up to date.
Problem is, people keep insisting that it must be wrong, because X doesn't
descend from Y, _etc._ That's why the text at the top tries to emphasise that
this is a graph of "developed because of a perceived short-coming."

 _Added in edit:_ Now submitted as a separate link for more specific
discussion.

[https://news.ycombinator.com/item?id=6970017](https://news.ycombinator.com/item?id=6970017)

~~~
webmaven
This still gets Python wrong. It wasn't a reaction to Perl at all.

------
paf31
Might as well take the opportunity to sell my own project: Purescript:
JavaScript doesn't have a static type system.

------
corey
Haskell: Programmers aren't disciplined enough to to isolate side effects by
themselves.

------
pshc
Rust: Other languages have boundary issues -- action-at-a-distance is evil.

~~~
pcwalton
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.")

------
kabdib
SNOBOL: Nobody can process strings worth a damn.

Icon: Generators are cool.

FORTH: Omit needless features! Omit needless features! Omit needless features!

------
intull
D: because C++ is a kludge

------
vlucas
PHP: Perl is too hard to configure and run on the web

~~~
mechanical_fish
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".

~~~
vlucas
I think the evidence absolutely supports this, and it's the primary reason PHP
largely replaced Perl scripts for tasks related to serving web pages.

------
woody99
Node: It's hard to find JavaScript coders since there is no career path for
them.

~~~
twerquie
There is no career path for anyone who only does one thing.

------
seanstickle
APL: Errors increase in proportion to the amount of code typed; therefore,
decrease amount of code typed while keeping expressiveness and power
unchanged.

Alternatively:

APL: Programming should be more like math.

~~~
gruseom
I noticed that the APL one seemed off as well. But I would say:

APL: Other languages are verbose and irregular.

------
fizx
Scala: there aren't enough ways to do this yet.

Go: Java is too bloated.

------
grannyg00se
Javascript: Scheme is too unapproachable

~~~
grannyg00se
Apparently some people hate the JS/SCHEME meme [1].

[http://journal.stuffwithstuff.com/2013/07/18/javascript-
isnt...](http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt-scheme/)

I'd happily agree to Self rather than Scheme but I can't edit now :)

------
aabalkan
Go: C does not have garbage collection.

------
ballard
C fixed Fortran 66 as well as assembly being too low level (very manual memory
allocations).

------
etfb
I suspect the kindest thing one can say about Forth is:

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!

~~~
justincormack
Forth: order wrong in arguments C

------
MBlume
For Java I would suggest "Lisp is _too_ powerful for Joe Programmer, and
parentheses are scary"

Java as essentially Lisp's bastard child is I think undermentioned in language
history.

~~~
cwzwarich
What Lisp influence is there in Java besides garbage collection? They differ
on basically every other language design point.

~~~
wonderzombie
[http://www.paulgraham.com/quotes.html](http://www.paulgraham.com/quotes.html)

"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...](http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/msg04045.html).

Relative to C++, Java is actually a lot like Lisp. Don't forget that objects
are a poor man's closures (and vice versa).

~~~
cwzwarich
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.

~~~
wonderzombie
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.

------
laureny
Interesting that the newest language that pg lists is more than ten years old.
He's probably not keeping up with new language development any more?

~~~
ricree
Or just not adding to the list. It's undated, but another posting from last
year lists it as (2002).

[https://news.ycombinator.com/item?id=4954663](https://news.ycombinator.com/item?id=4954663)

------
dschiptsov
PHP: somehow it runs.

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.

------
etfb
How about:

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 $.

------
krapp
Javascript: html is boring.

------
Mikeb85
Haxe: because nothing compiles to enough targets...

------
hrabago
Coffeescript: Javascript is too ugly.

~~~
twerquie
Coffeescript: I'd rather be writing Ruby

~~~
audreyt
Coco: I'd rather be writing Perl-flavored Ruby.

LiveScript: I'd rather be writing Perl-flavored Ruby, with a Haskell syntax. (
[http://livescript.org/](http://livescript.org/) )

------
jayzalowitz
pg: php?

~~~
prodigal_erik
Perl: PHP is a kludge.

~~~
RafiqM
What? Perl is about 10 years older than PHP.

In fact it would make more sense reversed.

PHP: Perl is a kludge.

Because that's what PHP mostly replaced - Perl.

------
jbeja
Lua: Because my dog is called "Luna"

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!!!

