This is a conversation that @cmp2020 have already had, repeatedly, and as I was writing some code this morning, I thought it would also make a good topic for a blog post.
When I entered the work force in the late 1980s, the programming industry was at the tail end of a paradigm shift. It was widely understood at the time that machine language was a "first generation" language; assembly language was a "second generation" language; and the "third generation" was comprised of languages that had only recently become commonplace: mainly Fortran, COBOL, and C - with BASIC and Pascal in the classroom. The somewhat recent paradigm shift was from the dominance of 2GLs to 3GLs.
On the horizon, we were expecting to see these third generation languages get replaced by fourth generation languages. And eventually, those would be replaced by direct communication with the computer in the English language. Things were moving so fast that people thought it might happen by the start of the 21st century.
What happened, instead, though is that 4GL languages stayed tied to specific domains (or disappeared, like FOCUS). Apparently, the language categorizers are now up to 6GL, but nobody I know really talks about programming languages in those terms anymore. As the decades passed and new 3GL languages like perl, Java, C++, JavaScript, python, and Ruby rose to prominence, the idea of programming in English drifted away like the idea of mankind traveling to Mars and beyond. The thing that was once inevitable became unlikely. For all the technical progress of the last 4 decades, in some ways it has also been a time of lowering expectations.
Then came the Large Language Model (LLM).
It's no secret that I rely heavily on LLMs for development of the Steem browser extensions that I've been working on. This is for two reasons. First, and primarily, it's because I'm learning to work in JavaScript, and HTML, and CSS as I do the development, so the LLMs are serving as my tutors. Secondly, it's because I'm basically lazy - this is a big part of why I was drawn to programming in the first place, to make things easier. The LLM serves as a sort of a compiler so that I can abstract away some of the more tedious aspects of coding.
So, the LLM translates from English to JS, HTML, or CSS, and all I have to do is describe what I want and decide which files should hold the code that the LLM spits back. Until recently, I had experimented with ChatGPT, Google Gemini, Claude, and Brave Leo. Another option which I wanted to try was Github Copilot. Unfortunately, I can't justify paying the monthly fee for a set of hobby products that generates zero revenue, so Copilot remains out of reach.
However, last week I decided to run some web searches to see if there's a free equivalent that I can use with Microsoft's vscode interface. It turns out that the answer is Yes. So, I downloaded ChatGPT-EasyCode and gave it a try.
It comes with a daily quota, so there are limits, but let me just say that it's frigging amazing. The first thing I did was right-click on the menu and see what options were available, and it gave me a "what does this file do". So, of course I had to try it. Let's look at an example of its output from the main.js file in the Steem Curation Extension.
This file is a JavaScript module for a Chrome extension designed to enhance the Steem blockchain curation experience. The extension highlights posts based on their promotion status and beneficiary settings, and it also provides additional information about the user's voting power when they interact with the profile dropdown menu. Here's a breakdown of the key functionalities and functions in the file:
Key Functionalities:
Highlighting Posts:The extension highlights posts that have been promoted or have @null beneficiaries.
Different colors are used to indicate the level of promotion or burn (percentage of rewards going to @null).
Displaying Voting Power:When the user clicks on the profile dropdown menu, the extension fetches and displays the user's current voting power.
Handling Page Changes:The extension uses a MutationObserver to detect changes in the page, such as logins or logouts, and updates the UI accordingly.
Data Preparation:The extension fetches data about transfers related to promoted posts and prepares this data for use in highlighting posts.
Key Functions:
highLight():
And so on. You get the idea. The plugin also has the ability to create code, answer questions about specific selections and to fix bugs, suggest improvements, and so on. And, unlike with the standalone LLMs, it's right there in my code editor so I don't have to waste time copying and pasting between windows or explaining the context to the AI.
So all of that is pretty amazing, and it's a big step forward from working in a separate LLM, but that's not the point of this post. The point is that the long-forgotten idea of using English to create computer programs is back on the horizon.
Yes, right now, the LLMs make a lot of mistakes, but at the dawn of the 3rd generation languages, compilers made a lot of mistakes, too. When I entered the work force, people said that if you wanted to optimize performance, you had to use assembly code. My expectation is that coding with an LLM assistant will follow the same trajectory that we saw back then.
So, my coding process right now is to describe what I want in English, examine the code, make changes where needed (or more likely, ask the LLM to make the changes), then test and debug. As time goes on and the LLM gets better, more of that happens in plain English and less of it happens in whatever language the app uses. Eventually, we can even ask what's the point of having a 3GL in the middle? Why not go straight from LLM to assembly or bytecode?
Of course, when I say that "The future of programming languages is English", you can substitute in basically any other spoken language. There's no reason that the future of programming languages can't also be German, Spanish, French, Italian, Korean and so on.
As long as humans continue to have the ideas, there will be a continued partnership between human intelligence and artificial intelligence. In fact, when English eventually replaces specialized languages I think we can expect to see more people implementing more ideas, and faster. The role of the software engineer is not threatened, but it is definitely changing.
Visit the /promoted page and #burnsteem25 to support the inflation-fighters who are helping to enable decentralized regulation of Steem token supply growth.