JavaScript? Listen to .Heater!
Seairth
Posts: 2,474
StackOverflow has published their latest developer survey. It's an interesting read (if you're a software person). One thing that sticks out is the prevalence of JavaScript and related technology. I realize that "what's popular" is somewhat of a moving target, but it looks like JavaScript is going to stay at the top for the foreseeable future (at least, on StackOverflow's survey).
https://stackoverflow.com/research/developer-survey-2016
https://stackoverflow.com/research/developer-survey-2016
Comments
Interesting that nobody does real-time/embedded systems programming. Or did I miss that as I scanned through?
Of course now that everything is connected to the net now a days (IoT) we are all "full stack developers" and using Javascript of course.
Chip seemed to be taken with the Javascript on the P2 idea. That would be great, JS for the ease of programming + a bunch of other COGs for all the usual real-time interfacing in PASM or C.
28% identified themselves as age 25-29 (5 year span).
But only 3% identified as age 50-59 (10 year span). (And this is where I fit in.)
And the median age is only 27. So I think this survey skews towards the young - who tend to use newer technologies.
I wonder what the results would be if they were broken down by age group.
Granted, Stack Overflow admitted it's not a perfect survey. And the recruiters I speak to all seem to want JavaScript experience.
Walter
I think one of the problems is that JavaScript started life as the scripting engine for the Netscape browser (actually first called LiveScript in the very early days). Maybe they had grand ideas even back then, but the mode of its introduction into the world has played a large part in stunting its growth as a general language.
That said, there's certainly nothing wrong with JavaScript, and even the various browser implementations are getting better all the time (despite such foolishness as Apple refusing to let Google use their V8 engine for Chrome on iOS). It's an in-demand skill worthy of learning.
It also says this
More respondents consider themselves Full-stack Developers than any other role. On average, Full-stack developers are comfortable coding with 5 to 6 major languages or frameworks (vs. 4 for everyone else).
Note that multiple language list, and given the dominance on 'Web Developers" it is no surprise Browser languages also top the language. There just are not many embedded developers.
You can get an idea of just how skewed this is, from the fact C or C++ do not even show in the first few pages.
The by-year trends show a gain by Python over C++, so for most, scripting seems tolerable.
That does indicate some scripted/byte code language for P2 would be well received.
I guess it comes down to what subsets-downwards the best, but holding back something like JS & Python would be the lazy type choices.
You really do not want 64b floats used everywhere.... other than a PC
Looking at the languages at the top of those lists, and checking for more-embedded Type support, it looks like C#, which would need a CLR base.
I find this too
https://en.wikipedia.org/wiki/.NET_Micro_Framework
"The .NET Micro Framework (NETMF) is an open-source .NET platform for resource-constrained devices with at least 256 KB of flash and 64 KB of RAM"
Which looks to be P2 territory ?
C# Types are here
https://msdn.microsoft.com/en-us/library/cs7y5x0x(v=vs.90).aspx
Seriously, if the P2 is up to it, I'd be very happy programming it in javascript.
-Phil
What does someone actually mean when they refer to a language as a 'scripting language'? It always seems to be used in a pejorative manner as if the language is incomplete or unable to be used for any useful programming beyond automating simple tasks or acting as glue to coordinate modules written in real languages.
Javascript (ECMA6) and Python and Perl are perfectly capable, fully featured languages that, at least in the case of Javascript and Python, are object oriented and can be compiled to run at near compiled language speeds, especially in the case of Javascript under V8. (Heater. please don't go off on the godawful use of white space to delimit code blocks because I can come back with the unneeded {} and ; - both are awkward and unfamiliar when crossing from language to language and cause as many errors and frustrations in either direction). Their ease of use and learning and interactive REPL sure make them easy to "script" in but they are more than just scripting languages.
So why are some languages considered 'scripting languages' and unworthy of serious consideration? Scripting does seem tolerable considering it runs some of the largest enterprises' day to day operations? Maybe some folks need to try 'scripting languages' or more specifically Python and Javascript and experience their expressiveness and full set of features and capabilities.
But what the Web community really needs is a completely fresh start. Might I suggest:
FORTH on Rails!
The power of FORTH and the opaque/magically works until it doesn't Rails are the language and framework to get the Web to the next level.
One of the best things I found was: "When I use it, it's a modern dynamic language, when you use it, it's merely a scripting language!"
Some people define "scripting language" by whether it's compiled to a binary executable or not. That does not help, some languages can be compiled or interpreted. There is even a interpreter for C and C++ https://root.cern.ch/cling
At a higher level the word "script" seems to come from the theater. In a play one has actors and the actors do and say what the script says they should. So in the unix world, for example, we have actors like "ls", "grep", "sed", "rm" and a thousand more. The script, say BASH, is what you write to get those actors to do what you want.
So, in away we could say that Javascript is the language you use to script the actions of the actors in the browser, DOM elements and so on. It's not what you use to create those actors.
The name "Javascript" is very unfortunate. It has nothing to do with Java and the "script" part is kind of meaningless.
* The meteoric rise of node.js. That has put Javascript everywhere. Especially in the cloud servers. The entire, huge, BBC site is built on JS. Not to mention Instagram and others.
* Microsoft is busy working to get node.js to work with their new open source JS engine. MS is taking this seriously.
* JS is used in GUI development in otherwise compiled desktop and other applications in Qt.
* JS is used in games.
* On a smaller scale there is the Espruino http://www.espruino.com/ and the Tessel https://tessel.io/
* Even Samsung is in on the JS act creating their own JS run time for tiny systems https://github.com/Samsung/jerryscript I agree. Having JS forever linked to the horrible browser API's tarnished it's image. Especially since those API's were different on every browser. On the other hand, ultimately that is what got JS "out there".
Netscape originally wanted to use JS, Livescript then, server side. That idea went down with Netscape and Java took that position.
Well what do you know, I'm a "full stack" developer now! The other day I created this, it's a serial port server:
On a tiny embedded systems out in the field data from an RS485 port is shunted to and from a server in the cloud over websockets, secured with HTTPS. That is Javascript and node.js.
On the "cloud" a node.js server shunts the data from the websockets to a good old fashioned TCP/IP server so that a good old fashioned Windows Application can access it form anywhere in the world.
The cloud server also delivers a web page "dashboard" that shows the state of the serial tunnel, data rates, errors etc and allows the user to control the tunnel connections.
Then of course is the code in the web page to show live graphs and so on.
That's "full stack", all the way from the embedded system to the cloud server to the browser to the end user application. All I'm missing is a database...
Hmmm...seems I have a lot to say here. Perhaps we should revive the "Official Javascript language war" thread
Yes, and a better range of types, more suited to non floating point microcontrollers.
Maybe some kludge like inferred types can be used, to avoid seriously slow floats-everywhere syndrome ?
C# has better types now, so that could be a better short term goal.
Wait for Python 4.0 ?
Python definitely is not suitable for MCUs... ;-)
--> http://micropython.org/
--> http://www.zerynth.com/
Floats everywhere syndrome? AAAAAahhhhhhh... Python2 vs Python3... I still live too much in Python2...
...does not look than automagically converting 2 to float... ...revives my optimism...
;-)
Micropython is a Python3 flavour... Lots of stuff for my acceleratingly growing (dark energy inside) to do list...
;-)
All this messing about with unsigned/signed bytes, words longs, double longs whatever is ridiculous, unnecessary, low level, and prone to error. Low level stuff that has nothing to do with the problem you are solving. If you want types do it properly with Ada where you can specify your own ranges for types that fit your intended use. Or do it in C++ where you can create your own types.
Python just gives you numbers. One neat thing it does is handle arbitrarily large integers seamlessly.
JS just gives you 64 bit floats which covers a lot of application areas. That means it handles 53 bit integers as well.
JS also gives you typed arrays. So if you want to work in low level bytes and words you can. This was dictated by the need to interface to opengl but has the interesting result of allowing languages like C to be compiled in JS with all the correct type semantics. Not to mention dealing with binary data like images and so on.
So in answer to jmg's statement "You really do not want 64b floats used everywhere", Why not? Makes life much easier. Gives a huge integer range when you need integers. Not restricted to a PC now a days either. Little one dollar controllers can handle this stuff well enough for a huge rage of applications.
Given the context of the survey, I'm not sure why that is, but here goes. When most people say (not you, but most) they "program in JavaScript" they really mean they write Web pages. The prevalence of JavaScript comes from the prevalence of it in Web pages. The bulk of that use is in manipulating the DOM. That's a separate skill set, and some would say more important than simple mastery of the language. Getting things to work and look right in all the various browsers is a tall order, and is far from simple; I'd argue it's more challenging that simply "knowing JavaScript. "
I think you imagine a slight when there is none. I mean no disrespect to the language. But I think it's important to differentiate between base technology and its end use.
It is precisely the tight binding with the world's most commonly used API that keeps JS associated with it, and why even after two decades, JS still struggles to be considered a "grown up" language on par with Perl or C -- both of which began as general-purpose languages, rather than a script helper for a Web browser. Again, this is not a slight, nor is it my own feeling, just an observation of reality. Many people may thumb their nose at JavaScript, but the Web wouldn't be the same without it.
Also add Kinoma (owned by Marvell) to the list. The element isn't for sale quite yet, but the create has been around for a while. I think that it was recently updated. http://kinoma.com/buy/ and https://github.com/Kinoma/kinomajs
Now the Tessel is a much bigger device running JS as node.js which requires a Linux kernel underneath and apparently a separate I/O processor. Another mess.
Perhaps it would have been better to pitch the original Tessel as a Lua machine. But nobody has ever heard of Lua so that might have been seen as a non-starter.
Meanwhile the Esprunio, launched about the same time as the Tessel has it's own JS engine written my Gordon Williams. It launched on the little STM32 controllers and now runs on Nordic Semiconductor WIFI devices and MIPS and whatever else.
Then came the ESP whatever. With Lua. Everyone loves it. Lua is great.
Also meanwhile, the Electric Imp was originally build with Lua. They had to change to some other language at the last minute before launch as they realized their controller did not have the memory space Lua demanded.
Never heard of the kimona. Seems to be a node.js machine and is in a different ball park to Espruino, ESP or Electric Imp.
Good examples showing the problem, and maybe they can do the hidden types I mentioned.
Python 4.0 perhaps ?
Umm, lets try those embedded fundamentals of Speed and Size ?
I'd call those a pretty good 'why not'
- but yes, some care less about Speed and Size.
A bold claim, any links to what that 'well enough' escape clause means, or any $1 chips that have 64b FPU ?
If you relax the type to 32bit (which is no longer true Python) then you do get into the 'few dollars' MCUs with hardware FPUs - but nothing at $1
Some links of prices and Eval Boards
http://direct.nuvoton.com/en/nuc505-series/
or
http://direct.nuvoton.com/en/nuc472vi8ae
http://direct.nuvoton.com/en/m4tkvg6ae
Meanwhile, Languages with those types you are so eager to discard, mean I can run (right now) code that give 32b Real, 32b Int, and 8 & 16b libraries, on this part - a mere 28c/1k
http://direct.nuvoton.com/en/n79e715as16
For fun, we can do a x8 comparison
8 of those comes to $2.28/1k, and has 8 cores and 128k Flash, 8 Uarts, 8 SPI, 8 i2c ....
I think that Heater covered this pretty well. Here's the talk - it wasn't as obvious to find as I remembered:
https://opbeat.com/events/web-rebels-2016/#the-eternal-struggle-node-js-in-embedded-devices
Electric Imp uses Squirrel for both the device and agent code, so they are a bit different than everyone else as far as I can tell. The Particle (formerly Spark) crew seems to be targeting Arduino developers.
Edited to add:
Here's a link which discusses the Imp's switch to squirrel from Lua:
http://www.theamphour.com/202-an-interview-with-brandon-harris-impish-internet-iamatology
I see that confusion again. Javascript is a language. It's not the browser DOM API. Here the Tessel guy keeps talking about how tricky it is to put node.js on small devices. Node is not Javascript. By analogy the Arduino is programmed in C++, it does not drag libstdc++ with it.
Also it cannot be that JS is hard to imitate. Right from the beginning Microsoft created a JS clone in very short time that was true to the original. Gordon Williams and others have written JS interpreters by themselves!
Yes it might be tricky getting node and it's NPM infrastructure running on tiny controllers, well, don't do that. Do like Gordon: https://www.kickstarter.com/projects/gfw/puckjs-the-ground-breaking-bluetooth-beacon. Low power, tiny very cheap controller, blutooth etc.
Apparently, it's seeing that as
Yes, Nicely gives Hidden Type info, shows promise.
Can this infer a boolean type too ? (eg named pins as booleans can be useful)
?
Err, you already knew they were both numbers, so Javascript goes into the 'needs to do better' report card basket here.
Lua is much more interesting to me than Javascript, because it really was designed from the ground up as an embedded scripting language; it's intended to sit on a C platform and call C functions for all the stuff the token-interpreted Lua isn't suitable for. The Lua interpreter is tiny despite a weirdly capable list engine which is used for everything even under the hood. And if you need performance, you can easily select an integer-only build. Don't fool yourself, even with coprocessors integer math is significantly faster than float, even on top of the overhead of a byte code interpreter. And when you don't have a coprocessor, integer is a lot faster.
Javascript, by contrast, is a hot mess even if you separate it from browser issues. Is there anything stupider than not knowing whether the result of 3+3 will be "33" or 6? If you're going to conflate all the data types maybe you could at least not overload the + operator for string concatenation? (Lua does not make this mistake; the string concatenation operator is two periods, "hello".."world".)
In the following example Lua's behaviour is like AWK:
$ lua5.1 Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio > =0 0 > ="0" 0 > =1+"2" 3 > a={} > a[1]="boo" > a["1"]="ya!" > =a table: 0x1d8ddd0 > =a[1] boo > =a["1"] ya! > _Strings and numbers are exchangeable somehow but not perfectly the same.