No, seriously, why? As far as I can tell, his entire argument is "web development in C is terrible and limiting, but not as quite as terrible and limiting as you might think." I guess that's good news if terrorists are forcing you to write websites in C, but I don't see even an attempt at explaining why you would choose to do this.
1) Whatever language you are most proficient in, that is often the most efficient tool for _you_ to get the job done right.
2) PHP is largely C for people who should never program in C (or PHP ;-). Depending on the nature of what you are doing, and if you use some basic support libraries (and the author mentions a few), your code needn't be that much more work to get done than any other language. In reality, it's not the typing in the code that tends to matter anyway.
3) If you are, for whatever reason, interfacing with a lot of systems components or C API's, there can often be a pretty big win using C as you avoid all the pain of language impedance mismatch.
4) Depending on what it is measured against and the nature of the problem, C can often be significantly more efficient, not just in terms of CPU, but the all important memory consumption these days. Depending on the problem, that can be highly highly relevant.
5) Portability. Okay, you can stop laughing now. ;-) Seriously though, if you talk to mobile game developers who've tried it, C and C++ tend to be the best languages for targeting a plethora of platforms. That goes double or triple for embedded systems. It's really not that hard these days to have very portable C/C++ code, and platforms that insist on making C a second class citizen tend to do themselves more harm than good (even Android ultimately relented).
Now, that's not to say that I think everyone should be doing their web projects in C, but depending on the context (the problem, the available tools, and the parties involved), it might well be a good choice.
There exists a form of survivalist mindset in some programmers. It goes roughly like this: if you can't boot it, it's fluff programming.
The attraction of C to this mindset is that it can be transliterated (vs translated) into machine code. This transliteration is so straight forward that if you know C and are familiar with the basics of the instruction set you can do it by hand.
The survivalist mindset fears dependence. VMs and interpreters are the essence of dependence. So those with this mindset always seek find a way to do it in plain C when they can.
> The attraction of C to this mindset is that it can be transliterated (vs translated) into machine code. This transliteration is so straight forward that if you know C and are familiar with the basics of the instruction set you can do it by hand.
Except modern processor architectures are no longer a one-to-one correspondence between Assembly code and C.
There has never been a one-to-one mapping (rather one-to-many), but it's still perfectly possible to transform C into assembly by hand. It's not even that difficult.
Yes, back in the old 8 and 16 bit days, it was pretty much one-to-one for most use cases.
Nowadays not any longer if you want to write code that takes advantage of branch prediction, speculative execution, cache lines, vector units, GPGPU ...
Just watch this Going Native talk on how sometimes generating code that is 4x bigger than the direct translation can yield up to 30% performance increase.
Auto vectorization can be impressive, but it applies to hard numerical code, not so much in regular code bases. I regularly debug assembly in my job, and in the vast majority of cases it's a fairly straightforward translation of the C/C++ code. Stuff like cache locality or using the GPU is still determined by the C code.
I'll concede there's more fine variations to think about than with an 8-bit system, though, with the padding, etc.
> VMs and interpreters are the essence of dependence.
I find that an odd perspective. If you can rewrite your VM/interpreter from scratch, are you really dependent on it?
I guess I see it less as "use some black-box language runtime to solve this problem" and more as "I will use plain C to solve this problem... by writing an interpreter in plain C for a good DSL to solve this problem in, and then writing the solution in that DSL. But, you know, someone else already did the first part. I'd do it myself if they hadn't, though."
Maybe your problem is CPU-bound. Maybe there are good C libraries that solve your problem. Maybe you just want to learn C better. Maybe you have latency limits you need to work within. Maybe you just want to be contrary. Sometimes "why not" is worth more than "why."
> Maybe your problem is CPU-bound. Maybe you have latency limits you need to work within.
Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell.
> Maybe there are good C libraries that solve your problem
Maybe, but most of the original post is about how lacking the library ecosystem is. I can well believe that you might have some useful domain-specific libraries for the backend, but that calls for writing a backend service in C (and using something like thrift to call it), not "web programming in C".
> Maybe you just want to learn C better.
If you try and learn on a fake problem you'll pervert your learning. Web development is not amenable to idiomatic C (Cello is a good example - it's not appropriate to the sort of problems C is appropriate for, and if you learn C based on using Cello it will not make you a good C programmer).
> lots and lots of time to spend micro-optimizing everything
If you're an experienced C developer you know what's fast and what not (and you know about things like cache coherency). You don't spend that much time on 'micro optimization' because you know how to layout your memory in the first place, etc.
> Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell.
This is stating the case too strongly. Performance wise, the naive, unoptimized solution in Haskell (ex. using the default String type instead of Data.ByteString, number crunching using lots of iteration\recursion) is going to be much slower than than the naive, unoptimized solution in C or Lua. However, for a given subset of the range between "zero" and "micro" levels of optimization, for a given problem, Haskell may still represent the local maximum.
Spending the same amount of development time as the naive, unoptimized solution in C or Lua would take will get you something more performant than the naive, unoptimized solution in Haskell.
>Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell.
This is just not true. Haskell is terribly (3x,4x) slow comparing to C for the most trivial of computing tasks. You can probably get it to 2x or 1.5x by giving up all the lists and other default data structures as well as writing everything in procedural (by monads) way.
If you do all this you can get close to C performance but you just gave up all the advantages of writing in Haskell in the first place. And you are still slow as hell.
You are just saying the equally wrong thing on the opposing side. You can get to 2x without giving up anything. Lists are just a data structure. So are vectors. You don't give anything up to choose one or the other, you pick the right one and use it. You do not write "everything in procedural (by monads) way" to gain performance. Do notation is literally syntactic sugar, and there is no "perform faster" monad to do it in. Haskell code gets to 2x C speeds the same way C gets to 1x C speeds: profile your code and fix the inefficiencies.
Pretty much any decent language has a way to call out to C. I wrote a portion of a book on Tcl's C API, for instance, and it's very easy to farm out computationally intensive work to C code, as it is in Python, Ruby and most other things, one way or the other.
I've done it. The use case was settings web pages on an small wifi audio device. Using a few hundred lines of code more was in all respects preferable to trying to fit some other language runtime into a 6 MB budget.
And I don't know why it would need to be so horrible to program web in C, once you have abstracted out common web tasks, using them is as simple as using them in any language, just call a function.
For a CRUD app, of course it doesn't make much sense and you'd probably have to be a masochist. :) But there are valid use cases I can think of: Anything that's very CPU intensive that would need to run very quickly: dynamic image generation, or something that does a complex series of operations on user input that needs to delivers the results ASAP.
Of course it's usually easier and safer to just throw more CPU at it, but at a certain scale that might get too expensive...
No, seriously, why? As far as I can tell, his entire argument is "web development in C is terrible and limiting, but not as quite as terrible and limiting as you might think." I guess that's good news if terrorists are forcing you to write websites in C, but I don't see even an attempt at explaining why you would choose to do this.