The only basic variant I used was qbasic, it was the first programming language I used!
It's not horrible at all if a child can learn to make a game in it from scratch.
However, qbasic doesn't have the line numbers (edit: at least not mandatory!). Never used a basic variant that requires the line numbers, but that seems like a total kludge!
It was fun. The dense text, all caps, line numbers in the left column, peeking and poking in memory, simple variables, it felt as a direct connection with the machine. The step to assembler wasn't that big. They shared some aesthetics, and certainly the spaghetti structure. And it possibly made me appreciate the algol-inspired languages more.
There were many kinds of BASIC created over the years. Some were incredibly limited interpreters for computers with 1kB available working memory, and decades later others were full-fledged desktop languages with structured programming and objects and GUI event loops.
Is TypeScript in 2023 the same language as JavaScript in 1996? The various BASICs were even more different than that. It’s impossible to say that they were all categorically horrible or perfect. But they did enable millions of people to discover computing, on everything from ZX-81 to Windows 95.
as the article points out, many contemporary and even earlier languages supported structured flow control, records, local variables, and subroutines with arguments. and of course lisp was basically javascript
basic had the advantage of being implementable in 4 kilobytes of ram and being memory-safe
agreed, especially on machines without memory protection hardware. these are not ideal characteristics for a beginner's all-purpose symbolic instruction code
Nobody is ever talking about the original Dartmouth BASIC, so we're really talking about a vast language family here. Arguably with more difference between different strands than e.g. within the BCPL family.
Dijkstra was in fact talking about something very close to the original Darmouth BASIC. In 1975 all the other BASICs, like for example the CDC one I used, looked pretty similar to the original. And the differences back then were much smaller than what you see today or even in the 80s.
It's been a long time since I programmed in BASIC, but I have gone memories of it.
My very first computer was a Commodore Vic20, whose User's Manual was essentially a BASIC manual. One of the very first programs I learned to wrote drew a simple bird on the screen made by characters and made its wings flap. I was mesmerised.
I started out on the C64, but that manual, too, received much love from me. I read it until it pretty much fell apart. Oh, well, the spiral binding might also have had something to do with that ;-)
The VIC-20 Programmers Reference was also a great next step, to get you into assembly/machine language. There wasn't a good freely-available assembler, so you get to become the assembler itself, POKEing instructions into memory.
It's a great language if you want to write a compiler for fun: You can add the different statements incrementally, so you quickly get to a point where you can compile your first program and then add more and more features to compile more and more.
Also, when I was implementing FOR, my first naive implementation was compiling the body first, then append the loop related things that check the conditional and jump backwards to the start of the body. "Hang on, what about the case when the condition is initially false?" I thought, only to discover that the BASIC standard actually specifies that a FOR loop runs at least once, even if the condition is false! Officially, the language is advertised as for beginners, but to me it looks like it was meant as a lingua franca of computers, as in not only easy to understand, but also easy to implement.
Trying to compile Basic is actually a bit trickier than just implementing an interpreter indeed. Like the FOR statement example you mentioned. Another messy situation is non-lexical FOR/NEXT like here [1], where NEXT can be encountered before a FOR statement, fairly certain I did not get it entirely right there.
Original Dartmouth BASIC had only 14 statement types, and it takes very little efforts to enumerate and implement all of them, even if you are just starting on a compiler journey and making things up suboptimally along the way.
The bonus upside for choosing BASIC as your first compiler project is that you get decades of vintage test programs to play with like this one [2].
The biggest achievement of BASIC was probably that it was the gateway drug into computing for teenagers throughout the 80's, because every popular home computer came with a BASIC builtin, available right after switching the computer on.
Exactly! My Atari booted up to a READY prompt and even loading a program/game from tape required typing a BASIC command. The on-ramp was incredibly shallow and smooth.
Yes. You owned the entire machine, there was a progression to assembler (awkard, but possible if you didn't mind hand-assembling the hex and typing into a BASIC shell), and you could a huge amount just with that.
The capabilities and the limits captured your imagination in a way that the modern stack doesn't come close to.
And especially in the UK, easy and cheap access to 8-bit machines for teenagers launched a generation of coding careers.
So Dijsktra is wrong. It's very possible to learn CS principles after learning BASIC. it's certainly an adjustment, but it's very easy to sell if you explain that you can build larger structured projects from smaller elements, including more complex data structures - not a difficult concept for anyone who taught themselves assembler from magazine articles and books, because there was no other help or support.
The other thing BASIC did was gave some of those teens a career. The cost of entry to a small game business was very low, and there were plenty of games that didn't even need assembler.
A bit of advertising in the magazines, maybe some hand duplication to start with, and good games made non-trivial money almost immediately, through organic word of mouth promotion.
I found it very easy to learn these principles once BASIC taught me loops and functions. Once out of BASIC, a tough concept to grok was passing pointers and different data types, because BASIC made global and local variables so brainless. Object-oriented languages are in many ways further from assembly than BASIC, but even VB teaches you objects and methods and properties albeit in a very simple form. Leaving the virtual box framework of basic was also somewhat difficult, but I don't think learning basic made it any harder or easier, just more frustrating because it seemed so pointless at first. It's like learning to drive an automatic and having someone tell you that you must now learn a manual transmission with manual brakes and steering, and how to change the oil/clean the carb. Seems silly at first, but ultimately rewarding.
Same here, got my Atari 400 (with the membrane keyboard) and wrote so many games, then later utility programs, machine code routines, and not long after macro assembler.
In no time, we were exposed to FFI (calling machine code routines) and internals (like BASIC program/token storage to make a line renumbering utility), and all the hardware interface memory locations. Learning how software copy-protection worked and defeating it was a great reverse-engineering/debugging passtime.
We were always reading about new tricks and sharing with each other who had the same machines. Getting a copy of the "De Re Atari" document was the holy grail where we felt like we had access to know everything, and we mostly did. I even tried as a kid to make a multitasking 'game' which failed because I didn't know enough about interrupt handlers, but I was close--it worked, briefly.
So true. The seeking and finding and revelation in its contents was something else. It also took a lot of reading and applying to get everything out of it.
> every popular home computer came with a BASIC builtin,
Until the Mac put the kibosh on that. You were firmly on the outside of the box, and to get in you had to buy either a box of floppies from Apple (MDW, was it?) or something like Lightning C which was just a couple of disks if memory serves.
Later there was the Hypercard thing, a scripting tool from Apple which did get some traction, but was never very popular.
The article mentions processing.js as a modern equivalent, which it can serve being rather high level and outputting great graphics. But that misses the "close to the machine" aspect of having a computer fully within the control of your hands.
Similarly using a web browser and View Source for HTML/CSS+JS was a modern equivalent before we had all the single-page-apps/frameworks that make it incomprehensible. And again the 'machine' is an abstracted web client.
The Commander X16 project[0] aims to recreate that environment for modern times (and also available for purchase). It's effectively what a C64 might be today, with more (but still limited) memory and easy to program graphics and sound. Something like a Raspberry Pi 400 looks the part but would end up running something like Linux and OpenGL ES2.0 which isn't much different than a regular desktop.
I can't find the original video where I saw the project getting started, but here's a review[1] that runs through what it is.
Yeah the Commander X16 isn't the most affordable, but I think it's the most accurate 'retro' machine. Specifically the custom VERA graphics hardware works in ways analogous to the machines of the time with various tile or bitmap modes and sprites. It's also in the 'batteries included' camp with lots of software support to get right into writing programs rather than lower-level tinkering.
There's even a full emulator[0] available so you can hack with friends who don't have one, or share your creations to run in the emulator.
That's a good point. I focused on this aspect in a much earlier post, so tried to stick to my BASIC vs alternatives investigation here.
The fact that the home computers used to be READY to be programmed within a second from powering up, and gave you such an easy access to all basic operations was what was so ... addictive?
It was one of the most important, if not _the_ most important, source of computing knowledge in my early childhood. I was born in 1984, got my first computer – a C64C – in 1991, and my dad procured a heap of past issues of „Bajtek” from previous years. In rural Poland those days, knowledge was hard to come by, so those proved invaluable to me.
Not only were there type-in programs and games, like in the German 64er, but most of them were actually accompanied by prose articles that offered clear explanations, background, and trivia. I learned BASIC from Bajtek and a few books. Bajtek literally had a monthly column called „For Preschoolers Only” with a BASIC tutorial in it.
I (the author) am Polish :) Bajtek was a treasure, the best pre-internet source of all kinds of information, also the advanced stuff (like a multi-issue series with a list of system calls on an Amstrad!).
I didn't have access to any of it until the late 90s (still didn't have the opportunity to switch to a PC).
BTW. Retronics is re-issuing Bajtek now! They print the same old issues but re-typeset for the highest quality. A true gem.
BASIC was ideal for introducing a generation of school kids to programming.
Back in the 80’s you fired up your computer and you had a readily-available interpreter for which you could immediately do ‘real’ stuff like printing characters anywhere on the screen and turning on and off pixels (even in colour on some platforms).
There was no need to compile or build a project or start with a lot of boilerplate. You just did stuff right away from a REPL or could make programs from line numbers and save them.
I learned a ton from it. Eg how to think algorithmically and break up something complicated into small parts. A key milestone was grokking the difference between GOTO and GOSUB. I also understood much about its limitations once I started learning Turbo Pascal in high school.
If you’re judging BASIC compared to a modern IDE with a modern structured language of course it falls short, but for what it was at the time it was nearly perfect.
That's what I miss these days. The barrier was low, you had access to it immediately and when using a computer from that era you were going to be exposed to that stuff. Now everyone has a smartphone but you cannot easily program with it and moreover the chances you will encounter a programming language using it is 0 unless you look hard for it. A lot of young people are missing opportunities of discovering cool stuff and having fun. Which maybe hurts the entire profession. Using BASIC and assembler was a ton of fun back then.
As a child a learnt BASIC after having taught LOGO. As a child that was an advancement (with all due respect to LOGO). Almost every computer included BASIC so it was an universal programming language for home computers. You could also interact with assembler (CALL/SYS instructions) so it enabled to go even farther. Conclusion, BASIC was pervasive and it was not horrible since your focus was in creating something on cheap personal computers. I know two older people than me, accountants, that learnt BASIC around their 40s and build their own accounting programs in a ZX81 [2] and TI-99/4A
[3]. I don't think many people now of that age (plus "age inflation") learn this new skill (programming) and create an useful program or even a script for themselves.
The language is primitive by today's standards but it gives you all sort of ways to express yourself. When BASIC progressed and was more structured, for example AmigaBASIC from Microsoft [2], there were more alternatives and more evolution so it is natural that BASIC faded.
Also important to highlight that every popular computer magazine (media) published BASIC code, also books.
I've programmed extensively in QBasic and TI-BASIC. Both were extremely limiting, ofc.
But there is one thing I'm very grateful for, in retrospect. Both languages required very few "concepts". Functions? Pointers? Classes? These are basics for coders, but BASIC didn't ask even this of you.
With a small syntactic baseline you could make full on games pretty easily. Compare this to making games even with Python using PyGame, or Godot, or whathaveyou.
Of course, nothing prevents you from learning Python and just limiting yourself to a few data types and control structures. But what really made BASICs easy (for me) was that "draw to the screen" was such a primitive operation. Same with detecting keypresses.
Again, these are easy if you're a software engineer, or even if you know how to code. But what if you don't?
Even Visual Basic had this virtue. When I was in Mexico I volunteered at a homeless shelter. The man who operated the shelter had no coding education, but was able to self teach Visual Basic two decades ago, and had created an entire system for managing the facility.
He had tried to rewrite it to use a more modern language (I believe C# or VB.Net) and was totally unable.
I've never used VB but I've heard countless tales like this, where non-coders create entire functioning software in it.
Linux is still missing something which had as tight a development loop as VB in terms of "intent -> result" (I've never managed to get Glade or any of the similar GUI tools working, and thus never really written a GUI app in Linux).
Lazarus is good and featured enough, if you know your way around, and the language is nice, but for "ease of use" and "beginners" the Lazarus just has horrible UX, on par with Eclipse.
That's because it's mimicking Delphi, which was mimicking Visual Basic (the first one). Just like Eclipse was one of the first of its kind.
People hate changes, even the slightest UI color changes are booed down. I can imagine redoing Lazarus to look like IntelliJ IDEA would be a lot of work that would be frowned upon (though I love IDEA... but I myself find it not tempting at all to switch to their "new UI" which copies VS Code and hides away my most frequently used features behind submenus and pictures, like I can't read ;-) (old man yelling at clouds)).
Gambas very much fits that bill, as the other reply mentioned. If you want to pay for something, Xojo (formerly known as RealBASIC) does too: https://www.xojo.com
My advice to developers that are interested in Xojo, or looking for something different in terms of languages / development platforms, is to give Xojo a try. You can build and run apps in debug mode for as long as you'd like, all at no charge. It's only when you want to compile apps so that you can run them as executables and/or for distribution that you'll need to purchase a license.
Emacs does pretty well. Its focus, however, is text rather than GUI. However, it has a really tight connection between intent and restult. Your point is a good one. VB, especially in the context of VBA in Excel, was quite effective. Was it Joel Spolsky who headed VBA design?
Why would it be outdated? I just spent some time browsing the VB .NET docs and there's about everything you could imagine including async functions or iterators.
I also used to be a non coder until I got my hands on VB. Consequently, my first programs were GUI instead of command line, which was everyone else's "hello world". It took a while to convince myself to learn other languages that didn't have GUI out of the box, because non-GUI software didn't look like the software I knew or wanted. My more "advanced" C/C++ friends, on the other hand, thought of GUI stuff as being more difficult.
I also grew up with BASIC (no new flavor. Controlling pixels one at a time on a TRS-80). One thing it teaches you is how to organize your own code, i.e., spaghetti is so easy in that format that you develop a lifelong appreciation for OO or functional code once you move on to it from thousand lines of GOTO and GOSUB... yet it teaches you everything you need. Yea
it exposes screen interfaces you don't have to write yourself, but the point is to teach logic, not pure CS. Every first time coder should be exposed to BASIC because it has no preference or bias... any code you write in it will be equally shitty and equally educational.
Learning BASIC made me feel OO, clear variable names and clean code was unnecessary and I made no effort learning that back then. I’d regret about that much later
Could they have been unnecessary at the time? Not all applications (in the literal English sense of this word) need this, and I think it's something we embrace as we advance.
After BASIC (which was obviously also my first, if I didn't mention it in the article already :D), I switched to a PC and used Borland Delphi for my first programming adventures. Fully object oriented language, with all the structural help you may want. And yet, my code was often repetitive, procedural, or just doing silly things (and variable names mixed English and Polish even within a single name).
But it was a phase. I think a beginner programmer focuses on the goal and struggles with their way to reach it enough not to bother about the best, or most beautiful, or idiomatic way to achieve the goal. However, after a few years you build the awareness that if you're going to revisit this code in the future, you want it easy to read as well, and you may want to hide certain functionalities and operations behind functions, procedures, objects. The more time you spend programming, the more you appreciate structuring your code, then your application, then your entire architecture in a way that wouldn't hurt you in the future... or minimize the hurt.
It's also a matter of the right tool for the job - an advanced programmer, writing a one-off script to quickly get or transform a result, may also decide not to decorate it with a sophisticated system of classes :-) I'd just write a bash or python script.
Nearly the same story here. In HS the only computers in sight were TRS80 IIIs, PET4032s, and C64s. By graduation I'd moved to assembler for the sense of the metal and the speed.
First year at college, took intro to programming in Pascal, and oh what breath of fresh air that was. Sure it was cumbersome, had a lot of ceremony, but it had procedures and functions that you could pass parameters to! And structures! Things that had been a hassle in BASIC suddenly had legible descriptions.
But yes, BASIC did one thing very well: it got out of your way and let you cut your teeth on the fundamental concept - that a machine can follow a sequence of simple instructions to produce complex behavior. It provided a sense of that dynamic, that I think would have been a little less obvious with an edit/compile/test environment with as much ceremony as Pascal etc.
Python is ideal! You can just drop code in a file - no structure - and it runs. Then when you have code you wanna reuse just wrap it in a function and drop it at the top of your file. That get too much? Split it into a different file and import. Have cases where data + logic in functions kinda all fit together? Move them to a class. Start getting overwhelmed by all the runtime errors and stuff being slow? Learn C#, Kotlin, Java or Rust.
no structure apart from the very strict structure imposed by the significant whitespace, guaranteeing that copy and pasting code will result in something unexpected, for a beginner?
I spent a pretty significant amount of time in QBasic. It definitely has functions. It also has subroutines "Subs" and the difference was a function returned a value and a subroutine did not.
I remember QBasic (the DOS 6 version at least) having a distinction between Subs and Functions, where the function returns a value but the Sub doesn’t.
I never stoped to wonder why and just accepted this as reality, but the mere existence of this distinction helped me understand software from an engineering point of view quite early.
It was a bridge to Functional programming, CQRS, Bertrand Meyer’s teachings, 10 years before I could even have a chance of hearing about it.
I didn't understand it at the time, but even Applesoft BASIC made the same distinction (DEF FN/FN vs. GOSUB/RETURN). In fact functions could only be defined as pure mathematical expressions.
There are some modern versions of basic (e.g. Purebasic and Powerbasic) that seem extremely nice. Also, there is Xojo, which is a fully OO Basic that natively cross compiles to Mac/Windows/Linux/Android/iOS/Raspberry pi. Xojo also has a full RAD tool that abstracts away a lot of stuff. Pretty easy to build games on it too. It's commercial though.
Xojo is full of bugs. https://ifnotnil.com was set up after Xojo banned users for complaining...
Xojo also compiles to Web Apps. But to compile to all those targets means creating a
- Project for Desktop ( Mac/Win/Lin/Rasp )
- Project for iOS
- Project for Android
- Project for Web
So, four different Projects instead of one Project. You can create externals to share code between projects.
I used Xojo shortly after it became available under the name "REALbasic" back when you could only compile to Desktop. Web, iOS, Android were later added.
I spent a ton of time on Web 1.0, but Xojo replaced it with Web 2.0 with no upgrade path, practically requiring a rewrite.
So I now code my Web Apps with PHP. While I really wanted to keep using Xojo, the lack of quality just got worse and worse. The only bugs I encounter now are my own. If Xojo was as tight as PHP, I'd still be using Xojo!
VB is what made me fall in love with programming, because it made coding feels like WYSIWYG. To this day nothing compares to it and I still never really touches front end programming again ever since.
We miss having environments like BASIC nowadays, Python is probably the closest to it, but at least by the 16 and 32 bit days of home computers, BASIC not only was structured, native compilation was part of the picture against.
My first computer was a Timex 2068, and something like CircuitPython or MicroPython, or TI/Casio calculators with them, definitely give similar experience.
Mainframes or minicomputers of course, mostly from IBM (mainframe) and DEC (minicomputers). There were other players and IBM sold minis and DEC sold mainframes but those two dominated those two niches.
What is a good program? To me, it's a program that does something useful and serves a purpose (being this a person or an organization).
I'm tired of this "good programming", there is people that talks about good programming and than produced programs that are either too complex to do something useful. These to me are bad programs!
There were a ton of companies or persons that used (and still use) BASIC (or Visual Basic) programs to do stuff, and maybe if it wasn't for BASIC these programs would probably never be written.
Same thing we can say about COBOL, a ton of companies are run by an IBM AS/400 running old COBOL programs written in the 80s that still work fine.
Running fine isn't the only measure. It also needs to be maintainable. Those old COBOL programs are a major headache for the organisations running them. One company I worked for had to pull old COBOL developers out of retirement to implement a mandatory change to a critical program. I don't know what they will do if it happens again in 10 years.
I agree with your point on companies running on VBA and how much worse the world would be without. But I still blame microsoft for making a language stuck in the 90s the only option for those users to integrate simple coding into their workflows. They are forcing users onto a bad path (and I am not complaining about the Basic syntax itself, but about the lack of the 25y of evolution and improvements you would find in VB.net).
I don't see what there is such difficult in a COBOL program to have to take a programmer out of retirement. The syntax may be different and old, but still there is no reason why a programmer can't learn it. I mean, I know people of my age (30 years) that work on companies that still maintain COBOL programs, and they learned it (some of this went to work for these companies right after high school).
It's not that is rocket science, like it is not BASIC. The most difficult thing is getting a development environment set up, but a company that maintains such programs can use virtual machines and test systems. There are even companies that provide you "cloud" IBM AS/400.
Anyway, what I meant is that normal companies are not Google, you find a small department of developers (in case of small companies, only one) that does everyting, from fixing the printers to developing the programs that are useful to automate and do the job the company needs to do. I've seen companies build even systems that manage an entire production plant in house with a complex business logic, something that not even commercial software that cost thousands of dollars do!
With no budget, and thanks to simple programming languages (in the past was BASIC, today I say that it's python) companies write programs that helps them speed up the work, that may be an ugly file of 10.000 lines of code with few comments, copied/pasted blocks, classes with poor or no encapsulation, but that work.
Saying that they are bad programs because they don't follow SOLID pricniples, or they don't do TDD or have a CI set up, or they are on a folder in file server instead of a git repository, to me is stupid. A bad program to me is a program that doesn't work, a program that has bugs, a program that doesn't solve the problem it was designed to solve.
A programmer can learn it, but if it's a bank that has to implement a change in a core system, I think they simply avoid developers with zero years of Cobol experience
Trying to solve the modern problems and showing that one needs more code than in Python is not the point.
The reason Basic wasn't horrible but amazing at the time as the home computers appeared is hard to understand without the context of that time:
Basic on these computers was, in today's language:
- an actual "complete" operating system and
- a command language and
- a script language and
- a programming language
Additionally, if one wanted to use the "full power" of the CPU one had to use machine code, as there was so little RAM that most of the programs that did fascinating stuff were true masterpieces. Those using Basic knew that it's not "all there is".
One really cool thing Atari Basic did was that you could list lines x,y and just move your cursor up to the line you wanted to change and insert/delete/overtype characters. It would even handle line-wrapping of the logical line up to 3 physical lines. Press enter and that's the new line (or change the line number and it's a new source line).
It was often used for renumbering a few lines to make room for more as there was no built-in renumber utility.
FORTH was the closest competitor. Perhaps it could have worked well enough if it was extended with custom parsing modes for infix arithmetic and for printing out floating point numbers, which were the main poimts where even minimal versions of BASIC were genuinely more user-friendly than FORTH.
Punched cards were a thing of the past when I first encountered computers (in the form of ROM BASIC machines like the TRS80 and PET4032), but there's just something fascinating about being able to physically hold the individual lines of your program in your hand.
These days if you want to run a program to crunch some numbers, the program is one file, and the data another - but back then, since you fed the whole 'job' into the card reader at once, you could change the data set by just swapping out the cards.
Not saying that this was in any way better. Just that the idea of it feels so alien - and this was the era in which BASIC first evolved.
Darthmouth BASIC used teletype terminals, not punched card input. The article has a picture, and comments "Dartmouth did better. At any time, when the program was in memory, you could use SAVE to save it from being forgotten when you finish working with the computer, and RUN to compile and execute it right away."
As may be, just going on observation that when I got to college, several of the profs still had punch decks lying around the offices. Granted that said offices were not more than 3 minutes walk from the computing center where the mainframe lived. Clearly anyone miles from campus, or anyone seeking any kind of interactive session, would want a tty. But evidently if you wanted to run your program more than once, and didn't want to incur the rental charge for online "DASD" storage, batch-job card decks had been an option. I presume that did not exclude BASIC programs.
Also, I suppose "era in which BASIC first evolved" would have better been stated as "part of the era in which BASIC first flourished"
I still remember the appeal of BASIC to me as a kid. A simple GOTO loop over INKEY, in which you can test which key is pressed and erase+redraw a CIRCLE accordingly. A trivial thing, but the feel it created was unforgettable.
Idk what Dijkstra means. My whole generation started with BASIC and learned languages as they’ve become useful enough for every new wave of accessible hardware, which wasn’t cheap for a hobby. There was no like “oh, now you’re lost”. My next language was 8080 assembly then Pascal then 8086 then C. You just can’t learn Pascal and C on a Sinclair clone when loading a compiler from a tape recorder takes half an hour and most of the available memory. And you can’t learn Python either, because it doesn’t really exist yet. I know it’s from 1991, but never heard of it until ten+ years later.
I also know that some ROMs had FORTRAN instead. Maybe Dijkstra would like to re-teach FORTRAN programmers more.
I thought the article did a pretty good job about describing what Dijkstra meant, and pointing out it was written years before you learned a BASIC variant on a microcomputer.
What are you still unsure about?
> Maybe Dijkstra would like to re-teach FORTRAN programmers more.
Unlikely. The article points out Dijkstra called FORTRAN "hopelessly inadequate".
I actually learned Pascal on a ZX Spectrum clone. It was Hisoft Pascal, so it was a bit limited (no strings - you had to use ARRAY OF CHAR instead). But it was awesome to draw 3D graphs due to its “fast” floating point routines.
On the Commodore PET, at least, you could do all kinds of clever things with BASIC due to the special graphics characters and the "cursor control" characters that could be embedded in strings (up/down/left/right etc). One of my hacks was a playable, graphic video game in one line of code (almost the full maximum 80 characters) and another is the standard 1-liner that generates mazes.
For examples of fancy BASIC graphic programs, search for:
Cursor magazine programs did occasionally have an assembly language subroutine; at least one flashed the screen using one. But most of them were just BASIC.
Purists may scoff, but kids with zero experience could make animated graphics after just a day or two of playing around, and curiosity about how more sophisticated programs worked (in my case: The "Miser" text adventure game) would soon motivate to find out more. Is that bad? It was the whole point of the language, the B stands for "Beginner". Plenty of time to graduate to other things later (in my case: Assembly language -> Pascal -> C).
Basic was my second programming language after Logo[1] in the early 90s (I was in 5th grade) in a third world country, on very slow computers that a factory had donated to my school after they had passed their useful life for the factory. In such an environment basic was amazing. Low barrier of entry both from computing and knowledge perspective. Easy to learn and create a lifetime of love and passion for programming and all things computers in people like me.
Curious author here. For me, Logo was a curiosity covered in chapter 6 of the manual. I wonder what the experience of learning it first was. Was it mostly like vector art fun, or did they teach more advanced concepts too?
I've been thinking about this recently when teaching my daughter to program.
What was very different about BASIC compared to today was that it was "Beginners' All-purpose Symbolic Instruction Code" (that's what BASIC stands for). At the same time it used to be used by adults to solve real world problems.
If you outgrew BASIC you could easily segue into Pascal which was much more powerful but still designed with education in mind.
I think today the gap between what is used to teach and what is used to solve problems is much bigger.
Once children get older the motivation for toy languages understandably goes away but learning a modern programming language that is actually used in the industry is a big step that is not easy to overcome.
I have no perfect solution for that but for us and for now we settled for Godot and GD Script. It is simple enough to get started and I think when I showed my daughter the Tesla App [1] it was a big motivation.
[1] I've heard the current version it is not made in Godot anymore, but it was when we started on this journey a while ago.
I'd say Scratch is the #1 way kids to day are introduced to programming in 2023
For parents that have some 8bit experience, Pico-8 (LUA) is also relatively popular. It's basically like running an Apple 2, Atari 800, Commodore 64 as if it booted into LUA instead of Basic. You can trivially draw things, and peak and poke bytes into "Screen memory" if you want to feel like you're "touching the hardware"
JavaScript is also available everywhere a kid might be and it's easy to draw stuff with literally millions of examples all over the net. Processing.JS is also a thing https://thecodingtrain.com/
I spent the summer of '83 at the GE Wilmington, NC nuclear fuels plant as the sole user of an HP 9845C with the integrated full size plotter. My job as a GA Tech ChE co-op student was to go around the plant with a rather simple gradient air sampling unit mapping out the airborne density of the various sizes of UO₂. I would take my overnight measurements (point a geiger counter at the different filter papers from the different levels) and enter the data into a program I wrote in... HP Basic. I would then feed that into another program I wrote in... HP Basic that plotted the densities as level plots in HPGL across a rather detailed for the time 2D map of the plant. It produced multicolor paper plots on full size drafting paper. My bosses, the physicists in the safety department, were very pleased. I was so happy doing this that I spent the evenings in the UNC Wilmington library learning level plotting algorithms. I needed more programming time so I would come in very early in the morning and have to remember to clock in at 8AM (overtime not allowed). All of us co-ops made $10/hr in '83, and I saved enough to pay for the entire next quarter at Ga Tech every quarter I spent working.
Weekends I spent at the beach, though.
I see from Wikipedia that the system costs were enormous! But that was an exquisite summer romance with BASIC.
Not too many years later I discovered Turbo Pascal. Yeah, off to the races. And then came Turbo C++, and g++ around '92. Haha you kids today would really enjoy debugging templates in early g++. (The idea that you could write the same code for 'float' and 'double' was intoxicatingly cool.)
The transition from Fortran (what I learned to program with) => HP Basic => Pascal => C++ was pretty easy. Pointers, well if you study 'The C Programming Language' carefully, are not difficult. People writing serious computational mathematics codes are constantly using pointers, just not as 'pointers'. Debugging, well that is another problem entirely, and I believe from way out here in the future, that that is the most difficult problem of all. How to program in such a way that the bugs are not silent. Those silent ones were the cause of most of the grief in my programming life.
The thing about HP Basic is none of the bugs were ever silent. Same with Turbo Pascal. I did a lot of really cool things with those 'toy' languages. They never caused me any grief.
So I think Dijkstra didn't understand (maybe) the importance of painless pleasure when (some) mortals are learning programming. It sure turned me on.
BASIC was responsible for sparking the interest in computers for a generation. One of the most harmful falsehoods about it is that somehow GOTOs and line numbers would turn you into a bad programmer for life. I think that even today there is nothing like BASIC to get kids interested in computers.
But it's not a language just for kids. While most dialects are somewhat limiting, there is nonetheless a TON of real useful stuff you can do with it.
I learned Basic at 10, and I would argue that Python is a better choice today. But regardless of which one, the most important thing about basic was that for a while every computer came with some flavor of Basic. It's what got a generation hooked on tech.
Why oh why doesn't Windows and macOS come with Python and Idle out of the box? Or does Mac, I forget.
The Mac does come with Python, but of course it’s easier to get started from zero when the first thing you see after switching on the computer is a BASIC prompt.
Having an onramp to programming is nice. I also imagine there was more of an incentive to write your own programs when there weren't a million games and other apps already available in app stores.
I also started with BASIC at 10 (C64 in 1990) and I'm going to teach my kids to code in Python. It's simple (low abstraction) and integrates well with other things (IoT) and they can use a REPL.
It's disappointing that Windows doesn't release with an accessible interpreted language. They ship with a couple of games so why not drop some kind of super integrated and simple programming environment? Most of my generation cut their teeth on Microsoft Basic after all.
I think most tech companies rely on ignorance to sell their "simple" solutions. If everyone could solve their own problems their own way, then nobody would buy "simple" solutions.
Tech companies sell convenience. Most people don't want to to do the work required to "solve their own problems their own way". They aren't buying simple. They are buying: "It's Already Built".
`Win+X I` brings up a PowerShell window. It’s supremely integrated - it can do ANYTHING a compiled .NET language can do, including calling into unmanaged COM, etc.. And it’s super simple - you can get started with simple string processing and file manipulation in just a few characters. It’s just not popular in the same way BASIC was.
Agree with everything you've said about Powershell. It's pretty cool.
Buuut...the common Basic computers of the time had commands that let you do built-in graphics in a very simple manner. Not anything as crazy complex as the .NET charting and GUI stuff available to Powershell now. It's a real shame there isn't a built-in DSL that could allow normal users (i.e. not full time developers) to build some really simple games in like half a page of code.
Commodore was very much the exception here. Pretty much every other 8-bit computer's Basic had a bunch of commands to do graphics and sounds. But Jack Tramiel just slapped in a licensed copy of Microsoft's Basic with the least amount of work necessary to make it run.
The Commodore machines at least had a fairly extensive set of graphics symbols to create basic [pun not intended] graphics. For sound, though, there indeed wasn't really anything in Commodore BASIC V2.
Tangential: Artist Raquel Meyers does really great stuff with the CBM graphics character set, see https://www.raquelmeyers.com/
I think the C64 alone was responsible for a lot of the bad press BASIC got in the 1980s-1990s, from former Commodore owners who knew that one, terrible BASIC and concluded from a sample size of 1 that BASIC was bad.
Most other BASICs were better. Some on machines of the same era were much better. The BBC Micro had the same CPU and had BBC BASIC, the fastest interpreted BASIC ever written, with types, structured code, named procedures with local variables, inline assembler, rich graphics and sound support and more... in 32 kB of ROM (half for the modular extensible OS, the other half for the BASIC).
Tramiel cheaped out: the machine had 20 kB of ROM, with an OS half the size and a BASIC half the size (plus a fancy character set).
One of the advantages of a classic BASIC for a beginner was its very small feature set. It was easy even for a kid to get it all in his or her head. Python not so much, especially the idiomatic stuff. BASIC is very clear:
10 PRINT "HELLO"
20 GOTO 10
If you understand that the computer will execute lines in numerical order, it's very easy to understand that. The equivalent in Python of just that simple thing would not be so clear.
It's great as an introductory language IMO. I disagree with Dijkstra that it will do any permanent damage -- if anything it will help the programmer appreciate the advantages of structured or object-oriented code when they are ready for it.
Right? I was just about to say that Windows ships with power shell these days, but then immediately realized how poorly that maps.
It used to ship with qbasic and a nice editor held over from dos. That was pretty good, though it was essentially hidden. It was there, but there was no icon for it and no docs or directions said to use it, let alone boot right to it as your primary interface.
Basically the driving force behind the production of Windows is the parts of MS that make money from it, not the developers who would write stuff for other developers if they could.
They want users that consume, not produce, and they absolutely do not want users who tinker and poke and modify.
They offer development systems only because they still have to, and they make even those into managed inscrutable products you merely use like powerpoint as much as possible.
> I disagree with Dijkstra that it will do any permanent damage
Dijkstra's quote about people who learned programming with BASIC being beyond repair is obviously hyperbole, but given the number of programmers he taught, I'd assume he was seeing some significant difference that was important enough to prompt his statement.
macOS-10.14 (Mojave) has python-2.7 + idle still bundled, but macOS-13 (Ventura) not any more. You'll have to install it via MacPorts, but at least you'll have a choice which version to install.
My Mac with Sonoma aka macOS 14 has Python in /usr/bin/python3, so I assume it's been installed with the system. It might have been installed with Xcode, though.
That's not Python; it's just a hard link to a generic shim for every program in /usr/bin that ships with the developer tools,
$ find /usr/bin -inum $(stat -f %i /usr/bin/python3) | wc -l
76
$ cp /usr/bin/python3 /tmp/IEFBR14
$ /tmp/IEFBR14
IEFBR14: error: sh -c '⋯/Xcode.app/⋯/xcodebuild -sdk
⋯/Xcode.app/⋯/MacOSX.sdk -find IEFBR14 2> /dev/null' failed with exit
code 17664: (null) (errno=No such file or directory) xcode-select:
Failed to locate 'IEFBR14', requesting installation of command line
developer tools.
$
and then if you're in a GUI session it pops up a dialog box[1] offering to download and install the developer tools (even if they're already installed; the example above is from a Sonoma box with both Xcode 15.1 and the latest command line developer tools installed).
I do have Xcode installed, and for me it's just Python
$ /usr/bin/python3
[ 12:18:42 ]
Python 3.9.6 (default, Nov 10 2023, 13:38:27)
[Clang 15.0.0 (clang-1500.1.0.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>>
So I guess it depends on whether Xcode and developer tools are installed or not. Too bad it's not installed by default any more anyway.
> GOTOs and line numbers would turn you into a bad programmer for life
Dijkstra will go down in history as one of the great algorithm designers, but this will always be a black mark on his legacy, possibly overshading his contributions. There's a lesson here about not pontificating outside of your field.
In his text he argued for higher level constructs, as they are established now. I think there he was right. Unrestricted goto often isn't good for complexer programs.
My understanding is that when "GOTO consider harmful" came out, the typical code flow was to put values into global variables, goto to some piece of code then goto back and continue. Nowadays we have functions with arguments and you should just use that. But harmful goto was about the specific type of coding that happened at the time, but people assume it's any goto use in general.
Dijkstra wrote that in 1968. At the time, quite a few languages didn’t support recursion (ten years later, FORTRAN 77 didn’t, officially), and lots of hardware didn’t have a call stack (a word that Dijkstra invented, and described in 1960. See https://ics.uci.edu/~jajones/INF102-S18/readings/07_dijkstra...), so if they needed one, they’d have to write it in code.
Using a language that supported structured programming would get rid of such scaffolding code that hid the logic of the actual program.
Many languages also allowed code to jump out of and into loops, and programmers (ab)used that to cram their code into the small amounts of memory they had at their disposal. The resulting code could be quite hard to understand.
> There's a lesson here about not pontificating outside of your field.
How was that outside of his field, which was about thinking logically about programming?
'Goto considered harmful' really brings nothing new to the table. It just states that gotos are hard to reason about. Well yes, that's true. Computer programs are hard to reason about as a baseline. Everyone knew that goto was hard to reason about before he wrote about it, but for some reason his letter became a reference for people who wanted to abolish GOTO from their codebases.
> How was that outside of his field, which was about thinking logically about programming?
Language design falls under human-machine interfaces, and while basically everyone in that era dabbled in that field, it wasn't really his forte.
> Dijkstra will go down in history as one of the great algorithm designers, but this will always be a black mark on his legacy, possibly overshading his contributions. There's a lesson here about not pontificating outside of your field
I am begging of you, please do a little bit of investigation into the historical context in which Dijkstra wrote that memo.
Your comment was likely inspired by other replies to my comment, but please, don't assume someone who has an opinion other than yours simply hasn't done enough research to agree with you.
Reading that paper it's hard to believe that the typical programmer cared all that much beyond getting something to work. Whatever you mean by "binary density", the subjects were programming for an IBM Model 67 which was a pretty hefty system for the time. The programs weren't all that big by modern standards either, with "number of executable statements" in the hundreds; when you have megabytes of memory it doesn't seem like spending a few extra bytes on instructions would be that big a deal.
By and large the ancients couldn't have been all that concerned about optimizations. Take a look at their "Example 6" in which the authors were able to significantly improve an inner loop thru such advanced techniques as "use 0.0 instead of 0 if you want a REAL" and "don't make extra assignments".
Do you have some evidence to back any of this up? You're claiming that software developers who had access to an IBM Model 67 didn't actually make use of its full storage space. In that case, why not buy a smaller machine? It sounds completely fantastical/fabricated to me.
> Do you have some evidence to back any of this up?
The paper that I linked?
> In that case, why not buy a smaller machine?
Because they needed to support an entire department or university worth of users, many of them at the same time.
> It sounds completely fantastical/fabricated to me.
Have you ever done serious work on a time-shared system? The kind where you type `w` and see a bunch of people who aren't you?
Nowadays everybody gets their own workstation and can use as much or as little of it as they see fit, but on a shared system trying to use the whole thing is a great way to get people mad at you, because you're taking away resources they need for their own work.
Not that you'd necessarily be allowed to use all that much in the first place, that's why things like `ulimit` exist.
GOTO-based programming is just continuation passing style - the definition of GOTO is literally switching the continuation of the current statement to something else. (Which means that its preconditions are OR'd to the preconditions of its target statement, and its post-condition is not defined. A GOTO-based program becomes easier to analyze and understand if you add COME-FROM markings to every possible GOTO target.) Incidentally, one can understand self-modifying code in a similar way.
GOTO does not pass a continuation though, so I can't see how it is similar to continuation-passing style. GOTO is just a jump like jumps in machine code.
BASIC does not have notion of a continuation as a value.
Some BASICs such as BBC BASIC allowed GOTO to take a variable or expression directly, and many BASICs supported the ON..GOTO construct that allows for the same. And turning all control flow within a program into jump-like operations is arguably the main point of CPS.
> One of the most harmful falsehoods about it is that somehow GOTOs and line numbers would turn you into a bad programmer for life.
In fact GOTOs in BASIC were, I think, a big part of lowering the barrier to programming for the new and the young. It relieves the mental load of structuring the program, allowing you to concentrate on the logic and syntax. Not using GOTOs requires already having a mental picture of what the program should look like before you write it, or at least rewriting it multiple times as you go.
As a Rust programmer, I probably spent 5-10% of my time restructuring branches to deal with Results and Options more elegantly, and it is the least fun part. While not related to program flow, it's an example of a Good Thing that makes coding less fun.
For me BASIC led to VB which led to VB.Net which quickly led me to C#.
I did some real fun stuff in BASIC as a kid that I never replicated in later languages. In kindergarten or first grade, I picked up a book called something like "Make Your Own Computer Games" at my local library. Everything was GOTOs and LABELS. The librarian didn't want to let me check it out because it was beyond my understanding, but my grandma insisted. That night and for the following 2 days, on my Dad's work computer, I would type and retype these computer games into GWBASIC in MSDOS, and then type run at the end. There was no way to actually save the .BAS files, so any time I wanted to play one of these games, I had to type it. So I memorized them before I had to turn the book back in.
I then started to combine games together. Like "Guess the Number" and "Hangman" which actually taught me more about programming than anything I learned later in life from education.
For me, as a golang programmer, it's almost the same like you mentioned. Additional mental overhead in golang is that you also need to implement everything in as-flat-dependencies as possible due to the compiler not having support to resolve single methods or recursive dependencies (and -injections).
Usually I find myself rewriting the codebase at least 3 times until I have a modular enough architecture that does not have any unresolvable recursive dependencies. Usually it ends up in a folder structure with a top level structs, utils, actions, cmds, schemas, parsers, protocols etc.
While it also embraces strong knowledge about the architecture, it also is a much higher threshold until you have a program working. Add to this the always occurring defined but not used errors and you can demotivate kids real fast, even though the language syntax and grammar could be very easy to learn (apart from what pointers, slices and reflections or memory allocations and callstacks are).
I think the real GOTO-harmful lesson is that for any non-trivial program, you'll end up implementing conditional blocks, loops, and functions by hand. There just aren't other abstractions on top of a von Veumann architecture, and GOTO arbitrary line rarely does anything other than those three cases, and when it does, it's exceedingly hard to get right. Like sure, true spaghetti code is bad, but it's also really hard to write.
> somehow GOTOs and line numbers would turn you into a bad programmer for life
I think the opposite. It's super simple to understand as a beginner and is a low barrier to entry. The key is likely aligning when to introduce someone to a more structured language with when the are hitting the limits of GOTO - like just have finished writing an awkward large program that could be significantly simpler, spent hours debugging a problem caused by lack of scoped variables, or are trying to modify something they wrote a few months ago that has dozens of GOTOs. These are the things where ideally the light goes on and people "get it".
On the last point, I think that is really what makes people great. Go back and try to work on code you haven't looked at it even thought about in 6+ months. If you've only been coding a couple years, you'll gain a ton of insights into what (not) to do to write maintainable software, in the same way students learn why we don't use GOTO.
I would suggest that Rust's only actual loop, (using the keyword loop) is unambiguous while also being structured. You can (and during development I sometimes do) just write loop until it's apparent what you actually meant and then rewrite - also the Clippy linter will point out various obvious idioms e.g. for or while let loops if they are written as legal but unidiomatic loop constructs. So that aids pedagogy. Your loop works, but the linter explains how an experienced programmer would express the same loop more clearly.
Computed GOTO is often possible in BASICs. In one sense that's awesome, this is a very powerful technique, but in practice it's so unstructured that you shouldn't ever use it so why even offer it?
"That's how the machine works". Yes it is, which is why we don't write raw machine code when we can.
I think it should be used when one needs a fast, deterministic field of branches.
When I used them, I would use boolean in the math to insure the input value was bounded properly.
X = (Y > 5) and Y (for systems setting true to -1 all bits set)
X = Y * (Y > 5) (for systems setting true to just the value 1)
Basically an in-line compare where the actual numeric value result of the comparison is used in a math expression rather than as an input to an if-then construct.
And these two ideas map directly to assembly language, which given the speed of the machines back in the day, made sense. People were going to be using assembly sooner or later.
Doesn't that still use unscoped global variables, though? That, to me, is the thing that causes unmaintainable spaghetti code more than anything else (in any language).
The funny part, and perhaps the part that really damns the critics, is that (IF..GOTO,) GOTOs and line numbers are useful baseline concepts because they have a direct correspondence to what a computer actually does. People who went from BASIC to assembly language did not experience much cognitive dissonance compared to your average JS programmer. And decades later, computers still work roughly this way under the covers complete with (tests,) jumps and memory addresses. :-)
That's an interesting observation that's never occurred to me. As a teen I got a 4k 8-bit home computer in 1981, connected it to the family TV and taught myself BASIC programming from the manuals that came with it and by typing in simple game program listings from hobbyist magazines. As I got the hang of it I started customizing, expanding and combining different games just as you did.
When I got tired of BASIC and wanted to do more, the only option was this thing called assembly language. The three letter mnemonics were kind of cryptic at first but I somehow got the idea of calling up Motorola and some kind sales rep took pity on me and sent me the reference book for the 6809 CPU. The book was too advanced for me but fortunately, it came with folding quick reference card with a simple chart showing the registers, a listing of all the mnemonics and a sentence or two about each one. That card was my constant companion as I taught myself assembler by writing simple programs that would put graphics on the screen.
Just as you said, I never really had any conceptual problem with ideas like holding a numeric value in a register, an index pointer storing the address of a string or array in memory or conditionally branching. All of these had fairly direct analogs in BASIC like LET, IF, GOTO, GOSUB, ARRAY, PEEK and POKE. Even primordial 8-bit ROM based BASIC wasn't that awful. The biggest challenges were the lack of editing tools, being locked into line numbers and the cryptic two-letter error codes. I think a modern BASIC dialect with full-screen editing (no line numbers), named function calling with parameter passing and a decent debugger would still provide a reasonable introduction to computer programming.
This was enough to launch me on a successful lifelong career in high tech as a programmer, product manager, entrepreneur and eventually senior executive. Every bit of it self-taught with no formal computer education at all.
I would add the computed goto, as in something like:
GOSUB (X * 100)
Is really fast, and using switch, or case, or a set of if, then, else statements can work, but not work well.
There are times when a numeric value works for branching, and having this in BASIC maps directly to assembly language where that sort of thing gets done all the time.
That's not something the Locomotive BASIC of Amstrad or the C64 basic support, seems like at least these two require a literal line number (probably also because how else would `RENUM` work?)
To emulate that feature in a development tool for the Parallax Propeller (FlexSpin), a sequence of labels was used.
on X goto a, b, c, d, e, 10000, Fred
While not quite the same, the core need is addressed and compiles to a fast jump table.
Interestingly, that tool allows one to build programs in SPIN, assembly, C and BASIC. The developer can mix and match at will and it all compiles into an executable image.
The Propeller Chip, especially Propler 2, is a literal, embedded playground. Lots of fun.
Definitely not just a language for kids - When I worked for the Navy in the early 90s, they were still using software written in Rocky Mountain BASIC on all the submarines in the fleet.
Rocky Mountain basic had exceptionally nice string handing, array handling and could do matrix math.
I think traditional CS hates BASIC because it's hard to get people to look at it in terms of pure math. And it enables muggles to create useful programs.
DECSYSTEM 20 BASIC User's Guide: LISTREVERSE command
LISTREVERSE
LISTNHREVERSE
LISTREVERSE and LISTNHREVERSE print the contents of the
user's memory area in order of descending line numbers.
LISTREVERSE precedes the output with a heading,
LISTNHREVERSE eliminates the heading.
LISTREVERSE
EQUIV 10:53 13-NOV-75
40 END
35 PRINT "THE EQUIVALENT CURRENT IS",I, " AMPERES"
25 I=E1/R
10 INPUT R
5 INPUT E1
READY
It's not a falsehood. It allows for a lot of bad stuff. Like the following
function Thing1()
begin
do important things
if condition
goto thisIsBad
end if
do more important things
end
function Thing2()
begin
do different things
label: thisIsBad
perform actions
end
And people would do the equivalent of that. You'd run across uninitialized variables, variables accessed outside of scope. Yes, there are disciplined ways to use GOTOs. And most control flow can be implemented with conditionals and jumps, but most people are not disciplined.
Abstracting from programming languages alone, this is the reason why good software design makes doing the wrong thing either impossible, or at least very hard, while making the right use very easy.
I am still learning to do that better. Sometimes I am able to foresee the misuse of a feature and make it impossible, but not always - and it's harder to correct the error once it proliferates.
However, the article puts the quote (though it had nothing to do with GOTO) in context - and at the time no dialect of BASIC that was used by millions of users had support for functions (other than mathematical expressions declared with DEF FN), or procedures - so you couldn't jump out of scope... because there was only one scope.
I agree, and frankly having gone from BASIC to 6502 assembly language, GOTO made perfect sense.
What I like most, and still enjoy today when possible, is how open the hardware is!
For someone wanting to know how computers work, it is damn tough to beat what many of us got as kids; namely, a respectable computer, schematics to understand the hardware, and BASIC right there, ready to go.
My first disassembler was written in BASIC. So was my assembler, and it was a line oriented one modeled closely after the one built into the Apple 8 bit computers.
And look at the BBC Micro! That BASIC was great and offered in-line assembly code! Excellent!
These days, I find microcontroller can offer something similar.
If I ever find time, the Parallax Propeller 2 could make a fantastic computer. It can run cores concurrently, or parallel, or even doing different things entirely. Jim Bagley and friends setup a NAMCO emulator and found they could host 8 simultaneous sessions of Space Invaders, complete with player controls and displays!
Put a BASIC on that, and a reasonable macro assembler and the result would be a killer learning system able to drive lots of hardware and use any display one can find from old TV's to HDMI panels and everything in-between.
I took the liberty of quoting the first sentence of your comment as the first sentence of the article intro.
I couldn't agree more with you :)
It's all about picking the right tool for the job, and the language itself, as it evolved, picked the concepts it could use from everything else - like other languages do as well.
I hope I didn't convey a message of BASIC being for kids - it just happens that many people that start their adventure with programming (especially in the 80s and 90s, but often also today) look for a simple language to learn the core concepts of how a computer operates internally. It's also a little like with Python - you can create a complex and deeply structured application with it, but it's also a language great for simple scripts that will look much more like the BASIC programs - glueing together a bunch of statements to get to the result ASAP. And this is extremely useful.
It seems like the same characteristics that made BASIC so good to start coding are also the ones that get the most criticism, which is a fascinating paradox.
266 comments
[ 2.7 ms ] story [ 355 ms ] threadIt's not horrible at all if a child can learn to make a game in it from scratch.
However, qbasic doesn't have the line numbers (edit: at least not mandatory!). Never used a basic variant that requires the line numbers, but that seems like a total kludge!
Is TypeScript in 2023 the same language as JavaScript in 1996? The various BASICs were even more different than that. It’s impossible to say that they were all categorically horrible or perfect. But they did enable millions of people to discover computing, on everything from ZX-81 to Windows 95.
basic had the advantage of being implementable in 4 kilobytes of ram and being memory-safe
you are forgetting peek and poke.
We're lucky if it crashes.
Basic has proper strings, proper arrays, with bounds checking, and automatic memory management.
Those used to be fighting words around here!
My very first computer was a Commodore Vic20, whose User's Manual was essentially a BASIC manual. One of the very first programs I learned to wrote drew a simple bird on the screen made by characters and made its wings flap. I was mesmerised.
Boy, how much I enjoyed that manual!
Edit: bids -> bird
https://archive.org/details/commodore-vic-20-manual-del-usua...
https://archive.org/details/VIC-20ProgrammersReferenceGuide1...
Also, when I was implementing FOR, my first naive implementation was compiling the body first, then append the loop related things that check the conditional and jump backwards to the start of the body. "Hang on, what about the case when the condition is initially false?" I thought, only to discover that the BASIC standard actually specifies that a FOR loop runs at least once, even if the condition is false! Officially, the language is advertised as for beginners, but to me it looks like it was meant as a lingua franca of computers, as in not only easy to understand, but also easy to implement.
Here's a BASIC compiler for the HP 15-C calculator written in Idris: https://gitlab.com/michaelzinn/voyc/-/blob/master/src/Compil...
Original Dartmouth BASIC had only 14 statement types, and it takes very little efforts to enumerate and implement all of them, even if you are just starting on a compiler journey and making things up suboptimally along the way.
The bonus upside for choosing BASIC as your first compiler project is that you get decades of vintage test programs to play with like this one [2].
[1] https://github.com/yiransheng/basic_rs/blob/ddd64e2eacfc2b36...
[2] Game of Life compiled to warm: http://subdued-afternoon.surge.sh/
The capabilities and the limits captured your imagination in a way that the modern stack doesn't come close to.
And especially in the UK, easy and cheap access to 8-bit machines for teenagers launched a generation of coding careers.
So Dijsktra is wrong. It's very possible to learn CS principles after learning BASIC. it's certainly an adjustment, but it's very easy to sell if you explain that you can build larger structured projects from smaller elements, including more complex data structures - not a difficult concept for anyone who taught themselves assembler from magazine articles and books, because there was no other help or support.
The other thing BASIC did was gave some of those teens a career. The cost of entry to a small game business was very low, and there were plenty of games that didn't even need assembler.
A bit of advertising in the magazines, maybe some hand duplication to start with, and good games made non-trivial money almost immediately, through organic word of mouth promotion.
In no time, we were exposed to FFI (calling machine code routines) and internals (like BASIC program/token storage to make a line renumbering utility), and all the hardware interface memory locations. Learning how software copy-protection worked and defeating it was a great reverse-engineering/debugging passtime.
We were always reading about new tricks and sharing with each other who had the same machines. Getting a copy of the "De Re Atari" document was the holy grail where we felt like we had access to know everything, and we mostly did. I even tried as a kid to make a multitasking 'game' which failed because I didn't know enough about interrupt handlers, but I was close--it worked, briefly.
De Re Atari survived all those rounds, even the ones where the Atari computers themselves did not. It did feel religious in a way.
Until the Mac put the kibosh on that. You were firmly on the outside of the box, and to get in you had to buy either a box of floppies from Apple (MDW, was it?) or something like Lightning C which was just a couple of disks if memory serves.
Later there was the Hypercard thing, a scripting tool from Apple which did get some traction, but was never very popular.
Similarly using a web browser and View Source for HTML/CSS+JS was a modern equivalent before we had all the single-page-apps/frameworks that make it incomprehensible. And again the 'machine' is an abstracted web client.
The Commander X16 project[0] aims to recreate that environment for modern times (and also available for purchase). It's effectively what a C64 might be today, with more (but still limited) memory and easy to program graphics and sound. Something like a Raspberry Pi 400 looks the part but would end up running something like Linux and OpenGL ES2.0 which isn't much different than a regular desktop.
I can't find the original video where I saw the project getting started, but here's a review[1] that runs through what it is.
[0] https://www.commanderx16.com/
[1] https://www.youtube.com/watch?v=bFIk8WV-RYQ
There's even a full emulator[0] available so you can hack with friends who don't have one, or share your creations to run in the emulator.
[0] https://github.com/x16community/x16-emulator
The fact that the home computers used to be READY to be programmed within a second from powering up, and gave you such an easy access to all basic operations was what was so ... addictive?
It was one of the most important, if not _the_ most important, source of computing knowledge in my early childhood. I was born in 1984, got my first computer – a C64C – in 1991, and my dad procured a heap of past issues of „Bajtek” from previous years. In rural Poland those days, knowledge was hard to come by, so those proved invaluable to me.
Not only were there type-in programs and games, like in the German 64er, but most of them were actually accompanied by prose articles that offered clear explanations, background, and trivia. I learned BASIC from Bajtek and a few books. Bajtek literally had a monthly column called „For Preschoolers Only” with a BASIC tutorial in it.
BTW. Retronics is re-issuing Bajtek now! They print the same old issues but re-typeset for the highest quality. A true gem.
Back in the 80’s you fired up your computer and you had a readily-available interpreter for which you could immediately do ‘real’ stuff like printing characters anywhere on the screen and turning on and off pixels (even in colour on some platforms).
There was no need to compile or build a project or start with a lot of boilerplate. You just did stuff right away from a REPL or could make programs from line numbers and save them.
I learned a ton from it. Eg how to think algorithmically and break up something complicated into small parts. A key milestone was grokking the difference between GOTO and GOSUB. I also understood much about its limitations once I started learning Turbo Pascal in high school.
If you’re judging BASIC compared to a modern IDE with a modern structured language of course it falls short, but for what it was at the time it was nearly perfect.
The language is primitive by today's standards but it gives you all sort of ways to express yourself. When BASIC progressed and was more structured, for example AmigaBASIC from Microsoft [2], there were more alternatives and more evolution so it is natural that BASIC faded.
Also important to highlight that every popular computer magazine (media) published BASIC code, also books.
[1] https://en.wikipedia.org/wiki/ZX81
[2] https://en.wikipedia.org/wiki/AmigaBASIC
[3] https://en.wikipedia.org/wiki/TI-99/4A
But there is one thing I'm very grateful for, in retrospect. Both languages required very few "concepts". Functions? Pointers? Classes? These are basics for coders, but BASIC didn't ask even this of you.
With a small syntactic baseline you could make full on games pretty easily. Compare this to making games even with Python using PyGame, or Godot, or whathaveyou.
Of course, nothing prevents you from learning Python and just limiting yourself to a few data types and control structures. But what really made BASICs easy (for me) was that "draw to the screen" was such a primitive operation. Same with detecting keypresses.
Again, these are easy if you're a software engineer, or even if you know how to code. But what if you don't?
Even Visual Basic had this virtue. When I was in Mexico I volunteered at a homeless shelter. The man who operated the shelter had no coding education, but was able to self teach Visual Basic two decades ago, and had created an entire system for managing the facility.
He had tried to rewrite it to use a more modern language (I believe C# or VB.Net) and was totally unable.
I've never used VB but I've heard countless tales like this, where non-coders create entire functioning software in it.
Lost count of non-coders that outgrown their Excel macros that I got to know, that dive into VBA, eventually ask IT for VS and VB.NET.
https://gambas.sourceforge.net/en/main.html
Or Lazarus, for the Delphi variant,
https://www.lazarus-ide.org/
People hate changes, even the slightest UI color changes are booed down. I can imagine redoing Lazarus to look like IntelliJ IDEA would be a lot of work that would be frowned upon (though I love IDEA... but I myself find it not tempting at all to switch to their "new UI" which copies VS Code and hides away my most frequently used features behind submenus and pictures, like I can't read ;-) (old man yelling at clouds)).
Workspaces as a way to have the concept of Smalltalk images, while being based in files.
To this day it supports code navigation like in Smalltalk.
Ironically, VSCode was also created by one of Visual Age and Eclipse architects, Erich Gamma.
My advice to developers that are interested in Xojo, or looking for something different in terms of languages / development platforms, is to give Xojo a try. You can build and run apps in debug mode for as long as you'd like, all at no charge. It's only when you want to compile apps so that you can run them as executables and/or for distribution that you'll need to purchase a license.
Too much business depends on some VBA macro that Shirley in Accounting or Jim in Shipping wrote 20 years ago.
After BASIC (which was obviously also my first, if I didn't mention it in the article already :D), I switched to a PC and used Borland Delphi for my first programming adventures. Fully object oriented language, with all the structural help you may want. And yet, my code was often repetitive, procedural, or just doing silly things (and variable names mixed English and Polish even within a single name).
But it was a phase. I think a beginner programmer focuses on the goal and struggles with their way to reach it enough not to bother about the best, or most beautiful, or idiomatic way to achieve the goal. However, after a few years you build the awareness that if you're going to revisit this code in the future, you want it easy to read as well, and you may want to hide certain functionalities and operations behind functions, procedures, objects. The more time you spend programming, the more you appreciate structuring your code, then your application, then your entire architecture in a way that wouldn't hurt you in the future... or minimize the hurt.
It's also a matter of the right tool for the job - an advanced programmer, writing a one-off script to quickly get or transform a result, may also decide not to decorate it with a sophisticated system of classes :-) I'd just write a bash or python script.
First year at college, took intro to programming in Pascal, and oh what breath of fresh air that was. Sure it was cumbersome, had a lot of ceremony, but it had procedures and functions that you could pass parameters to! And structures! Things that had been a hassle in BASIC suddenly had legible descriptions.
But yes, BASIC did one thing very well: it got out of your way and let you cut your teeth on the fundamental concept - that a machine can follow a sequence of simple instructions to produce complex behavior. It provided a sense of that dynamic, that I think would have been a little less obvious with an edit/compile/test environment with as much ceremony as Pascal etc.
https://developer.mozilla.org/en-US/docs/Games/Tutorials/2D_...
It’s not quite there, but getting to a context similar to a qbasic graphics mode is only 10-20 lines of boilerplate.
Now I consider JavaScript as more of a modern BASIC because of its ubiquity - it is included in basically anything that has a web browser
(Like BASIC, JavaScript also has its own set of idiosyncracies, many of which derive from its environment.)
I never stoped to wonder why and just accepted this as reality, but the mere existence of this distinction helped me understand software from an engineering point of view quite early.
It was a bridge to Functional programming, CQRS, Bertrand Meyer’s teachings, 10 years before I could even have a chance of hearing about it.
Xojo also compiles to Web Apps. But to compile to all those targets means creating a - Project for Desktop ( Mac/Win/Lin/Rasp ) - Project for iOS - Project for Android - Project for Web
So, four different Projects instead of one Project. You can create externals to share code between projects.
I used Xojo shortly after it became available under the name "REALbasic" back when you could only compile to Desktop. Web, iOS, Android were later added.
I spent a ton of time on Web 1.0, but Xojo replaced it with Web 2.0 with no upgrade path, practically requiring a rewrite.
So I now code my Web Apps with PHP. While I really wanted to keep using Xojo, the lack of quality just got worse and worse. The only bugs I encounter now are my own. If Xojo was as tight as PHP, I'd still be using Xojo!
Guess we need to hope for Mojo's success.
https://github.com/richpl/PyBasic
Maybe early BASICs were so-so, but QBasic already had all kind if procedural stuff.
I'm tired of this "good programming", there is people that talks about good programming and than produced programs that are either too complex to do something useful. These to me are bad programs!
There were a ton of companies or persons that used (and still use) BASIC (or Visual Basic) programs to do stuff, and maybe if it wasn't for BASIC these programs would probably never be written.
Same thing we can say about COBOL, a ton of companies are run by an IBM AS/400 running old COBOL programs written in the 80s that still work fine.
I agree with your point on companies running on VBA and how much worse the world would be without. But I still blame microsoft for making a language stuck in the 90s the only option for those users to integrate simple coding into their workflows. They are forcing users onto a bad path (and I am not complaining about the Basic syntax itself, but about the lack of the 25y of evolution and improvements you would find in VB.net).
It's not that is rocket science, like it is not BASIC. The most difficult thing is getting a development environment set up, but a company that maintains such programs can use virtual machines and test systems. There are even companies that provide you "cloud" IBM AS/400.
Anyway, what I meant is that normal companies are not Google, you find a small department of developers (in case of small companies, only one) that does everyting, from fixing the printers to developing the programs that are useful to automate and do the job the company needs to do. I've seen companies build even systems that manage an entire production plant in house with a complex business logic, something that not even commercial software that cost thousands of dollars do!
With no budget, and thanks to simple programming languages (in the past was BASIC, today I say that it's python) companies write programs that helps them speed up the work, that may be an ugly file of 10.000 lines of code with few comments, copied/pasted blocks, classes with poor or no encapsulation, but that work.
Saying that they are bad programs because they don't follow SOLID pricniples, or they don't do TDD or have a CI set up, or they are on a folder in file server instead of a git repository, to me is stupid. A bad program to me is a program that doesn't work, a program that has bugs, a program that doesn't solve the problem it was designed to solve.
The reason Basic wasn't horrible but amazing at the time as the home computers appeared is hard to understand without the context of that time:
Basic on these computers was, in today's language:
- an actual "complete" operating system and
- a command language and
- a script language and
- a programming language
Additionally, if one wanted to use the "full power" of the CPU one had to use machine code, as there was so little RAM that most of the programs that did fascinating stuff were true masterpieces. Those using Basic knew that it's not "all there is".
It was line oriented so you didn't need an editor. It was simple and had a very short learning curve.
You were never going to write a huge program, so modules or packages weren't a necessity.
It just fit this niche perfectly.
It was often used for renumbering a few lines to make room for more as there was no built-in renumber utility.
These days if you want to run a program to crunch some numbers, the program is one file, and the data another - but back then, since you fed the whole 'job' into the card reader at once, you could change the data set by just swapping out the cards.
Not saying that this was in any way better. Just that the idea of it feels so alien - and this was the era in which BASIC first evolved.
Also, I suppose "era in which BASIC first evolved" would have better been stated as "part of the era in which BASIC first flourished"
Idk what Dijkstra means. My whole generation started with BASIC and learned languages as they’ve become useful enough for every new wave of accessible hardware, which wasn’t cheap for a hobby. There was no like “oh, now you’re lost”. My next language was 8080 assembly then Pascal then 8086 then C. You just can’t learn Pascal and C on a Sinclair clone when loading a compiler from a tape recorder takes half an hour and most of the available memory. And you can’t learn Python either, because it doesn’t really exist yet. I know it’s from 1991, but never heard of it until ten+ years later.
I also know that some ROMs had FORTRAN instead. Maybe Dijkstra would like to re-teach FORTRAN programmers more.
I thought the article did a pretty good job about describing what Dijkstra meant, and pointing out it was written years before you learned a BASIC variant on a microcomputer.
What are you still unsure about?
> Maybe Dijkstra would like to re-teach FORTRAN programmers more.
Unlikely. The article points out Dijkstra called FORTRAN "hopelessly inadequate".
For examples of fancy BASIC graphic programs, search for:
https://www.youtube.com/results?search_query=cursor+tape+mag...
Cursor magazine programs did occasionally have an assembly language subroutine; at least one flashed the screen using one. But most of them were just BASIC.
Purists may scoff, but kids with zero experience could make animated graphics after just a day or two of playing around, and curiosity about how more sophisticated programs worked (in my case: The "Miser" text adventure game) would soon motivate to find out more. Is that bad? It was the whole point of the language, the B stands for "Beginner". Plenty of time to graduate to other things later (in my case: Assembly language -> Pascal -> C).
[1]: https://en.m.wikipedia.org/wiki/Logo_(programming_language)
What was very different about BASIC compared to today was that it was "Beginners' All-purpose Symbolic Instruction Code" (that's what BASIC stands for). At the same time it used to be used by adults to solve real world problems.
If you outgrew BASIC you could easily segue into Pascal which was much more powerful but still designed with education in mind.
I think today the gap between what is used to teach and what is used to solve problems is much bigger. Once children get older the motivation for toy languages understandably goes away but learning a modern programming language that is actually used in the industry is a big step that is not easy to overcome.
I have no perfect solution for that but for us and for now we settled for Godot and GD Script. It is simple enough to get started and I think when I showed my daughter the Tesla App [1] it was a big motivation.
[1] I've heard the current version it is not made in Godot anymore, but it was when we started on this journey a while ago.
For parents that have some 8bit experience, Pico-8 (LUA) is also relatively popular. It's basically like running an Apple 2, Atari 800, Commodore 64 as if it booted into LUA instead of Basic. You can trivially draw things, and peak and poke bytes into "Screen memory" if you want to feel like you're "touching the hardware"
JavaScript is also available everywhere a kid might be and it's easy to draw stuff with literally millions of examples all over the net. Processing.JS is also a thing https://thecodingtrain.com/
Weekends I spent at the beach, though.
I see from Wikipedia that the system costs were enormous! But that was an exquisite summer romance with BASIC.
Not too many years later I discovered Turbo Pascal. Yeah, off to the races. And then came Turbo C++, and g++ around '92. Haha you kids today would really enjoy debugging templates in early g++. (The idea that you could write the same code for 'float' and 'double' was intoxicatingly cool.)
The transition from Fortran (what I learned to program with) => HP Basic => Pascal => C++ was pretty easy. Pointers, well if you study 'The C Programming Language' carefully, are not difficult. People writing serious computational mathematics codes are constantly using pointers, just not as 'pointers'. Debugging, well that is another problem entirely, and I believe from way out here in the future, that that is the most difficult problem of all. How to program in such a way that the bugs are not silent. Those silent ones were the cause of most of the grief in my programming life.
The thing about HP Basic is none of the bugs were ever silent. Same with Turbo Pascal. I did a lot of really cool things with those 'toy' languages. They never caused me any grief.
So I think Dijkstra didn't understand (maybe) the importance of painless pleasure when (some) mortals are learning programming. It sure turned me on.
But it's not a language just for kids. While most dialects are somewhat limiting, there is nonetheless a TON of real useful stuff you can do with it.
Why oh why doesn't Windows and macOS come with Python and Idle out of the box? Or does Mac, I forget.
It's disappointing that Windows doesn't release with an accessible interpreted language. They ship with a couple of games so why not drop some kind of super integrated and simple programming environment? Most of my generation cut their teeth on Microsoft Basic after all.
Buuut...the common Basic computers of the time had commands that let you do built-in graphics in a very simple manner. Not anything as crazy complex as the .NET charting and GUI stuff available to Powershell now. It's a real shame there isn't a built-in DSL that could allow normal users (i.e. not full time developers) to build some really simple games in like half a page of code.
I don’t remember Commodore Basic for the VIC-20 and Commodore 64 doing graphics other than through a series of POKEs.
Tangential: Artist Raquel Meyers does really great stuff with the CBM graphics character set, see https://www.raquelmeyers.com/
I think the C64 alone was responsible for a lot of the bad press BASIC got in the 1980s-1990s, from former Commodore owners who knew that one, terrible BASIC and concluded from a sample size of 1 that BASIC was bad.
Most other BASICs were better. Some on machines of the same era were much better. The BBC Micro had the same CPU and had BBC BASIC, the fastest interpreted BASIC ever written, with types, structured code, named procedures with local variables, inline assembler, rich graphics and sound support and more... in 32 kB of ROM (half for the modular extensible OS, the other half for the BASIC).
Tramiel cheaped out: the machine had 20 kB of ROM, with an OS half the size and a BASIC half the size (plus a fancy character set).
I expanded on this a few years ago, here: https://liam-on-linux.livejournal.com/71381.html
https://www.wikihow.com/Make-a-Video-Game-With-Cmd
https://youtube.com/watch?v=tYgUxz6Rd_o
A somewhat better choice is VBScript, which also ships with Windows and can be run with cscript/wscript.
What’s indeed missing is a built-in IDE. At least MS Office comes with a VBA IDE.
It's great as an introductory language IMO. I disagree with Dijkstra that it will do any permanent damage -- if anything it will help the programmer appreciate the advantages of structured or object-oriented code when they are ready for it.
It used to ship with qbasic and a nice editor held over from dos. That was pretty good, though it was essentially hidden. It was there, but there was no icon for it and no docs or directions said to use it, let alone boot right to it as your primary interface.
Basically the driving force behind the production of Windows is the parts of MS that make money from it, not the developers who would write stuff for other developers if they could.
They want users that consume, not produce, and they absolutely do not want users who tinker and poke and modify.
They offer development systems only because they still have to, and they make even those into managed inscrutable products you merely use like powerpoint as much as possible.
Dijkstra's quote about people who learned programming with BASIC being beyond repair is obviously hyperbole, but given the number of programmers he taught, I'd assume he was seeing some significant difference that was important enough to prompt his statement.
[1] https://jasomill.at/IEFBR14.png
Because they have something better: a web browser with a javascript console.
i had nightmares about avoiding GOTOs in my teens...
Dijkstra will go down in history as one of the great algorithm designers, but this will always be a black mark on his legacy, possibly overshading his contributions. There's a lesson here about not pontificating outside of your field.
Using a language that supported structured programming would get rid of such scaffolding code that hid the logic of the actual program.
Many languages also allowed code to jump out of and into loops, and programmers (ab)used that to cram their code into the small amounts of memory they had at their disposal. The resulting code could be quite hard to understand.
> There's a lesson here about not pontificating outside of your field.
How was that outside of his field, which was about thinking logically about programming?
> How was that outside of his field, which was about thinking logically about programming?
Language design falls under human-machine interfaces, and while basically everyone in that era dabbled in that field, it wasn't really his forte.
I am begging of you, please do a little bit of investigation into the historical context in which Dijkstra wrote that memo.
By and large the ancients couldn't have been all that concerned about optimizations. Take a look at their "Example 6" in which the authors were able to significantly improve an inner loop thru such advanced techniques as "use 0.0 instead of 0 if you want a REAL" and "don't make extra assignments".
The paper that I linked?
> In that case, why not buy a smaller machine?
Because they needed to support an entire department or university worth of users, many of them at the same time.
> It sounds completely fantastical/fabricated to me.
Have you ever done serious work on a time-shared system? The kind where you type `w` and see a bunch of people who aren't you?
Nowadays everybody gets their own workstation and can use as much or as little of it as they see fit, but on a shared system trying to use the whole thing is a great way to get people mad at you, because you're taking away resources they need for their own work.
Not that you'd necessarily be allowed to use all that much in the first place, that's why things like `ulimit` exist.
Yup! As soon as I was exposed to a language withOUT line numbers and GOTOs, a little light went on, and stayed on.
Got a link we can use to get some insight maybe?
BASIC does not have notion of a continuation as a value.
Arguably the main point of continuation-passing style is that you pass a continuation along with the jump. Hence the name.
In fact GOTOs in BASIC were, I think, a big part of lowering the barrier to programming for the new and the young. It relieves the mental load of structuring the program, allowing you to concentrate on the logic and syntax. Not using GOTOs requires already having a mental picture of what the program should look like before you write it, or at least rewriting it multiple times as you go.
As a Rust programmer, I probably spent 5-10% of my time restructuring branches to deal with Results and Options more elegantly, and it is the least fun part. While not related to program flow, it's an example of a Good Thing that makes coding less fun.
I did some real fun stuff in BASIC as a kid that I never replicated in later languages. In kindergarten or first grade, I picked up a book called something like "Make Your Own Computer Games" at my local library. Everything was GOTOs and LABELS. The librarian didn't want to let me check it out because it was beyond my understanding, but my grandma insisted. That night and for the following 2 days, on my Dad's work computer, I would type and retype these computer games into GWBASIC in MSDOS, and then type run at the end. There was no way to actually save the .BAS files, so any time I wanted to play one of these games, I had to type it. So I memorized them before I had to turn the book back in.
I then started to combine games together. Like "Guess the Number" and "Hangman" which actually taught me more about programming than anything I learned later in life from education.
Usually I find myself rewriting the codebase at least 3 times until I have a modular enough architecture that does not have any unresolvable recursive dependencies. Usually it ends up in a folder structure with a top level structs, utils, actions, cmds, schemas, parsers, protocols etc.
While it also embraces strong knowledge about the architecture, it also is a much higher threshold until you have a program working. Add to this the always occurring defined but not used errors and you can demotivate kids real fast, even though the language syntax and grammar could be very easy to learn (apart from what pointers, slices and reflections or memory allocations and callstacks are).
And yet no one said this about programming assembly.
The whole GOTO-harmful is a product of a bygone time much as anyone needing to keep track of a jump table by hand is now.
I think the opposite. It's super simple to understand as a beginner and is a low barrier to entry. The key is likely aligning when to introduce someone to a more structured language with when the are hitting the limits of GOTO - like just have finished writing an awkward large program that could be significantly simpler, spent hours debugging a problem caused by lack of scoped variables, or are trying to modify something they wrote a few months ago that has dozens of GOTOs. These are the things where ideally the light goes on and people "get it".
On the last point, I think that is really what makes people great. Go back and try to work on code you haven't looked at it even thought about in 6+ months. If you've only been coding a couple years, you'll gain a ton of insights into what (not) to do to write maintainable software, in the same way students learn why we don't use GOTO.
GOTO is super unambiguous and probably a better introduction to program control flow while they get used to manipulating and juggling variables around
Computed GOTO is often possible in BASICs. In one sense that's awesome, this is a very powerful technique, but in practice it's so unstructured that you shouldn't ever use it so why even offer it?
"That's how the machine works". Yes it is, which is why we don't write raw machine code when we can.
When I used them, I would use boolean in the math to insure the input value was bounded properly.
X = (Y > 5) and Y (for systems setting true to -1 all bits set)
X = Y * (Y > 5) (for systems setting true to just the value 1)
Basically an in-line compare where the actual numeric value result of the comparison is used in a math expression rather than as an input to an if-then construct.
And these two ideas map directly to assembly language, which given the speed of the machines back in the day, made sense. People were going to be using assembly sooner or later.
When I got tired of BASIC and wanted to do more, the only option was this thing called assembly language. The three letter mnemonics were kind of cryptic at first but I somehow got the idea of calling up Motorola and some kind sales rep took pity on me and sent me the reference book for the 6809 CPU. The book was too advanced for me but fortunately, it came with folding quick reference card with a simple chart showing the registers, a listing of all the mnemonics and a sentence or two about each one. That card was my constant companion as I taught myself assembler by writing simple programs that would put graphics on the screen.
Just as you said, I never really had any conceptual problem with ideas like holding a numeric value in a register, an index pointer storing the address of a string or array in memory or conditionally branching. All of these had fairly direct analogs in BASIC like LET, IF, GOTO, GOSUB, ARRAY, PEEK and POKE. Even primordial 8-bit ROM based BASIC wasn't that awful. The biggest challenges were the lack of editing tools, being locked into line numbers and the cryptic two-letter error codes. I think a modern BASIC dialect with full-screen editing (no line numbers), named function calling with parameter passing and a decent debugger would still provide a reasonable introduction to computer programming.
This was enough to launch me on a successful lifelong career in high tech as a programmer, product manager, entrepreneur and eventually senior executive. Every bit of it self-taught with no formal computer education at all.
I actually went to a field office where one of their engineers sat with me for a while! Very cool.
Started on 6502, friend got Color Computer, and I loved 6809. Beautiful chip.
I would add the computed goto, as in something like:
GOSUB (X * 100)
Is really fast, and using switch, or case, or a set of if, then, else statements can work, but not work well.
There are times when a numeric value works for branching, and having this in BASIC maps directly to assembly language where that sort of thing gets done all the time.
on X goto a, b, c, d, e, 10000, Fred
While not quite the same, the core need is addressed and compiles to a fast jump table.
Interestingly, that tool allows one to build programs in SPIN, assembly, C and BASIC. The developer can mix and match at will and it all compiles into an executable image.
The Propeller Chip, especially Propler 2, is a literal, embedded playground. Lots of fun.
http://hpmuseum.net/display_item.php?hw=367
I think traditional CS hates BASIC because it's hard to get people to look at it in terms of pure math. And it enables muggles to create useful programs.
Seeing deeply nested excel IFs that parsed out individual letters of a string for recursive cell logic still gives me nightmares.
Yes, it actually did exactly what it sounds like!
Chalk one up for DEC and BASIC. What other programming languages support that feature, huh?
Now all you need is a COMEFROM and COMESUB and RUNREVERSE (or NUR) statements, and you can write reversible BASIC programs!
https://en.wikipedia.org/wiki/Reversible_computing
https://en.wikipedia.org/wiki/Counter-Clock_World
https://web.archive.org/web/20210713130832/https://imgur.com...
http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-1...http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-2...
Abstracting from programming languages alone, this is the reason why good software design makes doing the wrong thing either impossible, or at least very hard, while making the right use very easy.
I am still learning to do that better. Sometimes I am able to foresee the misuse of a feature and make it impossible, but not always - and it's harder to correct the error once it proliferates.
However, the article puts the quote (though it had nothing to do with GOTO) in context - and at the time no dialect of BASIC that was used by millions of users had support for functions (other than mathematical expressions declared with DEF FN), or procedures - so you couldn't jump out of scope... because there was only one scope.
What I like most, and still enjoy today when possible, is how open the hardware is!
For someone wanting to know how computers work, it is damn tough to beat what many of us got as kids; namely, a respectable computer, schematics to understand the hardware, and BASIC right there, ready to go.
My first disassembler was written in BASIC. So was my assembler, and it was a line oriented one modeled closely after the one built into the Apple 8 bit computers.
And look at the BBC Micro! That BASIC was great and offered in-line assembly code! Excellent!
These days, I find microcontroller can offer something similar.
If I ever find time, the Parallax Propeller 2 could make a fantastic computer. It can run cores concurrently, or parallel, or even doing different things entirely. Jim Bagley and friends setup a NAMCO emulator and found they could host 8 simultaneous sessions of Space Invaders, complete with player controls and displays!
Put a BASIC on that, and a reasonable macro assembler and the result would be a killer learning system able to drive lots of hardware and use any display one can find from old TV's to HDMI panels and everything in-between.
I couldn't agree more with you :)
It's all about picking the right tool for the job, and the language itself, as it evolved, picked the concepts it could use from everything else - like other languages do as well.
I hope I didn't convey a message of BASIC being for kids - it just happens that many people that start their adventure with programming (especially in the 80s and 90s, but often also today) look for a simple language to learn the core concepts of how a computer operates internally. It's also a little like with Python - you can create a complex and deeply structured application with it, but it's also a language great for simple scripts that will look much more like the BASIC programs - glueing together a bunch of statements to get to the result ASAP. And this is extremely useful.
It seems like the same characteristics that made BASIC so good to start coding are also the ones that get the most criticism, which is a fascinating paradox.