Re: [Haskell-cafe] Re: Interesting critique of OCaml
On 9 May 2008, at 6:59 am, Donnie Jones wrote: I pasted a copy of the article below for those that cannot access the site.Why Ocaml Sucks Published by Brian at 6:49 pm under Functional Languages: Ocaml, Haskell . An even better idea [for 'printf'] might be some variant of functional unparsing. There's a link to http://www.brics.dk/RS/98/12/. I spent a bit of time last week playing with the code in that paper. Some of the basic ideas are nice; the idea that 'formats' are functions and concatenation of formats is composition of functions was particularly nice. But seeing it with Haskell eyes, the idea of building strings up using cascades of (basically) \s x - s ++ f x, where s is a byte string, not a list, and ++ is concatenation of byte strings, seemed obviously wrong. I replaced it by \sl x - f x : sl, with the final step (in an already existing interface function) being to reverse all the stringlet and concatenate them in one big step. I was gratified, but the very reverse of surprised, to get a substantial speedup. (A factor of over 100 for a small but non- trivial test, using SML/NJ.) In effect, thinking in terms of shows paid off handsomely. Haskell-think wins again! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Interesting critique of OCaml
Don Stewart dons at galois.com writes: [interesting quote...] Which I think really captures the joy of being able to write algebraic and data structure transformations, via rewrite rules, without having to extend the compiler -- all thanks to purity, laziness, and static typing. This makes me wonder... Rewrite rules are certainly effective, and seem to be a good place to point (one of many, of course) when asked why you'd want a language with Haskell's characteristics. It seems like there should be an argument to this effect: 1. You'd like be able to declare compile-time transformations like map f . map g = map (f . g) without messing with the compiler 2. For x in [purity, laziness, static typing, higher-order functions] If you don't have x, here's what goes wrong (or can go wrong) 3. Of the very few languages with these characteristics, Haskell is the most widely-used, and the most actively developed and researched. Now, I don't know much about lisp, but aren't code transformations like this the whole point of macros? What makes is difficult to do the same thing in this context? What about object-oriented languages? The problem with step 1 in the argument is that it's already cast in a functional-programming framework. Is there a way to recast it so OOP could play? Thanks, Chad PS - the link now gives a 500 server error - did our traffic overwhelm it? Is the cafe the next slashdot? ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Interesting critique of OCaml
Chad Scherrer [EMAIL PROTECTED] wrote: Don Stewart dons at galois.com writes: [Stuff where I totally agree] Now, I don't know much about lisp, but aren't code transformations like this the whole point of macros? What makes is difficult to do the same thing in this context? Proof of correctness, or even a graspable notion of correctness for the whole semantics of the language. If you consider that hygienic macros (that is, macros that don't make a mess of every concept you have of namespace) were introduced quite late, you might get a grasp on how bravely and hackish they were designed. What about object-oriented languages? The problem with step 1 in the argument is that it's already cast in a functional-programming framework. Is there a way to recast it so OOP could play? Yes, I suppose so, but you'll be left with Haskell with an OOP Syntax, and a style of OOP that uses Objects mainly as closures, which isn't a thing OOP coders regularly, or at all, do, to get the granularity of replacements that is necessary to consider them useful in the first run. Some years or decades ahead, perhaps Haskell will not be able to avoid being successful anymore, and that is the time where you'll see things that look like Java, feel like Java, work like Java, but still use a Haskell RTS. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interesting critique of OCaml
Achim Schneider wrote: Some years or decades ahead, perhaps Haskell will not be able to avoid being successful anymore, and that is the time where you'll see things that look like Java, feel like Java, work like Java, but still use a Haskell RTS. I'm told they're calling it F#... [No, I can't verify the truth of that claim. But every time I mention Haskell, everybody goes Haskell is obsolete. Everybody who even *wants* functional programming in the first place will just use F# instead. The end.] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interesting critique of OCaml
Chad Scherrer wrote: PS - the link now gives a 500 server error - did our traffic overwhelm it? Is the cafe the next slashdot? ;) Hell, I can't even get a TCP SYN-ACK packet out of it... :-/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interesting critique of OCaml
Hello, I pasted a copy of the article below for those that cannot access the site. I would be interested to see an article on Haskell in the same light as this Ocaml article, aka a constructive criticism of Haskell. Enjoy! __ Donnie ### Begin Article ### Why Ocaml Suckshttp://enfranchisedmind.com/blog/2008/05/07/why-ocaml-sucks/ Published by Brian http://enfranchisedmind.com/blog/author/bhurt-aw/ at 6:49 pm under Functional Languages: Ocaml, Haskellhttp://enfranchisedmind.com/blog/categories/programming/functional-programming/ One of the ways to not fall into the blub fallacy is to regularly consider those ways in which your favorite language is inferior, and could be improved- preferrably radically improved. Now, it should come as a surprise to no one that my favorite language is (currently) Ocaml. So as an intellectual exercise I want to list at least some of the ways that Ocaml falls short as a language. I will note that if you use this post as a reason to *not* use Ocaml, you are a fool and are missing the point of this post. With the *possible*exception of Haskell, no other language I know of comes close to getting all the things right that Ocaml gets right. So, with that in mind, let's begin. 1. Lack of Parallelism In case you haven't guessed it from reading this blog, I think parallelism is going to be the big problem for the next decade. And while Ocaml does have threads, it also has a big ol' global interpreter lock, so that only one thread can be executing Ocaml code at a time. Which severely limits the utility of threads, and severely limits the ability of Ocaml programmers to take advantage of multiple cores. Now, to give the INRIA team credit, the reason they have for this is a good one- we (programmers) still don't know for sure how to write multithreaded code safely (I have my suspicions, but I have no proof), and we had even less of an idea a decade and a half ago when the fundamentals of Ocaml were being decided. And supporting multithreaded code slows down the garbage collector. And, a decade and a half ago, multithreaded code was a lot less important, and multicore systems were rare and expensive. So this is mainly just Ocaml showing it's age. But still, if I were to pick the biggest shortcomming of Ocaml, this would be it. 2. Printf You know what? Printf was a bad idea for C- having this special domain-specific language in what looks like strings to control formatting. It's even worse in Ocaml, where you have to add special kludges to the compiler to support it (at least the way Ocaml did it- there are smarter ways http://www.brics.dk/RS/98/12/ that don't require compiler kludges). You might think that %3d is a string in Ocaml, and sometimes you'd be right. But sometimes it's a (int - '_a, '_b, '_c, '_a) format4. This horrid type (which is *not* a string) is necessary to encode the types of the arguments printf needs to be passed it. The one thing I know of that C++ did better than Ocaml was ditching printf. And the idea of iostreams even isn't that bad- except for the fact that they encouraged generations of C++ programmers to abuse operator overloading (hint to Bjarne Stroustrup: and are not the I/O operators, they're the bit shift operators!), and they made the iostream classes exceptionally difficult to inherit from or extend. But a combination of C++ style iostream operators and Java style iostream classes would have worked so much better, and not required hacking the compiler. An even better idea might be some variant of functional unparsinghttp://www.brics.dk/RS/98/12/ . 3. Lack of multi-file modules Ocaml has an exceptionally powerfull and flexible module and functor system, which stops rather annoyingly at the file level. Files are modules, and files (and modules) can contain other modules within them, but you can't collect several files into one big multi-file module. You especially can't say that certain files, while they may be visible to other modules within the multi-file module, aren't visible outside the multi-file module. This is especially useful if you want to factor out common base functionality from a library of modules into a shared module, but not productize it for export to the outside world. This limits the ability of the programmers to correctly structure large projects. The -for-pack arguments help fix a lot of this, sorta- but they require smarts in the build system and generally special .mli files to control visibility. It can be done, but it's not clean- it makes the build process a lot more complex, and important information about which files are externally visible or not is contained somewhere that is not in the source code. This could certainly be done a hell of a lot better than it is. 4. Mutable data Mutable data is both a blessing and a curse. It is a blessing when
Re: [Haskell-cafe] Re: Interesting critique of OCaml
2008/5/8 Donnie Jones [EMAIL PROTECTED]: I would be interested to see an article on Haskell in the same light as this Ocaml article, aka a constructive criticism of Haskell. http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/ -- Darrin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
