A counterpoint to this post from my colleague Sam.

It’s not technical. Languages don’t succeed for technical reasons. If this were true we’d all be programming in Lisp and Smalltalk. Java became popular by riding the internet (specifically the web) wave. .Net became popular because Microsoft have billions of dollars to spend on marketing. Both of these platforms have something in common – they are aggressively marketed by a big industry name.

Write once, run anywhere. Sun coined the term, and successfully won the mindshare. Developers working in Lisp & Smalltalk wondered what was so special about that.

Garbage collection. Most work in garbage collection was done in the 70’s and 80’s (possibly even earlier – Lisp has been around since the 60’s). Again marketed heavily by Sun, while the aforementioned Lisp and Smalltalk programmers looked on nonplussed.

Lisp didn’t take over the world because (to my knowledge) there was no big name vendor marketing it, and everyone outside the Lisp community thought it was just for AI.

Smalltalk didn’t take over the world because of infighting between vendors, and a failure to see the threat of Java. They were too busy competing with each other to notice that Java was about to swamp all of them.

Having said that, there are places where Smalltalk and Lisp are thriving, and those companies are more than happy for everyone else to remain distracted by Java and .Net while they consistently outperform them in time-to-market of new features.

Looks like the Sixapart, the creators of Moveable Type, have gone all commercial and VC funded on us. I look forward to explosive growth followed by burnout, collapse and recrimination. Maybe they’ll get lucky and be the 1 in 10 that make it.

Woke up this morning convinced, convinced it was thursday. Someone on the tv just mentioned that it was friday, and it was like I’d been given a huge and unexpected present. Bonus. What a great way to start the day.

Don’t get me wrong, I love Rails. Its great to see something that isn’t .Net or Java gaining traction. ThoughtWorks has an internal mailing list about it and the traffic has been impressive so far.

Its just that now more than 25 people have heard about it, well, it feels like its gone all mainstream.

So I’m splitting my cool-new-dynamic-language-based-web-application-framework bandwidth between Rails and Seaside.

Today I saw something in Seaside that gave me one of those ‘Dude, that so totally rocks‘ moments.

There’s an innocent toolbar option in Seaside called ‘Toggle Halos’ that switches on a visual representation of the components on a page, with some icons for each one. One of the icons looks like a spanner (wrench), and when clicked on, shows you the code for the component in your browser, and lets you edit it!

Oh yes. Welcome to really rapid application development.

The software industry really needs an equivalent to Perry’s, the chemical engineering reference guide. This book more or less contains all the information needed to build your own functioning oil refinery or other chemical engineering construct.

Hyperthreading notwithstanding, one thread per cpu will give you the highest application performance. Having more than that means context switching and contention, which means the cpu is spending time on tasks other than running your program.

For this reason, the fastCGI approach to web application servers is definitely a good thing – prefork a fixed number of single-threaded processes to handle requests, one per cpu.

So why spawn more threads or processes than cpus? Blocking. If a thread blocks, its out of action until the thing its waiting for is ready. With 1 thread per cpu, if a thread ever blocks, thats a whole cpu idle. To implement an application that never blocks, especially when it needs to make network calls (eg. to a database), or read files, is more challenging than doing the same thing with blocking calls and many threads.

Bought the 1st series of the remade Battlestar Galactica yesterday. Much darker and edgier than the original. None of the characters appear to be all-bad or all-good, and most of them have ‘issues’ of some kind.

One of the characters was working on a Cylon detector (Cylons are the bad guys, robots that look like people and want to wipe out humanity, although some are programmed to think they’re human), and there’s a scene where we see the UI for the first time: red bar / green bar!

Introducing CyUnit. Red bar, failing test, you’re a Cylon. Green bar, you’re human. Made me laugh, geek that I am.

The combination of DHTML, Javascript and XMLHttpRequest has been making weblog headlines recently. My experience with it predated the hype by about 6 months (we were porting a rich client system to the web and hit upon using XMLHttpRequest specifically as a solution to some of the responsiveness issues). I was a little slow to realise just how unknown the technology was in the wider world, but I don’t mind that, so much as the appalling name its come to be known by.

Ajax? It sounds like a brand of detergent. Oh wait. It is.

Picking up the ‘schema as 3rd party code’ idea, I want my database access to be encapsulated behind an insulation layer that decouples the business logic from the table schema.

This is the primary reason I have mostly lost interest in tools such as Hibernate and Neo. Where the documentation says things like ‘Autogenerate your mapping layer and persist your domain objects’, I see ‘Tightly couple your code to your database’.

Relational databases are hard to change. Especially once they’ve gone live. They very quickly foster an ecosystem of reports and queries, and almost always become an ad-hoc integration point for several applications, making schema changes very difficult.

For this reason alone, any tool which works by coupling business logic to to the database causes me concern. On almost every project I’ve seen that had an OO application and a relational DB, the persistence mechanism became a point of pain. Code becomes really hard to change because its constrained by the database schema and there’s usually an additional maintenance burden of keeping an XML configuration file in sync.

Or, ‘Just because its open source I don’t want to have to compile it every time’.

Dee mentioned using vendor branches to manage 3rd party source.

I choose to avoid them. If I’m using a 3rd party library, I want a released binary. Recompiling someone else’s source as well as my own seems like a waste of time.

With respect to ‘fixing in place’, sure, if I know a solution I’ll submit a patch, but fixing in place means forking the 3rd party codebase, which (depending on the license) might oblige me to release it back to the community (which means time spent not getting work done), and opens a real potential for causing merge hell when I want to use a new version of the library. This happened to me a few weeks ago. Had the project done either of encapsulating access to the 3rd party code, or stuck with a binary version, the upgrade would have been far easier.