Show HN: Servasm – Literate web server in x86 assembler

Other than needing to fork for every request, this should be really fast because it uses the efficient sendfile() mechanism in the kernel to handle returning the file and most importantly only implements a bare minimum of support for the protocol. nginx is almost certainly going to be slower because it has to worry about different types of requests, different protocols, IPv4 vs. V6 sockets, CGI, etc...

It's easy to make something fast when you only implement a very small number of features.

Very nice.

However, I wonder who started this trend of bundling "better commented code" with "literate programming" though?

I appreciate the layout and hyperlinks etc - but this really is just a well-structured assembly program laid out in a way that it won't assemble until after it's been through a pre-processor (I'm talking about the program as presented with html/css etc). It's pretty far from "literate programming".

I suppose one could argue that if you manage to simplify the structure of your program to the point that it reads like prose, one has a "literate program". But it's a strange use of the term. The core idea is to have the code be incidental to the commentary, so that, among other things, one would update the commentary whenever one change the program.

Laying out the comments in a funny way doesn't quite do that. I first saw this with the "literate" re-write of coffee script, but perhaps it's older?

Perhaps the difference between "old" literate programming, and this style ("prose programming"?) is similar to the difference between unit testing and TDD, or between TDD and BDD?

I agree that functions are not usually a good one-to-one fit for abstraction.

If they were, we wouldn't need variables, loops, blocks etc. Now you could argue that we don't, we should just write code in lambda calculus -- but we don't do that.

Especially for languages like assembler and C-like languages, it can be very nice to single out smaller sections of code. And while for eg: C, or I suppose a macro assembler, one might be able to in-line a lot of such blocks -- having to stay at the "block-semantic"-level of the host language can make some things pretty hard to communicate to the human reader in a good way.

Ruby might actually be a good candidate for "simple" literate programming, in the sense that one probably could, and perhaps sometimes should, program ruby much like smalltalk -- no method/function longer than five lines or so, except for the most exceptional circumstances.

Even then, I think one would find patterns that would make sense to abstract out of the "function level", or "language level".

At the other end of the spectrum is too much magic, just as with any meta-programming technique, such as proper macros.

I had a most peculiar experience trying to write some (mostly procedural) java with noweb. It was typical intro programming stuff, basically some very simple data structures/algorithms.

It was a very nice fit for literate programming, but not such a good fit for java -- while the literate program read nicely, and was well structured, the mangled java code was unwieldy -- it turned out I'd ended up generating a java program that did what I wanted.

Now, that's not really a problem, we generate assembly programs that are unwieldy all the time -- but the point is it took some discipline and thought to write a literate program that was also readable in it's tangled form.

Only an issue if people are expected to read/modify it in that state, obviously. And they are, as they'll have to debug it at some point ;-)

> I think the code is not incidental

That was a bit tongue-in-cheek -- I meant more in the sense that comments are incidental to code in most programming languages.

> https://github.com/jostylr/literate-programming-lib

Very nice, thank you for sharing.

The non-spam link to download is here: http://download.savannah.gnu.org/releases/pgubook/

My version of literate-programming may have a bit too much possibility of that magic. I agree it can be dangerous and is something that takes good discipline, like any programming technique. But at least there is something to fall back on in terms of the narrative.

On the flip side of the tangled form, I do appreciate the "flattening" of potential functions. Imagine code that uses a lot of functions, scattered about. It can be hard to follow all that, rather a bit like the GOTO of old (better, to be sure, but still hard to follow). With literate programming one can get the conceptual separation of writing in different blocks, but then they get put back together and the flattened version can be read quite easily, one would hope. So I agree that a locally readable tangled form is very important.

I'd be curious to see your example's code, if you are willing to share it.