... starting with C is designed to produce meaningless results in order to look good on toy benchmarks. SML is one of the few exceptions. As a case in point, the corresponding SML code raises an exception: Standard ML of New Jersey v110.66 [built: Thu Nov 15 12:22:47 2007] - Real.compare ; [autoloading] [library $SMLNJ-BASIS/basis.cm is stable] [autoloading done] val it = fn : real * ...
Jon Harrop wrote: Very well. All I can say is that finding industrial uses and users of OCaml and F# has been much easier. Perhaps Haskell users have better taste in consultants? (No offense to *ML users, except the ones with poor taste in consultants.)
... can prevent programmers from being able to screw up in certain ways, like buffer over-runs. Vesa was saying that IO in Haskell can be very slow unless you use unsafe language features. Like MLs, Haskell strives to be a "safe" language but what is the value of that if you're forced to resort to unsafe methods for practically essential features like IO? OCaml has similar problems with its ...
...see what comes out of it in the coming years. C# is doing good things for many ordinary software developers in industry but F# is definitely the gold standard when it comes to many things that ML can be good at. I am interested in the asynchronous workflows in F# and how they draw upon Erlang but they are of little benefit to me: data parallel libraries are much more useful here and I...
Jon Harrop skrev: Ulf Wiger wrote: > Your experience with ML sounds depressing, which seems ironic, > considering how much you've bragged about it in various > forums. I'm not sure I get it. My experience is far from depressing. I have found these languages to be enormously productive for a wide range of tasks. So much so that Microsoft picked up the ball and are now...
...users are in fact using it commercially. Erlang is younger than ML, but older than Haskell. Perhaps "modern" is a ... excellent interop. We can fix this by writing a new ML implementation that offers the most valuable features without the baggage ... error-correcting HTML parsers, etc. Right. Your experience with ML sounds depressing, which seems ironic, considering how much you'...
... in Erlang, and most Erlang users are in fact using it commercially. Erlang is younger than ML, but older than Haskell. Perhaps "modern" is a euphemism for "based on the H-M ...for very special components, like BGP routing stacks, error-correcting HTML parsers, etc. Your experience with ML sounds depressing, which seems ironic, considering how much you've bragged about it in various forums....
...> Dylan is a mostly functional language. It was inspired by LISP. True. Should have said ML... Functional languages often make it easy to stack overflow instead, This depends on the implementation...I am one of the only people in the world trying to write mainstream commercial software in ML and I'm telling you that what we have is inadequate: you cannot compile and distribute ...
... in this case I'm talkin about structural ambiguity that can lead the unwary to make errors. Haskell has very similar rules, in its non-indented syntax option, but resolves it with non-optional begin/end braces, in I believe every possible case. Your optional match with ... end might serve the same, as would parentheses around (match with ...), but to get rid of the ambiguity you have to...
Jon Harrop <usenet@jdh30.plus.com> writes: Another alternative would be to persuade Apple that they should also innovate in the direction of ML. Why Apple? If you are thinking that anything with an Apple stamp will immediately take over the world, forget it. Look at what happened (or, rather, didn't happen) with Dylan, which AFAIK has been Apple's only serious effort in ...
