We should translate that into as many languages as possible and use it as a benchmark for a real world application to compare the efficiency of the various languages.
I wish someone would create some benchmarks that were good for comparing code size. That would be a bit harder, because the problems would have to be bigger, and thus more likely to be ambiguous, but it would be a useful thing to have.
Gzip-ed bytes of code is pretty great, and relatively fair to languages with verbose (but isomorphic) syntaxes. It's aiming to count the information content.
A benchmark counting the unshared working set would be pretty decent, but quite unkind to news.arc -- counting all of Arc and most of MzScheme as part of your program. MRI Ruby programs would be totally fucked, since the mark-happy GC keeps any library code from being shared between fork()ed processes.
For example, looping over a matrix in matlab is both clunky and extremely inefficient. You can just do matrix operations that are extremely tight.
You might use that to say it is better than C.
But it is C. They've just make language constructs that make is easy to do matrix operations. You could do the exact same thing with a library in C.
So comparing languages might run into the issue of comparing available libraries. I don't think new languages want to compete on availability of libraries.
Since Matlab has language constructs for doing matrix operations, it is better for manipulating matrices than C. That Matlab compiles down to C, or calls into C libraries, is an implementation detail.
You can't get around the interpreted vs compiles difference (among others) that differentiate Python and C. The discussion is one of code size though, not the other differences.
You can make compact and readable C that looks like other language constructs by writing libraries, to a limit.
My point, if I didn't complete it, is one I've mentioned a few times. Libraries matter more than things like LOC count. And it is a really big difference.
I challenge anyone to write an Arc levenberg marquardt minimization in less than 100 LOC. In Matlab (and other languages with good sets of libraries) it is literally just a parameterized function call.
Maybe I'm just too pragmatic for discussions like this.
Ok, so let me try to spell this out to see if I understand what you mean:
You are basically saying that whatever is primitive to the languages is irrelevant because the language that has the best libraries will win such a contest hands down because what needs to be re-implemented in one language is a primitive in the other.
That's true as far as I can see, but only for 'domain specific' problems. By running a benchmark that contains samples from many domains it should be possible to average out those factors.
Another way to deal with it would be to limit the code to code written in primitives.
Still matlab would handily outperform any other language not endowed with primitives for matrix manipulation, but that's exactly the whole point of such a test. To figure out given a problem for a certain domain what would be the most expressive platform to solve the problem in.
Across many domains, the effect of libraries is exaggerated. Perhaps minimization isn't enough. Let's add image processing, talking to hardware over a serial port, and parsing an xhtml file. Libraries win:
I agree completely. Even if I'm just playing around, the cost of creating a source repository is so small (especially with distributed repos) that I pretty much do it when I'm just playing with an idea.
If the idea grows big, it's fun to look at where it was when I started. If it fizzles, well at least you have something for the memories...
We should translate that into as many languages as possible and use it as a benchmark for a real world application to compare the efficiency of the various languages.
You'd have to translate it into Arc at this point. It would not run in present-day Arc.
You mean, like this?
http://shootout.alioth.debian.org/u32q/
I wish someone would create some benchmarks that were good for comparing code size. That would be a bit harder, because the problems would have to be bigger, and thus more likely to be ambiguous, but it would be a useful thing to have.
Gzip-ed bytes of code is pretty great, and relatively fair to languages with verbose (but isomorphic) syntaxes. It's aiming to count the information content.
A benchmark counting the unshared working set would be pretty decent, but quite unkind to news.arc -- counting all of Arc and most of MzScheme as part of your program. MRI Ruby programs would be totally fucked, since the mark-happy GC keeps any library code from being shared between fork()ed processes.
I think those comparisons would be meaningless.
For example, looping over a matrix in matlab is both clunky and extremely inefficient. You can just do matrix operations that are extremely tight.
You might use that to say it is better than C.
But it is C. They've just make language constructs that make is easy to do matrix operations. You could do the exact same thing with a library in C.
So comparing languages might run into the issue of comparing available libraries. I don't think new languages want to compete on availability of libraries.
By your rationale, Perl and Python are C.
Since Matlab has language constructs for doing matrix operations, it is better for manipulating matrices than C. That Matlab compiles down to C, or calls into C libraries, is an implementation detail.
You can't get around the interpreted vs compiles difference (among others) that differentiate Python and C. The discussion is one of code size though, not the other differences.
You can make compact and readable C that looks like other language constructs by writing libraries, to a limit.
My point, if I didn't complete it, is one I've mentioned a few times. Libraries matter more than things like LOC count. And it is a really big difference.
I challenge anyone to write an Arc levenberg marquardt minimization in less than 100 LOC. In Matlab (and other languages with good sets of libraries) it is literally just a parameterized function call.
Maybe I'm just too pragmatic for discussions like this.
Ok, so let me try to spell this out to see if I understand what you mean:
You are basically saying that whatever is primitive to the languages is irrelevant because the language that has the best libraries will win such a contest hands down because what needs to be re-implemented in one language is a primitive in the other.
That's true as far as I can see, but only for 'domain specific' problems. By running a benchmark that contains samples from many domains it should be possible to average out those factors.
Another way to deal with it would be to limit the code to code written in primitives.
Still matlab would handily outperform any other language not endowed with primitives for matrix manipulation, but that's exactly the whole point of such a test. To figure out given a problem for a certain domain what would be the most expressive platform to solve the problem in.
Across many domains, the effect of libraries is exaggerated. Perhaps minimization isn't enough. Let's add image processing, talking to hardware over a serial port, and parsing an xhtml file. Libraries win:
I'm not sure how meaningful this would be; arc was basically written for news.arc.
"meaning it's 4 days old." -> 4 years :-)
No, 4 days. The write date of the file is September 6, the comment below says he started writing it on September 2.
What's the LOC now?
About 10x that: http://github.com/nex3/arc/blob/dca901c0cb59ebb533a511df3a84...
lol..
Why would there be any confusion over what the earliest version is? It would just be the initial revision in your source control repo.
… which is usually empty.
I agree completely. Even if I'm just playing around, the cost of creating a source repository is so small (especially with distributed repos) that I pretty much do it when I'm just playing with an idea.
If the idea grows big, it's fun to look at where it was when I started. If it fizzles, well at least you have something for the memories...