sometimes if wonder if an idea like this is somehow related to the intuitive and rather questionable beliefs that people who don't know a (human) language will understand it better if you shout at them, or that kids learn better if you condescend to them
The very axiom is an important point:
If you type a valid command, the computer does it _now_. If you prefix it with a number, the computer remembers it and does it later.
That is huge. With this very simple distinction, which can be adapted to any human language or alphabet, suddenly, you have a simple model for building up programs in small steps, without needing to know about "files" or "folders" or "text editors" or any of that arcane stuff that learners need to handle Python or any other so-called beginners language.
"Do it now" versus "remember this" without using files is massive.
A second point, and a pain point for me with C and things built in C such as Python...
In BASIC, if output is in quotes, the language prints it. Other stuff is outside the quotes. Dead easy, simple, memorable.
PRINT "My name is "; name$
That's it.
C is much more complicated, with magic happening inside the quotes.
printf ("My name is %n", n);
Some of the weird stuff is inside the quotes but then it's repeated again outside them, and the stuff inside sort of affects the stuff outside, so some of what's inside is printed, and some is kinda processed somehow...
It's complicated and it's unnecessary and it's wrong to expect kids and beginners to learn this arcane 1970s junk.
Python does the same sort of weird processing...
print(f"My name is {}" name)
... or something. It's messy and it's unnecessary. It's exposing the beginner to implementation details and it's a bad idea.
Most other mainstream languages (C, javascript, java, rust, etc) seems to have settled on some semi-common syntax of the same ancestry so that it is "easy" to learn once you know another of the same kind.
Lisp, on the other side... You have to learn a different paradigm initially, which some find hard and/or irritating, but then, everything is so wonderfully regular.
I am not so sure of that. BASIC has direct ancestry in Algol and Fortran, but it's also informed by COBOL, which appeared 5 years earlier. COBOL goes much further to be English-like, with its
ADD foo TO bar GIVING baz
... syntax. It is my impression that BASIC's design intentionally avoided that, going for something a bit more terse and efficient yet still readable.
> Most other mainstream languages...
I think that's an artefact of commercial success.
Pascal and the whole large, wide-ranging Pascal family, from Euclid to Ada, doesn't. Forth and Postscript and HP calculators and the world of RPN don't. Mathematica and things don't. Classic MacOS had AppleScript which doesn't, and that persists in OS X. APL didn't. Windows straddles a line with both C ancestry but also BASIC, VB, VBA, VB.NET, PowerShell and a bunch of other stuff that's not very C-like at all.
And, as you say, Lisp is a whole other world unto itself.
There's prefix notation with a family of languages, postfix notation which is another family, and infix, which is a huge family of which the curly-braces language are a subset but by far not the only subset.
It looks like that from one position, embedded in the xNix world, but it's not a valid generalisation, no.
You can come at that from a different perspective in an improved editor, like Emacs, with the interpreter running as a subprocess: Write whatever you want, then send a portion of it to the interpreter and see the results in another window or pane.
> In BASIC, if output is in quotes, the language prints it. Other stuff is outside the quotes. Dead easy, simple, memorable.
I wonder if this is simpler to you just because you imprinted on specific BASIC dialects as a child.
1. I wouldn't put beginners in front of Emacs, no.
2. The BASIC user-interaction model can be implemented in 8kB of ROM, and was on most Commodore 8-bits, for instance, without any block-addressible direct storage. That's a big win, in my book.
> I wonder if this is simpler to you just because you imprinted on specific BASIC dialects as a child.
I genuinely don't think so, no. It genuinely seems like a simple, clean, logical division to me, and the way that C and C-derived languages let implementation details fall through for the user to have to face and deal with seems like a major failing to me.
It is not meant to scale to large projects, of course, but it provides a distractions-free learning experience.
It seems like you can have a little DSL that is pretty simple and good for small tasks, but doesn't always scale well upwards (think Awk). The tools built to be scaled are awful for small and quick stuff.
I think something like Forth is pretty nice for building up a shell language, but the stack methodology for everything is both a blessing (simplicity) and a curse (let's be honest.. pretty weird).
I really like the idea of powershell, but the performance is just abysmal, so a lot of heavy data processing work is a no-go even if it's fun.
Unix and BASIC are strictly orthogonal concepts/products. -hp- sold happily BASIC with their Unix workstations (that combination, at one time, was popular for automating test&measurement gear).
Nothing stops you from linking a BASIC interpreter to /sbin/init .
It is about philosophies.
UNIX is not a codebase any more. Novell bought the Unix code and the Unix trademark from AT&T in 1993. It gave the trademark to the Open Group and since then "Unix" means "an OS that is compatible with Open Group testing".
Unix is a way to design and use an OS.
A big part of that is the conceptual model: plain text files, which can be sent to programs as input, and programs' output can be captured as text and kept or sent on to other programs.
BASIC, as it developed and went very widespread in the late 1970s and early 1980s (and then faded away again) has a different model of its own.
That model is that the computer boots into a BASIC interpreter, and what you type is direct input to that interpreter. Some implementations (notably the very widespread Microsoft/Commodore model) let you edit it on screen and when you hit Return that was sent to the interpreter too.
There is no separate editor. The entire UI is the editor. You can't enter the editor because you can't leave the editor; there is no other UI. There's no "shell."
As such there needed to be an auxiliary model for saving code for later, for building up a program in memory as you write it.
That model is: enter a line number at the beginning, and it's not executed now, it's stored for later.
In most implementations there's some command from bringing back a numbered line to change it. Just entering the bare line number deletes that line.
It is its own UI model, and while I am not arguing that it is a better model or a worse model or comparing the virtues of the models, I'm just saying that it is a UI model and that it is a different UI model to the Unix UI model.
I think you could do something similar with a python IDE that abstracted away the file system as an introductory mode, and I even feel like I have used something along those lines, but I can’t remember if it was an idea or a memory at this point.
Anyone else care to chime in?
I do know of alternatives of comparably low effort. Logo's "to" command is the best example I know: if instead of a known command, you tell it "to $newProcedureName, it starts remembering instructions until you tell it "end".
That's clever, although I have no real idea of Logo's mainstream success, while tens of millions of computers shipped with BASIC and were used by millions of happy children.
But the problem you seem to skip over is:
> as long as switching in and out of the editor is low effort
What editor? Why does there need to be a separate editor? Should there be?
print(f"My name is {}" name)
print(f"My name is {name}")
print("My name is", name)I Googled this before posting, and found this:
https://www.geeksforgeeks.org/python-output-formatting/
Your comment seems to contradict that, AIUI?
But TBH your specified syntax doesn't look any better to me. Why is { and } magical inside quotes? Why does putting an f before the string to be output make magic happen? Why isn't a variable called `f` output as it would be after the string?
The Unix/C family has the habit of inserting what looks like random line noise into its output statements, which do special stuff depending on what order they're in and where they appear relative to other line noise.
Python fans think it's an easy, clear and obvious language, and as such, it's not only a suitable replacement for BASIC but a better choice.
But it's not as obvious as it looks to people who grew up in the Linux world and know little else. Such as this example: `f` before the string does something totally different to `f` after the string, and there's nothing to mark or indicate that. You just have to know that and remember where it goes.
> via a PRINT USING statement.
For me, something like that is preferable. There is one command that does unformatted output, and a different one that formats it. That's clear. With either, what's in quotes is what comes out. If it's inside quotes, it's demarcated and it's special: the human put this in there, and don't mess with it, just do what you're told.
Whereas with C, and in a different way with Python, the language does whatever it feels like with the stuff in quotes, and the human has to do extra work remembering that some stuff is magic and some isn't.
I am not attempting some full language critique here... merely reporting some of my own personal experiences.