Programming languages and clay
My bias first: I build (and ship) products. Anything that slows me down along the path of building is a hurdle to me. This list includes:
- my computer is broken
- my DSL doesn’t work
- I am sick
- the compiler I am using is excessively picky
- the mental model behind the programming language I am using forces me to think too long
Also some context. I grew up working with Lisp. I felt free. Then I had to switch to Java. Testing wasn’t a big thing at the time. Therefore I grew up with the “it compiles thus it works” belief. I am now convinced of the value of tests, once you know what you are building.
Now on to the matter at hand. Uncle Bob has posted a very provocative post about programming languages and testing. He took Swift and Kotlin for a spin and jotted down some thoughts. The most interesting part to me is not the discussion about programming languages but the reflection on the design:
All these constraints, that these languages are imposing, presume that the programmer has perfect knowledge of the system; before the system is written.
Uncle Bob source
That’s pretty much what I am fighting against every time that I write code. I have something in mind and I start prototyping and exploring. I have a vague idea of the destination but anything that distracts me is, again, a hurdle.
The most common hurdle is a programming language (or a framework) that behaves like clay that hardens too quickly. If I change my mind along the way it’s too late and I need to start over or heavily refactor.
Swift feels a bit like clay that hardens quickly. It asks me too many questions at once, and its compiler interrupts my train of thoughts pretty often, asking me for details I don’t know about yet. It’s a bit like a pushy guide that proposes me a lot of sightseeing possibilities while I am trying to enjoy the city as I walk around.
The worst part is probably the one uncle Bob doesn’t discuss, the fact that Swift is a moving target at the moment. The Swift I learned two years ago is almost useless, as opposed to the Objective-c, the Java or the Ruby that I learned a while ago.
A few years back I remember there was a discussion along the lines of
Every line of Objective-c code that you write from now on is legacy code.
It sounded right, at the time. Now open a Swift project that you finished a year ago, and tell me about it. Now open an Objective-c project that you finished four years ago. And don’t tell me about it because all you can say is “it just works”. You might have warnings related to deprecate API but nobody will propose you to migrate anything related to the code.
There’s people that consider compile errors as todo items. I wish I could think it like that and call it a day. I appreciate some help from the compiler (or the type system). But too much assistance seems detrimental to the way I work though, much like somebody that points a hair dryer on my clay, willing to help.