Jeremy Shaw sent me this bit about a DVD rewinder. Very humorous, of course, but there's also a nice little moral about programming in there.
When I was at Linspire, we often got questions from people looking to switch to Linux for the first time: How do I defrag my disk? Where do I buy anti-virus software?
We would explain that Linux filesystems didn't need defragmenting and that the virus problem was virtually non-existent. But sometimes, there was just no reassuring them. IT people sometimes said they simply had to have virus protection software, bought and paid for, because the company had made it mandatory for all computers. We felt a little silly, but we licensed one, shipped it and then they switched.
I wonder how many people learning a functional language wondered how to allocate and deallocate memory like they did in C? Whether the answer is obvious or not depends on one's understanding of the semantics of the language. If you have a model of C semantics in your head and you're looking at Haskell code, you're predictions about what's going to happen are bound to be wrong.
All these are examples of essentially the same problem. If we can't see (or otherwise sense) how a technology works, then a change in the underlying mechanism will leave us confused because our mental models are out of date.
I tend to prefer designs that show a technology at work, such as record players as opposed to most CD or DVD players. Unfortunately, miniaturization and digitalization only make the problem worse. I suppose that's why Hollywood always has been at the forefront of computer graphics, because the audience has no idea what's going on without all the flashing lights.
I will pursue these ideas further in some upcoming posts about functional programming and user interface design.
Subscribe to:
Post Comments (Atom)
5 comments:
One that I see a lot is, "How would you do this in Haskell?"
a = 1
a = a + 1
And the answer is difficult because you have to explain why you don't need to do that.
word. that's a neat observation. got me thinking:
1. it's good to come to a design/discussion table aware of the possibility of assumptions so that one asks the right questions at the beginning
2. other people have assumptions, too, but that doesn't mean they're stupid.
i hear that about seeing how things work over digital hiddenness. but i know that everyone shouldn't be using record players, so how do we make this scale? it's similar to enjoying empowerment while dealing with specialization.
I have read about this theme mentioned a few times in Python forums. They call it "Pythonic code". I think the mind shift is a difficult thing if you are used to solving a problem at a certain level (with certain mental model).
In the case of software, the best way to make this transition easier is to show a piece of code from one language (say Java) and show how it can be done in language like Python or Ruby.
In essence, you need to define the QWON (quality with out a name) of the new approach.
It is not just about programming languages. It is about the shifts that happen due to technology as well.
While MP3 players started as smaller/better walkmans, now they are audio-book players and reminding devices, as well.
I'd guess that questions about memory allocation are rare compared to "How do I define and create classes and objects?" for Haskell.
Appreciate your blog post
Post a Comment