I had an interesting conversation with a friend the other day. She wanted to try putting together a weekend "hackathon" just to see what we could build. It would be one of those fun things where we just start tinkering and see what comes out of it.
Somehow, this conversation got to the topic of libraries, programming languages, and frameworks. Then it got a little weird.
I guess the current "shiny" thing is still more-or-less Ruby, and particularly when used with Rails. Oh, I suppose there's also the whole node thing, in which you write things in Javascript and run them server-side with v8. She dismissed node right away (with no argument from me), so we got to talking about Ruby and Rails.
I was not thrilled with the suggestion that we go and work in that language and framework. I have no practical experience with them, and so far, I haven't had a reason to touch them. The few times I've seen or heard about them, it's all been linked to frothy people clamoring for the latest shiny thing. I've seen that pattern plenty of times before, and it's always annoying.
We started talking about how there are these modules you can glue together to do stuff. It might not be wonderful, but you could build something relatively quickly, at least in theory. She told me about some web site that came together in a weekend that allows users to do this thing, this other thing, and some third thing. The implication was that without those tools, it couldn't have happened within the scope of a "hackathon" -- 2 or 3 days at the most.
I found this disturbing. It was a situation I had never thought about before: that somehow you would need to abdicate almost all of your code to modules where you just hope they work. It seemed to describe a situation where you spend a good chunk of time looking for modules which might do what you want, and then start trying to glue them together. That doesn't sound fun to me.
If they don't work, you have a dilemma. Do you try to "open the hood", so to speak, and see about fixing it to do what you want, or do you throw out that module and start searching for another? What happens if you don't find one which will behave exactly the way you want?
Around that point, the conversation turned to how else I would do something like the web site she had described if not with Rails. I said, well, that's easy. I have libraries to handle dumb stuff too. One of them sorts out incoming GET and POST requests and another deals with incoming cookies. Still another library is used to handle requests which look like /normal/paths but are actually are calling a program called "/normal" with an argument called "paths". There are plenty of others not worth mentioning here.
It's nothing special. The difference is that the author of these libraries is me, and that they have been written in C++, just like everything else in my tree. I mentally switched my default to a specific subset of C++ after doing my time in Mountain View, and have put together my own little group of tools to let me stay in a similar groove on my new projects.
Apparently this was frightening. The implication is that "mere mortals" don't work this way. I didn't dig too deeply, but I can see several possibilities for this being raised. One is merely the fact that I do this in C++. I had the same sort of reaction from people years ago when I'd just knock out some random support ticket analysis tool in plain old C. To them, web apps meant Perl or even Python and C was some kind of untouchable magic. I never figured out why they had that belief.
Another possibility is that I went and wrote my own library to deal with things like an incoming GET query string. For one thing, I'm not dealing with a raw TCP socket and speaking HTTP myself. All of my stuff runs under Apache with the good old CGI interface. I've been doing random hacks with that for ages, and so far it hasn't let me down. When it starts becoming a problem, then I'll move away from it.
Thanks to being in the world of CGI, I only have to grovel through the QUERY_STRING environment variable handed to me by Apache to figure out a GET request. It isn't terribly difficult, and I can make a nice STL map of the things which interest me and throw out the rest.
Likewise, for POST, it's a matter of reading stdin and doing a similar sort of decoding run until EOF. Has it been done before? Of course. Did I have to exhaustively search for one that works the way I want it to? Nope. I didn't have to, because it was simple enough to just make my own.
Maybe that's the thing. Maybe everyone has their own cut-off point for what they are willing to do themselves. I know for sure that I would never write my own XML handling stuff unless absolutely forced to. This came up while writing my fred feed reader project. I find XML to be evil and ridiculous, so I found a library that's installed basically everywhere (libxml2), wrote a wrapper to isolate myself from most of its foibles and act "classful" in my C++ world, and left it at that.
Similarly, I decided to not bother with writing a TCP client that spoke HTTP. While it's simple enough to actually create a socket, open a connection, blast out a GET and deal with a response, there's just far too much corner case garbage which can arise: failures, timeouts, HTTP redirections, and worse. I left that to libcurl instead.
So why did I write my own GET and POST parser? Well, basically, I couldn't find an obvious way to delegate that to another library. There's cgic, but that creates an awful design where you give up main() to that program's code and then just wake up when it decides to call back to you. No thanks.
To bring this back to programming languages, one thing that always bothers me is why new ones keep appearing. I start saying things like "I guess language n-1 wasn't that great since language n came along and people jumped to it". How long did that most recent one last? A year or two?
Meanwhile, I'm back on language n-bignum, and yet I still manage to get things done. Better still, since I"m not chasing the shininess in that realm, I can spend those cycles on other things.
It would be different if I was stubbornly clinging to a programming language where I could not get things done. At that point, it would be obvious that I had lost hold of a pragmatic reality and was operating on some other premise.
That's about where the conversation got before I realized that it wasn't doing anything to further the cause of actually scheduling our hackathon. We were worrying about things which might not even matter. The fact that one person prefers Ruby and the other prefers C++ might turn out to be totally irrelevant depending on what we try to build.
We decided to just schedule it when time opened up in our respective calendars and then see what happens. It definitely beats having hypothetical language debates until the heat death of the universe.
At some point, you just have to shut up and make stuff.
