• Please review our updated Terms and Rules here

Testimonies of using BASIC back in the day

In Pick, "Data BASIC" was/is the core programming language. Very popular for ERP and accounting systems back in the day and still hanging on today - my work in Pick pays my mortgage. :)

g.
 
However, in Windows, Visual Basic was a very popular option, and quite a few well known programs were developed in VB.
A lot of companies also used Visual Basic for Applications as an advanced scripting language for adding functionality to their Office documents and such. You'd be surprised how advanced and mission-critical some of that stuff was/is.

It is kind of shocking how much you can do with a spreadsheet and Visual Basic for Applications. I think quite a few companies made use of that software to get around hiring external programmers.

Anybody use Visual Basic for DOS?
 
I don't remember anyone using Visual Basic for DOS. Most of the VB code I was familiar with was business front ends to databases which were very difficult to build with VB-Dos because of DOS's memory limits.
 
In Pick, "Data BASIC" was/is the core programming language. Very popular for ERP and accounting systems back in the day and still hanging on today - my work in Pick pays my mortgage. :)g.

The Microdata Reality-based Pick system was very popular in the insurance industry back in the day. I tend to think of the PICK system more as a file system which used a dialect of BASIC to access it--ISTR that very early versions used something that resembled PL/I more than anything.
 
I use D3 Pick, which is a direct descendant of Pick AP/R84, etc. Rocket Software now owns the product and they produce a number of MV db products - UniVerse, mvBase, mvEnterprise. Northgate Information Systems still sells Reality - it runs under Linux (and likely Windows) now.

Pick was NoSQL before it was cool. (hell, Pick was NoSQL *before* SQL! :D )

g.
 
My first computer, about 1982, was an Epson HX-20, which had a fair BASIC built in, and a year later I got the add-on TF-20 disk drive, which was well supported by a basic extension. Did quite a bit with that. Still have everything, although just not the HX and the TF are not communicating (but hopefully fixable).

On the back of that, I became my work computer expert. Local Council Planning Dept. When the whole council got an IBM /36 the system did NOT have anything for us, so I used the /36 Basic Interpreter to create some software, which (I think) works pretty well. That system did have some extras for structure, I was especially impressed with an 'Input Fields' structure whick allowed screens to be processed as a lump, both for input and display.

As others have said, you can write bad code, and good code, with just about any language. Any BASIC is really what you make of it.

I worked on some CBASIC code that was handling all the Accounts functions for the State of Maryland Courts system. Was that 'mission critical'?

Sincy my BASIC days I went into various combinations of dBASE/Clipper/C, but I still use basic from time to time. If I need a quick and easy prog to manipulate a file, then QB is as good as anything. And it's pretty fast on modern machines.

I've played with FreeBasic, and it's pretty impressive, and it's still BASIC as I've always known it. Handy for doing maintenance/conversion things with MySQL databases.

Remember the old saying - 'A Bad Workman Blames His Tools'!

Geoff
 
Well, if you paid attention to John Kemeny(deceased) and Thomas Kurtz (still kicking, the last I checked), the only "real" BASIC is TrueBASIC.

The others are illegitimate pretenders. In some respects, I have to agree that Visual BASIC is so far distanced from Dartmouth BASIC, that it isn't BASIC at all...
 
Well, if you paid attention to John Kemeny(deceased) and Thomas Kurtz (still kicking, the last I checked), the only "real" BASIC is TrueBASIC.

The others are illegitimate pretenders. In some respects, I have to agree that Visual BASIC is so far distanced from Dartmouth BASIC, that it isn't BASIC at all...

But wasn't Kemeny the one who said that BASIC should never be limited to one operating system, and isn't True BASIC now limited to only running on Windows? And is it true the rumour that True BASIC disables multitasking in Windows; the very language that promoted multitasking at Dartmouth?
 
Last edited:
Here's another way BASIC is useful:
I used to make a living designing and building industrial controllers based on these things.
 
Tangentially related, some months ago I started a benchmarking project for 8-bit home micro BASIC systems, calculating prime numbers by trial division (the goal was not to have an efficient way of finding prime numbers, but to have some consistent unit of work that could be expressed simply and therefore be implementable regardless of limitations in any particular system's BASIC).

At some point I thought I'd try my hand at an APL version to compare the speeds of BASIC and APL in my IBM 5100, and the project started spiraling out of control from there.

ZBasic, Dartmouth True BASIC (on the Macintosh), various Microsoft BASICs, even Atari 2600 BASIC are all represented (that last one was a challenging port).

It's pretty clear to see that Microsoft BASICs were all pretty slow, that Woz's Integer BASIC is pretty tidy, and Acorn's BBC BASIC is a masterwork.

I still have a few more language ports up my sleeves in various unfinished stages, a structural mistake in the DRI Personal BASIC version (which has also snuck into a couple other ports) that causes it to do more work after finding the last prime, which I need to correct both in the source and the published results, and a long list of results to gather using software and hardware I've already collected with ports I've already written.

Mostly the micro results are in the bottom half.

http://www.typewritten.org/Articles/Benchmarks/primes.html
 
When I get a chance, I'll have to run your benchmark on the BASIC that I wrote for the Durango systems. I've still got a couple 850s around. CPU is approx. 3 MHz 8085. The company is long gone, but a 16-bit version was ported to Xenix and was still in use in a couple of places about 5 years ago.

The weakness in a lot of BASICs isn't the basic math, particularly not integer math, but in character manipulation. Some were hideously inefficient.

Also, you have to consider the numeric representation. One big difference between some finance-oriented BASICs is that numeric representation is floating-point decimal, not binary. When working with decimal currencies, the occasion for truncation error is much less with decimal (that's one of the reasons that COBOL implements it to this day as the default).

It seems to me that there was a benchmark list from the 1970s that was essentially open-ended. Machines like a CDC 6600 got to compete--even though it used only a 10MHz clock, it was stunning to see how much faster it was than just about anything.
 
Mine too, but not for the better, I don't think. I wouldn't have had the desire to write my own assembler, which really affected everything I did after that point.
 
Also, it's very C64-centric.

Well, given that the C64 is the best-selling computer of all time, I suppose it would follow that the C64 is also the best-selling BASIC implementation of all time?
Or at least, in the 80s, when BASIC was at its peak in terms of relevance. So I would suppose that the majority of people who grew up with BASIC, grew up with C64 BASIC?

In fact, by the time I finally got my own Amiga, it was an Amiga 600 with Workbench 2.0. And unlike the 1.x incarnations, AmigaBASIC was no longer included as part of the OS.
I suppose AmigaBASIC always took more of a backseat on the Amiga compared to the C64, since it was a separate application that you had to boot up first, after first booting the OS. Neither of which was required for most software, since they would be on self-booting floppies, and especially games generally didn't use the OS at all.
 
It's pretty clear to see that Microsoft BASICs were all pretty slow, that Woz's Integer BASIC is pretty tidy, and Acorn's BBC BASIC is a masterwork.

Wouldn't that at least partly also depend on the design choices with regard to data types?
Because as I recall, the C64 BASIC didn't have separate integer and float datatypes internally, so everything would be processed through floating point routines, which would make math operations relatively slow.

So I suppose what I'm saying is that it would be interesting to have both integer and floating point workloads, and see how the two relate in performance. Perhaps on some BASICs, the floating point versions are much slower, where on others, there's no difference.
 
Wouldn't that at least partly also depend on the design choices with regard to data types?
Because as I recall, the C64 BASIC didn't have separate integer and float datatypes internally, so everything would be processed through floating point routines, which would make math operations relatively slow.

So I suppose what I'm saying is that it would be interesting to have both integer and floating point workloads, and see how the two relate in performance. Perhaps on some BASICs, the floating point versions are much slower, where on others, there's no difference.

Applesoft programs run faster when using integer types (%). How much faster I don't recall, but it would be easy to benchmark.

Commodore BASIC programs run significantly faster if you avoid explicitly using numbers. It takes a long time to parse numbers. So if you assign frequently used numbers to variables and only use the variables, execution speeds up. If I remember right, there isn't a significant improvement doing this in Applesoft.

The Commodore BASIC maths routines are much slower than the other Microsoft dialects, if I remember right. That's due to a much higher precision used in Commodore BASIC. I remember running into that whilst porting a program from Commodore BASIC to Applesoft. It seems to me also that there was something odd about it, that Commodore BASIC has a higher amount of error in some routines due to rounding errors, which shouldn't happen with the higher precision.
 
A lengthy set of benchmarks published in 1982 can be found at https://works.bepress.com/mwigan/14/ which includes Apple II+, Commodore PET, and many Z-80 variants.

The comparison ranges from the CDC Cyber 171 (fastest) to TRS Pocket Computer (slowest) with some amusing notes like the Seattle System 2 (8086) was faster than PDP-10 and IBM System 34.
 
All software released for the TRS-80 Pocket Computer was written in BASIC.

pocketcomputer.jpg
 
Back
Top