Just discovering Nimrod - most interesting.
Also recently ordered a Raspberry Pi so as to plunge into that and was kind of thinking would be nice to have a new language to try out on the Pi beside just going with the interpretive Python. Python is fine and all but would like to have something that does compile time type checking with type inference niceness, etc., plus other modernizations. Don't really want to go back to C or C++. Liked Go but the size of the produced executables was kind of a no-go (or turn off) when thinking about a target of just 512 MB (and less for other embedded devices).
Apple II and VisiCalc rode to prominence with each other. Then the Mac and the PostScript laser printer ala desktop publishing.
Perhaps Nimrod community could look to the Raspberry Pi phenomena as a marketing opportunity to rise to prominence on.
Have liked that there are Nimrod bindings to Python, given how Raspberry Pi kind of positions Python as the flagship language - and of course the C bindings generator.
All-in-all, on first blush examination the two (Nimrod and Pi) look like a good fit for one another. Really the whole embedded programming arena could stand to have fresh new language other than just carrying on with C or C++. Given the popularity of robotics clubs and such in high school and colleges, there's yet more opportunity to market a good, fresh-thinking language to a new generation audience.
There is the matter of the GC and the issue of deterministic behavior required in real-time embedded systems. Will need to learn more about memory management in Nimrod via its thread local heaps vis a vis the soft real-time scenario. I do recall that Sun Microsystems had R&D projects where Java for embedded programming was going with a GC using thread private heaps in order to meet memory management determinism constraints. And there's still the pointer-based memory objects in the unsafe shared heap as an out.
Should be fun to explore the potential here.
The R Pi is a powerful beast compared to typical embedded systems, even compared to embedded Linux devices with 64Mb. Since these guys don't have to drive any eye candy they are quite adequate - the one I'm dealing with here even runs Python! But rather slowly of course.
Now, systems with a few megs (if that) of RAM - that takes special engineering since GC is an inefficient use of memory.
I can estimate the memory requirements as following ([hint] dependent on MCU architecture):
32 bit - Static total estimated: 24 kB, dynamic at runtime: 8 kB = 32 kB 16 bit - Static total estimated: 12 kB, dynamic at runtime: 6 kB = 18 kB
A minimal environment (without JIT compilation) will use less than 8 kB
Any additional questions ?
That is definitely in the true embedded space! Since C is so dominant in that space (with a few determined people using C++) this could be a very attractive niche for Nimrod.
But what would be the limitations? Many useful things (like strings and seqs) need dynamic allocation? What would an embedded Nimrod feel like?
But what would be the limitations? Many useful things (like strings and seqs) need dynamic allocation? What would an embedded Nimrod feel like?
Please note that Mat2 is talking about a Nimrod subset that is small enough that the compiler itself can run on the embedded system. I'm talking about cross compilation to the target system: Nimrod is not in a bad shape for embedded programming. Strings and seqs are not required to use a GC thanks to their copying semantics. A STL-like implementation is entirely feasible too. The only language features that really require a GC are escaping closures (currently the compiler treats all closures as escaping) and ref pointers. However very often a template can be used instead of a closure as a workaround.
Also that integer literals have their own types helps for embedded; byte + 12 still produces the byte add instruction. In C the operation would be widened it to 16 bits at least. And when you do cross compilation you can still use the full language at compile time with all its meta programming goodness.