Just to clarify things for myself, nothing more. Personally I'm result-oriented person, so as long as BASIC suits all my needs, I'm not considering wasting time on learning something else.
Just to clarify things for myself, nothing more. Personally I'm result-oriented person, so as long as BASIC suits all my needs, I'm not considering wasting time on learning something else.
Haha! I must NOT be result oriented I have trouble using 'wasting' and 'learning' in the same sentence unless it's, "I'm wasting an opportunity by not learning what this person/situation/event is able to teach me."
I see you are still asking for an example, having ignored my post #14. For your convenience I reproduce part it here.
But as you have put your question as a challenge about performance I present my Fast Fourier Transform in C. It's a rude and crude FFT but works pretty well. Runs on any machine for which there is a C compiler. On the Propeller it can automatically make use of 1, 2, 4 or even 8 COGs to boost performance. It is impossible that any BASIC FFT is as quick or can easily use multiple COGs.
I've ignored it because I see no logical connection between specialised hardware architecture and programing languages comparison?
The way propeller is designed, why that applies to languages? and if propeller can run BASIC on it's cogs, will be there any difference at all?
btw, FFT using basic is possible, just google for that, there are numerous examples doing realtime FFT in BASIC, on chips much weaker than propeller.
Basically I agree with most of what you have posted here, just saying that's not an apt comparison, and in this case a good comparison is hard to find. I feel that the best language for those of us who are not full time programmers is the language we already know as long as it can do what we want it to do.
I've ignored it because I see no logical connection between specialised hardware architecture and programing languages comparison?
You will have to elaborate on that. I do not understand what you mean. Who said anything about "specialised hardware architecture"here ? There is nothing specialized about the code I presented, it has been run on many different machines under many operating systems (or none).
Your opening post asks "...can someone provide some simple task, and code in C and BASIC, so it will be possible to see, why C is better than BASIC ?" I have presented such a simple task and a C solution. Sorry I don't have a BASIC solution.
I have no doubt there are FFT's in BASIC. In fact the first FFT code I ever saw was in BASIC and ran on my Atari ST 520.
I'm looking forward to someone presenting an FFT in BASIC that runs on the Propeller for comparison.
Do you have a link to an example of realtime FFT in BASIC, on chips much weaker than Propeller?
Well, I was doing it on ZX Spectrum (Z80 CPU, 3.5mhz clock), but using basic compiler, called M.CODER2, but for obivous reasons, I can't provide the code
There is no source code of an FFT in BASIC at the link you provided. There is a BASIC compiler for the PIC that seems to include FFT functions, no doubt written in assembler.
I'm not about to spend £125 + VAT to try it out.
By the way, reading the example "BASIC" code there it strikes me how not BASIC it is, how similar to ALGOL like languages it is. It even has includes and defines like C. Why would you be so adverse to C if you can live with that?
I've often hear that C is way better than basic, because it is faster and more robust language. Indeed, C WAS FASTER once ago, when there was compilers for C and interpreters for BASIC. But currently, both being very effectively compiled. So I'm interested, can someone provide some simple task, and code in C and BASIC, so it will be possible to see, why C is better than BASIC ?
I've also heard the "compiled basic can be as fast as C" argument since the 80s. I also understand that basic has become to be considered a "toy programming language". Personally I don't see considering basic a "serious" language in the same league as a language like C until it supports things like pointer, structures, while loops, dynamic memory allocation, etc.
I personally have no interest in pitting C up against basic for "some simple task". I'm not sure what writing a for loop that output the numbers 1 - 10 in C or basic will prove anything. Lets try writing an in-memory database and see how basic does? If you like basic and it does what you need than use basic!
LOL....You won't find an answer to this question but you have succeeded in exposing the ignorance of those who have not kept with the times, once again!
I had to detach myself from programming at one point because I had to run my company. I insisted on sticking with BASIC when I hired *real* programmers and the end result is that I can actually not worry about them moving on and being left with unreadable code. The irony is that I still know several of my ex-programmers and guess what....they stuck with BASIC! I am not talking VB, I am talking PowerBASIC with its pointers, structures, etc., etc.
This is one - not the only one - compiler that can generate non-bloated code with no external dependencies and can do anything that C can do and generates executables that easily compare with C.
If PropBASIC had the benefit of the resources being poured in to other Prop languages, we would have one heck of a tool!
Code portability? What a joke! All dialects of BASIC are so darned similar that any critical code can be ported very easily....it's a Monday/Tuesday issue in my experience.
...you have succeeded in exposing the ignorance of those who have not kept with the times, once again!
I would not be so quick to bandy charges of ignorance around here. This forum is populated with many experienced and skill full people who are quite in touch with modern times.
PowerBASIC may be the best thing since sliced bread for the work you do. That is all well and good.
I have a couple of issues with it, these issues may not matter to you and many others but they are critical to me:
1) PowerBASIC does not work on any platform I need the code I write to run on. From embedded systems to cloud services.
2) For my own personal use, even if it did work on my machines, 200 dollars is hard to justify for such a limited tool. Especially as there are a dozen other languages and compilers to choose from that equally or more effective. That's a lot of Propellers!
3) Where is the ANSI or ECMA or other standard language definition for it? I know there is ANSI X3.113 but that dates from 1987 so I guess is not applicable.
4) If as you say portability is not an issue what is the PowerBASIC compatible compiler for Mac, Linux, BSD and other systems?
Code portability? What a joke! All dialects of BASIC are so darned similar that any critical code can be ported very easily....it's a Monday/Tuesday issue in my experience.
Given my experience with incompatible BASIC dialects, and the fact that PowerBASIC is for Windows and DOS, this strikes me as a dubious claim. As Heater points out the one standard predates most newer dialects with modern features.
@Heater, there is B4J which is a BASIC that targets the JVM. That lets you target any platform that has a JVM, but at that point you would probably be happier writing in Java. Although you wouldn't be happy about that. The same company has B4A and B4i which target Android and iOS, but they have per seat fees. The Android Java tools are free, so I can't imagine it has much of a user base.
If it comes to portability, COBOL is your friend. The language was developed with exactly that in mind from the beginning. They had to. There was no common OS as we know of today. Every computer manufacturer did his own stuff. And COBOL was there to run everywhere.
It did and it does today, some 53 years later.
God bless Rear Admiral Grace Hopper. What a astonishing woman. I wish they would still breed women like that.
The run time was 202ms (according post #50 in the above thread).
For sure you can put the result on github, but the BASIC compiler was never released. My plan was to rewrite it in PropGCC, but not found the time so far...
The issue of interpreted vs compiled has been brought up here many times. It's not so cut and dried. Many BASICs can be compiled to efficient native code. There are interpreters for languages that are normally compiled. Like this C++ interpreter https://root.cern.ch/drupal/content/cint
C is better than Basic simply because you can write a Basic Compiler in C and get as good results
That is not a sound argument for C. Whilst I guess most BASIC compilers are actually written in C/C++ conceptually it is possible to write a BASIC compiler in BASIC in the same way that a C compiler can be written in C. Does anyone know of a BASIC compiler in BASIC?
Or just maybe Basic is better simply because you can write a small interpreter in less space that C.
I'm not sure what you mean there.
On the one hand imagine: In an interpreter system I will have in memory, the interpreter (I), my BASIC program (B), and the data my program works on (D).
Clearly if I throw away I and B and replace it with native code I can get a lot more functionality into the space that I and B occupied. Faster too!
Where would that native code come from? Perhaps from C source compiled on a host machine. Or perhaps from BASIC code compiled on a host machine, like the PIC BASIC compilers that are available.
On the other hand if you actually want an interpreter, especially an interactive one, perhaps BASIC is the way to go. Other would suggest Forth of course.
But then this is not a debate about the actual language any more.
... conceptually it is possible to write a BASIC compiler in BASIC in the same way that a C compiler can be written in C. Does anyone know of a BASIC compiler in BASIC?
I don't really think it's about interpreted vs. compiled, not really. I do my share of time-critical development (and hunting for the highest-clocked Xenon CPU in the process..), but when I decide which language to use it's more about how I can express my program in the best way. And part of the problem (or possibly the single problem) is that CuriousOne said "BASIC", but didn't specify. When you say "BASIC" it forces the rest of us to go back to what was originally called BASIC, and that's Dartmouth BASIC. The original was actually a compiler, not an interpreter! The later BASIC interpreters (although the mini at school actually used a compiler -- read from a 10-inch roll of paper tape) many of us got exposed to implementation variants which stayed close to the Dartmouth syntax. Including Microsoft BASIC as found on Altair, Commodore, as AppleSoft BASIC etc.
And this BASIC doesn't have any facilities for structured programming, just to mention a single (for me) necessary feature of any high-level programming language.
Consider this simple C program which doesn't even use pointers:
The above isn't even something C is particularly good at.. but it has:
Real function calls. Not 'GOSUB 40' or whatever.
Functions can take parameters.
There is a type system: You can define new types.
You can define a record and pass that one around as any other variable (not even using a pointer (address)).
No line numbers.. if you want to insert a line of code you don't have to re-number all the lines in case there aren't any free numbers in between where you insert code.
I'm not including a version written in BASIC, because it's not possible to write it that way in BASIC! Before changing to a structured language I had to beat out that kind of functionality by not using records, by not using function calls (only gosub), by not defining types, and I hated that. After some time at least, when I saw how difficult it became to maintain and expand the mess.
I decided to do some more formal research and looked up the ANSI/ISO/ECMA standards for BASIC. There are two: The 'minimal' version ANSI X3.60-1978, maybe easier to find as ECMA-55 (it wasn't actually ready until 1983), and 'Full BASIC (ANSI X3.113-1987)', close to ECMA-116.
The 1978/1983 version is from what I can tell simply Dartmouth. 'LET' is there, line numbers are there (not even optional: "Each line shall contain a unique line number"), functions are just rudimentary - not much better than a simple C preprocessor macro:
DEF FNF(X) = X^4 - 1.
For the rest you have 'GO SUB (aka GOSUB), and no function parameters of course - just global variables.
Hm, it even states "The letters shall be the set of upper-case Roman letters contained in the ANSI[/i, depending on source] 7-bit coded character set [..]".
It has arrays (as BASIC always did), but not records.
Over to the 'full' version (wow, more than 200 pages). There are some improvements:
Lower-case letters are allowed
More loop control structures (DO .. LOOP UNTIL etc.)
A CASE mechanism (not too unlike what's in C and Pascal)
Some sort of subroutine support and what they call subprogram support. It's infinitely better than not having them, but why the long list of special words to support this.. they made it very complicated indeed.
And that's all. The rest is just much more built-in functions compared to the minimal version. There's no type system, there's no support for record types (not to be confused by the 'record' mechanism of its built-in file handling support). Even line numbers seem to still be mandatory. The best part of this language definition seems to be the loop control mechanisms, they seem to cover anything you could find elsewhere. Very flexible. However, this language is not good enough for even the simple C program above - you can't code it in a similar fashion.
There are other languages out there with BASIC or Basic as part of their names.. PropBasic, PBASIC, FemtoBasic, to mention some relevant ones for this forum. You have BBC BASIC (which is structured), FreeBASIC, and so on and so forth. But they are not BASIC. They have much less in common than FORTRAN IV, FORTRAN 66, Fortran 77, Fortran 95 have in common (but note how I left out Fortran 2000 there..).
So if you want to compare C with e.g. PropBasic, then it's best to say so, and then we can compare. Or protonbasic, which wasn't mentioned until page five of this thread.
Actually the FFT example is a kind of programming problem where the limitations I have discussed don't really apply.. it's just a computation problem. If you just want to add and multiply some numbers, then BASIC, or any of the <something>Basic languages, is as good as C and the rest - it's just a matter of degree and efficiency, which isn't what I have been looking at in my posts to this thread.
I agree the FFT, despite the head scratching maths behind it is just a bunch of simple arithmetic and loops that could probably be expressed just as well in Dartmouth BASIC. It does not require the niceties of a structured language.
I threw that FFT into the mix because CuriousOne's opening post, emphasises speed, as do his later ones. That FFT is a short, self-contained example C as he asked for.
You're right - he did mention speed, although my own reasons for why C (or Pascal or Fortran or Algol or D or even BCPL. And Spin) is better than BASIC are about other issues (as I outlined). I see speed as a red herring really, because you can always make a fast version of anything. If, for example, your FFT in BASIC doesn't run fast enough, then write a limited version of BASIC which compiles that particular code to the fastest FFT possible (obviously you'll write that special compiler in C, but I digress..). Or just use another faster pre-made compiler (but be prepared to modify the syntax a bit, as they differ).
As a side note I came over a 2013 post over on the freebasic forum which nicely summed up *why* C is so compatible with itself:
The situation with C and C++ and its stringent and often implemented formal standards is fundamentally different from standards of other languages.
This because C was tied to Unix from the very earliest, and Unix applications were only source recompilable. The large existing base of C product sourcecode made the standards process extremely conservative and lowest common [denominator], but on the other hand standards-use very widespread.
And Unix had this key difference with many other operating systems in that its command-line "commands" were all just user-level applications external to the core, so there was immediately a huge amount of widespread source out there.. and it all had to compile. You can fiddle with the syntax of a couple of files to get it to compile with "your" compiler, but you just can't do that with the whole world of Unix applications.
(I'm not sure if C++ should have been included there, C++ plays no role in Unix and indeed it's infamous for being incompatible with itself even from one version to the next. Maybe it will be stable after C++14).
Is its syntax similar to the one in my ANSI 1978/1983 example, "DEF FNF(X) = X^4 - 1"? Because that's not a function, it's equivalent to a C preprocessor macro:
#define F(X) pow(X,4) - 1
(and yes right there there's a weakness in C (but not D) compared to BASIC: No 'power' operator so you need a library function).
The problem with a DEF FN style 'function' is that it's so extremely limited. It's really just a macro. And that's why a more complete subroutine/function system was added to the 1986/1987 standard, but as I described earlier this still doesn't let you implement the sample I wrote in C.
It defines a new type 'person', which is a record-type holding certain values related to a person. Then there are a number of functions which take a variable of that type as input (parameter), and prints a value. One function prints the name, another prints the age, and so on. Finally the 'main' function, which is what gets called first when the program is started, defines a variable which is called 'salesman', it is of type 'person', i.e. a record, and assigns values to it. Then it calls a set of functions to output different parts of that record. A run looks like this:
Mostly, the dilemmas of selection are due to programability and the ability to abstract machine code into something else. The actual scope of what one can do on a computer is likely more than anyone can completely master. There are just too many alternative uses and alternative tools.
Each and every language has a choice as to the scope of its content, leaving the end-user to extend it further with additonal tools. Some languages are merely analogous to a screw-driver; while others are analogous to a whole hardware store's worth of tools.
So how does one decide the scope of a language?
A. Focus on the fundamental concepts of good programing -- looping, conditionals, testing, incrementing, i/o management, and so on OR Attempt to provide all and everything
B. Select a mode of use --- compiled, interpreted, tokenized, ?
C. Provide a particular creative environment --- graphics, word processing, animation, engineering, music composition, develop a web site, etc.
My best guess is that if computer education was properly taught, all these 'which language is better' questions would just fade away. We suffer from a very commercialized view of computer language selection rather than a utilitarian pragmatic view of selection.
And sadly, human psychology seems to make mavens of those than have mastered a language. So when you ask someone which is good, they are adamant that the one they know is the best.
I simply have settled for a few adequate and worthy of investing a lot of time in learning. In my opinion, SPIN is a worthy language, so are PYTHON, C, Forth, and a few others.
Basic has always had introductory appeal, but while PBasic is certainly an introductory Basic; others are anything but introductory.
One doesn't have to program an Arduino Uno with their C/C++, there is ZBasic that will provide competatively sophisticated compiler on the same silicon.
See www.zbasic.net
My gut feeling is this is more about time management and determining one's goals in learning computer. We all have to spent a lot of time learning a few languages and ignoring many others as distractions ... in order to learn anything at all.
Are we merely selling training wheels to everyone, pushing a personal preference, or are we offering real insight in how to enjoy life-long learning about programing?
I really wonder if performing an FFT offers anything meaningful for a generalized language. How many of us really need to calculate FFT? And if we do, how many of use desire to use a microcontroller to do so with limitations of speed and memory?
Most of what I do on a computer is email, text processing, searching, reading documents, and money counting. Since the programs and apps are all well-developed and free; my programing is primarily tinkering with odd-ball stuff. And generally, C is a distraction for my kind of tinkering.
Though I like Python and BASH, I rarely get around to doing anything in either. Of course, there are some computer polyglots that just love to learn yet another language just to make the rest of us feel like Forrest Gump.
Comments
What are your goals? This will add value to the discussion.
Haha! I must NOT be result oriented I have trouble using 'wasting' and 'learning' in the same sentence unless it's, "I'm wasting an opportunity by not learning what this person/situation/event is able to teach me."
I see you are still asking for an example, having ignored my post #14. For your convenience I reproduce part it here.
But as you have put your question as a challenge about performance I present my Fast Fourier Transform in C. It's a rude and crude FFT but works pretty well. Runs on any machine for which there is a C compiler. On the Propeller it can automatically make use of 1, 2, 4 or even 8 COGs to boost performance. It is impossible that any BASIC FFT is as quick or can easily use multiple COGs.
https://github.com/ZiCog/fftbench/blob/master/fftbench.c
Edit: I use the word "impossible" above in the usual sense of the word on this forum.
Well there is the thing. You have not stated what your needs are. Therefore it's impossible to define "better" for you, therefore we cannot answer.
However, we all like a good language war so thank you for lobbing the first hand grenade
The way propeller is designed, why that applies to languages? and if propeller can run BASIC on it's cogs, will be there any difference at all?
btw, FFT using basic is possible, just google for that, there are numerous examples doing realtime FFT in BASIC, on chips much weaker than propeller.
Basically I agree with most of what you have posted here, just saying that's not an apt comparison, and in this case a good comparison is hard to find. I feel that the best language for those of us who are not full time programmers is the language we already know as long as it can do what we want it to do.
Your opening post asks "...can someone provide some simple task, and code in C and BASIC, so it will be possible to see, why C is better than BASIC ?" I have presented such a simple task and a C solution. Sorry I don't have a BASIC solution.
I have no doubt there are FFT's in BASIC. In fact the first FFT code I ever saw was in BASIC and ran on my Atari ST 520.
I'm looking forward to someone presenting an FFT in BASIC that runs on the Propeller for comparison.
Do you have a link to an example of realtime FFT in BASIC, on chips much weaker than Propeller?
Here's one quick example: http://www.protonbasic.co.uk/content.php/3388-Proton-Fast-8-bit-FFT
There is no source code of an FFT in BASIC at the link you provided. There is a BASIC compiler for the PIC that seems to include FFT functions, no doubt written in assembler.
I'm not about to spend £125 + VAT to try it out.
By the way, reading the example "BASIC" code there it strikes me how not BASIC it is, how similar to ALGOL like languages it is. It even has includes and defines like C. Why would you be so adverse to C if you can live with that?
I've also heard the "compiled basic can be as fast as C" argument since the 80s. I also understand that basic has become to be considered a "toy programming language". Personally I don't see considering basic a "serious" language in the same league as a language like C until it supports things like pointer, structures, while loops, dynamic memory allocation, etc.
I personally have no interest in pitting C up against basic for "some simple task". I'm not sure what writing a for loop that output the numbers 1 - 10 in C or basic will prove anything. Lets try writing an in-memory database and see how basic does? If you like basic and it does what you need than use basic!
LOL....You won't find an answer to this question but you have succeeded in exposing the ignorance of those who have not kept with the times, once again!
I had to detach myself from programming at one point because I had to run my company. I insisted on sticking with BASIC when I hired *real* programmers and the end result is that I can actually not worry about them moving on and being left with unreadable code. The irony is that I still know several of my ex-programmers and guess what....they stuck with BASIC! I am not talking VB, I am talking PowerBASIC with its pointers, structures, etc., etc.
This is one - not the only one - compiler that can generate non-bloated code with no external dependencies and can do anything that C can do and generates executables that easily compare with C.
If PropBASIC had the benefit of the resources being poured in to other Prop languages, we would have one heck of a tool!
Code portability? What a joke! All dialects of BASIC are so darned similar that any critical code can be ported very easily....it's a Monday/Tuesday issue in my experience.
PowerBASIC may be the best thing since sliced bread for the work you do. That is all well and good.
I have a couple of issues with it, these issues may not matter to you and many others but they are critical to me:
1) PowerBASIC does not work on any platform I need the code I write to run on. From embedded systems to cloud services.
2) For my own personal use, even if it did work on my machines, 200 dollars is hard to justify for such a limited tool. Especially as there are a dozen other languages and compilers to choose from that equally or more effective. That's a lot of Propellers!
3) Where is the ANSI or ECMA or other standard language definition for it? I know there is ANSI X3.113 but that dates from 1987 so I guess is not applicable.
4) If as you say portability is not an issue what is the PowerBASIC compatible compiler for Mac, Linux, BSD and other systems?
Given my experience with incompatible BASIC dialects, and the fact that PowerBASIC is for Windows and DOS, this strikes me as a dubious claim. As Heater points out the one standard predates most newer dialects with modern features.
@Heater, there is B4J which is a BASIC that targets the JVM. That lets you target any platform that has a JVM, but at that point you would probably be happier writing in Java. Although you wouldn't be happy about that. The same company has B4A and B4i which target Android and iOS, but they have per seat fees. The Android Java tools are free, so I can't imagine it has much of a user base.
It did and it does today, some 53 years later.
God bless Rear Admiral Grace Hopper. What a astonishing woman. I wish they would still breed women like that.
Enjoy!
Mike
If you search a bit in your original thread fom 2011, you will find two BASIC versions of the FFT Benchmark:
http://forums.parallax.com/showthread.php/129972
Andy
Thank you. I'd forgotten all about that. Did you ever get a run time measurement for those?
Can I put them in the fft_bench repository on github?
For sure you can put the result on github, but the BASIC compiler was never released. My plan was to rewrite it in PropGCC, but not found the time so far...
Andy
I think the fundamental issue of interpreted languages versus compiled languages is being ignored.
C is better than Basic simply because you can write a Basic Compiler in C and get as good results.
Or just maybe Basic is bettery simply because you can write a small interpreter in less space that C.
Quite so it can never be concluded.
The issue of interpreted vs compiled has been brought up here many times. It's not so cut and dried. Many BASICs can be compiled to efficient native code. There are interpreters for languages that are normally compiled. Like this C++ interpreter https://root.cern.ch/drupal/content/cint That is not a sound argument for C. Whilst I guess most BASIC compilers are actually written in C/C++ conceptually it is possible to write a BASIC compiler in BASIC in the same way that a C compiler can be written in C. Does anyone know of a BASIC compiler in BASIC? I'm not sure what you mean there.
On the one hand imagine: In an interpreter system I will have in memory, the interpreter (I), my BASIC program (B), and the data my program works on (D).
Clearly if I throw away I and B and replace it with native code I can get a lot more functionality into the space that I and B occupied. Faster too!
Where would that native code come from? Perhaps from C source compiled on a host machine. Or perhaps from BASIC code compiled on a host machine, like the PIC BASIC compilers that are available.
On the other hand if you actually want an interpreter, especially an interactive one, perhaps BASIC is the way to go. Other would suggest Forth of course.
But then this is not a debate about the actual language any more.
Yes, try this
http://www.freebasic.net/about
And this BASIC doesn't have any facilities for structured programming, just to mention a single (for me) necessary feature of any high-level programming language.
Consider this simple C program which doesn't even use pointers:
#include <stdio.h> typedef struct { char *name; int age; int height; int weight; } person; static void print_name (person theperson) { printf ("Name: %s\n", theperson.name); } static void print_age (person theperson) { printf ("Age: %d\n", theperson.age); } static void print_height (person theperson) { printf ("Height: %d\n", theperson.height); } static void print_weight (person theperson) { printf ("Weight: Won't tell\n"); } int main (void) { person salesman; salesman.name = "Mr Seller"; salesman.age = 35; salesman.height = 180; /* No imperial measurements */ salesman.weight = 110; /* Likewise */ print_name (salesman); print_age (salesman); print_height (salesman); print_weight (salesman); return (0); }The above isn't even something C is particularly good at.. but it has:- Real function calls. Not 'GOSUB 40' or whatever.
- Functions can take parameters.
- There is a type system: You can define new types.
- You can define a record and pass that one around as any other variable (not even using a pointer (address)).
- No line numbers.. if you want to insert a line of code you don't have to re-number all the lines in case there aren't any free numbers in between where you insert code.
I'm not including a version written in BASIC, because it's not possible to write it that way in BASIC! Before changing to a structured language I had to beat out that kind of functionality by not using records, by not using function calls (only gosub), by not defining types, and I hated that. After some time at least, when I saw how difficult it became to maintain and expand the mess.I decided to do some more formal research and looked up the ANSI/ISO/ECMA standards for BASIC. There are two: The 'minimal' version ANSI X3.60-1978, maybe easier to find as ECMA-55 (it wasn't actually ready until 1983), and 'Full BASIC (ANSI X3.113-1987)', close to ECMA-116.
The 1978/1983 version is from what I can tell simply Dartmouth. 'LET' is there, line numbers are there (not even optional: "Each line shall contain a unique line number"), functions are just rudimentary - not much better than a simple C preprocessor macro:
DEF FNF(X) = X^4 - 1.
For the rest you have 'GO SUB (aka GOSUB), and no function parameters of course - just global variables.
Hm, it even states "The letters shall be the set of upper-case Roman letters contained in the ANSI[/i, depending on source] 7-bit coded character set [..]".
It has arrays (as BASIC always did), but not records.
Over to the 'full' version (wow, more than 200 pages). There are some improvements:
- Lower-case letters are allowed
- More loop control structures (DO .. LOOP UNTIL etc.)
- A CASE mechanism (not too unlike what's in C and Pascal)
- Some sort of subroutine support and what they call subprogram support. It's infinitely better than not having them, but why the long list of special words to support this.. they made it very complicated indeed.
And that's all. The rest is just much more built-in functions compared to the minimal version. There's no type system, there's no support for record types (not to be confused by the 'record' mechanism of its built-in file handling support). Even line numbers seem to still be mandatory. The best part of this language definition seems to be the loop control mechanisms, they seem to cover anything you could find elsewhere. Very flexible. However, this language is not good enough for even the simple C program above - you can't code it in a similar fashion.There are other languages out there with BASIC or Basic as part of their names.. PropBasic, PBASIC, FemtoBasic, to mention some relevant ones for this forum. You have BBC BASIC (which is structured), FreeBASIC, and so on and so forth. But they are not BASIC. They have much less in common than FORTRAN IV, FORTRAN 66, Fortran 77, Fortran 95 have in common (but note how I left out Fortran 2000 there..).
So if you want to compare C with e.g. PropBasic, then it's best to say so, and then we can compare. Or protonbasic, which wasn't mentioned until page five of this thread.
Actually the FFT example is a kind of programming problem where the limitations I have discussed don't really apply.. it's just a computation problem. If you just want to add and multiply some numbers, then BASIC, or any of the <something>Basic languages, is as good as C and the rest - it's just a matter of degree and efficiency, which isn't what I have been looking at in my posts to this thread.
-Tor
Ah yes, from the freebasic docs "Building the compiler requires a working FB installation, because it's written in FB itself."
However it also says "rtlib/gfxlib2 are written in C...."
But, yeah, close enough for me.
Still it makes installing freebasic a pain and there is still no 64 bit version. All in all not worth the bother.
You sum up the situation very well.
I agree the FFT, despite the head scratching maths behind it is just a bunch of simple arithmetic and loops that could probably be expressed just as well in Dartmouth BASIC. It does not require the niceties of a structured language.
I threw that FFT into the mix because CuriousOne's opening post, emphasises speed, as do his later ones. That FFT is a short, self-contained example C as he asked for.
You're right - he did mention speed, although my own reasons for why C (or Pascal or Fortran or Algol or D or even BCPL. And Spin) is better than BASIC are about other issues (as I outlined). I see speed as a red herring really, because you can always make a fast version of anything. If, for example, your FFT in BASIC doesn't run fast enough, then write a limited version of BASIC which compiles that particular code to the fastest FFT possible (obviously you'll write that special compiler in C, but I digress..). Or just use another faster pre-made compiler (but be prepared to modify the syntax a bit, as they differ).
As a side note I came over a 2013 post over on the freebasic forum which nicely summed up *why* C is so compatible with itself: And Unix had this key difference with many other operating systems in that its command-line "commands" were all just user-level applications external to the core, so there was immediately a huge amount of widespread source out there.. and it all had to compile. You can fiddle with the syntax of a couple of files to get it to compile with "your" compiler, but you just can't do that with the whole world of Unix applications.
(I'm not sure if C++ should have been included there, C++ plays no role in Unix and indeed it's infamous for being incompatible with itself even from one version to the next. Maybe it will be stable after C++14).
-Tor
#define F(X) pow(X,4) - 1
(and yes right there there's a weakness in C (but not D) compared to BASIC: No 'power' operator so you need a library function).
The problem with a DEF FN style 'function' is that it's so extremely limited. It's really just a macro. And that's why a more complete subroutine/function system was added to the 1986/1987 standard, but as I described earlier this still doesn't let you implement the sample I wrote in C.
-Tor
-Tor
Each and every language has a choice as to the scope of its content, leaving the end-user to extend it further with additonal tools. Some languages are merely analogous to a screw-driver; while others are analogous to a whole hardware store's worth of tools.
So how does one decide the scope of a language?
A. Focus on the fundamental concepts of good programing -- looping, conditionals, testing, incrementing, i/o management, and so on OR Attempt to provide all and everything
B. Select a mode of use --- compiled, interpreted, tokenized, ?
C. Provide a particular creative environment --- graphics, word processing, animation, engineering, music composition, develop a web site, etc.
My best guess is that if computer education was properly taught, all these 'which language is better' questions would just fade away. We suffer from a very commercialized view of computer language selection rather than a utilitarian pragmatic view of selection.
And sadly, human psychology seems to make mavens of those than have mastered a language. So when you ask someone which is good, they are adamant that the one they know is the best.
I simply have settled for a few adequate and worthy of investing a lot of time in learning. In my opinion, SPIN is a worthy language, so are PYTHON, C, Forth, and a few others.
Basic has always had introductory appeal, but while PBasic is certainly an introductory Basic; others are anything but introductory.
One doesn't have to program an Arduino Uno with their C/C++, there is ZBasic that will provide competatively sophisticated compiler on the same silicon.
See www.zbasic.net
My gut feeling is this is more about time management and determining one's goals in learning computer. We all have to spent a lot of time learning a few languages and ignoring many others as distractions ... in order to learn anything at all.
Are we merely selling training wheels to everyone, pushing a personal preference, or are we offering real insight in how to enjoy life-long learning about programing?
I really wonder if performing an FFT offers anything meaningful for a generalized language. How many of us really need to calculate FFT? And if we do, how many of use desire to use a microcontroller to do so with limitations of speed and memory?
Most of what I do on a computer is email, text processing, searching, reading documents, and money counting. Since the programs and apps are all well-developed and free; my programing is primarily tinkering with odd-ball stuff. And generally, C is a distraction for my kind of tinkering.
Though I like Python and BASH, I rarely get around to doing anything in either. Of course, there are some computer polyglots that just love to learn yet another language just to make the rest of us feel like Forrest Gump.