Ah, I see what you mean. I find using white space as a block delimiter annoying as well.
But that is only syntactic "fluff". As opposed to the actual features one language may or may not have over others. For example: nested functions, first class functions, lambdas, closures, classes, objects, prototypes vs classes etc etc etc.
After years of programming I have come to think that compilers/interpreters should actually dictate how many spaces your indentation will be, where you will put your brackets, braces, semicolons and so on. That would have saved decades of code formatting debates and made everything standardized and easy to read.
Ah, I see what you mean. I find using white space as a block delimiter annoying as well.
But that is only syntactic "fluff". As opposed to the actual features one language may or may not have over others. For example: nested functions, first class functions, lambdas, closures, classes, objects, prototypes vs classes etc etc etc.
After years of programming I have come to think that compilers/interpreters should actually dictate how many spaces your indentation will be, where you will put your brackets, braces, semicolons and so on. That would have saved decades of code formatting debates and made everything standardized and easy to read.
It may only be syntactic fluff but I still don't like it. I learned Perl a long time ago and stick with it. Perl is a nice language that lets me quickly write scripts that I use as a Unix sys admin to help automate aspects of my job. Never felt the need for classes, lambdas, etc in those scripts.
I do like the idea of enforced programming styles! Since I use the one true and right style of indentations and put the brackets, braces and semicolons in the only right place so I wouldn't have to change the way I do it!
It's a good thing Peter bailed out on his own thread. This call to arms has turned into a full-blown language war, where everyone is battling with their favorite language. Poor Forth never had a chance in this war.
If you take a young guy or someone who has never programmed before and you start them with the Arduino you kick off with this:
int led = 13;
void setup() {
pinMode(led, OUTPUT);
}
void loop() {
digitalWrite(led, HIGH);
delay(1000);
digitalWrite(led, LOW);
delay(1000);
}
Which is already weird. I mean what is "int" and "void" never mind the squiggly brackets.
I guess in the SimpleIDE world that is something like:
#include <propeller.h>
int main (int argc, char* argv)
{
int led = 13;
pinMode(led, OUTPUT);
while (1)
{
digitalWrite(led, HIGH);
delay(1000);
digitalWrite(led, LOW);
delay(1000);
}
}
Assuming we had Arduino like functions for I/O.
You see the problem here?
Other than the #include at the top, I don't see any significant difference between these two. You can, of course, declare main this way:
int main(void)
{
return 0;
}
I guess you'll get a warning unless you put the return 0; at the end though. Maybe that's the big problem. Anyway, I don't believe it is setup() and loop() that make the Arduino easy to program.
Thing is, neither do us old hands any more What a tedious waste of life.
Yes, the Java and Spin feature of having the class definitions also be the prototypes makes things a little easier. It doesn't seem like a big deal to me though and I had to learn it at one time as well.
I could issue a basic redirect to send this to serialX or an LCD or a TCP connection or Telnet ....
This is comprehensible to a pre-beginner, show them they are in charge of the machine and not just blindly following an online tutorial to do x y z without any understanding which leads to 0 retention.
That Forth syntax always bothered me. The strings look like they begin with a blank. I understand why it is done but it looks like a kludge to me.
So far I have not seen anyone suggest that Forth should or should not be used. Or any other language for that matter.
I did my best to refrain from such comments. You know me.
If I understand Peter correctly there is a suggestion that the byte code system he has used has merit no matter what language.
I am in no position to comment on that as I have not studied it and I'm not about to write any compiler that generates it.
So, anyone have a guess if such a byte code system is better than CMM for example?
It may run faster than CMM because of Peter's clever scheme of treating a bytecode as an address of the bytecode handler. I haven't looked at it closely enough to know whether it would be better either but I suspect it would be worse for GCC since I imagine it presents a stack model like the ZPU rather than a register model which tends to work better with GCC. It might be a good match for Spin though since it doesn't make any attempt to optimize code as far as I can tell. However, it might not be any faster than the Spin VM if naive code generation is used.
Arduino and it's variations are not aimed at high end professionals like yourself and others here but hobbyists/artists who aren't interested in devoting their life to learning the intricacies of C/C++, so you're aren't going to see any advantages over C/C++. Plus it was open source for everything, which has allowed it to spread over multiple processors from different vendors. BTW the Mbed people did pretty much the same thing with their on-line C++ compiler and libraries which made ARM's accessible to mere mortals.
The take away is that you need to make things user friendly for hobbyists instead of expecting prospective customers to learn something complex or obscure like self-modifying code or the gory details of C++. You need to pay attention to them. Banzai did and his concept came out on top.
Here we have a program that takes no inputs, does nothing and then reports that it did nothing successfully.
Assuming that we know that "void" means there is nothing here and returning an integer value of zero means OK.
Imagine you have never seen a computer program before. You have no idea that even you can control a machine with a program. So it starts:
What is "int"?
What is "main"?
What is "void" and why is it in those brackets.?
What are those curly braces?
What is "return"?
Why the zero?
Why the semicolon?
This program is much more succinctly written as:
Yes, that's right. Nothing. No characters at all. Works in JavaScript anyway.
Thank you heater, this is EXACTLY my point, what all you sharp pencils take for granted is mind numbing and turns people off from even trying. How do you motivate people when you have to start explaining the syntax the compiler NEEDS, stupid compiler.
Thank you heater, this is EXACTLY my point, what all you sharp pencils take for granted is mind numbing and turns people off from even trying. How do you motivate people when you have to start explaining the syntax the compiler NEEDS, stupid compiler.
Have you ever looked at a Forth program? It is full of gibberish that is totally non-intuitive and pretty much there only to make the "compiler" simpler.
I looked at Forth. I promised not make any further comments on it on these forums
That "gibberish" problem is of course not just limited to C or Forth, pretty much every programming language I have used suffers from it. The need a lot of incantations to be made just to get started.
Some of that gibberish is dictated by the mechanics of the compiler technology. Like #include in C. Or the weirdness that goes on in Forth.
Some of it is a structural part of the very language design. For example the requirement that everything be class in Java. Which makes writing a "Hello world!" program a nightmare.
Attempts at getting rid of the gibberish and creating a language that is a soft start for beginners include such things as BASIC and JavaScript.
Seems to be a problematic approach though. How to design a language that is both easy to pick up from the get go but also sophisticated enough to be generally useful as program size and complexity grows? BASIC in its original form failed here. It was great as an introduction to programming concepts for beginners but of limited general use.
JavaScript is quite remarkable in that respect. Extremely easy on the beginner whilst also being a very sophisticated and capable language with features that make it useful over a huge spectrum of size and complexity in programs.
Maybe Peter should take a page from the Arduino success, create a front end syntax for the interactive portion, based on Forth. Everybody keeps saying that the language that is being used with the Arduino is C++, but the users do not know that and are quite happy.
There are quite a few professional programmers here, you would think that if you guys would put your heads together along with Peter, you could come up with a relatively easy to use syntax that would make Peter happy to implement within the underlying Forth engine. All the other stuff that Peter has mentioned as being doable implementations could come later, but first address the front end, to make people as happy as the Arduino users are.
[COLOR=#020FC0][B]DECIMAL
: BLINKY 10 FOR 4 PINSET 100 ms 4 PINCLR 100 ms NEXT ; ok
[/B][/COLOR]
Not very exciting to blink an LED but how would you do this in Forth, especially Tachyon?
First we need to hook-up an LED to a port pin, in this case I happen to
have one on P4 that turns on when the pin is high.
Many boards have an LED hookup, so find the port number it is on,
I am going to "talk" to it directly like this:
4 MASK OUTSET ok
As soon as the <cr> is hit the code is executed in interactive mode.
The word OUTSET requires a bitmask that matches the outputs that we want to SET or turn on high.
At the same time OUTSET will ensure that the matching bits in the DIRA register are set.
Since I was lazy I got Forth to calculate the bit mask for me from the supplied port number 4
so MASK does the same thing that |< does in Spin and in fact we could create an alias for MASK as well:
: |< MASK ; ok
4 |< OUTSET ok
Now since we are only playing with single pins at present let's use the simpler version of
setting and clearing pins with PINSET and PINCLR, they only need a port number.
In fact PINSET is simply defined as MASK OUTSET but looks cleaner when we read code.
Pick your flavor then but like the wizard's apprentice we want to know how to turn
the thing off too but no need to panic, it's simple:
4 PINCLR ok
To make an LED flash we also need a delay between turning it on and off (and back on again),
this is where we use the ms word (milliseconds) and combine all these elements into code:
Typing in BLINKY from above at any time now will execute the definition and make the
LED flash on for 100ms and off for 100ms ten times.
Analysing what we just did with spaces between all numbers and words:
:
Create a new definition - name follows
BLINKY
The name of the defintiion - any combination of letters, numbers, symbols, except space.
10 FOR
Setup a loop from here for 10 times
4 PINSET
Set PIN 4 (high)
100 ms
delay for 100 ms
4 PINCLR
Clear PIN 4 (low)
100 ms
delay 100 ms
NEXT
Countdown NEXT loop back to 4 PINSET
;
EXIT return from defintiion
now isn't this something for the beginner ??
you could define a synonym TIMES for FOR if you wanted it to sound it more english.
Could you do this in C or BASIC ?
you could define a synonym TIMES for FOR if you wanted it to sound it more english.
Could you do this in C or BASIC ?
It may be something for a beginner, but it requires as much explanation as the same program in BASIC, Spin or C. And because Forth does everything on the stack the novice programmer has to learn about stacks before he can do anything in Forth. I firmly believe that BASIC is the best language for introducing a novice to computing -- and I'm talking about old-school BASIC that requires a line number for each statement. It's very simple and the novice programmer can get instant gratification from it. Because BASIC is simple the novice can learn it in a matter of hours.
Once the novice has mastered BASIC he can move on to structured BASIC or C, or some other more complete language. And yes, you can define synonyms in C if you wanted it to sound more like English. Not only that, but C has local variables, function parameters, data structures and many other features that Forth does not have. It also has a real optimizing compiler and a linker that Forth doesn't have.
FYI, I wasn't claiming that C didn't have warts and couldn't be improved upon. I was just saying that in my opinion the Arduino setup/loop functions don't really help that much.
you could define a synonym TIMES for FOR if you wanted it to sound it more english.
Could you do this in C or BASIC ?
No, you can't change the syntax of the C compiler other than by writing macros. You probably can't change Basic's syntax at all. However, changing a language's syntax might not be advisable anyway since by doing it you're really creating a new language.
No, you can't change the syntax of the C compiler other than by writing macros. You probably can't change Basic's syntax at all. However, changing a language's syntax might not be advisable anyway since by doing it you're really creating a new language.
maybe that is the most important point in Forth.
which also makes it sometimes really hard to read other people's code.
You create a new application specific vocabulary, which makes it then easy and natural to solve your problem.
Of course as with any language you will not be proficient without learning the vocabulary.
In other languages the vocabulary might be big, but in itself static.
But when it comes to writing bigger programs you will rely on libraries, which extend the vocabulary in an other way. And without knowing the libraries and it's huge numbers of functions you need to reinvent the wheel again yourself.
Since in Forth you do not see if the word is from the base vocabulary or from a library (without special conventions)
this can be difficult for the reader of the code - as I had the experience myself.
And since the factorization in Forth is - if done right - quite complete - which results in MANY words to learn
- this can be a real problem for the only occasional programmer.
And exactly this makes the experienced programmer so effective and efficient - just see Peter's results.
So there are at least this two aspects -
- a simple base set of words for the occasional user - which are ok to let the LED blink - the pidging english so to speak
- and the the full > 1 Million words of the english language for the Poem and Novel writer ...
If you have a look at the many language and syntax constructs that Peter invented to make the SD file system, Webserver etc. ..
that makes this possible in this small space.
And still the base syntax is VERY simple
everything is a WORD seperated by a SPACE (if it has not been changed ;-) temporyrily to make a more problem centerted sub-language).
I took me quite some time - even coming from LISP - to adapt to Tachyon -
but it is very well woth it.
That's the other problem with Forth is that half the Forth programmers believe in anarchy, and they don't adhere to standard Forth. At least with standard Forth there's a chance that one Forth programmer can understand another Forth programmer's code without having to look up each non-standard word that they use. To make matters worse, some Forths use a different interpretation for standard Forth words, so you fall into a trap thinking the code is doing one thing, when it's actually doing something else. And then there's Forth code that intersperses stack thrashing words like OVER, DUP, SWAP and ROT. These waste cycles moving stuff around on the stack, and makes it difficult to figure out what the code is actually doing.
[16:53:30] peterjakacki:
Since there are aliases in EXTEND.fth including some recent ones
the Blinky code could be written as:
#P28 == LED // assign port pin as the LED
pub BLINKY
10 TIMES
LED HIGH
100 ms
LED LOW
100 ms
NEXT
RETURN
just as an example of a new 'Language' for blinking LEDs
I assume that NEXT starts the next iteration of the TIMES loop? Any reason the statements between TIMES and NEXT aren't indented? Anyway, this code is quite easy to figure out especially if you have enough knowledge of Forth to know that arguments come before operators.
Well, a suitable ARM, with a fair bit of memory could serve as the EEPROM to the P8x. A Cortex R would meet 'real time' / deterministic requirements, I suppose....
Obviously, the ARM would need to act as an I2C slave to the Propeller, and would have to hold the Prop in reset until it's ready.
I think a big issue would be how to program both, since there's no common IDE between them.
If I were building a system with an ARM and a Propeller I would not be using the ARM as an EEPROM "simulator" for the Propeller.
Much easier is to just use a UART connection from the ARM and program the Prop using it's normal serial download protocol.
We have already done that from ARMs like the Raspberry Pi and from MIPS chips as found in cheap WIFI routers.
My propeller loader for such situations is here https://github.com/ZiCog/pi-propeller-load That is basically a clone of the loader found in propgcc adapted to use a GPIO pin for resetting the Propeller.
Well, a suitable ARM, with a fair bit of memory could serve as the EEPROM to the P8x. A Cortex R would meet 'real time' / deterministic requirements, I suppose....
Obviously, the ARM would need to act as an I2C slave to the Propeller, and would have to hold the Prop in reset until it's ready.
I think a big issue would be how to program both, since there's no common IDE between them.
Did I manage to de-rail this thread yet?
IDE? What's that? :-)
They both understand gcc and Makefiles so that's fine by me.
Comments
My biggest problem with it is the blocking by indentation that it uses. I know that spin has the same "feature" and I don't like it with spin either.
Nothing really wrong with it but I learned perl a long time ago and use it for the scripting I do. One of these days I may decide to learn python.
Ah, I see what you mean. I find using white space as a block delimiter annoying as well.
But that is only syntactic "fluff". As opposed to the actual features one language may or may not have over others. For example: nested functions, first class functions, lambdas, closures, classes, objects, prototypes vs classes etc etc etc.
After years of programming I have come to think that compilers/interpreters should actually dictate how many spaces your indentation will be, where you will put your brackets, braces, semicolons and so on. That would have saved decades of code formatting debates and made everything standardized and easy to read.
It may only be syntactic fluff but I still don't like it. I learned Perl a long time ago and stick with it. Perl is a nice language that lets me quickly write scripts that I use as a Unix sys admin to help automate aspects of my job. Never felt the need for classes, lambdas, etc in those scripts.
I do like the idea of enforced programming styles! Since I use the one true and right style of indentations and put the brackets, braces and semicolons in the only right place so I wouldn't have to change the way I do it!
int main(void)
{
return 0;
}
I guess you'll get a warning unless you put the return 0; at the end though. Maybe that's the big problem. Anyway, I don't believe it is setup() and loop() that make the Arduino easy to program.
That Forth syntax always bothered me. The strings look like they begin with a blank. I understand why it is done but it looks like a kludge to me.
"Language war" Where?
So far I have not seen anyone suggest that Forth should or should not be used. Or any other language for that matter.
I did my best to refrain from such comments. You know me.
If I understand Peter correctly there is a suggestion that the byte code system he has used has merit no matter what language.
I am in no position to comment on that as I have not studied it and I'm not about to write any compiler that generates it.
So, anyone have a guess if such a byte code system is better than CMM for example?
Here we have a program that takes no inputs, does nothing and then reports that it did nothing successfully.
Assuming that we know that "void" means there is nothing here and returning an integer value of zero means OK.
Imagine you have never seen a computer program before. You have no idea that even you can control a machine with a program. So it starts:
What is "int"?
What is "main"?
What is "void" and why is it in those brackets.?
What are those curly braces?
What is "return"?
Why the zero?
Why the semicolon?
This program is much more succinctly written as: Yes, that's right. Nothing. No characters at all. Works in JavaScript anyway.
Arduino and it's variations are not aimed at high end professionals like yourself and others here but hobbyists/artists who aren't interested in devoting their life to learning the intricacies of C/C++, so you're aren't going to see any advantages over C/C++. Plus it was open source for everything, which has allowed it to spread over multiple processors from different vendors. BTW the Mbed people did pretty much the same thing with their on-line C++ compiler and libraries which made ARM's accessible to mere mortals.
The take away is that you need to make things user friendly for hobbyists instead of expecting prospective customers to learn something complex or obscure like self-modifying code or the gory details of C++. You need to pay attention to them. Banzai did and his concept came out on top.
Thank you heater, this is EXACTLY my point, what all you sharp pencils take for granted is mind numbing and turns people off from even trying. How do you motivate people when you have to start explaining the syntax the compiler NEEDS, stupid compiler.
I looked at Forth. I promised not make any further comments on it on these forums
That "gibberish" problem is of course not just limited to C or Forth, pretty much every programming language I have used suffers from it. The need a lot of incantations to be made just to get started.
Some of that gibberish is dictated by the mechanics of the compiler technology. Like #include in C. Or the weirdness that goes on in Forth.
Some of it is a structural part of the very language design. For example the requirement that everything be class in Java. Which makes writing a "Hello world!" program a nightmare.
Attempts at getting rid of the gibberish and creating a language that is a soft start for beginners include such things as BASIC and JavaScript.
Seems to be a problematic approach though. How to design a language that is both easy to pick up from the get go but also sophisticated enough to be generally useful as program size and complexity grows? BASIC in its original form failed here. It was great as an introduction to programming concepts for beginners but of limited general use.
JavaScript is quite remarkable in that respect. Extremely easy on the beginner whilst also being a very sophisticated and capable language with features that make it useful over a huge spectrum of size and complexity in programs.
Hello World in Java: WTF?
There are quite a few professional programmers here, you would think that if you guys would put your heads together along with Peter, you could come up with a relatively easy to use syntax that would make Peter happy to implement within the underlying Forth engine. All the other stuff that Peter has mentioned as being doable implementations could come later, but first address the front end, to make people as happy as the Arduino users are.
Ray
"A new syntax" Do you mean that?
My feeling is that the last thing the world needs, especially the Propeller world, is Yet Another Fine Language (YAFL).
https://docs.google.com/document/d/1bEH0DfGmu99M1SqCbmlzl991Ssv2J5m6XWmkJX0XSl8/pub now isn't this something for the beginner ??
you could define a synonym TIMES for FOR if you wanted it to sound it more english.
Could you do this in C or BASIC ?
Once the novice has mastered BASIC he can move on to structured BASIC or C, or some other more complete language. And yes, you can define synonyms in C if you wanted it to sound more like English. Not only that, but C has local variables, function parameters, data structures and many other features that Forth does not have. It also has a real optimizing compiler and a linker that Forth doesn't have.
which also makes it sometimes really hard to read other people's code.
You create a new application specific vocabulary, which makes it then easy and natural to solve your problem.
Of course as with any language you will not be proficient without learning the vocabulary.
In other languages the vocabulary might be big, but in itself static.
But when it comes to writing bigger programs you will rely on libraries, which extend the vocabulary in an other way. And without knowing the libraries and it's huge numbers of functions you need to reinvent the wheel again yourself.
Since in Forth you do not see if the word is from the base vocabulary or from a library (without special conventions)
this can be difficult for the reader of the code - as I had the experience myself.
And since the factorization in Forth is - if done right - quite complete - which results in MANY words to learn
- this can be a real problem for the only occasional programmer.
And exactly this makes the experienced programmer so effective and efficient - just see Peter's results.
So there are at least this two aspects -
- a simple base set of words for the occasional user - which are ok to let the LED blink - the pidging english so to speak
- and the the full > 1 Million words of the english language for the Poem and Novel writer ...
If you have a look at the many language and syntax constructs that Peter invented to make the SD file system, Webserver etc. ..
that makes this possible in this small space.
And still the base syntax is VERY simple
everything is a WORD seperated by a SPACE (if it has not been changed ;-) temporyrily to make a more problem centerted sub-language).
I took me quite some time - even coming from LISP - to adapt to Tachyon -
but it is very well woth it.
[16:53:30] peterjakacki:
Since there are aliases in EXTEND.fth including some recent ones
the Blinky code could be written as:
just as an example of a new 'Language' for blinking LEDs
A Cortex R and Propeller would probably be a nice fit.
Obviously, the ARM would need to act as an I2C slave to the Propeller, and would have to hold the Prop in reset until it's ready.
I think a big issue would be how to program both, since there's no common IDE between them.
Did I manage to de-rail this thread yet?
If I were building a system with an ARM and a Propeller I would not be using the ARM as an EEPROM "simulator" for the Propeller.
Much easier is to just use a UART connection from the ARM and program the Prop using it's normal serial download protocol.
We have already done that from ARMs like the Raspberry Pi and from MIPS chips as found in cheap WIFI routers.
My propeller loader for such situations is here https://github.com/ZiCog/pi-propeller-load That is basically a clone of the loader found in propgcc adapted to use a GPIO pin for resetting the Propeller.
You can even compile Spin code on the ARM (or MIPS or whatever) if you like with the Open Source Spin compiler. https://code.google.com/p/open-source-spin-compiler/
As for a "common IDE", well, your favorite text editor will do fine for both.:)
Not at all. I think you spot on.
IDE? What's that? :-)
They both understand gcc and Makefiles so that's fine by me.