Doing less

A lot of automation is about doing less manual labour. People who automate enjoy doing less. This desire lead to new programming languages, advanced IDE-tooling, but recently we’ve gotten a new type of assistance: AI. Microsoft using Github Copilot, Amazon with CodeWhisperer, and more will follow offering yet another Code predictor using ‘open source’ models.

But is it the right approach?

Solving problems that I don’t have

I mainly write in a language that was developed for developer happiness: ruby. It wasn’t designed for optimal performance, but allows code to be readable and easy to write (when you have a certain proficiency in Ruby that is). After having turned CodePilot on and off for a year, I’m really not impressed. It has saved me typing strings that I might have otherwise copied from an earlier test, but with the disadvantage that the resulting text had to be closely read by me when it wasn’t behaving as I expected. Code generated sometimes looks so good that it is hard to spot the error, and errors occur at weird places.

I can imagine that if you’re writing in a language like Go, which has a strong culture of reducing dependencies, it may help you implement that algorithm over and over again, whereas as a ruby developer you would grab a gem to solve the problem in as few lines as possible. Not saying the one approach is better than the other, but it comes down to this: there are different ways one can reduce repetitive manual work.

Problems that I want to be solved

One of the biggest problems we currently face is climate change. While transportation, producing physical stuff and farming cows for dairy and meat may have a much bigger impact on climate, soft technology isn’t innocent. We can’t continue to throw endless computing resources at problems to solve it, without considering alternatives:

• stop using inefficiently running programming languages (that might include scripting languages like ruby and python)
• stop using microservices and lambda trains that require heavy communication between services and/or spinning up, how tiny or fast, executing environments for a few lines of code.
• stop building every tiny commit as an image that can be build
• stop sending every keystroke to a central webserver so that it can come up with a suggestion for auto complete (yes, “AI”)

But. I care about the language I write my code in. It makes me efficient in solving people’s needs.

What if?

So what if we can have a concise language to specify behaviour that is easy to develop in, allows us to explicitly define behaviour when required, that helps recover from errors more quickly with results that are near as performant (and energy efficient) as compiled C?

Currently people are working on improving performance of ruby, through “Just In Time” compilers and in general trying to boost performance. Developer tooling is improving, and perhaps we can get early feedback on ‘mistakes’ that grind compiled code to a halt; breaking for example the implicit types assumptions. So what is wrong with scripting languages as meta programming languages, that skip boilerplate code that everyone is annoyed by, that produce highly efficient code with minimal lines over human language entry with unpredictable end results.