[kangdolit]

"All non-trivial abstractions, to some degree, are leaky." - Joel Spolsky

> In my experience, learning OO design patterns was substantially more difficult than learning algebra, but I think this is mainly due to how CS education is carried out in many universities.

You supported my argument. In addition to this, there are many code academies that pump out graduates with almost no mathematical foundation work. Until that changes, functional languages will always take the back seat.

[lmm]

> "All non-trivial abstractions, to some degree, are leaky." - Joel Spolsky

If you learn Haskell you will see this is total bollocks.

[mrob]

What's the Haskell code for preventing me touching the power switch?

[runT1ME]

I think you fundamentally misunderstand what the word abstraction means and the point of it.

[lmm]

Touching the power switch will not lead to an incorrect result being returned.

[mrob]

A late result is an incorrect result in real-time systems. And if time isn't an issue, what's the Haskell code that stops me overclocking the CPU enough to make it unreliable?

All software is leaky abstraction because it doesn't run on abstract mathematics, it runs on hardware. I can literally smash it with a hammer and then all the "guarantees" are worthless.

[tathougies]

> All software is leaky abstraction because it doesn't run on abstract mathematics, it runs on hardware. I can literally smash it with a hammer and then all the "guarantees" are worthless.

Man, if that were the only thing that could make software go wrong, we would live in a much better world.

[lmm]

If the CPU violates its spec then the code will violate its spec, sure. That's not an abstraction leak though - if the CPU violates its spec then hand-crafted assembly would also go wrong.