If I were to refactor this code, I'd first make a good set of automated tests, by recording the input and output of a series of games. If you go through many stages of refactoring, these tests will save you a lot of time.

I'd be tempted to toss that into QBasic where it might reasonably run. Then start renaming variables and creating functions in QBasic. Slowly turning it into a modern program but have it run at each stage.

The code looks like the ones from C64. I used to write C64 Basic when I was 5 to 10 years old. (Later my father bought me an Amiga 500 and I started to play around 68000 assembly with MSeka assembler. There was also a C compiler, but there wasn't any documentation about C and the libraries. So I didn't choose to learn C with trial and error. Also there wasn't any Internet... Assembly was so much easier and logical to me at those days.)

But at some time, my C64's tape recorder broke. And I couldn't save the programs I wrote. So, programming to me was, waking up in the morning, start writing some program and playing with it, and in the evening when I switched off the power button everything would be gone. But I loved to play with my C64 :)

At those days, sometimes I even wrote very long programs. But I must admit that, when I see those 322 lines, it really frightened me now! It's looks like a million line C or Java codebase to me. I have no intention to refactor that code at all.. But I agree it would be fun.

Sounds like fun https://github.com/newmana/haunted-house

One of the biggest hurdles for me is the inability to have arrays of structs. You have to have multiple arrays of atomic types, and keep the indexes in synch. Maybe that's not a problem here. I collect old basic books and enjoy the nostalgia as you seem to :)

Back then everything was mainly numeric arrays then a mid$ (substr) lookup for the card names...

yeah, I could remaster the logic a lot simpler with with all the modern syntax. Maybe should draft out the original logic and rebuild from there, certainly a lot of variables and odd jumps to sort out.

Ive seen some articles on a more realistic card shuffle routine, etc. Also the games book suggests going for a three deck cardset would be more accurate as well..

I love looking at old BASIC code. I remember learning it on a TI 99/4A, then an Apple IIe a few years later.

Recommend you port it to Python, as a command line / console app. Command line would make it simpler to keep the "spirit" of the original.

I took a few minutes to see how difficult it would be just regexing a bunch of lines into something like JavaScript. At first it was pretty clear, but then wow... I forgot how insane GOTOs were! How anyone could follow a program like that amazes me.

If you look at it they are doing the job of extended if then/else or switch commands, just in reverse. What gets me is all the gosubs... :-D Seems like everyone was doing them to make the programs look smarter.

Related question... Is early BASIC the best we could do with all of our modern programming experience? If we were teleported back in time, knowing everything we do now, what could we accomplish in the same hardware constraints, language design wise?

Some really basic concepts weren't even realized back then one big one is hypertext - its not really a complex thing when you think about it but undiscovered then.

At the time many folks were graduating from cassette/paper tape to floppy disk, so random text file usage was kind of a new thing to many micro owners, text files were there but mainly used to store program variable data. Other concepts like compression, graphics formats, remote updating, distributed data, etc. were in their infancy.

I would think someone going back there would have an advantage, they may have to learn the old languages then build a whole lot of tools, but they would know more advanced end results which is a lot better then trial and error to reach those points originally.

Hypertext was in the Mother of All Demos in 1968:

https://en.wikipedia.org/wiki/The_Mother_of_All_Demos

I think it would be difficult for anyone that currently develops software for the web to truly get that whole era. 4k of memory.... 4k. I have people telling me that I'm prematurely optimizing things all the time. "Memory is cheap". If they knew they had 4k, every step of the way would be an optimization. All variables would be named a letter. No garbage collection because we'd be mallocing every single byte and mfreeing it asap. I really am wracking my brain to think of a concept that we have that we could have had in the 80's. Most of the greatest things are because we had CPU cycles and memory to burn.

Toys - a few years back some toy manufacturer was looking for some 6502 coders to work on a toy, had gobs of ROM storage (for code and audio) but only 256 bytes of RAM to work with.

Many of the early systems were made in a very short amount of time by a very small number of people who had remarkably bad tools.

I wrote code (pre-STL) for linked lists, sorted arrays, array lookups, and everything. And without modern languages (like C#!), I had to fight with not screwing up pointers.

Refactor QBASIC code instead and keep your sanity: http://www.jefflewis.net/programming-qbasic-blakjak.html#sou...

a few years ago, i contributed a guest ruby quiz that involved translating the old basic HAMURABI game into ruby. it was a pretty fun exercise - you can see the challenge and a few solutions here: http://rubyquiz.strd6.com/quizzes/223-hamurabi

Oh the days when I used to copy code out of books on my TI-99/4A...