Hacker News Reader

This is really neat, but I am very wary of building kernel modules with garbage collected languages especially ones like Haskell, which can has very difficult to reason about runtime characteristics due to laziness.

This is FUD, repeated ad nauseum all over the internet as a misinterpretation of what Simon Peyton Jones said once during a talk. In case you hadn't noticed, there appears to be a tradition in programmer circles of picking SPJ quotes and turning them into memes. "Haskell is useless!" and "Avoid success at all costs!" are some others.

The reality is far less extreme than most people think. It is not at all unreasonable to write low-level code such as device drivers in Haskell. This has actually been done as part of the HaLVM project.

> This is FUD, repeated ad nauseum all over the internet as a misinterpretation of what Simon Peyton Jones said once during a talk. In case you hadn't noticed, there appears to be a tradition in programmer circles of picking SPJ quotes and turning them into memes. "Haskell is useless!" and "Avoid success at all costs!" are some others.

I think you have this backwards. People have been saying that laziness has unpredictable performance characteristics (especially when it comes to space usage) as long as there have been lazy functional languages. SPJ was referring to that common sentiment; it didn't somehow materialize because of comment he made during a talk.

There was an era where space complexity and space usage semantics were a big deal in functional programming, e.g. the work on giving a precise definition of "tail call optimization" and the emphasis on space safety that has since been present in the strict functional programming world. In contrast, there is no standard space semantics for lazy languages, and certainly none that GHC respects. It's tricky when simple CSE can dramatically alter the space complexity of your program, e.g.

https://ghc.haskell.org/trac/ghc/ticket/947 https://ghc.haskell.org/trac/ghc/ticket/1752

I didn't say there wasn't any difficulty, I said it was FUD. It is true that there is more mental overhead in reasoning about space usage in a lazy language. It is not true that this is unpredictable. If that were the case, it would be a complete crapshoot for people to write code in a lazy language. Luckily, a basic understanding of Haskell's evaluation model gives one the ability to predict space usage and know reliably what sort of anti-patterns to avoid (such as the infamous lazy foldl).

The problem with FUD is that it takes reasonable statements and exaggerates them to an unreasonable degree. People repeat the word "difficult", eventually someone starts using "very difficult", sooner or later people start throwing around "impossible".

It's not just the evaluation model; you have to know whether the compiler will perform transformations behind your back that increase space usage. If you were to impose a space semantics on the compiler and require that it preserve the semantics, a lot of optimizations would have to be disabled for lazy expressions.

It's not surprising that people manage to produce lots of working programs despite this, though. Almost all life-critical software is written in completely unsafe languages.

the compiler will perform transformations behind your back that increase space usage

This is not exclusive to Haskell; even C compilers will do this with jump tables and so on.

Jump tables don't increase asymptotic space complexity, whereas some of GHC's optimizations will. You can also see how much jump tables increased the space usage of your program by inspecting the size of the compiled binary.

I'm not proficient in Haskell, just a bystander, but this isn't the sentiment I get from reading Neil Mitchell's posts on the subject:

http://queue.acm.org/detail.cfm?id=2538488

http://neilmitchell.blogspot.com/2013/02/chasing-space-leak-...

He appears to use profiling tools and "try them all and see which produces the most useful information", to me that sounds very different from reasoning.

Try this:

http://blog.ezyang.com/2011/05/anatomy-of-a-thunk-leak/

and particularly this:

http://blog.ezyang.com/2011/05/an-insufficiently-lazy-map/

One point I'd like to mention: just because it seems complex and intimidating for beginners/outsiders does not mean it is intractable for experienced programmers.

SPJ is a fool for making those 'clever' statements like "Haskell is useless!", because most people won't stick around to hear the twist explanation.

The explanation of this particular quote is like 5 minutes long on YouTube. If you don't spend that much time to listen to an argument, it's unlikely that you have a well founded opinion on programming languages anyway.

I don't think at the time he was trying to be clever. If you watch the talk you'll see it makes a lot of sense to make this statement in its context. Also - Haskell will either be very popular or not, based on its merits in industry. I doubt the fallout from these type of statements will amount to much in the long run.

I think you have it backwards. If someone forms opinions on languages based on out of context quotations then they are the fool, not SPJ.

Galois are doing lots of interesting things in this space, including HaLVM, which allows you to write Haskell programs that run without an OS [1]

[1] http://corp.galois.com/halvm

Absolutely! I am very interested by their approach in this area because integration with existing infrastructure is essential for practical work in this area, but reasoning about existing infrastructure is a lot harder than it needs to be.

This is a relatively old presentation of theirs, but it has a decent overview of what they have used Haskell for. http://www.cse.chalmers.se/edu/year/2010/course/TDA555/Mater...

But if you generate C code from Haskell, don't you have the same problem as before that it's difficult to reason about runtime characteristics due to laziness?

Not really. Haskell is basically used as a compiler from a DSL to C. Compilers running on general purpose systems are much less sensitive to timing and memory use than embedded systems and kernel drivers, so it isn't that big of a deal. The generated C code is the only thing that executes on the target device so you get the same performance that you would expect from C code.

The emitted code need not be lazy, and most often isn't. To a lesser extent the EDSL technique is also the technique that Accelerate uses to build fast array computations.

[1]: https://speakerdeck.com/mchakravarty/embedded-languages-for-...

> This is really neat, but I am very wary of building kernel modules with garbage collected languages

Native Oberon, Spin, Singularity, ...