Flying Frog Blog

>When Haskell is pushing trillions (downloads/cash/views/ads) every year - call me. Did you not notice how many banks are on that page? >Source: http://flyingfrogblog.blogspot.ch/ Are you seriously referencing Harrop to support your argument? You do realize he is a troll right? Not like, people disagree with him, an actual, original definition troll. He jumps from language to language as people learn to ignore him, and has gone through trolling every major functional programming language except F#, which is the one he currently says is perfect and ocaml is shit. Before that, ocaml was perfect and haskell was shit. Before that, haskell was perfect and lisp was shit. Google his name, there's literally thousands of messages from him in mailing list archives demonstrating this.

That page has generated some heat in the past: http://flyingfrogblog.blogspot.ch/2010/05/why-is-haskell-used-so-littl… (admittedly this guy seems to have some personal grievances with people in the Haskell community) I don't know how much the page has changed since this rant was written, but some of the entries seem to be the same, e.g. 'Ansemond LLC' which is a company with a single mac app that hasn't been updated since a beta in 2009 and only mentions Haskell in an old blog post. The site for that company is so charmingly dated that I feel kind of bad for highlighting it, but if this is the kind of 'industry success story' they think worth mentioning then I'm not sure the wiki page is of any value.

http://flyingfrogblog.blogspot.com/2009/07/ocaml-vs-f-burrows-wheeler.… Great article about how F# can approach the speed of C with some fancy inlining.

A followup from the same blog from the next day is here: http://flyingfrogblog.blogspot.com/2010/01/naive-parallelism-rebuttal.…

> Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/ I just watched it. Great to see somebody else trying but this is no more advanced than OC4MC and they are using Fibonacci as an example when I already used a complete parallel ray tracer with shared memory when benchmarking parallelised HLVM code: http://flyingfrogblog.blogspot.co.uk/2010/01/naive-parallelism-with-hl… They've got a lot of catching up to do before they can overtake and I'm concerned that retrofitting a modern GC on a 20th century VM will never work because OCaml has such poor locality of reference due to massive unnecessary boxing. > TBH I don't miss multithreading in OCaml, I said multicore, not multithreading. I dot lots of concurrency and parallelism in F# without having to worry about multithreading. > if you write applications which expose some sort of API over a socket that will scale to clusters not just multicore. You're proposing deep copying all of your data structures when multicore programming is all about sharing data between cores using shared caches. If you copy then your identical copies of the data compete for space in a shared cache. > And you can program those kinds of applications quite nicely with Lwt or Async already. Lwt and Async are for concurrent programming. In particular, they are extremely slow. > Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C library at runtime using pure OCaml (and a wrapper…

That page is just sad when compared to C/C++/Java. When Haskell is pushing trillions (downloads/cash/views/ads) every year - call me. Furthermore: > Bad science. The Haskell community generate an unprecedented amount of bad science, setting out to draw the conclusion that Haskell is great and using every trick in the book to make that conclusion seem feasible. In many cases, it requires quite some effort to uncover the truth. For example, Saynte published results for "naively" parallelized ray tracers and concluded that Haskell was the easiest language to parallelize efficiently, requiring only a single line change. This deception was perpetrated by starting with a "serial" version that had already been extensively reworked in order to make it amenable to parallelization and then disabling optimizations only for the competitors (and even adding their compile times in one case!) in order to make Haskell appear competitive. Moreover, that reworking could only have been done on the basis of extensive benchmarking and development. Even the academics publishing Haskell research are up to it. For example, in the recent paper Regular Shape-polymorphic parallel arrays Manuel Chakravarty et al. artificially close the gap between Haskell and C by benchmarking only cache ignorant algorithms (that spend all of their time stalled on unnecessary cache misses), incorrectly states that such algorithms are "widely used", describes the one-line change required to parallelize the C code as…

https://en.wikipedia.org/wiki/Name-dropping For people without an argument. Because then you would have to know what those firms actually do. Read this: http://flyingfrogblog.blogspot.de/2010/05/why-is-haskell-used-so-littl… It's from 2010 so things may be different - but it illustrates that you can't just drop names, you have to do your research.

relatively recent discussions http://www.reddit.com/r/ocaml/comments/fmpl8/i_have_yet_to_learn_a_fun… http://www.reddit.com/r/programming/comments/gd4xq/james_gosling_joins… http://flyingfrogblog.blogspot.com/2011/03/pros-and-cons-of-ocaml.html http://groups.google.com/group/sayeret-lambda/browse_frm/thread/56cd32…

Or http://flyingfrogblog.blogspot.com/2009/03/hlvm-has-been-released.html

I like Haskell, perhaps because of my strong mathematics background. My dilemma is should I spend more time developing my Haskell skills or should I spend some time with the new C++ features, or learning Rust, or just programming in the languages that I am already productive in? When I assess a programming language, one of the questions I ask myself is "How will this programming language help me write correct programs?" In more detail I want a language that helps with four goals related to the ability to produce programs that achieve their specifications: (1) Partial correctness: the program doesn't give wrong answers (2) Total correctness: the program does (1) and doesn't deadlock or get stuck in an infinite loop. It eventually produces a correct answer. (3) The program does (2) within the desired performance bounds specified. (4) The program does (3) while making efficient use of hardware. Haskell definitely helps with (1). Reasoning about the partial correctness of Haskell programs is easier than it is with imperative programming languages. Total correctness is very hard, especially with multi-thread, multi-process, or multi processor programs, but I think that Haskell is helpful here as well. The real problem is that Haskell makes (3) and (4) very difficult to understand. Some of this is that compilers for functional programming languages are magic, making it hard to reason about what they are doing. This is further aggravated by Haskell's non-strictness. A…

Not to be ad hominem, but why do these posts advocating garbage collected languages keep making exaggerated claims? F# certainly is capable of expressing code more succinctly than C++, but 6,000 versus 1,000,000 lines is far beyond what that difference could account for; the code could presumably have been rewritten in much less C++ as well. Nor, in all likelihood, would it "have taken man-decades of work by real experts and cost millions of pounds" to get "better performance"; quite possibly it would to get to near-optimal performance, but compared to F#, it would probably be relatively easy for a skilled C++ developer (and the author does seem to be a skilled F# developer) to get better performance. shared_ptr has issues, and in many respects is significantly inferior to a real garbage counter, but the post downplays the extent to which idiomatic C++ code avoids use of shared_ptr in most circumstances. You can write Java in any language... The claim that scope-based reference counting can keep garbage around for longer than necessary is strictly true but seems absurd to argue with, as the time between end-of-use and end-of-scope is usually rather short. The linked post (http://flyingfrogblog.blogspot.com/2013/10/memory-management-myths-pro… attempts to illustrate this, but uses a completely illogical/pathological example.