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

71–80 of 102 posts

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

#71

Post by wes-exp »

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?

Rasmus Lerfdorf (designer of PHP) did an interview where he explained PHP's origins http://www.twit.tv/floss12.

It's been a long time since I listened to the interview, but I think he created PHP to create simple websites. Wikipedia even says the original acronym was "Personal Home Page".

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

#72

Post by rufugee »

kragen wrote: post #60
rufugee wrote: post #55

Earlier quoted context omitted.

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 rea…

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 :)

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.

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

#73

Post by kgtm »

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.

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

#75

Post by kragen »

thurn wrote: post #67
kragen wrote: post #32

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

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

#76

Post by kragen »

shazow wrote: post #70
kragen wrote: post #32

Earlier 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…

from processing import LEFT, mouse_x, mouse_y, mouse_button Now you don't have to prefix things with `processing` just like you don't in your Ruby version.

If the program used them in several places, that would be an improvement, but it doesn't. It's maybe a little bit atypical, but nearly all of the things it calls from Processing, it calls in exactly one site: the above, plus color_mode, no_stroke, smooth, background, and rect.

It does call fill from four call sites, but that was because there's no reasonable way to return a list of four arguments from a method in Ruby, as far as I can tell.

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

#77

Post by zwp »

kragen wrote: post #76
shazow wrote: post #70

Earlier quoted context omitted.

from processing import LEFT, mouse_x, mouse_y, mouse_button Now you don't have to prefix things with `processing` just like you don't in your Ruby version.

If the program used them in several places, that would be an improvement, but it doesn't. It's maybe a little bit atypical, but nearly all of the things it calls from Processing, it calls in exactly one site: the above, plus color_mode, no_stroke, smooth, background, and rect. It does call fill from four call sites, but that was because there's no reasonable way to return a list of four arguments from a method in Rub…

> way to return a list of four arguments from a method

p, q, r, s = * method_that_returns_array_of_4_things

* aka "splat operator"

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

#79

Post by nostrademons »

rauljara wrote: post #3

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

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

Hah. I added that edge way back when I was back in college. The "extended" graph was actually crowdsourced on the C2 Wiki, circa 2004, and it's pretty cool to see it here now.

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

#80

Post by kragen »

zwp wrote: post #77
kragen wrote: post #76

Earlier quoted context omitted.

If the program used them in several places, that would be an improvement, but it doesn't. It's maybe a little bit atypical, but nearly all of the things it calls from Processing, it calls in exactly one site: the above, plus color_mode, no_stroke, smooth, background, and rect. It does call fill from four call sites, but that was because there's no reasonable way to return a list of four arguments from a method in Rub…

> way to return a list of four arguments from a method p, q, r, s = * method_that_returns_array_of_4_things * aka "splat operator"

That's great, thanks! And that works for method calls too. So now I can replace set_color_from @cells[x][y] with fill *color_from(@cells[x][y]), reducing the number of side-effecting methods by one, and now I'm calling every Processing function in at most one place.
Post reply on HN