The unlearning curve

I recently paired up with a family member over the holiday for some coding time. Grace was trying to achieve some automation in her life. She was familiar with Python, and by incorporating some third-party libraries she was coding a small project that she had a genuine need for.

My role was unofficial; I was just there to help when something confusing came up. Although I’m no stranger to Ruby and other imperative languages, I’ve never leaned on Python in all my years hacking. Having long left languages like Python in pursuit of functional ones like Erlang, I was curious where my unlearning of imperative & von Neumann languages had left me.

The following are my observations of Grace and her Python hacking session.

Print all the things

Largely, in order to see how progress was going as she wrote code, Grace would print-to-screen. A flag indicating: ‘Ok, I got here’ was waved at every corner so she could see the flow of her program.

It reminded me of someone stringing along breadcrumbs so that there was no way of getting lost. And that made sense! Why? The routines she assembled were whoppers, and the myriad of ‘if/else’ conditionals were like trap doors, even though they were the skeleton that held everything in place.

Within every ‘if/else’ block, assignment statements usually overwrote old ones. For example:

some_flag = 'spam'

would soon enough become

some_flag = 'eggs'

I asked her why overwrite variables so much, and when Grace exclaimed why, I had to agree: coming up with variable names was difficult!

So while there was lukewarm chaos in the state, Grace had found a way to stay somewhat sane by simply printing-to-screen. But even then, she was often crestfallen with the unexpected results yielded.

Data on trial

In Erlang, the data-type I use eighty percent of the time is lists. In Python — from what I gathered via Grace’s code & the third-party libraries she was using — it seems like the only data-type used are dictionaries; with the values being predominantly strings.

This left an impression on me, as I have purposely veered clear of the Erlang dictionary equivalent: Erlang maps. As well, using strings in Erlang is quite inefficient, so seeing the world held together with maps/dictionaries & strings put me on edge.

Strings as values for everything proved at first to be innocent enough. But it wasn’t long before the ol’ regular expressions had to be unsheathed in order to accomplish this & that.

It was as though Grace had chosen a hammer, and when it was time to pull a nail out, with perfectly sound instinct, she spun the hammer around to find a nail-extracting claw (regular expressions).

So now, as they say about ‘RegEx,’ Grace had two problems.

Strange things happened with dictionaries, too. It seemed that by using such a powerful type to containerize data, a certain frivolousness took over, and soon enough, name clashes, naming conventions, lost values, deep-nesting hell all reared their ugly heads. It didn’t help that Grace’s familiarity with JSON inspired her to lean on dictionaries in the first place. To her, with all its conveniences, it was the only data-type in the universe.

Raise the roof

Each flow of logic had a case where if it didn’t meet the expected results, the edge-case was coded for. So for every case where there was an ‘if/else,’ there would be at least one line of raise code to handle the unexpected.

Visually, it looked as though half the code was made up of dealing with the unexpected. And when testing, these edge cases were never triggered. Though, I guess that makes sense: who has time to dwell over the incorrect case when our head space is one of ‘I need to move forward.’

All in all, with strings, RegEx, maps, defensive programming, printing to the screen to debug, and mutable everything, this Erlang coder was having some visceral flashbacks.

Lessons abound

I didn’t end up helping too much in our short session that day. And that’s fine, as I was happy to be the one learning.

I don’t think there was anything unnatural about how Grace was coding Python. She was expressing herself as an agent of the language & was succumbing to the paradigms it champions. And I have seen code in production not unlike what Grace was crafting into shape, so the code was pretty typical.

But while this was all going on, Grace was in a good deal of pain. I could tell that coding was like ice-skating uphill.

Python is lauded by almost every coder I know. And many first- rate companies use it (Google/Youtube). But I wonder if Grace would have been happier confronting the problem with a different type of tool altogether?

Her approach to the problem is a million miles away from how it would be accomplished using a functional language. And sadly, there wouldn’t be an ounce of ‘carry over’ if she every were to transition from Python to a functional language, either. So, she could master Python many times over, and when it came to programming in a non-imperative language, she would just throw all those hours out the window.

I think functional languages need to find their way in front of people like Grace earlier. It’s not an exotic landscape any longer & it’s the imperative & von Neumannian languages that should play second fiddle for the next sixty years.