Heater
Posts: 8086
Joined: Tue Jul 17, 2012 3:02 pm

Re: A Crittical look at BBC BASIC V.

Thu Nov 21, 2013 5:35 pm

Yep, as you might guess I'm quite fascinated by programming languages features, how they have evolved over the years, how they help with this or that programming problems, how they interact with each other in a language design and so on. I could debate these things from an amateur theoretical point of view forever, I'm any kind of language designer or compiler writer.

What about practical issues?

The biggest issue for the proposed take up of BASIC V is that for any realistic point of view it does not exist. It only works on ARM and it only works on RISC OS which means it's not of any use to 99.9% of the worlds computer users.

What to do?

One could spend a few years creating a cross platform version, Linux, Mac, Windows as a minimum. Sound's like one of BASIC V's main strengths is the simple in-line assembler feature so that will need to be made to work on Intel, Power PC, MIPs, OpenRISC and whatever else. (Mind you in the cross-platform world I'm living in having assembler built into the language is mostly useless).

Having done all that I suspect it would still attract a very small user base. Why?

1) It will not have the tons of useful modules and libraries that people need to get anything done.
2) The world already has a lot of BASICs to choose from along with dozens of other languages, compiled or interpreted.

What massively compelling feature or features does BASIC V have that would cause anyone to take notice once you have put all the work into getting into a state where they could even use it?

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at BBC BASIC V.

Thu Nov 21, 2013 8:52 pm

Heater wrote:The fact that C/C++ cannot print anything without a library function is good. Recently the Python guys realized this and new Python has a print function not a print language keyword.

Not sure what you mean by weird constructs. Formatting text output can be complicated, printf reflects the complexity of what it does. iostreams may be a bit cleaner.
Yes and BASIC defines PRINT as a library implementation *(well at least some early references did), as well as the other IO statements. Thus my comparison.

There would need to be an update of the library to handle the new datatype of Unicode Strings. Though the keywords used to access it would remain the same.

Still attempting to figure out where to put its token.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at BBC BASIC V.

Thu Nov 21, 2013 8:55 pm

Ravenous wrote:
DavidS wrote:As you mention example in C++ remember that C++ like C can not pring anything, they require a library for that, and some weard constructs.
But this thread is not about what C++ or C is lacking, it's about what other people think BASIC V is lacking. That's what you asked for in the original post. And you're getting that, I think (I haven't studied all the answers but at least some of the replies are coming from people who have used it, I think...)
I was only using it as a comparison point, as it had been used as a comparison point to me the responce using the comparison point seemed apropriate.

And yes I am very interested in the responces. I have to agree with unicode being added to the IO statements BASIC library in BBC BASIC V as being a positive. Again need somewhere to put a token for the new datatype of unicode string.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at BBC BASIC V.

Thu Nov 21, 2013 9:21 pm

Heater wrote:Yep, as you might guess I'm quite fascinated by programming languages features, how they have evolved over the years, how they help with this or that programming problems, how they interact with each other in a language design and so on. I could debate these things from an amateur theoretical point of view forever, I'm any kind of language designer or compiler writer.
Well yes I have always thought that study of the evolution of Programming languages and the implementation of at least a few quite different compilers and interpreters is a prerequesit of real programming. I also feel that if you can not implement a working usable self hosting compiler for a language in under a week to a point that is satisfactory for 90% of your code you should not use the language for any real work. I am not including the development of language specific libraries in that time window just a simple compiler for the target lang. If a compiler is well thought out in its initial design you can worry about adding optimization latter.
What about practical issues?

The biggest issue for the proposed take up of BASIC V is that for any realistic point of view it does not exist. It only works on ARM and it only works on RISC OS which means it's not of any use to 99.9% of the worlds computer users.
I am aware of this. The same can be said of most languages and this is not the point at hand. I did mention that there is nothing stopping someone from making compatible compilers for other ARM based OSes.

Yes it is tied to the ARM CPU, the most used CPU on earth is the ARM now. So if the bonds of RISC OS are broke by porting it to other ARM based OSes it suddenly will become usable to most. And thing about making a Linux system call by:

Code: Select all

SYS 0,SysCallNum,Param0,Param1,etc
In BBC BASIC V this is equilivent to:

Code: Select all

  MOV R0,SysCalNum
  LDR  R1, Param0
  LDR  R2, Param1
  LDR  R3, etc
  SWI 0
in ARM Assembly.

Though the point is those that could use it and do not bother to consider it because of missperception of the language.

What to do?

One could spend a few years creating a cross platform version, Linux, Mac, Windows as a minimum. Sound's like one of BASIC V's main strengths is the simple in-line assembler feature so that will need to be made to work on Intel, Power PC, MIPs, OpenRISC and whatever else. (Mind you in the cross-platform world I'm living in having assembler built into the language is mostly useless).
Now that is one thing about BBC BASIC V it is strongy tied to the ARM CPU in more ways than just the assembler. Though this is no problem as the ARM is the most used CPU on the planet today.

Though due to the similarities I see no reason it could not be ported to the Propeller P8X32A. Or even the Prop II in the future.
Having done all that I suspect it would still attract a very small user base. Why?

1) It will not have the tons of useful modules and libraries that people need to get anything done.
2) The world already has a lot of BASICs to choose from along with dozens of other languages, compiled or interpreted.
Again the main point is to those that could use it. Yes this is only on RISC OS at this time. Though I have heard many say that they never looked at BBC BASIC V simply because they think that any BASIC is bad news, even though they do use RISC OS. So you are missing the point. The point has nothing to do with other platforms and does not aply to the people that you are attempting to target.
What massively compelling feature or features does BASIC V have that would cause anyone to take notice once you have put all the work into getting into a state where they could even use it?
Well I have said it ten times what is eleven:

The point has nothing to do with other platforms and does not apply to the people that you are attempting to target.

Do not get me wrong I would like to see it on other ARM based OSes though the point is those that ignore it completely that are new to RISC OS, and not because it is not for them though because it includes the word BASIC in its name and they were taught that BASIC is bad or in some cases that you could not get any real work done in BASIC. And there in we have the false perception that I am attempting to break. I am not attempting to convert a bunch of people, nor am I attempting to popularise BBC VASIC V in OSes other than RISC OS.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
jojopi
Posts: 3007
Joined: Tue Oct 11, 2011 8:38 pm

Re: A Crittical look at BBC BASIC V.

Thu Nov 21, 2013 10:35 pm

DavidS wrote:All byte values from 0x7F through 0xFF are used for Tokens, though I guess that one of the unused characters bolow 0x1F would work as well, though may still slow down the interpreter when encountered.
Earlier versions of BBC BASIC used the tokens &C6, &C7, &C8 for AUTO, DELETE, LOAD. Since these are commands, which are not valid in programs, BASIC V reuses the tokens to introduce two byte sequences representing various functions, commands, and statements, respectively. There is plenty of room for expansion in these two byte token spaces.

Interestingly, BBC BASIC for Windows does use tokens below &20 (omitting &00 and &0D) instead.

Twinkletoes
Posts: 210
Joined: Fri May 25, 2012 9:44 pm

Re: A Crittical look at BBC BASIC V.

Thu Nov 21, 2013 10:54 pm

Your problem is not the language. There are hundreds of languages which were created for a purpose that no longer exists, or were superseded by better ones. Some of those languages are great.

But no one uses them any more in the numbers required to keep a community going. If I have a problem in C#, I can google it and I will get hundreds of pages, and the top ten will all give me an answer that will work.

Googling a sample question "c# look up into dictionary", I get a tutorial, examples, discussion of the best way to do it, discussion of coding style when doing it.

Googling "bbc basic V look up into dictionary", link 1 is "Learn how to use a dictionary to improve your spelling with these English skills". Link 2 is this thread on the Pi forum.

kthxbai

ame
Posts: 3172
Joined: Sat Aug 18, 2012 1:21 am
Location: Korea

Re: A Crittical look at BBC BASIC V.

Fri Nov 22, 2013 12:02 am

Twinkletoes wrote: Googling "bbc basic V look up into dictionary", link 1 is "Learn how to use a dictionary to improve your spelling with these English skills".
Sage advice indeed.

User avatar
scruss
Posts: 1398
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: A Critical look at BBC BASIC V.

Fri Nov 22, 2013 1:15 am

I'd say it was a nice language, as it's practically unavailable for almost every computer now. And I do have fond memories of BBC BASIC, as it was the first language I really learned on the BBC B at school. It stuck with me through university: Computer Concepts' FaST BASIC (which predated BASIC V but was structured and ran from ROM cartridge on the Atari ST - was a very nice development environment in 1988), BBC BASIC on the Z88, and also Ariadne's mostly-BBC B compatible emulator for the Amiga. All of these are more than 20 years in the past, though.

If you wanted to resuscitate BBC BASIC, you'd have to make it portable — that is, runs on something other than ARM. There are already a few decently-fast open BASIC interpreters and compilers available, so any BASIC V port would really have to justify its existence.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Critical look at BBC BASIC V.

Fri Nov 22, 2013 2:11 am

scruss wrote:I'd say it was a nice language, as it's practically unavailable for almost every computer now. And I do have fond memories of BBC BASIC, as it was the first language I really learned on the BBC B at school. It stuck with me through university: Computer Concepts' FaST BASIC (which predated BASIC V but was structured and ran from ROM cartridge on the Atari ST - was a very nice development environment in 1988), BBC BASIC on the Z88, and also Ariadne's mostly-BBC B compatible emulator for the Amiga. All of these are more than 20 years in the past, though.

If you wanted to resuscitate BBC BASIC, you'd have to make it portable — that is, runs on something other than ARM. There are already a few decently-fast open BASIC interpreters and compilers available, so any BASIC V port would really have to justify its existence.
The trouble with porting BBC BASIC V to anything non-arm is it is realy designed with the ARM in mind. Yes it is based on the older BBC BASICs and as such would be possible to port to other CPUs though you would loose to much.

Besides what is wrong with sticking to the worlds most popular CPU. I could see adopting it to other ARM BASED Operating systems, as that would still be a good fit.

As to justifying itself, do you (or anyone) know of a purely interpreted (no jit stuff) BASIC implementation with at least the feature set of BBC BASIC V that is as fast as the BBC BASIC V interpreter? I certainly do not. Of cource the ABC Compiler is far far from ideal.

I do not care so much if anyone uses the language, it is just those that lable it negitively that realy got me on this topic.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at BBC BASIC V.

Fri Nov 22, 2013 2:18 am

jojopi wrote:
DavidS wrote:All byte values from 0x7F through 0xFF are used for Tokens, though I guess that one of the unused characters bolow 0x1F would work as well, though may still slow down the interpreter when encountered.
Earlier versions of BBC BASIC used the tokens &C6, &C7, &C8 for AUTO, DELETE, LOAD. Since these are commands, which are not valid in programs, BASIC V reuses the tokens to introduce two byte sequences representing various functions, commands, and statements, respectively. There is plenty of room for expansion in these two byte token spaces.

Interestingly, BBC BASIC for Windows does use tokens below &20 (omitting &00 and &0D) instead.
That is interesting indeed. I had not looked at the tokens quite that closely, I generally only look at those tokens that are in my code, and then only when dealing with things to do with the source.

I am looking at them as I type this though, and there is a huge amount of available space (especialy under 0xC6 that has only 0x8E = SUM/LEN and 0x8F = BEAT) thank you. And I guess that using a two byte token for the type for a string of two byte characters is apropriate :).
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at BBC BASIC V.

Fri Nov 22, 2013 2:21 am

Twinkletoes wrote:Your problem is not the language. There are hundreds of languages which were created for a purpose that no longer exists, or were superseded by better ones. Some of those languages are great.

But no one uses them any more in the numbers required to keep a community going. If I have a problem in C#, I can google it and I will get hundreds of pages, and the top ten will all give me an answer that will work.

Googling a sample question "c# look up into dictionary", I get a tutorial, examples, discussion of the best way to do it, discussion of coding style when doing it.

Googling "bbc basic V look up into dictionary", link 1 is "Learn how to use a dictionary to improve your spelling with these English skills". Link 2 is this thread on the Pi forum.

kthxbai
Well it is not a popularity contest in any way shape or form. I have found that people generaly flock in groves to the least effecient solutions :) .

And do not get me on about C#. If you want OO perhaps you should consider porting charm to your OS of choice.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

Steve Drain
Posts: 87
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: A Crittical look at BBC BASIC V.

Fri Nov 22, 2013 2:27 pm

David
I have been using BBC BASIC V since the first Archimedes over a quarter of a century ago. For over 15 years I have been documenting the in-and-outs of the language in a StrongHelp manual:
http://kappa.me.uk/basic.htm
For more than a decade I have been writing an extension module that seeks to overcome its many faults and ommisions:
http://kappa.me.uk/basalt.htm
I do not recognise the language you are describing, its history, how it works and its use on other machines. I do not think you know it as well as you think, eg: tokens are not used for types; PRINT is a keyword, not a library function; the rights to BBC BASIC on non-Acorn machines rest elsewhere; pointers are not indirection; event handling does not mean using a CASE structure; unicode depends on the OS; etc ...

I like programming in BASIC and the inline assembler. It is fast and very capable of supporting full WIMP applications, but not in a thousand years would I promote it for use outside its current scope.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at BBC BASIC V.

Fri Nov 22, 2013 3:39 pm

Steve Drain wrote:David
I have been using BBC BASIC V since the first Archimedes over a quarter of a century ago. For over 15 years I have been documenting the in-and-outs of the language in a StrongHelp manual:
http://kappa.me.uk/basic.htm
For more than a decade I have been writing an extension module that seeks to overcome its many faults and ommisions:
http://kappa.me.uk/basalt.htm
I do not recognise the language you are describing, its history, how it works and its use on other machines. I do not think you know it as well as you think, eg: tokens are not used for types; PRINT is a keyword, not a library function; the rights to BBC BASIC on non-Acorn machines rest elsewhere; pointers are not indirection; event handling does not mean using a CASE structure; unicode depends on the OS; etc ...
Actually you just repeated many of my points. And yes technicaly PRINT is a keyword and built into the language. Types are defined by a character, this is a kind of token, though there are no printable charachters available (as far as I know) to use thus the idea of using a token above &7F

And yes I would agree with the use of Unicode only through the OS. I know there is a RISC OS module for that though I do not remember any details as I personaly do not have any use for unicode.

As to BBC BASIC on other platforms, none of them are BBC BASIC V.


Thank you for pointing out that I am terrible at describing anything to others. The language that I am speaking of is BBC BASIC V that I have used on Aurthur and RISC OS since 1989.
I like programming in BASIC and the inline assembler. It is fast and very capable of supporting full WIMP applications, but not in a thousand years would I promote it for use outside its current scope.
Now I personaly agree with that. I only mention its potential outside of RISC OS as so many miss the point that I am attempting to target users of RISC OS not of other OSes. Thank you for reinforcing that.

I do envy what you do with BBC BASIC V as you probably know more about it than 99% of the other RISC OS users.

OT:
Do you think that there is any chance in seeing Sophi Wilson getting involved in RISC OS and/or BBC BASIC V again?
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
scruss
Posts: 1398
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: A Critical look at BBC BASIC V.

Fri Nov 22, 2013 4:31 pm

DavidS wrote:The trouble with porting BBC BASIC V to anything non-arm is it is really designed with the ARM in mind.
How so? Apart from the inline assembler (which is a function of the host; to me, the “real” assemblers included in BBC BASIC are for 6502 and Z80), what is inherent to the language design that runs best on ARM only?
DavidS wrote:Besides what is wrong with sticking to the worlds most popular CPU.
I think there may be rather more embedded 8-bit microcontrollers than ARMs around there: 8051-clones, PICs, etc. Compact fluorescent lightbulbs even have processors in them …
DavidS wrote:As to justifying itself, do you (or anyone) know of a purely interpreted (no jit stuff) BASIC implementation with at least the feature set of BBC BASIC V that is as fast as the BBC BASIC V interpreter?
X11-Basic is pretty fast, but isn't BASIC V's tokenizing a bit of a shortcut to gain some speed? It's going to be very hard to find a straight comparison, as you'd need to find a BASIC interpreter that runs on RiscOS, since that's all that BASIC V will currently run on.

The fastest language is what runs on the machine in front of you that does the job you need. For me, sometimes that's awk, as it's right there in the shell.
DavidS wrote:I do not care so much if anyone uses the language, it is just those that label it negatively that really got me on this topic.
I'm actually rather fond of it. I'd like a portable version to run on any machine (BASICV.js, maybe? ☺)
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

Steve Drain
Posts: 87
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: A Crittical look at BBC BASIC V.

Fri Nov 22, 2013 6:43 pm

DavidS wrote:And yes technicaly PRINT is a keyword and built into the language.
No need for 'technicaly'; it is. And it is one of the more awkward parts of the language. It is so versatile that it is a souce of a number of obscure bugs. Thankfully, it is never needed in wimp programs.
Types are defined by a character, this is a kind of token, though there are no printable charachters available (as far as I know) to use thus the idea of using a token above &7F
String and integer variable identifiers have a trailing $ or %, but that is not anything like a token. Internally variables are identified by an l-type and their values by a value-type, but neither of those can be called a token either. As far as creating new variable identifiers, there are some options. For instance, long strings might have $$, but that is only a tiny bit of solving that problem.
As to BBC BASIC on other platforms, none of them are BBC BASIC V.
The rights to BBC BASIC, any version, is not anyone's to give away. You can write a compatible language, some of which have been mentioned, but you cannot use the term 'BBC'. Note that Brandy BASIC is almost fully compatible, it is written in C and might be compiled for any suitable machine, not just ARM. For use on RISC OS itself it can be a bit slow. And do not forget BBC BASIC for Windows, which is actively developed.

Heater
Posts: 8086
Joined: Tue Jul 17, 2012 3:02 pm

Re: A Crittical look at BBC BASIC V.

Fri Nov 22, 2013 7:03 pm

Steve Drain,

Great. Thanks for your input. It's good to hear from someone who knows what BBC BASIC is and where it can and cannot go.

For myself, I am of such an age that the BBC computer was beyond by budget and later the Archie was also beyond by budget. I had to content myself with building a 6809 computer by hand and programming it in HEX!

scruss,

Code: Select all

BASICV.js
Excellent idea. That would bring BASIC V to more potential users than it could ever previously imagined.
Now a days we can run virtual machines running Linux, written in JS and running the browser, why not BBC BASIC?
No idea why one would want to do that when JS is a perfectly good language but from a historical perspective why not?

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at ARM BASIC V.

Fri Nov 22, 2013 8:46 pm

Steve Drain wrote:
DavidS wrote:And yes technicaly PRINT is a keyword and built into the language.
No need for 'technicaly'; it is. And it is one of the more awkward parts of the language. It is so versatile that it is a souce of a number of obscure bugs. Thankfully, it is never needed in wimp programs.
Types are defined by a character, this is a kind of token, though there are no printable charachters available (as far as I know) to use thus the idea of using a token above &7F
String and integer variable identifiers have a trailing $ or %, but that is not anything like a token. Internally variables are identified by an l-type and their values by a value-type, but neither of those can be called a token either. As far as creating new variable identifiers, there are some options. For instance, long strings might have $$, but that is only a tiny bit of solving that problem.
Interesting indeed. I am thankful for this info indeed.

You have my mind going. Also thankyou for the information on veriable types, I did not know this.
As to BBC BASIC on other platforms, none of them are BBC BASIC V.
The rights to BBC BASIC, any version, is not anyone's to give away. You can write a compatible language, some of which have been mentioned, but you cannot use the term 'BBC'. Note that Brandy BASIC is almost fully compatible, it is written in C and might be compiled for any suitable machine, not just ARM. For use on RISC OS itself it can be a bit slow. And do not forget BBC BASIC for Windows, which is actively developed.
I am aware of this. BBC BASIC for Windows is definitely not the same as BBC BASIC V. And Brandy BASIC is not the same either, I notice the differences when I attempt to use the other BBC BASIC implementations and clones. Also Brandy BASIC is written in C, I personaly dissagree with this approch.

As to the name I am aware of the fact that that is a held tradmark, and would never recomend that a compatible language use it.


Again I thank you for pointing toward information that I did not know. Also I do not use the builtin consol IO statements in any of my projects so would not be aware of the errors with PRINT.

Still wish there was a better and more complete compiler available.

Also as to the BBC BASIC V name as I am speeking of the language and not nessesarily the implementation I will rephrase the thread title to read ARM BASIC V as this is a term that some use to refer to the language.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at ARM BASIC V.

Fri Nov 22, 2013 8:51 pm

I have changed the thread title to "A Critical look at ARM BASIC V" as this does not specificaly look at the trademarked implementation that is built into RISC OS.

I must thank Steve Drain for pointing this out.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

ame
Posts: 3172
Joined: Sat Aug 18, 2012 1:21 am
Location: Korea

Re: A Crittical look at ARM BASIC V.

Sat Nov 23, 2013 4:31 am

DavidS wrote:I have changed the thread title to "A Critical look at ARM BASIC V" as this does not specificaly look at the trademarked implementation that is built into RISC OS.

I must thank Steve Drain for pointing this out.
Actually, you changed it to "A Crittical look at ARM BASIC V.", which I find quite ironic.

Heater
Posts: 8086
Joined: Tue Jul 17, 2012 3:02 pm

Re: A Crittical look at ARM BASIC V.

Sat Nov 23, 2013 5:01 am

DavidS,
I also feel that if you can not implement a working usable self hosting compiler for a language in under a week to a point that is satisfactory for 90% of your code you should not use the language for any real work.
I have been scratching my head wondering what you meant by this.

Are you saying that I should not be doing any real programming until I have first written by compiler, which can compile itself and is simple enough to write in a week?

Or is it that I should not be doing any real work unless the compiler I use, whoever wrote it, can compile itself and is simple enough to write in a week?

Really, if that were the rule there would be very few programmers in the world and they would be using such crude tools that progress would be impossible.

Don't forget that high level languages were originally developed to enable computers to be used by people who were not computer gurus. Think Fortran and Cobol, and yes BASIC. etc. These compilers/Languages have often taken much longer than a week to create. (Actually none of them are finished yet after many decades, they are still evolving).
Besides what is wrong with sticking to the worlds most popular CPU.
Remind me again, is that the 6502 or the Z80? Or perhaps the 8086... I can't keep up :)

Steve Drain
Posts: 87
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: A Crittical look at ARM BASIC V.

Sat Nov 23, 2013 1:35 pm

DavidS wrote:Also thank you for the information on veriable types, I did not know this.
BASIC Reference Manual, under CALL. Available since 1988. Summarised in my StrongHelp manual.

User avatar
scruss
Posts: 1398
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: A Crittical look at BBC BASIC V.

Sat Nov 23, 2013 2:23 pm

Heater wrote:Now a days we can run virtual machines running Linux, written in JS and running the browser, why not BBC BASIC?
I was more meaning to run it as a Node application. Yes, it pains me a bit to see these kids doing heavy lifting in interpreted languages, but most development isn't meant for the ages; it just has to be good enough now.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

hippy
Posts: 2343
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: A Crittical look at ARM BASIC V.

Sat Nov 23, 2013 3:12 pm

Heater wrote:DavidS,
I also feel that if you can not implement a working usable self hosting compiler for a language in under a week to a point that is satisfactory for 90% of your code you should not use the language for any real work.
I have been scratching my head wondering what you meant by this.
Me too. The best I could interpret it as is, if a compiler cannot be written for the language, in the language itself, in under a week it is not an appropriate language to be using.

I am not convinced that's true or even a valid measure of any particular language. There are plenty of languages targeted to do particular jobs which are not necessarily well suited to being used as compilers. A language which is easy to write compilers in does not make it most suitable for everything else. The time clause seems completely arbitrary.

That "if you can't write..." suggests a measure of programmer competence rather than language capability. I don't believe it's necessary for a programmer to be able to write compilers to call themselves a programmer. It's a fine skill to have but I don't consider it a prerequisite.

There's a danger in all this that the best languages are perceived to be the ones best to write compilers in. As dynamic strings are quite handy for compilers you can end up arguing those languages which intrinsically support things a compiler writer finds useful to have are better than languages which don't.

And what of languages which can self-compile themselves but don't offer any mechanism to interact with the real world interfaces you would like to interface with ? There are valid reasons some languages may be sand-boxed.

scruss wrote:
DavidS wrote:The trouble with porting BBC BASIC V to anything non-arm is it is really designed with the ARM in mind.
How so? Apart from the inline assembler (which is a function of the host; to me, the “real” assemblers included in BBC BASIC are for 6502 and Z80), what is inherent to the language design that runs best on ARM only?
That was something which equally intrigued me. It rather suggests that if ARM were not available then BASIC V would be all but a dead end.

Heater
Posts: 8086
Joined: Tue Jul 17, 2012 3:02 pm

Re: A Crittical look at ARM BASIC V.

Sat Nov 23, 2013 4:08 pm

scruss,
I was more meaning to run it as a Node application.
Yes, why not? Lot's of my JS runs in the browser or under Node.
...it pains me a bit to see these kids doing heavy lifting in interpreted languages..
I'm an old hand that's grown up with assembler and lived with compiled high level languages but I have to say the young kids are right to do this in many
cases.

For sure you are going to want to use a high level, compiled, portable language for the heaving lifting. Like your OS kernel, audio, video, compression, XML parsing, graphics, etc etc etc. You are going to need that to implement your JavaScript engine anyway.

But that means your application code, perhaps in a browser, has become just a "glue" that orchestrates all these lower level functionalities to do what you
want. You are no longer programming in bits and bytes but in XML streams, JSON objects and so on.

It no longer matters if you write your app in a slow interpreted language, it is only a few percent of the code that is making up the entirety of your application.

It was a real eye opener to me a couple of years back when I implemented some server functionality in node that was dealing with XML streams. That JS was
performing nearly as well as the old equivalent code we have in C++. It was much easier and quicker to develop.
..most development isn't meant for the ages; it just has to be good enough now.
Perhaps true of much web page development. But those guys building Node and all it's modules obviously intend it to be around for a long time. Same goes for
many JS libraries intended for use in the browser.

Those young kids have caught on to the idea that a lot of unit testing can make up for the dynamic "sloppy" nature of JS.

All is good.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: A Crittical look at ARM BASIC V.

Tue Nov 26, 2013 12:26 pm

Heater wrote:DavidS,
I also feel that if you can not implement a working usable self hosting compiler for a language in under a week to a point that is satisfactory for 90% of your code you should not use the language for any real work.
I have been scratching my head wondering what you meant by this.

Are you saying that I should not be doing any real programming until I have first written by compiler, which can compile itself and is simple enough to write in a week?

Or is it that I should not be doing any real work unless the compiler I use, whoever wrote it, can compile itself and is simple enough to write in a week?

Really, if that were the rule there would be very few programmers in the world and they would be using such crude tools that progress would be impossible.

Don't forget that high level languages were originally developed to enable computers to be used by people who were not computer gurus. Think Fortran and Cobol, and yes BASIC. etc. These compilers/Languages have often taken much longer than a week to create. (Actually none of them are finished yet after many decades, they are still evolving).
Now I am just saying that a seasoned programmer should have a good enough familiarity with the language that they use to write a usable recursive decent compiler for that language with enough of it complete to compile itself in under a week. Now good optimizing compilers take a bot more time. Though it is an easy matter to get a working Recursive Decent compiler that is self hosting going for any good language in a week, while it may be missing some miner feature it would be a near complete implementation of the language. This is true for C, Most BASIC's, Pascal, Oberon, etc. Those languages for which it is not true it is difficult to recomend the use of, those that are to complex include the newer verients of C++, C#, Java, etc.

And I am only talking about the Compiler not any standard libs.
Besides what is wrong with sticking to the worlds most popular CPU.
Remind me again, is that the 6502 or the Z80? Or perhaps the 8086... I can't keep up :)
Yes it is true. Who knows what will be most used in ten years.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

Return to “Other languages”

Who is online

Users browsing this forum: No registered users and 5 guests