Gates has been quoted as telling his development teams that he could get the same job (no matter what it was!) done using BASIC in just a few minutes.
Do you have a link to such a quote?
Sounds silly given that doing anything interesting in BASIC is all but impossible.
Of course things improved with Microsoft's Visual Basic and such. But they are not children of BASIC as much as they are children of ALGOL.
The way I remember reading it (but I have no idea where to find it now) was that some other guy at Microsoft, development head or some such, said that BG could get whatever done in VB over the weekend. It *could* be that it was BG himself who said it, I'm not sure, but what I'm sure about is that it was VB, not e.g. GW BASIC.
Admittedly there was FORTRAN which I think had line numbers, and I know nothing about.
Not line numbers, but it used numbers for labels.
The Fortran I remember had line numbers. If you didn't use them and you dropped your punched cards, well goodbye program
At least the mini I worked with from 1974 had 6 character labels. It was programmed in assembler with only 15 instructions, with each instruction being 60 bits (10 x 6 bit uppercase ASCII characters. I could enter machine code straight into the mini. BTW it was a decimal computer, both in arithmetically and memory addressing. A multiply instruction could multiply an A address of up to 10 characters by a B address of up to 10 characters, with the result (in decimal) written to the B address for a length of A+B, so no overflow was possible. Divide effectively reversed a multiply giving a dividend and remainder (in decimal).
Of course it was a monster - the length of my garage!
Admittedly there was FORTRAN which I think had line numbers, and I know nothing about.
Not line numbers, but it used numbers for labels.
The Fortran I remember had line numbers. If you didn't use them and you dropped your punched cards, well goodbye program
At least the mini I worked with from 1974 had 6 character labels. It was programmed in assembler with only 15 instructions, with each instruction being 60 bits (10 x 6 bit uppercase ASCII characters. I could enter machine code straight into the mini. BTW it was a decimal computer, both in arithmetically and memory addressing. A multiply instruction could multiply an A address of up to 10 characters by a B address of up to 10 characters, with the result (in decimal) written to the B address for a length of A+B, so no overflow was possible. Divide effectively reversed a multiply giving a dividend and remainder (in decimal).
Of course it was a monster - the length of my garage!
Those were not line numbers, they were sequence numbers and used exclusively to sort cards as you mention. I don't the the Fortran compiler even looked at them.
By the early 80s second generation BASICs were being released that did away with things like line numbering. In '85 we had QuickBASIC, and if you used line numbering you were considered a Luddite.
Hamstringing a language by its initial incarnation will always end up zero sum. Look at the first JavaScript/ECMAScript, and compare with today's Back in the day there was no try/catch error handling, no regular expressions, no collections, no extensibility to use objects like a DOM, and the list goes on. No line numbers either, but as a language, the versions in the first years were extremely crude by today's standards.
By that same argument you could say that BASIC didn't add anything to what you can do in assembly language and assembly language didn't add anything to what you can do in binary machine code. Let's get rid of all high-level languages and assemblers and just program in hex!
The first FORTRAN was written in a fixed format. The first 5 character positions being reserved for numeric statement identifiers. It was not required to have an identifier on each line/punch card. As this example on punched card shows:
The issue of dropping a card deck was eased by drawing angled stripes up the side of the deck so that a dropped deck could reassembled in order by matching the line up again.
A trick that I wish I knew of at the time
The issue of dropping a card deck was eased by drawing angled stripes up the side of the deck so that a dropped deck could reassembled in order by matching the line up again.
A trick that I wish I knew of at the time
Pretty clever! If you had a bit more time and were easily amused, you could make a flip book out of your punch card deck. Rearranging errant cards becomes a fun activity!
Hamstringing a language by its initial incarnation will always end up zero sum...
Very true.
I would have more sympathy for that view in the case of BASIC if there was an actual standard modern BASIC. In the way we have a standard for C, C++, JS, etc.
As it stands modern BASICS are mish-mash of concepts from other great languages that pioneered them. Like Algol.
Look at the first JavaScript/ECMAScript, and compare with today's Back in the day there was no try/catch error handling, no regular expressions, no collections, no extensibility to use objects like a DOM, and the list goes on.
When I look at Javascript I see that it has changed remarkably little in, terms of actual language, since it's inception.
Regular Expressions and try/catch catch came very early on, only a year or so after the language was created.
I'm not sure what you mean by "no collections". JS has objects which are used as collections. Always has had as far as I know.Functions are objects. In JS almosteverything is a "collection".
Access to the DOM is not really a language is issue. That's an API.
Admittedly JS is in danger of being made into a pigs ear with recent major changes. Like class and modules. I think that's because the JS world has been overrun by loads of Java refugees who think they need that junk.
I still would not say the "versions in the first years were extremely crude by today's standards." Far from it.
Hmm...the article you linked to does not support that proposition. In fact quite the opposite. It talks of three programming paradigms that are considered useful in many applications. None of which BASIC has.
When it comes to taking something away, well, BASIC did that in spades. It had no access to actual memory via pointers or whatever. It had no functions. It had no structure.
Stop hamstringing. It has all that. Yet each is optional. And on top of that, it has the quickest development time, faster than assembly AND faster than any other HLL. It truly holds the sweet spot.
With Commodore BASIC on the PET and similar, you had access to memory with pointers using PEEK and POKE; you could define functions using DEF FN though it was not much used; a competent programmer could write a nicely structured program - just as a competent assembly programmer can.
I would have more sympathy for that view in the case of BASIC if there was an actual standard modern BASIC. In the way we have a standard for C, C++, JS, etc.
There's not much of a need to standardize BASIC, as its place in computing history is now as a learning tool, similar to pictographic languages such as Blockly and Scratch. There are standards but they are now old and no longer relevant. That doesn't diminish the language's importance of how it got modern computing to where it is today.
On JavaScript being crude at the start: I was there, and it was crude by today's standards. Sure, we had loose objects that you could code into "anything" -- not always very well, but a hack is a hack. By that standard, early BASIC had an enormous array of capabilities, depending on how you wanted to view your coding. The kind of collections I'm talking about are the very standards you're wanting in a modern BASIC-- keyed collections like Map, Set, and so on are part of ECMAScript, and it's the kind of evolution you want to see in any language.
I used varptr()-tricks to make strings overlay the character screen memory of the TRS-80. So shifting/rotating the string's contents with normal string functions directly made the characters cycle in the associated screen line.
Sometimes I think BASIC was fun because we did many surprising things those days that were more or less dirty and unportable tricks but always felt like a small(?) victory... \o/
In the mid-80's I did some work at an interesting intersection in the history of BASIC, Microsoft Series 100 BASIC which was offered for the HP150, a non-PC compatible DOS machine with an optional infrared matrix touch screen. It was hella expensive and used mainly for business, I know of at least one airline that got hecka screwn when HP decided to stop making them.
Anyhow Series 100 Basic came with a regular MS-DOS line number based interpreter, and a matching compiler. I believe this was one of Microsoft's first compiler projects; it had very noticeable GC glitches and was prone to crash if long strings were manipulated a lot (I learned much later due to a bug in the 8088 which caused REP operations not to be resumed if they were interrupted). S100 Basic made no system calls at all other than MS-DOS, and so had no native access to any of the non-MS-DOS machine functions such as graphics. I wrote a lot of assembly language routines to link to that compiler. And by writing different ones, I continued to use the compiler and existing code on regular PC's when we moved to them, because the MS-DOS layer was exactly the same and converting the hardware access functions was easier than converting the whole thing to QuickBASIC.
By default the compiler expected a line numbered program as might have been entered into the interpreter, but there was a mode switch which made line numbers optional and allowed you to use a page editor. You still had to number lines that were GOTO targets, because there were no alphanumeric labels as in QuickBASIC and later. It was otherwise exactly the same language as the interpreter, although once you started leaving out the line numbers you could no longer open and run the program with the interpreter.
It was a couple of years after Series 100 BASIC that QBasic and QuickBASIC came out. I am convinced that Series 100 Basic was the pivotal transition product that marked the move from line numbers to screen editing. And of course once screen editing was the norm, the language itself pivoted toward features that were more appropriate to that environment, like CALL and SUB and FUNCTION instead of GOSUB and RETURN, parameter passing, local variables, and so on. These features were added incrementally until VB looks so different from Level II Basic for the TRS-80 that many people think it's a different language. But it isn't, really, and it's much simpler to convert a series 100 BASIC program to VB than it is to move between other "different" languages. I should know, since I did it quite a few times.
The BBC Basic on RISC OS seems to be pretty nice as far as these things go. You can easily mix ARM assembly and Basic. For anyone curious you can easily run it on a Raspberry Pi.
I gave it a quick look, but since I never had a RISC OS machine it didn't hold my interest. Too much digital archaeology involved for me. But it looks like a lot of interesting programs were written in it.
However, IIRC, the benchmarks published on this forum (can't find them) show that PropBasic is the most efficient HLL available for the Prop. Not bad for something that Bean APPEARS to have just thrown out there, how many years ago?
Presumably, C is now able to get close.
Are you refering to http://forums.parallax.com/discussion/142803/some-multi-language-benchmarks/p1? There PropBASIC in COG mode did win the title for one benchmark (toggling a pin 1000 times) at 8024 cycles, versus 8044 cycles for PropGCC in COG mode. But most of the other benchmarks didn't have PropBASIC versions, so it's a bit premature to say it's the most efficient HLL available for the Prop. In LMM mode a compiler that has FCACHE (like PropGCC or fastspin) is going to perform better than one that doesn't (like PropBASIC) in most benchmarks. On the same toggle benchmark in LMM mode we had fastspin at 8208 cycles, PropGCC at 16416, and PropBasic at 48176 -- a pretty significant difference. And in more representative code, like Heater's FFT_BENCH, the best PropGCC score was 65 ms, the best fastspin score was 171 ms, and the best PropBasic score was 691 ms.
We're lucky on the Propeller to have a variety of very good tools, including PropBasic, PropGCC, openspin, fastspin, and Tachyon, all of which have applications that they excel at.
To me, the compelling part of BASIC lies in how it's oriented toward people doing stuff.
Often, choices are limited, or presented in layers, and this has the important artifact of helping people see how it can be done more easily.
The real value, of course, is that they start getting stuff done. Lays the foundation for getting more kinds of things, more advanced things done, and then done better.
Of the 8 bit BASICS, I really liked AppleSoft and the BBC Basic, which featured in-line assembly. The Apple didn't do that, but did include a system monitor and mini line assembler, and hooks for user code. Both also offered enough string handling, math, I/O to make solid use of the machines they were offered on too.
Usability and accessibility issues aside, both offered an "in-language" and "out of the box" way to get at the machine and maximize how it's used. It was possible to author assembly language and or make use of bits of it generated all sorts of ways, and do so easily.
People could make big, reasonably effective programs. In home-early business computing land, there were just tons of business automation type tasks coded in BASIC. Very significant numbers of these people went on to bigger and better things in various industries too. Borland picked right up on all of that with Turbo Pascal and Delphi, with Microsoft doing a similar thing with Visual Basic. Lots of that is still in use today.
This game:
...was written in BBC Basic, which ended up being nearly all assembly language, and employed advanced techniques to procedurally generate the environment and a ton of variables for the players to explore. It's a poor statement about BASIC, given that outcome, but it's a great statement about BASIC too. And that's all about being able to prototype, explore, build and not worry about too much while making stuff happen.
Elsewhere on the "series of tubes" (Love that, sorry it's just too funny!), you can find a history on how it was done. The best parts are the fact that the developers didn't really know, or were not told "what is possible?" and just proceeded to keep working, until it did what they wanted.
There are various BASICS out there I see people use for quick prototyping all the time. It's simple, runs fast, universal in that most everyone can read, share and get something out of the code they can use, port, understand, whatever.
I'm not sure I can go along with "advanced", but I am totally on board with ideas like, "enabling", because BASIC did just that and was a wild success.
In my view, this also speaks to the importance and value of enabling people to do things. Once they get a win or two, they remain motivated and that's generally going to mean moving on to bigger and better things. Nothing wrong with that. It may also mean just getting more things done. If the tool works, no worries! It works. For many, that's the goal. Reaching it matters.
The ones who demonstrate some affinity for programming will advance and leave BASIC behind, as they should and need. Those that don't, or who really are about getting some things done tend to invest in something and they stay with it to maximize that investment, as the rewards come from the thing getting done, not so much how it's done.
Stop hamstringing. It has all that. Yet each is optional.
"It" what exactly? I don't know of any standard definition of BASIC.
If you mean things like PEEK and POKE and inline assembler etc, then that is not BASIC. Such things go against the entire motivation and design philosophy of BASIC as created by Kemeny and Kurtz.
Of course things we know as "BASIC" from 1970's vintage micro-computers grafted kludges like PEEK, POKE, etc on to the language. They had to make it actually useful somehow.
On JavaScript being crude at the start: I was there, and it was crude by today's standards. Sure, we had loose objects that you could code into "anything"
Admittedly I was not there. Like most programmers of the time I ignored JS as that stupid, slow, browser scripting language that was of no real use.
So I may have missed a point. Surely objects in JS are pretty much the same today as they were from the beginning?
If you are talking collection abstractions like map, set etc then surely they could be created in JS circa 1999?
I would not say it is a "hack" to create such abstractions in your code or use them from a library. Not all abstraction can or should be built into a language.
Although it is good to have such commonly used things standardized.
Think I have to dig out my old RedHat CD's and play with Netscape...
I've used lots of Basics in the day as well as VB and even now sometimes occasionally but it would be very naive of anyone to say that Basic is better as the B in Basic stands for "Beginner". When it comes to the Prop the trick to making a language look good in terms of speed is to have it compile to PASM and fit it all into a cog. But real programs are more than a couple of k in size and can't fit into such a small space. Besides, PASM is not "efficient" in terms of code size with one long just for a very basic instruction. Chip designed the Prop and wrote Spin which is a good match for the Propeller architecture and is compact. The C compilers can also generate PASM that runs in a cog but anything larger needs to be interpreted either via LMM or as bytecode etc. That's where it all slows down but that is where the real test of the "efficiency" of the language is, in these larger programs as only very "basic" beginner programs could fit into 2k bytes.
btw, I always hated magic number peek and poke and they were so "8-bit", what did you do if you wanted 16 or 32 bits? (don't tell me).
Admittedly I was not there. Like most programmers of the time I ignored JS as that stupid, slow, browser scripting language that was of no real use.
JS wasn't horrid for what it did, but its security architecture was disadvantaged because of the way it was implemented, rightfully leading the charge against it as a security risk. For example, the early versions of Netscape 2.x allowed you to skim through the values in the history object, allowing any site to see what other sites you visited. Not until 3.x did they close the loophole where sites could silently grab user's email addresses (remember Netscape also served as an email and news reader). Pretty unimpressive stuff.
While many of these faults are from its implementation, and not the language itself, it's rewriting history to view the beginnings of JavaScript as a generic language pressed into service as a browser script engine. Independence came later, though it didn't take them long to decide on this approach. Internet time is not normal time.
There are several inacted ECMA and ANSI standards for BASIC, though they date some 30 years. I don't think standardization was a key point for "user" languages back in the day. For years my brother-in-law made a good living coding a time scheduling program in compiled BASIC that he sold to nursing homes. During my time supporting WordPerfect automation (well, still do; let's talk about arcane!), I wrote many utilities in BASIC that did things like parse through WordPerfect files and revising them on-the-fly. I no longer use it, but BASIC is/was certainly capable of doing all these things -- and no line numbers, BTW.
Think I have to dig out my old RedHat CD's and play with Netscape...
If you mean things like PEEK and POKE and inline assembler etc, then that is not BASIC. Such things go against the entire motivation and design philosophy of BASIC as created by Kemeny and Kurtz.
Yes, which is a part of why I put what I did here. BASIC, as in "Beginners All purpose, Symbolic Instruction Code", ended up being something more like the interface to the computer, with all sorts of things bodged on to, and into it.
That design philosophy, did it's job. People could grok what they got. And yes, total mess from there.
"K&K Basic was compiled. Bill Gates made it interpreted, which gave it a bad name." Heh, Gates.
"I was a Freshman in the Fall of '65. Only in retrospect do I appreciate how important it was, this combination of a human intelligible language, time sharing, and opening the resource across the community. At the time it was just stimulating and fun, as the best learning always is."
"There was a lot of evolution in BASIC during my time at Dartmouth, from BASIC 6 to SBASIC to BASIC 7. While I was still an undergraduate, I saw, but didn't pay much attention to, some of the micro languages on early PCs that called themselves BASIC. When I started encountering even more mangled versions in the real world, I bought myself a copy of TrueBASIC for the Mac Plus. With 31 years in the computer and software business now, I still occasionally deal with code in modern variants of BASIC. With all the changes that we've seen in computing, It's nice feeling a connection to the history of something that's been so durable."
BTW those other guys know all about us and the P2!
The Basic Stamp is still available, and Parallax also launched their own 8-core microcontroller, the Propeller, about ten years ago. Designed completely by one man! And he's nearing the finish of the sequel, the Propeller 2.
Comments
At least the mini I worked with from 1974 had 6 character labels. It was programmed in assembler with only 15 instructions, with each instruction being 60 bits (10 x 6 bit uppercase ASCII characters. I could enter machine code straight into the mini. BTW it was a decimal computer, both in arithmetically and memory addressing. A multiply instruction could multiply an A address of up to 10 characters by a B address of up to 10 characters, with the result (in decimal) written to the B address for a length of A+B, so no overflow was possible. Divide effectively reversed a multiply giving a dividend and remainder (in decimal).
Of course it was a monster - the length of my garage!
Hamstringing a language by its initial incarnation will always end up zero sum. Look at the first JavaScript/ECMAScript, and compare with today's Back in the day there was no try/catch error handling, no regular expressions, no collections, no extensibility to use objects like a DOM, and the list goes on. No line numbers either, but as a language, the versions in the first years were extremely crude by today's standards.
Each of these paradigms took something away. None of them added any new capability. Each increased discipline and decreased capability.
https://8thlight.com/blog/uncle-bob/2012/12/19/Three-Paradigms.html
https://en.wikipedia.org/wiki/Punched_card#/media/File:FortranCardPROJ039.agr.jpg
The issue of dropping a card deck was eased by drawing angled stripes up the side of the deck so that a dropped deck could reassembled in order by matching the line up again.
A trick that I wish I knew of at the time
Pretty clever! If you had a bit more time and were easily amused, you could make a flip book out of your punch card deck. Rearranging errant cards becomes a fun activity!
I would have more sympathy for that view in the case of BASIC if there was an actual standard modern BASIC. In the way we have a standard for C, C++, JS, etc.
As it stands modern BASICS are mish-mash of concepts from other great languages that pioneered them. Like Algol. When I look at Javascript I see that it has changed remarkably little in, terms of actual language, since it's inception.
Regular Expressions and try/catch catch came very early on, only a year or so after the language was created.
I'm not sure what you mean by "no collections". JS has objects which are used as collections. Always has had as far as I know.Functions are objects. In JS almosteverything is a "collection".
Access to the DOM is not really a language is issue. That's an API.
Admittedly JS is in danger of being made into a pigs ear with recent major changes. Like class and modules. I think that's because the JS world has been overrun by loads of Java refugees who think they need that junk.
I still would not say the "versions in the first years were extremely crude by today's standards." Far from it.
When it comes to taking something away, well, BASIC did that in spades. It had no access to actual memory via pointers or whatever. It had no functions. It had no structure.
There's not much of a need to standardize BASIC, as its place in computing history is now as a learning tool, similar to pictographic languages such as Blockly and Scratch. There are standards but they are now old and no longer relevant. That doesn't diminish the language's importance of how it got modern computing to where it is today.
On JavaScript being crude at the start: I was there, and it was crude by today's standards. Sure, we had loose objects that you could code into "anything" -- not always very well, but a hack is a hack. By that standard, early BASIC had an enormous array of capabilities, depending on how you wanted to view your coding. The kind of collections I'm talking about are the very standards you're wanting in a modern BASIC-- keyed collections like Map, Set, and so on are part of ECMAScript, and it's the kind of evolution you want to see in any language.
I used varptr()-tricks to make strings overlay the character screen memory of the TRS-80. So shifting/rotating the string's contents with normal string functions directly made the characters cycle in the associated screen line.
Sometimes I think BASIC was fun because we did many surprising things those days that were more or less dirty and unportable tricks but always felt like a small(?) victory... \o/
Anyhow Series 100 Basic came with a regular MS-DOS line number based interpreter, and a matching compiler. I believe this was one of Microsoft's first compiler projects; it had very noticeable GC glitches and was prone to crash if long strings were manipulated a lot (I learned much later due to a bug in the 8088 which caused REP operations not to be resumed if they were interrupted). S100 Basic made no system calls at all other than MS-DOS, and so had no native access to any of the non-MS-DOS machine functions such as graphics. I wrote a lot of assembly language routines to link to that compiler. And by writing different ones, I continued to use the compiler and existing code on regular PC's when we moved to them, because the MS-DOS layer was exactly the same and converting the hardware access functions was easier than converting the whole thing to QuickBASIC.
By default the compiler expected a line numbered program as might have been entered into the interpreter, but there was a mode switch which made line numbers optional and allowed you to use a page editor. You still had to number lines that were GOTO targets, because there were no alphanumeric labels as in QuickBASIC and later. It was otherwise exactly the same language as the interpreter, although once you started leaving out the line numbers you could no longer open and run the program with the interpreter.
It was a couple of years after Series 100 BASIC that QBasic and QuickBASIC came out. I am convinced that Series 100 Basic was the pivotal transition product that marked the move from line numbers to screen editing. And of course once screen editing was the norm, the language itself pivoted toward features that were more appropriate to that environment, like CALL and SUB and FUNCTION instead of GOSUB and RETURN, parameter passing, local variables, and so on. These features were added incrementally until VB looks so different from Level II Basic for the TRS-80 that many people think it's a different language. But it isn't, really, and it's much simpler to convert a series 100 BASIC program to VB than it is to move between other "different" languages. I should know, since I did it quite a few times.
Probably similar to here. Plenty of baby boomers & older! Certainly some smart cookies, but it's not the social club that Parallax is.
I gave it a quick look, but since I never had a RISC OS machine it didn't hold my interest. Too much digital archaeology involved for me. But it looks like a lot of interesting programs were written in it.
Are you refering to http://forums.parallax.com/discussion/142803/some-multi-language-benchmarks/p1? There PropBASIC in COG mode did win the title for one benchmark (toggling a pin 1000 times) at 8024 cycles, versus 8044 cycles for PropGCC in COG mode. But most of the other benchmarks didn't have PropBASIC versions, so it's a bit premature to say it's the most efficient HLL available for the Prop. In LMM mode a compiler that has FCACHE (like PropGCC or fastspin) is going to perform better than one that doesn't (like PropBASIC) in most benchmarks. On the same toggle benchmark in LMM mode we had fastspin at 8208 cycles, PropGCC at 16416, and PropBasic at 48176 -- a pretty significant difference. And in more representative code, like Heater's FFT_BENCH, the best PropGCC score was 65 ms, the best fastspin score was 171 ms, and the best PropBasic score was 691 ms.
We're lucky on the Propeller to have a variety of very good tools, including PropBasic, PropGCC, openspin, fastspin, and Tachyon, all of which have applications that they excel at.
Eric
Often, choices are limited, or presented in layers, and this has the important artifact of helping people see how it can be done more easily.
The real value, of course, is that they start getting stuff done. Lays the foundation for getting more kinds of things, more advanced things done, and then done better.
Of the 8 bit BASICS, I really liked AppleSoft and the BBC Basic, which featured in-line assembly. The Apple didn't do that, but did include a system monitor and mini line assembler, and hooks for user code. Both also offered enough string handling, math, I/O to make solid use of the machines they were offered on too.
Usability and accessibility issues aside, both offered an "in-language" and "out of the box" way to get at the machine and maximize how it's used. It was possible to author assembly language and or make use of bits of it generated all sorts of ways, and do so easily.
People could make big, reasonably effective programs. In home-early business computing land, there were just tons of business automation type tasks coded in BASIC. Very significant numbers of these people went on to bigger and better things in various industries too. Borland picked right up on all of that with Turbo Pascal and Delphi, with Microsoft doing a similar thing with Visual Basic. Lots of that is still in use today.
This game:
...was written in BBC Basic, which ended up being nearly all assembly language, and employed advanced techniques to procedurally generate the environment and a ton of variables for the players to explore. It's a poor statement about BASIC, given that outcome, but it's a great statement about BASIC too. And that's all about being able to prototype, explore, build and not worry about too much while making stuff happen.
Elsewhere on the "series of tubes" (Love that, sorry it's just too funny!), you can find a history on how it was done. The best parts are the fact that the developers didn't really know, or were not told "what is possible?" and just proceeded to keep working, until it did what they wanted.
There are various BASICS out there I see people use for quick prototyping all the time. It's simple, runs fast, universal in that most everyone can read, share and get something out of the code they can use, port, understand, whatever.
I'm not sure I can go along with "advanced", but I am totally on board with ideas like, "enabling", because BASIC did just that and was a wild success.
In my view, this also speaks to the importance and value of enabling people to do things. Once they get a win or two, they remain motivated and that's generally going to mean moving on to bigger and better things. Nothing wrong with that. It may also mean just getting more things done. If the tool works, no worries! It works. For many, that's the goal. Reaching it matters.
The ones who demonstrate some affinity for programming will advance and leave BASIC behind, as they should and need. Those that don't, or who really are about getting some things done tend to invest in something and they stay with it to maximize that investment, as the rewards come from the thing getting done, not so much how it's done.
If you mean things like PEEK and POKE and inline assembler etc, then that is not BASIC. Such things go against the entire motivation and design philosophy of BASIC as created by Kemeny and Kurtz.
Of course things we know as "BASIC" from 1970's vintage micro-computers grafted kludges like PEEK, POKE, etc on to the language. They had to make it actually useful somehow.
So I may have missed a point. Surely objects in JS are pretty much the same today as they were from the beginning?
If you are talking collection abstractions like map, set etc then surely they could be created in JS circa 1999?
I would not say it is a "hack" to create such abstractions in your code or use them from a library. Not all abstraction can or should be built into a language.
Although it is good to have such commonly used things standardized.
Think I have to dig out my old RedHat CD's and play with Netscape...
btw, I always hated magic number peek and poke and they were so "8-bit", what did you do if you wanted 16 or 32 bits? (don't tell me).
JS wasn't horrid for what it did, but its security architecture was disadvantaged because of the way it was implemented, rightfully leading the charge against it as a security risk. For example, the early versions of Netscape 2.x allowed you to skim through the values in the history object, allowing any site to see what other sites you visited. Not until 3.x did they close the loophole where sites could silently grab user's email addresses (remember Netscape also served as an email and news reader). Pretty unimpressive stuff.
While many of these faults are from its implementation, and not the language itself, it's rewriting history to view the beginnings of JavaScript as a generic language pressed into service as a browser script engine. Independence came later, though it didn't take them long to decide on this approach. Internet time is not normal time.
There are several inacted ECMA and ANSI standards for BASIC, though they date some 30 years. I don't think standardization was a key point for "user" languages back in the day. For years my brother-in-law made a good living coding a time scheduling program in compiled BASIC that he sold to nursing homes. During my time supporting WordPerfect automation (well, still do; let's talk about arcane!), I wrote many utilities in BASIC that did things like parse through WordPerfect files and revising them on-the-fly. I no longer use it, but BASIC is/was certainly capable of doing all these things -- and no line numbers, BTW.
On local files only, please!
Yes, which is a part of why I put what I did here. BASIC, as in "Beginners All purpose, Symbolic Instruction Code", ended up being something more like the interface to the computer, with all sorts of things bodged on to, and into it.
That design philosophy, did it's job. People could grok what they got. And yes, total mess from there.
http://www.dartmouth.edu/basicfifty/forum.html
That comment string is very interesting.
"K&K Basic was compiled. Bill Gates made it interpreted, which gave it a bad name." Heh, Gates.
"I was a Freshman in the Fall of '65. Only in retrospect do I appreciate how important it was, this combination of a human intelligible language, time sharing, and opening the resource across the community. At the time it was just stimulating and fun, as the best learning always is."
"There was a lot of evolution in BASIC during my time at Dartmouth, from BASIC 6 to SBASIC to BASIC 7. While I was still an undergraduate, I saw, but didn't pay much attention to, some of the micro languages on early PCs that called themselves BASIC. When I started encountering even more mangled versions in the real world, I bought myself a copy of TrueBASIC for the Mac Plus. With 31 years in the computer and software business now, I still occasionally deal with code in modern variants of BASIC. With all the changes that we've seen in computing, It's nice feeling a connection to the history of something that's been so durable."
The Basic Stamp is still available, and Parallax also launched their own 8-core microcontroller, the Propeller, about ten years ago. Designed completely by one man! And he's nearing the finish of the sequel, the Propeller 2.
http://www.picaxeforum.co.uk/showthread.php?29791-Kemeny-amp-Kurtz-The-Invention-Of-BASIC&p=308755&viewfull=1#post308755
And I won't do it again!!!
I don't even know PICAXE. That sure is an asymmetric relation...
Do they know SC/MP?
SC/MP-III even had BASIC in ROM!
https://en.wikipedia.org/wiki/National_Semiconductor_SC/MP#Implementations: ...which is not bad for a 1970ers chip and so finally brings me back on topic... \o/