Join the Polyglots!
I’ve been writing software professionally for 9 years now, and unprofessionally for 18. My recent focus has been on C#, but I’ve worked with many languages over the years.
When I was in the 7th grade, one of the other students made a Myst clone with Hypercard using photos taken around the school. That seemed like pure magic, so I wanted to find out how software is made. Like most people who get into this subject at an early age, my goal was to make games.
My first programming language was Pascal. I used Turbo Pascal, whose IDE lived in text mode. It actually had a pretty decent debugger, one quite similar to what you get with Visual Studio today. Pascal is a little verbose with keywords, but that came in handy to a total newbie. Its type system was simple: you start with basic things like ints and strings, and then declare compound types like arrays and records in terms of simpler types. It was neat to see the way you could build up ever-more complex types in terms of the primitives.
After taking a year of Pascal in high school, we switched to C++. At first, it seemed to be only superficially different. Instead of Writeln("Hello")
, you cout<<"Hello"
. Type names appeared before variables now. The first new thing that came up was pointers. It wasn’t too different, but it was pretty neat, and I got a better idea of how interesting types could be built up from this new primitive concept. Still, C++ didn’t seam too Earth-shattering compared to Pascal. I figured all software development would feel like this.
Then I saw Perl for the first time during an internship, and it blew my mind!
Perl was weird and ugly in a glorious sort of way. The Camel Book, written by the creator of Perl, didn’t just tell me how to write “Hello” to the screen or how to declare functions. Instead, it was entertaining, downright whimsical at times, and that reflected the fun I had playing with Perl. Right out of the box, I got to work with interesting things like hashes and regular expressions. I saw the appeal of the brevity that came from some of the shortcuts it takes.
I had a semester of Functional Programming with Scheme, but I didn’t really “get it” at the time. I wish I had… I’ve since come to really enjoy working with lambda expressions, and Scheme is lousy with them.
In my second internship, I worked briefly with Tcl (pronounced “tickle”). In Tcl, “everything is a string”, and when everything is a string, you have to start stretching your definition of things like “string” and “quotation marks”. All data types in Tcl can be manipulated as strings, even blocks of code! This was my first exposure (second, if I had actually understood Scheme) to the idea that code itself can be a value, something you can pass around from one function to another.
During senior year and in a fit of youthful recklessness, I had an affair with PHP. Please accept my heartfelt apologies.
Python started to appeal to me as an alternative to PHP’s inconsistency and Perl’s readability issues. Like with any language, you’re going to be surprised by some of the details, but by and large Python’s simplicity just makes sense. Operator overloading feels very natural; your operators are just methods with special names. Significant whitespace is weird at first, but it mimics the way I write psuedocode on paper. Slices, lazy generators, and list comprehensions are all just really slick concepts.
Ruby re-re-reintroduces functional programming for the masses without making it feel like functional programming. Ruby blocks are similar to lambdas of other languages, but combined with nonlocal returns you gain the ability to define your own control flow constructs. It’s as if you can add new keywords to the language.
I haven’t used Clojure much, but it does seem like the first Lisp capable of grabbing wide-ish appeal. It gives you just a little more syntax out of the box than other Lisps, and the built-in data structures are really interesting and opinionated.
Haskell forces you to rethink something that other languages take for granted: the order of evaluation of everything. It also forces you to realize just how little of your code really has to deal with mutable state.
As I said above, C# has been my focus lately. It’s a bit of a kitchen sink. Every few years, it gains a pretty significant upgrade. The first version was suspiciously similar to Java, but since then they have diverged greatly. Properties help with readability, generics are far stronger than their Java counterparts, delegates and lambda expressions introduced functional programming constructs, LINQ introduced freaking monads, and you can even opt-into dynamic method invocation reminiscent of Python and Ruby.
Since C# exposes the developer to such a wide array of concepts from a wide variety of preceding languages, C# is a bit of a polyglot. C# is a toolbelt with many tools. You can pull out only the tools you need, when they’re appropriate for the job you’re doing.
Software developers should take the opportunity to similarly fill their own toolbelts. We should expose ourselves to as many languages as possible. Doing so will give you career security, expand your mind, and strengthen your problem-solving skills. Most importantly, it’s just plain fun.
Find out just how green the grass is on the other sides of things. Sometimes, the grass is purple.