On 10/27/07, Christopher Smith <[EMAIL PROTECTED]> wrote: > Chuck Esterbrook wrote: > > I have concerns about speed in FP, however, and I see more problems > > that can be more easily cast as OO than FP. > The issue of speed has come up several times in this thread, and frankly > I don't understand why. OCaml programs perform within 10% the > performance of comparable C programs. Even grand daddy LISP with all of > its impurities stands up quite well against C, let alone OO. Sure, some > of the more cutting edge languages haven't been optimized as much, but > even they do very well for a lot of problems. Erlang's model is to > actually encourage the use of C for computationally intensive bits of > the code path and use Erlang for the IO stuff, which seems to work out > well for those who employ it. What exactly is the basis for this concern? > > --Chris
The basis is this: I was reading up on FP. I encountered the quicksort algorithm in FP and thought it was just great! Compared to the imperative version, it really looked like the algorithm itself. Wonderful stuff. Then I read that it was 2 - 4 X slower. I believe the language was ML, but it may have been Haskell. This seems to be a theme with languages btw. Smalltalk, Ruby and Python: Nice languages and really slow. C++ and Java: Not so nice languages and pretty fast. Also, imperative OO languages are still thinly disguised assembly language in my opinion (particularly in the case of C++ and even with Java to a great extent). While this causes us to miss out on the benefits of FP, it also means you can write screaming fast code as there is not much of a mismatch between your programming model and the hardware. For those that say you don't really need speed because (insert reason), I say yes and no. When I'm building a corporate intranet, Python could be twice as slow and it still wouldn't impact me. However, when I'm doing financial analysis and/or genetic programming, Python is just awful. Before you tell me that I could just use 90% Python and 10% C, some programs don't break down like that. Sometimes you need the speed throughout. Especially after a few rounds of improving performance based on profiling, you can end up with a pretty flat profile where CPU cycles are more evenly distributed among your methods. If at that point, you've got your speed then great. If you don't, you're screwed out of that language unless you get cook up an algorithmic breakthrough. I think there is a better middle ground where you could capture most of the nice stuff and most of the speed for a better balanced language. You seem to be claiming that OCaml and LISP are already there. I respect and enjoy LISP for its purity, but don't find it palatable for project work. I haven't checked out OCaml yet... -Chuck -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
