Links published on September 3, 2006
Yawning public puts convergence on skids - survey
Ah, Andrew Orlowski. The man can’t even manage to be consistent within the same article. Compare this bit:
The survey shows consumers express a slight, but firm preference for having one device that does music on the go, with the preference being that it should be a phone. Farewell, then iPod - we’ll see you in the section today reserved for PDAs at Circuit City (ie, locked away, under the counter) fairly soon.
With this bit:
Refreshingly, a whacking 80 per cent of respondents said they didn’t need any new kind of converged gizmo at all right now, thank you. 44 per cent said they weren’t interested at all, and 36 per cent said they were fine with what they had, all the same.
So… the preference is for one device, probably a phone, to pick up multiple duties, which means the iPod should soon go on the junk heap. But the preference is also against getting one device that picks up multiple duties, and most people aren’t interested in switching out what they already have Which, judging from market share, is probably an iPod.
Hmm.
OO, FP, Erlang, and Me
I’m not sure I buy this:
When I finally felt that I ‘got’ Erlang, never once did I miss a single OO construct. In fact, I started regarding OO as a burden. In OO languages, every class, every method, every field has so much context around it. To understand where piece of code fits into the big picture, you have to read through the documentation for all the classes and interfaces to which it belongs. Also, OO languages often encourage if not force you to wedge your types into some inhertiance chain in order to reuse code, which results in ugly inhertiance relations that are inflexible at best.
Functional languages like Erlang have the opposite philosophy. They try to minimize the context surrounding a piece of logic— a function. All you have to know is what parameters a function takes and what it returns. There is no implicit link between the function and the data it uses. With single-assignment, you don’t even have to worry about functions mangling the values of your variables. When you’re coding in Erlang as opposed to Java, you think less about the context of your functions and more about what they do and how to compose them together to solve your problem.
Specifically, I’m not sure that “a class which inherits from a class which inherits from a class which inherits from a class…” is necessarily any worse (or any better) than “a function which is called by a function which is called by a function which is called by a function…”
Context is always important. Rooting your development in one high-level abstraction instead of another high-level abstraction probably won’t yield objective gains (though, depending on your mental makeup, it may yield significant subjective gains). The only magic bullet for architectural complexity is architectural simplicity.