Hacker News Reader

Comment by jameskilton | Hacker News Reader

Why do we keep playing this like a competition? I'm sure someone could put together an equally valid post about why Go is "better" than Racket. It's frustrating how so many people forget that we're all in this together, how every language has it's pros and cons, and how our job is to pick the best tool for the job.

View on HN

Err, because "pick the best tool for the job" is precisely a competition that each of us has to judge?

These posts could help us in choosing the best tool for our jobs.

Best is vague and ambiguous, you might as well be trying to find out what the best instrument is for making music (or the best color for painting).

A composer doesn't necessarily sit down and decide to "make music". A composer often has some sort of goal in mind, and yes, they will indeed seek out the best instrument for the job. The criteria may very well even include such things as "how skilled am I on the instrument"; someone may just noodle around on a keyboard or a guitar for something that may end up on another instrument entirely, for reasons of familiarity, or because the instrument has useful characteristics. For instance, a piano is a very useful instrument to write for a symphony orchestra, because even though it may not sound like any instrument that will be in the final composition, it's pretty hard for one person to play two flutes and two trombones at the same time, whereas the piano makes it easy to play at least the same notes, so you can hear the harmony.

Similarly for painting; you're looking at a world of difference between watercolor and oil (just to pick two examples), and what you chose depends on the goals.

I'm not sure your metaphor was as useful as you'd like.

Those analogies don't work. Paintings use multiple colors, and many pieces of music use multiple instruments; but for most programs, it's far simpler to use just one language. And if one is going to develop a large program over the span of many years, it's good to think carefully about what language to use before diving in, as that decision is not easily changed.

Except the selection of "facts" presented by these kinds of posts are rarely amenable to independent analysis.

I think it sums it up at the very last sentence, almost as if it isn't really relevant :

"Racket programs build and run much slower than Go programs."

Edit: By this I meant to be agreeing with the above statement that someone will come along and write a post about why Go is better - it's already been done in this one post. Sorry for the misunderstanding..

Obviously, sometimes execution speed is important, and sometimes it isn't - it depends on what you are trying to do.

The author's postscript links to this follow-up blog post:

http://cxwangyi.wordpress.com/2012/07/29/chinese-whispers-in...

To me, the speed at which the code executes is a second derivative problem - this is to say that if a language gets version 0.1 deployed two months faster, then it is faster in a more important sense. A hammer and screws is more useful than a screwdriver and nails - intact it is more useful than a Phillips screwdriver and slotted screws.

If you see the links after that (and the comments) there were some issues with Racket's GC, and there were some fixes offered. YMMV.

That said, of course it isn't "really relevant". Or, at least, it's not all that matters, if Racket offers a superior experience otherwise AND its speed is adequate for the task.

Else we'd use C all the time, and nobody would use Python or whatever higher level language.

That's only an implementation detail that could one day be overcome. PyPy is an excellent example of why, "X language is slow," is a silly statement. The implementation of the language runtime can be made to be faster.

As well as speed being a secondary concern for all but a few application domains.

Reply on news.ycombinator.com