4 ms·

I think in part it's because the idea that programming is text and math-based is too ingrained in society. For example, we talk about programming languages. Bu

I think in part it's because the idea that programming is text and math-based is too ingrained in society. For example, we talk about programming languages. But IMO there are also programming systems such as Smalltalk [1]. I've programmed 2 years professionally in it, currently looking for an engagement in a different language (a curiosity thing, also a resume thing). I think Smalltalk has a lot to offer by switching the programmer's view of thinking about programming systems rather than programming languages. Moreover, programming systems is also not where it is at. One downside that Pharo in particular has is that the community is small. A lot of plugins/libraries that are a given in other languages aren't there! For some, however, this is a strength because one gets to learn much better how to build stuff from the ground up and tinker on it by yourself. Given that there is still a lot of low hanging fruit it is easy to become a contributor. But this part, whether a community is big or small means that I think it's smarter to think about programming ecosystems where a programming language or programming system is the central hub connecting the programming community together. Why don't schools teach about programming communities? See my first sentence ;-) [1] https://pharo.org https://pharo.org - a modern Smalltalk

argiopetech 3y ago
Programming is logic, language, and practical skill (like welding or riding a bike). The logic is basic enough that you can get most of it in a single class. You can get a good bit of the language idea (since the syntaxes change) in class(es), but you can't be fluent without immersion. The practical skill (which is what people get paid for) can't be directly taught and requires significant personal effort practicing over a long period of time. In my experience, most students fall on the practical hurdle.
theamk 3y ago
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)
- igouy 3y ago
  > especially hard for beginner students 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 Fraction understands: 'asInteger' as: '↑ self makeFloat asInteger' 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 https://dl.acm.org/doi/pdf/10.1145/3386335 https://dl.acm.org/doi/pdf/10.1145/3386335
  - theamk 3y ago
    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..)

argiopetech 3y ago

Programming is logic, language, and practical skill (like welding or riding a bike). The logic is basic enough that you can get most of it in a single class. You can get a good bit of the language idea (since the syntaxes change) in class(es), but you can't be fluent without immersion. The practical skill (which is what people get paid for) can't be directly taught and requires significant personal effort practicing over a long period of time. In my experience, most students fall on the practical hurdle.

theamk 3y ago

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)

igouy 3y ago
> especially hard for beginner students 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 Fraction understands: 'asInteger' as: '↑ self makeFloat asInteger' 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 https://dl.acm.org/doi/pdf/10.1145/3386335 https://dl.acm.org/doi/pdf/10.1145/3386335
- theamk 3y ago
  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..)