That entire era in Microsoft products, MSVC 6.0, Office 97 and bit later w2k was quite special: linear progress from earlier windows things, but not yet in that cycle of change for the sake of change, that is never really complete so you always get a wild mix (arguably w2k already contained first glimpses of that with its service control panels that felt a little alien to the rest)
(ps: change for the sake of change is not quite all that I meant, it's not just that "new UI language every five years", but also those great API revolutions that came independent of looks. Those are certainly far more well-founded than just "for the sake of change", but suffer from coexistence with their predecessors nonetheless. win32 as an evolution of win16 and optionally wrapped in MFC, that might have been error-prone and complicated to write for, but it does have a certain clarity that no successor can claim as long as compatibility remains the product)
It's been a long time since I programmed in BASIC, but I have gone memories of it.
My very first computer was a Commodore Vic20, whose User's Manual was essentially a BASIC manual. One of the very first programs I learned to wrote drew a simple bird on the screen made by characters and made its wings flap. I was mesmerised.
The VIC-20 Programmers Reference was also a great next step, to get you into assembly/machine language. There wasn't a good freely-available assembler, so you get to become the assembler itself, POKEing instructions into memory.
I started out on the C64, but that manual, too, received much love from me. I read it until it pretty much fell apart. Oh, well, the spiral binding might also have had something to do with that ;-)
My wife's Toshiba laptop was bought in 2005 and still works. It's a 32-bit machine with just 1–2 GB of memory, but I put a SSD a few years ago and with this setup Linux runs fine. I still use it sometimes, as it's the smallest laptop we have in our house and it's handy to use it while in bed for browsing and checking mail.
Borland Pascal 7 had a chess engine implementation in the EXAMPLES directory. There were two frontends in the same directory: one used OWL to provide a graphical interface in Windows, the other one was for MS-DOS (character-based) using the Turbo Vision library, and it was pretty awesome!
When my dad found a box full of old floppies in the back of a drawer, I bought a USB floppy drive and was able to backup all the data in them: some of them contained my very first programs written in Turbo Pascal 3.0 and GW-BASIC.
USB floppy drives are quite cheap to buy, and in my case it was totally worth the money!
I didn't know this project existed, but that controversy on the license made me curious, and I have had a look at the repository. I stumbled upon this discussion, which shows another controversial decision by the new maintainer regarding the way disk files are managed by the emulator:
He’s not “the new maintainer,” he’s “one maintainer” but he decided he knew better than everyone else. Hence why the official SIMH repository is at open-simh.
There wasn’t “out-of-band harassment,” there were people calling out his toxicity and unilateral negative changes that he kept doubling down on. And no matter how many contributions he’s made, it’s always been Supnik’s project.
I was able to convince my coworkers to stop working on a Python project (a simulator for a scientific instrument) once we all realised that we would have not been able to keep using plain Python because of performance. When the alternatives where (1) to force everybody to learn either C or Fortran, or (2) to rewrite everything in Julia, they asked me to provide examples of both solutions. After I showed them a few different approaches (pybind, cbind, f2py...), there was full consensus for Julia. We moved what we implemented so far (it was not to much, luckily), and so far nobody has regretted the choice.
The problem in using two languages is that you do not have just to learn a new language besides Python. You have also to figure out how to properly interface them. (f2py was considered the easiest solution, but we feared that the 1- vs 0-based array indexing would have likely caused many bugs.)
Did you evaluate Cython? I'm not anti-Julia, but I like that my Cython code is useable out of the box from Python, with no wrapping, and then users can continue to use their Jupiter + Python scripting workflows with performant bespoke modules complemented by the full Python ecosystem.
Someday I'll do a project in Julia. But for some such projects, Rust seems fully guaranteed to be performant while Julia might or might not be, so I might still lean towards Rust (unless one of the high quality packages of Julia removes a lot of development time, which is a decent possibility).
I used it for another project but was not impressed. When I tested it, the documentation was scarce, and the deployment is harder than Julia because it needs a working C compiler alongside the CPython interpreter.
