I'm currently reading an excellent book called Everyday Scripting. I'm really enjoying it as a nice primer on whipping things up with Ruby. When I hit chapter 7 the author began to discuss a programming style that I have used for a while now. I had no idea this simple technique had a name. Many of the things I've picked up throughout my career I've learned from books, articles, reading code, and still others I've devised from first principals. This particular practice I picked up while pair programming with this super smart guy Peter Seibel. Apparently it's called "Programming by Wishful thinking."
The idea is that when you have some code to write you first do so as if methods existed already to perform the high level operations. Say you want to write some code that tells you how many songs and albums you have by a given artist. Programming languages don't have methods do to this baked in but you pretend they do. An extreme example of the practice would be:
I came up with this example in about thirty seconds so I hope it isn't to opaque.
You may then go on to write the above methods in the same way:
and so on and so on. Anyway, don't know how many people out there use this style but I've found it really helpful when I need to keep focused on the task/flow at hand without getting to distracted by the details of an issue. Maybe it will help someone else too.
Subscribe to:
Post Comments (Atom)
Posts
11 comments:
All the time! Thanks for posting this I also didn't know that it has a name.
Actually, this method is quite common (what I know, at least I use it and some of my colleagues).
Thus, I would call it "intentional" rather than "wishful".
--
To give a sort of strange and maybe too far analogy: Test-Driven Development (TDD) is about writing your tests first, and then caring about the business logic.
--
I think, coming from a high-level view and then going down to a more detailled level is a natural way for organized persons :-)
I was taught to program using this style about 10 years ago in my introductory programming course where Smalltalk was the language of instruction.
I thought it was called "top down"
http://en.wikipedia.org/wiki/Top_down
I think test driven design takes this a step further - instead of writing actual production code that uses methods that you haven't implemented yet, you write tests first that do so. This can really help you think through what API is needed as you're not just writing code that uses the API, but you actually think about edge cases and so on too.
A step further from this is doctest based programming, where instead of writing a normal test, you write developer documentation with test fragments embedded. This helps you focus on what API is needed even more, in my experience.
http://en.wikipedia.org/wiki/Doctest
I especially like the option where doctests are embedded in .txt files, as these are developer documentation. Often not great developer documentation, but a lot better than no developer documentation, which tends to be the alternative.
Note that test-first programming or doctest-first programming is actually a process of co-evolution. I start out writing a doctest txt file describing what I want, then implement a bit, revise my doctest as I think things through, revise the code, extend the doctest, extend the code, and so on.
I don't think anyone was saying this is new. I was only pointing out two things:
1) That I didn't know it had a name
2) That I have found it useful
I used to do a bit of Smalltalk back then too. It's a lot of fun. Probably why I picked up the Ruby book
I think the top down thing does sound quite similar though more at a sub-system level. This strategy is super important when building a complex system. I usually dummy up interfaces and basic implementations of things in order to pass tests while I'm building a multi subsystem app/framework.
The test driven design thing while also a very useful concept feels a bit different. I tend to do this kind of stuff in response to a test I may have written to help me sort through what I want an algorithm to do. Maybe my example wasn't good.
wow, pair programming with Peter Seibel must've been a blast. His book on lisp (PCL: Practical Common Lisp) is probably one of the best programming books ever written. And wishful thinking is praised by Gerald Jay Sussman (co-authored, with Hal Abelsson, the book 'Structure and Interpretation of Computer Programs') as a foundation of programming (he shows it off using Scheme though). Wishful thinking is extremely easy on Lisp, specially because it lets you go beyond the actual language, if it imposes limitations to you.
Not that you didnt know that already (if you paired programmed with Seibel, you probably know :D ) but well, comments are for everybody.
As some grandmother probably said somewhere sometime: "Nothing new under the sun". All you have to do is give it a name :)
Intention-Revealing Interfaces
may be.See DDD
I'm the author of the book cited. I got the name from Abelson and Sussman. (Don't want anyone to think I claimed the phrase was original to me, much less the idea.)
I do like "wishful thinking" over other descriptions, though, because it promotes the right Devil-may-care attitude: "Why *of course* the perfect method for me exists, so I'll write my code the way it should be, rather than distort it to meet what's available... Oh rats, it doesn't exist. Guess I'll have to write an adapter."
Its funny. I am reading 'Everyday-Scripting' too and I am thankful that I got a name for this technique which I like a lot.
In fact, my first aha moment in software design was when I discovered this technique on my own.
Rajiv
Post a Comment