4 ms·

I've seen this sort of version control done twice in a professional setting, and both were by programmers much more gifted than me. I once saw a guy who wrote

I've seen this sort of version control done twice in a professional setting, and both were by programmers much more gifted than me. I once saw a guy who wrote a robust e-store web app in C. Not C++, but C. Tons of complexity, and it worked fine, but then when I dived in to work on it, it was a nightmare. He told me "You want main_app.version3.old.c, That's the one that gets compiled and pushed to the production server. Not main_app.c, that one's old and we don't use it anymore." He built a build system from scratch, did his own version control in his head, and kept everything in one monolithic C file. Of course, he was the shittiest software developer I've ever seen. Just a brilliant programmer. He needed a manager the way a jet needs a pilot. Sadly, he was 30 years my senior, and not amenable to being told what to do, so after a long talk with our CEO, we decided to let him go. He was the only one who knew how our system work, but I built a comparable one using best practices and open-source software in less than a month.

rwmj 11y ago
C isn't a terrible language to write a web framework in. (Not using version control is a terrible idea). About 15 years ago I wrote a simple high level framework in C for writing web apps: http://git.annexia.org/?p=c2lib.git http://git.annexia.org/?p=c2lib.git http://git.annexia.org/?p=pthrlib.git http://git.annexia.org/?p=pthrlib.git http://git.annexia.org/?p=rws.git http://git.annexia.org/?p=rws.git http://git.annexia.org/?p=monolith.git http://git.annexia.org/?p=monolith.git It actually does stuff that even current frameworks cannot achieve, such as providing long-lived stateful web apps entirely in HTML (no JS required), although you are entitled to doubt if that matters these days since JS has won and is available pretty much everywhere. The best thing about it was that it was so fast, because the code + data of a small web app would fit entirely in the L1 cache of the CPU.
- kbenson 11y ago
  > It actually does stuff that even current frameworks cannot achieve, such as providing long-lived stateful web apps entirely in HTML What? This was the norm back in the day. It's not like all those Perl programmers writing CGIs or later PHP programmers writing PHP apps were using JS to tie it all together. Or am I misunderstanding what you mean?
  - rwmj 11y ago
    It had two levels of persistence. There was a database layer for long term, persistent storage. But the clever(?) part was that the C threads persisted (in memory) beyond each single HTTP request. e.g. you could create a calculator web app where you would press buttons and have the calculator display numbers, and all that would be handled (across multiple requests) by a single C thread. The calculator display might be stored in a stack variable. Of course you can imagine ways for this to fail - restarting the webserver wasn't very nice for your users for example. Also you needed a smart front end which would direct user sessions back to the same web server instance. (And since it used cooperative threads, each core would be running a separate web server -- but this was 15 years ago when multicore machines were not too common).
    - kbenson 11y ago
      Ah, so this was possible, and occasionally done back then, but the real reason it wasn't was less to do with capability, and more to do with everyone wanting to ride on top of Apache. Apache handled a lot of stuff you wouldn't want to in a CGI (at that time), so it made sense to use it. Apache forked (and/or threaded depending on era), so variables shared in memory wasn't common. That said, people set up shared memory regions, or used file based sessions and /dev/shm, which is functionally the same, and had much the same thing.
      - rwmj 11y ago
        This is a ground-up web server rewrite, so it didn't use Apache, although we did (sometimes) front it with an Apache-based proxy.
        kbenson 11y ago
        Oh, I understand that. I just used Apache as a reasoning for why most in the era weren't using memory based sessions. Also I think it's worth saying that I'm not trying to belittle your accomplishment, as it may have come across that way. Writing your own framework in the language you used to handle logic proved to be somewhat prescient of you, it's what numerous other projects ended up doing (Rails, Mojolicious, etc) for multiple reasons, which I'm sure you were able to take advantage of. I remember my own tests using ApacheBench ca. 2005 to test simple CGI performance vs mod_perl performance vs PHP vs Perl's HTTP::Daemon implementation with forking. When the workload is small, and the routing needs are simple, it's amazing how much overhead the webserver includes.
- pcx 11y ago
  C is a terrible language to write a web framework in. The kind of high-level constructs modern programming languages provide are just not possible in C. It is also very easy to write buggy code and is too low level for the use case.
  - rwmj 11y ago
    You should try looking at the code before declaring that. The C used a pool allocator, had some high level structures (vectors and hash tables, basically the same as Perl), loads of safe string functions, try/catch, coroutines, cooperative threads, and other stuff I've forgotten[1]. It was possible to write safe code in that framework, and in fact we did write a lot of code used daily by tens of thousands of UK schoolchildren until quite recently. [1] Invoking https://en.wikipedia.org/wiki/Greenspun's_tenth_rule https://en.wikipedia.org/wiki/Greenspun's_tenth_rule although I like to think our code was very minimal, elegant and not too buggy.
    - deleted 11y ago
      [deleted]
    - pcx 11y ago
      > You should try looking at the code before declaring that. Attempting to write a web framework in C is great! Even though you end up building the high-level programming constructs, C web dev is still just too hard compared to other alternatives. Because of this it is not possible to build a large community around it, which I would say is the most crucial part of today's web framework like Django/Rails.
- knodi123 11y ago
  > C isn't a terrible language to write a web framework in. Hey, I wrote my first CGI script in Pascal, so I know it's not impossible. And nothing I've written since then has been so fast. ;-) But so much stuff like GZIP delivery, POST parsing, cookies, etc will require you to write enormous functions, with countless "gotcha" edge cases, just to reinvent the wheel. Using it in production for anything complex (like a web store selling digital downloads), is just nuts.
  - rwmj 11y ago
    Agreed. This was 15 years ago (although it was in service until quite recently). We used to front the thing with an Apache proxy, so that could deal with more modern web standards.
- lmm 11y ago
  C doesn't have tagged unions, which makes it a terrible language to write pretty much anything in. Most of the other pieces you need for good programming you can write yourself in C, but you can't make a safe tagged union out of thin air, and if you rely on helper functions or macros then your tools won't understand them. It's also so bad at expressing literal values that I've seen a serious recommendation to write literal strings and parse them instead ( http://www.tedunangst.com/flak/post/string-interfaces http://www.tedunangst.com/flak/post/string-interfaces ). The type system doesn't even do generics, never mind higher kinds. Maybe you could keep a web framework small enough that that wouldn't be too big a deal.
  - rwmj 11y ago
    These are all valid reasons against using C for anything at all, but they apply to many other languages that people use for web apps too. It's worth noting that another web framework I wrote a couple of years later was written in OCaml[1]. [1] https://savannah.nongnu.org/projects/modcaml https://savannah.nongnu.org/projects/modcaml - also dead upstream, and there are now much better choices for OCaml web apps.
    - lmm 11y ago
      People still use untyped languages for some things, but for the rest I don't think so? I mean if you have virtual functions then you can effectively implement (inefficient) tagged unions, and every language I've seen used on the web has a reasonable syntax for basic values.
st3v3r 11y ago
I don't know about that statement. If someone can't understand basic source control, and the benefits it brings, what else in their software are they not thinking of?

rwmj 11y ago

C isn't a terrible language to write a web framework in. (Not using version control is a terrible idea). About 15 years ago I wrote a simple high level framework in C for writing web apps: http://git.annexia.org/?p=c2lib.git http://git.annexia.org/?p=c2lib.git http://git.annexia.org/?p=pthrlib.git http://git.annexia.org/?p=pthrlib.git http://git.annexia.org/?p=rws.git http://git.annexia.org/?p=rws.git http://git.annexia.org/?p=monolith.git http://git.annexia.org/?p=monolith.git It actually does stuff that even current frameworks cannot achieve, such as providing long-lived stateful web apps entirely in HTML (no JS required), although you are entitled to doubt if that matters these days since JS has won and is available pretty much everywhere. The best thing about it was that it was so fast, because the code + data of a small web app would fit entirely in the L1 cache of the CPU.

kbenson 11y ago
> It actually does stuff that even current frameworks cannot achieve, such as providing long-lived stateful web apps entirely in HTML What? This was the norm back in the day. It's not like all those Perl programmers writing CGIs or later PHP programmers writing PHP apps were using JS to tie it all together. Or am I misunderstanding what you mean?
- rwmj 11y ago
  It had two levels of persistence. There was a database layer for long term, persistent storage. But the clever(?) part was that the C threads persisted (in memory) beyond each single HTTP request. e.g. you could create a calculator web app where you would press buttons and have the calculator display numbers, and all that would be handled (across multiple requests) by a single C thread. The calculator display might be stored in a stack variable. Of course you can imagine ways for this to fail - restarting the webserver wasn't very nice for your users for example. Also you needed a smart front end which would direct user sessions back to the same web server instance. (And since it used cooperative threads, each core would be running a separate web server -- but this was 15 years ago when multicore machines were not too common).
  - kbenson 11y ago
    Ah, so this was possible, and occasionally done back then, but the real reason it wasn't was less to do with capability, and more to do with everyone wanting to ride on top of Apache. Apache handled a lot of stuff you wouldn't want to in a CGI (at that time), so it made sense to use it. Apache forked (and/or threaded depending on era), so variables shared in memory wasn't common. That said, people set up shared memory regions, or used file based sessions and /dev/shm, which is functionally the same, and had much the same thing.
    - rwmj 11y ago
      This is a ground-up web server rewrite, so it didn't use Apache, although we did (sometimes) front it with an Apache-based proxy.
      - kbenson 11y ago
        Oh, I understand that. I just used Apache as a reasoning for why most in the era weren't using memory based sessions. Also I think it's worth saying that I'm not trying to belittle your accomplishment, as it may have come across that way. Writing your own framework in the language you used to handle logic proved to be somewhat prescient of you, it's what numerous other projects ended up doing (Rails, Mojolicious, etc) for multiple reasons, which I'm sure you were able to take advantage of. I remember my own tests using ApacheBench ca. 2005 to test simple CGI performance vs mod_perl performance vs PHP vs Perl's HTTP::Daemon implementation with forking. When the workload is small, and the routing needs are simple, it's amazing how much overhead the webserver includes.
pcx 11y ago
C is a terrible language to write a web framework in. The kind of high-level constructs modern programming languages provide are just not possible in C. It is also very easy to write buggy code and is too low level for the use case.
- rwmj 11y ago
  You should try looking at the code before declaring that. The C used a pool allocator, had some high level structures (vectors and hash tables, basically the same as Perl), loads of safe string functions, try/catch, coroutines, cooperative threads, and other stuff I've forgotten[1]. It was possible to write safe code in that framework, and in fact we did write a lot of code used daily by tens of thousands of UK schoolchildren until quite recently. [1] Invoking https://en.wikipedia.org/wiki/Greenspun's_tenth_rule https://en.wikipedia.org/wiki/Greenspun's_tenth_rule although I like to think our code was very minimal, elegant and not too buggy.
  - deleted 11y ago
    [deleted]
  - pcx 11y ago
    > You should try looking at the code before declaring that. Attempting to write a web framework in C is great! Even though you end up building the high-level programming constructs, C web dev is still just too hard compared to other alternatives. Because of this it is not possible to build a large community around it, which I would say is the most crucial part of today's web framework like Django/Rails.
knodi123 11y ago
> C isn't a terrible language to write a web framework in. Hey, I wrote my first CGI script in Pascal, so I know it's not impossible. And nothing I've written since then has been so fast. ;-) But so much stuff like GZIP delivery, POST parsing, cookies, etc will require you to write enormous functions, with countless "gotcha" edge cases, just to reinvent the wheel. Using it in production for anything complex (like a web store selling digital downloads), is just nuts.
- rwmj 11y ago
  Agreed. This was 15 years ago (although it was in service until quite recently). We used to front the thing with an Apache proxy, so that could deal with more modern web standards.
lmm 11y ago
C doesn't have tagged unions, which makes it a terrible language to write pretty much anything in. Most of the other pieces you need for good programming you can write yourself in C, but you can't make a safe tagged union out of thin air, and if you rely on helper functions or macros then your tools won't understand them. It's also so bad at expressing literal values that I've seen a serious recommendation to write literal strings and parse them instead ( http://www.tedunangst.com/flak/post/string-interfaces http://www.tedunangst.com/flak/post/string-interfaces ). The type system doesn't even do generics, never mind higher kinds. Maybe you could keep a web framework small enough that that wouldn't be too big a deal.
- rwmj 11y ago
  These are all valid reasons against using C for anything at all, but they apply to many other languages that people use for web apps too. It's worth noting that another web framework I wrote a couple of years later was written in OCaml[1]. [1] https://savannah.nongnu.org/projects/modcaml https://savannah.nongnu.org/projects/modcaml - also dead upstream, and there are now much better choices for OCaml web apps.
  - lmm 11y ago
    People still use untyped languages for some things, but for the rest I don't think so? I mean if you have virtual functions then you can effectively implement (inefficient) tagged unions, and every language I've seen used on the web has a reasonable syntax for basic values.

st3v3r 11y ago

I don't know about that statement. If someone can't understand basic source control, and the benefits it brings, what else in their software are they not thinking of?