-
It's easy to look at decisions in Espruino from the outside and pick holes in it. It's a reason the Performance page is a bit defensive
Yes I agree, I think constructive criticism is really important for improving and opens discussion. Bashing for the sake of bashing doesn't help anyone. Anytime I question something its with this aim of improving the product or my own understanding. Something I often fail to bring across in my wording.
Its really hard to not be defensive when you spend so much time making something so this is totally understandable. Especially when alot of comments have no positive intent and often lack context on why you made a certain decision (like with the hashmaps).
I would still implement assocs as hashmaps so they are future proofed for larger mem sizes. But I have no experience in creating compilers and I probably use assocs more as a dictionary than others might, coming from python and c#. You clearly have time constraints on this stuff as well and is a difference between perfect and good enough for moment.
charlie-
I think constructive criticism is really important for improving and opens discussion. ..... Anytime I question something its with this aim of improving the product or my own understanding.
And BTW my replies are not meant to discourage or silence you, it is just that it still looks like your technical suggestions are missing the context a bit.
There are some other javascript engines for embedded devices that target a bit higher hardware requirements that made different design decisions. Maybe thanks to that they are more future proof or feature complete regarding JS specs but they do not run so well on the hardware we have here.
Two interesting ones I've seen sometime ago
https://kalumajs.org/ based on JerryScript
https://www.moddable.com/ - discussion https://forums.raspberrypi.com/viewtopicÂ.php?t=304964
Did not actually try to do something with them as they target Raspberry Pico and/or ESP32/ESP8266 which are not low power platforms like nrf52.
fanoush
... there is also a circuitpython port for Bangle.js if you want to go that route, but as far as I know the framework needed for apps/etc isn't there yet - so you'll be writing pretty much everything from scratch.
Since we use fixed-size memory elements (to avoid delays from malloc/etc and fragmentation) hashmaps don't fit that well - not to mention keys usually being added to objects incrementally. I did have plans for a red/black tree (which would still work) but the JS interpreter was designed for 64kB RAM and under, and then you're looking at the most you could ever have in an object being 3000 items (because that would fill all memory), which you can actually iterate over pretty fast.
In reality most code is written with some level of tree-ness (even if that's only nested scopes) so there aren't a great deal of elements in each object and a tree or hashmap wouldn't provide a massive pay-off.
PRs to the interpreter are always welcome if you find a way to hugely improve things though ;)
It's easy to look at decisions in Espruino from the outside and pick holes in it. It's a reason the Performance page is a bit defensive - it's been routinely used for Espruino-bashing online, but at the end of the day Espruino does manage to provide a reasonably convincing watch experience on Bangle.js - it may not be how most people would do it.