I have a hard time understanding what it means to compile JS to byte code. For example, if my program using the number X is compiled to byte code presumably the generated byte code handles X as a number. But my program can change the type of X at anytime, X = {}. Then what?
Or do they Just In Time compile to byte code such that the byte code can be regenerated on the fly when a type changes like that?
Or is it so that one can design a byte code that handles all this without recompilation? Perhaps with enough indirection anything is possible.
At least the byte code compilers I've written for interactive languages use a generic structure to store a value basically consisting of a type tag and a union for all of the different types. That way a variable can take on any type of value. Of course, that is less storage efficient than inferring the types from usage so more sophisticated byte code compilers probably do some level of type inference.
typedef enum {
typeInteger,
typeFloat,
typePointer
} ValueType;
typedef struct value {
ValueType type;
union {
int integerValue;
float floatValue;
void *pointerValue;
};
} Value;
For example, if my program using the number X is compiled to byte code presumably the generated byte code handles X as a number. But my program can change the type of X at anytime, X = {}. Then what?
That will happen in different places, so bytecode using X as string in one location will not contradict bytecode using X as list in a different location.
Meanwhile, over on another famous language ranking, th7e TIOBE index, this month sees assembly language break into the top 10 ! http://www.tiobe.com/tiobe-index/
Some of that is being driven by machine learning applications. The core math is a matrices type that compilers generally do not optimize well. People have been writing assembly functions to optimize for performance. It can be a 10x delta in many cases.
Why was JS made in this flexible manner to begin with?
Good question.
As far as I understand the history...
Netscape wanted a simple scripting language for the browser. We already had Java which was considered too complex for the non-programmer, normal person. What with all that Smile you had to write about data types, classes etc.
Java applets were also slow to load and run and not at all integrated into the HTML rendering which was the browsers main point in being. And they needed the extra hurdle of compilation.
Of course if you want to make a language simple and concise you end up with no type declarations, no classes, no "main" function, etc. Something very flexible.
The same sort of reasoning behind the development of BASIC years before.
The "web" was supposed to be open to all. So the scripting language had better be accessible to all. It's an ideological thing.
Netscape hired the young Brendan Eich to build their scripting language. Brendan proceeded to design a language inspired by Self. A dialect of the famous Smalltalk from Xerox PARC.
Netscape said "No. Great stuff but it's to weird. Can you make it look like C/Java that is familiar to people."
The result is Javascript. Formerly "Mocha", then "LiveScript". Formally "ECMAScript"
Legend has it that JS was built in 10 days!
The end result of this contorted history is that the "dumb, simple, slow scripting language that is only good for handling browser clicks" and ignored by "real programmers" for decades is and always was very sophisticated. Having features that languages like Java, C++ and C# have only recently begun to acquire, in their clunky baroque ways. Like first class functions, lambdas, prototypical inheritance.
It's sad that all the names for JS are horrible. "Javascript" smells of the horrible Java. ECMAScript sounds like medicine for a skin disease. I think we should just call it "ES".
Oh, I forgot. One of Javascript's main features is it's event driven programming model. Unlike traditional languages that have a "main" line and crunch round and around as if they control everything.
You can't do that in a browser, it would hang up user interaction whilst waiting for a mouse click or some fetch from the net. Or it would have to poll everything which is horrible inefficient.
Traditional languages tackle that problem by introducing threads. A whole huge pile of complexity and confusion.
To make it simple JS does not have polling or threads. One simply attaches bits of code to mouse clicks, responses from net requests, etc, that get run when the event happens. Easy.
Turns out this is also a very nice and efficient way to make server side code that has to juggle all kind of events, HTTP requests, timer events, database responses, etc, etc.
We see what is going on today, and awesome things can get served up in a browser.
Back then, you know Netscape had those ideas too.
JS is loose, or permissive if you will, because the optimal cases were not known. Best to make a lot possible and robust and see what comes. And being that way, adding bits here and there are likely done with less hassle and inertia too, as those bits can be just as permissive as the rest of it is.
That's my take after reading on these things you mentioned.
Some of that is being driven by machine learning applications. The core math is a matrices type that compilers generally do not optimize well. People have been writing assembly functions to optimize for performance. It can be a 10x delta in many cases.
I have heard that said before recently. I don't buy it.
I'm sure if you want to deal with huge matrices then throwing them at the standard C++ library or whatever is going to be inefficient.
Even a simple matrix multiply gets you into two nested loops and ends up dealing with data that is spread far and wide in memory. Thus causing billions of cache misses and slowing things down horribly. By a factor of 10 or a hundred or more.
If you can rearrange your algorithm to be careful to keep data in the "working set" as much as possible (i.e. in cache) you can realize huge performance boosts.
After that, rewriting the thing in assembler is not going to buy you much.
Of course there will always be demand for assembler programmers and those that understand machine architectures. Someone has to write compilers and interpreters after all. And operating systems.
JS is loose, or permissive if you will, because the optimal cases were not known. Best to make a lot possible and robust and see what comes. And being that way, adding bits here and there are likely done with less hassle and inertia too, as those bits can be just as permissive as the rest of it is.
My take on it is that to make it simple for non-programmers, beginners, casual programmers it has to be as simple to reason about from the get go as possible.
So typing:
a = 2
b = 3
a + b
and getting the result "5" is a lot easier than:
#include <stdio.h>
int main (int argc, char* argv[])
{
int a = 2;
int b = 3;
printf("%d\n", a + b);
return (0);
}
In C. Or worse...
public class HelloWorld {
public static void main(String[] args) {
int a = 2;
int b = 3;
System.out.println(a + b);
}
}
In Java.
Plus the compilation step needed.
The rest follows from there.
The magic trick is to design a language that is so easy to start with, from knowing nothing about programming, but is also sophisticated enough to keep experts happy.
As for "adding bits here and there" the Javascript language was amazingly stable and unchanging for many years. More so than many others. Recently there has been a spurt of activity in the language standard. Most of that seems to be syntactic fluff of little benefit designed to appease Java refugees. Like the "class" construct.
I worry that if this pressure continues JS will be turned into a tortuous gibberish.
function silly (x, y) {
return x + y;
}
console.log(silly(2, 3)); // Prints "5"
console.log(silly("Hello", " Yeti)); // Prints "Hello Yetti"
console.log(silly("Hello", {})); // Prints "Hello[object Object]"
Should the byte code for the silly function add numbers or concatenate strings?
There are many other cases.
In this case there is an addition for all the types thrown at that function. So as long as "+" looks at the types I see no reason why it could not be a type-aware bytecode "+"...
Edit @ 20170216-0545-GMT:
It is possible to have a type-aware bytecode addition. My JS knowledge is neglectable, but why should JS not be capable to do what Python can do?
I suspect you are right and that's probably what JS engines that use byte code do.
Things are bit different with JIT Javascript engines that will generate machine code to handle specific types and try to optimize it. But if your program then uses that compiled code with a different type all the JITed optimized machine code gets thrown away and you are back to some slow old unoptimized code.
By using the right options to the node.js run time it will report when functions get deoptimized.
function silly (x, y) {
return x + y;
}
console.log(silly(2, 3)); // Prints "5"
console.log(silly("Hello", " Yeti)); // Prints "Hello Yetti"
console.log(silly("Hello", {})); // Prints "Hello[object Object]"
Should the byte code for the silly function add numbers or concatenate strings?
There are many other cases.
In this case there is an addition for all the types thrown at that function. So as long as "+" looks at the types I see no reason why it could not be a type-aware bytecode "+"...
Edit @ 20170216-0545-GMT:
It is possible to have a type-aware bytecode addition. My JS knowledge is neglectable, but why should JS not be capable to do what Python can do?
This is exactly what my virtual machines have always done. I think it's pretty common. A JIT that compiles to machine code will obviously generate faster code.
So maybe JS on the P2 is still not practical. But maybe we could go another way. Suppose (warning: blasphemous statements past this point) Spin were to be redone with a curly-brace syntax. In other words, make it look like JS (and Java,C,C++,C#, etc.). In other words, make it a curly-brace language. Here's my reasoning:
* Even if you could fully support JS, there are a number of aspects of the P2 that would require custom extensions (or possibly complex and inconvenient constructs that conform to JS).
* If it's a given that a JS implementation would be significantly custom, then it begs the question "why JS over any other scripting language?"
* For instance, why not just use Spin? Well, to everyone who's never used a Propeller, Spin looks foreign. It certainly doesn't look like a familiar curly-brace language.
* So why not make Spin look more familiar by making it a curly-brace language? It can still be as custom as we need it to be, because very little of that actually affects the basic syntax (i.e. you still have if/else blocks, you still have conditional loops, you still have block statements, etc.)
* With a curly-brace Spin, newcomers immediately have some level of familiarity/understanding. Learning the particulars of curly-brace Spin is no different than learning the particulars of any other curly-brace language.
* With a curly-brace Spin, some curly-brace code from other environments can be copied with little or no modification/translation.
* With a curly-brace Spin, some code can more easily be migrated to gcc when you want to move your codebase to C/C++.
Okay, maybe you don't call it "Spin" any more. "PropScript" or "PScript", maybe?
So maybe JS on the P2 is still not practical. But maybe we could go another way. Suppose (warning: blasphemous statements past this point) Spin were to be redone with a curly-brace syntax. In other words, make it look like JS (and Java,C,C++,C#, etc.). In other words, make it a curly-brace language. Here's my reasoning:
* Even if you could fully support JS, there are a number of aspects of the P2 that would require custom extensions (or possibly complex and inconvenient constructs that conform to JS).
* If it's a given that a JS implementation would be significantly custom, then it begs the question "why JS over any other scripting language?"
* For instance, why not just use Spin? Well, to everyone who's never used a Propeller, Spin looks foreign. It certainly doesn't look like a familiar curly-brace language.
* So why not make Spin look more familiar by making it a curly-brace language? It can still be as custom as we need it to be, because very little of that actually affects the basic syntax (i.e. you still have if/else blocks, you still have conditional loops, you still have block statements, etc.)
* With a curly-brace Spin, newcomers immediately have some level of familiarity/understanding. Learning the particulars of curly-brace Spin is no different than learning the particulars of any other curly-brace language.
* With a curly-brace Spin, some curly-brace code from other environments can be copied with little or no modification/translation.
* With a curly-brace Spin, some code can more easily be migrated to gcc when you want to move your codebase to C/C++.
Okay, maybe you don't call it "Spin" any more. "PropScript" or "PScript", maybe?
While I'm not that excited about Spin using indentation for block structure that isn't really my main objection to the language. What I really miss is first-class objects that can be passed to functions as parameters and also some form of inheritance. The syntax issues are minor for me. In fact, I don't mean to imply that I don't like Spin. I just mean that these are the features I would want to see added rather than a syntax overhaul.
While I'm not that excited about Spin using indentation for block structure that isn't really my main objection to the language. What I really miss is first-class objects that can be passed to functions as parameters and also some form of inheritance. The syntax issues are minor for me. In fact, I don't mean to imply that I don't like Spin. I just mean that these are the features I would want to see added rather than a syntax overhaul.
My suggestion wasn't particularly addressing what features should be added to Spin. That's a whole separate topic from the syntax being used.
As for syntax, I think it is somewhat important. Most of my workday currently revolves around C#. Moving between that and a non-curly-brace languages often causes a bit of dissonance that I would rather not deal with. For instance, I'm currently doing some Lua programming as well. And I keep forgetting the "then" at the end of "if" statements! But, I am also doing some TypeScript programming. In that case, there are certainly difference from C# that I have to remember, but general syntax is not one of them (for the majority of code).
Incidentally, curly-brace syntax is not the only way we could go. It's just that we were talking about JS, so that was the natural syntax to focus on (it also encompasses well over 50% of the popular programming languages being used today). But, in the world that Propeller chips live in (microcontrollers, IoT, etc), I could also see an argument for syntax that looks like Python, and maybe even Lua.
But, to invent an entirely new language (Spin) and not start with what's familiar only makes sense (to me) if the language requirements deviate considerably from what's been done before. And, in this case, Spin doesn't deviate that much. It's still primarily a cross between an imperative language and a simple object-oriented language. And the majority of the programming world do imperative and object-oriented programming in a curly-brace language.
I love spin for its simplicity and forced indentation.
However, I would think that a braces style syntax vs spin syntax could be done by simple conversion via a format button, similar to turning the PropTool indentation markers on/off. To identify the braces format a parameter at the beginning of the file would be inserted.
This might be a big help in marketing "spin" as more like those other languages (such as C etc) than it is now.
I don't think adding braces to Spin is a good idea. It won't be enough to attract people who only like C-like languages unless you also adopt all of the C operators and the rest of the C syntax. What you could do I suppose is what XMOS did, extend C with Propeller-oriented constructs but that would not be Spin anymore.
Yeah, I agree with David. Adding braces to Spin would negate one of its signal advantages: i.e. the lack of syntactical gingerbread. What's the opposite of putting lipstick on a pig? Muddying a supermodel? I dunno. But whatever it is, that's what adding braces to Spin would be.
Yeah, I agree with David. Adding braces to Spin would negate one of its signal advantages: i.e. the lack of syntactical gingerbread. What's the opposite of putting lipstick on a pig? Muddying a supermodel? I dunno. But whatever it is, that's what adding braces to Spin would be.
-Phil
Well, I guess whether you characterize it as a pig or a supermodel is a matter of opinion. I'd choose something in the middle I think. :-)
Well, there is familiarity, but several use cases to consider:
First, we are gonna have a nice C environment. Bet you we get JS too. I'm interested in that actually.
But, there are people who aren't into this stuff like we are. Set preferences aside, and SPIN + PASM + PropTool are seriously good for introductory work. Prototyping too. It's nuts good. One metric I use is related to myself in that I am often away from this stuff. Sometimes I hit it really hard too. SPIN is super lean, and in a recent project, just knocked it out of the park. Was able to bring the others up, and they were productive. Some came from our background, others were noobs all around. Didn't matter. Literally took a coupla days for them to get going and write a lot of effective code.
Then there are those of us who have strong preferences. Adding braces really could help attract people, but isn't that what having C was for? Why not go for the real deal? On P2, it's gonna be effective. We should see more use and for more purposes. (and we should see the thing get done this year too. Fingers crossed! Good times coming.)
And there are people, who may or may not be pros, but who can handle advanced things. Adding a couple features to SPIN to satisfy them seems like a great move. It can be done without over complicating things, and again on P2, inline PASM is going to rock hard. And we have it with ersmith's work. (which I want to jump on and write some code now that I've got some time to do it again.) The nice thing about this one is it can take all of us, who enjoy how lean SPIN is, forward some, and it won't really impact the "just jump in and go" use case that makes it high value. I hope we can add these in ways that leave existing SPIN intact, just as it is, programs run, and all that. The reasons are both compatibility, which will get used, and the current SPIN language hits a nice, sweet spot IMHO.
Finally, remember there are always constants. At any given time, total newbies are getting into this stuff and SPIN + PASM + PropTool is every bit as effective for this as it ever was. Nothing broken, and still relevant. There are always experienced people, always ones with specific preferences, and the whole nine.
We often talk in terms of ourselves and community, and that's natural and fine, but not always the most effective perspective on all this, IMHO of course.
**For me, I can write in various languages. I vary a lot in my skill, depending on how long I've been away, or what I've done. Curly braces are something I really dislike, and it's down to selfish reasons.
One, they eat up vertical space. SPIN is lean and compact on many fronts. This is one of them. (and yes, I know I don't have to take the space, but that's just crappy to read too.)
Another is I'm near constantly missing one. Indents are super easy! When I did some Python, I got introduced to this delimiter idea right about the time I was exploring SPIN. At first, sided with the curly braces people, but it didn't take but a couple days to realize how easy it was to see most cases. Some of this is editor specific, like PropTool and it's intent guides, but other editors have options, and when one uses them, it's not hard.
Wow. I just read this whole thread. Lots of ideas.
I really like this example someone gave:
a = 2
b = 3
c = a + b
It's simple and there's no need to declare variables.
Maybe there could be some framework that allows those simple kinds of declarations to coexist with compiled code. It would be really neat to be able to try out objects by having live conversations with them, before operating them through code.
Could just allow multi-line input. Working with compiled code would be good.
Multi line would take blocks. Paste in a PASM block, procedure, whatever. Or type it right in.
Either way, a new definition just overwrites the existing one, or creates new.
On successful input, it gets compiled, or assembled right then using the environment present.
It's all interactive that way.
If the input is buffered, a user could list and get all successful input sorted in various ways. This would be stored procedures and functions. This display would contain all data, variables, procedures, functions and state, values of anything callable.
A user could type history and get it all exactly as input too. This is just the interactive session.
The product would be the ability to do it the text editor, compile, etc... way
Or, build up a program a piece at a time, listing or history to screen for other uses, repeat input or archive for use or expansion in a text editor.
The compiler could be simple and effective. For the best code, use non interactive means.
Maybe there could be some framework that allows those simple kinds of declarations to coexist with compiled code.
It's not clear to me how one would do that. To get rid of type declarations one could create a language with only one type, say long, so that it never has to be specified.
Otherwise one needs to have type information stored with every variable so that the system knows what it is at all times. Which means an interpreter or some complex byte code. It all gets big and complicated.
Or, just use Javascript. Potentially a small JS engine, like Espruino or JerryScript, could be included in a users compiled binary program written in Spin, or whatever language. The user could interact with that. How that JS would interact with the users Spin code is another problem....
Comments
typedef enum { typeInteger, typeFloat, typePointer } ValueType; typedef struct value { ValueType type; union { int integerValue; float floatValue; void *pointerValue; }; } Value;That does not help much with Javascript's "eval" and "Function" which involve creating new code out of strings.
One starts to see why Epruino interprets directly from the source text. No space for a compiler like that.
It can happen in the same place.
function silly (x, y) { return x + y; } console.log(silly(2, 3)); // Prints "5" console.log(silly("Hello", " Yeti)); // Prints "Hello Yetti" console.log(silly("Hello", {})); // Prints "Hello[object Object]"Should the byte code for the silly function add numbers or concatenate strings?There are many other cases.
I have a question. Been reading this thread with interest.
I see a lot of, "should be this way" ideas floating around. Not questioning them. All well reasoned.
Why was JS made in this flexible manner to begin with?
Some of that is being driven by machine learning applications. The core math is a matrices type that compilers generally do not optimize well. People have been writing assembly functions to optimize for performance. It can be a 10x delta in many cases.
As far as I understand the history...
Netscape wanted a simple scripting language for the browser. We already had Java which was considered too complex for the non-programmer, normal person. What with all that Smile you had to write about data types, classes etc.
Java applets were also slow to load and run and not at all integrated into the HTML rendering which was the browsers main point in being. And they needed the extra hurdle of compilation.
Of course if you want to make a language simple and concise you end up with no type declarations, no classes, no "main" function, etc. Something very flexible.
The same sort of reasoning behind the development of BASIC years before.
The "web" was supposed to be open to all. So the scripting language had better be accessible to all. It's an ideological thing.
Netscape hired the young Brendan Eich to build their scripting language. Brendan proceeded to design a language inspired by Self. A dialect of the famous Smalltalk from Xerox PARC.
Netscape said "No. Great stuff but it's to weird. Can you make it look like C/Java that is familiar to people."
The result is Javascript. Formerly "Mocha", then "LiveScript". Formally "ECMAScript"
Legend has it that JS was built in 10 days!
The end result of this contorted history is that the "dumb, simple, slow scripting language that is only good for handling browser clicks" and ignored by "real programmers" for decades is and always was very sophisticated. Having features that languages like Java, C++ and C# have only recently begun to acquire, in their clunky baroque ways. Like first class functions, lambdas, prototypical inheritance.
It's sad that all the names for JS are horrible. "Javascript" smells of the horrible Java. ECMAScript sounds like medicine for a skin disease. I think we should just call it "ES".
That is how I see it anyway.
You can't do that in a browser, it would hang up user interaction whilst waiting for a mouse click or some fetch from the net. Or it would have to poll everything which is horrible inefficient.
Traditional languages tackle that problem by introducing threads. A whole huge pile of complexity and confusion.
To make it simple JS does not have polling or threads. One simply attaches bits of code to mouse clicks, responses from net requests, etc, that get run when the event happens. Easy.
Turns out this is also a very nice and efficient way to make server side code that has to juggle all kind of events, HTTP requests, timer events, database responses, etc, etc.
Hence the rise of node.js in recent times.
Back then, you know Netscape had those ideas too.
JS is loose, or permissive if you will, because the optimal cases were not known. Best to make a lot possible and robust and see what comes. And being that way, adding bits here and there are likely done with less hassle and inertia too, as those bits can be just as permissive as the rest of it is.
That's my take after reading on these things you mentioned.
I'm sure if you want to deal with huge matrices then throwing them at the standard C++ library or whatever is going to be inefficient.
Even a simple matrix multiply gets you into two nested loops and ends up dealing with data that is spread far and wide in memory. Thus causing billions of cache misses and slowing things down horribly. By a factor of 10 or a hundred or more.
If you can rearrange your algorithm to be careful to keep data in the "working set" as much as possible (i.e. in cache) you can realize huge performance boosts.
After that, rewriting the thing in assembler is not going to buy you much.
Of course there will always be demand for assembler programmers and those that understand machine architectures. Someone has to write compilers and interpreters after all. And operating systems.
So typing: and getting the result "5" is a lot easier than:
#include <stdio.h> int main (int argc, char* argv[]) { int a = 2; int b = 3; printf("%d\n", a + b); return (0); }In C. Or worse...public class HelloWorld { public static void main(String[] args) { int a = 2; int b = 3; System.out.println(a + b); } }In Java.Plus the compilation step needed.
The rest follows from there.
The magic trick is to design a language that is so easy to start with, from knowing nothing about programming, but is also sophisticated enough to keep experts happy.
As for "adding bits here and there" the Javascript language was amazingly stable and unchanging for many years. More so than many others. Recently there has been a spurt of activity in the language standard. Most of that seems to be syntactic fluff of little benefit designed to appease Java refugees. Like the "class" construct.
I worry that if this pressure continues JS will be turned into a tortuous gibberish.
In this case there is an addition for all the types thrown at that function. So as long as "+" looks at the types I see no reason why it could not be a type-aware bytecode "+"...
Edit @ 20170216-0545-GMT:
It is possible to have a type-aware bytecode addition. My JS knowledge is neglectable, but why should JS not be capable to do what Python can do?
$ python Python 2.7.9 (default, Jun 29 2016, 13:08:31) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> def adder(a,b): ... return a+b ... >>> import dis >>> dis.dis(adder) 2 0 LOAD_FAST 0 (a) 3 LOAD_FAST 1 (b) 6 BINARY_ADD 7 RETURN_VALUE >>> X="Hello " ; Y="Heater!" >>> adder(X,Y) 'Hello Heater!' >>> X=2 ; Y=3 >>> adder(X,Y) 5 >>> _Things are bit different with JIT Javascript engines that will generate machine code to handle specific types and try to optimize it. But if your program then uses that compiled code with a different type all the JITed optimized machine code gets thrown away and you are back to some slow old unoptimized code.
By using the right options to the node.js run time it will report when functions get deoptimized.
* Even if you could fully support JS, there are a number of aspects of the P2 that would require custom extensions (or possibly complex and inconvenient constructs that conform to JS).
* If it's a given that a JS implementation would be significantly custom, then it begs the question "why JS over any other scripting language?"
* For instance, why not just use Spin? Well, to everyone who's never used a Propeller, Spin looks foreign. It certainly doesn't look like a familiar curly-brace language.
* So why not make Spin look more familiar by making it a curly-brace language? It can still be as custom as we need it to be, because very little of that actually affects the basic syntax (i.e. you still have if/else blocks, you still have conditional loops, you still have block statements, etc.)
* With a curly-brace Spin, newcomers immediately have some level of familiarity/understanding. Learning the particulars of curly-brace Spin is no different than learning the particulars of any other curly-brace language.
* With a curly-brace Spin, some curly-brace code from other environments can be copied with little or no modification/translation.
* With a curly-brace Spin, some code can more easily be migrated to gcc when you want to move your codebase to C/C++.
Okay, maybe you don't call it "Spin" any more. "PropScript" or "PScript", maybe?
My suggestion wasn't particularly addressing what features should be added to Spin. That's a whole separate topic from the syntax being used.
As for syntax, I think it is somewhat important. Most of my workday currently revolves around C#. Moving between that and a non-curly-brace languages often causes a bit of dissonance that I would rather not deal with. For instance, I'm currently doing some Lua programming as well. And I keep forgetting the "then" at the end of "if" statements! But, I am also doing some TypeScript programming. In that case, there are certainly difference from C# that I have to remember, but general syntax is not one of them (for the majority of code).
Incidentally, curly-brace syntax is not the only way we could go. It's just that we were talking about JS, so that was the natural syntax to focus on (it also encompasses well over 50% of the popular programming languages being used today). But, in the world that Propeller chips live in (microcontrollers, IoT, etc), I could also see an argument for syntax that looks like Python, and maybe even Lua.
But, to invent an entirely new language (Spin) and not start with what's familiar only makes sense (to me) if the language requirements deviate considerably from what's been done before. And, in this case, Spin doesn't deviate that much. It's still primarily a cross between an imperative language and a simple object-oriented language. And the majority of the programming world do imperative and object-oriented programming in a curly-brace language.
However, I would think that a braces style syntax vs spin syntax could be done by simple conversion via a format button, similar to turning the PropTool indentation markers on/off. To identify the braces format a parameter at the beginning of the file would be inserted.
This might be a big help in marketing "spin" as more like those other languages (such as C etc) than it is now.
-Phil
First, we are gonna have a nice C environment. Bet you we get JS too. I'm interested in that actually.
But, there are people who aren't into this stuff like we are. Set preferences aside, and SPIN + PASM + PropTool are seriously good for introductory work. Prototyping too. It's nuts good. One metric I use is related to myself in that I am often away from this stuff. Sometimes I hit it really hard too. SPIN is super lean, and in a recent project, just knocked it out of the park. Was able to bring the others up, and they were productive. Some came from our background, others were noobs all around. Didn't matter. Literally took a coupla days for them to get going and write a lot of effective code.
Then there are those of us who have strong preferences. Adding braces really could help attract people, but isn't that what having C was for? Why not go for the real deal? On P2, it's gonna be effective. We should see more use and for more purposes. (and we should see the thing get done this year too. Fingers crossed! Good times coming.)
And there are people, who may or may not be pros, but who can handle advanced things. Adding a couple features to SPIN to satisfy them seems like a great move. It can be done without over complicating things, and again on P2, inline PASM is going to rock hard. And we have it with ersmith's work. (which I want to jump on and write some code now that I've got some time to do it again.) The nice thing about this one is it can take all of us, who enjoy how lean SPIN is, forward some, and it won't really impact the "just jump in and go" use case that makes it high value. I hope we can add these in ways that leave existing SPIN intact, just as it is, programs run, and all that. The reasons are both compatibility, which will get used, and the current SPIN language hits a nice, sweet spot IMHO.
Finally, remember there are always constants. At any given time, total newbies are getting into this stuff and SPIN + PASM + PropTool is every bit as effective for this as it ever was. Nothing broken, and still relevant. There are always experienced people, always ones with specific preferences, and the whole nine.
We often talk in terms of ourselves and community, and that's natural and fine, but not always the most effective perspective on all this, IMHO of course.
**For me, I can write in various languages. I vary a lot in my skill, depending on how long I've been away, or what I've done. Curly braces are something I really dislike, and it's down to selfish reasons.
One, they eat up vertical space. SPIN is lean and compact on many fronts. This is one of them. (and yes, I know I don't have to take the space, but that's just crappy to read too.)
Another is I'm near constantly missing one. Indents are super easy! When I did some Python, I got introduced to this delimiter idea right about the time I was exploring SPIN. At first, sided with the curly braces people, but it didn't take but a couple days to realize how easy it was to see most cases. Some of this is editor specific, like PropTool and it's intent guides, but other editors have options, and when one uses them, it's not hard.
I really like this example someone gave:
a = 2
b = 3
c = a + b
It's simple and there's no need to declare variables.
Maybe there could be some framework that allows those simple kinds of declarations to coexist with compiled code. It would be really neat to be able to try out objects by having live conversations with them, before operating them through code.
Multi line would take blocks. Paste in a PASM block, procedure, whatever. Or type it right in.
Either way, a new definition just overwrites the existing one, or creates new.
On successful input, it gets compiled, or assembled right then using the environment present.
It's all interactive that way.
If the input is buffered, a user could list and get all successful input sorted in various ways. This would be stored procedures and functions. This display would contain all data, variables, procedures, functions and state, values of anything callable.
A user could type history and get it all exactly as input too. This is just the interactive session.
The product would be the ability to do it the text editor, compile, etc... way
Or, build up a program a piece at a time, listing or history to screen for other uses, repeat input or archive for use or expansion in a text editor.
The compiler could be simple and effective. For the best code, use non interactive means.
Otherwise one needs to have type information stored with every variable so that the system knows what it is at all times. Which means an interpreter or some complex byte code. It all gets big and complicated.
Or, just use Javascript. Potentially a small JS engine, like Espruino or JerryScript, could be included in a users compiled binary program written in Spin, or whatever language. The user could interact with that. How that JS would interact with the users Spin code is another problem....