5 ms·

There's a tender place in my heart for Pascal. The first language I was taught was Turbo Pascal (I had sort of taught myself QBasic before that, as much as one

There's a tender place in my heart for Pascal. The first language I was taught was Turbo Pascal (I had sort of taught myself QBasic before that, as much as one can from reading the help manual and stumbling through), and the built-in libraries was as close to the liberty and scope of Python as you could get in those days. It really inspired me to continue down the path of software development. I also have fond memories of BBS door games and software, a large portion of which was built with Pascal. I digress: but it's nice to reminisce about those old days.

acqq 7y ago
> 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.
- Crinus 7y ago
  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).
  - acqq 7y ago
    > 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.
    - Crinus 7y ago
      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).
      - acqq 7y ago
        > 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).
augustk 7y ago
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 https://www.miasap.se/obnc/oberon-report.html
- Crinus 7y ago
  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.
  - augustk 7y ago
    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.
    - Crinus 7y ago
      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).
      - augustk 7y ago
        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.
Just1689 7y ago
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

acqq 7y ago

> 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.

Crinus 7y ago
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).
- acqq 7y ago
  > 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.
  - Crinus 7y ago
    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).
    - acqq 7y ago
      > 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).

augustk 7y ago

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 https://www.miasap.se/obnc/oberon-report.html

Crinus 7y ago
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.
- augustk 7y ago
  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.
  - Crinus 7y ago
    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).
    - augustk 7y ago
      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.

Just1689 7y ago

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