I came of age in the 1980s, programming personal computers such as the Commodore VIC-20 and Apple ][e at home. Going on to study computer science (CS) in college and ultimately getting a Ph.D. at Berkeley, the bulk of my professional training was rooted in what I will call "classical" CS: programming, algorithms, data structures, systems, programming languages. In Classical Computer Science, the ultimate goal is to reduce an idea to a program written by a human—source code in a language like Java or C++ or Python. Every idea in Classical CS—no matter how complex or sophisticated, from a database join algorithm to the mind-bogglingly obtuse Paxos consensus protocol—can be expressed as a human-readable, human-comprehendible program.
When I was in college in the early 1990s, we were still in the depths of the AI Winter, and AI as a field was likewise dominated by classical algorithms. My first research job at Cornell University was working with Dan Huttenlocher, a leader in the field of computer vision (and now Dean of the MIT Schwarzman College of Computing). In Huttenlocher's Ph.D.-level computer vision course in 1995 or so, we never once discussed anything resembling deep learning or neural networks—it was all classical algorithms like Canny edge detection, optical flow, and Hausdorff distances. Deep learning was in its infancy, not yet considered mainstream AI, let alone mainstream CS.
Agree. But even "The bulk of the intellectual work of getting the machine to do what one wants will be about coming up with the right examples, the right training data, and the right ways to evaluate the training process." might be more than what will be needed. Why wouldn't future systems largely automate this?
Also that sounds more like engineering that computer SCIENCE. Maybe a good fraction of future computer science researchers will be focussed on figuring how these systems work by analysing the behavior of small subsets of their neural networks.
Remember Ed Yourdons prediction in 1992 (see https://en.m.wikipedia.org/wiki/Decline_and_Fall_of_the_American_Programmer). Matt Walshs prediction may or may not be accurate, but the timeframe isnt always clear.
I dont think that AI means the end of programming, but I do think that it will change the way we teach computer science.
Already it is clear that we need to be teaching all kinds of new skills, such as prompt engineering and the theory and practice of data annotation. We also need to teach how to use AI to build more complex systems. Just as todays computer science students dont need to know how to implement a language like Python but need to know how to use it, CS students of the future will need to know how to use AI effectively, and that will sure be improved with formal education.
Its also clear that computer science departments will need to be at the forefront of socio-technical issues, including understanding and counteracting systematic bias in AI systems, improving access to these systems, and making sure that the benefits of AI are shared by all. These may seem like soft social science issues, but over the past decade, weve learned that its simply not possible to address these issues without a firm grounding in computer science.
Improving cybersecurity and developing approaches for respecting privacy while making use of private data are two other areas where the need for strong education and research will continue. Yes, cybersecurity defenders make use of AI, but so do attackers: we will need the combination of human-AI teams to stay ahead of attackers. In terms of privacy, it seems unlikely that AI is likely to develop fundamentally new technical or legal approaches for protecting privacy, but we will certainly need them to keep up with the technologys challenges.
I am confident that AI will only increase the demand for CS graduates.
When FORTRAN was introduced, the authors claimed that it would "virtually eliminate coding." Did it? No, but it changed what the term "coding" meant. AI tools will similarly change was "programming" means. Is that the "end" of "programming," though? Highly unlikely it is.
(See https://www.softwarepreservation.org/projects/FORTRAN/BackusEtAl-Preliminary%20Report-1954.pdf -- "Since FORTRAN should virtually eliminate coding and debugging, it should be possible to solve problems for less than half the cost that would be required without such a system.")
I agree that AI models could very well displace humans as authors of simple and complex software components. However, I would argue that already today writing the actual code is only a small part of my daily work as an software engineer. Much of it is indeed spent discussing (and also finding) the correct requirements (or stories), devising the architecture, writing documentation and generally thinking about how to keep the code base maintainable. Thus, I think that "the bulk of the intellectual work of getting the machine to do what one wants will be about coming up with the right examples, the right training data, and the right ways to evaluate the training process" is probably very true, but I would say that that is already a large part of what I do as a software engineer - although maybe in a different form.
The alternative is to use speech, which is certainly an information bearing medium, as a Turing Complete mechanism, by embedding an orthogonal boolean signal (Ok, . or Sorry, ) to act as a conditional, and to create loops by recursion. This follows the symbolic logic of C. S. Peirce as applied by Ogden and Richards in 1923, and the Pragmatic linguistics in the 1950s. More detail on how this works is further detailed in:
However, what this solves is the age-old problem of software engineering: the need for a written artifact. Even the above article alludes to writing a program and neural-nets requiring a few keystrokes, it comes so easily! The inductive process the creation of meaning can be described, or programmed by voice, by what an utterance implies. This too is simple science and so is evidenced by open experiment: a simple demonstration, currently with 504 unit test examples, is available at https://bitbucket.org/martinwheatman/enguage/src/develop/ (and at a similar location on github!)
It took 100 years to get from the idea of Babbages Analytic Engine to Turings idea for the Universal Machine. Perhaps it is fitting that Ogden and Richards published their Meaning of Meaning in 1923? It is here, it is now. Enjoy.
Having used ChatGPT to help me writing code for a complex project, not just some toy CS intro examples, I found many cases where ChatGPT provided some amazingly great support beyond other resources such as StackOverflow. But, as others have found themselves, it can also produce answers that are simply wrong and do so with great confidence. In some cases it took me a long time to debug. My more general insights are these:
1) New Skills. CS competence models of the past have focused on the ability of students to ANSWER QUESTIONS. In the post-GPT era competence may need to be reconceptualized as ability to POSE QUESTIONS. The quality of an answer produced by ChatGPT is somewhat proportional to the quality of the question posed. And to ask meaningful follow up questions. Making effective use of tools such as ChatGPT develops a modern form of dialectic. This is a good thing. Entering the workforce and working in teams, past students will have to be able to master this kind of dialectic to work with fellow humans as well as with AI. In the long run, this kind of competence is likely to be more important than knowing some detail regarding a certain algorithm or specific programming language.
2) Shift in CS University Education. Working on real projects professional programmers already find value added by current AI programming support systems such as Copilot and ChatGPT. This value will only go up over time. It makes no sense to hide or forbid these systems in (not only CS) education. These systems provide new kinds of affordances that we do not fully appreciate yet. Our current mechanisms of CS skill assessment will not work well in the post-GPT era. Like it or not, students will use these new tools but in contrast to Google/StackOverflow-based approaches, there are no anti plagiarism tools to support educators. Tricky times ahead. A shift towards more project-oriented, higher level skills could help. Project portfolios instead of low level coding exams. If you want to become an architect you would not be judged how well you can hammer in a nail either.
3) Shift towards Explicative Programming in K-12 Education. Maybe The End of Programming will come to K-12 education as long as programming is only considered a recruiting mechanism for the CS education pipeline. To this day, programming is still not well received in K-12 education mostly because it does not provide measurable benefits towards non-CS subjects relevant to schools. In the post-GPT era K-12 programming with this career oriented focus, will become an even harder sell. Explicative Programming (), in contrast, is about the use of programming to develop the understanding of powerful ideas in other disciplines such as STEM, music and art by building interesting artifacts. Programming as instrument of thought is about thinking WITH computers. This kind of programming is will not end. It is about to begin.
Practitioner's experience and comment
"I'm a pretty decent programmer. Good enough that I've made a career out of it and none of my code will (likely) ever make it to the Daily WTF. But there are programming concepts that I've always struggled to understand because frankly, the documentation is obtuse and hard to parse, and it wasn't really worth my time.
For instance, the Wikipedia entry on monads is frankly just obnoxious to read. I program in elisp a bit, so trying to understand monads is mostly about satisfying some curiosity, but something about the article just doesn't click with me and I have to move through it really slowly.
I've also asked it to document some elisp functions that I've always thought were poorly described (emacs' documentation can really be hit or miss) and it really did a great job.
I'm not so arrogant as to say that these models won't one day generate a lot of good, usable code, but I honestly think that this ability to collate a tonne of data and boil it down to something understandable could fill in the gaps in a lot of documentation. The longest, most tedious parts of my job very often boil down to research for some engine-specific feature that I need, or some sort of weird platform quirk. For publicly available engines like Unreal, this will honestly improve my productivity quite a lot."
I'm not ruling out the idea that traditional programming might one day be replaced by AI, but I think there's a much bigger hill to climb than this article would seem to indicate. As I see it, there are two major jobs of a programmer:
1 Designing a program (including gathering requirements and writing the code)
2 Ensuring that the program works as intended (including not only testing, but troubleshooting issues as they arise)
Even if we fiat that AI will one day write clean, efficient code for any task assigned to it with little or no programming involved, that still leaves the second of those tasks to be accomplished in its entirety. I'd argue from an epistemological standpoint that doing so necessarily requires human input on some level; there will need to be a human with the domain knowledge necessary to verify that the program is behaving as intended.
Perhaps not the end of programming but programming as we know it today. Moving away from coding to "true" software engineering to solve problems and build solutions more economically, faster, and at higher levels of productivity and quality, while producing a powerful developer's experience.
Having been in this industry for over 50 years at one time this would have been nirvana and pie in the sky but at this juncture, it is quite refreshing and exciting to still be in the industry as this becomes reality. This a good article that opens the door to new possibilities and feeds a mindset for growth.