Hacker News Reader

Comment by CyberRabbi | Hacker News Reader

A problem with Haskell and with this is that they are inherently only suitable for batch processing. You cannot build interactive systems that have real-time requirements with these languages because how computation is done is not generally under control of the programmer.

People attempt to program interactive systems with Haskell but then they spend most of their time adapting their program to GHC’s particular evaluation strategy. Usually the optimized program ends up convoluted and nothing like how Haskell code should look, additionally still with no guarantees on the run time.

View on HN

It's hard to build systems with hard real-time requirements with GHC Haskell.

The vast majority of systems people build do not have hard real-time requirements. People have built video games, real-time audio, and all sorts of other soft-real-time systems with Haskell

> soft-real-time systems

No they aren’t soft real time systems either, most applications in general a don’t satisfy soft real time requirements.

Most people hack it but hacking it with Haskell requires rewriting your pure functional code into a form that strongly resembles procedural languages like C. This defeats the purpose of a lazy pure functional programming language.

If most applications don't satisfy soft real time requirements either, then maybe those requirements aren't really important for most cases.

There's only one industrial Haskell codebase I've worked on, and although parts of it were very procedural, that was probably less than half the codebase, even including the IO-bound code. Sure it's one way to use the language, but it's certainly not the only one.

> If most applications don't satisfy soft real time requirements either, then maybe those requirements aren't really important for most cases.

Most applications are buggy and crappy. Sure, if you’re churning out minimally passable garbage for a paycheck, then don’t worry about correctness or timing requirements and pray for the best. Cf. Slack desktop client. If you are producing something that necessarily has a higher quality bar then these things matter, e.g. an aircraft control interface. Haskell isn’t up to the challenge (imagine indefinitely waiting without feedback for a long-lived heavily nested thunk to evaluate when you press “land” ouch).

I've worked on a real-time requirements system with GHC Haskell and it's certainly possible!

That is really not true, but I do agree Haskell passes that impression, for the wrong reasons. I'm working hard to fix these misconceptions on HVM, Kind-Lang and related projects!

It is true and it’s not a bug. It’s a feature. It’s an inherent property of the lazy pure functional programming model, not any particular language. I can’t remember where he said this but SPJ himself said that was a design goal of Haskell. In C you must specify both how and where computations take place. In Java you don’t have to worry about the where (because memory allocation is automatic) but you still how to worry about the how. Haskell goes one step further and abstracts both time and space away from the programmer. Touting this as a benefit of the language but then denying the negative consequences is attempting to have your cake and eat it too.

And for the record Java and other garbage collected languages are not generally suitable for interactive applications either. Anyone who has ever waited on a GC pause can attest to that. This is the exact reason Rust exists and why people continue to use C/C++ despite being inconvenient languages to use.

I do disagree with SPJ here, though. On HVM, you can have complete control over how the resources (both space and time) are used in your programs and algorithms. That is why it outputs the memory (space) and rewrites (time) cost of each program you run, and it is so precise you can even make formulas of how much memory and how many rewrites your functions will demand. You can absolutely have tight memory control in HVM, just like in C. Being lazy, high-level, etc. is NOT incompatible with that, I'd argue.

Would you say DOOM is interactive with real-time requirements?

https://github.com/rainbyte/frag

The vast majority of the code in that repository is in the IO monad and uses carefully placed “!” eager evaluation annotations. Both facts only serve to reinforce my point that a programmer must have control over the way in which computations proceed to build interactive applications. Haskell does allow some level of control over this as I said but it ends up not looking like Haskell, it looks like C with funny syntax.

> The vast majority of the code in that repository is in the IO monad and uses carefully placed “!” eager evaluation annotations.

Looking through that repository, I believe we have extremely different definitions of "vast majority."

Nearly everything in Render.hs is in the IO monad. That is a fact, not a subjective opinion. I point out those routines because they are the heart of the application.

Yes, rendering is by definition I/O. That's also one file. You stated:

> The vast majority of the code in that repository is in the IO monad and uses carefully placed “!” eager evaluation annotations.

Do you have anything to back that up?

> Yes, rendering is by definition I/O.

First of all rendering is not by definition I/O except in the trivial sense that all functions take input and produce output. A pure 3D rendering function takes game state as input and produces a list of triangles + attributes to draw as output.

Even if that were true it would only further validate my point.

> Do you have anything to back that up?

Yes, I already showed that Render.hs validates my point.

> The vast majority of the code in that repository is in the IO monad and uses carefully placed “!” eager evaluation annotations.

This is the claim we're talking about. Since you're into facts, not subjective opinions, show some evidence that the vast majority of the code in the repository is in the IO monad and uses carefully placed "!" eager evaluation annotations. Just to be clear, you haven't done that yet. That's a fact, not a subjective opinion.

https://github.com/rainbyte/frag/blob/master/src/Render.hs

https://github.com/rainbyte/frag/blob/master/src/BSP.hs

On every source file:

    {-# LANGUAGE BangPatterns #-}

Here's one more file than you listed without BangPatterns enabled:

https://github.com/rainbyte/frag/blob/master/src/BitSet.hs

https://github.com/rainbyte/frag/blob/master/src/Command.hs

https://github.com/rainbyte/frag/blob/master/src/Curves.hs

BangPatterns is a normal language extension to have enabled, was this used heavily? (hint: it's not enabled on "every source file.") You listed two of 28 files there, I'm assuming to try to show that the vast majority of the code in that repository is in the IO monad? You went from "vast majority" from one file to now two files. I'm looking for objectivity here, as you seem to be into. Let's see some numbers. I think anyone that glances at that repo would need some convincing of your claims.

Render.hs is 211 of 5580 lines of Haskell in the repository, by the way.

Curves.hs may not have BangPatterns but it is heavily in the IO monad. My point is sufficiently supported by the provided evidence, even evidence provided by you, exceptional cases not withstanding. Thank you.

You still haven't shown me any data to back up your assertion, but you're welcome I guess.

Reply on news.ycombinator.com