I wonder why mlton doesn't have a higher profile. Is it hard to use, or something?
The speed, size and dependability of programming languages
51–59 of 59 posts
Re: The speed, size and dependability of programming languages
#52I thought this was the most telling line of the article: "Ultimately the first factor of performance is the maturity of the implementation."
That supports a common conviction held by fans of functional programming: if all of the years of arduous optimization that have been poured into GCC had instead been poured into (say) GHC, then Haskell would be even faster today than C is.
That is, to many people functional programming languages seem to have more potential for performance than lower-level procedural languages, since they give the compiler so much more to work with, and in the long run a compiler can optimize much better than a programmer. But so much more work has been put into the C-style compilers that it's hard to make a fair comparison. It's still hard, but this experiment seems to give some solace to the FP camp.
Re: The speed, size and dependability of programming languages
#53Earlier quoted context omitted.
I'm amazed gcc is slower than java. And it's more expressive than scala and f#? Something's gotta be wrong there..
You need to look at how many data points each language implementation actually produces. gcc runs all programs whereas java steady state (the one that looks faster than gcc) lacks a lot of data points (i.e programs). As you can see in the diagram gcc's star is pulled towards the right by one data point (at least it looks like one). If java steady state ran all programs its star might shift to the right as well. Or it…
A two line fix to compile in something like smartheap typically makes that memory allocation penalty go away. Not that it's hard to avoid unnecessary allocation/deallocation.
Re: The speed, size and dependability of programming languages
#54Earlier quoted context omitted.
That sounds more like, "its design interferes with fast implementation" to me. If there's a major difference between that and "it's slow language", I'm really curious what it is.
You missed a meta-level. The design doesn't interfere with having a fast implementation. It interferes with implementing a fast implementation. "It's a slow language," implies that there's something special about Ruby that precludes (relatively) fast implementation. There's nothing special about Ruby like this. Ruby is a very nice remix of language features that existed before. Getting a language to be fast can requi…
Got it. FWIW, I don't particularly care for Ruby; for that style of programming I usually use Lua, whose syntax and semantics are quite simple.
The existence of LuaJIT (http://luajit.org/luajit.html) supports your argument, I think.
Re: The speed, size and dependability of programming languages
#55Earlier quoted context omitted.
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 t…
> > (I want to see Clojure and Arc on this.) > Well, arc's running on top of MzScheme, so it's likely to be a bit slower. I'd be interested to see how Arc fares on the code-size axis.
Are there any large projects using it?
Re: The speed, size and dependability of programming languages
#56Earlier quoted context omitted.
> > (I want to see Clojure and Arc on this.) > Well, arc's running on top of MzScheme, so it's likely to be a bit slower. I'd be interested to see how Arc fares on the code-size axis.
Are there any large projects using it?
I don't know much about the Shootout, but my guess is that, if someone wants Arc there, they need to go and write whatever programs the Shootout requires you to write in order to participate in the Shootout.
I'd try it, but I don't know Arc (or Lisp yet, for that matter). If someone here knows Arc and wants to see it in the Shootout, I suggest they look into the faq: http://shootout.alioth.debian.org/u32q/faq.php
Re: The speed, size and dependability of programming languages
#57I thought this was the most telling line of the article: "Ultimately the first factor of performance is the maturity of the implementation." That supports a common conviction held by fans of functional programming: if all of the years of arduous optimization that have been poured into GCC had instead been poured into (say) GHC, then Haskell would be even faster today than C is. That is, to many people functional prog…
Haskell may potentially be compiled to within epsilon of C when using strict evaluation + mutable state + unboxed types (look at the shootout implementations; the majority are in this style), but lazy evaluation and functional data structures have a real cost.
It's not merely that the ghc developers have been insufficiently clever and diligent.
Re: The speed, size and dependability of programming languages
#58I wonder why mlton doesn't have a higher profile. Is it hard to use, or something?
I looked at SML and there seemed to be a few warts compared to Ocaml: http://www.mpi-sws.org/~rossberg/sml-vs-ocaml.html
mlton may not allow separate compilation (it does whole-program optimization at least), and it's pretty slow even on small stuff, but if you were really using just the Standard ML language, you could use a faster compiler for development. I'd probably want to use some extensions, and I wasn't sure if the intersection of mlton's extensions with some other implementation could satisfy me.
Re: The speed, size and dependability of programming languages
#59I wonder why mlton doesn't have a higher profile. Is it hard to use, or something?
I looked at SML and there seemed to be a few warts compared to Ocaml: http://www.mpi-sws.org/~rossberg/sml-vs-ocaml.html mlton may not allow separate compilation (it does whole-program optimization at least), and it's pretty slow even on small stuff, but if you were really using just the Standard ML language, you could use a faster compiler for development. I'd probably want to use some extensions, and I wasn't sure…
mlton seems to be used for optimized compilation for releases, while general development is typically done in another SML environment, such as smlnj.
I don't have really concrete experience with SML, just OCaml, which also has its share of warts. It's a fantastic language in certain niches, though; generally, the sort of niches for which dynamic / "scripting" languages are usually a poor fit. (I wouldn't write a serious compiler in Python, for example.) They're very complementary.
I think the ML family has a lot of advantages, but the community is pretty closely tied to academia (much like Haskell, but without the buzz). While that in itself is probably neither good nor bad, in this case a lot of the terminology used is especially math-y; There are many features ML has that programmers would find tremendously useful, except they're usually discussed using Greek letters, which is insular. I got a copy of The Definition of Standard ML from Amazon, hoping to get further insight into the language's design, and found it completely impenetrable. (Then again, I'm not a grad student.)
Newer languages seem to be using type inference (finally!), but as far as I know, nobody has really ran with the design of its module system.