jahboater
Posts: 5191
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 9:32 am

Heater wrote:
Sun Nov 25, 2018 9:22 am
Did Micro Soft C on the IBM PC come with a lint? If so I'm dumb enough not to have found it at the time :)
No, it was a UNIX thing.
Like most of the other development tools that made the "UNIX software factory" what it was.

The point about lint was that because it only did the optional static checks it could afford to be more "noisy" and produce a lot of "maybe" type errors that a compiler would not do (then).

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 9:54 am

I'm totally with the lint idea.

It's just that at the time I was using C for the first time. I had never heard of lint. The sloppiness of MS C was not what I was used to after Algol 68.

Perhaps I have selective memory but my Algol programs might produce a wrong result or fail with some kind of error if I made a mistake but they never silently crashed and had me wondering WTF?

Of course when you are preparing your code on punch cards and it takes all night to get the results of a run back you tended to check and double check you code before handing your card deck over to the operators.

Getting stuck in and endless loop would consume your allocation of CRU's (Computer Resource Units) which as a mere undergrad student were in short supply.

Oh, the answer to the original question "Why Avoid BASIC on RPi?" was in my mind when I woke up this morning.... For the same reasons we avoid BASIC everywhere else of course :)
Memory in C++ is a leaky abstraction .

User avatar
PeterO
Posts: 5623
Joined: Sun Jul 22, 2012 4:14 pm

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 2:48 pm

Debugged Algol-60 Fibonacci programme has been run successfully at TNMOC today on the original Elliott 803 hardware :-)

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 3:40 pm

PeterO,

Fantastic. Well done! I hope there was an audience to be suitably impressed.

How long did it take to run?

I really must get over to TNMOC one day. I'd love to meet you there. Bit tricky as I'm stuck in Helsinki now a days.

How much free memory space does the 803 have? Can we squeeze out a few more digits?

I think what we need here is an Eliot 803 architecture implemented in Verilog for FPGA!

I find it amazing one can get a compiler running in a machine with 8192 words of 39 bits each. And they think Bill Gates is smart for his BASIC. Pfft..

I want to see that ALGOL 60 compiler running on my own little Eliot 803.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 5:18 pm

heater wrote:I find it amazing one can get a compiler running in a machine with 8192 words of 39 bits each.
Yes it is impresive by modern standards. Though there are many compilers that run on a lot less.

I wonder how people would look at things if they had recent experience developing software on one of the 8-bit systems that had a total of 8KB (or less) of RAM and 4KB of ROM? That is using such a system for the development as well as the target.

It is true that it takes a lot more work to figure out how to get it done when you are working on a more limited system, and thus it is more impressive.

I think that if software authors really thought about the resources they are using, we would have software that is just as capable as what we do have, though runs quite faster (many reasons for the slowness) and takes a lot less RAM and disk space than what we do have. This is the reason I will very often use low end emulators to test what I make, to be sure that it runs acceptable on HW that is 100 times slower than it will ever be used on.

ejolson wrote:Any progress fixing the big number addition routines for BBC BASIC?
Yes, I just need to take the time to make sure it does not contain any face-palm obvious bugs.

I am guessing you have not been looking at my OS web site, I have been quite busy last few days, and that is not including the normal daily things that I have to do.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 6:24 pm

DavidS,
Yes it is impresive by modern standards. Though there are many compilers that run on a lot less.
Do you have any links to examples? Not that I don't believe you but "many" and "lot" seems very implausible.
I think that if software authors really thought about the resources they are using, we would have software that is just as capable as what we do have, though runs quite faster (many reasons for the slowness) and takes a lot less RAM and disk space than what we do have.
Thing is, over the past few decades processors have doubled in speed every two years or so. "Mores Law" bla bla. Similarly memory speed and capacity was growing exponentially. Even good old magnetic storage with its mechanics was keeping up.

Meanwhile software creators have consumed all that performance as they provide what users think they want, more features, higher resolution graphics, better sound etc, bigger data sets, etc.

Recently all of that hardware performance growth has stalled as we hit the limits of what is economically and physically possible. We cannot expect such dramatic growth in performance in the future.

It will be interesting to see how the software world responds to this new hardware reality.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 6:57 pm

DavidS,

So I was thinking about your comments re: software "bloat" and speed and such....

Over there in the hardware world the guys have been providing us with machines that doubled in speed every two years or so. Similarly memory speed and capacity has been doubling every two years or so.

What about the software guys?

I think you could spend forever honing your algorithms in assembler or developing compilers to do it for you. Which is what has been happening. But you will never be doubling the speed of your code every two years like the hardware guys have been doing.

Only occasionally does this dramatic jump in software performance happen. For example:

1) When Cooley–Tukey came up with the Fast Fourier Transform in 1965 they increased the performance of solving that important problem by orders of magnitude:
https://en.wikipedia.org/wiki/Cooley%E2 ... _algorithm

2) When Tony Hoare came up with Quick Sort algorithm in 1959:
https://en.wikipedia.org/wiki/Quicksort#History

3) Closer to home. The speed of the fastFibo algorithm I have used here is down to some clever mathematical insight. I have no idea where that originates but for sure tinkering around with optimizing the naive algorithm would never get the job done so fast.

What am I hinting at here?

Software engineers cannot solve the performance problem by tweaking their code in assembler or whatever.

No, they need the break throughs of mathematicians and such. Which are kind of rare it seems. If they are possible at all.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 7:47 pm

Do you have any links to examples? Not that I don't believe you but "many" and "lot" seems very implausible.
Unfortunately I do not at this time. Though if you look for pre-1980 8-bit personal computer hosted compilers you will find that there are more than one would expect, a few that even ran on CP/M on systems with only 8KB of RAM.

I may look up some of them again in the near future.
Thing is, over the past few decades processors have doubled in speed every two years or so. "Mores Law" bla bla. Similarly memory speed and capacity was growing exponentially. Even good old magnetic storage with its mechanics was keeping up.

Meanwhile software creators have consumed all that performance as they provide what users think they want, more features, higher resolution graphics, better sound etc, bigger data sets, etc.

Recently all of that hardware performance growth has stalled as we hit the limits of what is economically and physically possible. We cannot expect such dramatic growth in performance in the future.
Well on that note see my most recent blog post, form this morning:
https://asmfun.riscos.fr/blog.html

It is a quick little statement of my personal frustration on the wasting of resources.

That is an area where we agree to a point.

There are many poorly chosen algorithms for various tasks. These are where the problems come from in most cases in my view. Like having rediculous amounts of disk access, because resources that should be in RAM are kept on disk instead. Or wasting RAM when a different algorithm would be just as fast for the job and use less RAM, or of course with speed of processing.

You have a point on the math, in some cases.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 8:31 pm

Ah yes,

There was the BDSC C compiler by Leor Zolman for CP/M. That required a full up 64K machine I think.

There was Tiny Pascal for the TRS-80.

Before any of that the there was a PL/M compiler for the 8080 by Garry Kildal and shipped by Intel.

All of that was long after the Eliot 803. And the 803 effectively had about 64K RAM but no instructions to handle character sized things. Which must have made a language parser challenging and space consuming.

I do have a point on the math in some cases because there are very few such cases! The big leaps in software performance have been few and far between.

Yes I read your blog post. Whilst we can all agree with the sentiment there is nothing concrete of use there.

It's an open source world now a days, if you have ideas to optimize things then just submit your patches to whatever project you fancy. Firefox, Chrome, the Linux kernel, X Windows, whatever.

Meanwhile... I have been toying with the idea of implementing our fastFibo algorithm in C that uses no non-standard libraries. You have to promise me you will attempt to reproduce the same in whatever BASIC before I think about starting.
Memory in C++ is a leaky abstraction .

stevend
Posts: 235
Joined: Fri Oct 11, 2013 12:28 pm

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 8:42 pm

Heater wrote:
Sun Nov 25, 2018 8:31 pm
There was the BDSC C compiler by Leor Zolman for CP/M. That required a full up 64K machine I think.

There was Tiny Pascal for the TRS-80.
There was a standards-compliant Pascal Compiler for the Z-80 by a small British company called Prospero Software - ran under CP/M. Very good quality, with the ability to turn various error checks (including range checks) on and off. Delivered on an 8" floppy disc. Took three passes to compile the code, saving intermediate files to disc (no mean feat if you only had a 220kbyte floppy!). Compiling became a lot faster when 10Mbyte hard drives became available....

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 8:50 pm

Heater wrote:
Sun Nov 25, 2018 8:31 pm
Ah yes,

There was the BDSC C compiler by Leor Zolman for CP/M. That required a full up 64K machine I think.

There was Tiny Pascal for the TRS-80.

Before any of that the there was a PL/M compiler for the 8080 by Garry Kildal and shipped by Intel.

All of that was long after the Eliot 803. And the 803 effectively had about 64K RAM but no instructions to handle character sized things. Which must have made a language parser challenging and space consuming.

I do have a point on the math in some cases because there are very few such cases! The big leaps in software performance have been few and far between.
Depends on which way you are leaping? If leaping to lower performance it has happened many times, and often.

A good complete configurable syntax highlighting, folding programmers text editor, with the ability to shell out a compiler through a simple menu selection, and has no limit on file size, used to be about 5 times faster on HW that was 5 times slower, also used to take about 20 times less RAM for the same work. Now the new ones that take so much more do not do a single thing the older did. For example the old full screen DOS and Linux SEDIT, which was completely mouse driven and did have shortcuts for all. It was more capable than most of the modern ones with less functionality.
Yes I read your blog post. Whilst we can all agree with the sentiment there is nothing concrete of use there.
I attempt to avoid specific case examples in my BLOG when I am writing about what I feel is wrong with modern software development.

I suppose it may be worth the venture to go into a few specific cases for that purpose. Perhaps for tomorrows post.
It's an open source world now a days, if you have ideas to optimize things then just submit your patches to whatever project you fancy. Firefox, Chrome, the Linux kernel, X Windows, whatever.
Actually there are some good efforts out there by some people to produce more reasonable software. Many of them in the retro community, though much of what they produce is still valid to more modern systems. Firefox, Chrome, Linux, X are all fairly large projects, though fun to play in from time to time. What ever happened to all the up to date lightweight web browsers (the HTML5 complaint browsers that would run well in less than 64MB and fast on a 200MIPS CPU) from only 6 years ago? OWB being my favorite, though does not seem to be updated anymore.
Meanwhile... I have been toying with the idea of implementing our fastFibo algorithm in C that uses no non-standard libraries. You have to promise me you will attempt to reproduce the same in whatever BASIC before I think about starting.
I can give my word that what ever algorithm you come up with in C I will gladly reproduce in BASIC. I expect the C version to be a little faster, just because not as many people are working on optimizing BASIC Compilers as are on optimizing C Compilers.

And I will one better for you, and do it in FreeBASIC (as it is not as much of a moving target as most other BASICs, and easy on any Linux). Just for you.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
PeterO
Posts: 5623
Joined: Sun Jul 22, 2012 4:14 pm

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 8:54 pm

2) When Tony Hoare came up with Quick Sort algorithm in 1959:
https://en.wikipedia.org/wiki/Quicksort#History
[/quote]
Which is just before he started work on the 803 Algol-60 compiler at Elliotts. The two are slightly interwoven as the Algol (with it's support for recursion) may have been the first way he was able to implement quick-sort :-)
There was the BDSC C compiler by Leor Zolman for CP/M. That required a full up 64K machine I think.
I used to run that on my Z80 CP/M machine. It was rather slow :-) I also had the HiSoft C compiler for CP/M.
All of that was long after the Eliot 803. And the 803 effectively had about 64K RAM but no instructions to handle character sized things. Which must have made a language parser challenging and space consuming.
8K words of 39 bits is just under 40K bytes. 803 Algol symbols were limited to 6 significant characters, which could then be packed (6 x 6 bit character) into one word. And although the 803 has 8K words, there are two instructions in each word (what a crazy machine I hear you cry!) , so when thinking about code size it is more like an 16K machine.

The two pictures show (from my emulator) show the core store with just pass 2 and the run time loaded and with pass 1 and pass 2 and the run time loaded. For large programmes the output from pass 1 (called "own code") could be output to paper tape and then read back in with just pass two of the compiler loaded.

One day I will release my 803 emulator and you'll be able to watch and listen to the compiler running :)

PeterO
Attachments
A104Tape2.png
A104Tape2.png (15.09 KiB) Viewed 1766 times
A104Tape2.png
A104Tape2.png (15.09 KiB) Viewed 1771 times
A104.png
A104.png (51.3 KiB) Viewed 1771 times
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 9:46 pm

PeterO,

Odd you should bring up that Quick Sort - ALGOL connection.

That thought had crossed my mind some years ago when I was contemplating that QuickSort is a recursive thing and ALGOL was perhaps the first high level language to support recursion. And both arrived on the scene about the same time.

My thought at the time was that the programming language a programmer has forms and perhaps limits what that programmer can think of doing. Which I still think is true.

Then I thought, ALGOL allowed the expression of recursion so a guy like Tony Hoare could think of recursive solutions. Hence QuickSort.

Then I found out Tony Hoare was behind both of them !

Looks more like Tony Hoare had this recursion idea in mind and wanted the ALGOL language to be able to express that.

Genius!
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 9:53 pm

Very interesting. How many systems at that time were able to support recursion easily? As memory serves (I could be off) a lot of systems at the time did not have hardware stacks, using other means for call returns that were often non-reentrent in nature.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
PeterO
Posts: 5623
Joined: Sun Jul 22, 2012 4:14 pm

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 9:57 pm

Heater wrote:
Sun Nov 25, 2018 9:46 pm
PeterO,

Odd you should bring up that Quick Sort - ALGOL connection.

That thought had crossed my mind some years ago when I was contemplating that QuickSort is a recursive thing and ALGOL was perhaps the first high level language to support recursion. And both arrived on the scene about the same time.

My thought at the time was that the programming language a programmer has forms and perhaps limits what that programmer can think of doing. Which I still think is true.

Then I thought, ALGOL allowed the expression of recursion so a guy like Tony Hoare could think of recursive solutions. Hence QuickSort.

Then I found out Tony Hoare was behind both of them !

Looks more like Tony Hoare had this recursion idea in mind and wanted the ALGOL language to be able to express that.

Genius!
My copy of the 803 Algol manual is autographed by the three authors :-)

PeterO
Attachments
803A104Sigs.jpeg
803A104Sigs.jpeg (46.96 KiB) Viewed 1735 times
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 10:14 pm

PeterO,

Wow, that is precious!
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 10:29 pm

@Heater:
I am looking forward to converting that C version that you spoke of. I will convert it to FreeBASIC as stated. If I happen to be on RISC OS when you post it I will use the DOS version of FreeBASIC in DOSBox, and first do a version in BBC BASIC.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 10:34 pm

DavidS,
Very interesting. How many systems at that time were able to support recursion easily? As memory serves (I could be off) a lot of systems at the time did not have hardware stacks, using other means for call returns that were often non-reentrent in nature.
Let's not confuse hardware capabilities with software ideas.

My take on it is that at some time the mere idea of a subroutine or procedure was new. You want to run the same instructions from various places in your code...

OK, let's have the hardware allow you to jump to those instructions and remember where to jump back to when they are done. No stack, just a place to store a return address.

That is brilliant for a lot of work but then comes the mind twister...

I want to run the instructions I am currently running to run again. Recursion.

That is an algorithmic or software idea. It can be done even without specific hardware support. In the same way software can have a multiply even if the hardware does not.

Naturally hardware soon adopted stacks and subroutine calls etc.

Conceptually the idea of recursion is a big jump. Even today many resist it. As you do I believe.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 10:36 pm

DavidS,
I am looking forward to converting that C version that you spoke of
Oh shoot. That means I actually have to get it working!

Challenge on !
Last edited by Heater on Mon Nov 26, 2018 6:48 am, edited 1 time in total.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Sun Nov 25, 2018 10:38 pm

DavidS wrote:
Sun Nov 25, 2018 10:29 pm
@Heater:
I am looking forward to converting that C version that you spoke of. I will convert it to FreeBASIC as stated. If I happen to be on RISC OS when you post it I will use the DOS version of FreeBASIC in DOSBox, and first do a version in BBC BASIC.
As I never seem to get very much done when using Linux, my mind and hands are more accustomed to the way things are in RISC OS.

Though it could be fun to try compiling the result for the FreeBASIC version in QucickBASIC for the Macintosh, on an 8MHz Macintosh Plus (or maybe a 16MHz LC if it needs more than 3MB free RAM). that could take a bit to run, though you say it is a fast version. I am going to be careful to make sure the FreeBASIC version can be compiled on as many potential BASIC versions as possible (FreeBASIC, AmigaBASIC, QuickBASIC for Macintosh, QB64, etc).

Which brings up the commands in QuickBASIC for the Macintosh for dealing with GUI Windows, Menus, Mouse, Buttons, and Clipping. These are commands that would make a great base for a universal GUI library for just about any language, and could be easily implemented in a low over head way. That could be what is needed to get some tracktion towards a standard GUI lib for the next C version :) . Also note that many of these commands are the same on AmigaBASIC (same version of MS-BASIC from what I can tell).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

ejolson
Posts: 4461
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 12:38 am

Heater wrote:
Sun Nov 25, 2018 3:40 pm
I find it amazing one can get a compiler running in a machine with 8192 words of 39 bits each. And they think Bill Gates is smart for his BASIC. Pfft..
Microsoft Basic occupied 4096 bytes of 8 bits each and included a full floating point library with support for the common transcendental functions. Although the floating point library was limited to single precision and did not support arbitrary precision arithmetic, in my opinion it is the distinguishing feature that made Microsoft Basic popular in education and other application areas compared to the integer-only arithmetic in other microcomputer programming languages. It is interesting that neither Bill Gates nor Paul Allen wrote the floating point code in Microsoft Basic, but rather contracted those routines out to Monte Davidoff. Note that a compiler generally needs less memory than an interpreter because compilation can be done in passes and the compiler does not need to be resident in memory while the program in running.

Artists are familiar with the use of what is called an artistic constraint. Unix was developed on a machine that had a combined program and data address space of 64K bytes. Therefore the Unix philosophy of do one thing well was motivated in part by hardware constraints. Another hardware constraint that later led to improved software design was the fact that the video display terminals used to create the editor vi did not have function or dedicated cursor control keys. Of course an artistic constraint can also go wrong as demonstrated by the near and far pointers of Intel x86 mixed memory model C programming.

The value of recursion for expressing and reasoning about algorithms was known long before digital computers existed. As Algol was originally intended to be a theoretical programming language used to describe published algorithms in a way suitable for people to understand, including recursive constructs was mathematically natural. As computers became more powerful, it became possible to make practical programming languages for computers that were closer to the abstract languages used to communicate between people. The direct implementation of recursion via stacks turned out to be surprisingly efficient. Call by name and some of the ideas of functional programming turned out to be more difficult.

I'm finding this to be a very interesting thread full of history and ideas for the future. I'm also looking forward to more code for big number arithmetic.
Last edited by ejolson on Mon Nov 26, 2018 1:16 am, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 1:02 am

ejolson wrote:
Mon Nov 26, 2018 12:38 am
Microsoft Basic occupied 4096 bytes of 8 bits each and included a full floating point library with support for the common transcendental functions.
4K BASIC had to ditch string support to fit that in, so it wasn't too useful an interpreter.

While I wish there were a built-in language on modern computers the immediacy of a ROM BASIC's

Code: Select all

Ready
█
prompt, none of the modern interpreters have enough built-in features to be an effective scripting language.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 2:05 am

scruss wrote:
Mon Nov 26, 2018 1:02 am
ejolson wrote:
Mon Nov 26, 2018 12:38 am
Microsoft Basic occupied 4096 bytes of 8 bits each and included a full floating point library with support for the common transcendental functions.
4K BASIC had to ditch string support to fit that in, so it wasn't too useful an interpreter.

While I wish there were a built-in language on modern computers the immediacy of a ROM BASIC's

Code: Select all

Ready
█
prompt, none of the modern interpreters have enough built-in features to be an effective scripting language.
What do you consider an effective scripting language? On RISC OS you do have BBC BASIC V built in to this day, and it can run any command, it can make system calls to create windows, or use system calls to perform networking operations (BSD Socket style TCP/IP API), or it can do just about anything else, and it is a fairly fast interpreter.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

ejolson
Posts: 4461
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 4:02 am

DavidS wrote:
Mon Nov 26, 2018 2:05 am
scruss wrote:
Mon Nov 26, 2018 1:02 am
ejolson wrote:
Mon Nov 26, 2018 12:38 am
Microsoft Basic occupied 4096 bytes of 8 bits each and included a full floating point library with support for the common transcendental functions.
4K BASIC had to ditch string support to fit that in, so it wasn't too useful an interpreter.

While I wish there were a built-in language on modern computers the immediacy of a ROM BASIC's

Code: Select all

Ready
█
prompt, none of the modern interpreters have enough built-in features to be an effective scripting language.
What do you consider an effective scripting language? On RISC OS you do have BBC BASIC V built in to this day, and it can run any command, it can make system calls to create windows, or use system calls to perform networking operations (BSD Socket style TCP/IP API), or it can do just about anything else, and it is a fairly fast interpreter.
Instead of built-in features a scripting language could also assemble features provided by external programs and subroutines. How hard would it be to rewrite most Unix shell scripts in Basic?

Wouldn't it have been nice if, instead of replacing those confusing System V init scripts by a huge C program, that those systemd programmers would have written a collection of easy to understand startup scripts in Basic.

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

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 4:44 am

DavidS wrote:
Mon Nov 26, 2018 2:05 am
What do you consider an effective scripting language? On RISC OS …
Something like Perl or Python: it'll allow me to dig about in deep and messy structures without having to bother me with memory allocation. Maybe store stuff in a SQLite or Spatialite database: take a query and spit it out in the the vector data format of my choice for further transformation in (say) OpenSCAD. The language doesn't have to be super fast or pure: just no limits. F'rinstance, I just realized that the database I looked at for neighbourhood buildings is around 2.6 GB, but Python didn't complain.

RISC OS is such a productivity killer for me: single core, no wifi, broken multitasking, only runs on small hardware, the most unusual GUI ever. I know you're very partial to it, but it's a fast nope for me.
ejolson wrote:
Mon Nov 26, 2018 4:02 am
How hard would it be to rewrite most Unix shell scripts in Basic?
I know that the first bootstrap Unix commands were written in Fortran, 'cos back in the day most computers shipped with a Fortran compiler. HP used to write a lot of their system stuff in Basic dialects. But I'd hate to think of how Basic shell scripts would handle big data with mixed Unicode data.
Wouldn't it have been nice if, instead of replacing those confusing System V init scripts by a huge C program, that those systemd programmers would have written a collection of easy to understand startup scripts in Basic.
If you want AppleDOS 3.3, you know where to find it. ☺
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

Return to “Off topic discussion”