A language that doesn’t affect the way you think about programming, is not worth knowing. — Alan Perlis
Just now I was pondering my progression through various programming languages and paradigms over the 28 years that I’ve been playing around with computers (almost 23 professionally as of this writing). My attitudes toward several of the languages I’ve used over that time looked something like the following:
- (1984) Basic is COOL!
- (1985) This COMAL stuff is neat, but how do you program without line numbers?
- (1986) Basic’s all right, I guess, but what’s this C thing?
- (1987) C is hard.
- (1988) C is COOL!
- (1989) COBOL is… verbose. Eww.
- (1990) Natural is fun, especially after I get my listings back from the data center!
- (1991) Visual Basic is entertaining. Hmm, how do I call
- (1992) C is… meh. C++ looks interesting.
- (1993) C++ is OMG FLKJSDF I HAVE FOUND NIRVANA!!!11!1
- (1994) C++ is the optimal language for expressing multi-paradigmatic software solutions most suitable for a given problem domain.
- (1995) MFC is COOL!
- (1996) MFC Internals will finally let me learn MFC inside-out!
- (1997) I finally know MFC inside-out. MFC is horrible!
- (1998) This crash dump is confusing. I wish I had learned assembly language.
- (1999) Assembly language is confusing.
- (2000) Java is interesting.
- (2002) Java isn’t all that interesting.
- (2003) Is C# really Java without training wheels, or is it C++ with training wheels?
- (2004) Why don’t I just write this app in C#? I can get it done a lot more quickly, it’ll be easier to read, and, my word, it’s fast!
- (2005) C, my old nemesis, we meet again.
- (2006) Why don’t I just write this app in C? I can get it done a lot more quickly, it’ll be easier to read, and, my word, it’s fast!
- (2008) Assembly language is so easy! Oh, no, here comes another programmer with a crash dump for me to analyze.
- (2009) MSIL is cool. Why won’t C# let me do all this stuff?
- (2010) I’ll write a DLL in C++ and make it callable from C since it’s so much easier than dealing with COM interface pointers.
Now, obviously, I’m not done. I figure I’ve got another 20 good years in me, and probably a lot of not-so-good ones after that. I plan to learn many more programming languages in the future, and my ideas about what works and what doesn’t are probably going to… let’s just say “evolve.”
You’ll notice that I mentioned MFC as a language in the list above. I actually do regard MFC as a language, not a library. It pre-dates standard C++, and it carries a lot of cruft around as a result of that. It’s almost entirely object-oriented; in fact, I’d say it tries to shoehorn everything into an object-oriented view of a world that isn’t always OO. When I am forced to modify or maintain an MFC source base I actually have to forget everything I usually apply to C++ and downshift into thinking in terms of MFC, and it’s terribly frustrating. I read the book MFC Internals around the same time I read Design Patterns, and when I got done with both books I swore off of MFC for any new code. It still makes me shudder.
Library design is language design — Bjarne Stroustrup
Nor is the list above a complete one. I left off a few languages like LISP, Powershell, Pascal, and several others that I’ve used at various times and that had a significant impact on my programming style. Overall, I think a programmer should learn a lot of languages in order to gain exposure to different ways of not only solving problems, but of thinking about problems. My knock on MFC (fitting every problem into an OO box) applies to other languages and paradigms as well (C and structured programming, Haskell and functional programming, Java and OO, etc.).