

Every language fixes something - a DiGraph - just for fun - ColinWright
http://www.solipsys.co.uk/new/EveryLanguageFixesSomething.html?HN0

======
Sukotto
Yes the chart has errors, yes some of the vectors make no sense. Yes, _your_
version of the chart would differ greatly (hell, his "enhanced" one differs
significantly from the basic one.)

 _Cut the guy some slack_. He put the work in and the result is a pretty cool
look at how _he_ makes sense of the way various languages interrelate and
borrow from each other. There are others showing the way other people think
[1] and I hope some of you will try your hand at it.

[1] Personally, I really like the one O'Reilly did a few years back:
<http://oreilly.com/news/graphics/prog_lang_poster.pdf> I suspect I tend to
think more linearly than the OP

~~~
vidar
Well said, if perfection is the only thing worthy of being posted nothing
would be said.

------
rauljara
The enhanced version is completely different from the regular version. Not
only are the reasons different, but a lot of the languages don't even inherit
from the same sources (the regular version had javascript coming from java.
wtf?). Just goes to show how arbitrary/silly it all is.

Still pretty awesome. Why did haskell come about? "Lazy evaluation is cool,
yo."

~~~
diminish
fortran is apparently fixes machine code

~~~
ColinWright
It doesn't say it fixes it, it asserts that ForTran was created because people
thought Assembler was too low level.

Not the same thing at all.

------
mononcqc
Erlang actually came from needs in proprietary languages like PLEX and other
stuff used within Ericsson. The ideas were to have better concurrency (not
parallelism) and better fault tolerance (through distribution and whatnot),
properties that were thought to be too hard to do with other languages at the
time.

That it has lisp influences and was implemented in Prolog first speaks of the
creators of the language, not what it attempted to fix in there. And I
seriously doubt that fixing lisp syntax was an objective in the language,
especially given Robert Virding, one of the original 3 creators of Erlang, now
has his own lisp syntax on top of the BEAM VM as LFE (Lisp Flavored Erlang).

------
gizzlon
Cool =) But who says perl has "no support for Japanese"? Don't think that's
true

~~~
kgtm
I came here to inquire about the same thing. The shared page has been last
modified 2011-07-28 but currently Perl seems to handle Japanese fine, either
via the Encode module (core) or alternatively Unicode::Japanese on CPAN.

Regardless, I'd be interested in knowing of any problems people have had with
handling Japanese.

~~~
ColinWright
I just stuck the page up as a place-holder for the graph that was played with
in 2003/2004.

I'll go change it again to help try to make that clear.

------
temptemptemp13
Python is "notenough OO" and leads to Ruby?

I smell a troll under the bridge.

~~~
dimmuborgir
Around 1995, when Ruby was created, Python was "notenough OO".

------
shrikant
Colin, would a reasonable implicit assumption be that if the problem being
solved isn't a problem for me, then I should stick with the language in
question?

I mean, for e.g., if I don't care that Python's not OO enough, I don't need to
know Ruby, right? Right?!

p.s: in case it's not apparent, I will be using these graphs to justify some
laziness on my part :)

~~~
kragen
There might be other reasons that are more important to you. e.g. if you've
been using Modula-3, its syntax might be a reason to switch to Python, but in
my mind, things like the iterator protocol and NumPy are better reasons.
(Also, you've been asleep under a rock for fifteen years.)

In my case, I've been surprised at how much less syntactic overhead Ruby
imposes than Python (despite the explicit "end"!), and how much it matters.
Compare:

    
    
        def mouse_clicked
          x = mouse_x / @cellsize
          y = mouse_y / @cellsize
    
          if @cells[x][y] == :empty
            set x, y, :wire
          elsif mouse_button == LEFT
            set x, y, :empty
          else
            set x, y, :electron_head
          end
        end
    
        def mouse_clicked(self):
            x = processing.mouse_x() / self.cellsize
            y = processing.mouse_y() / self.cellsize
    
            if self.cells[x][y] is Empty:
                self.set(x, y, Wire)
            elif processing.mouse_button() == processing.LEFT:
                self.set(x, y, Empty)
            else:
                self.set(x, y, ElectronHead)
    

(Here ElectronHead and the like are assumed to be top-level empty classes in
the module; the Ruby equivalent is a Lisp-style atom that doesn't need to be
declared.)

To me, the Ruby version has a much higher signal-to-noise ratio.

Another thing: JRuby seems to be a lot more mainstream among Rubyists than
Jython is among Pythonistas, which I think means it's a bit more solid.

~~~
rufugee
Hi there...experienced ruby guy here who is doing python work at the moment.
The nice thing I find about python, even in its verbosity relative to ruby, is
that I always for the most part know what it's doing. With ruby, the impulse
to overload operators and create dsls mean that I have to learn a new language
(potentially) with every new project or library I choose to use. It's not
immediately clear what code is really doing. With python, it usually is. Just
my (quick) two cents.

~~~
kragen
Yes, I think the verbosity I'm complaining about above is the fruit of three
of the principles of the Zen of Python:

Explicit is better than implicit.

Errors should never pass silently.

Namespaces are one honking great idea -- let's do more of those!

Maybe after I spend more time with Ruby, I'll see the dark side of DSLs, but
so far I'm loving it :)

~~~
rufugee
You probably will, if you're anything like me. However, at the end of the day,
I find the "require" statement in ruby to be the truly most irritating
feature. You simply don't get much control over what is slurped into your
code. Python's import statement is so refreshing in comparison. I feel more in
control in python, and I say this as someone who really likes ruby.

------
Supermighty
PHP gets no love.

Where would it be in the chart? coming off of C or C++?

~~~
ColinWright
When the people who "designed" PHP did so, why did they think no existing
language would do the trick? What was the problem with all the existing
languages?

What problem were they trying to fix?

~~~
prodigal_erik

      Everything -> not bundled -> PHP
      Perl -> too weird -> PHP
    

It's hard to explain to a novice that in Perl 4/5, $x[42] dereferences @x, not
$x (which are completely separate, except when they're not, due to *x). And
PHP has a much more typical object system. I think we agree that most all of
PHP's distinctive and non-mainstream design decisions have been bad ones,
though.

~~~
JadeNB
> It's hard to explain to a novice that in Perl 4/5, $x[42] dereferences @x,
> not $x (which are completely separate, except when they're not because of
> (star)x).

(I don't know how to protect the star from starting an emphasise block.
Escaping it doesn't seem to work.)

Sorry to nit-pick, but these may be particularly hard to explain because
they're not true.

$x[42] isn't a de-reference at all, but an indexing. (Granted, it's more than
a little confusing that it's indexing @x. This is 'fixed' in Perl 6.) $x->[42]
_is_ a de-reference, but of $x, not of @x (which isn't a reference anyway (I
think unlike in Ruby)). @x and $x are _always_ completely separate; typeglobs
allow you to say something like (star)x = \@y, whereupon @x and @y are the
same (but still $x and @x are completely different). I suppose you could claim
that $x and @x are no longer _completely_ different if you say something like
$x = \@x, whereupon $x->[42] and $x[42] mean the same thing.

~~~
prodigal_erik
(On using *, the trick is not to put two in the same paragraph with words
between.)

You're right, "dereference" was a poor choice of words because it means
something more specific in Perl. And I think a programmer would need at least
a year of experience before they could possibly understand your main
paragraph, while PHP was dumbed-down enough to be approachable by amateurs.

~~~
JadeNB
It seems that pairs of stars is a problem, whether they're in the same
paragraph or not: _starts here …

… but ends here._

------
snippyhollow
Not only is it arbitrary, it could be cool if it was realistic. But "Not pure
-> ML" ? Seriously ?

It should be Turing machines -> Too awkward for modeling programming -> Lisp
Lambda calculus -> No typing -> ML -> Not pure -> Haskell ML -> no
objects/modules -> Ocaml

------
sequoia
Javascript was developed to replace Java... do tell.

~~~
ColinWright
a. You're looking at the original, which is in PG's original essay. The second
version doesn't have that link at all.

b. It's not talking about "developed to replace," it's talking about "was
developed in response to a perceived problem."

~~~
sequoia
>"was developed in response to a perceived problem."

It wasn't this either.
[https://secure.wikimedia.org/wikipedia/en/wiki/Javascript#Hi...](https://secure.wikimedia.org/wikipedia/en/wiki/Javascript#History)

I'm just taking the piss anyway, the whole chart is silly. Cheers!

~~~
ColinWright
Your reference seems to miss the point. The question is - what was wrong with
existing languages? Why was JavaScript developed instead of using an existing
language?

What problem was it trying to fix?

~~~
sequoia
Javascript was not created to "fix Java's 'scary syntax'"!! Java applets were
self-contained features embedded in a webpage whereas javascript– argh! Why
are we having this discussion!? :p

~~~
ColinWright
Have you not noticed that the "enhanced" version doesn't have an arrow between
the two? You're still arguing about PG's original ...

<grin>

------
ColinWright
Where do people think "D" should be put? What arrows with what labels?

~~~
Symmetry
C++ -> D "Kludge"

Java -> D "But I _liked_ manual memory management."

~~~
ColinWright
I've added (something similar to) that.

~~~
andrewcooke
also C + memory management = Go

~~~
ColinWright
Done.

------
RichClaxton
Nothing after Erlang, does that mean its perfect :)

~~~
eru
Unfixable.

------
peteretep
The line from Lisp to Ruby should go from Lisp to Perl - all the Lispy
features Ruby has - as I understand it - were lifted via Perl...

~~~
kule
I think the Lispy features were more derived Smalltalk than Perl...

~~~
ColinWright
It's not a question of what the language was derived from, it's a question of
what prompted it to be developed.

It's not where it drew it features from, or what its ancestor was, or what's
it's most like. It's a question of what caused the developers to create a
language, not where they got the new language's feature from.

------
msarnoff
Still my favorite: "A Brief, Incomplete, and Mostly Wrong History of
Programming Languages"

[http://james-iry.blogspot.com/2009/05/brief-incomplete-
and-m...](http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-
wrong.html)

------
kingkilr
A related view of language evolution:
[http://www.reddit.com/r/programming/comments/90g80/history_o...](http://www.reddit.com/r/programming/comments/90g80/history_of_the_c_family_of_languages_funny/c0b0nmy)

------
Rickasaurus
Nemerle but no F#? Seriously?

------
siphr
This is definitely worth a bookmark. It must've taken some considerable time
to create but is of great value. I find it to be a quick reference to see how
the languages differ from each other. Very nice.

------
davedx
Java (controlled by Sun) -> C# (controlled by Microsoft)

Sensible?

~~~
ColinWright
The claim is that Microsoft developed C# in response to the perceived problem
that Java was controlled by Sun.

Sensible or not, seems a reasonable interpretation. 8-)

------
ScottBurson
I think Ada should be linked from Pascal, with (like Modula) an arrow labelled
"too wimpy for systems programming", or perhaps "programming in the large".

------
buckwild
Thanks for this. I truly didn't believe learning multiple computer languages
could make you a better programmer until I saw this diagram.

------
perlgeek
I found it particularly amusing that Common Lisp solved the "too many
dialects" problem, being a Lisp dialect itself...

~~~
alttag
Of course it is. XKCD explained this a few weeks ago: <http://xkcd.com/927/>

~~~
pavpanchekha
In this case, it actually seemed to solve it. A lot of the older lisps died
off as a result of CL. Scheme and Dylan were really the only survivors for a
while. IIRC.

------
smackfu
I think the real one for PL/I is "not invented by IBM" but maybe I'm too
cynical.

------
lawlit
What do you think Go fixes ?

~~~
bhousel
Not invented here?

------
tarmil
Methinks it lacks "Pascal -> Need contracts -> Eiffel"

~~~
ColinWright
I won't add everything everyone suggests, that's just silly, but I've added
that. The whole thing is intended as a bit of fun and not to be taken
seriously, but I thought that was worth adding, not least because it improved
the layout 8-)

------
cek
Where's INTERCAL? What does _it_ fix?

~~~
prodigal_erik

      COBOL -> not funny -> INTERCAL

~~~
rcfox
INTERCAL -> not funny enough -> LOLCode

------
SeoxyS
I can't respect any chart that describes Java as an evolution and improvement
of Objective-C.

~~~
mmariani
I'd say Java targeted to improve on C++ by abstracting the machine, and only
took some cool features from Obj-C. Which by the way came from Small Talk.

------
naughtysriram
Nice graph. It would be wonderful if you could also put it in what takes what
from where in addition to what fixed what.

------
pavpanchekha
Bullshit. Not to mean or anything. But bullshit. Most of the arrows are
labelled with the author's post-hac, childish generalizations of language
differences. JavaScript came from Java because of the scary syntax? No, it
came from Scheme because of the scary syntax, Java's syntax was considered
particularly comforting. There's no relation between Lisp and MacLisp. Lisp
came from "Turing Machines"? Ruby came from Perl and Lisp (but _not_ Scheme)
and not from Smalltalk? In fact, seems like Smalltalk had no influence at all.
It's a cool idea, but it forces one to trivialize language differences to a
scary extent.

~~~
ColinWright
So, do the words "just for fun" not actually mean anything to you?

Just curious - you seem really angry about this.

~~~
alttag
Perhaps part of his point if it's "just for fun", which in the broadest
interpretation could be taken as "without any basis whatsoever" then it
doesn't belong in front of a crowd of people who expect logical explanations
for things.

Let's be honest—some of the descendants are a bit off (Java->Javascript,
anyone?), and some languages have multiple inspirations not listed.

It's an interesting idea, and perhaps the starting point of actual research,
but isn't yet trustworthy or sensible enough to be taken as gospel.

~~~
JadeNB
> some of the descendants are a bit off (Java->Javascript, anyone?)

The page explicitly notes that this is not an inheritance / 'paternity' graph,
but rather a description of the (perceived) problems with one language that
another language fixes (or tries to).

I don't think there's even any implication that any one language was created
in response to any other, just that it shares certain aspects, and removes
certain warts.

~~~
nxn
So you agree with the diagram is stating: that JavaScript fixes Java's syntax
by using the same C-like syntax?

No, the given reason for Java -> JavaScript is completely wrong. I'd
understand if the reason was "Java browser applets suck", but syntax?

~~~
ColinWright
Have you not noticed that the link you're complaining about is in PG's
original essay, and the newer version _has no link between Java and
JavaScript_?

~~~
nxn
Yeah, actually I have noticed and was well aware of it when making my comment.
The topic of this particular comment thread, however, was specifically about
the first graph since the mentioned link's validity was being "defended" by
saying the graph was not an "inheritance / 'paternity' graph".

In fact, I could have also mentioned myself that the link was taken off the
second graph to further my case that it was just plain wrong. The only reason
I did not was because I thought it was something so obvious it would not be
necessary to state it.

