

Replacing small C programs with Haskell - chalst
http://blog.ezyang.com/2010/03/replacing-small-c-programs-with-haskell/

======
mark_l_watson
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.

------
darklajid
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)?

~~~
ezyang
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.

~~~
darklajid
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. :)

------
joeyh
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.

~~~
dons
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...](http://stackoverflow.com/questions/6115459/small-haskell-program-
compiled-with-ghc-into-huge-binary)

~~~
ldesegur
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.

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

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

------
anon_d
_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.

~~~
chalst
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.

~~~
anon_d
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.

~~~
chalst
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.

~~~
anon_d

        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.

------
dextorious
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._

