Was BASIC that horrible or better?
retrofun.pl
retrofun.pl
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,
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!
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.
10 PRINT "HELLO"
20 GOTO 10
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.
$ 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.
$
$ /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.
>>>
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.
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...
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
http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-2...
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
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.
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.
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.
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.
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?
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.
C AREA OF A TRIANGLE - HERON'S FORMULA
C INPUT - CARD READER UNIT 5, INTEGER INPUT, ONE BLANK CARD FOR END-OF-DATA
C OUTPUT - LINE PRINTER UNIT 6, REAL OUTPUT
C INPUT ERROR DISPAY ERROR MESSAGE ON OUTPUT
501 FORMAT(3I5)
601 FORMAT(4H A= ,I5,5H B= ,I5,5H C= ,I5,8H AREA= ,F10.2,
$13H SQUARE UNITS)
602 FORMAT(10HNORMAL END)
603 FORMAT(23HINPUT ERROR, ZERO VALUE)
INTEGER A,B,C
10 READ(5,501) A,B,C
IF(A.EQ.0 .AND. B.EQ.0 .AND. C.EQ.0) GO TO 50
IF(A.EQ.0 .OR. B.EQ.0 .OR. C.EQ.0) GO TO 90
S = (A + B + C) / 2.0
AREA = SQRT( S * (S - A) * (S - B) * (S - C) )
WRITE(6,601) A,B,C,AREA
GO TO 10
50 WRITE(6,602)
STOP
90 WRITE(6,603)
STOP
ENDYeah. I knew Fortran (at a high school level). Then I came across the TRS80 Basic manual. I read it in an hour, and I thought "this is just like Fortran, except the words are different".
I see programs written in later dialects of Fortran and they look totally fine. But my understanding is that Fortran in the "real world" is a far messier affair.
It's 1976, so a little newer. Did I follow a bait to a spec that wasn't about to catch on until another few years?
I checked again. It seems indeed like Fortran 70 was a spec that wasn't in use until fortran 77 in 1978.
Thanks again @vajrabum, I've update the article with your example!
Exactly. The primary variations in that program from an equivalent BASIC program are the more cryptic output commands (FORMAT/WRITE vs. PRINT) and the comments (C vs. REM).
(Note that PRINT did originally mean "print on paper" using a teletype-style printing terminal.)
I recall reading that Tom Kurtz (BASIC's co-creator) would travel by train to some other campus to batch-process his FORTRAN punched card decks - and many programs failed because of simple errors.
A personal background: writing this article was fun! I started with BASIC too, I was about 6, and the Amstrad CPC6128 my dad had was 8 already. You can tell by how I treat Locomotive BASIC like a reference implementation of the 80s. I knew Pascal only from a label on diskette 5 (but someone replaced it with invoices), listings from 80s Bajtek magazine stash that I mostly got from a friend (he had an Atari 65XE but was switching to a... Pentium III 500Mhz), and the manual for the Amstrad and having A LOT of free time were my source of knowledge. I remember trying to replicate (in BASIC!) the UI of first computerized cash registers from the shops, when I was 12.
I knew Dijkstra made the quote, but never before asked myself: when did he do it? Was it the BASIC I know? What did people use, probably just assembly, right? Wrong!
It's amazing how much old documents, newsletters, and documentation you can find from the 70s, and how many the problems it did not change that much today, even though the computers changed incredibly.
I'll read through the comments here, and for sure won't miss any on the site itself.
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/
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).
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.
Several teachers who taught BASIC/COMAL in the 1970ies and 1980ies have commented to me, that the line numbers made them much easier to teach than for instance PASCAL.
The line numbers enables the teacher to say "Now, look at line 240" which is much more precise and concise than "Look at the statement in the IF inside the WHILE" etc.
Plus it immediately and intuitively exposes the imperative sequential "turing tape" model of the computer to the user. "Do these sets of things, in sequence, now go back to this line, or forward to this, and do the things there" is far less abstract than "execute this function."
But I was thinking more in the context of showing code to a class, during which you're usually not updating it, and even if you do, you just say the new line number as appropriate. It only breaks down if everyone is individually editing the same one piece of code.
Line numbers, for beginners, eliminate the advanced OS concepts of "files" and with them "editors" and "saving" and "loading" and much else.
If you type the code without a number, that means: do this now.
If you type code with a number in front, it means: remember this for later.
And that is all you need to enter, edit and run code.
No "editor" that loads "files" from a "directory" on a "drive" which you must "save" before you "execute" the code in a language.
To try it: type the code; hit Return.
To run the code you entered earlier: type RUN, hit Return.
This is a very powerful abstraction which simplifies a lot for beginners.
That you can further expose this by using those numbers in the code is a great first step into thinking about program structure as more than a consecutive list of steps. It leads naturally into loops and things.
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".
I gave the deck of cards to a friend and a couple of days later I got the fan-fold paper output that listed a bunch of syntax errors and nothing else. I just didn't understand programming very well.
BASIC is what got me on track. I found a book in my local public library on the relatively new language BASIC. It was easy to understand and I practiced writing out the solutions to simple problems with paper and pencil. I didn't have access to a BASIC system, but I learned enough that I could try FORTRAN again (this time on simpler problems). After a few attempts (with the two day turnaround) I was successful and programming became a hobby that eventually led to a career as a real computer scientist.
BASIC was just right. It was concrete enough for a novice to understand while being much more expressive than assembly language. I've never actually run any program that I wrote in BASIC, but I have written programs in scores of languages since and BASIC got me started.
Today, there are better choices for a first language: Python provides students with a lot of power right away, and my daughter learned Scheme as her first language and never had difficulties in later classes with recursion or functions as values.
Scheme, like Lisp, no matter how popular, seem to me a little... esoteric? Even though there's no reason to, they're easy to parse, and enchantingly functional. Maybe that's how BASIC spoiled me, pushing me towards procedural code on day 1? :)
As I've told unbelieving students that I learned to program using a Teletype and line numbers were really really useful. Later I actually used an "editor" on a DEC Writer and it was even more convoluted. (it would print the line you were editing, down arrow would move to the next line, up arrow to the previous line, right arrow would print out the current line character by character and if you typed other characters they would either be inserted or replace characters depending on the mode.)
I think a case insensitive python with group delimiters rather than using indentation for groups and a line terminator character would be a good replacement. The goal is to minimize the number of new things you have to learn to get going. Concepts like grouping and individual statements seem to "stick" better with students when they can easily express that with characters in the code. (my experience teaching people to program YMMV of course).
For where you have to put a newline and an indent, I tend to think of it like the mandatory "only good" formatting, which many languages suggest, or enforce, anyway. Maybe rather than "whitespace matters", we should see it more like "you gotta start an indented block after if condition:"
The author, being born in 1987, while interested in how things came to be the way they are, only had an 8-bit and PCs, and needed to base it on some archive digging, and it was really satisfying.
I have corrected the Fortran reference - was mislead by the "70", but it turns out it was more like a WIP standard that wasn't even in use until the end of the decade.
Inserting on a DEC Writer must have been... not the most intuitive experience. I think inserting characters in the middle of the line wasn't practical on anything else than a screen, even if of an electronic typewriter?
It's also a great point how case sensitivity may be confusing for beginners - it's the same word after all, isn't it?
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.
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
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/
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!
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".
Part of the problem is that the OS API is kind of restricted to basic sounds and graphics drawing primitives. For everything else you need PEEK and POKE.
The beauty of BASIC is that everything is so concrete. Every line has a number, and you just keep going down the page unless you hit a GOTO. It's easy to reason about what's going on inside the computer. Abstractions make a language powerful, but also harder to learn. This is why spreadsheets are still the most popular way of programming a computer -- they're concrete and you can see exactly what is happening in every cell.
I will try to say this without bitterness: a wistful statement like this could only come from someone who hasn’t had to maintain production software of any size written in BASIC, which was my situation from 2016–2021. It was incredibly fragile and difficult to reason about, *because of* its so-called simplicity, global variables and line numbers with GOTO/GOSUB in particular.
Abstractions do not always make a language harder to learn. A language with the right set of abstractions for the problem space is going to be easier than a “simpler” language that is insufficient to meet the size or complexity of the actual problem. Machine code is the most concrete of all: by your standards it ought to be the most beautiful language of all.
The appropriate problem space for BASIC is “an alternative to assembler for teaching programming to middle-schoolers” — which was how I first encountered it. Using it even for that use case is irresponsible in an age where we have Python and Pyret.
Suppose you're trying to do maybe the second program someone ever writes -- print out the numbers from 1 to 10.
In BASIC it's something like:
10 LET X=1 20 PRINT X 30 IF X <= 10 GOTO 20
In Python it's:
for x in range(1,11) print(x)
In the BASIC example, you need to understand LET, PRINT, IF, and GOTO, and the general concept of a variable.
In the Python example you have to explain:
1. What a variable is
2. What a for loop is, how it's repeatedly assigning values from a sequence to the variable x and then running the indented code
3. That range(1,11) is a function call (what is a function?)
4. That this function returns a generator (now we're really in the weeds)
5. That print(x) prints out the variable.
IMO Python 2 was a better teaching language because lists are concrete and generators are (much) more abstract.
The old 80s microcomputers were absolutely ideal for this, and the other magical thing was that you'd just boot up and start typing. You could use BASIC to write software that wasn't quite as good as what you'd buy, but it was in the ballpark, which was very exciting for a kid learning to program. Roblox I think is the modern version of this.
[1]: https://en.m.wikipedia.org/wiki/Logo_(programming_language)
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.
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"
I think the idea of learning one bad thing and being ruined for life is a misconception about learning.
The GOTO guy has done more damage to computing than Microsoft and Google combined.
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.
Was it the first language you tried? Was it a PC or an 8-bit home computer?
...and weren't line numbers a parallel to memory addresses? Not named, of course.
At the end of the day, what matters is the end-product. Your users don’t care what programming language or tech you used to solve their problem.
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...
<https://news.ycombinator.com/item?id=35220605>
I wrote BASIC code in the 1980s; both games and utility software. It is precisely because I did those things that I object to any BASIC lacking functions. The BASIC I used lacked functions, and I remember it being very difficult to do what I can now call abstractions and subroutines. This would have been vastly more easy if the BASIC I used had had user-defined proper functions.
Functions return a value, and can be used by name in an assignment operation.
Subroutines are not interchangeable with them and are traditionally called by line number, and lack local variables.
It sounds to me like what you are referring to are procedures: named blocks of code that can accept parameters, manipulate them in local variables, and thus can call themselves, enabling recursion.
If that's what you meant, I agree. I owned a few (ZX Spectrum Beta BASIC, Sam Coupe SAM BASIC, and BBC BASIC V) and it makes much clearer code very easy.
Firstly, because you are so lazy and inconsistent with your terminology, it's not possible to determine what your real meaning is.
Secondly, because you are muddling up separate and different terms "function", "subroutine" and not using the correct term "procedure", you are missing the core point that even simple BASICs had subroutines.
0/10, try again. Learn the right words and use them correctly.
But it also made it easy to learn. You got more done after learning a few keywords. With more evolved languages there's more to teach in order to make one aware what would be the preferred solution, so that they don't bang out unstructured code forever. The same lack of features makes it quick to grasp. Most of the keywords have a specific functionality, only a few actually "structure" the program and control the flow and the variables. It gives you the opportunity to jump straight into what you want to do. This, plus booting right into distraction-free BASIC environment within a second was a powerful combo.
I believe that if someone keeps learning, they will outgrow that feature set, and prefer having functions and procedures, to hide away the complexity of some operations. But you could start learning even doing BASIC-level coding in, for example, Python, and use the more advanced constructs later on. It's one of the languages where a tutorial wouldn't have to start with a "let's ignore what public static class Main public static void main means for now".
Guess we need to hope for Mojo's success.
BASIC is a product of limited memory. It can run, as an interpreter, in a machine with 4K of RAM and nothing else. No ROM--No tape--No disk.
Try that in any other language. The only ones that can even attempt that are Scheme and Forth.
Dijkstra can slag BASIC all he wants; he had access to computers with megabytes of storage. We plebians, on the other hand, were quite lucky if we had 4K of RAM.
It was my first language - I don't think it was detrimental as it lead to me having my career in tech.
What I hate is the number of tools since created to enable endless tech debt and horrible engineering practices so as to increase the hiring pool of fungible coding talent.
Who needed nice things anyway when we have 280 characters and inspiring influencers?
Turns out it was Dartmouth BASIC, much simpler than the ones on C64, CPC, XL/XE or a ZX.
Old kodger powers -- ACTIVATE! *Form of,an 80s programmer! (My sidekick will form something liquid like a case of Jolt)
I miss those days, because anyone could learn to do whatever they wanted -- it was just work, not layers of corporate. Granted, it was mostly assembly language to get anything done, but it was all open
And just so you know-- I have other things I can change into like:
Form of - a paper tape reader/punch!
form of - a modem without an AT command set!
Form of - 64KB of RAM -- or less!
Form of - the GOOD Byte Magazine -- but if I had to, I'd settle for an Interface Age or Creative Computing
Form of - that snooty guy at the Byte Shop who wouldn't talk to this kid because he had no money
Maybe I should have called them Blue-Smoke powers -- I certainly made enough of that.
Maybe early BASICs were so-so, but QBasic already had all kind if procedural stuff.
Currently I am using OpenSCAD Graph Editor: https://github.com/derkork/openscad-graph-editor to create programs:
https://willadams.gitbook.io/design-into-3d/programming#open...
but the fundamental question which remains unanswered is:
>What does an algorithm look like?
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!