Found this in the slides for a presentation by Jim Weirich entitled “10 things every Java programmer should know about Ruby”:
A language that doesn’t affect the way you think about programming is not worth knowing — Alan Perlis
Amen, brother!
A little searching reveals that it was included in a collection of such pearls of wisdom in an article entitled “Epigrams on programming“, published back in 1982. Some have aged poorly, and some I just disagree with, but there are some real gems and this is one of them.
There have arguably been five significant milestones for me in my development as a programmer:
- Learning to program (almost entirely self-taught, first on a TI-59 programmable calculator in Jr. High, and then on a TRS-80 Model 1, 16K, Level 2 BASIC in High School)
- Learning structured programming and memory management (PASCAL, then C, while an undergraduate)
- Learning (in graduate school) to think of programs as formal, mathematical texts, which can be reasoned about in a mathematical way. This included learning pure functional programming (Miranda) and then taking a wonderful and head bending course on the formal derivation of programs from specifications taught by Edsger Dijkstra.
- Learning object-oriented programming (C++, Eiffel, and Java) as part of my teaching here at UMM.
- Moving from a kinda-sorta waterfall model of software development to understanding and embracing agile development methods (again as part of my teaching here at UMM). There was no programming language, per se, but ideas and tools such as test-driven development, JUnit, Clover, refactoring, and Eclipse all played important roles and certainly changed the way I think about programming.
Of those, probably the hardest was probably really “getting” objects after all those years of C. It was the first major transition (since my initial forays into BASIC) that was entirely self-taught, and really changing the way I thought about the structure of software was tough. Now, on those odd (and thankfully very rare) occassions when I find myself leaving the world of objects, it’s amazing how strange and foreign the old ways seem and feel.
It’s been a while since I’ve learned a programming language that stretched my head and helped me rethink some important things. I think Ruby has the potential to open up some new doors (if small ones), and Rails is pretty darn cool, so I’m looking forward to becoming more conversant in those universes.
Having recently come upon the agile development process while working in a company that has lived waterfall for years, I had to smile at this post. It becomes difficult for me to see how waterfall ever worked on a project of any complexity. Im not sure if that is because agile fits my way thinking and working, or if it is a great explanation for how most of us work and think when tackling multifaceted projects.
Amen, brother! We struggled for several years to teach some flavor of waterfall in our Software Design and Development course, but the students constantly fought it. We kept telling them to do lots of up-front design and documentation, but their lack of experience with doing that sort of design (or building anything very big) made the exercise frustrating and fruitless. So they did what we made them do, and then ignored all that design work when they were finally allowed to build the system. They instinctively knew that the situation was too unstable (for a whole lot of reasons) for Big Design Up Front to make any sense.
When I read Beck’s Extreme Programming explained (first edition arguably much better than the new, second edition) it was a really blinding revelation. Beck was essentially outlining and supporting what the students had been trying to do intuitively, and which we had all too often been fighting. When we switched to use more agile methods, the success in that course improved enormously.