Symphonious

Loud Thinking:

Finally, the new economics of dynamic languages like Ruby simply makes reuse a lot less attractive. Since the cost of producing new, original code is so much lower…

Hang a tick, why is new code cheaper with dynamic languages? Sure, you can write the code faster but the vast majority of cost involved in code isn't spent up front, it's spent in maintenance. So writing new code hurts because you don't take advantage of all the money already spent on maintaining existing code and instead incur extra maintenance cost.  Even if the initial cost of writing new code was reduced to zero, new code would still be very expensive purely because of the maintenance element.

I might buy it that programmers are more productive using dynamic languages, I can't see any evidence that dynamic languages have any significant impact on maintenance costs. In fact, a lot of the flexibility of dynamic languages can make it very difficult to maintain the code because it can be hard to find where the cause of the fault is.

I've been mostly ignoring the uproar about how Steve Jobs "lied" about how much faster the Intel iMac is opposed to the G5 iMac. Expecting benchmarks to reflect any form of reality is just plain ignorant of the complexities of modern computing.

Despite thing, there's a great irony which has just dawned on me. If Steve Jobs is clearly lying about how much faster the Intel iMac is over the G5 iMac, then clearly he wasn't lying when he was pushing the G5 chip and pointing out how fast it is compared to those crappy Intel chips. You remember those old photoshop bake-offs that everyone mocked right?

It appears to me, the incessant Apple bashers are somewhat snookered. Then again, with Apple switching to Intel, the Apple fanboys who have spent so much time arguing for the G5 are just as snookered.

With both camps now proven wrong, couldn't we all just get along?

Here's a tip for you, anytime you hear someone say, "The XML specs aren't really that complicated", you know they haven't tried to work with XML in any detail.  For a start, as soon as you start using the term "specs" instead of "spec", you've got something that's going to difficult to piece together.  When you get to the vast number of specs involved when working with XML, you've got a weeks reading just to get through them all.

Then you get the corner cases, the little oddities that trip people up. Prefixes vs name spaces, default name space and attributes, document node vs root node, the perennial "entities, characters, charsets and you". That's before you start trying to do anything with validation, DOMs, XSLT and the like.  This stuff is seriously big and seriously complex.

That said, all that complexity serves a very important purpose and I'm not suggesting that it should be removed from XML or that XML should necessarily be changed (though many others would). I just find it so amusing whenever people complain about some XML producing or consuming product not being 100% perfectly compliant with the standards because it's just so easy to produce valid XML. Anyone who thinks that either hasn't really worked with XML or has worked with XML so much they've forgotten what it's like to try to learn (hint: these people are often on expert groups related to devising XML standards).

I'd like to be able to play around with the photos in my iPhoto library without having to export them first. Do APIs exist for accessing this stuff or is there an opensource library available somewhere that can read the iPhoto Library data? Google searches tend to indicate there isn't any but I thought I'd ask the lazy web.

Brain Sparks has an interesting critique of the findings from that infamous study suggesting that users make judgments about a web site in the first 50ms. Turns out there's no evidence in the study to suggest that users will leave your site if that first 50ms doesn't look good - they'll just think it's ugly.

Thankfully, we're not as fickle as some people seem to think we are.