We'll Always Have C

The other day there was an interview in Dr. Dobb's Journal with the managing director of TIOBE Software, who publishes the TIOBE Programming Community Index, a ranking of programming language popularity. It was also discussed on Slashdot.

The methodology used by TIOBE to calculate a language's popularity is basically the good old google hits ad-hoc voodoo index, using "[language] programming" as the query. This measures the "web presence" of a programming language.

First of all, it's obvious to you and me that this measures something, that something being the amount of web pages including the term "[language] programming", obviously. There's nothing wrong with this method, as long as one is aware of what they're measuring. But is it fair to call this the popularity of a language?


Look at this blog, for example. I mostly mention JavaScript and PHP here, just like everyone else. Throw in some Ruby and Python too to max out the buzz factor. There is no mention of relics such as C in this blog. But you know what language I use ten times more than any other? C. I'd love to have a job hacking away in JavaScript, Ruby, and Python all days, but I'd have to settle with half the salary. So here it goes: C programming. Index that. Embedded, heavily multi-threaded, efficient, minimum memory, hardcore badass C programming, that's what I do, and I love doing it.

Most coders can't do C. That's why you see all these Visual This and Dot That and scripting languages on the ranking, because these kids blog about every little insignificant hobby project they manage to cut and paste together, just like I do. But let there be no mistake about it: real programmers can code in C. They do syntactically correct typedefs of function pointers in their sleep. (just kidding that's impossible.)


At work I also hack in Python, Perl, and Makefile. At home it's mostly JavaScript, PHP, Ruby, Python... Lately Python has replaced Ruby as my language of choice for home hacking because of its decent unicode support. (Although I've had to hack the Python standard library in some places where it didn't properly support unicode. I read the next version of Python (2.6?) will use unicode strings by default, which is great, and only ten years late.) I also sold my soul the other day and installed Visual C# 2008 Express Edition for some hobby hacking. Turned out not very fun though, but I haven't given up yet.

At my previous job I used C++ for doing essentially the same thing as I do in C now. I'm completely convinced that C is the right tool for the job. I'm also convinced C does object orientation better than C++, but that is a topic for another post. And I used to be a Java fan, but now I'm considering Java the best examples of software suckiness ever. It's a volatile industry, technologies come and go, but no amount of blogging will convince me that the C programming language is anything but #1.

I'm saying it because it's true: We'll always have C. Because we've got jobs to do.

Minesweeper!

Finally! My Minesweeper game is ready for the web! It's the classic game in a web 2.0 costume. Why did I do that? when surely it's been done before. Because I like minesweeper.

Developing this game has taught me one something about the time it can take from prototype to somewhat finished product: Developing the completely playable "offline" prototype version was quick and easy - after all, I developed minesweeper already in high school on my programmable Casio calculator. So I thought it would take about trice the time to finish it, but in the end it took about ten times that time.

One reason for this is the online highscore functionality. But T-rex, online highscores just means keeping a list of the best times on the server and sending it to the client. Yes, but then it wouldn't take much to figure that all you need to do is type "register_highscore.php?time=0&name=script%20kiddie" into your browser's address field to get an instant all-time high. So how did I solve that?

The game is played simultaneously on the client (i.e. in the web browser) and on the server (in php). Sweeps are sent at regular intervals to the server, which then plays the same moves and checks the results. So in the end it's the server that decides that a game is over, how long it took, and whether that's a new highscore or not. That, ideally, is not so complicated either, but well there are lots of opportunities to make stupid mistakes. (Especially when you're having a shochu on the rocks while coding (I did it during my vacation).)

The other reason is that it's hard to make a web app behave like a nifty game. You need graphics, animations, and that kind of stuff that often causes you to run into problems with layout positioning and, most of all, browser inconsistencies. Web browsers just aren't ideal for making applications yet. (Well, tell me a platform that is, anyway...) The game runs best, as always, in Firefox. Although I admit I haven't tried IE 6 yet. I'll tackle that beast tomorrow. :) IE 7 works good, though.

I still have a number of features planned that I'll implement during the coming weeks, but at least now it's good enough to play. Try and beat my times! Here's the url again:

http://henrikfalck.com/minesweeper/

Caching in Php

Php by default tries as hard as it can to make the web browser not cache pages. While I can understand the rationale behind this a bit, sometimes you want caching. Caching is actually a good thing! you know. It means faster load times and lower bandwidth and processing requirements.

So I was surprised by how hard it is to turn off this aggressive non-caching policy. I googled for a few minutes and browsed the php documentation without finding an easy way of doing it. Ok, so you can use the following code snippet to enable caching in php (the argument to the function is number of seconds the page is valid):

function send_cache_headers($expire) {
  header("Cache-Control: max-age=$expire");
  header("Pragma: cache");
  header("Expires: " . gmdate('D, d M Y H:i:s \G\M\T', time() + $expire));
}


A JavaScript messaging library

I'm working on a library for sending messages between browsers using JavaScript, XMLHttpRequest, and PHP/sqlite on a server. The idea is that even though it's not possible to open a connection of sorts directly between the clients (i.e. web browsers viewing a page, or even different pages, or running a widget), you can pull for updates in a way that will make it seem like you have a connection open. Not only that, but all client listening on the same channel, so to speak, will receive the messages, so it's like broadcasting. Technically this is nothing fancy, it's just that you don't see it much, and if implemented and packaged nicely I think it'll be useful and fun to use.

How do I know this works? Because it's based on a much cleaned up version of the code used on paintmyblog.com - which has proven itself already. I look forward to writing some cool apps using this library, and I hope other people will use it as well. Expect the first release next week.

Useful JavaScript Programming Sites

There are some sites I tend to consult all the time while programming in JavaScript. Let's see what they are...

Core JavaScript 1.5 Reference - Mozilla Developer Center
A thorough and complete reference for the JavaScript language and standard library, with examples and links to more information, etc. Really good.
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference

Gecko DOM Reference - Mozilla Developer Center
Complements the above reference with a complete reference to the document object model, i.e. all the methods and classes that are available in JavaScript for manipulating the web page in the browser.
http://developer.mozilla.org/en/docs/Gecko_DOM_Reference

Canvas Class Reference - Apple Developer Connection
If you like playing with the canvas tag like I do, then this is the place to go for reference documentation on the 2d graphics context object. Complete and handy with all in one page.
http://developer.apple.com/documentation/AppleApplications/Reference/SafariJSRef/Classes/Canvas.html

Prototype JavaScript Framework API
The reference documentation for the Prototype framework. Of course, this is only useful if you're using Prototype. But if you're not, you better have a really good excuse... such as using some bloated alternative like the Yahoo UI Library or Google Web Toolkit.
http://www.prototypejs.org/api

Dojo ShrinkSafe
Dojo ShrinkSafe shrinks the sizes of your JavaScript source files by removing whitespace and renaming local variables to shorter names, and some other stuff. Saves bandwidth and loading time without really giving much up, except debuggability. But you're not doing debugging on your live site anyway, right? Riiight?!
http://alex.dojotoolkit.org/shrinksafe/

A Note On PHP

Php is the most useful piece of crap ever shat on the face of the Earth. My old software engineering professor Uwe Aßmann (who held the by far best lectures I've ever had the pleasure to attend) used to call it Some Dude's Law (I can't remember whose) - that the ugly and worst designed software (Windows, PHP...) always win over the sexy and well designed (BeOS, Smalltalk...). Well, that's how it is. Php makes me feel sick all the time, but I still use it. Because I have to (because that's what's installed) is only half the reason. The documentation is top notch, and I'm very productive using it. In Windows...