I think there's a great opportunity for someone to release a simple, programmable Gameboy-esque device that runs Javascript or something similarly noob-friendly to give people (and kids) a less friction-filled path to learning programming. This might not be the device for that, but it's a really cool project nevertheless.
Javascript... what an odd choice. Definitely not my first choice for a language used to teach programming to beginners, nor to run on embedded systems.
ps: I'm well aware there are embedded systems for Javascript and it is being taught on codecademy to beginners, I'm just saying it seems weird to me.
The pros: It's RIGHT THERE. It's in your browser, complete with console and debugger. You don't need to download a compiler or interpreter or anything to play with it. You don't have to visit any particular site. All you need is Notepad or TextEdit.
It's about as close as you're going to come to this nowadays:
C64 BASIC was all there was for many people, otherwise computers were mostly not affordable and available to children. There just wasn't real choice, so we used what we had. If structured BASIC or better had been shipped that would have been the thing to use instead, without a doubt.
Today there's a choice. We can't pretend we are forced. Now there are many MUCH better things. And if we intentionally choose hardware which enforces the use of something bad to start with, when we could put all kinds of things on all kinds of hardware today - it isn't because we were forced but because we are stupid. People with experience use Javascript because they have to in order to program the browser (due to a completely artificial monopoly) and they have the ability to adapt to it. Maybe they even develop stockholm syndrome and forget all the ways it's broken and missing basic capabilities. But that doesn't mean it's a good choice among starting languages when we have a free choice.
This. When I was in middle school, I (along with many of my friends) used to program games in TI-Basic on our TI-83 calculators because it was right there and we always had our calculators at school. There were definitely better/simpler languages available, but nothing beats convenience and a low barrier to entry.
What's the problem to going to a particular site? There are loads of languages you can learn interactively online. Even if you were just learning JavaScript, you'd still have to visit specific sites for information.
Yeah, I don't get the unending Javascript love. I "waited" a long time to learn to program, mostly just cause it never "felt" right, and I never really had a need to learn it. I've pretty much come from nothing to where I am today in about 18 months.
How I'd want to learn programming:
If I were to learn programming through just messing about, I really wouldn't want to do it using Javascript. Javascript can have a very convoluted syntax, and that can be really off putting.
I'd much rather learn to program in a language like BASIC or, even better, subset of Python 3; a language that lacks many high level features, but not a language where I have to deal with the hard edges of the hardware (like you'd have to do in C).
Sorry. That's a deal-breaker. Even if I concede that 1-based is a style choice you can get used to (and I do not), you must interoperate with the land of C and that is all 0-based.
> Javascript... what an odd choice. Definitely not my first choice for a language used to teach programming to beginners, nor to run on embedded systems.
The problem is that you are looking through a lens of Javascript in 2014 where it has become a bloated pig of a language.
Javascript in 1996 when it was introduced ran on a system that was roughly 66MHz, 64MB of RAM, 10's of GB of disk, and 56Kbps of bandwidth. And, it ran as a subsystem inside the Netscape process, so it probably had access to less than 2MB of RAM. Microchip just released a PIC32 (MIPS R4K) with 200MHz, 512K RAM, and 2MB flash. That's a pretty good match in terms of capabilities.
Javascript, the language of 1996, is actually pretty decent and is a small language.
Let's look at the alternatives:
Scheme/Lisp fails for a variety of reasons but the biggest one is that a cons-cell is a terrible abstraction on modern hardware (see Clojure for a Lisp with good modern abstractions).
Lua is a 1-based language in a world of 0. Sorry Lua, but that's just not acceptable. Every time you cross the Lua-C boundary, bugs abound (well, they abound in Lua, too, but I'm being nice).
Forth is stack-based in a world of imperative, register-based abstractions.
So, what's left? C. Which takes almost 18 months to train a new junior programmer in until he's useful at embedded programming. It takes about 6 months to beat C pointer manipulations into his head, and then another 12 months to beat all of the coding conventions into his head so that he doesn't blow off his foot.
God, I hope Rust gets it right. Please. We really need a compiled systems-programming language that works in a world of concurrency.
Now, let's look at Javascript.
Failures:
lack of direct hardware accessors--every Javascript will have to grow some way to read/write pointers/memory in embedded. Yeah, that's a big one, but not that huge.
function scoping--Correctable with the "let" keyword--just don't teach "var".
inheritance--Better to have left it out that to have done the bodge that is the Javascript implementation of prototypal. Prototypal inheritance is fine, but the way Javascript implements it is terribly broken.
mutable system globals--sigh. Yeah, it's enabled beautiful things like installing workaround for broken Javscript interpreters, but it also means there is almost nothing you can count on.
So, if you sit and think a while, Javascript is actually pretty good for an embedded language. It's at the 80% point at least. It's probably closer to 90% (once you add a hardware accessors).
The real question to ask is: what should an ideal embedded language look like? Small (check--only Forth is smaller). Brace syntax (check). Vectors, Hash Tables, Garbage Collection (check). Concurrency (fail-but nobody else gets it right yet either). Interpretable or compilable (check). Widely known (oh, yeah).
Javascript fits the hole. Yeah, it's not what I would have expected, but if you look at it clearly, the evidence checks out.
> cons-cell is a terrible abstraction on
modern hardware
Could you expand on this?
Also, whether or not it's better to teach to kids than JavaScript, Squirrel is a more traditional curly-brace alternative to Lua for embedded development.
> > cons-cell is a terrible abstraction on modern hardware
> Could you expand on this?
Sure, that one is pretty easy. cons cells are effectively 2 pointers. Consequently, they are not guaranteed nor expected to be near one another in memory.
Now, that's not a big deal with respect to the first pointer. That contains the thing, so we always have to chase that down.
In a Lisp/Scheme cons-cell list, the second pointer needs to be referenced to get to the next cons cell. So, we have to chase a second pointer just to move to the next element.
Every time you chase a non-contiguous pointer like this, the processor may have to bring in a cache line and that's a big penalty.
Contrast this to say, an array/vector. To get to the next element you just add some small amount to the current index. It's likely already in the same cache line as the previous element.
Arrays/vectors have a big win over pointer-based lists in terms of locality of reference on a modern microprocessor.
There is a second problem with cons cells in that their abstraction in terms of the language also has problems:
What is so much better between Squirrel and Javascript? To my eye, they look pretty much the same.
And Javascript has an enormous ecosystem. While Squirrel has a very small niche of the not terribly large Lua ecosystem.
This isn't to knock Squirrel as a language, but I view this in the same light and Python vs. Ruby. The languages don't have enough better/different from one another for me to tell someone to switch if they already know one or the other.
"Espruino is a small computer that anyone can use to control things around them. Its JavaScript interpreter gives you instant feedback so that you can experiment and develop whatever your level of experience."
I've been trying to find a way to do it with LuaJIT. Putting something like LOAD81 (http://github.com/antirez/load81) on a business card would be awesome ..
Why not just switch to KiCAD rather than use eagle? I have found KiCAD is far superior at this point and is open source. They mostly have the ability to use eagle libraries in KiCAD now (although it is in alpha I think).
Maybe they could donate the $820 to support KiCAD?
EAGLE is the tool they know. All their files are already in EAGLE's format, and even if KiCAD can "mostly" do import, that's not quite a matter of being able to pick up your design and keep on going.
In the electronics world, tool lock-in is a very real, strong, and painful force.
I don't have pity for people who choose to lock themselves in to tools and then ask for $800 because of it. Oh well, their choice! It really isn't much work to switch to KiCAD.
