Jules May's posts on the arts of programming
Guest author Pete Libman writes:
You are sitting at your screen wearing a t-shirt with some witty clever tech joke on it, reading some blog written by a bloke who probably looks a lot like the guy from the comic shop in The Simpsons.
Monolithic databases are so 80s, inflexible, they are an obstacle to change. Referential integrity stops us implementing service orientated architecture, and they cannot be harmonised with continuous delivery.
Do you agree?
I have made a discovery. You might think it’s obvious, but it was new to me. It was this: that programmers come in different shapes and sizes.
When was the last time you read through someone else’s code, not because you were looking for a snippet to pinch or because you’ve been saddled with debugging it; but for the sheer joy of reading someone else’s elegant, witty, creative code?
Modern computer systems couldn’t function without it, and it’s at the heart of nearly every modern software development. And yet, the very mention of its name is enough to strike terror into the hearts of even hardened developers. Why is multi-threading so difficult?
For more than thirty years, alongside conventional language development, there’s been a small but thriving culture of functional languages. These are not like the languages we all know and love. Their most obvious property is that they contain no variables at all; instead, they describe truths about the problem to be solved[1].
As anyone with even a passing familiarity with functional programming knows (and I accept that passing familiarity usually comes only after three to five years), things in a functional language don’t do anything (the way procedures execute or variables change in conventional languages); instead they are something, and what they are never changes. A term may describe a function which defines a list of primes, or it may describe what it means to be an expression, or what-have-you. But whatever it is, it describes it once and for all time – the function is the list of primes, it’s not a sequence of operations to compute the list.
Proponents of functional languages claim that by talking exclusively in terms of values, you get shorter, simpler, and more reliable programs. If things are things, rather than do things, they reason, then if they ever work, they’ll always work. If nothing ever changes, where can a bug hide?
de Programandis 