Yeah. I'm that guy that just orders a double espresso. I'd be happy with fresh black filter coffee too.

SVN works well with a single up to date master, but that model eventually breaks if you want to have experimental features. At some point that will become a need -- trying something outside the main branch that is actively being deployed. Git is a bit of a pain at first but you simply can't do the things git does in svn.

I use SVN at work and for a small number of developers it works decently well. SVN is quick to set up and to learn -- it somehow feels easy. I agree with the TortoiseSVN as a client -- all of that works quite well. However. Doing merges in SVN is an absolute nightmare. The "cherry picking" model of implementing features and merging them back in, one by one, as code gets ripe is painful in SVN. There is a learning curve for git, but not much more so that for SVN, and the habit of using a feature branch and merging back feels logical and the right thing to do.

Peugeot makes them: http://www.peugeot.co.uk/hybri...

Are you sure? http://www.telegraph.co.uk/new...

Try Cambridge, with companies like ARM, Cambridge Silicon Radio/CSR (several billion chips sold) Cambridge University. Plenty of money in London, Europe's financial centre. Plenty of talent around, or attractable due to English being the universal language and European borders being open -- or old colonial ties. Or try Berlin for "frontier living".

Is it an African or a European gyrocopter?

In Berlin, after the war, trams were used to haul freight.

Irish / English law are often alike: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.gov.uk%2Fright-of-wa...

Buy low, sell high.

Normally a lookup table would be the way to go. There's always a why -- in this case it was a slow microcontroller with 16KByte of codespace, which was already cramped. Table won't fit.

I live in the UK, about an hour away from London. I have been to New York, but only once.

London has existed for over a thousand years. It has just grown organically. All recent services (such luxuries as underground, trains, ringroads, mains water, electricity, sewers, communication lines) have been retrofitted on that base -- and it shows. The roads are the wrong size for the amount of traffic -- trains clash and are overfull, high rise offices are planned but foundations have to carefully avoid all the tunneling below.

New York, in it's current form, is a lot younger than that. A lot of the concepts "we might want sewers" / electricity / rail, to some extend, could be taken into account when the city grid was being laid out. It's a lot easier to build sewers / underground trains before high rise buildings have gone up on top.

Back to the software world -- if you've got code that was pre-Web / pre-Internet but needs to be brought into the 21st century, inevitably things won't fit. I've worked on some banking code which had punchcard assumptions shine through. Some of that code is 40 years old. You could call it crufty, some would call it rock-solid.

I respectfully disagree.

I've written code that computes a CRC. It's been done before. The naive/reference implementation works but isn't fast. The optimized version, and how the heck that came about from the naive implementation to those magic few lines of code, looks nothing like it. Now rather than you glazing over "what the?", I figure that *if* you have to overhaul this code, you'd like to know *why* this code looks like it does. So I explained why. In the code. In a full page of comments.

Interesting code, serves a real purpose, solves a real problem.

A lot of "real world" code out there has not been designed, it has grown, and that's part of the problem. Think of cities that have grown (London?) rather than be designed according to some grand master plan (New York?) and major reengineering exercises need to be undertaken (in the case of London, as one example, sewage pipes were fitted in underneath). Inevitably there's some shortcuts taken or real reasons that you could not quite do the best job.

Codewise, the oldest running code probably lives in the banking system or the telephony system. Typically code that has grown over time and can't just be shut down for an upgrade -- "what do you mean close the bank for a week?". Now whatever code runs there has been kept running (bodged?) for decades, but pretty it probably isn't.

http://www.reuters.com/article...