O.T.: BASIC Co-Inventor Thomas Kurtz Has Passed Away

[GARTHWILSON]

Hackaday article posted yesterday: "BASIC Co-Inventor Thomas Kurtz Has Passed Away"
https://hackaday.com/2024/11/15/basic-c ... ssed-away/

[BigDumbDinosaur]

Despite “professional” programmers looking down their noses at BASIC, the language did a lot to get people interested in a programming career.  So, Dr. Kurtz can be justly considered a pioneer in the development of computing for the masses.  He was 96 when he passed away, a life well-lived.

I was fairly late to learning BASIC—I knew no high-level languages for about the first eight years of my computing career.  My first project in 1970 was machine code—literally; there was no assembler.  My second major project was also machine code, but at least I had an assembler at my disposal.  I wasn’t exposed to BASIC until 1979, when I got involved with something on an MAI Basic 4 minicomputer.  Once I got a Commodore 64, I decided to become more adept with the language, although it really was too slow on that machine to do anything serious with it.

Reading some of the comments posted on Hackaday about this, I see someone asserted that there was no good reason for BASIC to be successful and that it should have been Forth.  That gave me a good chuckle, as Forth’s learning curve is a lot steeper than that of BASIC.  Most people have a rough go with RPN and the concept of messing with a data stack.  On the other hand, BASIC’s infix notation is easy to relate to the way we learned math in high school.  Having automatic variables makes it easier for the programmer to focus on the task and less on having to wrestle with the machine and how/where it’s storing its data.  I suspect that had Dr. Kurtz and John Kemeny said...

Quote:

"Let’s introduce this language that looks like random gibberish, requires the programmer to be cognizant at all times of a stack, and goes completely opposite of what our students have learned about math and grammar.  We’ll call it BASIC, ’cuz it’s for beginners who want to be thoroughly turned off by anything having to do with a computer.”

...BASIC would have died a quick and painless death.

Fun fact about Dr. Kemeny: he worked on the Manhattan project at Los Alamos along side John von Neumann, and was Einstein’s mathematical assistant at one point.

I also noted comments about BASIC’s unstructured nature and how developing a major project with BASIC would be hellish.  That would be true of microcomputer BASIC dialects, especially Micro-Soft’s interpreter, but not so the timesharing BASIC interpreters that proliferated on minicomputers of the 1970s and 1980s.  Those interpreters were designed to support major business development, and are several orders of magnitude more powerful than what Gates and Allen were peddling.

Several such timesharing interpreters survive to this day, two of which, BBX and Thoroughbred Dictionary-IV, are familiar to me (I have Thoroughbred installed on one of my Linux boxes).  I have written major-sized vertical applications in Thoroughbred BASIC, one of which was a full ERP-style package used by a building materials distributor that they ran on for about 25 years.  Yes, it required quite a bit of planning and sit-down discussion with the business’ managers, as well as close to a year of programming and testing time, to bring it to fruition, but at no time were there any aspects to the language that got in the way of development.

Incidentally, Thoroughbred BASIC and BBX both support branch and subroutine labels, C-like structures, recursive programming, remote subroutines, reusable code, background processing, and several types of keyed random-access files, including ISAM.  Hardly a beginner’s language and hardly unstructured, I’d say. 

Thank you, Dr. Kurtz, for opening the fascinating world of computer programming to so many people.

[commodorejohn]

It was indeed a major contributor to the democratization of computing. Hats off, sir, may you rest in peace.

[jgharston]

BigDumbDinosaur wrote:

I also noted comments about BASIC’s unstructured nature and how developing a major project with BASIC would be hellish.

It's only unstructured BASIC that's unstructured. Structured BASIC isn't unstructured. REPEAT:PROChelp(sys1%):sys1%=FNtest(in%,flag%):UNTIL sys1%>endstate%

[cjs]

BigDumbDinosaur wrote:

Despite “professional” programmers looking down their noses at BASIC, the language did a lot to get people interested in a programming career.

Yeah, but pretty much any high-level language on microcomputers would have done that. It happened to be BASIC, but didn't have to be.

Quote:

Reading some of the comments posted on Hackaday about this, I see someone asserted that there was no good reason for BASIC to be successful and that it should have been Forth.

Yes, your analysis of that is correct, I believe. Forth is certainly higher level language than assembly language, but it's nowhere near as high level as BASIC. It's not so much just the stack use, but the particular style of stack use (including the lack of an easy and clear way of nesting things) that causes problems in the realm of expressions. You'll note that Lisp, which is a similar notation but prefix instead of postfix, doesn't have this issue.

But it goes further, as you mention: one thing that even the microcomputer BASICs had was automatic memory management which, as we all know to this day (at least those of us who have programmed in C and C++) is a big boon.

Quote:

I also noted comments about BASIC’s unstructured nature and how developing a major project with BASIC would be hellish.  That would be true of microcomputer BASIC dialects, especially Micro-Soft’s interpreter....

Sure, but that's what people learned on, and in the end when someone decided to strip down "mainframe" BASIC and functions went out the window, that's at least in part on the language designers. That couldn't have happened with Lisp.

It's worth noting that a huge factor in BASIC being a win over, e.g., FORTRAN (which provided the general idea of the language), was its focus on interactive development. Which of course was taken from (or rather, given by, given that McCarthy suggested it to Kurtz) Lisp.

[cjs]

jgharston wrote:

Structured BASIC isn't unstructured. REPEAT:PROChelp(sys1%):sys1%=FNtest(in%,flag%):UNTIL sys1%>endstate%

Yes, but that rather completely misses the whole point of structured code. We don't write structured code because it's inherently better; we write it because it's a much clearer expression of our intent, thus making it easier for other people to read, find bugs in, modify, etc.

Would you say that the code above is the clearest possible way, and easiest to read way, to express what you're trying to say? Is it quick and easy to identify the loop structure at a glance?

[GARTHWILSON]

I'll say that's terribly unreadable, even though I used the outstanding BASIC in my HP-71B (enhanced by language-extension (LEX) files written by the users' groups) for years.  I do seem to have an RPN brain, and Forth was a natural for me, and I have no problem at all with nesting in it—although the way the source code is laid out is super important to readability.  Many have accused Forth of being a write-only language.  I've definitely seen a ton of very unreadable Forth; but I blame that on the programmer, not the language.

My programming experience began with my TI-58c programmable calculator in Dec '81, then taking a class in FORTRAN IV and a class in 6502 at the same time in the spring of '82, then moving up to the RPN-based HP-41cx calculator/computer in '86 which I used to automate testing processes on the workbench at work, and then to the HP-71B hand-held computer in '87 or '88 which has the best BASIC I've ever seen.  Then we got HP's Rocky Mountain BASIC 5.1 at work to run on a full-length 68000-based HP Viper board in a PC, and it was a huge disappointment after what I had in the hand-held HP-71B.  GWBASIC was worse yet.  A few years later, I got into Forth on the HP-71B, and that ended my desire to pick up any other languages.  With Forth, I felt like, "This is where I belong.  This is home to me, and I'm staying here."  There is a Forth available for the HP-41 also, but the 41's hardware is hardly suitable for Forth, and it seems like the Forth was just written just to show it could be done, not because it was at all practical.  My home-made workbench computer has taken over virtually all workbench work of controlling things and taking data on the workbench, with Forth in its EPROM.  It's super easy to mix assembly language in when necessary for performance.

Today if I want to write programs with a lot of floating-point complex-number operations to figure out something in my design work, I always turn to the 41 with its RPN, not the 71 with its BASIC, unless the 41 simply doesn't have the speed or memory capacity needed for the task.  The large look-up tables in that section of my website were calculated with the HP-71B, using BASIC.  The largest two take 256K each of memory in the 65816's memory map for 65,536  32-bit outputs, and their Intel Hex text files take 737KB each.  One is for inverses, which is good for fast division also, because you can look up the inverse of the divisor and multiply that using another table which dramatically speeds up the multiplication.

I am glad of course for the fact that BASIC got so many kids and teenagers into programming on early home computers.

[barrym95838]

jgharston wrote:

It's only unstructured BASIC that's unstructured. Structured BASIC isn't unstructured. REPEAT:PROChelp(sys1%):sys1%=FNtest(in%,flag%):UNTIL sys1%>endstate%

At first glance, that doesn't even look like BASIC to me. But I grew up with Microsoft BASIC variants, so it's not as easy for me to mentally shift gears.

[BigEd]

JGH's example would be more convincing, I think, if laid out differently. It's standard BBC Basic.

Code: Select all

REPEAT
    PROChelp(sys)
    sys=FNtest(in,flag)
UNTIL sys>endstate

It's clear (to me) that REPEAT..UNTIL is a nice addition, much more structured than FOR, IF, or GOTO, and also relatively easy to implement (it doesn't need any lookahead or complex parsing)

[barnacle]

BigEd is right; it's not the syntax of the instruction but the semantics of the way it's laid out.

It's why my tiny basic doesn't allow multiple statements on a line; it's too easy to miss some small but critical part of an instruction within a loop when it's all stuffed on a line. (I implement REPEAT/UNTIL as do/while which is effectively identical beyond the names, and the sign of the final test).

Programming is a question of algorithms and data structures; tricksy programming helps nobody and deliberately obfuscated code - irrespective of the language that's being obfuscated - is an offence to any other programmer... there is absolutely no point in writing code that no-one else (including, probably, future you!) can read.

Neil

[cjs]

BigEd, that clarified things massively.

Interestingly, writing that out in a more functional way to get rid of the extra complexity of the REPEAT loop makes more clear one of the issues with the code: when you rewrite it to be a function with a tail call you discover you need to add a sys parameter, at which point it becomes obvious you need to set sys in two different places: once outside the loop and once inside it:

Code: Select all

function helploop(sys, in, flag):
    help(sys)
    sys = test(in, flag)
    if sys <= endstate:
        helploop(sys, in, flag)

This points out one of the issues with BASIC's hard focus on an imperative style, rather than encouraging the use of functions for everything.

[barrym95838]

barnacle wrote:

BigEd is right; it's not the syntax of the instruction but the semantics of the way it's laid out.
Programming is a question of algorithms and data structures; tricksy programming helps nobody and deliberately obfuscated code - irrespective of the language that's being obfuscated - is an offence to any other programmer... there is absolutely no point in writing code that no-one else (including, probably, future you!) can read.

Neil

I'm probably in the minority here, but I'm actually fond of tricksy programming, especially on older CPUs that can significantly benefit from its utilization, with smaller and/or faster being the implied goal. This is where proper and informative comments in the source can make all the difference. Obfuscation can have a place too, but a much smaller one, IMO. I'm not really a "programmer" though ... I'm a hobbyist/hacker who likes to program with an intense fetish for optimization, so that is a contributing factor.

[barnacle]

Ah, but you don't have to work with decade-old code written by a cow-worker with a penchant for, um, dense programming matched only by his distaste for white space and comments... "All my code is self-commenting!"

Though I can appreciate the intellectual challenge of creating the smallest fastest code - you need only look at my neobasic, though I haven't 'optimised' it yet, for an example - I can't help feeling it doesn't have anyone in a professional environment.

Neil