4 ms·

Compare Limbo+Tk under Inferno with current C#/Java. Or C++ against Plan9C. We have impressive CPU's running really crappy software. Remember Claude Code aski

by anthk 7mo ago

Compare Limbo+Tk under Inferno with current C#/Java. Or C++ against Plan9C. We have impressive CPU's running really crappy software. Remember Claude Code asking 66GB for a damn CLI AI agent for something NetBSD under a Vax (real or physical) from 1978 could do with NCurses in miliseconds every time you spawn Nethack or any other NCurses tool/game. On speed, Forth for the ACE was faster than Basic running under the ZX80. So, it wasn't about using a text-parsed language. Forth was fast, but people was not ready for neither RPN nor to manage the stack, people tought in an algebraic way. But that was an 'obsolete' mindset, because once you hit HS you were supposed to split 'big problems into smaller tasks (equations). In order to implement a 2nd degree equation solver in Forth you wouldn't juggle with the stack; you created discrete functions (words) for the discrimination part and so on. In the end you just managed two stack items per step. If Forth won instead of Basic, instead of allowing spaghetti code as a normal procedure we would be pretty much asking to decompose code into small functions as the right thing to do from the start.

hnlmorg 7mo ago
Most dialects of BASIC actually had functions too. They just weren’t popularised because line numbers were still essential for line editing on home micros. > On speed, Forth for the ACE was faster than Basic running under the ZX80. So, it wasn't about using a text-parsed language. Forth and BASIC are completely different languages and you’re arguing a different point to the one I made too. Also I don’t see much value in hypothetical arguments like “if Forth won instead of BASIC” because it didn’t and thus we are talking about actual systems people owned. I mean, I could list a plethora of technologies I’d have preferred to dominate: Pascal and LISP being two big examples. But the C64 wasn’t a lisp machine and people aren’t writing modern software in Pascal. So they’re completely moot to the conversation.
- anthk 7mo ago
  They were different but both came in-ROM and with similar storage options (cassette/floppy). On Pascal, Delphi was used for tons of RAD software in the 90's, both for the enterprise and for home users with zillions of shareware (and shovelware). And Lazarus/FPC+SQLITE3 today is not bad at all. On Lisp... it was used on niche places such as game engines, Emacs -Org Mode today it's a beast-, a whole GNU supported GNU distro (Scheme) and Maxima among others. Still, the so called low-level C++ it's an example on things picking the wrong route. C++ and QT5/6 can be performant enough. But, for a roguelike, the performance on compiling it's atrocious and by design Go with the GC would fix a 90% of the problems and even gain more portability.
  - hnlmorg 7mo ago
    I’m very aware of Lazarus, Delphi and Emacs. But they’re exceptions rather than industry norms. And thus pointing them out misses the point I was making when, ironically, I was pointing out how you’re missing the original point of this discussion.
    - anthk 7mo ago
      My point was about performance. Yes, Basic vs Forth was the worst choice back in the day, and you could say low level stuff was done under assembler. Fine. But the correct choice for 'low level' stuff it's C++ and I state that most of the C++ compilers have huge compiling times for software (GCC), or much better but they still eat ram like crazy (clang) and except for few software, the performance boost compared to Go doesn't look as huge for mosts tasks except for Chromium/Electron and QT. For what software it's doing a 90% of the time, Go + a nice toolkit UI would be enough to cover most tasks while having a safe language to use. Even for bloated propietary IM clones such as Discord and Slack. Because, ironically, most of the optimized C++ code is to run bloated runtimes like Electron tossing out any C++ gives to you, because most Electron software it's implementing half an OS with every application. With KDE and QT at least you are sharing code, even by using Flatpak, which somehow deduplicates stuff a little bit. With Electron you are running separate, isolated silos with no awareness of each other. You are basically running several 'desktop environments' at once. You can say, hey, Go statically builds everything, there's no gain on shared libraries then... until you find the Go compiler can still do a better job using less RAM than average than tons of stuff. With Electron often you are shipping the whole debugging environment with yourself. Loaded, and running graphical software with far less performance than the 'bloated' KDE3 software back in the day doing bells and wistles under a Kopete chat window under an AMD Athlon. QT3 tools felt snappy. Seeing Electron based software everywhere has the appeal of running everything GUI based under TCL/Tk under a Pentium modulo video decoders and the like. It will crawl against pure Win32/XLib under a Pentium 90 if everything it's a TK window with debugging options enabled. So, these are our current times. You got an i7 with 16GB of RAM and barely got any improvement with modern 'apps' over an i3 with 2GB of RAM and native software.
      - 7mo ago
- pjmlp 7mo ago
  You could get structured basic when using CP/M.
  - hnlmorg 7mo ago
    Again, even the crappy ROM versions on 8bit micros supported structured execution flow and functions. Just because it wasn’t a commonly known feature doesn’t mean it wasn’t supported.
    - pjmlp 7mo ago
      Which one? C64 and Speccy not really, they were unstructured, and functions were one liners.
      - hnlmorg 7mo ago
        Microsoft BASIC was the crappiest BASIC in my experience and the C64 shipped a hugely outdated version of Microsoft BASIC. But even there, you had a few options for structuring your programs beyond one liners. GOSUB was used for subroutines DEF could create a function (limited to one line but they could be nested to allow more complex functions spanning multiple lines) Then you had the obvious instructions for iteration, such as FOR Apple BASIC, BBC Basic (BBC Micro) and Locomotive BASIC (Amstrad CPC) all supported enhancements for composing functions and subroutines. But the latter two are European systems to Americans missed out there. The ZX Spectrum had been only the quarter of the memory of the C64 and was an intentionally budget device. So don’t expect any thrills there. But even that would have supported at least GOSUB. I’m not going to argue that structured programming in BASIC was pretty. Because it wasn’t. But that doesn’t mean it wasn’t possible.
        pjmlp 7mo ago
        Except doing it with line numbers and direct jumps wasn't structured, was faking it. You can be creative with jumps outside FOR...NEXT, and line numbers. Likewise GOSUB might not necessarily flow back as expected if the programmer gets creative. There is a reason a certain famous article existed. Or arrow diagrams for execution flow for that matter. QuickBasic, QBasic, HP Basic, AMOS, Turbo BASIC, S-BASIC, GFA BASIC, Acorn Basic, now those yes.

by anthk 7mo ago

hnlmorg 7mo ago

Most dialects of BASIC actually had functions too. They just weren’t popularised because line numbers were still essential for line editing on home micros. > On speed, Forth for the ACE was faster than Basic running under the ZX80. So, it wasn't about using a text-parsed language. Forth and BASIC are completely different languages and you’re arguing a different point to the one I made too. Also I don’t see much value in hypothetical arguments like “if Forth won instead of BASIC” because it didn’t and thus we are talking about actual systems people owned. I mean, I could list a plethora of technologies I’d have preferred to dominate: Pascal and LISP being two big examples. But the C64 wasn’t a lisp machine and people aren’t writing modern software in Pascal. So they’re completely moot to the conversation.

anthk 7mo ago
They were different but both came in-ROM and with similar storage options (cassette/floppy). On Pascal, Delphi was used for tons of RAD software in the 90's, both for the enterprise and for home users with zillions of shareware (and shovelware). And Lazarus/FPC+SQLITE3 today is not bad at all. On Lisp... it was used on niche places such as game engines, Emacs -Org Mode today it's a beast-, a whole GNU supported GNU distro (Scheme) and Maxima among others. Still, the so called low-level C++ it's an example on things picking the wrong route. C++ and QT5/6 can be performant enough. But, for a roguelike, the performance on compiling it's atrocious and by design Go with the GC would fix a 90% of the problems and even gain more portability.
- hnlmorg 7mo ago
  I’m very aware of Lazarus, Delphi and Emacs. But they’re exceptions rather than industry norms. And thus pointing them out misses the point I was making when, ironically, I was pointing out how you’re missing the original point of this discussion.
  - anthk 7mo ago
    My point was about performance. Yes, Basic vs Forth was the worst choice back in the day, and you could say low level stuff was done under assembler. Fine. But the correct choice for 'low level' stuff it's C++ and I state that most of the C++ compilers have huge compiling times for software (GCC), or much better but they still eat ram like crazy (clang) and except for few software, the performance boost compared to Go doesn't look as huge for mosts tasks except for Chromium/Electron and QT. For what software it's doing a 90% of the time, Go + a nice toolkit UI would be enough to cover most tasks while having a safe language to use. Even for bloated propietary IM clones such as Discord and Slack. Because, ironically, most of the optimized C++ code is to run bloated runtimes like Electron tossing out any C++ gives to you, because most Electron software it's implementing half an OS with every application. With KDE and QT at least you are sharing code, even by using Flatpak, which somehow deduplicates stuff a little bit. With Electron you are running separate, isolated silos with no awareness of each other. You are basically running several 'desktop environments' at once. You can say, hey, Go statically builds everything, there's no gain on shared libraries then... until you find the Go compiler can still do a better job using less RAM than average than tons of stuff. With Electron often you are shipping the whole debugging environment with yourself. Loaded, and running graphical software with far less performance than the 'bloated' KDE3 software back in the day doing bells and wistles under a Kopete chat window under an AMD Athlon. QT3 tools felt snappy. Seeing Electron based software everywhere has the appeal of running everything GUI based under TCL/Tk under a Pentium modulo video decoders and the like. It will crawl against pure Win32/XLib under a Pentium 90 if everything it's a TK window with debugging options enabled. So, these are our current times. You got an i7 with 16GB of RAM and barely got any improvement with modern 'apps' over an i3 with 2GB of RAM and native software.
    - 7mo ago
pjmlp 7mo ago
You could get structured basic when using CP/M.
- hnlmorg 7mo ago
  Again, even the crappy ROM versions on 8bit micros supported structured execution flow and functions. Just because it wasn’t a commonly known feature doesn’t mean it wasn’t supported.
  - pjmlp 7mo ago
    Which one? C64 and Speccy not really, they were unstructured, and functions were one liners.
    - hnlmorg 7mo ago
      Microsoft BASIC was the crappiest BASIC in my experience and the C64 shipped a hugely outdated version of Microsoft BASIC. But even there, you had a few options for structuring your programs beyond one liners. GOSUB was used for subroutines DEF could create a function (limited to one line but they could be nested to allow more complex functions spanning multiple lines) Then you had the obvious instructions for iteration, such as FOR Apple BASIC, BBC Basic (BBC Micro) and Locomotive BASIC (Amstrad CPC) all supported enhancements for composing functions and subroutines. But the latter two are European systems to Americans missed out there. The ZX Spectrum had been only the quarter of the memory of the C64 and was an intentionally budget device. So don’t expect any thrills there. But even that would have supported at least GOSUB. I’m not going to argue that structured programming in BASIC was pretty. Because it wasn’t. But that doesn’t mean it wasn’t possible.
      - pjmlp 7mo ago
        Except doing it with line numbers and direct jumps wasn't structured, was faking it. You can be creative with jumps outside FOR...NEXT, and line numbers. Likewise GOSUB might not necessarily flow back as expected if the programmer gets creative. There is a reason a certain famous article existed. Or arrow diagrams for execution flow for that matter. QuickBasic, QBasic, HP Basic, AMOS, Turbo BASIC, S-BASIC, GFA BASIC, Acorn Basic, now those yes.