> and the built-in libraries was as close to the liberty and scope of Python as you could get in those days

And even better with Delphi that additionally had better rapid UI creation possibilities than Visual Basic, and on top of that, differently than Visual Basic, produced a self containing executable, not depending on anything external.

Yeah, but the VB executables themselves were tiny (in P-Code form, which was the default, they were also much more compact than machine code) and while a single exe+runtime itself was larger than the ~300K a minimum that Delphi 2/C++ Builder would produce (with +~100K for a program that did something interesting), it would take 3-4 programs sharing the runtime to quickly win that difference back.

This is actually a (minor) issue i have with Lazarus - the executable files do not depend on anything, but they are too large (~2MB minimum nowadays, if you remove all debug info, etc) so if i want to create several "small" utilities that focus on one thing instead of a multi-tool, i waste a lot of space (and most importantly nowadays, bandwidth).

At least with Delphi you can compile the executable with the runtime library as a separate file to be shared among the programs (my guess is that they wanted to do something the VB shared runtime, but it didn't seem to catch on as nobody used it like that).

> the VB executables themselves were tiny (in P-Code form, which was the default, they were also much more compact than machine code)

Now that you mention and I think about it, as VB was compiled to the p-code and depended on the big common runtime which executed it, it can be seen as one Windows-specific spiritual precursor of... Java.

Yeah, actually Microsoft used P-Code way before VB1 - AFAIK their C compiler was able to emit it and several of their products were compiled as P-Code instead of machine code, which helped to save disk space (a premium at the time, especially considering it could make a difference on how many floppy disks they shipped) and quickly port their applications to other emerging platforms at the time (like the Macintosh).

Both Microsoft's P-Code and Java were really inspired by UCSD Pascal which only emitted P-Code to be executed by a runtime they implemented quickly in a lot of systems (including the original IBM PC).

> Both Microsoft's P-Code and Java were really inspired by UCSD Pascal which only emitted P-Code

Yes, and I've actually experimented with UCSD Pascal on a 8-bit machine (Apple II). Turbo Pascal was, of course, much faster on it (using Z-80 card).

The designer of Pascal, prof. Niklaus Wirth, evolved the language into Modula-2 and then Oberon. Oberon is a refreshingly lean language. The specification is only 17 A4-pages long:

https://www.miasap.se/obnc/oberon-report.html

Note that this is Oberon-07, not Oberon, the latter is a bit different (and there are other Oberons). Also the spec is indeed small, but it doesn't address qustions like what happens when you assign an integer to a byte that is outside the range that a byte can represent.

Oberon-07 is simply the latest version of Oberon, like Python 3 is the latest version of Python. Other non-Wirthian Oberons are best viewed as forks of the original.

The result of assigning an integer > 255 to a byte is unspecified; it's the same with numeric overflow in arithmetic operations.

You'll find that a lot of people who work with Oberon explicitly state the dialect/variant they use (they are different dialects, not just versions) and Oberon usually refers to either the original or the language family.

Yes, the result is unspecified, that is what i'm talking about: it doesn't specify what it happens, meaning that the implementations will have to figure that out themselves, potentially in an incompatible manner (although in general implementations do try to be compatible with each other, but this is by communicating among themselves and trying to fill the holes in the Oberon-07 spec).

The programmer should make sure that an integer is within the range of a byte before assigning it to a byte variable. It's no more complicated than that.

The question is what happens if the programmer doesn't do that. If you are implementing a compiler, what do you do in that case? Are you using whatever is the first or last byte in memory (depending on the machine endianess)? Are you wrapping the value around to keep it consistent between implementations? Are you generating code that aborts the program?

Similar question is also about pointers, what happens if you try to use p^ when p is nil? Do you try to access whatever address nil represents? Do you abort?

C has the notion of undefined behavior and it is explicitly mentioned, but Oberon-07 doesn't mention this at all meaning that implementations need to make those decisions.

If you are implementing a compiler you do what makes most sense for the target language/machine. On the other hand, if you specify exactly how each ill-defined operation should be handled you

1. restrict the freedom of compiler writers. On very small systems, for instance, array bound checking may not be implemented,

2. make programmer rely on non-obvious behaviour/results which makes programs harder to understand and maintain,

3. make the language specification more complicated.

Or you can simply type "Integer to byte conversion and nil dereference are machine dependent" (or implementation dependent if you prefer, but the point is to have something).

No way! I too stumbled through QBASIC. A guy I knew was 7 years older and in high school. They were learning Turbo Pascal. Every Sunday I would go to him after church to enquire about what else he could teach me. Then I would go home to try it and if I wrote it down wrong or wasn't listening it was a whole week before I could ask for help. It's so cool to see someone else walked that road