If I was making something that would be sold, I think I would do an embedded BASIC with WiFi access. I think that would be the most popular (maybe not the most useful).
Bean
Well, I guess PE-Basic on the new ActivityBoard WX with a Xbee Wi-Fi module would be all you'd need. All but the Wi-Fi module is already available. In fact, the Wi-Fi module we've been working on uses an ESP8266 chip which has space for user-written code. It might be possible to put the PropBASIC compiler on the ESP8266 and have it download generated code to the Propeller. The whole system wouldn't be hosted entirely on the Propeller but it would be all on a single ActivityBoard WX.
Well... I will NEVER be a real programmer but I can do some modifications to other spin programs. I dabble in Prop C and Tachyon but never got too far with either. But with Basic I have created useful programs for me using the BS2 fo my power chair. Havent run over my wifes cats tail since putting motion detectors on back of chair, Havent got into trouble in the outdoors with the tilt sensors either. All run by a BS2.
Now I would love a full featured Prop Basic for BOTH the P1 and esp the P2. I want to redo my setup with a Prop as I lost the source several years go in HD failure.
Thanks Bean and I hope very much Parallax supports this 100%
With the introduction of the Activity WX board, that could be an interesting board to target with your new embedded PE-Basic program. I would be interested in something like that if it ended up with a way of saving your PE-Basic program and maybe being able to run the saved program on another Propeller based board.
I mentioned on my other thread, a scripted option for PE-Basic. I have been working with Python script programs, and I find that to be a very useful solution. Now you could have an interactive session or you could create a script file.
If you do target the new Activity WX board, and it was mounted on a Bot, I think you might find some new users, if they were able to program and run there ActivityBot, especially if it was programed from a tablet. Just a few things for you to think about. Oh, almost forgot, you would really have to think about being able to create and run TASKS in there own COG(s), if that is even possible in your new scenario.
On the subject of the P2 if I write a Basic on top of Tachyon for the P1 then this will work just as well with the fast Tachyon for the P2 which I got up and running last year along with the FAT32 filesystem and Ethernet servers. Instant P2 Basic!
However I realize without meaning to that I am butting in on this thread so I will not mention anything further!
Man, you should incorporate a small LMM kernel to allow big programs on the P1. Just hide this from the user. It's just part of the primary COG running BASIC.
Then, your result will also move easily over to the P2, where big PASM is in the can and working nicely.
Add in-line PASM to that BASIC, and people have a pretty nice set of options to make fast code without having to get into all that many details. In-line would allow for the odd PASM snippet they want to incorporate and understand, while the BASIC being compiled would run quickly for the general case. Both together would give access to the many new features of the P2 without having to do the work of new keywords and use cases right away.
On the P1, the LMM kernel would allow similar things and bigger overall programs benefit everyone.
If I was making something that would be sold, I think I would do an embedded BASIC with WiFi access. I think that would be the most popular (maybe not the most useful).
SiLabs already have a Basic like script in their BlueGiga wireless family.
Some of these new RF parts are releasing with Dual cores, so the RF stack is in one, and the user has a whole separate core.
That certainly helps avoid user changes breaking the stack.
Native code is really restrictive because of the size (only 496 instructions), but it is really fast and required for video drivers and such.
LMM code is pretty fast, and large and seems like good method of "most" code.
I thought PropBASIC had a LMM type mode already ? Or have I confused another tool flow ?
On the subject of the P2 if I write a Basic on top of Tachyon for the P1 then this will work just as well with the fast Tachyon for the P2 which I got up and running last year along with the FAT32 filesystem and Ethernet servers. Instant P2 Basic!
That sounds good, can you elaborate further ? This would give what Speed/Size point for P1 and P2 ?
PropBasic does support building LMM not just PASM,
already done!
@Heater, why not BASIC?
@Peter Jakacki, the BASIC layer on top of Tachyon sounds interesting. The main problem people have with FORTH is the RPN. In all the examples you showed, I find the BASIC line way more readable as the FORTH line.
@Bean, you have a long run with PropBasic, still searching for a home in some Parallax supported IDE. I was not aware that the roots are the SX-Basic. WOW.
I do like the way it is working now, and manual splitting expressions into code lines might be cumbersome, but gives you also a good way to optimize things, while breaking the expression down. Like others mentioned I also see PropBasic as a sort of Macro-Assembler.
You mentioned that the source is not as nice as it would be if you write it new. But would it be possible to add the P2 Instructions needed to the current source and substitute LMM by HubExec? Having PropBasic on the P2 would be fantastic.
In fact, the Wi-Fi module we've been working on uses an ESP8266 chip which has space for user-written code. It might be possible to put the PropBASIC compiler on the ESP8266 and have it download generated code to the Propeller.
Where is the upgrade to the ESP8266 in the pipeline - The ESP32 ?
In fact, the Wi-Fi module we've been working on uses an ESP8266 chip which has space for user-written code. It might be possible to put the PropBASIC compiler on the ESP8266 and have it download generated code to the Propeller.
Where is the upgrade to the ESP8266 in the pipeline - The ESP32 ?
The Stamp users concept is a pretty good idea - to my definitely non-business mind, that seems like a user base ready and waiting for the Ultra Stamp. But then again, I think the Stamp may be a fairly profitable item for Parallax and they may not want to potentially negatively impact that product line.
I am _not_ using PropBasic, however thats because I've somehow missed the memo that it can work as a sort of ASM RAD tool. This piques my interest, and I would like to subscribe to your newsletter....
However, I will disagree with the comment regarding the BS being more profitable and this effort cannibalizing sales.
If Parallax does not make an attempt to cannibalize BS users to Prop users, then someone, or something else quite probably will. Much as I hate to quote Jobs, one of his reportedly shrewder beliefs I just read about re either iPod or iPhone was that he realized trying to keep users captive, one could either attempt to keep users by getting them to move forward/up to one of your other products, or risk losing them as a customer entirely.
Apple's Walled Garden, yadda yadda yadda... thats an ecosytem example.
Parallax has been shooting themselves in the foot for years now IMO by not throwing a few people some bones and getting some sort of supported BASIC going for that very large group of potentially interested tinkerers who could easily wrap their heads around such a simple language.
The Not Invented Here thing seems to be fading with the C push, which is great. But there are still many people who have tried learning it and failed or been discouraged with pointers, etc.
I really think a 5-10K Challenge years ago for a BASIC would have brought many, many more people to the fold. Yes, HAD and other sites would have had posters laughing at Prop as supporting such an 'obsolete' language. But Parallax would have been laughing all the way to the bank, and a lot of people who started at BASIC would have been more confident to take a stab at PASM or Spin.
I mean really. Parallax has numerous people on here doing all sorts of work for them free with editors, compilers, etc. Not taking more advantage of that is a real business opportunity lost.
Ouch, that got me thinking. I don't think either of my grand fathers were still alive when BASIC was invented. I was first introduced to programming, using BASIC, in 1973. So I guess for the purposes of this discussion I will have to be my own "Grandad"
My father taught himself how to program in BASIC when he retired, round about 1984.
I don't really have a downer on BASIC, it get's one started with programming concepts easily enough. Although in my case I was kind of done with it after a few months when I wanted to write an expression parser and realized it was going to be ugly and not so simple.
I did get MS 4K and 8K BASICS working on the Prop sometime back just for kicks. See PropAltair.
It's easy enough to 'apply 2016' to any Basic, to make it a modern language.
I am something of a Luddite when it comes to modernizing BASIC. If you are going to remove the line numbers, introduce structured programming features, and so on, then it is no longer BASIC in my book. Might as well invent a whole new language and give it a different name. Call it Pascal or Spin or something.
I kind of like the idea of a dead simple BASIC like syntax that compiles statements one for one into assembler. Especially if the whole system runs on the target machine.
I am something of a Luddite when it comes to modernizing BASIC. If you are going to remove the line numbers, introduce structured programming features, and so on, then it is no longer BASIC in my book.
By that yardstick, something that *compiles* is no longer BASIC either
Reality is, things like line numbers are less a 'language feature', than a compromise forced by the very small systems they ran on way-back-when.
Might as well invent a whole new language and give it a different name. Call it Pascal or Spin or something.
I'm fine with Pascal too, but this is a Prop BASIC thread.
To me, any MCU language should have reasonable PC hosted equivalents.
Spin scores ~zero there, whilst with BASIC, there is FreeBASIC which I use for simple test and demo scripts, but the better PC hosting is Lazarus/FreePascal.
With a blank sheet, I would favour Pascal over Basic, but PropBASIC already exists (in a quite polished form), as too does Basic Stamp, so an effort that can be comfortable in Basic Stamp / PropBASIC_p1,PropBASIC_p2, & FreeBASIC user ecosystems has merit.
Especially if the whole system runs on the target machine.
That's less important, as with a MCU, there often is no 'target machine' in any language development environment sense.
If you can build self-hosting, that can make for a nice demo, which is one appeal of System Oberon.
Personally, I rate Good Debug way ahead of self hosting .
By that yardstick, something that *compiles* is no longer BASIC either
I have to disagree.
A programming language is defined by it's syntax and semantics. How it gets implemented is a different matter. If I type code and then run it what do I care if it's interpreted of compiled or something in between (JIT). Practical issues like performance aside.
After all there are compiled BASICs and there is an interpreter for C++ !
Certainly line numbers seem to be a result of wanting to work on limited machines. But if you are going to program with GOTO you need labels. The labels may as well be numeric.
I think the main point there was being able to get an editor working easily in a small space. And perhaps on a teletype. Just type a new line with an existing line number and it replaces the old one. None of this full screen editing business.
I think BASIC is fine with labels. It's a minor change from the classic syntax, but a really easy one. Doesn't change anything much at all.
You still get nice things like "ON X GOTO LABEL1, LABEL2, etc... which compiles down to a nice, fast assembly structure.
The idea of simple assembly, statement at a time is a really good one, particularly when combined with inline. The old BBC BASIC is a great example of this. Skilled users end up using it as an assembler. Add a few basic directives, and it is one, if you want.
It's possible to get good speed / space / complexity trade offs, even on really small targets! I've mentioned this before, but it's worth it here: http://bataribasic.com/
That's a compiled 6502 BASIC. No room or capability on the target to be interactive. Target has 128 bytes of RAM, and a 4K primary address space. Banks and such can take that to something like 32K.
The author is here in PDX, and his approach worked amazingly well! Labels and such all work transparently with both the statements and inline code. I was able to download this and knock out a brickout game in a couple hours. The most interesting thing about it is the very limited core language. It has what you need and no more. If you want access to the special features, inline those. This turned out to be stupid easy.
Note, programming that target, the old Atari VCS or 2600, is considered some sort of rite of passage for assembly language programmers. It's a very challenging platform. No screen buffer, no interrupts, just a timer and a few registers needed to control the limited line oriented screen display. A little over 1Mhz clock.
An assembly project, like that same brickout game, could take a person weeks.
On the Prop, having a BASIC like this makes a TON of sense. It's not about portability, or any other modern thing. It is all about getting the code written in a lean, "you don't have to know much" sort of way. For a lot of people, this makes great sense. They've got a task, and they've broken it down into some sort of steps. From there, write it, and when it works, done! Next.
Line numbers are a PITA, and not really needed to preserve all the good aspects of BASIC. And yes, there are plenty of good aspects. It's not rocket science, yet capable of a lot, is likely the primary good in BASIC. And, we've seen over the years, it's very accessible to most people, so long as the syntax and overall capability are kept to minimums.
Also, on the Prop, it can be both compiled and interpreted, which is nice. Both have their merits and use cases. On the P2, it's probably going to make sense to just have the whole environment on there. Run the interpreter, and use it. Once it works, compile and it goes fast. Should all happen in a modest amount of space, and on a few COGS tops. Honestly, a person could do it on chip and get a sizable app, in terms of complexity and overall bytes needed, done with few hassles, other than making sure storage is sorted out.
Best thing is a person using a PC could do about the same thing with few overall differences in workflow.
Seems like a great niche to me. Bean could do a lot of good here.
The thing I've noticed is choices matter. A lean, fast language that only offers a few options can be learned and used quickly. The same language with a ton of goodies actually takes more time as there are more choices and the obvious path forward isn't always obvious. BASIC fits into that "get going and get it done" class of options that just don't take much to be useful to people.
Over time, those people will gain skill and seek out the goodies in other more powerful and expressive languages.
Think of it like real language. If you get the basics, say a thousand or so words, you can do a lot! From there, it's just adding a tool at a time, until you have greater mastery. This is how BASIC works, and it's a perfectly fine way for people to get access to and apply tech like this.
Reality is, things like line numbers are less a 'language feature', than a compromise forced by the very small systems they ran on way-back-when.
I don't think this is true. BASIC was originally written for a mainframe computer I believe. I'd be willing to bet that the same mainframe could run FORTRAN and COBOL so it wasn't so small as to require line numbers to simplify the compiler. I think the line numbers were to make things easier on beginners.
BASIC was originally written for a mainframe computer I believe. I'd be willing to bet that the same mainframe could run FORTRAN and COBOL so it wasn't so small as to require line numbers to simplify the compiler.
I believe BASICs line numbers were an essential part of it's interactive nature at the time.
It was a different world back then. When I arrived at university in 1976 they had an ICL mainframe as the sole computing resource for the entire comp. sci. department. With a bunch of teletypes and card/tape readers attached. There were no editors, how could there be on a teletype?
Yes one could compile FORTRAN and such on those main frames. I used ALGOL. But that was a tedious business involving punching card decks and submitting them to the operators to enter into the batch system for compilation. Often the results would come back next morning!
Ideas of multi-user interactive sessions were pretty new. That's just what you want for introducing dozens of students to programming. You could do it with that bunch of teletypes an interpreted language and a simple time sharing operating system. But how do you edit on a teletype? Easy, give every program line a line number. If the user makes an error he can just type that line again with the corrections. The interpreter keeps track of the ordering of everything entered in its memory.
Then we come to the early micro-computers. Pretty much the same problems. An Altair or MITS did not have a nice CRT monitor you could write an editor for. Even if there was enough memory to fit an editor in.
Enter Bill Gates and the 4K BASIC. Just what everyone needed to get going quickly with their otherwise useless lump of logic.
I think the line numbers were to make things easier on beginners.
Line numbers:
10 Start
15 DO something
20 GOTO 50
30 GOTO 10
40 DO something
45 GOTO 10
50 GOTO 30
Lets see spaghetti code, does that jog anybody's memory? Where is that box of blank punch cards?
That is why from very early on we were taught to design our programs first. Using flow charts, with some rules about "structure" or Nassi Shneiderman diagrams. That later of which look like modern day graphical programming in Scratch or Blockly etc.
Such design presentation was a required part of all our assignments and bigger projects.
Oddly, the introduction of structure programming languages, C, Pascal etc, the banishment of GOTO and so on did not stop people writing unintelligible code.
Then they invented object oriented programming and C++, all hope of comprehensibility was lost.
If I had to guess, I would say that line numbers came from the way the text editors worked back then.
Anyone remember EDLIN ? Whoa, flashback.... Using DEBUG to format a MFM harddrive.... Turbo Pascal 3.01....
Amstrad PC1512 with dual 360K floppies.... Connecting things to the printer port....
Good times.....Good times.....
Comments
I am looking to use this or similar with a Prop slave.
Now I would love a full featured Prop Basic for BOTH the P1 and esp the P2. I want to redo my setup with a Prop as I lost the source several years go in HD failure.
Thanks Bean and I hope very much Parallax supports this 100%
I mentioned on my other thread, a scripted option for PE-Basic. I have been working with Python script programs, and I find that to be a very useful solution. Now you could have an interactive session or you could create a script file.
If you do target the new Activity WX board, and it was mounted on a Bot, I think you might find some new users, if they were able to program and run there ActivityBot, especially if it was programed from a tablet. Just a few things for you to think about. Oh, almost forgot, you would really have to think about being able to create and run TASKS in there own COG(s), if that is even possible in your new scenario.
Ray
However I realize without meaning to that I am butting in on this thread so I will not mention anything further!
Then, your result will also move easily over to the P2, where big PASM is in the can and working nicely.
Add in-line PASM to that BASIC, and people have a pretty nice set of options to make fast code without having to get into all that many details. In-line would allow for the odd PASM snippet they want to incorporate and understand, while the BASIC being compiled would run quickly for the general case. Both together would give access to the many new features of the P2 without having to do the work of new keywords and use cases right away.
On the P1, the LMM kernel would allow similar things and bigger overall programs benefit everyone.
my .02
Are we still talking about BASIC ?
Some of these new RF parts are releasing with Dual cores, so the RF stack is in one, and the user has a whole separate core.
That certainly helps avoid user changes breaking the stack.
I thought PropBASIC had a LMM type mode already ? Or have I confused another tool flow ?
That sounds good, can you elaborate further ? This would give what Speed/Size point for P1 and P2 ?
PropBasic does support building LMM not just PASM,
already done!
@Heater, why not BASIC?
@Peter Jakacki, the BASIC layer on top of Tachyon sounds interesting. The main problem people have with FORTH is the RPN. In all the examples you showed, I find the BASIC line way more readable as the FORTH line.
@Bean, you have a long run with PropBasic, still searching for a home in some Parallax supported IDE. I was not aware that the roots are the SX-Basic. WOW.
I do like the way it is working now, and manual splitting expressions into code lines might be cumbersome, but gives you also a good way to optimize things, while breaking the expression down. Like others mentioned I also see PropBasic as a sort of Macro-Assembler.
You mentioned that the source is not as nice as it would be if you write it new. But would it be possible to add the P2 Instructions needed to the current source and substitute LMM by HubExec? Having PropBasic on the P2 would be fantastic.
Enjoy!
Mike
http://makezine.com/2015/12/09/meet-esp32-new-big-brother-to-iot-board-esp8266/
Seems a better target for this ?
@heater: tech never, ever goes away. What happens is people will center in on tech that works and when they are happy, they are happy.
In the end, kind sir, that trumps everything else.
At the risk of stating the obvious, yes ... and with great enthusiasm. I completely understand that many feel differently and that is cool, too.
Sure, but this is not your Grandad's Basic.
It's easy enough to 'apply 2016' to any Basic, to make it a modern language.
* Beta, limited to 200 modules, Starts Nov 2015.
* Mass production of ESP32 in April 2016
So quite close ?
I am _not_ using PropBasic, however thats because I've somehow missed the memo that it can work as a sort of ASM RAD tool. This piques my interest, and I would like to subscribe to your newsletter....
However, I will disagree with the comment regarding the BS being more profitable and this effort cannibalizing sales.
If Parallax does not make an attempt to cannibalize BS users to Prop users, then someone, or something else quite probably will. Much as I hate to quote Jobs, one of his reportedly shrewder beliefs I just read about re either iPod or iPhone was that he realized trying to keep users captive, one could either attempt to keep users by getting them to move forward/up to one of your other products, or risk losing them as a customer entirely.
Apple's Walled Garden, yadda yadda yadda... thats an ecosytem example.
Parallax has been shooting themselves in the foot for years now IMO by not throwing a few people some bones and getting some sort of supported BASIC going for that very large group of potentially interested tinkerers who could easily wrap their heads around such a simple language.
The Not Invented Here thing seems to be fading with the C push, which is great. But there are still many people who have tried learning it and failed or been discouraged with pointers, etc.
I really think a 5-10K Challenge years ago for a BASIC would have brought many, many more people to the fold. Yes, HAD and other sites would have had posters laughing at Prop as supporting such an 'obsolete' language. But Parallax would have been laughing all the way to the bank, and a lot of people who started at BASIC would have been more confident to take a stab at PASM or Spin.
I mean really. Parallax has numerous people on here doing all sorts of work for them free with editors, compilers, etc. Not taking more advantage of that is a real business opportunity lost.
My father taught himself how to program in BASIC when he retired, round about 1984.
I don't really have a downer on BASIC, it get's one started with programming concepts easily enough. Although in my case I was kind of done with it after a few months when I wanted to write an expression parser and realized it was going to be ugly and not so simple.
I did get MS 4K and 8K BASICS working on the Prop sometime back just for kicks. See PropAltair. I am something of a Luddite when it comes to modernizing BASIC. If you are going to remove the line numbers, introduce structured programming features, and so on, then it is no longer BASIC in my book. Might as well invent a whole new language and give it a different name. Call it Pascal or Spin or something.
I kind of like the idea of a dead simple BASIC like syntax that compiles statements one for one into assembler. Especially if the whole system runs on the target machine.
By that yardstick, something that *compiles* is no longer BASIC either
Reality is, things like line numbers are less a 'language feature', than a compromise forced by the very small systems they ran on way-back-when.
I'm fine with Pascal too, but this is a Prop BASIC thread.
To me, any MCU language should have reasonable PC hosted equivalents.
Spin scores ~zero there, whilst with BASIC, there is FreeBASIC which I use for simple test and demo scripts, but the better PC hosting is Lazarus/FreePascal.
With a blank sheet, I would favour Pascal over Basic, but PropBASIC already exists (in a quite polished form), as too does Basic Stamp, so an effort that can be comfortable in Basic Stamp / PropBASIC_p1,PropBASIC_p2, & FreeBASIC user ecosystems has merit.
Agreed, High Level Assembler is a lot more 'Microcontroller space', which is where P1 and P2 sit.
That's less important, as with a MCU, there often is no 'target machine' in any language development environment sense.
If you can build self-hosting, that can make for a nice demo, which is one appeal of System Oberon.
Personally, I rate Good Debug way ahead of self hosting .
A programming language is defined by it's syntax and semantics. How it gets implemented is a different matter. If I type code and then run it what do I care if it's interpreted of compiled or something in between (JIT). Practical issues like performance aside.
After all there are compiled BASICs and there is an interpreter for C++ !
Certainly line numbers seem to be a result of wanting to work on limited machines. But if you are going to program with GOTO you need labels. The labels may as well be numeric.
I think the main point there was being able to get an editor working easily in a small space. And perhaps on a teletype. Just type a new line with an existing line number and it replaces the old one. None of this full screen editing business.
You still get nice things like "ON X GOTO LABEL1, LABEL2, etc... which compiles down to a nice, fast assembly structure.
The idea of simple assembly, statement at a time is a really good one, particularly when combined with inline. The old BBC BASIC is a great example of this. Skilled users end up using it as an assembler. Add a few basic directives, and it is one, if you want.
It's possible to get good speed / space / complexity trade offs, even on really small targets! I've mentioned this before, but it's worth it here: http://bataribasic.com/
That's a compiled 6502 BASIC. No room or capability on the target to be interactive. Target has 128 bytes of RAM, and a 4K primary address space. Banks and such can take that to something like 32K.
The author is here in PDX, and his approach worked amazingly well! Labels and such all work transparently with both the statements and inline code. I was able to download this and knock out a brickout game in a couple hours. The most interesting thing about it is the very limited core language. It has what you need and no more. If you want access to the special features, inline those. This turned out to be stupid easy.
Note, programming that target, the old Atari VCS or 2600, is considered some sort of rite of passage for assembly language programmers. It's a very challenging platform. No screen buffer, no interrupts, just a timer and a few registers needed to control the limited line oriented screen display. A little over 1Mhz clock.
An assembly project, like that same brickout game, could take a person weeks.
On the Prop, having a BASIC like this makes a TON of sense. It's not about portability, or any other modern thing. It is all about getting the code written in a lean, "you don't have to know much" sort of way. For a lot of people, this makes great sense. They've got a task, and they've broken it down into some sort of steps. From there, write it, and when it works, done! Next.
Line numbers are a PITA, and not really needed to preserve all the good aspects of BASIC. And yes, there are plenty of good aspects. It's not rocket science, yet capable of a lot, is likely the primary good in BASIC. And, we've seen over the years, it's very accessible to most people, so long as the syntax and overall capability are kept to minimums.
Also, on the Prop, it can be both compiled and interpreted, which is nice. Both have their merits and use cases. On the P2, it's probably going to make sense to just have the whole environment on there. Run the interpreter, and use it. Once it works, compile and it goes fast. Should all happen in a modest amount of space, and on a few COGS tops. Honestly, a person could do it on chip and get a sizable app, in terms of complexity and overall bytes needed, done with few hassles, other than making sure storage is sorted out.
Best thing is a person using a PC could do about the same thing with few overall differences in workflow.
Seems like a great niche to me. Bean could do a lot of good here.
The thing I've noticed is choices matter. A lean, fast language that only offers a few options can be learned and used quickly. The same language with a ton of goodies actually takes more time as there are more choices and the obvious path forward isn't always obvious. BASIC fits into that "get going and get it done" class of options that just don't take much to be useful to people.
Over time, those people will gain skill and seek out the goodies in other more powerful and expressive languages.
Think of it like real language. If you get the basics, say a thousand or so words, you can do a lot! From there, it's just adding a tool at a time, until you have greater mastery. This is how BASIC works, and it's a perfectly fine way for people to get access to and apply tech like this.
It was a different world back then. When I arrived at university in 1976 they had an ICL mainframe as the sole computing resource for the entire comp. sci. department. With a bunch of teletypes and card/tape readers attached. There were no editors, how could there be on a teletype?
Yes one could compile FORTRAN and such on those main frames. I used ALGOL. But that was a tedious business involving punching card decks and submitting them to the operators to enter into the batch system for compilation. Often the results would come back next morning!
Ideas of multi-user interactive sessions were pretty new. That's just what you want for introducing dozens of students to programming. You could do it with that bunch of teletypes an interpreted language and a simple time sharing operating system. But how do you edit on a teletype? Easy, give every program line a line number. If the user makes an error he can just type that line again with the corrections. The interpreter keeps track of the ordering of everything entered in its memory.
Then we come to the early micro-computers. Pretty much the same problems. An Altair or MITS did not have a nice CRT monitor you could write an editor for. Even if there was enough memory to fit an editor in.
Enter Bill Gates and the 4K BASIC. Just what everyone needed to get going quickly with their otherwise useless lump of logic.
10 Start
15 DO something
20 GOTO 50
30 GOTO 10
40 DO something
45 GOTO 10
50 GOTO 30
Lets see spaghetti code, does that jog anybody's memory? Where is that box of blank punch cards?
Ray
Today, I'm not sure the numbers are any gain for beginners. Maybe.
With full-screen editors, there really is no need for line numbers.
Labels, yes, but a named label is more useful, as in ASM.
That is why from very early on we were taught to design our programs first. Using flow charts, with some rules about "structure" or Nassi Shneiderman diagrams. That later of which look like modern day graphical programming in Scratch or Blockly etc.
Such design presentation was a required part of all our assignments and bigger projects.
Oddly, the introduction of structure programming languages, C, Pascal etc, the banishment of GOTO and so on did not stop people writing unintelligible code.
Then they invented object oriented programming and C++, all hope of comprehensibility was lost.
Anyone remember EDLIN ? Whoa, flashback.... Using DEBUG to format a MFM harddrive.... Turbo Pascal 3.01....
Amstrad PC1512 with dual 360K floppies.... Connecting things to the printer port....
Good times.....Good times.....
Bean