The Agnostic Coder

Please go and read this: Microsoft’s Charney suggests ‘Net tax to clean computers | ITworld. This kind of s**t really f***s me off! Microsoft want to charge everyone for cleaning up a mess that they should be paying for and frankly being sued for, in my opinion. M$ should have taken security more seriously starting with Windows 95. Most of the bot nets are compromised MS Windows machines, and why? Because the default security is f***ed. Unbelievable! Programmers, and the companies they work for while producing this s**t code should be held responsible for the mess they create. If this was the automobile industry, or the construction industry, they’d have been sued out of existence by now. When will the courts and governments realise that bad coding and poor coding practices are making this world worse, and punish those who make the software?!

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…

“My language is better than yours at doing X!”

“Yeah, well mine’s better at doing Y!”

Yep, we’ve all been there, well most of us have I’m sure. Someone likes Perl. Someone else likes Ruby. Someone else likes Java (really? you sure?! just kidding )

Here’s a classic example that popped up recently http://blog.obiefernandez.com/content/2009/04/my-reasoned-response-about-scala-at-twitter.html. The article itself is well readable, although it does come across quite critical of Alex Payne, and of the use of Scala at Twitter. But the comments are pure flame bait.

There are countless similar examples all over the Googles back yard (or the Internet as some call it). So why drives people to start flame wars? I’d hazard a guess it’s the same thing that drives all wars. Religion. Of course some people wouldn’t call it that. Think of it as belief in your a programming deity, where each language has its own deity, and belief system. Java followers pray towards the Sun HQ, Ruby devotees bend their knees towards Japan, and Perls acolytes simply grow longer beards and get on with the job at hand. But whatever faith/language you choose there are ways to piss off the other guys, the ones that don’t believe the same as you do.

And the sad part is that there is nothing to be gained from flame wars like this. I would very highly doubt that anyone from camp A has been persuaded to give up their language of choice and side with camp B just becuase they read a ranting post in a flame war thread. Have you? Seriously?

The fact of the matter is, in 99.999% of situations language A is going to work just as well as language B. Yes there are fringe cases. Yes there will always be ways you can make it look like language B is faster.  An unbiased benchmark of all current major languages in every possible permutation is of course impossible. So how do you choose? Do you have to? Well, yes, I’m sure some of us do. Most of us will be forced into using a particular language via our job, via our experience. But for those projects where you can choose the language, how do you? How about this?:

• Is it your first programming exercise? Yes – choose C (seriously, do it, you’ll learn the most this way). No – choose the language you’re most familiar with.

That’s it. Simple, yes?. Good. Right, now stop writing incediary posts on blogs and twitter et all, and spend time sharpening your skills. Then when the time is right, and you really do need to argue why your language is better suited to a particular implementation you’ll know the ins and outs and gotchas of your language better than the other guy, because he won’t have read this and so he’ll still be starting flame wars that don’t matter.

Have fun!

By framework I mean the MVC crud (and I don’t mean crud as in MVC CRUD either), the stuff that other people spend ages writing that apparently speeds up your development process by a factor of infinity, but only until a) you want to write something that the framework doesn’t natively do, or b) you have a bug, and you can’t find it in your code and you suspect the framework, but hey why would the framework have a bug it’s being used by millions of people all over the world, surely?!, or c) well I can’t think of another reason but I’m sure there is one.

MVC frameworks are supposed to separate your logic, database, and purdy html code so that the poor developer(s) don’t get confused and start writing database queries inside html, or heaven forbid write anything where the framework designer said it shouldn’t be written. Godly delusions, that’s probably what leads people to write frameworks. Why would I want to use your 500,000 line framework when I can write my application in 500 lines, and make it a) work, and b) be quick, and c) scale it up without have to put the whole crudding framework on again and make sure I’ve got all of the 400+ dependancies installed and at the correct version?

Bah, just let me code.

Why would anyone think otherwise. The algorithms are at the very heart of the language. The language wouldn’t exist without them, whatever the language is.  And the particular algorithms that a language uses in it’s core libraries will make or break the languages use, because if the core is slow, all dependencies are slow too. Therefore adoption is stunted, and the language dies into obscurity. It’s evolution of the programming language.