“English is a better programming language than Ruby.”

Ruby on Rails creator DHH made this proclamation at this year’s Rails developer conference keynote, and while I don’t think he’s entirely correct I agree with the sentiment.

When I first started learning to program over a decade ago, one of the first languages I learned was Ruby. Rails was the first web application framework I ever touched. To be perfectly honest, I was so new to programming that while I was learning both, I did not understand the distinction between them at the time. In the first tutorials I tried and pet projects I built, each of the core elements — the language and the framework — were so indistuigishable to my novice mind that I could not tell the difference between what was a feature of the language (Ruby) versus a feature of the framework (Rails).

As I got deeper into web development, however, I began to disentangle these tools, and over time began to learn more about how the two worked together. I realized the decisions Rails was making for me for the sake of efficiency, the lower level concerns regarding object relationships in a database it abstracted away via Active Record, and how a slew of developer-created libraries simplified adding core features like user management and authentication. Then there was the language of Ruby. Simple, expressive, declarative. Optimized for readability and flexibility instead of static typing and immutability — perfect for a beginning programmer.

Along the way I was drawn, for some reason, into the world of databases and data structures. I found schema design and SQL to be quite interesting, and I learned about Postgresql and MySQL. Then later, large scale databases where how you stored the data itself mattered for performance. Then further on, distributed databases where networking and compression affected availability and latency. I dug into languages like Python, Java, and Scala to transform data into new shapes for analysis and insights. Out of curiosity, and necessity, I was inexorably drawn deeper into the stack.

My experience developing with AI today feels very reminiscent of those early days of programming: having an idea, typing some commands into a computer, and seeing some version of that idea appear on screen, all while having only the vaguest sense of what might be happening in between all those words I typed and the wires they flew across. The only difference now is that my layer of abstraction, instead of being a programming language, is plain English.

While I can respect those programmers who think we need to retain a degree of understanding and control in the way we express our ideas in software, I don’t think that has to be everyone. I’m certainly not one of those people. I never was as interested in the practice of coding itself as I was in creating things using code. And I imagine there are a lot of other people in the world who are the same. As more people begin to use AI to create the software they only had in their imaginations, I would assume many of those same people will go on to dive deeper into the stack, out of curiosity and necessity, just like I did. It’s a natural inclination. Others will be happy just creating without understanding the underlying mechanics, and that’s fine, too.

I think about Elvis, and how he didn’t need to understand a tape machine in order to record a great song. How he didn’t even write the songs he sang. It worked out OK in the end.