Replacing small C programs with Haskell | Hacker News Reader

Replacing small C programs with Haskell

blog.ezyang.com

65 pointschalst19 comments

Several years ago I started doing the same thing except that I used Gambit/C Scheme: small fast executables written in a convenient to use programming language.

I have been programming since the mid-1960s and in retrospect the only C/C++ code I have written that really needed to be written in C/C++ were games for Nintendo and for the PC.

I'd like to understand a little more about the technical requirements here. 'Running with different credentials than the webserver' sure could've been solved with a fastcgi/wsgi setup and a decent way for expiration/monitoring of these processes (which the author admits failing to get his head around at the time of the implementation/writing of the blog post).

As soon as you remove the startup time from the equation (by stopping to spawn a tool per request) the result is really just IO (writing a couple headers, serving a file) which _should_ perform quite similar in most applicable languages.

While I'd like to see more (practical) Haskell content, this seems to be a lot of reinvention (see for example the mime-table commits). Whatever the language ended up being, was there no way to solve that issue more easily (and arguably, cleaner)?

The code is pretty basic, and one can guess many of the requirements from it:

http://andersk.mit.edu/gitweb/scripts-static-cat.git/blob_pl...

The alternative to reinvention is usually borrowing other people's code, and it's often not clear that this will increase confidence in the correctness of the code.

What I take from this post is a reminder that efficiency worries need not deter one from using languages like Haskell for this kind of task, despite the widespread belief that "CGI programs have to be small". The example would be that bit more compelling if the authors had used Quick Check to partly specify the code.

We understand the tuning parameters for these processes a bit more since this post was written a year and a half ago (We hit a magic phase shift for our other FastCGI processes, at which point our servers started falling over from 4000 users worth of FastCGIs. "Good thing we didn't listen to Geoffrey when he suggested we run an Apache for each user.")

FastCGI static-cat should work (indeed, one of the original design intents was making this switch easy, if we decided to do it). But I disagree that language becomes irrelevant in this case: you still care about memory usage (since this will influence how many users you can support) and loading an entire interpreter can be pretty costly. I do agree that IO should be essentially comparable.

As for the reinvention, all of these features are what you would normally find in Apache. But Apache is a large, complicated piece of software, and we don't want it to have access to arbitrary user files if it is compromised.

Thanks a lot. Of course you'll have done your homework, I just had the immediate 'Hmm.. Most of this exists already' reaction.

Interpreter: Sure. I've no clue how many concurrent users you have (or is that the 4000 above?) - at some point that becomes a good point again.

Anyway: Thanks a lot, appreciated the feedback directly from the source. :)

did you ever figure out why upx had such a large performance penalty?

Same here. I must be missing something big here because none of this makes sense. Its reinvention for the sake of it.

There's more information at http://scripts.mit.edu/wiki/Technical_overview_of_scripts.mi...

I'm doing this too.. The multimegabyte size of the haskell executables is the only drawback.

Well, and some portability issues if you want your code to be usable everywhere, since ghc is not bootstrapped on every artchitecture.

Use dynamic linking and object stripping, if space is a concern. You'll have tiny objects then.

http://stackoverflow.com/questions/6115459/small-haskell-pro...

I tried Haskell but it doesn't cut it for me. So I switched to Go and have been very happy so far. I dig channels and co-routines. Type inference is great. I still wish some generics would happen in 2012. The lib is great for doing what C libs do in a more readable way.

Debian (and thus Ubuntu I assume) still uses static linking of haskell. I hope this will change though. I think the issue is finding a way to avoid breaking binaries when haskell libraries are upgraded, since they don't have sonames like regular libraries do.

Another good replacement for C might be the D programming language:

http://en.wikipedia.org/wiki/D_(programming_language)

As such, it's critically important that the program is concise and well-defined; both properties that are quite hard to get in C code.

This is baseless FUD.

I do think that it is easier to acquire confidence that well-written Haskell is correct than well-written C, and there is some evidence supporting this belief. There's room to argue this, but it is very far from baseless FUD.

For an example of the kind of techniques available to Haskell but not to C, check out:

http://www.andres-loeh.de/Contracts.html

Some correctness infrastructure, such as Quick Check, have proven themselves to be eminently practicable.

It is perhaps also true that it is easier to write Haskell well than to write C well: certainly there is no shortage of awful C coding out there.

I love me some ML/Haskell, but the article is about small C programs. Small utility programs is the domain where C shines. C is dead-simple, ubiquitous, and fast. Just the tool-complexity of Haskell alone makes C the better choice for these kinds of programs.

Over the last several years, I've experimented with rewriting some of my small C programs in Haskell or ML, and vis-versa. Amazingly, the C programs often end up being shorter, simpler, and significantly less headache (for these small programs). I am very comfortable coding in all three languages, so I think I'm pretty unbiased.

Reading the code from the article, the Haskell code is much better written than the C code. I think the author is making a mistake in thinking the better code is a result of the merits of Haskell w.r.t C instead of just the result of the clean rewrite plus being more experienced with Haskell.

I don't know whether Haskell or C is best for these kind of programs, but I have three considerations:

1. You seem to presume that good C programmers can be confident that their short, simple C programs are correct. The anecdotal figure I follow for error incidence is an error per 1000 lines of code, for code written by and check by professional programmers. In this 600 loc program, that's over a 50% chance of error at the end of the auditing process; the authors are worried about security, which makes looking for alternative sources of reassurance make sense.

2. Being comfortable coding in two languages doesn't mean that the set of problem-solving idioms you have for the two languages are equivalent. IO code in Haskell is indubitably more complex than in C, and has some particularly sharp edges, but the price tag in terms of code complexity does not map into a similar price tag in terms of code-comprehension complexity: the complexity arises from disciplines that, when married to the use of good IO idioms, make it easier to reason about the code.

3. Reading the code from the article, the Haskell code is much better written than the C code -- This does suggest that the author is right to use Haskell in cases where you would use C, since you have different skill sets.

    I think it's silly to continue this without using (better) concrete
    examples, but I'm don't think it'd be worth the effort.

    >> [Author is better at Haskell than C].
    > This does suggest that the author is right to use Haskell [...].

    Certainly.

LOL comment in the article thread by (of course) "Anonymous":

should have done it in asm. time coding is greater but time savings in performance of program over long term makes up for it. but i guess asm is too difficult for you. visual basic is good for programmers who like “easy” job.

Reply on news.ycombinator.com