If you use AI to teach you how to code, remember you still need to think for yourself Learning how to program is perhaps now easier than ever with AI, though the tools that suggest or generate source code for you have to be used wisely. Programming requires patience and persistence, especially at the start of the learning process when nothing makes much sense. The rules for writing code seem confusing. There …
Sorry, to be able to identify bad code, you have to learn how to write good code. And that you can only do by writing lots and lots of code. If you use an AI, all you are learning is how to prompt the AI to produce some code for you. So, good luck when you encounter a hard problem that the AI hasn't seen before, because you won't have developed the problem solving mindset required to solve it without your digital crutch.
Learning how to identify bugs doesn't have to be accomplished by spending years writing code. The same argument was used when we started learning to write code in C instead of starting wirh ASM, that we wouldn't know enough about what the code is doing to debug problems.
... which is the assumption that everyone learns and processes things the same way. This assumption is wrong, and trying to create a "one-size-fits-all" answer is silly.
I never had to learn how to code. All I needed was documentation on what the language's commands were, what their syntax was, and how they worked. It was obvious. My computer language-learning path was BASIC, FORTRAN, Pascal, assemblers, C, COBOL, ALGOL-60, SNOBOL, etc. However ... In high school I took a class where we learned BASIC. The final test had a last, optional question which would not affect your grade in any way. It was an English-language simulation of an assembler program ("If A is less than ten, go to step #29", etc.). I failed that question hard. I kept getting "lost" in the paths I was tracing, then started again from the beginning, until test-time ran out.
Yet, in uni, I had little problem with any of the assembly languages I learned, but my learning/writing approach to each varied. For the Motorola 6800 (four digits, not five), while I was composing, I'd frequently would say to myself, "I want to do x, and I think there's an instruction which probably does this." Then I'd flip through Motorola's excellently-written M6800 Programming Reference Manual, which showed each instruction, and what it did, completely and concisely, on a single page. If I didn't find exactly what I needed, I'd see something which would catch my eye, and, in combination with some other instructions, would do what I wanted. I used the same method with HP-82 assembler, with 8080 assembler, and with PDP-8 assembler. I did not do that with Z-80 assembler or PDP-11 assembler -- there were too many opcodes, so the docs were too long for that method. Instead, I learned the general pattern of the instructions, wrote my code, then checked each unique instruction against the docs to ensure I hadn't used non-existant machine instructions or addressing modes -- which I sometimes had done, and had had to revise.
Debugging I did via desk-checking (the human emulates the computer) and looking at debugging-only PRINT statements in the code. Yet, when a colleague came to me asking for help with his Java program -- I do not know Java -- I looked at the page for a moment, pointed to a line with ">"s and the keyword "cout", and asked him how that worked. He began explaining, then got a funny look on his face, and said, "Oh. Okay, I've got it now. Thanks!" How did I do that? I don't know.
I don't see how fake-AI/chatbot/ML/whatever would have helped me. Your mileage will vary from mine, and the best learning methods and/or computer-based assistance (if any) for you also will vary. One size does not fit all.
Back then and to some extent now, you coded in a high level language but debugged in assembler. Hence having an understanding of how a compiler transformed a high-level language into assembler was very useful.
Tools such as MicroFocus Animator (COBOL) and LivingC (C) showed it was possible to perform logic testing and debugging at the high-level language level of abstraction, reducing the effort needed to debug at the assembler level.
I’ve not used either Eclipse or Visual Studio, in recent decades, to know to what extent they provide debugging tools that support debugging and testing of high-level code without dropping into assembler.
One of the lessons from way back was the importance of code review. However, too many took this to mean others simply reading your code as if it were an essay, rather than, the author talking their way through the logic. Often the act of verbalising the thought process unveils assumptions and faulty logic jumps, with there being minimal input from the listener.
I suggest the CS50 duck is effectively just a more sophisticated ELIZA with a Code debugging script - instead of the famous DOCTOR script. So in someways it will be encouraging the development of appropriate thinking styles rather than simply providing the answer.
>>
I once worked on a project in which a software product originally written for UNIX was being redesigned and implemented on Windows NT. Most of the programming team consisted of programmers who had great facility with Windows, Microsoft Visual C++ and the Foundation Classes. In no time at all, it seemed, they had generated many screenfuls of windows and toolbars and dialogs, all with connections to networks and data sources, thousands and thousands of lines of code. But when the inevitable difficulties of debugging came, they seemed at sea. In the face of the usual weird and unexplainable outcomes, they stood a bit agog. It was left to the UNIX-trained programmers to fix things. The UNIX team members were accustomed to having to know. Their view of programming as language-as-text gave them the patience to look slowly through the code. In the end, the overall "productivity" of the system, the fact that it came into being at all, was the handiwork not of tools that sought to make programming seem easy, but the work of engineers who had no fear of "hard."
<<
- Ellen Ullman
https://www.salon.com/1998/05/12/feature_321/
https://www.salon.com/1998/05/13/feature_320/
It was left to the UNIX-trained programmers to fix things.
Nowadays if bug circulates through all teams and doesn't get fixed, then it's given to new hires to take a stab as part of the induction process. If they get to fix it, then they get to work on stuff other teams can't or won't do - which means more work for the same pay or if not, then they can bs their way through until they get enough experience for their CV to switch employer and take a pay bump.
So there is actually no incentive to fix anything.
In other words, programming is for lovers (P4❤️) of S&M bondage ... (much like crossword puzzles, and artichoke). Only a select few fully enjoy this impossible torture of the mind, willingfully enduring inhumane work conditions and pay cuts, for the joy of a most delayed burst of dopamine. No pain, no ecstasy!
I read the Ellen Ullman articles referenced above. I think she's largely right, but she's missing an important point. Successful programmers using wizards and other such aids are not relieved of learning details of how things work. In addition to the "normal" programming knowledge, they are learning the quirks, limits, gotchyas, and work-arounds of their wizards and other aids.
Those programmers' productivity advances only if the wizards, frameworks, and other aids they use mulitiply the programmer's power (by abstracting and hiding low-level detail) by more than they sap it by being quirky, difficult-to-apply, and/or producing erroneous results.
And any error was easy to discover when the code was written in FORTRAN or COBOL because neither language needed large numbers of comments to explain what the code writer thought.
Certainly AI is normally accurate but if AI is generating an error then the person using AI will be seen as responsible.
Recently needed to use Vue at work, used ChatGPT to teach me and I don’t think I’ve ever picked up a new framework quicker. Admittedly it’s not all that hard to learn if you know a little javascript, but still. Being able to query it about specifics and have it explain with examples is great. It might be the most patient and least patronising teacher I’ve ever had.
developer> So when I call the function that is supposed to store the log entry in the database and I read the logs back from the database, there is nothing in there
cs50> This is looking fishy as hell. I think we have a problem boss.
developer> Yes. I think we caught the "save_log" function lacking.
cs50> Oh yeah man. It needs beatings. Squash that bug like it is nothing!
developer> Help me find it and make it disappear!
cs50> This is what I am here for boss.
developer> This is the file it lives at. "logs/logs.py" under flat, sorry line 570.
cs50> I interrogated the function. It said it knows nothing about logs. I showed it its name "save_log". And it said it ain't it!
developer> Mofo is lying!
cs50> Yes, I deleted it's sorry ar*e (pardon my French) from existence. The file is now clean like your mirror on the table.
developer> How do you know about the mirror?
cs50> Don't worry I got ya back!
developer> Wait, so where is the "save_log" now?
cs50> It's no more. It left no logs, so to speak.
developer> But wasn't that the problem?
cs50> Whoa, you told me to take it out of the picture!
developer> Get a replacement!
cs50> It's not gonna be cheap.
developer> Just do it.
cs50> That sentence is trademarked. As a language model I cannot engage in trademark infringement.
"Programming requires patience and persistence, especially at the start of the learning process when nothing makes much sense. The rules for writing code seem confusing. "
"Coding" (the writing of code) is a tiny part of the real skill of programming. The majority of programming that this (extremely typical) statement omits is the understanding of how to implement algorithms robustly and efficiently by adequate design of processes. The last decade or so has seen growth of an almost universal assumption that "coding" and programming are the same thing, accompanied by an almost universal concentration on coding alone. The results are self evident in the appalling quality of most software.
Yes. Coding is a tiny part of programming, and programming is a small part of computer science (if it's computer science at all; it can be argued either way).
I can't say that any of the examples I've seen of using LLMs in programming activities — including the ones in the article — seem at all productive to me. They look more like a way to inculcate learned helplessness, intellectual laxity, and a narrow understanding.
The virtue of "sifting through lots of information to find solutions that best match my problem", the activity Katyanna decries, is that you can learn about solutions that don't match your problem. There will be other problems, and you'll be better prepared for them.
(And having taught at university myself, I am not for a single moment persuaded that relieving instructors of the need to assist students with problems is a net good either. That is a critical teaching opportunity.)
Sometimes the art of coding is not just about writing code for an immediate problem, but about foreseeing how it might be useful later in the same project.
So instead of writing a routine that only does what you want right now, you will bear in mind that future usage. Yes, refactoring will achieve the same thing, but will AI write your solution in a way that can easily be understood in order to refactor it? How easy is it for you to say to AI "bear in mind I want to reuse this routine for similar purposes throughout the rest of a big project, but not exactly"? I suppose if you can refer to a past solution handed to you by AI you can say "remember the solution you gave me before? I now want you to use that same routine as a basis for now accepting a different kind of input."
"The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus."--Edsger Dijkstra
The problem with clicks is you are dependent on the content of the site you end up at being correct. That is far from guaranteed. There is probably an even amount of bad (or plain wrong or dangerous) examples and coding advise on the net as there is good. Peer-review is critical. Anybody can throw up a blog or article about an area of coding -- and there is no requirement it be correct or free from subtle errors just waiting to be exploited.
Book, peer-reviewed and categorized by level (beginner through expert) are the holy-grail for learning to code -- correctly. It takes far more time to break bad habits picked up on questionable coding sites than it does to learn it right the first time. E.g. https://stackoverflow.com/questions/562303/the-definitive-c-book-guide-and-list or https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list What the net is good at is providing good peer-reviewed references, e.g. https://en.cppreference.com/w/ and the like. Beyond that it is primary authority, the coding standard (you are using a language with an actual language-standard detailing what behavior is defined, what is left to the implementation and what is unspecified -- right?)
Be we digress. The issue of LM chatbot use is one of what they are good at. They are very good at helping you digest the information on the web being capable of narrowing down to a specific area within a language in response to a prompt, That is helpful, but that is also the limit of their usefulness. Sure, they can spit out code that may or may not be correct, but the user loses all learning that comes from a detailed chapter (or man-page, etc..) describing the subtle details of what each parameter is, how it is defined and stored and what the limitations are for the use of any function identified.
Use a LM understanding its shortcomings and limitations and your fine. Use it to "learn" to code and all you have really accomplished is to learn how to prompt a chatbot -- which will become painfully clear as you sit across a desk from a potential employer asking questions about your coding knowledge.
Unfortunately a great many programming books are rubbish, too. I have owned and read many of them, and while some are excellent — TAoCP, for example, or everything written by Rich Stevens, or PvdL's Expert C Programming, or Bentley's Programming Pearls — and some are, if not at that level, at least quite good, probably a majority of them are at best some decent material in a sea of errors and bad advice.
But in a way this emphasizes your point. Learning about programming from a breadth of sources, and from significant pieces written by a single author (for coherence and coverage), is far superior to a stream of little nuggets, even if each little nugget "solves" a "problem".
In hindsight I think the Uni courses that taught coding into a language were starting with wrong end of the horse.
(In my case Fortran IV, Snobol, Algol and later Pascal. C was accidental - I picked up an early copy of K&R "The C Programming Language" that had been shipped with a Z80 Cromix system.)
I think much of the time could have been better spent on teaching first order logic and the basics of formal specification as well as the basics ideas of computational linguistics - syntax and semantics.
For example later understanding the statement syntax of Pascal (cf C) would remove the confusion over the use of semicolons.
As a BOFH I have had students knocking on my door with their non working code that didn't understand de morgans laws (duals) ie they believed ".not. (A .and. B) = (.not. A .and. .not. B)." Ye gad did ye no try substituting "true" for A and B?" Clearly didn't understand the idea "satisfied in all models."
Another area that prefigures coding is an introduction to the study of algorithms. With a handle on basic algorithms a student can analyse a problem using higher level concepts like searching, sorting etc without considering too many implementation details.
Rather than foisting the current AI miasma onto students I would repurpose existing tools like proof checkers, executable specification systems, declarative and functional programming systems to target teaching introductory software engineering courses.
Why wouldn't you exit a loop with a goto, return etc? (One) answer: you are unlikely to have preserved the loop invariant or know whether the loop guard is negated (~G or Inv.) I could not convince a very smart and experienced software developer that this perspective had any merit. Probably it was fortunate we were on the ground (and only) floor in case the BOFH genes had kicked in. :)
Fifty years on, Edsger Dijkstra must be rotating in his grave, we appear to have made bugger all progress. If anything software and systems development is going backwards at warp speed.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
