Kaluma squeezes JavaScript onto the Raspberry Pi Pico

Although JavaScript is responsible for some bloated Electron apps, apparently you can still usefully run it in 264kB of RAM. The Kaluma project has managed to embed a working JavaScript interpreter into the Raspberry Pi Pico, and other devices using the same CPU. The Pi Pico ships with 264kB of RAM and just 2MB of flash …

[Missing Semicolon]

Hmm.

"JavaScript is an extraordinarily good language." - from the linked article.

It's certainly powerful, but powerful in the way a sack full of sharp powertools with the safety guards taken off is powerful. You can do a lot of things, but you are going to lose a finger or two in the process.

Utterly dynamic languages are great for geniuses who can hold the entire context of a codebase in their heads at once. Such demi-gods have no use for typing, or static inspection, or sane, predictable scope rules. Remember that the default scope for variables is global. Don't forget them 'var' declarators!

For the rest of us, anything really large is going to turn in to an unmaintainable ball of mud way too fast, and exhibit unexpected bugs unless you can achieve 100% coverage auto-test cases.

[Liam Proven]

Re: Hmm.

[Author here]

> anything really large is going to turn in to an unmaintainable ball of mud

Really.

In a quarter of a meg of RAM and two megs of flash. Do you think any school kid, or even the most demented adult developer, is going to make "anything really large" in that little space?

There are some big Javascript apps out there now, but you will not be running them on a Pi Pico.

[klh]

Re: Hmm.

I doubt the original comment here was about JS on Pi Pico, but the praise of JS in general.

Looking at it this way, there wasn't millions of dollars worth of investment to make the language fast, it was to make specific implementations fast. And this implementation doesn't benefit from any of that.

After working with it for over 20 years all I can say to someone who thinks it's good is they haven't used it enough yet, or haven't seen a good language.

[doublelayer]

Re: Hmm.

From your description, I expect that some of them will try. My guess is that they'll get one of the boards which take an RP2040 and more flash chips so they have some more space to put files and then start experimenting with how much they can import. I believe this from a simple thing: your article says they've gotten Node and NPM on it, and someone will try to use it. You can hardly write anything in NPM without pulling in a useful library which provides some function you don't want to write, does it well, and comes with thirty seven dependencies that nobody is clear what they're for and why they're there. So yes, I do expect that people will try to run that on that system and that they'll either run out of RAM or end up choking it by repeatedly loading and unloading parts of an unnecessarily large dependency tree.

You can write something small in JS, and some users will. I just don't imagine that it will stay that way for everyone, just the people who make a functional result when they're done.

[Jason Bloomberg]

Re: Hmm.

Utterly dynamic languages are great for geniuses who can hold the entire context of a codebase in their heads at once.

And people who only write short and simple code, and that's what many using the Pico, Pico W and other RP2040 boards will be doing. It's a moderately powerful device, more than a micro but not a PC, perfect for tinkerers and beginners.

Kaluma isn't that new as I have an installation for the Pico on my PC dated 2021. I am sure it has been improved, and I don't mind it getting promotion.

As it was some years ago when I tried it I can't say much more than it seemed to work when I tested it back then.

I went in a different direction but if people want to use JavaScript then good luck to them. Each to their own. The more makers the better.

[Caver_Dave]

Size

Wow, the standard must have changed somewhat.

At the end of last century I was a programmer for an Internet set-top-box manufacturer.

25Mhz Intel processor, 64M of RAM (half of which was the screen memory and couldn't be accessed by the processor for half the time while updating the screen). It had a fully compatible browser including a JavaScript interpreter (which I wrote) and an area for cookies, passwords, history, etc.

At least this is a story against the bloatware that is more common place.

[Liam Proven]

Re: Size

[Author here]

> 64M of RAM

You _did_ notice that the Pi Pico has, as I said, 264 *kilobytes* of RAM, not megabytes, right?

The last new computer I can think of offhand with so little RAM was the Amstrad PCW 8256 in 1985.

The Pi Pico has 3% more.

That's very nearly FORTY YEARS AGO, and good luck running Javascript on a PCW.

[Elongated Muskrat]

Re: Size

good luck running Javascript on a PCW

Sweet $deity no, don't give people ideas. It's bad enough that they've dirtied the Pico.

[David 132]

Re: Size

“And for my next trick… Systemd on a ZX Spectrum!”

[heyrick]

Re: Size

PCW clock speed - 4MHz

Pico clock speed - 125MHz (31× faster)

Doesn't mean it's not doable, but given that it would be in the same sort of category as watching a snail's lonely trek across a windowsill, clearly one would do it for the sake of doing it and not because it's in any way useful.

[Anonymous Coward]

Re: Size

Since when do MHz alone define computational ability?

[lostinspace]

Using Javascript as a beginner language is fine for a while. All the curly brace languages are basically the same at a superficial level. The problem with Javascript is it's inheritance model is like no other common language. Most widely used languages have a concept of a class and an instance of that class. Javascript has a crazy prototype model, which is far more complex and hard to understand.

Python is a far better choice for a beginner.

[Anonymous Coward]

You're correct of course, but if you use strict mode, always use "let" instead of "var", if you use class { ... } and private member variables/functions, it looks a lot like Java. You don't have to indulge in the worst aspects of the language.There's still lots wrong - I think promises were botched, personally, the component library model (or models) are ridiculous, especially as ES6 modules still don't work brilliantly on the web. But I digress.

Re. python, any language that attaches semantics to something you can't see has an uphill battle with me, but I know it's popular so each to their own.

[John Sager]

Python semantics

We all do indentation anyway for readability so losing curly brackets doesn't seem too much of an imposition.

As for the RP2040, it's a nice device to play with, and I've just built a nice little app (in C though) that listens for the RF signal from the doorbell button so I can get a 'bing-bong' in my headphones when someone rings the doorbell.

The pico-sdk does put quite a few functions into RAM though for speed, as flash is over a QSPI interface so cache misses will be slow, so that does take away from available heap space.

[Dan 55]

"JavaScript also enjoys a wealth of support, documentation"

Usually the more documentation you have the better, but that's not true in JavaScript's case.

[Johannesburgel12]

> The other thing is, it's had billions of dollars of investment to make it very, very, very fast and very efficient, and it runs everywhere.

Billions of dollars have been invested to make specific runtimes fast. JerryScript is not one of them. It's a pure interpreter without any JIT or anything, so this is among the slowest ways to execute JavaScript at all. And I'm not even talking about design decisions that are particularly stupid on microcontrollers, like the lack of integer datatypes.

[Liam Proven]

[Author here]

> It's a pure interpreter without any JIT or anything

Do you think they could fit a JIT into 264kB of RAM?

I can't think of many modern OSes that would fit into a quarter of a megabyte.

Even RISC OS Pico, the very cut-down RISC OS, was meant for a full-size RasPi.

https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20RaspberryPi:%20RISC%20OS%20Pico%20RC5

However, note how fast BBC BASIC V was compared to Python:

https://weblambdazero.blogspot.com/2015/11/modern-micro-with-risc-os-pico.html

A "pure interpreter" does not necessarily mean slow.

[doublelayer]

"Do you think they could fit a JIT into 264kB of RAM?"

No, but that wasn't their point. They weren't trying to say that it could have been done better but wasn't. They were saying that, even though some runtimes have been made super fast by spending a lot of money, it won't do users of this one any good because the result of that spending is not available to them.

By the way, while a JIT and then an interpreter for the remainder probably can't be usefully fit into that memory, you could precompile things to a lighter version, which would probably help over a straight source interpreter.

[Will Godfrey]

A quote from 'elsewhere'

One is amazed; not that it has been done, but that anyone would want to do it!

[ovation1357]

Why, $deity, why?!?!

I have terrible difficultly understanding how JavaScript became the defacto standard in web browsers - it's a case of the lowest common denominator IMO.

I have immense difficulty understanding why anybody would want to take the language and adapt it to run server side.

So this just blows my mind.

I suppose it's a bit like Foone (presumably still going on Mastodon since quitting Twitter?) getting Doom to run on a electric toothbrush... Very clever, somewhat entertaining but ultimately not of any practical use.

[Dan 55]

Re: Why, $deity, why?!?!

I guess the practical use is providing work for security researchers. As the website says "A JavaScript engine for Internet of Things". I doubt you could find two worse things in modern-day IT to put together.

[doublelayer]

Re: Why, $deity, why?!?!

"I have terrible difficultly understanding how JavaScript became the defacto standard in web browsers - it's a case of the lowest common denominator IMO."

Because it started small. HTML is a pretty weak language for the smallest of active tasks, and people doing web design in the 1990s didn't want every change to a page to require a round trip to a server over a slow connection. The first uses of JavaScript were to do relatively simple tasks to a page's content, and at that level, you don't need very much. You don't need execution speed or a lot of types or a coherent dependency system when most functions will be at most twenty lines and involve showing or hiding some blocks or putting dynamic text into them. Any language that includes all that stuff would probably get in the way, because you can easily write HTML in any text editor, so the last thing you wanted when writing a basic client-side script was to need a massive compiler and a big set of header files you'd have to have stored somewhere. Then it advanced slowly from there, with people using slightly more complex blocks.

It also won because the alternatives at the time and later were horrible. Most alternatives required a large blob to execute at all, a blob which frequently got updated. Sure, if you had the choice of writing a moderately complex client script in Java or JavaScript, you might prefer Java. However, if the question was helping users install the right version of Java so your thing could execute or forcing yourself to write two hundred lines of JS, you wrote the JS. A language like JS, I.E. without external dependencies, without a lot of base code that had to be incorporated, and without significant version pinning problems, probably would have done better. The other options did not check those boxes, so JS was adopted.

[abend0c4]

Re: Why, $deity, why?!?!

I have terrible difficultly understanding how JavaScript became the defacto standard

I think, like many things Internet, it was largely an accident.

The tale seems to have blurred over time, but I think it went something along these lines. Netscape was looking at a scripting language. Brendan Eich was known to be a fan of Scheme (and Self), but Netscape wanted to partner with Sun as a bulwark against Microsoft's tentative Internet interest. Sun was keen to promote Java, but it wasn't at that point feasible (either because of the limitations of PCs at the time, or the short development window, or both). The compromise was that Netscape's scripting language would adopt a superficial similarity with Java syntax and borrow the Java name. Eich was able to knock something up in a fortnight.

Once Java was also incorporated into Netscape, it and JavaScript lived rather unhappily side by side for some time.

JavaScript would probably have died a death if it weren't (ironically) for Microsoft - who also offered VBscript in Internet Explorer - to come up with AJAX, initially as an ActiveX object. This, for the first time, offered scriptable dynamic updates to the document. Its popularity swiftly resulted in equivalent mechanisms in other browsers and a significantly wider use of JavaScript to access its functionality.

JavaScript persists even now because: (a) it is reasonably functionally complete (and has been from the outset), having borrowed just sufficient from languages such as Scheme and Self to make it widely applicable whilst having such a short initial implementation period; (b) it's sufficiently ubiquitous that it's been worth investing significant resources in ameliorating is various issues.

I think the concept is quite clever and was well-tailored to the requirement of the moment. As a programming mainstay, I am less convinced of its merits. There is a school of thought that it was actually a genius concept and that people who criticise JavaScript have simply failed to understand it - but in my view that's a retrospective construction mostly led by the kind of people who argue at length about the merits of composition versus derivation and who don't really want to accept that things that are widely used may just be the product of a short-term lash-up.

[Jason Bloomberg]

Re: Why, $deity, why?!?!

I have immense difficulty understanding why anybody would want to take the language and adapt it to run server side.

If you ignore all the stuff which lets it interact with web pages in a browser it's really Just Another Programming Language (TM), one which looks a bit like C but simpler to use because of dynamic typing, not hard to get to grips with and use at all.

And that's what some people wanting to program microcontrollers are looking for.

[Dan 55]

Re: Why, $deity, why?!?!

Dynamic typing is probably the last thing you need on a microcontroller. And of course it's JavaScript where 2 + 5 can be 25 and 2 - 5 is -3.