JavaScript for the Propeller ?
Heater.
Posts: 21,230
One of my current fantasies is to be able to program the Prop II in JavaScript.
If you are crazy like me you might like to help...
I started playing with TinyJS a while back, a very small JavaScript interpreter written in C++ by Gordon Williams. TinyJS can be compiled with prop-gcc and runs on the FPGA implementation of the Prop II. So far so good but it is rather large and slow. It would take quite a bit of work to optimize it and add all the goodies we need for accessing Propeller features from JavaScript.
Turns out Gordon has been doing all that work already. However that effort is for the small ARM processors and he has not opened sourced his code, yet...
Gordon now has a kickstarter project going with plans to build a little custom ARM board especially for running JavaScript. The plans include open sourcing all the hardware design and the JS interpreter when the kickstarter goal is met.
This is totally awesome by itself but it does mean that if his project is a success we then get access to the interpreter source code and will have a solid piece of work that can be adapted to the Propeller II.
So I'm urging anyone who is interested to have a look at the "Espruino: JavaScript for Things" kickstarter project page and pony up a few beers worth of money to help make it come true. Then we can get down to adapting it for the Prop II and perhaps coming up with a board customized to run it.
"Why JavaScript on the Propeller?" I hear you say.
Well, we have lot's of languages for the Prop now, Spin, C, BASIC, Forth etc etc and everyone likes to use their own favorites. However there are millions of people out there who are familiar with JavaScript. All the worlds web page builders. They don't want to be getting down to the low levels of the languages we have today. They don't want to be learning yet another language, they already have a hard enough time having to deal with HTML, CSS, PHP and all that other wonky web technology. Having JavaScript might be a good "carrot" to get them thinking about exploring the embedded systems world and electronics tinkering. And getting more Props sold.
JavaScript is now moving into the server end of operations with things like node.js. It would be just fitting to be able to program everything from sensors to server to web pages in the same language.
"Won't JavaScript be a bit slow?" you ask.
Perhaps it will, but a slow JS on the Prop II might be better than a slow JS on a small ARM. If one cog is handling JS the other seven are available for running that high speed real-time stuff in parallel. Where as the ARM just has to be slow. Also having video output available is a compelling advantage over the ARM boards.
The kickstarter project is here:
http://www.kickstarter.com/projects/48651611/espruino-javascript-for-things
Gordon Williams popped up on the forum here:
http://forums.parallax.com/showthread.php/147256-Trying-to-build-TinyJS-for-the-Prop.?p=1203364&viewfull=1#post1203364
Update: 2013-09-27
The Espruindo kickstarter project was funded to five times it's initial goal! As a result the Espruino TinyJS interpreter is now available as open source here: https://github.com/espruino
I have forked the code to a repo here:
https://github.com/ZiCog/Espruino
and will be working on a Propeller target there.
If you are crazy like me you might like to help...
I started playing with TinyJS a while back, a very small JavaScript interpreter written in C++ by Gordon Williams. TinyJS can be compiled with prop-gcc and runs on the FPGA implementation of the Prop II. So far so good but it is rather large and slow. It would take quite a bit of work to optimize it and add all the goodies we need for accessing Propeller features from JavaScript.
Turns out Gordon has been doing all that work already. However that effort is for the small ARM processors and he has not opened sourced his code, yet...
Gordon now has a kickstarter project going with plans to build a little custom ARM board especially for running JavaScript. The plans include open sourcing all the hardware design and the JS interpreter when the kickstarter goal is met.
This is totally awesome by itself but it does mean that if his project is a success we then get access to the interpreter source code and will have a solid piece of work that can be adapted to the Propeller II.
So I'm urging anyone who is interested to have a look at the "Espruino: JavaScript for Things" kickstarter project page and pony up a few beers worth of money to help make it come true. Then we can get down to adapting it for the Prop II and perhaps coming up with a board customized to run it.
"Why JavaScript on the Propeller?" I hear you say.
Well, we have lot's of languages for the Prop now, Spin, C, BASIC, Forth etc etc and everyone likes to use their own favorites. However there are millions of people out there who are familiar with JavaScript. All the worlds web page builders. They don't want to be getting down to the low levels of the languages we have today. They don't want to be learning yet another language, they already have a hard enough time having to deal with HTML, CSS, PHP and all that other wonky web technology. Having JavaScript might be a good "carrot" to get them thinking about exploring the embedded systems world and electronics tinkering. And getting more Props sold.
JavaScript is now moving into the server end of operations with things like node.js. It would be just fitting to be able to program everything from sensors to server to web pages in the same language.
"Won't JavaScript be a bit slow?" you ask.
Perhaps it will, but a slow JS on the Prop II might be better than a slow JS on a small ARM. If one cog is handling JS the other seven are available for running that high speed real-time stuff in parallel. Where as the ARM just has to be slow. Also having video output available is a compelling advantage over the ARM boards.
The kickstarter project is here:
http://www.kickstarter.com/projects/48651611/espruino-javascript-for-things
Gordon Williams popped up on the forum here:
http://forums.parallax.com/showthread.php/147256-Trying-to-build-TinyJS-for-the-Prop.?p=1203364&viewfull=1#post1203364
Update: 2013-09-27
The Espruindo kickstarter project was funded to five times it's initial goal! As a result the Espruino TinyJS interpreter is now available as open source here: https://github.com/espruino
I have forked the code to a repo here:
https://github.com/ZiCog/Espruino
and will be working on a Propeller target there.
Comments
What platform is @rockbot currently using? Espruino? Laptops? Beagles? RasPi w/ Node?
Do you mean this rockbot? https://github.com/rockbot
Interesting but a long way short of getting JS into really small spaces.
Meanwhile after only a few days Gordon's kickstarter project for JS on dinky ARM chips is almost fully funded.
I'm kind of wondering what the disconnect between the Propeller world and the JS world is.
P.S. Perhaps I should have said that I don't know Gordon from Adam but it just seems like a crazy brilliant idea to me.
I'm just starting to dabble in JavaScript and all its friends (node, jQuery, etc.). I can see power but I also see it needing power and space to run effectively (Prop2).
Maybe it's not considered a traditional programming language (considered by many as more of a web developer tool?).
It's certainly not a traditional controller language.
Maybe it's the events?
Objects?
Anonymous functions?
First class functions?
Misunderstood?
Misrepresented?
The Kickstarter looks like a fun one to fund and it should be fun to play with the final board.
You just need to get out there and keep evangelizing. Show us some projects and examples, it's like the Forth community, there is a lot of talk but not a lot of concrete project examples.
I'm with you on this bandwagon (like that helps!
I suspect you are right.
JS is a really wonky language that does not fit in the traditional mold of C, Pascal, even Spin etc.
It's "obviously" stupid for small embedded systems. You know, big, interpreted, slow etc.
It's obviously "not a real language" what with not having anything in the way of a type system or compile time checks.
On the other hand. Java was supposed to be the language of the web originally with Java "applets". That idea proved unpopular as it was slow and clumsy
Or we have Spin which is interpreted and slow and lacks any type system, much like JavaScript.
On yet another hand, you forgot mention "closures" in JavaScript an amazing feature along with first class functions that makes all kind of weird stuff possible, It's such a nice idea that Java is trying to offer closures in it's next version and C++ can only dream of them.
At the end of the day you are right "Show us some projects and examples," or "Where is the beef?" as they used to say.
Looks like it's very possible that might come to be. So, Propeller world, be prepared for millions of web developers descending on the Propeller:)
I do realize this is more of a Propeller II thing. I just decided to put it here for maximum coverage. Hope nobody minds.
Gordon's project is fantastic. Eventually, JS will open up the PC to a Propeller Bot in many useful ways. I became a backer after seeing your thread.
Thanks
I must respectfully disagree. Java applets died because of the Microsoft and Sun lawsuit. Sun tried to keep Java pure, but their AWT UI technology was inadequate. Microsoft's extensions let you build some good UI's, but violated the license agreement. Swing was Sun's next attempt, but the credibility of applets was gone by then. Flash and Silverlight became popular because of inadequacy in the browser programming environment, but sidestepped Sun's intransigence with applets.
Now with HTML5 we're finally supposed to be able to build real applications with client side Javascript. Frankly Javascript is almost acceptable as a language, except but both Google (Dart) and Microsoft (Typescript) are working on replacements. So that seems to indicate some concerns about its viability.
I know absolutely nothing about JavaScript, or Java for that matter. To me it is another language in the forest.
However, I love making pasm programs run fast, and designing pcbs. So once the interpreter is released I will take a look.
I did this for the spin interpreter without actually understanding the internals between the spin language and its resultant calls.
Is HTML5 another possibility??? I have programmed a website in HTML4 so I understand the basics of 4, but not the latest extensions.
I must respectfully disagree.
Java applets died because Java as a language is stinking pile that brings nothing new to the table except the idea of compiling to byte codes that can run anywhere where there is a Java byte code interpreter. And even that was not new as byte code systems had been around decades before.
Verbose and ugly as Java is one could not actually do anything with it in the browser, it's intended homeland, without assistance from JavaScript. As a result web developers skipped the verbose and ugly part and went straight to JS where they could get stuff done.
Java has yet to catch up with the high level features of JavaScript. Like closures, which I understand will be in the next Java version in a predictably verbose and ugly fashion.
I'm curious why you say "almost acceptable". JS is a very high level and sophisticated language, arguably more so than Java.
@Cluso Well that is another can of worms. HTML is not a programming language but a markup language.
HTML5 seems to be a combination of markup (HTML) plus styles (CSS) plus JavaScript plus the most horrendous API in the world, the browser DOM.
In short HTML5 is a big ugly mess that we should keep away from our beloved Propellers.
Edit: Was I a bit strident about Java there? I'm sorry, some times things are actually bad enough that my genteel English manner breaks down.
It has C-like syntax.
Objects can be easily defined.
It has good libraries and lots of online help.
It has an easy, event driven HTML DOM interface.
It "can be written" so that it's easy to read*.
Here is one of my favorite Javascript web sites:
http://www.devguru.com/technologies/javascript/home
Here is a Javascript program I wrote long ago:
http://www.brouhaha.com/~sdenson/javascript/RentFlow6.html
*It can also be written so that it is impossible to understand.
In my mind Java is a language and AWT is a GUI tool kit. They are totally orthogonal things.
For example JavaScript gets a bad rap because it is normally associated with the browser GUI environment, the DOM, which is a total disaster. JavaScript itself, as a language is pretty cool.
Java applets failed because they did not actually interact with the browser which was the GUI after all. Never mind that they were slow to load and the whole user experience was a disaster.
Then they tried to push Java to embedded systems which naturally fell flat on it's face.
How Java ever took off on the server I will never know.
Let alone the burning with the fury of a billion exploding suns hatred I have for variables having both null or undefined values, or debugging to find errors that a compiler would find.
Now applets might stink, but we were able to build viable server push applications in Java applets because Java supports sockets. When applets fell out of favor we switched to C# and Silverlight which also supports sockets. Now HTML5 is adding support for Web sockets, but browser support is spotty on mobile platforms which is where all the action is right now. So we have yet to find a truly viable Javascript approach because all of them fail in some way. So we're building native apps in mobile, and as luck would have it we have a Java runtime that supports sockets as does objective C.
In short HTML5 and Javascript just don't work for what we've been doing.
Edit. The use case of JavaScript and DOM programming is exactly why I hate it. I don't care if the language is good or bad, but can I use it to get a task done.
As for "fighting technical debt" I spent the first 10 years or more of my career having to learn a new programming language and operating system with every new project that came along. JS is rock stable by comparison. Yep it's a pain. However I don't think it's any more of a pain than the weird stuff that goes on in languages like C or even Spin. Did you know you can add one to a value which is already the maximum size of a 32 bit signed integer and the compiler will not tell you? Worse still at run time it obediently does that producing a totally wrong result. How crazy is that?
All languages have their quirks. Many of them, like the above, we have been living wih for so long we think it's normal.
Bottom line is, compilers do not find bugs. Code reviews and testing do. Again that's not a language issue but an environment issue. Why it took so long for browsers to get a socket like interface is beond me.
What have you been doing? With HTML5 and JS I have streamed live data to a browser through a websocket and rendered it as a 3D animated scene with webgl. Thus making the native Windows application equivalent redundant. What else do you want?
Whilst we have be yakking the Espurino project has hit its goal!!
http://www.kickstarter.com/projects/48651611/espruino-javascript-for-things
There will be JavaScript on the Propeller II.
Streaming financial market data in real-time to charts and grids of ticker symbols. The data must be delivered in under a few hundred milliseconds from the exchange to the consumer, and we can't buffer data like you can with audio and video as that increases latency. I imagine something like Skype has similar performance challenges. HTML5 and Javascript just don't meet our performance requirements which are really strict.
Again, I don't care how good or bad a language is in the land of ideal forms. I care about the ability of it to perform in a specific environment. Javascript's normally used in a browser for DOM manipulation and parsing network responses in multiple browsers. It's exactly the use case where it has the lowest reliability.
Edit: also a compiler and lint like tools can be thought of as a defense in depth strategy. They don't eliminate other steps, but the sooner you find a problem the less expensive it is to fix.
It is perfectly possible to stream hundreds of data points to a browser over a websocket and update them at 10, 20 or more times per second. Whilst at the same time updating a scene displaying those points using webgl. When I look at what you can do with libraries like three.js or ivank I'm stunned at the rates they can work at. I would of guessed that updating numbers or charts at rates a human can keep up with was quite doable. Normally the network latencies and jitters are the limiting factor here.
I agree with you about the "ideal forms" of languages. At the end of the day the thing has to work in practice. We have been lucky, when I tell our customers they will need to use a browser that supports the features we use to get the best results they do not even flinch. Most of them have been off IE for a long time anyway it seems.
Still JavaScript has been moving out of the browser for a long time. node.js famously brings JS to the server where if flies really well. JS is in GUI application development in Qt as QML. And now JS is moving to the embedded world.
There must be something about the "ideal form" of JS that attracts people to do all this.
I'm all for compiler checks and linting and such. But when it's all done if you don't have enough testing in place to check that the thing works in all the situations in will meet in use then you are trusting in the gods that it will, and one of those gods is called "Murphy". The compiler cannot help you. Of course if you do have such testing in place things like type checking in the compiler become less of a concern.
Of course Java held out the promise of "write once run anywhere". A great idea that was obviously doomed from the start. It can only work if the language and all it's run time and environment is dictated by a single entity. Hence the Sun vs MS spat. And then you get Google coming along, see how well a normal Java app runs on Android.
So, yes, there is a motivation to get browsers to be capable of doing what native apps can. It seems to be the only way to get to that cross-platform nirvana.
I always thought the idea was nuts. I mean JS is not a real programming language and it's all going to be terrible slow. That is until I found out that JS is actually very sophisticated and Google V8 started a huge round of JS turbo charging.
I'm sure you or your competitors will come up with a browser based client soon.
BoneScript is a Node.js library specifically optimized for the Beagle family and featuring familiar Arduino function calls, exported to the browser. Get started exploring the BoneScript Library to discover the great simplicity that is made possible by utilizing Linux.
http://beagleboard.org/Support/BoneScript
Oddly BoneScript makes pins into objects so you have to write:
b.digitalWrite('USR0', b.HIGH);instead of:digitalWrite('USR0', HIGH);like the original Arduino calls.Espruino is more like the original. Probably because the code is a bit smaller and quicker.
I think that when it comes to the P II it would be better to have functions that work on many pins at once as we are used to with INA, OUTA, DIRA.
With a bit of tweaking the Cloud9 server running on your PC could made to download your code to the Prop.
I've looked at JS many times in the past, and it is interesting for some of the simple apps that can be made accessible via my browser by me.
The attention its gotten the last number of years with JIT's and performance increases are great and interesting to follow and see happen in my normal web browsing.
However, I see nothing in it that is worth expending the time, effort, brain cells, etc, if I am not going to use it as some sort of web application.
More directly, as a uC language, I'm not sure I've seen anything that JS can do that C or others can not.
It seems more verbose than C, for what gain I'm not sure...
I occasionally wonder if something truely unique like Python could be cross-compiled down to the Prop, but its just a daydream (so far), and ultimately while I think the RAD might be particularly useful in this field, I'm unsure as to how/why or if this would translate nuts & bolts down to a faster, more reliable, or more bug free uC application.
My beer money is not too be trifled with.
It's all about making "tinkering with gadgets" appeal to wider range of people in this case those who know JS. The WEB developers.
Realistically we cannot expect to be able to create applications for the Propeller of the type we are used to seeing on the forum pretty much every day. Because:
1) JavaScript's run time is big, even if the one under consideration here is about the smallest ever.
2) Execution will be slow compared to Spin or C. Especially since I imagine it's impossible to put all the optimization tricks of a V8 or SpiderMonky engine in such a small system. We are not going to see JS outperforming C++ as it does in some of my server processes running on the V8 engine.
You are right. JavaScript cannot do anything C cannot do. After all the JS interpreters are writen in C++, which is only C with extra syntax baggage, so ultimately C/C++ is doing everything. In general all programming languages are equivalent that way.
So why want to put JS on the Propeller or any other micro controller?
OK, I'll be honest. One of the biggest attractions for me personally is simply the fact that it's there. It's an itch to scratch. It needs to be done just for the kicks. Bit like those who have to create a Z80 interpreter for the Prop....
But there is a potential real purpose to this madness. There are a billion web developers out there. Increasingly JavaScript is being used on the server as well. (See node.js). Perhaps if those guys can pick up a micro-controller and have it flash a LED or beep or return a sensor reading using a language they already know without needing to learn a new language or IDE etc, then perhaps we attract more people to the world of micro-controllers and importantly the Prop itself.
Performance issues I don't worry about, one could see JS being the "glue" running on a cog that stiches an application together from other high speed real time code running on the other cogs. Like we do in Spin.
I'm curious why you say JS is more verbose than C. I've been racking my brain to think of an example where that is true. Do you have one?
I like Python. Despite it's use of white space as block delimiting. And despite the fact that it is way behind JS in performance.
I think there are major issues getting Python to run on a small micro-controller. For example Python allows me to do arithmetic on huge numbers, as in thousands of digits not just big floating point values. This kind of ability would have to be trimmed down a lot and then you don't really have Python anymore.
However, I believe the first incarnation of the Raspberry Pi idea did use an AVR micro-controller and Python. Your daydream may be closer than you think.
Far be it for me to trifle with a man's beer money. If JS is not going to do what you want to do that's fair enough reason to ignore it.
Luckily Gordon has attracted a lot of other guys beer money in a very short time. This idea seems to have hit a resonance with a lot of people already.
re:Interesting stuff there Bob.
I really like the Beagle bone Black.(BBB) I have one for Node.js, Java script and one for Android(Haven't tried it yet).
I have been using node.js or Raspberry Pi and for professional work on the ISEE IGEP board. It works a treat.
I love it that I can work in the same language from the field units to the servers to the clients browsers.
That's twice the original goal and nearly 1000 backers in two weeks.
Seems that despite all the naysayers there are a lot crazy people like me who would like to see JS on small cheap embedded devices.
JS is almost certainly coming to the Propeller world.
1300 lunatics really want JS on embedded systems and the Prop (II) should have it to.
I'm on the reminder list so I'll have one last time to check the budget for Javascript before it's all over.