they could approach the same math from the other side, by starting to write games. and gradually come to game math. that would be more interesting, and then it would become obvious why one may need some math while programming.
not only libc. what is very cool is that most of the parts of very rich fpc library has no libc dependency.
so necessary parts get linked statically to the resulting binaries, and those binaries do not require libc. most of the library goes with roots to kernel calls, bypassing libc.
once you start using threads or link to other c libraries (like gtk) then libc becomes a dependency.
https://cppcast.com/cpp-builder/ - this is the podcast where embarcadero devs tell about how they maintain number of patches to llvm's compiler to make it compatible with necessary non-standard features like closures.
this also tells us that c++ became so big and complicated that one company (embarcadero size company) is not able anymore to support own compiler, they need to maintain own patches.
This might be because we all are relatives, there was a creature which first had something like an eye, then an eye, and it's our common ancestor, so perception of the relative species is to some extent common.
Or may be that's because there is a universal concept of beauty, as Feinman was guessing, but I doubt it.
I guess, the code would not look as C-like to you, if it would use some threading or socket library, may be written in "oop" way.
It might create an impression of being close to C because it uses the same way of dealing with sockets as people do in C usually. If the code would use TThread and TSocket classes, like in Object Pascal, it might look different.
It requires less efforts to create wrappers, than to write libraries. Probably if there were more "speakers" of the language, then there would be more ready to use libraries for developers.
This also may explain why that code could be improved, as you have pointed out - it serves more as an example of how to write a wrapper, rather than example of how to, or not to, program in Oberon.
I also know that the code could be improved, I can add that for instance I do not like that the main server module imports SYSTEM module, which flags it as unportable and potentially dangerous. But never thought that it could appear at such a crowded space as HN and deferred the improvements. Also, I did not think the code deserves a lot of attention.
>What "good ideas" should I be looking at?
To me it is important that it's low level and system programming language which, if compared to C, is still is more safe and less error prone.
It is important to me that Oberon is modular. That types, variables, functions are "private", unless explicitly exported. Strong typing. Type checks across module boundaries. In Oberon systems I could point out dynamic module loading, tasks vs threads, active objects in the language, single address space operating system is controversial but interesting. These are good ideas I can mention without even thinking.
well, photos do not become "incredible artwork" or "art" just because means of expression change.
there are photos that are considered to be art, without applying such effects. and there are photos that are not considered to be an artwork.
latter will more likely become more tasteless and ugly with those filters applied, while former don't need such filters in order to be considered the art.