For this week’s reading, Paul Graham’s essays kept highlighting the idea that programming languages are essentially a medium for which programmers think. Throughout high school, I was part of the robotics build and programming team. We worked in Python to program our robot to complete tasks in the games each year. In Python, you can have an idea for a command/script, and you can just write it. If you wanted to store some key-value pairs, you would just create a dictionary, easy as that. I didn’t take any Python classes in high school, but I did take Java and HTML. The language felt very straightforward, trying to help us as programmers get from the tasks that we envisioned our robot doing into reality.
Then I got to university and took Fund. Comp. Suddenly, I was writing in C. And let me tell you, C is not trying to help you. In fact, it feels like it’s actively setting up traps for you to fall into. Forgetting to free your memory? That leads to a memory leak. Crossword was hell. Accessing one element past the end of the array? That will lead to a Segmentation fault. For the first few weeks, I was miserable. Why would anyone choose to use this language, which makes you manually manage every single byte of memory and constantly worry about pointers? Don’t even get me started with pointers. It felt like a massive step backwards in “Power/efficiency”.
But after a while, something clicked. I realized C wasn’t forcing me to think about memory management and pointers just to be difficult; it was forcing me to think about how a computer actually works. That was the point of Fund. Comp. My thoughts shifted from “I need a list of items” to “I need a contiguous block of memory of a certain size, and I need a pointer to its starting address.” This is exactly what Graham meant. I was tackling the same types of problems as in Python, but the language I was using completely changed the mental framework I used to solve them. I was no longer thinking at the level of abstraction, but at the level of the machine.
This is where Graham’s points about Lisp being a “secret weapon” make so much sense. For building Viaweb, thinking in terms of memory addresses would have been a massive disadvantage. They needed a language that allowed for rapid prototyping and high-level abstractions, letting them build features faster than their competition. Their Lisp code was probably more expressive, allowing them to think about the problem of e-commerce, not the problem of memory allocation. The power of a language isn’t just about execution speed; it’s about the speed of thought and development it enables. C is incredibly powerful when you need to write an operating system or a driver, but it would be a terrible choice for a website startup.
I don’t believe that it will be one specific language. C won’t disappear, and neither will Python. Instead, I think it’s the ideas Graham hints at in “The Hundred-Year Language.” The features that will persist are those that give programmers leverage–(AI). The ability to build powerful abstractions, to create mini-languages within the language (like in the Lisp macros), and to choose the right level of thought for the right problem. The future isn’t about finding the one best programming language, but it is about understanding which language lets you think in the most effective and efficient way to handle the task at hand. AI is on the rise and will be the future in coding.