Re: [Caml-list] Re: Why OCaml sucks

[Kuba Ober <ober.14@osu.edu>]

On Friday 09 May 2008, Ulf Wiger (TN/EAB) wrote:
> Jon Harrop skrev:
> > On Friday 09 May 2008 14:00:52 you wrote:
> >> Jon Harrop skrev:
> >>> . Parallelism is for performance and performance
> >>>
> >>  >   requires mutable data structures.
> >>
> >> I disagree. SMP Erlang has no mutable data structures,
> >> but achieves very good scalability anyway.
> >
> > Scalability != performance. For CPU intensive tasks,
> >
>  > Erlang is uniformly slow.
>
> I don't see how you can say that. If you introduce the
> restriction that there can be only one CPU, then this
> might be true. Some applications are very difficult to
> scale to multiple CPUs, but others are inherently
> scalable. For some problems, mutable data structures
> make all the difference, and in others, they just make
> a mess of things.
>
> If you say "parallelism is for performance", you imply
> that the program is scalable, and that it actually makes
> a difference to add more CPUs. In this case, mutable
> the presence of data structures will make scaling more
> difficult. Most problems involved in utilizing multicore
> boil down to the widespread use of mutable data structures.
>
> If the problem isn't scalable, then other tricks are needed
> to achieve performance, and mutable data structures may
> be indispensable.

I think people forget Jon's background/interests: numerical methods.
Think of working with large amounts of numbers, where the cost of some 
operations is on par with copying a few words of memory, and good 
non-algorithmic (!) optimizations can increase performance 10-fold (see 
Mersenne project, for example). Moreover, a lot of numerical methods are 
applied in real-time applications, and there a 50% loss in performance simply 
means that the game becomes unplayable, or that the phone connection sounds 
like excrement dropping into the hole. For web applications (generally 
speaking), a 50% loss of performance means you pay 2x more money for servers 
and power. Up to a certain point, this is small compared to the costs of 
maintaining the software. Where numerical methods are widely applied, a 50% 
performance loss may mean you're out of the market.

I'm no F# fanboy; I use Ocaml exclusively for most of my numerical work (some 
FEM, all numerical methods courses I take), but as a language for packaged 
application development (bread-and-butter stuff that sells in boxes or via 
downloads) it's simply not there yet for me. F# would be more like it, if I 
weren't wary of .net platform lock-in. Give Mono a few more years and it 
won't be an issue anymore...

For server-side use Ocaml is probably fine, but so is a number of languages 
that for me pack way more punch (Lisp, for one). In any event, these days I 
see little reason to develop web-facing stuff on non-google platforms (at 
least if you're a startup), so I'm in Python lock-in in that area anyway now.

Cheers, Kuba