Browse thread
Re: Why OCaml sucks
-
Jon Harrop
- Matthew William Cox
- Arthur Chan
- Tom_PrimožiÄ
- Elliott Oti
- Richard Jones
- David Teller
- Ulf Wiger (TN/EAB)
- Vincent Hanquez
- Ulf Wiger (TN/EAB)
- Kuba Ober
-
Kuba Ober
-
Arthur Chan
- Karl Zilles
- Kuba Ober
-
Arthur Chan
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Kuba Ober <ober.14@o...> |
| Subject: | Re: [Caml-list] Re: Why OCaml sucks |
On Monday 12 May 2008, you wrote: > > Yet, if you look at things in the light of "optimization is > > depessimization", > > you'd much rather have easier to read code, than code which is ugly > > because > > you preoptimized it by hand. This is why, for me, Ocaml has a long way to > > go > > to make it useful for run-of-the-mill production code. My pet peev is > > performance penalty paid for writing in functional style where it > > actually makes sense -- say passing an arithmetic operator to a map-style > > function. > > What do you mean by this? What language would not incur this kind of > performance hit? Is F# able to optimize this out or were you referring to > something else? It's not much about the language, but about implementation. IIRC some Lisps can do this kind of an optimization, gcc could do it as well -- whenever the value of the argument to a function is known, a potentially call-site-specific version of the function can be generated, and in such cases it'd be much simpler, emitted-code-wise, than the version which explicitly emits the arguments and calls the operator. Cheers, Kuba