ST BASIC Type-Ins?

[project7800]

18 hours ago, prog99 said:

Ah, here we go.

 

Ah! This one is in Fast BASIC. I haven't tried that one, yet. It seemed pretty popular in the UK, however. It sounds worth looking up as I understand it had an in-line assembler. 

 

[jefffulton]

13 minutes ago, project7800 said:

Thanks, I actually just found Compute!'s First Atari ST book. I review I read in STart said it had several ST BASIC type-ins. It's in the mail as we speak. Looks promising!

It's available digitally too I'm pretty sure.  Take a look here for more: 

https://archive.org/search.php?query=compute atari st

[ParanoidLittleMan]

11 hours ago, lp060 said:

Regardless if you "feel" they were necessary, line numbers are in fact overhead and less intuitive, it does not change the facts. I know how interpreters work internally, made a study of that on both platforms. The interpreter has to search for the line number and you are trying to tell me that is not overhead? Seriously? A couple of 8-bit basic interpreters use tricks to overcome this overhead by converting line numbers into pointers at run time.

What is your problem ? Mixed up some time lines ? I did not say that they were necessary. What  I  wanted to say is that it was simpler than using labels.

What you do is just attacking some old solutions on very limited (slow, little RAM size) computers. Maybe some better way was possible even with limited RAM/ROM and computing power. What is really limited is human imagination, ability to invent something new, according  to just arrived new technology - especially in short time. It is always easy to be 'smart after battle' - and you do exactly that.

Line numbers were good solution, and perfectly suitable for type ins.

[lp060]

5 hours ago, ParanoidLittleMan said:

What is your problem ? Mixed up some time lines ? I did not say that they were necessary. What  I  wanted to say is that it was simpler than using labels.

What you do is just attacking some old solutions on very limited (slow, little RAM size) computers. Maybe some better way was possible even with limited RAM/ROM and computing power. What is really limited is human imagination, ability to invent something new, according  to just arrived new technology - especially in short time. It is always easy to be 'smart after battle' - and you do exactly that.

Line numbers were good solution, and perfectly suitable for type ins.

No problem here. There's no other way to interpreter "Line numbers in early BASIC were not overhead." If you wanted to say "it was simpler than using labels" you should of said it. Still it changes nothing, my facts remain the same. So now I'm attaching old solutions. That's funny. I lived through that era, used them machines and many of those languages. BASIC by design had line numbers to facilitate jumps, not to ease your type in experience. Just so happens the line numbers where handy for printed listings.

 

Those so called "very limited (slow, little RAM size) computers" also had 6502 assembler, 'C', Forth, Pascal, and the Action programming language. None of which have line numbers. I should know, it was Action that freed me.

 

I guess you are unable to agree that line numbers are technically overhead, but would rather squabble over the semantics of some phrase. So it's now my fault you didn't write all that you should of wrote in a previous post. Typical.

 

 

Edited July 8, 2021 by lp060

[Tillek]

On 7/8/2021 at 2:27 AM, ParanoidLittleMan said:

Line numbers in early BASIC were not overhead. They served as labels for jumps (GOTO), for instance. Surely simpler to implement and interpret.

And they were useful exactly in case of typing in - better overview, and easy to see if some line was skipped during type-in.

I think you have a shallow understanding of what he was saying since you didn't carefully read what he said.

 

The key points are "by the end of the 8-bit era" and "moving away from a line number based language was a goal".

 

Followed by the 20-30 years of language evolution.

[Tillek]

On 7/8/2021 at 11:09 AM, zzip said:

Line numbers are a relic from when computers did not have the memory/storage to do full-sceen editors,  instead you had line oriented editors, so you needed a way to edit a line you already entered.   Line 30 is wrong?   Type "30" and a new line, and it gets replaced.   Some computers like the Atari 8-bit would let you cursor up to an already displayed line 30 and change it,  but as long as 30 was there, your edits would replace the existing 30.

 

The 16-bit computers had enough memory that you could edit the entire program in a free-form text editor and you no longer needed the line numbers.

But for some people, line numbers were an integral feature of BASIC and had trouble shifting out of that paradigm.   Also a whole generation learned programming on a line-oriented BASIC on a home computer and became way too reliant on GOTOs as a result.

I'd also venture to guess the line numbers in BASIC were about trying to reproduce the concept of the "program counter".

[Tillek]

On 7/8/2021 at 1:47 PM, ParanoidLittleMan said:

What is your problem ? Mixed up some time lines ? I did not say that they were necessary. What  I  wanted to say is that it was simpler than using labels.

What you do is just attacking some old solutions on very limited (slow, little RAM size) computers. Maybe some better way was possible even with limited RAM/ROM and computing power. What is really limited is human imagination, ability to invent something new, according  to just arrived new technology - especially in short time. It is always easy to be 'smart after battle' - and you do exactly that.

Line numbers were good solution, and perfectly suitable for type ins.

Actually, line numbers were not simpler than using labels.  It just shows a shallow understanding on your part.

 

Ask anyone who had to renumber a ton of lines in a basic program to insert something.

 

Something about your comments make me think of Arnold Palmer explaining the finer points of basketball to Kevin Love.  After all, many of these "very limited, slow, little RAM size" computers did have the higher level languages like C that didn't use line numbers (and I know LP060 just said that, but ... just wanted to make sure it sinks in).

[ParanoidLittleMan]

I was talking about what was used in most of Basic in middle 80-es of previous Century, and that line numbering was actually good for type-ins (what would be topic here, btw.) . And now we learned that line numbers were something so bad, that must point on it multiple times. Sure misters - those who want to type in some Basic will then have serious problems to add some new lines, even if usually line skip is 10 .

Congrats on finding something with what now feel superior, even if all it was constructed by force - like there were C compilers on some 8-bit machines. Yeah, that now means that all those people working on Basic years before C even existed were brainless idiots, who liked to make solutions what tortures people. 

Program counter is not good term - it shows not which in row is currently executed instruction, it shows actually address in memory (can be RAM or ROM) where instruction is located. Total length of instruction together with immediate data varies, so not same skip. And of course, it starts not in low RAM  (like address 10) in usual micros.  Line numbering is just simple system to have reference of some line.

[zzip]

19 hours ago, Tillek said:

Actually, line numbers were not simpler than using labels.  It just shows a shallow understanding on your part.

 

Ask anyone who had to renumber a ton of lines in a basic program to insert something.

 

Learning to code on BASIC with line numbers got me used to the idea that I could just goto any line in my program.   Moving to a BASIC without line numbers required a shift in thinking (I can't just GOTO anywhere anymore?)  In reality I wouldn't want to do that anyway.   Now I just had to figure out the areas where I would want my GOTOs to land and slap a label on it.   Better yet, skip the GOTOs and learn to use subroutines.

[gokmase]

On 7/11/2021 at 7:48 PM, Tillek said:

I'd also venture to guess the line numbers in BASIC were about trying to reproduce the concept of the "program counter".

That is an interesting idea, I never thought about it that way.
But that comparison isn't at all a bad allegory - from my point of view the line numbers in earlier/primitive Basic dialects can absolutely be seen as high level languages' equivalents to program counter in machine code, posing as exact references to where you are currently located in the program flow.

I made my first attempts at programming around 1984 with a Swedish Z80-based computer (ABC80) which had a Basic interpreter built into ROM. Needless to say, like most Basic versions at the time it was based on the concept of line numbers. At the time I didn't know of any alternatives but I sure recall the hassle of renumbering segments of code in order to be able to insert new code in between existing row numbers. The first time I tried to pick up Basic programming after I had bought my first Atari I quickly found out that none of the Basic alternatives that were any good (and that were at my disposal) used a line number based approach, so that presented a somewhat cumbersome threshold to get past for me.

The usage of line number based coding hadn't really encouraged me as a coder to get a proper feel for program flow, so that was something I later on had to battle a bit with to improve. So my take on explaining the biggest downside with line number based coding to someone that never tried it - it is a concept that is very far from being ideal when it comes to writing well structured code. Especially for beginners, it is in my opinion much too easy to end up writing spaghetti-like code and make a bad habit out of it.

Once I had adjusted to manage without the line numbers, there was absolutely nothing about them that I felt I was missing. If I'd ever power up my ABC80 (Yes, I still have it!) today and try to do any programming with it, there wouldn't be much choice though. The Basic of ABC80 resides in ROM and its 16kb of RAM certainly isn't enough to soft load a more modern programming solution (if that would even exist) and be able to create anything with it.
The only incitement for me to do that would be to create a moment of nostalgia, revisiting my first computing experience. As a way to achieve that, I'd accept the line number approach since that would be part of the retro experience.

But from a general (Basic) programming point of view I am inclined to say that line number based programming is only the best option when there are no alternatives.

[walter_J64bit]

On 7/1/2021 at 4:14 PM, zzip said:

I think Compute! magazine published some, I think they also had a separate publication "Atari ST Gazette"

 

Atari ST Basic is just not very good for general purpose stuff, which I think is why you won't see a lot of listings for it.   I remember some magazine like Antic published type-ins in other languages instead, like C.

Yes Compute! has them I recall looking at them when I was using my A8 at that time.

[ParanoidLittleMan]

Well, this went pretty much aside original topic - more posts about Basic variants self,  solutions. It is normal that it evolved - but printed program (sources) were published mostly in 80-es, little in 90-es, later practically nada. And magazines are much less spread, mostly because something better - Internet. No need for floppy disks, CDs ...

Btw. In Sinclair Basic you could use machine code subrutine calls (USR), and of course Basic subrutine calls.

Problem of adding some longer new code between 2 lines - quick solution can be to not add it there, but to end .

Then it would be like:

10 PRINT "HELLO 21st Century"

11  GOTO 3500

20 Whatever

....

3500 New code

....

4130 GOTO 20

Yeah, things can be solved in many ways . I still not saying that line numbers are something advanced, good for program writing, but that was used in those time, and as everything it can have it's good sides.