Change the way you think about programming for the better
Challenging ourselves is transformative. Changing the way you look at programming will introduce paradigm-shifts... even when going back to old languages and tools.
“A language that doesn’t affect the way you think about programming is not worth knowing.” — Alan Perlis
I absolutely love that quote.
For me, Java long since stopped affecting the way I think about programming. C++ even more, and I’ll throw Python in the mix too. None of these languages challenge me to think about programming in new or different ways.
Which is probably why I haven’t touched them in years. They’re stagnant, uninteresting, and just not pushing boundaries.
There are plenty of languages that get me thinking about how I program. Changing my methods, for the better — really learning interesting and new concepts, not just a new technical skill but a new view of programming.
Changing how you think
Rust is one such language. If you haven’t learned Rust, I recommend doing it — even if you’re just exploring. It will affect the way you think about programming.
I’m biased toward functional programming languages, which is probably why I like Rust. It’s not a functional programming language but it acts like one. As Manuel Cerón points out, it’s almost as if it’s a functional language in disguise.1
When I first learned Rust, I found myself approaching it as a functional language. That is, using immutability and functional composition — and I found it pretty elegant. Later on, I realized that a lot of people struggle with Rust because they approach it as a mutable language, and run head-long into its strict rules about borrowing and ownership. Turns out, if you never mutate anything, almost all those headaches go away.
The first 20-or-so years of my career, I was using C, Objective C, C++, Java, all the usual suspects. That was a procedural, mutable world — the state of the art being rife with memory faults, side effects, and occasional stack overflows.
Then for the next 20-or-so years, I moved more and more toward functional programming (first with Scala, and eventually landing on Elixir).
I don’t look at programming the same way I did in my “procedural” days.
Can a mindset make Java better…?
Even if I’m working in Java, I’ll write functional code. I work really hard to avoid mutating any variables. I use functional composition. No side effects allowed. I use abstractions like map and reduce and always avoid procedural loops. I groan and moan about the lack of good pattern matching. 🤣
I think my “functional programming glasses” make my procedural programming much better. Or maybe it makes my procedural programming much more scarce — either way, I think it’s an improvement.
Functional programming can be as much a mindset as it can be a language feature. And I do firmly believe it’s a more sound paradigm, especially for large-scale systems. That’s why I bring my “functional mindset” with me — even to Java.
And of course — if I had never challenged myself years ago to learn Scala, I would never have started that journey.
Blending paradigms
Functional programming is what I love. There are good times to use procedural programming, too. I don’t think either can be said to be empirically “better.”
What I can say, is that having grown as a programmer over 40 years, I have a rich background that encompasses well over 20 languages. In that journey, I’ve become a better programmer with a greater appreciation for what each language offers.
I’ve got strong personal preferences (“Elixir all the way!”), but I can confidently tackle writing code in many languages. Not because I know the language forwards-and-backwards, but because I know how to structure a good program.
Simplicity follows complexity
Challenge yourself. Go find a language that makes you uncomfortable, that affects the way you think about programming. A language that introduces some completely new concepts that you’ll take with you — no matter what language you code in tomorrow.
It might seem complicated at first. I remember — shifting my procedural, mutable coding to pure functional practices was a challenge. In the long run it was worth it.
Which reminds me of another great quote by Alan Perlis:
Simplicity does not precede complexity, but follows it. — Alan Perlis
If you go with Rust, I guarantee you’ll love its environment, package management, and documentation — all of which are first rate. And you’ll probably run headlong into its obsession over who owns each and every variable. Along the way, I think you’ll discover some interesting new ways to approach old problems.
If you want a very quick and well-written peek at Rust, I recommend Brandon Gay’s short article. In a 10 minute read he offers a really fantastic description of why the language is so admired and offers advice that will help you pick it up quickly.2
On the other hand if you’ve never learned a truly functional language, I highly recommend doing so. Elixir would be my choice.
Manuel Cerón, Is Rust a Functional Language in Disguise?, Sep. 17, 2020.
Brandon Gay, Rust: Beyond the Syntax, Sep. 30, 2023.
Happy New Year Zac! What do you think of Zig? 😄