3 ms·

Back the day people had BASIC and some machines had Forth and it was like print "Hello world" or ." Hello world " / .( Hello world ) for Fo

by anthk 7mo ago

Back the day people had BASIC and some machines had Forth and it was like print "Hello world" or ." Hello world " / .( Hello world ) for Forth. By comparison, giving how they optimized the games for 8 and 16 bit machines I should have been able to compile Cataclysm DDA:BN under my potato netbook and yet it needs GIGABYTES of RAM to compile, it crazy that you need damn swap for something it required far less RAM 15 years ago for the same features. If the game was reimplemented in Golang it wouldn't feel many times slower. But no, we are suffering the worst from both sides of the coin: something that should have been replaced by Inferno -plan9 people, the C and Unix creators and now Golang, their cousin- with horrible compiline times, horrible and incompatible ABI's, featuritis, crazy syntax with templates and if you are lucky, memory safety. Meanwhile I wish the forked Inferno/Purgatorio got a seamless -no virtual desktops- mode so you fired the application in a VM integrated with the guest window manager -a la Java- and that's it. Limbo+Tk+Sqlite would have been incredible for CRUD/RAD software once the GUI was polished up a little, with sticky menus as TCL/Tk and the like. In the end, if you know Golang you could learn Limbo's syntax (same channels too) with ease.

hnlmorg 7mo ago
BASIC was slow in the 80s. Games for the C64 (and similar machines) were written in machine code. > By comparison, giving how they optimized the games for 8 and 16 bit machines I should have been able to compile Cataclysm DDA:BN under my potato netbook and yet it needs GIGABYTES of RAM to compile, it crazy that you need damn swap for something it required far less RAM 15 years ago for the same features. That’s not crazy. You’re comparing interpreted, line delimited, ASCII, with a compiler that converts structured ASCII into machine code. The two processes are as different to one another as a driving a bus is to being a passenger on it. I don’t understand what your point is in the next two paragraphs. What Go, TCL, UNIX nor Inferno have to do with the C64 or modern software. So you’ll have to help out there.
- 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.
- pjmlp 7mo ago
  Some BASIC was slow, Darthmouth BASIC was compiled to machine code before execution, and to make it fit as the machine shell on 8 bit computers, the only option available on ROM was an interpreter. Machines using CP/M had BASIC compilers available, and professional devs had the option to buy BASIC compilers for 8 and 16 bit home computers, when the 16 bit home computers came to be, BASIC compilers became common again. It was only during the glory 8 bit days, with most users being students with limited budgets, and the pain of switching tapes all the time, that made using BASIC compilers a no go option for most, thus we ended up using DATA blocks for Assembly code within our budget, or if lucky to get a hexdump monitor or proper Assembler, use those instead.
  - hnlmorg 7mo ago
    I’m aware you can compile BASIC but we aren’t talking about those systems. We are talking specifically about the ones which you just admitted were slow.

by anthk 7mo ago

hnlmorg 7mo ago

BASIC was slow in the 80s. Games for the C64 (and similar machines) were written in machine code. > By comparison, giving how they optimized the games for 8 and 16 bit machines I should have been able to compile Cataclysm DDA:BN under my potato netbook and yet it needs GIGABYTES of RAM to compile, it crazy that you need damn swap for something it required far less RAM 15 years ago for the same features. That’s not crazy. You’re comparing interpreted, line delimited, ASCII, with a compiler that converts structured ASCII into machine code. The two processes are as different to one another as a driving a bus is to being a passenger on it. I don’t understand what your point is in the next two paragraphs. What Go, TCL, UNIX nor Inferno have to do with the C64 or modern software. So you’ll have to help out there.

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.
pjmlp 7mo ago
Some BASIC was slow, Darthmouth BASIC was compiled to machine code before execution, and to make it fit as the machine shell on 8 bit computers, the only option available on ROM was an interpreter. Machines using CP/M had BASIC compilers available, and professional devs had the option to buy BASIC compilers for 8 and 16 bit home computers, when the 16 bit home computers came to be, BASIC compilers became common again. It was only during the glory 8 bit days, with most users being students with limited budgets, and the pain of switching tapes all the time, that made using BASIC compilers a no go option for most, thus we ended up using DATA blocks for Assembly code within our budget, or if lucky to get a hexdump monitor or proper Assembler, use those instead.
- hnlmorg 7mo ago
  I’m aware you can compile BASIC but we aren’t talking about those systems. We are talking specifically about the ones which you just admitted were slow.