BASIC 2? Why not get BASIC 7?

[rje]

I had completely forgotten how terrible limiting two-character variables are.

It is SO EASY to lose track of them with programs larger than 4K.  By the time you get to 16K, you'd better have accompanying documentation kept up in good order... I think there must be a mental load function, here.

L(x) = (x / 4096) ^ 2

L(x) is the mental load incurred by a typical Commodore BASIC program of byte length x.

Its value is the probability that you'll forget a variable each time you add to the code.  A probability of 1 means you'll forget one variable.  A probability of 4 means you're going to forget four of them.

LOL

 

[rje]

So, here's the features of the BASIC transpiler that I'm using:

1. 
   Labels, not line numbers.
   
   
   
   • 
     And the labels can have a dot in them, so as to look like prototype-y subroutines.
     
   
   
   
   


2. 
   Long variable names.
   


3. 
   Multiple files.
   

It doesn't have while loops, and it doesn't have true procedure calls.

Just labels and long variables are a HUGE leap forward.  It makes programming 24K+ BASIC programs possible without the need for reference documents.

 

Current discipline uses files as modules, and I build labels with a module name as a prefix.  This adds even more readability / traceability to the source code.

 

[integer_basic]

18 hours ago, Cyber said:

 

 

[paulscottrobson]

14 hours ago, rje said:

So, here's the features of the BASIC transpiler that I'm using:

1. 
   Labels, not line numbers.
   
   
   
   • 
     And the labels can have a dot in them, so as to look like prototype-y subroutines.
     
   
   
   
   


2. 
   Long variable names.
   


3. 
   Multiple files.
   

It doesn't have while loops, and it doesn't have true procedure calls.



Just labels and long variables are a HUGE leap forward.  It makes programming 24K+ BASIC programs possible without the need for reference documents.



 



Current discipline uses files as modules, and I build labels with a module name as a prefix.  This adds even more readability / traceability to the source code.



 

Even if you can just write GOSUB update.display or something it improves readability of GOSUB 7730 so much it beggars belief.

[paulscottrobson]

19 hours ago, BruceMcF said:

Converting variables from two significant to variable width could be tricky, but changing the number of significant characters from two to four would be a substantial increase in ease of use and likely to be less challenging.



But the number one community pull improvement to the current CX16 Basic would to be upgrade the garbage collector from the C64 version to the C128 version, which is much faster when there is an appreciable number of string variables to collect garbage for.

It really depends how they've done it. Theoretically it shouldn't be too hard. The risks of introducing a near-impossible-to-track bug is very high thought, as it's terribly unmodular. In theory all the variable code could go in one independent module, the only complexity being DIM and that's just called whenever you encounter a variable and it returns a reference and type. In practice ..... compared to patching the command vector table  and calling eval it'd be a mess

[rje]

1 hour ago, paulscottrobson said:

Even if you can just write GOSUB update.display or something it improves readability of GOSUB 7730 so much it beggars belief.

It is a massive improvement in self-documenting code.  When I see

gosub {:display.update}

I know that not only is the display going to update, but that the subroutine can be found in the file module-display.list.

[paulscottrobson]

32 minutes ago, rje said:

It is a massive improvement in self-documenting code.  When I see

gosub {:display.update}

I know that not only is the display going to update, but that the subroutine can be found in the file module-display.list.

The problem with it is if you just crossdev you get away from the original point of the design - I thought - to replicate the learning environment we had on our Spectrums/C64/BBC Micros etc without the downsides (mostly storage before disk drives). You might as well design a console type design.

[Michael Parson]

7 hours ago, paulscottrobson said:

The problem with it is if you just crossdev you get away from the original point of the design - I thought - to replicate the learning environment we had on our Spectrums/C64/BBC Micros etc without the downsides (mostly storage before disk drives). You might as well design a console type design.

To quote the great philosopher, The Dude, "That's just like, your opinion, man." ?



Cross-dev has been a thing for a long time.  Lots of MS-DOS dev work was reportedly done on UNIX until DOS was self hosting (was it *ever* self hosting?).  Quite often, initial development of new systems is done on the previous generation using simulators of the new components until the design is ready to be sent off for the next level of prototyping.



Yeah, a lot of dev work was done on the real hardware, but a lot of it was done on bigger/other systems and maybe only the fit, finish, and polish done closer to it being ready to release.



In any case, I see this transpiler being a modern & updated version of how I wrote stuff on the C-64 back in the 80s, start on paper with a general design/flow, maybe a few lines of hand-written code in a notebook, maybe even whole programs written out in long hand while away from the keyboard, surrounded by reference books.  Type it in, some parts work, some parts don't.  Looking at the code on the screen, we only had 40 columns and 25 lines, the program was probably longer than that, possibly much longer, and if it was in BASIC, no back-scroll, so, either LIST and hold down CTRL to slow down the output until you see what you're looking for and try and hit RUN/STOP before it scrolls past, or look at in chunks with LIST 100-200, nope, not there, LIST 200-300, ad nauseam.  Oh it might be in this chunk, or the chunk it calls, or somewhere inbetween. Print it out on the tractor feed dot-matrix, back to working with a pile of paper, your pencil, and the reference material.

Ah, the good ole days.

Here, instead of a bunch of paper and a pencil, you're getting closer to the code in a text-editor.  Working like this, your transpiled code might get you close enough to done that you do your final work on the end system and possibly back-port those fixes to the transpiler format for future versions/improvements.

Writing a transpiler/compiler is cool, and not a small task.  It requires knowledge of not only the target language and all of its idiosyncrasies, but of the language(s) you're writing the transpiler in.

Cross-dev doesn't magically make the target system do things it can't otherwise do, we're still dealing with the limitations of the target (hell, even the limitations of the system you're doing the dev work on, compilers/transpilers/etc aren't perfect either).



The only wrong way to do it is the way that doesn't work.

[paulscottrobson]

I don't have a problem with cross development, and I wrote a transpiler professionally thirty years ago (which could do way more complex things and had to generated readable editable code) for exactly the same reasons. Difficult to measure the exact speed up, but on a similar project French colleagues were doing 2 reports a day and I could do one in about half an hour :)

Cross development on an X16 is entirely sensible for the same reasons that it was when people were developing professionally for C64s and Sinclair Spectrums, after the first year or so, anyway. I've written a couple of X16 compilers which I'm not happy with for various reasons, mostly connected with having to downgrade the compiler to fit the system.

My 'opinion' is that almost nobody at all will program the system in any other way. I'm not actually convinced anyone will program it at all like the old cross dev systems where there was a physical download connection. I think they'll develop it on the emulator, and occasionally run it on the system.

[Michael Parson]

7 hours ago, paulscottrobson said:

My 'opinion' is that almost nobody at all will program the system in any other way. I'm not actually convinced anyone will program it at all like the old cross dev systems where there was a physical download connection. I think they'll develop it on the emulator, and occasionally run it on the system.

That is a valid point.  And while I'm a HUGE fan of this project, and will probably buy one, honestly, I'm not sure how much I'll actually use it.  I've never been a huge video game player.  Over the years, I've built a collection of lots of games for most of the systems I've owned over the years, but only a handful of them ever got played repeatedly, and a small subset of them got any regular play. My Steam library has close to 300 games in it, mostly stuff I bought as part of HumbleBundle "Support the independent developers bundles," a few I bought individually from the Steam store directly, but I have only played less than a dozen of them, and maybe half of them repeatedly.

As it is, I'll have to do some re-arranging of stuff on my desk to even make room for a new system.

This is one of the reasons I like the MiSTer setup, it's small and doesn't take up a lot of room on my desk.  If it didn't have networking and required that I pull the SDdard out to change the contents, it would probably get less use than it does. If they ever get tun/tap or even SLiRP networking working to the point that we can use the networking from the running cores, I might use it even more.

Similarly, If the X-16 winds up with some sort of networking, or even a usable rs232 serial port that I can hang off the back of my Linux box, and can use a terminal emulator to connect to remote systems and do file transfers with, it will improve the odds of me using it more.

Even before I saw his channel, I had often fantasised about having a mini retro-computing museum in my house similar to Perifractic's.  Maybe once all the kids are grown and have moved out I can set it up in one of their rooms, though I'm not sure my wife would be as understanding as Ladyfractic. :)