Last time, I enumerated all the dialects I’ve attempted in my life-long efforts to communicate with computers. I valiantly resisted drawing any sort of family tree of programming languages through the decades. It’s diverting to develop taxonomies and tease out relationships and influences. I think this list points out just how much fun it is to build systems and tools with computers.
But what I wanted to emphasize was the task-oriented way someone can approach learning. Want to adapt something? Need a tool to get things from one place to another? Want to automate something for yourself or your team? Here’s a way to tell the computer what you need.
And this is why so many people loved Perl, while it had its place in the sun. “There’s More Than One Way To Do It” appealed to people who were intimidated by software design. Don’t worry about algorithms, Perl seemed to say. You can be clever or simple, as you like. Just make a go of it, and you’ll probably find your way there! It’s the Unix Philosophy in practice.
This liberal attitude is why Perl brought joy and fun to the world. For the (mostly) self-taught, like myself, it asked me to grab the “Swiss Army Chainsaw” and get to work. “Perl is a language for getting things done.” “Perl is not a tidy language.”
This “shoot from the hip” attitude is also what drove people away from Perl. Try it! It’ll definitely do something! But the thrill of hacking something together would fade when we looked at our scripts a few weeks later. What was this supposed to do? What was this little idiom that had seemed so clever? How had we managed to write something so incomprehensible? Perl got mocked for being a “write-only” language–you can write it in, but you sure can’t read it. And that’s not completely fair; I’ve read some very clear, well-organized, and straightforward Perl. And yet. And yet.
Code Ninja vs. Code Monkey
How do software design patterns, good or harmful, establish themselves in general use? I’m not even talking about algorithms–not my area of expertise–but more about the ecosystems and conventions that grow up around languages and tools.
At the same time, Sun produced version 1.0 of Java and the JVM. Java, now decried as verbose, full of boilerplate, and designed for tedious business logic. How uncool! But at the time, its standardized platform coupled with object-oriented structure did feel revolutionary. And I still feel the tension between Perl’s “get stuff done” and Java’s “please please let this be clearly defined and maintainable, even if it seems wordy right now”.
What Is This Fine Manual You Speak Of?
Nonetheless, in 2021 I decided to ignore the wisdom of my elders and just start scavenging. What could I figure out from the Vue docs? What could I pick up from the Chart.js examples? Again, I muddled through some syntax, and sometimes things clicked (oh, you mean a map is just a kind of List Comprehension, which I love using in Python? No, Allan. Other way around. But now you know. Oh, those curly braces around your variable name just mean you unpack things? Just like Py–…) And others remained muddy but worked decently.
Some of my biggest pain/aha points:
- Not understanding npm and how many packages could get drawn into my dependencies as I experimented. (Allan, it’s just like venv in PYTHON)
- async/await whens and whats and please just load my JSON! That all makes sense now, though.
- Arrow Functions. Are they magic?
- Stepping into and out of various UI toolkits just for a simple slider.
- mixins. How does this fit into the object model I learned with C++?
- Dates. And doing math with them.
- Vue3 vs Vue2 and incompatible libraries. Wait, this really is just like Python.
Stuff I had fun doing
- This little Play/Pause button:
- This adorable one-liner to check the environment for dev vs prod defaults:
- Just getting a handle on Vue and reactive properties. Maybe I’ll try something else next time, but Vue was a good time.
I liked making something! I enjoyed, to a point, discovering new syntax and structure behind every curtain. But I knew what I’d wound up with had its bright points and its, you know, messy points.
It was time to get more methodical. Maybe this was the time to get back to a thorough grounding in programming, not just the ad-hoc approach I’d championed for so long.