[Oberon] Train VS all terrain truck

[Lars]

On Tue, February 9, 2016 8:56 am, Alexey Veselovsky wrote:
> Hi.
>
>
>
>> Coming to your niche question: In my point of view, let Oberon run on
>> RISC5,
>> ARM or Intel. Whatever might fit your taste.
>> The benefit of Oberon (not only the language but also the whole Oberon
>> system) is that it is so small. So, programming an embedded device
>> (=small
>> memory space and very low power, not too fast CPU) in Oberon could be
>> beneficial. You don't have to develop in assembly language but can use
>> a rather high level, strictly typed OOP-ready language. The embedded
>> device runs your application and ships directly with its very compact
>> Oberon
>> runtime system running natively on the embedded device without a
>> stripped down Linux or so.
>
>
> Oberon system (but not RISC5) is very small and neat self-development
> environment. And it is a very good choice for education purposes.
>
> But if you want to develop embedded system for production (and you do not
>  need any development environment in a finished product) then Oberon
> system may be is not a best choice. Just because there are several other
> languages that have less runtime overhead and has more low and high level
> abilities (Ada, C++, Modula (2,3), Rust).
>
>
> Host and target systems can be very different.
>
>
> I wrote embedded software in C++ (actually C++11 - with lambda functions,
>  templates and so on) for hardware with only 512 *bytes* of RAM.
>
> Thanks,
> Alexey.

This is why I don't understand why people say C is good for embedded
programming.  If you can use C++, with only 512 bytes of ram, why are
people still saying regular plain C is better for embedded programming?

Supposedly with plain C you can optimize better as the algorithms match
the hardware more closely. But if you were able to do C++ with only 512
bytes of ram, it makes me think that... C++ is still low level enough ,
almost as much as plain C.

My reason for not choosing C++ would be because plain C is simpler, but I
hate wasting time allocating string memory (pointers to chars) in plain C.
Did your embedded software use fixed length short strings, and did you use
C++ strings, or plain C strings? I get the impression that with embedded
programming, strings are not as much of an issue that people worry about. 
Writing desktop software (not embedded) with plain C is mostly a pain
because of strings, and not for any other reason. GoLang is essentially C
with strings, and solves that problem.

So with your embedded C++ software, did you use some plain C code, or all
C++ code? Did you call in a strings library of some sort, use pointers to
chars, or the software didn't even deal with strings much?