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.
Every language fixes something - a DiGraph - just for fun
61–70 of 102 posts
Re: Every language fixes something - a DiGraph - just for fun
#62Earlier quoted context omitted.
So, do the words "just for fun" not actually mean anything to you? Just curious - you seem really angry about this.
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 star…
> 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.
Re: Every language fixes something - a DiGraph - just for fun
#63Re: Every language fixes something - a DiGraph - just for fun
#64The 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...
I'd argue that the idea of a first-class "symbol" data type is one of Ruby's best features, and one that was directly copied from Lisp.
Re: Every language fixes something - a DiGraph - just for fun
#65Earlier quoted context omitted.
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 mu…
I don't understand why you think the Ruby code has better SNR. The python code is two lines shorter. In python, you have to type the (), but that's not really "noise". I do hat the : at the end of python control statements. I always forget them, and it seems like the parser could do it's job just as well without them.
> I don't understand why you think the Ruby code has better SNR.
Because they say the same thing, but the Python code is much longer, if you count tokens instead of lines. It has about 28-30 more tokens than the Ruby code does, about three per line. Those tokens don't convey any information. They're just redundancy, i.e. noise. And there are a lot of them; these redundant tokens are something like a third of the code.
Now, redundancy can be useful (see e.g. http://www.paulgraham.com/redund.html) but it is costly, so you should keep it to the minimum that achieves what you want the redundancy to achieve.
Re: Every language fixes something - a DiGraph - just for fun
#66Earlier quoted context omitted.
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.
> 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…
(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.
Re: Every language fixes something - a DiGraph - just for fun
#67Colin, 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 :)
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 mu…
I don't understand this code. In the Ruby example, mouse_x() appears to be a method on the current object, in the Python one it's a method on some other object (a module named "processing"?). Since the code examples are the same, I'd say whichever language I'm wrong about is the less clear one.
Re: Every language fixes something - a DiGraph - just for fun
#68Earlier quoted context omitted.
> 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…
(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.
It seems that pairs of stars is a problem, whether they're in the same paragraph or not: starts here …
… but ends here.
Re: Every language fixes something - a DiGraph - just for fun
#69Earlier quoted context omitted.
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 star…
> 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…
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?
Re: Every language fixes something - a DiGraph - just for fun
#70Colin, 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 :)
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 mu…
from processing import LEFT, mouse_x, mouse_y, mouse_button