Smalltalk is image-based though, which means the amount of things you can break is much bigger than in traditional systems, and you need to apply a real effort to keep things consistent. Which would be especially hard for beginner students.
Take a classical C or Python programing assignment for example: it all fits on a single screen or few screens, and that's all there is (most assignments usually do not include third-party packages or persistence mechanisms like files/databases). When you run it, the state resets from scratch every time, and the run is normally deterministic. If you revert your file to previous version, program will function as before. You can show this file to someone and they'll have the full picture of what you have done.
Compare it to Smalltalk where your program is spread throughout the system inside lots of tiny functions. You might have a good code which does not work because there are objects created by previous versions. Or maybe you changed a system-provided function during debugging and accidentally broke it in the process.
("notebook" environments like Jupyter notebook have the similar problems. But at least there, you can tell a student: "please restart the kernel and reproduce the problem". Nothing so simple exists in smalltalk)
Perhaps you don't know that 50 years ago Smalltalk was being taught to middle school and high school students?
> Nothing so simple exists in smalltalk
Have you actually used Smalltalk?
----
`I will always remember a debug emergency call I received during one of our student classes. A girl was experimenting with numbers in Smalltalk-80, and suddenly her system froze when she tried to reframe a window. Although the UI was unresponsive, the "emergency evaluator" window was still operating so I was able to take a look at what had happened. Her window was trying to display itself, but was encountering an error because BitBlt, responsible for painting the border, had a width that was. . . wait a minute. . . a Fraction? We did not even have fractions in the student system, but she said, "Oh yes, I added a Fraction class".
Interestingly, BitBlt was written to be resilient, in that if it received a non-integer argument, it would call itself again after sending the message asInteger to that argument. However, her fractions did not have such a method, so the debugger had stopped at that point and was not even able to show the problem because of another such infraction (er, sorry). I asked whether she had a conversion to integer and she replied no, but that her fractions did have a makeFloat message. We talked about the problem, and I got her to suggest defining
We were able to type this into the emergency evaluator, at which point the debugger miraculously displayed itself, the window she had tried to reframe reappeared, and everything in the system seemed to work again. Probably hundreds of methods in the system were now operating just fine with rectangles whose coordinates were instances of a student’s newly defined Fraction class. This illustrates the astounding ability of message-sending systems to absorb unanticipated constructions.`
Daniel Ingalls "The Evolution of Smalltalk" 85:63
Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 85. Publication date: June 2020
I don't think "smalltalk was taught 50 years ago" is a good argument. When I was a kid we used MSX machines with no storage.. your program would be just gone at the end of the lesson (or if you messed your POKE's). If you wanted to save, you copied code to your notebook. Were we able to get things done as middle-school students? Yes. Would I recommend this environment to anyone else today? No.
And yes, I get this, if you have on-call expert for student classes (preferably principal architect of the system), then you can use Smalltalk. But I've never seen "on-call experts" at any time during the university... the closest thing is sometimes there are TAs during labs, but those TAs are just slightly older students.
What would that girl do if Daniel were not around? Would she have to reset the environment and lose all of her work?
(For comparison, later on we got PCs with MS-DOS. I've crashed those machines so many times with all sorts of crazy or stupid code.. and I never needed anyone's assistance to recover - hit RESET, wait for machine to reboot, reopen your files..)
Take a classical C or Python programing assignment for example: it all fits on a single screen or few screens, and that's all there is (most assignments usually do not include third-party packages or persistence mechanisms like files/databases). When you run it, the state resets from scratch every time, and the run is normally deterministic. If you revert your file to previous version, program will function as before. You can show this file to someone and they'll have the full picture of what you have done.
Compare it to Smalltalk where your program is spread throughout the system inside lots of tiny functions. You might have a good code which does not work because there are objects created by previous versions. Or maybe you changed a system-provided function during debugging and accidentally broke it in the process.
("notebook" environments like Jupyter notebook have the similar problems. But at least there, you can tell a student: "please restart the kernel and reproduce the problem". Nothing so simple exists in smalltalk)