Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every language fixes something - a DiGraph - just for fun

solipsys.co.uk

Post reply on HN
Print view View original

81–90 of 102 posts

Re: Every language fixes something - a DiGraph - just for fun

#81

Post by sili »

Sukotto wrote: post #30

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…

If the OP's main premise holds, it should take only some research to "expand" oreilly's graph with improvements between each language.

Re: Every language fixes something - a DiGraph - just for fun

#82

Post by ColinWright »

nxn wrote: post #69
JadeNB wrote: post #62

Earlier quoted context omitted.

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

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?

Re: Every language fixes something - a DiGraph - just for fun

#83

Post by ColinWright »

kgtm wrote: post #73
gizzlon wrote: post #2

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

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.

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.

Re: Every language fixes something - a DiGraph - just for fun

#87

Post by regularfry »

ColinWright wrote: post #48
Supermighty wrote: post #44

PHP gets no love. Where would it be in the chart? coming off of C or C++?

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?

The problem PHP tried to fix (and largely succeeded) had very little to do with the language, and a lot to do with the deployment of products written in that language, as I understand it.

Re: Every language fixes something - a DiGraph - just for fun

#88

Post by Peaker »

kragen wrote: post #75
thurn wrote: post #67

Earlier quoted context omitted.

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.

Yes. I don't have a Python version of Processing, so I thought about how the Processing API would best be exposed in Python — and it would probably be by calling functions exported by a module named "processing", rather than by inheriting your class from processing.App. So you're right about both languages.

You could use:

  from processing import ...

Re: Every language fixes something - a DiGraph - just for fun

#89

Post by Peaker »

kragen wrote: post #65
karmalizer wrote: post #51

Earlier quoted context omitted.

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…

Haskell removes not only the () that Ruby does, but also the commas. It also uses a simple precedence trick to remove almost all () in general (not just for functional calls).

I wanted to translate the code to Haskell directly, but the idioms don't map that well (self.cellSize would becomes something else entirely, and the comparison would not be fair).

Post reply on HN