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

The speed, size and dependability of programming languages

gmarceau.qc.ca

Post reply on HN
Print view View original

11–20 of 59 posts

Re: The speed, size and dependability of programming languages

#11

Post by silentbicycle »

gruseom wrote: post #9
silentbicycle wrote: post #8

Earlier quoted context omitted.

Lua isn't usually associated with the functional languages. Besides mainly being promoted for embedded / extension use, I think the single biggest reason for this is that, while it has tail-call elimination, closures, first class functions, etc., you still have to say "return x" at the end of functions. I do a lot of FP-style stuff in Lua, and while the language doesn't actively resist it the way Python does, it's no…

you still have to say "return (val)" at the end of functions We have a bunch of code that compiles to both Common Lisp and Javascript, and those nasty "return" statements are one of the two biggest mismatches between the two languages (the other being Javascript's weird semantics around null, false, 0, and ""). One of these days I intend to try inserting them all automatically.

Indeed. It's surprising how deeply eliminating return changes the language semantics.

I've postponed learning Javascript until recently, because my work hasn't usually been web-oriented, but it's interesting how similar Javascript and Lua are. They seem to have been aimed at the same target, but for historical reasons Javascript's development got frozen early, while Lua had time to iron out many similar design flaws.

(In Lua, undefined and null are both nil, nil and false are "false-y", and everything else, including 0 and "", are truthy.)

Re: The speed, size and dependability of programming languages

#12

Post by bayareaguy »

gruseom wrote: post #9
silentbicycle wrote: post #8

Earlier quoted context omitted.

Lua isn't usually associated with the functional languages. Besides mainly being promoted for embedded / extension use, I think the single biggest reason for this is that, while it has tail-call elimination, closures, first class functions, etc., you still have to say "return x" at the end of functions. I do a lot of FP-style stuff in Lua, and while the language doesn't actively resist it the way Python does, it's no…

you still have to say "return (val)" at the end of functions We have a bunch of code that compiles to both Common Lisp and Javascript, and those nasty "return" statements are one of the two biggest mismatches between the two languages (the other being Javascript's weird semantics around null, false, 0, and ""). One of these days I intend to try inserting them all automatically.

Yes. Playing around with Metalua[1]'s anonymous functions[2] which allow you to shorten

  function(arg1, arg2, argn) return some_expr end
to the much more concise

  |arg1,arg2,argn| some_exp
makes me wish they were part of core Lua.

1- http://lua-users.org/wiki/MetaLua

2- http://metalua.luaforge.net/manual003.html#toc3

Re: The speed, size and dependability of programming languages

#13

Post by herdrick »

This is great.

If you've looked at Peter Norvig's spell checker shootout you won't be surprised much. Ex., the story on Common Lisp and Scheme implementations is the same here: MzScheme is the mediocre best of an unimpressive lot. (I want to see Clojure and Arc on this.) Python looks great again. F# looks weak here but wins big in the spell checker with reasonable-looking code. Sounds interesting.

What's the deal with Squeak? I had thought that it very concise.

The meta-message here is best of all: people are measuring language conciseness.

Re: The speed, size and dependability of programming languages

#16

Post by silentbicycle »

herdrick wrote: post #13

This is great. If you've looked at Peter Norvig's spell checker shootout you won't be surprised much. Ex., the story on Common Lisp and Scheme implementations is the same here: MzScheme is the mediocre best of an unimpressive lot. (I want to see Clojure and Arc on this.) Python looks great again. F# looks weak here but wins big in the spell checker with reasonable-looking code. Sounds interesting. What's the deal wit…

Well, arc's running on top of MzScheme, so it's likely to be a bit slower. Also, Stalin in the left column is a Scheme implementation, albeit one that is very restrictive for sake of raw speed.

Also, it's worth noting that the features in a language that make large systems' codebases manageable (such as good module systems) are different from the features that allow you to pare down small scripts further. It's hard to show features supporting conciseness-in-the-large in a one page benchmark, so IMHO the latter is often greatly overemphasized. Being able to knock 2 lines off 20 is often just a parlor trick, though, while 50kloc off of 200kloc can mean life or death for a project. The programming world would be a happier place if the size of every legacy C++ / Java codebase were cut by a double-digit percentage.

Re: The speed, size and dependability of programming languages

#17

Post by gruseom »

silentbicycle wrote: post #11
gruseom wrote: post #9

Earlier quoted context omitted.

you still have to say "return (val)" at the end of functions We have a bunch of code that compiles to both Common Lisp and Javascript, and those nasty "return" statements are one of the two biggest mismatches between the two languages (the other being Javascript's weird semantics around null, false, 0, and ""). One of these days I intend to try inserting them all automatically.

Indeed. It's surprising how deeply eliminating return changes the language semantics. I've postponed learning Javascript until recently, because my work hasn't usually been web-oriented, but it's interesting how similar Javascript and Lua are. They seem to have been aimed at the same target, but for historical reasons Javascript's development got frozen early, while Lua had time to iron out many similar design flaws.…

I think you hit the nail on the head earlier. It isn't "return" as such, it's expressions vs. statements. Backus got it right. What's surprising is that the superior way gets the tiny minority of usage. (Not so surprising if you know the historical reasons.)

JS is not so bad. We're lucky that what we're doing (writing high-level FP code that compiles to JS and runs in pretty much every web browser in the world) is doable at all.

JS even has its own version of progn: "(a,b,c)" evaluates to c (after evaluating a and b). We use that pretty heavily. Alas, it has two problems: there are some things you can't do inside the block (like declare new variables or have for loops), and it makes the JS harder to read and debug. Otherwise we'd probably just compile everything that way.

Re: The speed, size and dependability of programming languages

#18

Post by magv »

silentbicycle wrote: post #4

Very good graphs. Aside from X (time) and Y (code size), the center of the star implies "typical" performance, and the relative spread of the star shows specific data points. Ruby, for example, shoots out from the bottom right - to me, this says, "This is quite expressive, and if you know what you're doing, you can get reasonably good performance". It doesn't show memory usage or sample size, however - Rebol probably…

> The most interesting shape, to me, is Io's

There seems to be a mistake. If you compare Io to JRuby [1], you'll find that Io is always the slower one, even though the picture in the article suggests otherwise.

[1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

Re: The speed, size and dependability of programming languages

#19

Post by unbannable »

For this sort of comparison, mostly-functional multi-paradigm languages like SBCL and Ocaml should be run through the benchmarks twice; once with imperative code, once in the functional idiom. The often-repeated complaint (of which I'm skeptical) about functional languages is that they're only efficient when ugly imperative features are used, and it would be good to confirm or dispel that suspicion.

Re: The speed, size and dependability of programming languages

#20

Post by bad_user »

petercooper wrote: post #3

The references to Ruby aren't entirely what they seem in here. They seem to be relating to Ruby on the older shootouts, rather than the recent ones. That is, the uber-slow Ruby 1.8, rather than the Perl-beating and PHP-matching Ruby 1.9 which is more closely related to "yarv" on this list.

Maybe that's because Ruby 1.9 isn't being used in production yet. I tried using it but many gems are still incompatible with it.
Post reply on HN