Hacker News Reader

Comment by antirez | Hacker News Reader

In the first place the rule that all the libs should be standard libs is non sensical from the point of view of comparing languages power, so I think we can safely suppress it and still consider the attempts valid.

Proof: if you want to measure the power of a language with this test, enforcing that everything should be in the standard lib, and a language fails at it, adding some code to the standard lib will change the power of the language, but this is not possible because the syntax, semantic and behavior of a language (i.e the language itself) is not changed by additions to the standard library.

View on HN

But if you look at it another way, a significant portion of what's used in the arc examples would not reach the bar of what's included in the standard libs of some other languages. The fact is that what is in the standard lib of a language is a totally arbitrary decision, and measuring any language's power in a way that's dependent on whether or not a necessary library is in the standard lib is silly.

The real test should be, "How short can you make this code using libraries available for the language which would be generally useful working on some other task as well."

This is the argument I should have used in the post, having slept now and my thoughts being more clear:

There are really three, separate things under consideration here:

- What is the expressive power of the language's syntax?

- How strong is its standard library?

- How strong is library coverage for common tasks?

The first question is what the second example tries to demonstrate, i.e. "How concise could this be made in Ruby?" The second question, I agree with you mostly. There are outliers like C++ with an especially poor standard library, but in general, that doesn't speak to the language's innate power. And in the third, I hit at in the post by saying that I feel this particular task is a bit contrived with respect to Arc: it shows simplicity in things that I wouldn't necessarily look for in a web programming language, but lacks things that I would expect (i.e. the ability to connect easily to web services APIs).

The challenge should be LOC total, including the LOC of the libraries used. That is the only possible way to compare apples to apples. Otherwise, what is to stop you from wrapping the entire solution into a "library" and just making a simple call-out to said library.

What is the total LOC of the implementation, period. Remove all ambiguity.

With respect to ambiguity: Wouldn't the LOC count have to also include the code of the interpreter or how would you compare an interpreted language where some method is "built-in" with another language where the method has to be implemented in a library?

Anyway, LOC count is a fetish that wreakes havoc in language communities like ruby. I'd be more interested in readability and clarity. Show the code to somebody who knows the language only superficially and take the time the person needs to figure out what the code does.

It would be possible to implement a processor that implemented this as a single assembly language instruction!

How low do you go before you give up? Silicon atom count?

I'd say that 'LoC using a language plus common libraries at least some developers use in real projects' is the most valid thing to measure.

Reply on news.ycombinator.com