A friend of mine was taught True Basic for a middle school programming class, and he really disliked that class (middle school is grades 6-8, for students about 11-14 years old). The next year they switched to teaching Python, and that frustrated him, because he thinks he would have maybe liked the class more with an easier programming language like that. This was in the early 2010s.
On the other hand, it's not like he ever pursued Python or any other programming language outside of class anytime after that, so it could he that he just wouldn't have liked programming anyway.
That's not to say True Basic is bad or anything. Some people tear their hair out over coding in C but enjoy other languages. It's just what came to mind for me when I read "True Basic".
When I was young, and I enjoyed learning to program, I thought everyone could learn to program, and they would enjoy it.
Many decades later I've come to understand that programming is an intrinsically shitty job [1] which can only be done well by people who really love doing it. You cannot force people to learn programming. You can offer opportunity, but those that enjoy it will enjoy it. The language is irrelevant - joy trumps difficulty.
This is true for so many well-paid jobs. Smart kids get pushed into medicine, but good doctors are those that like being around sick people (and making them better). Sure it pays well, but often that's a sign that its a shitty job with a high skill level, and high societal value.
I'd still be programming even if I didn't get paid. It gets my motor running. But I understand now that its not for everyone.
[1] go on, describe your job to a middle schooler. Hours behind a desk, staring at a screen, spending hours to find out what a comma should have been a period... it's their very definition of a nightmare.
What is everybody’s opinion on Edsger Dijkstra’s quote “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.”
I’ve seen several version of Basic, but I’ve written only a a small bit of code in one of them, and that was 30 years ago. So I don’t know enough about the language to know what his objection was. The language I’ve programmed in the most is Ruby (also my favorite so far), and the one that interests me the most to look at next is probably Pharo. And I know Dijkstra did not like object-oriented languages, either.
I started writing software as a child, in the eighties. I only had access to various forms of BASIC and machine code. I switched to C in the early nineties, when I got access to Turbo C in middle school. Later, I got access to Minix, BSD, and Linux. I turned out fine.
I'm a fan of Dijkstra, but it's best to take his opinions with an appropriate dose of salt. He liked to be provocative.
The version of BASIC I learned (Applesoft) had little support for functions and no concept of scoping. Every variable was global. GOSUB acted a little like a function, but barely (no function parameters, and without variable scoping a parameter is meaningless anyway). Without these features, it was very hard to write a program of any size without it becoming a mess. I wouldn't go so far as to say BASIC breaks your brain, but it is almost antithetical to structured programming, and eventually you need to learn structured programming if you plan to write maintainable code.
There is also an argument against learning programming with languages that have no concept of a heap. I agree that a C pointer is a weird thing at first, and some people never get it. But I've softened my stance over the years. People can be productive coders without being bit twiddlers.
I learned Dartmouth BASIC on a timeshare in 1981. Variable names are single letter, or a letter and a digit. All variables are global. No function headers. Branching by GOTO. It means that modularity and structure are virtually impossible.
It practically forced you to write obfuscated code, and programs larger than a few dozen lines become exponentially harder to manage. Imagine the worst code you've ever seen.
People who got good at coding in this way tended to develop mental habits that had to be un-learned when they moved to a more advanced language such as Pascal, as I did. With that said, beginners in any "scripting" language can evolve in the same way, if not taught some better habits. I've seen some Python programs that were as bad as my BASIC programs.
Did you also use Dartmouth BASIC6 on a DCTS connection? That was my first language, and god it was miserable. But on the same machine we had BASIC8 which was essentially True Basic.
Don't know. It was what we got when we entered BASIC. We didn't have the manual, but only our textbook. The timeshare was on some kind of minicomputer. I later got a summer internship at the facility that hosted this thing, and the rack of modems was as big as the computer.
I wrote a multi-thousand line conferencing program in BASIC6. It was an absolute nightmare (no subroutines, everything global, line numbers were hardcoded and couldn't be changed.) Weirdly, the experience was almost like learning an assembler as your first language -- you had to keep state for everything. Learning Pascal and C after that was actually a huge relief.
It's still amazing, considering that there was no networking at the time. Today, a conferencing program would be able to take advantage of phenomenal networking infrastructure, yet instead of multi-thousand, it would be multi-million lines, and still an absolute nightmare. Some sort of Parkinson's law applies: The code expands until it becomes unmanageable.
When AI can write code for itself, it will be trillions of lines.
I've been playing with vintage 8bit machines the last few years and it's true.
Nontrivial basic apps have to be written essentially like assembly, or worse even, chock-a-block with single lines with 2 or 3 different exits, and every 3rd line is also a goto target while also still being the ordinary next line in some routine.
And it's not because the programmmer was thoughtless or undisciplined. With only a few k and basic to work in, this is just required to get the job done.
Outside of something quite as limited as a trs80 model 100, you can have at least some kind of modularity using chain, if you architect everything around that concept, and develop a framework or set of rules you follow the same way everywhere, like having a dispatcher main loop and all other modules all follow some consistent set of standards so that all modules can rely on all other modules working the same way, with a common interface, entrance, exit, params, etc.
Instead of functions or gosubs, you are always chaining forward, loading a new file, and sometimes the next file happens to be the one you came from previously.
>>> ... every 3rd line is also a goto target while also still being the ordinary next line in some routine.
This is also what killed the Apple II. People figured out places that they could branch into the BIOS and OS code to do weird things or bypass the time consuming parts. The result was that every byte of the code was potentially a branch target, and Apple could never change it. Even upgrading to the Apple IIe was fraught, and I made a hack for my mom with a toggle switch for choosing between the Apple II and IIe ROMs.
It's one of the reasons why Apple preferred a "closed" system for the Mac.
Almost all software uses the main rom as a library of functions, and if you change almost anything in the main rom, you break almost all software. It's why a lot of software that works on the model 100, doesn't work on the practically identical Olivetti M10, Kyotronic KC-85, NEC PC-8201, and doesn't even work on the non-US versions of the model 100! All of those machines have practically identical hardware, and practically identical main roms, but, not identical. Mostly it's all the same routines just with some addresses moved around by a few bytes, and that's all it takes to break everything.
To patch the main rom for y2k, you can search for a particular string of bytes to find the spot where "19" is hard coded, and edit it to "20". It's in a different spot in every different rom, but the routine it's part of is actually the same in all of them, and the same search & edit works on all of them. (ok the NEC does add something else since it also hardcodes "83" for "1983" somewhere else as part of some other routine that only the NEC has, but the part that has the "19" is the same as all the others.)
The point is, that's how similar they all are. And yet software isn't portable between them. The exact same routines, not even changed, but just landing at slightly different addresses, breaks all the software.
I disagree. I've lived through various levels of programming languages and it makes me appreciate features in languages that, these days, are just taken for granted.
I've got a few vintage BASIC machines now and some of the code for those machines is almost unreadable. What struck me now that didn't when I was kid was kind of how much like assembly language BASIC can be in some of these computers. On machines with very limited RAM but plenty of ROM, BASIC acts like compression allowing you to write much more complex programs than you could actually fit in RAM if you did everything in machine code. And, like assembly, being terse and clever can result in better performance and smaller code.
I'm considering writing a BASIC-to-BASIC compiler for these machines that works something like a JavaScript minifier.
Hah, in another comment I just made the same association, that you had to write basic essentially like assembly to get any actual nontrivial work done.
And pointedly, it wasn't a failing of the programmer writing badly.
I disagree with that comment about BASIC, for a few reasons.
First, you can say that about any language when trying to learn another. The classic “writing Fortran in Lisp” concept. Learning to write idiomatic BASIC doesn’t prevent you from learning to write idiomatic anything else.
Is there some, perhaps, unlearning necessary? Of course there is, as with anything. But it’s not fatal.
Second, it’s hard to appreciate how good something is until you’ve fought through something else that could have benefited you, if you knew it.
Early BASIC is not very expressive, and therefore limited. When you move on to something more modern, you don’t necessarily take it for granted. “Oh boy, this is so much better!”
Now you know WHY it’s better rather than just accepting it as rote. That leads to just a better, and deeper understanding of the whole field. When you were implementing your first B-tree, or hash table in raw C, you learn to appreciate why the one in the utility library, that you get for “free” may well not only be better than the one you copied from your “Data Structures 201” book (since it just may well be a more advanced algorithm), but you’ll realize how it works as well.
In contrast just blindly drag and dropping one into your project because you found a link on the internet.
Similarly, while it’s easy to condemn these older systems, if you ever go back and try to do work on some of these vintage systems, at their vintage speeds, you may well appreciate why something like BASIC was limited in the ways it was.
Are the more advanced language features worth the expense they incur? Maybe, but also maybe not.
Maybe for some the habits they learn have life long impact, but I don’t think being exposed to different idioms and methodologies of software development is a bad thing. Let’s folks learn and understand where those sayings and “best practices” they blindly apply (and not always necessarily for the better) come from.
I'd go so far as to suggest that Dikstra was right, but without the Basic qualification.
It is very hard to teach programming to students.
Most students at the time had some exposure to Basic (there was little else available to the non-student at the time), but programming is hard. Most students make lousy programmers, especially if one adjusts for the standard Dikstra might have been hoping for.
He chose to see Basic as the common denominator in the ones who failed (with the "almost" qualification to cover the outliers) but I'd suggest that correlation is not the same as causation. Then again, who am I to argue with Dikstra?
My personal experience is that after having fought with the limitations of BASIC, I enjoyed the power of C: pointers, that most students struggle with, were fresh air for me.
On the contrary, I was exposed to Pascal after C, and hated it: haw can you tolerate self- inflicted limitations when you know that there's something better out there?
What I learned is: always go from simple to complex, never backwards. So yes, BASIC is a great choice for absolute beginners.
He is wrong. It is an infantile view on learning which assumes that your first contact with an area of knowledge creates a lifelong habit that can't be improved with further learning. I started programming with BASIC and easily switched to C, Pascal etc without a trace of BASIC's programming practices.
When I was 9 years old in 1996, my dad got me TrueBASIC. It was one of my first programming languages. And it was cool to be able to create programs that draw graphics and output executables. Something I hadn't done before. The manual was good enough to get started. I made some games over the next few years before I moved on to RealBASIC (now Xojo). Perhaps if there had been some kind of online community I would've taken it much further. At the time, I was not aware of QBasic or any of the other common similar BASICs.
What I can tell you looking back is that it was a fine way to get started. We can debate whether it would still make sense to use something like this over Python for a modern 9-year-old. Certainly it's much more limited. But I will say there are just a lot fewer foot guns for a complete beginner. There's less surface area, so there is less to learn, but also less to do. I don't think that's such a bad tradeoff actually. Sometimes limitations actually spark imagination. And it's motivating to be able to learn all of something. But there are certainly free/open source BASICs that are just as good today. It's a legacy product.
33 comments
[ 2.9 ms ] story [ 83.3 ms ] threadOn the other hand, it's not like he ever pursued Python or any other programming language outside of class anytime after that, so it could he that he just wouldn't have liked programming anyway.
That's not to say True Basic is bad or anything. Some people tear their hair out over coding in C but enjoy other languages. It's just what came to mind for me when I read "True Basic".
Many decades later I've come to understand that programming is an intrinsically shitty job [1] which can only be done well by people who really love doing it. You cannot force people to learn programming. You can offer opportunity, but those that enjoy it will enjoy it. The language is irrelevant - joy trumps difficulty.
This is true for so many well-paid jobs. Smart kids get pushed into medicine, but good doctors are those that like being around sick people (and making them better). Sure it pays well, but often that's a sign that its a shitty job with a high skill level, and high societal value.
I'd still be programming even if I didn't get paid. It gets my motor running. But I understand now that its not for everyone.
[1] go on, describe your job to a middle schooler. Hours behind a desk, staring at a screen, spending hours to find out what a comma should have been a period... it's their very definition of a nightmare.
But most of my job is not creative. Writing another json interface to some random API is not creative.
Very, very, seldom is my creativity visible to others, and in more than a few cases the creativity works against the project in the long run.
But I love it anyway... :)
But really someone else must say exactly the same thing about my fully engrossing coding or sysadminning.
For me it's building castles and engines, but to someone else it's just "sitting in front of an editor all day"
I’ve seen several version of Basic, but I’ve written only a a small bit of code in one of them, and that was 30 years ago. So I don’t know enough about the language to know what his objection was. The language I’ve programmed in the most is Ruby (also my favorite so far), and the one that interests me the most to look at next is probably Pharo. And I know Dijkstra did not like object-oriented languages, either.
I'm a fan of Dijkstra, but it's best to take his opinions with an appropriate dose of salt. He liked to be provocative.
There is also an argument against learning programming with languages that have no concept of a heap. I agree that a C pointer is a weird thing at first, and some people never get it. But I've softened my stance over the years. People can be productive coders without being bit twiddlers.
It practically forced you to write obfuscated code, and programs larger than a few dozen lines become exponentially harder to manage. Imagine the worst code you've ever seen.
People who got good at coding in this way tended to develop mental habits that had to be un-learned when they moved to a more advanced language such as Pascal, as I did. With that said, beginners in any "scripting" language can evolve in the same way, if not taught some better habits. I've seen some Python programs that were as bad as my BASIC programs.
When AI can write code for itself, it will be trillions of lines.
Nontrivial basic apps have to be written essentially like assembly, or worse even, chock-a-block with single lines with 2 or 3 different exits, and every 3rd line is also a goto target while also still being the ordinary next line in some routine.
And it's not because the programmmer was thoughtless or undisciplined. With only a few k and basic to work in, this is just required to get the job done.
Outside of something quite as limited as a trs80 model 100, you can have at least some kind of modularity using chain, if you architect everything around that concept, and develop a framework or set of rules you follow the same way everywhere, like having a dispatcher main loop and all other modules all follow some consistent set of standards so that all modules can rely on all other modules working the same way, with a common interface, entrance, exit, params, etc.
Instead of functions or gosubs, you are always chaining forward, loading a new file, and sometimes the next file happens to be the one you came from previously.
This is also what killed the Apple II. People figured out places that they could branch into the BIOS and OS code to do weird things or bypass the time consuming parts. The result was that every byte of the code was potentially a branch target, and Apple could never change it. Even upgrading to the Apple IIe was fraught, and I made a hack for my mom with a toggle switch for choosing between the Apple II and IIe ROMs.
It's one of the reasons why Apple preferred a "closed" system for the Mac.
Almost all software uses the main rom as a library of functions, and if you change almost anything in the main rom, you break almost all software. It's why a lot of software that works on the model 100, doesn't work on the practically identical Olivetti M10, Kyotronic KC-85, NEC PC-8201, and doesn't even work on the non-US versions of the model 100! All of those machines have practically identical hardware, and practically identical main roms, but, not identical. Mostly it's all the same routines just with some addresses moved around by a few bytes, and that's all it takes to break everything.
To patch the main rom for y2k, you can search for a particular string of bytes to find the spot where "19" is hard coded, and edit it to "20". It's in a different spot in every different rom, but the routine it's part of is actually the same in all of them, and the same search & edit works on all of them. (ok the NEC does add something else since it also hardcodes "83" for "1983" somewhere else as part of some other routine that only the NEC has, but the part that has the "19" is the same as all the others.)
The point is, that's how similar they all are. And yet software isn't portable between them. The exact same routines, not even changed, but just landing at slightly different addresses, breaks all the software.
I've got a few vintage BASIC machines now and some of the code for those machines is almost unreadable. What struck me now that didn't when I was kid was kind of how much like assembly language BASIC can be in some of these computers. On machines with very limited RAM but plenty of ROM, BASIC acts like compression allowing you to write much more complex programs than you could actually fit in RAM if you did everything in machine code. And, like assembly, being terse and clever can result in better performance and smaller code.
I'm considering writing a BASIC-to-BASIC compiler for these machines that works something like a JavaScript minifier.
And pointedly, it wasn't a failing of the programmer writing badly.
First, you can say that about any language when trying to learn another. The classic “writing Fortran in Lisp” concept. Learning to write idiomatic BASIC doesn’t prevent you from learning to write idiomatic anything else.
Is there some, perhaps, unlearning necessary? Of course there is, as with anything. But it’s not fatal.
Second, it’s hard to appreciate how good something is until you’ve fought through something else that could have benefited you, if you knew it.
Early BASIC is not very expressive, and therefore limited. When you move on to something more modern, you don’t necessarily take it for granted. “Oh boy, this is so much better!”
Now you know WHY it’s better rather than just accepting it as rote. That leads to just a better, and deeper understanding of the whole field. When you were implementing your first B-tree, or hash table in raw C, you learn to appreciate why the one in the utility library, that you get for “free” may well not only be better than the one you copied from your “Data Structures 201” book (since it just may well be a more advanced algorithm), but you’ll realize how it works as well.
In contrast just blindly drag and dropping one into your project because you found a link on the internet.
Similarly, while it’s easy to condemn these older systems, if you ever go back and try to do work on some of these vintage systems, at their vintage speeds, you may well appreciate why something like BASIC was limited in the ways it was.
Are the more advanced language features worth the expense they incur? Maybe, but also maybe not.
Maybe for some the habits they learn have life long impact, but I don’t think being exposed to different idioms and methodologies of software development is a bad thing. Let’s folks learn and understand where those sayings and “best practices” they blindly apply (and not always necessarily for the better) come from.
It is very hard to teach programming to students.
Most students at the time had some exposure to Basic (there was little else available to the non-student at the time), but programming is hard. Most students make lousy programmers, especially if one adjusts for the standard Dikstra might have been hoping for.
He chose to see Basic as the common denominator in the ones who failed (with the "almost" qualification to cover the outliers) but I'd suggest that correlation is not the same as causation. Then again, who am I to argue with Dikstra?
My personal experience is that after having fought with the limitations of BASIC, I enjoyed the power of C: pointers, that most students struggle with, were fresh air for me.
On the contrary, I was exposed to Pascal after C, and hated it: haw can you tolerate self- inflicted limitations when you know that there's something better out there?
What I learned is: always go from simple to complex, never backwards. So yes, BASIC is a great choice for absolute beginners.
The fact that there are many great programmers that started with BASIC disproves this quote.
What I can tell you looking back is that it was a fine way to get started. We can debate whether it would still make sense to use something like this over Python for a modern 9-year-old. Certainly it's much more limited. But I will say there are just a lot fewer foot guns for a complete beginner. There's less surface area, so there is less to learn, but also less to do. I don't think that's such a bad tradeoff actually. Sometimes limitations actually spark imagination. And it's motivating to be able to learn all of something. But there are certainly free/open source BASICs that are just as good today. It's a legacy product.
1974 - Kemeny and Kurtz go to 1964.
https://james-iry.blogspot.com/2009/05/brief-incomplete-and-...