The Agnostic Coder

Is it harder to code web apps, taking into account multiple browsers, browser versions, and plugins, Javascript on or off, etc, or is it harder to c ode for games, with different CPU architectures, graphics cards, OSes, etc? Well turns out it’s games. Found an excellent article on the low level troubles of building games on the Intel software site, although it’s (quite unsurprisingly) more about all the different Intel architectures and subtleties therein. Excellent read though. But put aside 30 minutes or so to read it, and even more to digest.

Maks Nemisj has a very interesting article about removing 2 keywords (‘new’ and ‘this’) from Javascript to make OOP easier. Basically he’s built a library (zet.js) that disallows the ‘new’ and ‘this’ keywords. It’s a great effort to reduce the complexity of OOP in Javascript, and he has my admiration for trying to do it.
However I do have a problem here, not with Maks, but with Javascript OOP. I just don’t think it should be attempted. My (admittedly limited) experience with trying to shoehorn OO in to Javascript code and to get it to play nice with non-OO code is something I’d rather forget. Perhaps I was doing it wrong. But other languages (Perl, Python, etc) manage to make it easy. I just could never get Javascript to play nicely with OO code. Maybe someone can give me a decent tutorial and I’ll understand more…?

Well for me it’s a bitch. Maybe not for you. But then do you work in a large team, small team, or on your own?

Any version control system (vcs) is useful to a degree. Where most of my peers (myself included) seem to hit a problem is with merges. Branching is great. We love branches. Need a new feature? Let’s branch and test it. Found a bug? Let’s branch and fix it. Now hold on,  we need to merge it back to baseline as well? Oh ****! (<- inset explitive of choice)

Now, I’ve only worked with CVS and Subversion, so I can’t speak for any other vcs or distributed vcs (dvcs), such as Git or Mercurial, even though I’ve read a lot about all of them and seen the gripes others have had.
But with CVS/Subversion branching is easy, merging is hard. At least if you’re in a reasonable enough size team that doing lots of changes to the same baseline, or you’re fixing lot s of bugs that you’re branching for each time (which in my opinion is wrong anyway, but I’ll go into detail about another time).

Consider the diagram below:

This is a typical 2 branch Subversion workflow (or at least it is for me). Far too much time is spent in resolving potential conflicts on merges, updating your working copy from the branch (in case any one else has submitted changes), updating the branch from the baseline (in case the baseline has changes from other branches).  I have no hard figures to back this up, but my gut feeling from working this way for far too long is that roughly somewhere between 20 to 40% of my time is spent doing vcs tasks. And that only increases with the number of team members working on the same projet, and the number of branches. That is so wrong. And that’s all down to having to merge between branches and the baseline.
But what better way is there? Would a dcvs work better? Would a different vcs work better? Honestly, I don’t know. Perhaps someone can suggest a better work flow. Perhaps a vcs isn’t the right method anyway…

There seems to be a small war being waged between Python and Ruby at the moment(here, for example). I can’t understand why, clearly someone has a bee on their bonnet, and won’t stop until one side capitulates. As I’ve mentioned before though, I don’t see why language wars are needed. But then again, who listens to me

A recent discussion with a good friend threw up some memories of a few problems I have with virtualisation, or at least what I would expect a good virtualised platform to provide me with. Maybe I’m expecting too much, or maybe what I’m looking for already exists. If it does already exist then perhaps someone would be kind enough to point me towards it.
But perhaps first I should explain the problem and what I see as the ideal solution and what I’m expecting to find.

Problem: A particular coding problem needs to run for a long time. The code could be re-written to use threads, or be run several times on smaller data-sets. However, imagine for now those options are too expensive, financially. So, the user has a single core box to run this on.  Oh, hold on, he’s got 10 single core boxes sitting idle that he could use, but how to split the load. The user wants to use some kind of virtualisation but doesn’t know how to link the boxes to form 1 VM, or how to split the load across the multiple available cores even once he’s linked the boxes.

Solution: So, that’s the basic problem I’m dealing with; how to make multiple cores, on seperate boxes not only appear to be a single VM, but also for the user not to care how many cores are available, just that the code that’s run on them (including the OS if possible) can take advantage of the extra cores without any extra code being written.

Maybe I’m being naive to expect a reasonable answer to this dilemma,  or maybe there isn’t an answer that’s as easy to implement as I’d like (I suspect that part to be particularly true).

Anyway, if anyone can suggest a solution to this then I’d be eternally grateful.

Think you know what type theory is? If you don’t, or if you’re not sure, or even if you think you do and want to check what you think is correct actually is correct, then check out this ACM article. It’s great.

Bruce Eckel has managed to sum up some of my current thoughts. I don’t believe for one moment that thinking the same thing as an industry heavyweight makes me any better, but it’s nice to know I’m not alone in what/how I think

Over at DCS Media, there’s a small but insightful post about 20 programming lessons that Jonathan Danylko has learned in 20 years of programming. Hey, guess what, I’ve been preaching some of these too! Look at no.2 ffs!

David Mosher has a great post explaining his own version of the (now) classic 3 programmer virtues by Larry Wall. I totally agree with David on his points. I don’t think there are just 3 characteristics, but the 3 he describes (passion, perfection & perseverance) are relevant to any good (and I’d say great) programmers.

Just read a great post about using an “unlicense” license to make sure your code is really free. Having followed through to unlicense.org and read all the blurb I can honestly say that I will most likely be following Zach’s example with all future code.