sutton037

Guido van Rossum, the celebrity programmer responsible for the Python programming language, published a horribly misinformed blog post last week that was meant to explain why tail calls are "unpythonic" and do not deserve a place in the Python language. Given the simplicity of the subject matter and the widespread availability of accurate information from experts like Will Clinger , it seems remarkable that anyone would still be confused about tail calls. Although the presence or absence of tail calls in Python is unimportant, this is still serious because Python is the new BASIC and, consequently, Guido is abusing his celebrity status by misguiding a huge number of young programmers. Indeed, this is very visible on the ensuing Reddit discussions where the majority of comments are factually incorrect. Definitions A tail call is a call that appears as the last thing a function does before it returns. In functional languages, this means the caller is returning the result of ...

Mike Hendrickson has been busy updating O'Reilly's analysis of the state of the computer book market by programming language. That means it is time for us to reiterate how authors of decent books can earn far more for their work by cutting out the middlemen including trade publishers like O'Reilly. Traditional book publishers are a dying breed. Aside from e-books, they have been driven out by an increasing number of so-called "self-published" books. In the context of software development, this is particularly common around non-mainstream subjects and includes titles such as OCaml for Scientists and Programming in Scala . O'Reilly's analysis excluded all such books even though they are far more profitable for authors. In order to make a case for self-publishing it is necessary to present some information about a variety of existing books: OCaml for Scientists was written and self-published in 2005 and is sold for £85 through the publisher's website....

Sadek Drobi has interviewed many interesting people in the past and his interviews are of particular interest because Sadek is not afraid to ask difficult questions. Sadek recently published an interview with Don Syme, a lead developer of .NET generics and F#. In particular, Sadek asks why the experiments at Microsoft Research in writing SML and Haskell implementations on top of .NET led Don to build an eager language rather than a non-strict language like Haskell. Don describes the "dissonance" between non-strict evaluation and .NET that culminates in excessive use of monads making it unnecessarily tedious to reuse the framework, as well as the efficiency and debugging problems imposed by non-strict evaluation. Don then goes on to discuss some of the other features of Haskell that F# does draw upon, such as type classes. In particular, Don explains how he carefully separated the proven foundations of such features, such as the use of type classes for overloading as they we...

A dutch startup called Tupil just announced that their first commercial application written in Haskell has gone live. Tupil describe themselves as: Tupil is Chris Eidhof and Eelco Lempsink . We code for a living, using functional programming languages like Haskell. Technology is our passion and we just love building great software tools. After working for years as web developers at very nice companies, we decided to go solo, together. Credible success stories of bleeding-edge functional languages like Haskell being used in industry are always great to see. Keep up the good work!

We recently proved that Haskell's defacto-standard hash table implementation is extremely slow. So slow that optimized native-code compiled Haskell is even slower than interpreted Python and 32× slower than a decent hash table implementation! If that result were not remarkable enough, we have now discovered that the history of this issue is even more surprising... Haskell programmers have been complaining about the poor performance of its hash table implementation for at least 3 years . The cause of the problem, a bug in the garbage collector, was identified a long time ago but that bug was never fixed. Instead, it appears that the Haskell developers went on a crusade to persuade the world that decent hash table implementations are not advantageous. For example, the book "Real World Haskell" by Don Stewart et al. explicitly states : "Compared to a hash table, a well-implemented purely functional tree data structure will perform competitively. You should not approach...

Peter Verswyvelen of Nazooka , one of the only industrial users of Haskell, uncovered another serious bug in GHC, the defacto-standard Haskell compiler. The bug afflicts floating point arithmetic in external libraries such as Qt, GTK, OpenGL, BLAS, LAPACK and FFTW on x86. Peter said "It's insane this bug did not cause any more problems. Every call into every C function that uses floating point could have been affected". Given that this bug had gone unnoticed for so long, the only logical conclusion is that the GHC FFI is immature because it has very few users. This concurs with our previous findings that no mature software has ever been written in Haskell. Moreover, this bug joins the list of serious FFI-related bugs in GHC along with the subtle FFI bug in GHC that helped to destroy Darcs and a memory alignment bug in GHC's FFI that caused segmentation faults. Suffice to say, the moral of this story is that even the most advanced high-level programming language impl...

I just stumbled upon an interesting benchmark. Put mappings i -> i for i in 1..10M in a hash table, print the entry for 100. Don Stewart's optimized Haskell: import Control.Monad import qualified Data.HashTable as H main = do m forM_ [1..10000000] $ \n -> H.insert m n n v print v My OCaml translation: let n = 10000000 let () = let m = Hashtbl.create n in for n=1 to n do Hashtbl.add m n n done; Printf.printf "%d\n%!" (Hashtbl.find m 100) My F# translation: do let m = System.Collections.Generic.Dictionary() for i = 1 to 10000000 do m.[i] printf "%d\n" m.[100] Performance: Haskell: 22.8s OCaml: 2.82s F#: 0.706s I found it remarkable that the performance difference is so large: F# is 32× faster than the optimized Haskell here! Thanks to everyone who has replied. Apparently this is a fundamental design flaw in GHC's garbage collector which is incapable of handling the mutation of arrays of boxed values (e.g. ha...