On 3-7-2012 6:40, Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> OCaml (and F#) look to be much more promising in the realm of writing
>> production systems de novo. Haskell isn't deterministic in its return
>> time (it's Lazy so it may come back in 5 secs or may take 5 hours - and
>> you cant really predict up front which - this is fatal for use in eg
>> pricing libraries)"

Wow, just wow. Let me rephrase: 'you should never use a sorting 
algorithm because the runtime depends on the input'.

>> You heard it here folks - Haskell "isn't deterministic". :-D

Deterministic is not the right word, he meant unpredictable. And even 
that is wrong (see also Andrews reply). I know of only one language that 
is unpredictable and that is Dijkstra's guarded command language. OTOH I 
don't know if anybody ever made an implementation of that.

>> While obviously this statement is false (you /can/ predict run-time,
>> it's just harder than you might imagine), the assertion that "this is
>> fatal" is probably bang-on.
>
>    I don't understand at which point Haskell decides to stop laziness and
> start actually computing results. It cannot be lazy forever because it
> would just run out of memory sooner or later (probably even with algorithms
> that would normally require O(1) memory in an imperative language).

No. Although you could write a program that needs an infinite amount of 
space. Such a program would make as much sense as a program in an 
imperative language that has an infinite loop.

Laziness basically means that you don't start computing things when you 
don't know if you are ever going to need the result. It is just the way 
you traverse your statespace in search of a solution. If we cut some 
corners we might say that it is a depth first search. So it is going to 
work on a branch if the branch on the left (or the right for Hebrew and 
Arabic speaking persons) is exhausted. For every specification and every 
input there might be another way of going through your statespace that 
is faster for that particular problem. But that is not the point. If you 
know the optimal strategy you can always force Haskell to use that. Yet, 
if you don't know the answer it is in general a good strategy (if you 
are running on a single thread machine).


-- 
tip: do not run in an unknown place when it is too dark to see the 
floor, unless you prefer to not use uppercase.

Post a reply to this message