While we are here, another important article by Kildall has been made available online, "Global Expression Optimization During Compilation"-1972 [1] - while the field has obviously moved on, this is still interesting and relevant IMO, if anything it shows what a talented technical writer he was.

[1]: https://www.proquest.com/docview/302615627/?fromunauthdoc=tr...

Kinda saddens me that society usually aligns with marketing and business mindset (impressing, selling, profiting) instead of people like Kildall. There are many passionated, driven, creative, prolific people with intrisic motivations that are wasted due to commercial forces.

I remember the early IBM PC days. PC-DOS was $40. CPM/86 was $240. Both were available, people simply picked the cheaper one. I used both, and there was nothing better about CPM/86.

Due to inflation, this is like $113 vs $679 today. It was a no-brainer to buy MS-DOS instead. Kildall clearly was a businessman wanting to make money off of it.

It was IBM who set the price. According to Kildall’s right-hand Tom Rolander, they were shocked when they saw the price difference.

> It was IBM who set the price

Not what I heard at the time - IBM accommodated what Kildall wanted. Kildall could have sold it separately at a competitive price.

The date on it is 2016. 33 years later. I don't find that particularly convincing.

BTW, I've read a lot of computer histories, and I often find errors in them. This is why professional historians try to use contemporary sources as much as possible.

We ended up with the one this society, which usually aligns with business and marketing mindsets, deserves.

In time, we might remake society in a kinder, wiser version of itself. At that time, we might even deserve more Kildalls.

This paints Bill Gates as not a tech person and a business first person, which is not true. He got a BASIC compiler on the altair which MITS thought couldn't be done. He helped Wozniak implement a version of BASIC supporting floating point numbers. Gates didn't even want to take Microsoft public. They had to convince him. Ballmer was the biggest businessman in the bunch. Hell, he was the one that suggested kidall since Microsoft wasn't in the OS business.

This is mostly true. Gates was a tech wizard - a great programmer before there were even books about programming. But to make it sound like Gates wasn't a business-first guy is wrong - he wanted to sell software from day 1. Read any early bio about him and his speech about selling software to the homebrew club (https://en.wikipedia.org/wiki/An_Open_Letter_to_Hobbyists).

MITS was correct. TinyBASIC is a very different animal from the language for time-sharing minicomputers that was what people actually meant by "BASIC" at the time. For one thing, TinyBASIC was a language interpreter and not a compiler.

And had no timesharing features at all.

TS was fairly scarce in those times - let alone on PCs. I wonder when the first general-purpose time-share system was available ... outside of mainframes? I know UofM's MECC had MECC Timesharing System (MTS) up on a Cyber73 in 1977 ; before that, their SUMITS had to make do with batch-processing on a FunnyVac.

DRI had MP/M in 1979. I'm thinking about writing a multi-user dungeon for it. There doesn't seem to be any multi-user games for MP/M and, with the ability to host 4 terminals on an emulated Altair, it seems like a waste of resources not to have one.

> BASIC compiler

Interpreter - an entirely different kind of animal. Microsoft didn't get a BASIC compiler until much later.

> He helped Wozniak implement a version of BASIC supporting floating point numbers.

No. He sold Apple a BASIC, then used it as leverage to prevent Apple from making a BASIC for the Macintosh.

> Ballmer was the biggest businessman in the bunch.

He suggested cutting Paul Allen's family off when Allen was battling cancer.

Um, it is necessary to compile a program before being able to interpret it. I don't know how early BASICs were implemented, but the usual method is to compile it to some sort of intermediate representation, and then interpret that representation.

D's compile time function execution engine works that way. So does the Javascript compiler/interpreter engine I wrote years ago, and the Java compiler I wrote eons ago.

The purpose to going all the way to generating machine code is the result often runs 10x faster.

> necessary to compile

Um, no? your experience is probably at least two decades after the time period in question.. The more advanced versions of, for example, the TRS-80 BASIC (part of this "microcomputer BASICs that all share a common set of bugs") did no more than tokenize - so, `10 PRINT "Hello"` would have a binary representation for the line number, a single byte token for PRINT, then " H E L L O " and an end-of-line marker. Actually interpreting the code involved just reading it linearly; GOTO linenumber involved scanning the entire code in memory for that line number (and yes, people really did optimize things by putting GOTO and GOSUB targets earlier in the program so the interpreter would find them faster :-)

I was going to post this, but you beat me to it.

It's a VM of a sort, and the p-code the VM executes is tokenized input.

Tokenizing it and interpreting the token stream is still a compilation process. Even if it re-tokenized it each time it executed a line.

Tokenizing is a necessary but not a sufficient task for compilation. I could tokenize this comment to efficiently store it in a database but that would have nothing to do with compilation.

Recognizing `3+x*(2+y)` is compilation - even if the program is being executed while compiling it.

You can continue to argue the point but that goes against every single definition of compilation that exists. Compilation is a transformation of programming language into another form. For example, taking `3+x*(2+y)` and transforming it into a series of byte codes, machine language instructions, ASTs, or even C code would be compilation.

The BASIC interpreter doesn't recognize `3+x*(2+y)` nor does it compile it instead it evaluates that expression using a pair of stacks. You've expanded the definition of compilation to cover almost all computation. It's compilers all the way down to the electrons.

Well, all my compilers use recursive descent for expressions, meaning the stack is used to maintain the current state. Whether you evaluate it while doing this or produce an IR is a trivial difference.

It might be a trivial difference but it's literally the thing that makes something a compiler. It should make sense. How a piece of software works doesn't make it a compiler or not; it's input and output of the software that defines it as a compiler. That's true of almost any broad category of software.

No problem calling it parsing, but yeah, "compilation" feels like a huge stretch. And they didn't do recursive descent - just tokenizing for compactness (when you only have 4k or 16k of RAM you do things like that) - you could still get syntax errors at runtime. In some interpreters it also served to normalize abbreviations to save typing.

It is not necessary to compile a program, in the general case, before executing it.

Many programming languages parse their program to an AST then walk that AST interpretting as they go. But for BASIC you can parse/execute statement by statement - no need to parse the whole program ahead of time, and certainly zero need to compile to either machine code or any internal representation.

Remember at the time we're talking about 64k was a lot of RAM. Some machines had less.

The parsing, even if line by line as necessary, is still compiling.

In 45 years of writing software, I've never before seen anyone call tokenizing a BASIC program compilation. It's decidedly not common usage.

I've been writing compilers for 45 years now. Tokenizing is a big part of every textbook on compilers. To resolve expressions (which are recursive in nature) it would have had to do more than just tokenizing. While this isn't hard at all, it's "parsing" which is also qualifying it as a compiler.

I.e. the basic program was lexing and parsing. It's a compiler. A very simple one, sure, but a compiler.

Yes, but tokenization on its own is not compilation any more than whiskers are a cat just because a cat has them.

"Nobody" uses it that way, and language is defined by use.

Compilers generate code in another, usually lower level language that is executed by reading all of the code that could be executed first. Interpreters (such as the BASIC interpreter we are discussing here) read only that part of the code that gets executed and typically call functions rather than that they generate code (never mind JIT). Tokenization prior to interpretation is technically an optional step (it's just an efficiency boost) and is not normally confused with compilation even if there are some superficial similarities.

You of all people should know this, come on.

You and I have a different point of view.

Of all the hills you could die on this one seems really silly.

I have to agree. This is a very very odd objection, and it does not match up with my ~40 years of study of this industry, including WB's work.

You have an idiosyncratic definition of "compiler" then. Many BASICs, including the MS family of BASICs, did tokenize keywords to save on memory storage.

But 99.9% of people take "compiler" to mean translating source code to either a native CPU instruction set or a VM instruction set. In any tutorial on compilers, tokenization is only one aspect of compilation, as you know very well. And unlike some of the tricky tokenization aspects that crop up in languages like C++, BASIC interpreters simply had a table of keywords with the MSB set to indicate boundaries between keywords. The tokenizer simply did greedy "first token which matches the next few characters" is the winner, and encoded the Nth entry from that table as token (0x80 + N).

When LIST'ing a program, the same table was used: if the byte was >= 0x80, then the first N-1 keywords in the table were skipped over and the next one was printed out.

There were also BASIC implementations that did not tokenize anything; every byte was simply interpreted on every execution of the line. There were tiny BASICs where instead of using the full keyword "PR" meant "PRINT", and "GO" meant "GOTO" etc.

Early BASICs didn't compile a program before interpreting it. The interpreter read the code as written and executed it step-by-step. There was some tokenization; keywords were turned into single or double bytes and that was literally done when you pressed enter on the keyboard. Your source code was these actual tokenized bytes. On the Commodore 64, you could type the tokenized versions of keywords instead of the full keyword as a shortcut. Even numbers were not transformed into bytes ahead of time.

This was used to save memory -- there wasn't much room to hold both the source code and an intermediate form. But also it wasn't that necessary, with the keywords tokenized and the syntax so simple that there wouldn't have been much savings in space or performance.

Just like Jobs. He was the marketing and sales guy. Woz, et al. were the visionaries and engineers cranking out the product.

Jobs had a key difference from Gates - he had taste. He insisted on the injection molded case for the Apple II instead of sheet metal because he wanted it to look like a finished product. He insisted on not having lines dividing the color bands in their logo, which made it more expensive to print (but much nicer to look at).

Jobs would never let something like Windows 1 escape the lab.

He also refused to have fans in the first several models causing a high failure rate...

Form follows function. Just ask Ive.

Good thing Microsoft fixed it with 2.0!?

They arguably fixed it at 3.0, the first truly popular version of windows.

3.11 was the first really decent one.

3.1 was a massive upgrade over 3.0 - it introduced TrueType. 3.11 had peer to peer networking and, at least in Brazil, doomed Netware in the small business segment.

Jobs had control of the hardware and the software.

Gates (well, the MS programmers) had to make the software work on the PC hardware of the time (CGA/EGA video cards including non-square pixels and terrible colour palette, see https://devblogs.microsoft.com/oldnewthing/20100625-00/?p=13...)

Terrible palettes were a thing (the Macintosh II was the first Apple computer able to correctly display the Apple logo) in other platforms as well, as were rectangular pixels. Macintosh was the first Apple computer designed to have square pixels (even though the II came close for its original HGR modes, but that was gone with the /// and //e higher resolution modes).

I recommend reading "Idea Man" [1] by Paul Allen, Microsoft's cofounder, to understand the deep and early involvement he and Bill Gates had with computers.

I also recommend Hard Drive (1992) [2] for a deeper look into the business side of Bill Gates.

Regardless of any negative opinions about him, I believe Bill Gates was/is in a league of his own.

[1] https://en.wikipedia.org/wiki/Idea_Man

[2] https://www.amazon.com/Hard-Drive-Making-Microsoft-Empire/dp...

> He was nothing like BG.

This is exactly my point.

> He hated running a business, even though he started DRI after failing to convince Intel to buy CP/M

This is what uniquely qualified him to bring about a nicer timeline.

Sadly, we got the second rate one...

S12E45, Gary Kildall special: https://m.youtube.com/watch?v=doOQnc0A3Ek&list=PLmM8tWTshxQB...