I think requiring it provides consistency that is very valuable for beginners.
...strcat() is the obvious solution whereas sprintf() is more powerful but uses more memory. The standard Arduino implementation of sprintf() does not allow for the use of float variables although it can be added at the expense of more memory use. snprintf() is safer to use than sprintf()
If there is to be a new language I'd like it to focus on improving the cake.
However I can't help feeling that you are expecting a lot from a 2K Arduino.
As to frosting, I think the conceptual bridge between the arduino world and the C/C++ world is something to keep. Many recipes exist to solve problems in in the semicolon-bounded world and I'd want to be able to copy and paste them into any new world, or take my arduino work and learning onto an industry platform.
As to the cake part, the thing that we lack most are effective ways to deal with concurrency. This is holding back the use of multi-core hardware and leads step-by-step programs into problems of semaphores and deadlocks, especially now when we try to use interrupts to multitask.If there is to be a new language I'd like it to focus on improving the cake. Maybe with objects that communicate messages via queues, but do computation in the way that is already known and accepted. The standard frosting looks just fine.
If you didn't have s setup() function, where would the stuff that only needs to occur once happen?I didn't see the unsigned long type in there. Will that be coming to support the time elements?Will bit manipulation be supported?
everything is auto-saved.
I think if you must use auto-save it should have to a different file each time - with serially-numbered names. But that is very difficult with the Arduino IDE because of its requirement for the file name and directory name to match. I sometimes save a version with a name myProgram.ino.BK1 and the IDE just ignores it when it comes to compile time. (This is on a Linux PC).
But the files within the IDE itself are always saved,
Right now they are pinWrite, pinRead, PinMode, which are shorter to type and all start with 'pin', which sort of 'namespaces' them in a way.
That is the bit I don't like. Personally I only want it to save the changes when I say so. I am happy to take responsibility for my own failures. But I don't want my perfectly good working code automatically overwritten by some garbage that I typed and then thought better of. I do realize, of course, that the code needs to be saved before it can be compiled. Maybe I am misunderstanding when your program saves the code?
I rather like this style. It would be easy to have a few macros in regular Arduino code to make the same commands be converted to digitalWrite() etc.It is probably a typo - but you have an uppercase P for your PinMode - be consistent (I prefer to start with lowercase).
you can use Ctrl+Z to get the changes back,
That sounds very familiar.
Sometimes I get an idea for a substantial reorganization of a piece of code and rush in to make changes. After 30 minutes or so I have got completely confused. At that stage Ctrl+Z isn't really any help - partly because it is a sequential process and I can no longer remember all the changes I have made, never mind the order in which I made them. In that situation starting over is often easiest - so dump all the changes and go back to the original version.
Don't worry about a few days delay. Although we might lose patience after 3 months