I will live to be a happy old man if I never read another blog post telling me in absolute terms what I must do and why I'm an idiot if I don't. I blame Joel Spolsky for this, his tone and style seems to have kicked off an entire sub-culture of blogging where the posts read like a lunatic standing on a street corner demanding that we repent before the end of the world and the coming of the messiah.
Bloggers, please try a kinder, gentler tone, one that suggests you and I are colleagues. One that suggests you have discovered some neat thing and won't I have a look at it and isn't it interesting to play "what if" games with it and maybe, just maybe I might experiment with it.
Looking back on my own posts, I would say the strongest ones are those where I found a more reasoned voice. An essay can be strongly opinionated without being imperative.
I agree, but TBH there have been a lot of ridiculously overhyped blog posts/articles telling us how totally awesome every scripting language is, and how it's completely a 'game changer' and how you can do completely revolutionary things in them really easily.
I guess this is just a reaction to the froth+hype. Both sides need to step away from the keyboard, and calm down.
Sweet merciful lord. Is this guy channelling Zed Shaw or what?
Apart from all the hand-waving and generalizations, this guy doesn't sound like he's ever really a webapp under serious load.
I'm not a Ruby guy, so I don't know how things fly with that, but I've never once had a problem with a webapp being slow because of the language it was written in. Bad database queries, unnecessary assets being loaded, definitely. But CPU-bound limitations caused purely because of the cost of interpretation of a scripting language? Not so much...
I've worked on a webapp under serious load, and I think he's right.
You're correct that database queries and resource bottlenecks are the usual problems for web application scaling, but even taking that into account, I've had more than one problem that was caused by the simple fact that Ruby is a dog of a language. Python is better, but only just so. Perl is faster than both, but still nowhere near as fast as a C++ program.
But let's ignore execution speed, since one can make a reasonable argument that even the slowest scripting language can saturate the network I/O on modern hardware. I think I'd still consider using a compiled language, because the type-safety and compile-time guarantees of a statically typed language would go a long way toward eliminating a huge class of silly bugs that we deal with on a daily basis. That's developer time in the bank.
Yeah I would like to second this... I'm no expert on web apps or frameworks, but I've heard enough that they're generally more I/O bound instead of CPU bound.
Now if he were to propose writing JUST a web application in C that has a custom HTTP server designed from sockets up to HMTL... you can streamline the sh*t out of that.
Much luck to him. Success or failure, he'll still probably be learning...
I had that basic idea when web app frameworks starting becoming popular. So I implemented a web framework which took a 'description' of the app written in perl, and generated C++ which compiled into a single exe file which served the app with a built in http server. Small bits of business logic were written in C++, but basically it was done by the perl. All templates, internationalisation, everything, compiled down to a few database queries, string concatenations and the odd if statement.
I then build a couple of production sites in this, one on my own, and another with a few other developers.
Conclusions from this:
1) It's really really fast and efficient, and the single exe model for deployment is lovely.
2) It's a pain to implement such a framework, and a pain to use it.
I have worked with a project for the past several years that, by necessity not choice, required a web application framework written in C (it's an embedded platform) and I can tell you it is pure hell. The most mundane and simple tasks, often trivial one-liners in scripting languages, require many lines of error-prone C code even with a fairly rich set of libraries available. Working in this environment, you'll quickly realize why the rest of the world doesn't do it this way. Thankfully, this project is finally moving away from this architecture and I couldn't be happier about it.
Would Lua have worked there? It's a ~200k library designed to provide an embedded scripting language to C projects. (It's very similar to Python, but a tenth the size, and with a bit more Scheme influence.) While it may be too big for some especially tight embedded platforms, if you could fit it in, it would have likely been substantially less painful.
It's also a pretty good scripting language on its own merits, and has replaced Python as my default language. (Unlike Python, its design expects you to know at least a little C, but in exchange, it avoids cluttering the language with things that C already does well.)
The most mundane and simple tasks, often trivial one-liners in scripting languages, require many lines of error-prone C code even with a fairly rich set of libraries available.
What would be an example of this? I'm mostly a C and Perl person, and once a library is available I've never noticed cases where something was much simpler to write in one than the other. That library might take more time to write in C than Perl, but once it's written I find it just about (less than a factor of 2?) as easy to write the application logic in C as in Perl. My instinct is that if you're writing 'many lines of error-prone C' to do something simple, there's probably room for improvement somewhere.
It's a valid point. I wrote the Mibbit backend from scratch in Java for these reasons. I can only start to imagine the horror I would be enduring if I'd chosen a scripting language.
Having said that, choose the right tool for the job.
edit: Downmod me all you like. A scripted language wouldn't handle 2k req/sec on a couple of VPSs.
I think Mibbit, much like twitter, is one of those apps that is a non-traditional webapp. While its a web based frontend the traffic and distribution of chat messages is a much different beast then what most webapps do. Java is very likely a much better choice for these reasons.
The reason why people choose to go with languages like Ruby is because the trade-off on speed is worth it.
Web front-ends scale very easily. You can just add more web heads and load balance between them. Databases are much harder to scale since you need to keep data consistency and can't just throw more boxes at the problem.
So, you don't need to be computationally efficient. However, you do need to develop fast. You need to be able to create features before your competition. You need to be able to make your system more reliable and bug-free than your competition. And that's where Ruby (and similar languages) helps you.
Sure, you and Linus have a point that selection of language can keep out the riff-raff (Linus Torvalds having a huge rant against C++ simply because of the programming community), but it also means that you're missing out on the good parts of the community. Ruby programmers tend to put a lot of thought into user experience. While you've ranted against testing, I don't think any IT manager would agree with you there. Testing substantially improves one's ability to create new features because you can easily spot anywhere you've broken something. And that leads to better quality applications too.
There's a difference between speed and scaling and if something scales fine, that's ok. Look at it this way, array indexing in a slower way to go through an array in C than incrementing a pointer. And if you had a lot of code you could go through and change all instances. However, it wouldn't be worth your time. Such an improvement wouldn't net you any real benefit while you'd be neglecting improving your product.
I think your point is exacerbated by the fact that it's hard to get web UIs "right". I was critical of languages like python and ruby until I had to do the frontend for some company code. Box looks like it needs to be shifted a few pixels right? Modify code, compile, check. Logo looks better with an offset? Modify code, compile, check. Writing in a scripting language makes it just Modify, check.
You just can't do that in compiled languages, and the compiled language of choice for the web-- Java --isn't known for blazing compilation speed. You'd probably also have to jar it up and copy the damn thing over, whereas psps could be modified in-place. I think this is something that compiled folks like me simply failed to grasp: all the things about scripting languages that make them orders of magnitude faster for developing, especially for the web.
I wrote the upload and download handlers for droplink.me in C as FastCGIs, anticipating performance problems. I built it; but they never really came. It was a fun exercise, but if I wasn't interested in having fun with C, I would have written it in a dynamic language.
I think the reason there isn't a "C web development community" is that programmers are more than willing to trade time for performance. Safe, readable code can be written in high level languages in a snap. You can see your ideas happen very quickly. If you run into performance problems (which I think is safe to say is a fairly rare occurrence for the average web developer who produces decent code, in any language), you can a) refactor or streamline what you already have or b) start fresh, lessons learned, in something lower level.
An aside: the site http://halfbakery.com is implemented entirely as an Apache module.
Your comment adds less to an intelligent discussion than does the article you're calling a troll.
First, this isn't a troll. The guy posted a blog post on his own blog. He didn't post off-topic content to a thread and didn't try to provoke an argument in an otherwise civil conversation. The only possible way that you can characterize this as a troll is that he uses some crude language, and says some things that are unpopular on HN. But say what you will about the content, he didn't try to make you read it.
Second, the guy has a point. I've had a rant like this building in my craw for a long time, and this guy nailed nearly every point I've wanted to make. From a software engineering perspective, web development is in the dark ages. What's worse, it's a luddite process -- a totally self-made exile from the benefits of 50 years of progress: Type safety is shunned. Language efficiency is ignored. Data structures beyond the hash table are exotic and rare (and worse, I've met more than one "professional" web developer who couldn't tell me the difference between open and closed hashing!)
I understand very well that programmer time is more valuable than computer hardware, and that the speed/development time trade-off is often biased toward development time. But if you ask me, what was once an intelligent guideline is now becoming a cult. It is possible to do rapid development in a compiled language, and there are some really good reasons -- beyond execution speed -- to revisit the idea.
I don't think it's a troll, but just someone who is really in to performance, like I do, and I agree with him on some points.
But what I don't agree is using just C. C is too low level and is a horrific unfit task for web development. Instead C++ would be a good fit (and writing in C mixed in). The STL/Boost provide a wonderful abstraction layer that does pretty much anything you throw at it with ease, plus there are lot of other libraries for anything else you can ever think of. I've written several web applications in C++, and it was actually very much like writing in Python/PHP/Ruby and at time prefered writing it in C++ after writing a poc in a scripting language. They were just a little bit less readable but very clean, but the biggest plus the the multiple magnitude performance increase of the application it self with FastCGI. (all these applications were serious number crunchers and had lot of CPU and Memory Bound problems).
tldr;
C for web dev painful, C++ with STL/Boost good/easy/fast/clean.
The old blog software, Typo, is nowhere near as good as Wordpress. I only used it because it was written in Ruby on Rails and I am a Ruby on Rails coder. This is a very poor means of choosing software.
Guys, his point isn't valid. If you want to write things in C, the current implementation of ruby LETS YOU. That's the whole point of C extensions.
You can then ask, why bother writing in Ruby at all, and i think you'll find the answer to be, it's not anywhere near as much of a pain in the ass as writing C is.
The elitism argument is bullshit. We don't need fewer people programming. We need better ways to tell if someone knows what the fuck they're doing.
In my opinion the tools we use and develop should be as accessible as possible. Anyone should be able to pick them up and get what they need to do, done. Good luck doing that with C.
Actually, the problem isn't compiled vs. non-compiled, the problem is C vs. languages that you can actually safely manipulate strings in without segfaults, buffer overflows, and other "own the box/own the webservice" flaws.
Arguably, all the languages that show up down near C in the Shootout would be fine languages to write webservices in, since nearly all of them are as fast as C without the eXtreme danger.
Some web services are "shovel strings from the DB out to the user", like CMSs, but for those that aren't, this isn't a terrible point.
(It's easy to forget when you're the type of person who hangs out on HN, but for most people, compiled == C, or C++ if you're lucky.)
Web site performance problems usually don't have much to do with the raw executing speed of the language they're written in. The problems derive from poor understanding of how to handle concurrent connections. If your app is written in C, but is accessed through a CGI interface - starting a process for each request - then it's going to be slow. Similarly if you write a web server which makes blocking connections to a backend database, your server will be slow. If you use threads to handle concurrent connections, you're going to allocate 2mb stacks for each user - and your website is going to suck. This all has little to do with how fast a language can invert a matrix.
And then there's situations like porting a Rails app to Lift and seeing a huge improvement in performance without touching the database / storage IO: http://lambda-the-ultimate.org/node/2147
Granted, it's not from the most unbiased source, so take it with a grain ;)
There are already a few options for a MVC web framework in compiled code. I'm working on ASP.NET MVC now. It's compiled, but development does not feel like that because of JIT compilation. Also, it will run in Mono on Linux if I want.
I notice comments on the blog post are currently closed. I wonder why. ;)
Although I understand the author's position, it is obvious this is a tech person and not a well-rounded business person. The thing about programming is it's not all about tech.
A program typically serves one purpose: to make a company money. This requires more than just pristine tech. First and foremost it requires time to market so that a company can stay competitive. It also requires the ability for more than just a handful of people to be able to write it for expandability and, God forbid, staff changes.
C is fast. But slow to market. And slow to pick up a program. And slow to test. That's why there is so much WYSIWYG.
Don't get me wrong: there needs to be a lot more code behind and a lot less script out there, but in the end coding is a balance. Anytime anyone says it's all this or all that, you know the position is not sound. It's part speed, part usability, part scalability, part development speed, part readability, part expandability, part pretty pictures, etc. Balance in all things.
That is why there are things called "application servers". Java is not perfect but it has a fine feature called JIT (Just In Time compiling) that produces machine code whenever it makes sense. Raw compiled language goes against the current trend for virtualization, whose goal is to save energy too. So in my opinion JIT is a good solution.
I don't think the guy is troll. I think he simply doesn't know better. This is a classic case of micro-optimization. While he should look at the bigger picture. It is all about global architecture.
[+] [-] raganwald|17 years ago|reply
Bloggers, please try a kinder, gentler tone, one that suggests you and I are colleagues. One that suggests you have discovered some neat thing and won't I have a look at it and isn't it interesting to play "what if" games with it and maybe, just maybe I might experiment with it.
Looking back on my own posts, I would say the strongest ones are those where I found a more reasoned voice. An essay can be strongly opinionated without being imperative.
[+] [-] justin_vanw|17 years ago|reply
I wish all I had to do to be happy for the rest of my life was to never use a computer again.
[+] [-] axod|17 years ago|reply
I guess this is just a reaction to the froth+hype. Both sides need to step away from the keyboard, and calm down.
[+] [-] PhilChristensen|17 years ago|reply
Apart from all the hand-waving and generalizations, this guy doesn't sound like he's ever really a webapp under serious load.
I'm not a Ruby guy, so I don't know how things fly with that, but I've never once had a problem with a webapp being slow because of the language it was written in. Bad database queries, unnecessary assets being loaded, definitely. But CPU-bound limitations caused purely because of the cost of interpretation of a scripting language? Not so much...
[+] [-] timr|17 years ago|reply
You're correct that database queries and resource bottlenecks are the usual problems for web application scaling, but even taking that into account, I've had more than one problem that was caused by the simple fact that Ruby is a dog of a language. Python is better, but only just so. Perl is faster than both, but still nowhere near as fast as a C++ program.
But let's ignore execution speed, since one can make a reasonable argument that even the slowest scripting language can saturate the network I/O on modern hardware. I think I'd still consider using a compiled language, because the type-safety and compile-time guarantees of a statically typed language would go a long way toward eliminating a huge class of silly bugs that we deal with on a daily basis. That's developer time in the bank.
[+] [-] dag|17 years ago|reply
Example usage: "Yes, he can write well, but has he ever really a webapp?"
[+] [-] brooksbp|17 years ago|reply
Now if he were to propose writing JUST a web application in C that has a custom HTTP server designed from sockets up to HMTL... you can streamline the sh*t out of that.
Much luck to him. Success or failure, he'll still probably be learning...
[+] [-] bensummers|17 years ago|reply
I had that basic idea when web app frameworks starting becoming popular. So I implemented a web framework which took a 'description' of the app written in perl, and generated C++ which compiled into a single exe file which served the app with a built in http server. Small bits of business logic were written in C++, but basically it was done by the perl. All templates, internationalisation, everything, compiled down to a few database queries, string concatenations and the odd if statement.
I then build a couple of production sites in this, one on my own, and another with a few other developers.
Conclusions from this:
1) It's really really fast and efficient, and the single exe model for deployment is lovely.
2) It's a pain to implement such a framework, and a pain to use it.
3) I'm never using perl again.
4) Life's too short for this kind of game.
The code is here: http://www.boxbackup.org/trac/ticket/6
[+] [-] grayhacker|17 years ago|reply
I have worked with a project for the past several years that, by necessity not choice, required a web application framework written in C (it's an embedded platform) and I can tell you it is pure hell. The most mundane and simple tasks, often trivial one-liners in scripting languages, require many lines of error-prone C code even with a fairly rich set of libraries available. Working in this environment, you'll quickly realize why the rest of the world doesn't do it this way. Thankfully, this project is finally moving away from this architecture and I couldn't be happier about it.
[+] [-] silentbicycle|17 years ago|reply
It's also a pretty good scripting language on its own merits, and has replaced Python as my default language. (Unlike Python, its design expects you to know at least a little C, but in exchange, it avoids cluttering the language with things that C already does well.)
[+] [-] nkurz|17 years ago|reply
What would be an example of this? I'm mostly a C and Perl person, and once a library is available I've never noticed cases where something was much simpler to write in one than the other. That library might take more time to write in C than Perl, but once it's written I find it just about (less than a factor of 2?) as easy to write the application logic in C as in Perl. My instinct is that if you're writing 'many lines of error-prone C' to do something simple, there's probably room for improvement somewhere.
[+] [-] baguasquirrel|17 years ago|reply
[+] [-] axod|17 years ago|reply
Having said that, choose the right tool for the job.
edit: Downmod me all you like. A scripted language wouldn't handle 2k req/sec on a couple of VPSs.
[+] [-] mikeryan|17 years ago|reply
[+] [-] jerryji|17 years ago|reply
[+] [-] swombat|17 years ago|reply
For the average web app, it's a lousy point, really (and, as pointed out by others, it's a troll/satire).
The fact that you take it seriously is a little worrying tbh. Are you feeling ok? :-)
[+] [-] mdasen|17 years ago|reply
Web front-ends scale very easily. You can just add more web heads and load balance between them. Databases are much harder to scale since you need to keep data consistency and can't just throw more boxes at the problem.
So, you don't need to be computationally efficient. However, you do need to develop fast. You need to be able to create features before your competition. You need to be able to make your system more reliable and bug-free than your competition. And that's where Ruby (and similar languages) helps you.
Sure, you and Linus have a point that selection of language can keep out the riff-raff (Linus Torvalds having a huge rant against C++ simply because of the programming community), but it also means that you're missing out on the good parts of the community. Ruby programmers tend to put a lot of thought into user experience. While you've ranted against testing, I don't think any IT manager would agree with you there. Testing substantially improves one's ability to create new features because you can easily spot anywhere you've broken something. And that leads to better quality applications too.
There's a difference between speed and scaling and if something scales fine, that's ok. Look at it this way, array indexing in a slower way to go through an array in C than incrementing a pointer. And if you had a lot of code you could go through and change all instances. However, it wouldn't be worth your time. Such an improvement wouldn't net you any real benefit while you'd be neglecting improving your product.
Your product is what matters.
[+] [-] baguasquirrel|17 years ago|reply
You just can't do that in compiled languages, and the compiled language of choice for the web-- Java --isn't known for blazing compilation speed. You'd probably also have to jar it up and copy the damn thing over, whereas psps could be modified in-place. I think this is something that compiled folks like me simply failed to grasp: all the things about scripting languages that make them orders of magnitude faster for developing, especially for the web.
[+] [-] wooby|17 years ago|reply
I think the reason there isn't a "C web development community" is that programmers are more than willing to trade time for performance. Safe, readable code can be written in high level languages in a snap. You can see your ideas happen very quickly. If you run into performance problems (which I think is safe to say is a fairly rare occurrence for the average web developer who produces decent code, in any language), you can a) refactor or streamline what you already have or b) start fresh, lessons learned, in something lower level.
An aside: the site http://halfbakery.com is implemented entirely as an Apache module.
[+] [-] jimbokun|17 years ago|reply
[+] [-] timr|17 years ago|reply
First, this isn't a troll. The guy posted a blog post on his own blog. He didn't post off-topic content to a thread and didn't try to provoke an argument in an otherwise civil conversation. The only possible way that you can characterize this as a troll is that he uses some crude language, and says some things that are unpopular on HN. But say what you will about the content, he didn't try to make you read it.
Second, the guy has a point. I've had a rant like this building in my craw for a long time, and this guy nailed nearly every point I've wanted to make. From a software engineering perspective, web development is in the dark ages. What's worse, it's a luddite process -- a totally self-made exile from the benefits of 50 years of progress: Type safety is shunned. Language efficiency is ignored. Data structures beyond the hash table are exotic and rare (and worse, I've met more than one "professional" web developer who couldn't tell me the difference between open and closed hashing!)
I understand very well that programmer time is more valuable than computer hardware, and that the speed/development time trade-off is often biased toward development time. But if you ask me, what was once an intelligent guideline is now becoming a cult. It is possible to do rapid development in a compiled language, and there are some really good reasons -- beyond execution speed -- to revisit the idea.
[+] [-] dryicerx|17 years ago|reply
But what I don't agree is using just C. C is too low level and is a horrific unfit task for web development. Instead C++ would be a good fit (and writing in C mixed in). The STL/Boost provide a wonderful abstraction layer that does pretty much anything you throw at it with ease, plus there are lot of other libraries for anything else you can ever think of. I've written several web applications in C++, and it was actually very much like writing in Python/PHP/Ruby and at time prefered writing it in C++ after writing a poc in a scripting language. They were just a little bit less readable but very clean, but the biggest plus the the multiple magnitude performance increase of the application it self with FastCGI. (all these applications were serious number crunchers and had lot of CPU and Memory Bound problems).
tldr; C for web dev painful, C++ with STL/Boost good/easy/fast/clean.
Also I've heard of wt, a C++ web framework although I've never used it http://www.webtoolkit.eu/wt
[+] [-] nuclear_eclipse|17 years ago|reply
The old blog software, Typo, is nowhere near as good as Wordpress. I only used it because it was written in Ruby on Rails and I am a Ruby on Rails coder. This is a very poor means of choosing software.
[+] [-] mildweed|17 years ago|reply
[+] [-] bena|17 years ago|reply
[+] [-] knowtheory|17 years ago|reply
You can then ask, why bother writing in Ruby at all, and i think you'll find the answer to be, it's not anywhere near as much of a pain in the ass as writing C is.
The elitism argument is bullshit. We don't need fewer people programming. We need better ways to tell if someone knows what the fuck they're doing.
In my opinion the tools we use and develop should be as accessible as possible. Anyone should be able to pick them up and get what they need to do, done. Good luck doing that with C.
[+] [-] jerryji|17 years ago|reply
[+] [-] chanux|17 years ago|reply
[+] [-] burke|17 years ago|reply
[+] [-] laktek|17 years ago|reply
Only recently they decided to change it to a must robust Erlang based implementation - http://www.37signals.com/svn/posts/1728-nuts-bolts-campfire-...
[+] [-] JulianMorrison|17 years ago|reply
[+] [-] jerf|17 years ago|reply
Arguably, all the languages that show up down near C in the Shootout would be fine languages to write webservices in, since nearly all of them are as fast as C without the eXtreme danger.
Some web services are "shovel strings from the DB out to the user", like CMSs, but for those that aren't, this isn't a terrible point.
(It's easy to forget when you're the type of person who hangs out on HN, but for most people, compiled == C, or C++ if you're lucky.)
[+] [-] ryah|17 years ago|reply
[+] [-] warfangle|17 years ago|reply
Granted, it's not from the most unbiased source, so take it with a grain ;)
[+] [-] nathanwdavis|17 years ago|reply
[+] [-] vyrotek|17 years ago|reply
[+] [-] goodkarma|17 years ago|reply
[+] [-] jdbeast00|17 years ago|reply
[+] [-] albertcardona|17 years ago|reply
[+] [-] Deadly_B|17 years ago|reply
Although I understand the author's position, it is obvious this is a tech person and not a well-rounded business person. The thing about programming is it's not all about tech.
A program typically serves one purpose: to make a company money. This requires more than just pristine tech. First and foremost it requires time to market so that a company can stay competitive. It also requires the ability for more than just a handful of people to be able to write it for expandability and, God forbid, staff changes.
C is fast. But slow to market. And slow to pick up a program. And slow to test. That's why there is so much WYSIWYG.
Don't get me wrong: there needs to be a lot more code behind and a lot less script out there, but in the end coding is a balance. Anytime anyone says it's all this or all that, you know the position is not sound. It's part speed, part usability, part scalability, part development speed, part readability, part expandability, part pretty pictures, etc. Balance in all things.
[+] [-] maigret|17 years ago|reply
[+] [-] petercooper|17 years ago|reply
Good bit of satire. I wouldn't call it a troll because it's funny and just unbelievable enough, rather than inflammatory and merely misguided.
[+] [-] icefox|17 years ago|reply
[+] [-] st3fan|17 years ago|reply