My understanding from the propeller conference is that the SimpleIDE is readily extensible and it appears to run some sort of command line compiler anyway. I've been a big fan of Bean's BASIC since SX/B which I still use a lot.
Keep in mind that there is also a very good BASIC implementation "Propeller Color BASIC" that is used on the Propellerpowered Pocket Mini Computer. All I'm saying is that having common syntax and features might be a nice thing.
Do you think that a SimpleIDE BASIC should require object libraries for extensibility or should it have built in commands for graphics, coms, sound, etc... (I'm in favor of the latter
I'm in favor of keeping SimpleIDE as simple as can be.
I thought the initial idea was that it should a drop dead simple IDE for C on the Propeller much like the Arduino IDE is for the AVRs. Only better:) I was already worried about the idea of throwing Spin into Simple IDE.
Adding in BASIC, or anything, is OK but I would like to see it done in such away that the user is only presented with one language at a time. Perhaps that means forking Simple IDE into different versions for different compilers. Perhaps it means supporting all possibilities from the same code base but being able to build different IDEs from it.
Interestingly though, once upon a time telegrams used STOP and not the dot.
Telegrams charged by the character. They used STOP instead of . so they could charge for four characters instead of one. This was an early example of a clever idea that ticked off customers.
I'm in favor of keeping SimpleIDE as simple as can be.
I thought the initial idea was that it should a drop dead simple IDE for C on the Propeller much like the Arduino IDE is for the AVRs. Only better:) I was already worried about the idea of throwing Spin into Simple IDE.
Adding in BASIC, or anything, is OK but I would like to see it done in such away that the user is only presented with one language at a time. Perhaps that means forking Simple IDE into different versions for different compilers. Perhaps it means supporting all possibilities from the same code base but being able to build different IDEs from it.
I wonder if the Arduino IDE is a little too simple. I think SimpleIDE may be a good compromise between a overly simple IDE like the Arduino one and an incredibly complicated one like Visual Studio or Xcode.
That implies that the code generated by the BASIC to C translator will have to be 100 percent sure never to generate C that won't compile.
It this true? Can't one create strings that the basic interpreter won't compile? Doesn't the B-to-C xlator only have to produce the identical output as the BASIC?
Further along there may be issues in debugging. How do you match up the generated code back to the original BASIC source code?
Log file? "BASIC input = C output" , statement by statement. Since this must be happening anyway, it should be trivial, and disk space is cheap.
Can't one create strings that the basic interpreter won't compile?
What I meant was that if you have some syntax or whatever error in your BASIC, as you typed it, that should never lead to the situation that it blindly translates to C and then the C compiler rejects the C code. Thus leaving the poor BASIC programmer exposed to the byzantine mess which is the C language, header files, compiler, assembler, libraries, linker...
Log file? "BASIC input = C output" , statement by statement.
Yes. However that does not even work for C if you turn on optimizations. You can easily get into the situation where the compiler rearranges code or removes unused things. All of a sudden the is no one to one corresondence between source line numbers and executable instructions. Can be very confusing when debugging.
My comment about things like BEGIN...END being annoying was not about writing the code but reading it. They are just ugly and get in the way. As there tends to be rather a lot of them it eases the situation by reducing them to "hamburger buns".
I will not agree or disagree this moment but will only remind, since I'm sure you're already aware, that this is highly subjective. Clearly, a good many don't mind and even prefer looking at code written as such. (I do think that Ada's end if, end loop, end case, etc., can be said to aid readability.)
However, doing this at all might not make sense if PropBasic already produces better code than PropGCC. I'm still waiting for an example to be posted. I'd love to see how the code generation compares. Maybe we can learn something that will help us improve PropGCC!
Didn't someone post an analysis of outputs (benchmarks) for various Propeller languages not long ago? With code size and execution times for various tasks? I seem to recall that PropBASIC rather consistently came out near or at the top.
I wonder if the Arduino IDE is a little too simple.
I certainly think so. On the other hand, doubtless that accounts for much of its appeal. I guess it comes down to, do you want to market Prop to "artist" types?
Didn't someone post an analysis of outputs (benchmarks) for various Propeller languages not long ago? With code size and execution times for various tasks? I seem to recall that PropBASIC rather consistently came out near or at the top.
Certainly, if PropBasic beats PropGCC then there would be no point in a basic2cpp translator. I wasn't aware that PropBasic was so good at optimization. I guess I should try it!
POST @KC_Rob
PARAGRAPH
SENTENCE
yes, it's subjective
END SENTENCE
SENTENCE
for sure it has been discussed and debated to death over the years
END SENTENCE
SENTENCE
sometimes I just can't resist throwing in my feelings about it
END SENTENCE
SENTENCE
it's probably better to just ignore it
END SENTENCE
END PARAGRAPH
PARAGRAPH
QUESTION
what I don't understand is why such verbose markup is desired by
some for their programming language but there has never been
such demand in natural language
END QUESTION
END PARAGRAPH
END POST
-- I rest my case.
Certainly, if PropBasic beats PropGCC then there would be no point in a basic2cpp translator. I wasn't aware that PropBasic was so good at optimization. I guess I should try it!
I'm not sure if the top post was kept up to date but from that it seems that PropBasic is a hair faster in COG mode and significantly slower in LMM mode.
POST @KC_Rob
PARAGRAPH
SENTENCE
yes, it's subjective
END SENTENCE
SENTENCE
for sure it has been discussed and debated to death over the years
END SENTENCE
SENTENCE
sometimes I just can't resist throwing in my feelings about it
END SENTENCE
SENTENCE
it's probably better to just ignore it
END SENTENCE
END PARAGRAPH
PARAGRAPH
QUESTION
what I don't understand is why such verbose markup is desired by
some for their programming language but there has never been
such demand in natural language
END QUESTION
END PARAGRAPH
END POST
LOL!! Good one, Heater!!
(PS - I think your analogy would work better with a programming language which had more than one type of "stop" instead of only curly brackets.)
Haa! yes I forgot. They invented XML/HTML so as to avoid all that bother with full stops and paragraph spacing. Don't get me started on that....
KC_Rob,
The Arduino may be two dumbed down for you and I. When talking about keeping SimpleIDE simple I'm not really thinking of marketing the Prop to artistic types. More along the lines of that ocean of people, who may or may not be younsters, who have never programmed before. They don't even know what a program or a programming language is or what you might be able to do with it. They certainly don't want to be hit with even "select language: C, Spin BASIC, ALGOL..." questions or options. The natural response of normal people to that is "Bah, this is too hard, get me out of here".
As I have often said the smartest part of the Arduino setup is that they don't even name the language they are presenting.
I'm not sure if the top post was kept up to date but from that it seems that PropBasic is a hair faster in COG mode and significantly slower in LMM mode.
That I do not know without further investigation (ie, reading the entire thread again). I see that Bean had a problem with how some of the examples were coded. Were they updated to reflect that? I dunno.
That I do not know without further investigation (ie, reading the entire thread again). I see that Bean had a problem with how some of the examples were coded. Were they updated to reflect that? I dunno.
At least one message from Eric in reply to Bean said that he had updated the results to reflect Bean's alternate way of coding something. I'm not sure if that was the table I was looking at though.
The Arduino may be two dumbed down for you and I. When talking about keeping SimpleIDE simple I'm not really thinking of marketing the Prop to artistic types. More along the lines of that ocean of people, who may or may not be younsters, who have never programmed before. They don't even know what a program or a programming language is or what you might be able to do with it. They certainly don't want to be hit with even "select language: C, Spin BASIC, ALGOL..." questions or options. The natural response of normal people to that is "Bah, this is too hard, get me out of here".
As I have often said the smartest part of the Arduino setup is that they don't even name the language they are presenting.
I don't disagree, Heater. But make it too simple and some might think it more a toy than a professional tool. I guess it mainly comes down to who your intended market is. That being the case, David is perhaps right in that the best option (for Parallax) is to split the middle between Arduino IDE and full-blown, full-featured tools like VS (or closer to home, AVR Studio 6).
...I think your analogy would work better with a programming language which had more than one type of "stop" instead of only curly brackets.
I have often thought about this, as you might guess.
On the one hand we have languages like lisp and scheme that only have round brackets. Arguably that's all they need as their syntactical constructs are so simple and few. The result is a bewildering mess of round brackets with some code hidden here and there all of which is a real pain to read let alone write. That dooms those language to a niche of freaks why can handle that situation.
On the other hand we have languages in the C style where there are square brackests for array indexing, round brackets for parameter lists, conditionals, etc and "hamberger buns" for code block delimiting and data initializers. Those different brackets give you a good clue as to what you are looking at in a concise way.
On a third hand we have the over the top verbose languages like Ada and Cobol which as it turns out nobody want to use.
Adding more kinds of "stop" to those C style syntaxes would require more bracket styles to choose from which normal keyboards don't have. And it would look messy anyway. The "hambuger buns", I guess Americans might not like me just calling them just "buns", have an advantage in that I can change a "while" to a "for" or such like change without having to go and change the "stop bun".
...make it too simple and some might think it more a toy than a professional tool.
I agree. It seems to be a delicate balance.
My thesis is that Simple IDE has no need to grow into a huge complex, all singing all dancing, multi-language, plugin infested nightmare like Eclipse. We already have Eclipse. It should be, as it is, dead easy and quick to install. Dead easy and quick to just write your first line of code and have it run.
As for the professionals who might think it's a toy. I would not worry, those guys have their prefered dev set ups. From Eclipse down to vim and the command line. Don't forget that millions of AVRs are sold outside of the Arduino world.
And it would look messy anyway. The "hambuger buns", I guess Americans might not like me just calling them just "buns", have an advantage in that I can change a "while" to a "for" or such like change without having to go and change the "stop bun".
I'm not so sure. Talking about readability, where we started, I can imagine potential advantages to having different delimiters for different control structs (ie, what Ada does more verbosely) -- no need to limit these to a single character, either.
Couldn't be any worse than swimming in a sea of curly brackets. But that's just my take.
I'm not sure if the top post was kept up to date but from that it seems that PropBasic is a hair faster in COG mode and significantly slower in LMM mode.
Quote from ersmith in the benchmark thread: "In LMM mode GCC does not generate djnz, so its loop is a bit bigger (using a cmp and branch). The loop does fit into the FCACHE area in the COG and so executes without LMM overhead, which explains why GCC's LMM time is close to PropBasic's COG time."
I'm not so sure. Talking about readability, where we started, I can imagine potential advantages to having different delimiters for different control structs (ie, what Ada does more verbosely) -- no need to limit these to a single character, either.
Couldn't be any worse than swimming in a sea of curly brackets. But that's just my take.
I'm not sure any of the block delimiter approaches is idea. I think the best way to avoid "swimming in delimiters" is to factor your code into relatively small functions/methods so that the code isn't too deeply nested. Of course, there may be a performance hit for that unless you use inline functions.
As for the professionals who might think it's a toy. I would not worry, those guys have their prefered dev set ups. From Eclipse down to vim and the command line. Don't forget that millions of AVRs are sold outside of the Arduino world.
No real argument here either. But a perception like that might harm Parallax (in particular Propeller adoption in real-world designs) more than it would, say, an Atmel.
I'm not sure any of the block delimiter approaches is idea. I think the best way to avoid "swimming in delimiters" is to factor your code into relatively small functions/methods so that the code isn't too deeply nested. Of course, there may be a performance hit for that unless you use inline functions.
Agreed. And I think most of us strive for that. But, whether it's your code or someone else's that you're working with, it almost invariably becomes an issue at some point.
No real argument here either. But a perception like that might harm Parallax (in particular Propeller adoption in real-world designs) more than it would, say, an Atmel.
This might not be a problem if Parallax offers a "professional IDE" in addition to SimpleIDE but I doubt they have the resources to do two IDEs.
I can imagine potential advantages to having different delimiters for different control structs (ie, what Ada does more verbosely) -- no need to limit these to a single character, either.
Ouch, I have considered that as well. Actually when I was messing around following Jack Crenshaw's "Let's Build a Compiler" I tried putting together differnet dialects with different delimeters. I did not come up with a nicer solution than the buns.
If you use multi charater delimeters, and different ones for "if", "while", "case" etc you are going to end up with, for example:
if (a)
while (b)
...
/&
/%
Or some such. Which is going to look like line noise on the screen (Or Perl anyway) and is going to be even more beginner unfriendly than what we have now with the buns. Buns are at least consistant, they delimit a block of code in the same way no matter in which construct that block lives.
Or some such. Which is going to look like line noise on the screen (Or Perl anyway) and is going to be even more beginner unfriendly than what we have now with the buns. Buns are at least consistant, they delimit a block of code in the same way no matter in which construct that block lives.
So, then, perhaps Ada didn't do so bad after all? Frankly, I find its method of uniquely delimiting control structs more "readable" than any of the other options so far considered -- it's just more verbose is all. Once again, a "pick your poison" deal. Highly subjective. (Nonetheless, I've been working with braces for as long as I can remember and it hasn't killed me -- yet.)
For a professional IDE, nothing beats Visual Studio (IMHO). Maybe Mac has something like it, I don't know.
I've figured out how to code for PropGCC inside Visual Studio and I must say it's a real pleasure, compared to the other tools.
So, if it were me, I'd be inclined to see if the Visual Basic IDE could be used for PropBasic code...
Just as a test, I created a new VB project for the "Console".
Here's what VB gives you automatically:
Module Module1
Sub Main()
End Sub
End Module
Anyway, if that type of format could be used, maybe one could use VB for the editor and then get someone to make us a Basic2Cpp program...
Comments
Keep in mind that there is also a very good BASIC implementation "Propeller Color BASIC" that is used on the Propellerpowered Pocket Mini Computer. All I'm saying is that having common syntax and features might be a nice thing.
Do you think that a SimpleIDE BASIC should require object libraries for extensibility or should it have built in commands for graphics, coms, sound, etc... (I'm in favor of the latter
I thought the initial idea was that it should a drop dead simple IDE for C on the Propeller much like the Arduino IDE is for the AVRs. Only better:) I was already worried about the idea of throwing Spin into Simple IDE.
Adding in BASIC, or anything, is OK but I would like to see it done in such away that the user is only presented with one language at a time. Perhaps that means forking Simple IDE into different versions for different compilers. Perhaps it means supporting all possibilities from the same code base but being able to build different IDEs from it.
Telegrams charged by the character. They used STOP instead of . so they could charge for four characters instead of one. This was an early example of a clever idea that ticked off customers.
It this true? Can't one create strings that the basic interpreter won't compile? Doesn't the B-to-C xlator only have to produce the identical output as the BASIC?
Log file? "BASIC input = C output" , statement by statement. Since this must be happening anyway, it should be trivial, and disk space is cheap.
Yes. However that does not even work for C if you turn on optimizations. You can easily get into the situation where the compiler rearranges code or removes unused things. All of a sudden the is no one to one corresondence between source line numbers and executable instructions. Can be very confusing when debugging.
POST @KC_Rob PARAGRAPH SENTENCE yes, it's subjective END SENTENCE SENTENCE for sure it has been discussed and debated to death over the years END SENTENCE SENTENCE sometimes I just can't resist throwing in my feelings about it END SENTENCE SENTENCE it's probably better to just ignore it END SENTENCE END PARAGRAPH PARAGRAPH QUESTION what I don't understand is why such verbose markup is desired by some for their programming language but there has never been such demand in natural language END QUESTION END PARAGRAPH END POST -- I rest my case.<mode>
<levity = on >
hahahahah. alas we are born to suffer through it.
</levity>
</mode>
(PS - I think your analogy would work better with a programming language which had more than one type of "stop" instead of only curly brackets.)
Haa! yes I forgot. They invented XML/HTML so as to avoid all that bother with full stops and paragraph spacing. Don't get me started on that....
KC_Rob,
The Arduino may be two dumbed down for you and I. When talking about keeping SimpleIDE simple I'm not really thinking of marketing the Prop to artistic types. More along the lines of that ocean of people, who may or may not be younsters, who have never programmed before. They don't even know what a program or a programming language is or what you might be able to do with it. They certainly don't want to be hit with even "select language: C, Spin BASIC, ALGOL..." questions or options. The natural response of normal people to that is "Bah, this is too hard, get me out of here".
As I have often said the smartest part of the Arduino setup is that they don't even name the language they are presenting.
I have often thought about this, as you might guess.
On the one hand we have languages like lisp and scheme that only have round brackets. Arguably that's all they need as their syntactical constructs are so simple and few. The result is a bewildering mess of round brackets with some code hidden here and there all of which is a real pain to read let alone write. That dooms those language to a niche of freaks why can handle that situation.
On the other hand we have languages in the C style where there are square brackests for array indexing, round brackets for parameter lists, conditionals, etc and "hamberger buns" for code block delimiting and data initializers. Those different brackets give you a good clue as to what you are looking at in a concise way.
On a third hand we have the over the top verbose languages like Ada and Cobol which as it turns out nobody want to use.
Adding more kinds of "stop" to those C style syntaxes would require more bracket styles to choose from which normal keyboards don't have. And it would look messy anyway. The "hambuger buns", I guess Americans might not like me just calling them just "buns", have an advantage in that I can change a "while" to a "for" or such like change without having to go and change the "stop bun".
My thesis is that Simple IDE has no need to grow into a huge complex, all singing all dancing, multi-language, plugin infested nightmare like Eclipse. We already have Eclipse. It should be, as it is, dead easy and quick to install. Dead easy and quick to just write your first line of code and have it run.
As for the professionals who might think it's a toy. I would not worry, those guys have their prefered dev set ups. From Eclipse down to vim and the command line. Don't forget that millions of AVRs are sold outside of the Arduino world.
Couldn't be any worse than swimming in a sea of curly brackets. But that's just my take.
Quote from ersmith in the benchmark thread: "In LMM mode GCC does not generate djnz, so its loop is a bit bigger (using a cmp and branch). The loop does fit into the FCACHE area in the COG and so executes without LMM overhead, which explains why GCC's LMM time is close to PropBasic's COG time."
Ouch, I have considered that as well. Actually when I was messing around following Jack Crenshaw's "Let's Build a Compiler" I tried putting together differnet dialects with different delimeters. I did not come up with a nicer solution than the buns.
If you use multi charater delimeters, and different ones for "if", "while", "case" etc you are going to end up with, for example:
if (a) while (b) ... /& /%Or some such. Which is going to look like line noise on the screen (Or Perl anyway) and is going to be even more beginner unfriendly than what we have now with the buns. Buns are at least consistant, they delimit a block of code in the same way no matter in which construct that block lives.
I've figured out how to code for PropGCC inside Visual Studio and I must say it's a real pleasure, compared to the other tools.
So, if it were me, I'd be inclined to see if the Visual Basic IDE could be used for PropBasic code...
Just as a test, I created a new VB project for the "Console".
Here's what VB gives you automatically:
Module Module1 Sub Main() End Sub End ModuleAnyway, if that type of format could be used, maybe one could use VB for the editor and then get someone to make us a Basic2Cpp program...