tanakian
which subset?
the older html/http versions are older versions, not a subset of the modern html/http. afaik modern html/http doesn't have subsets.
>using a popular browser like Chrome
Gemini is created so that anyone would be able to write a Gemini browser in a couple of days. Or server.
I don't want "popular HTML browser" because I won't be able to write something like it in whole life.
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.
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.
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.
But in Oberon everything worked in the same address space.
That's how Oberon Gadgets were working. Later the same idea was used in Blackbox Component Builder.
Or may be that's because there is a universal concept of beauty, as Feinman was guessing, but I doubt it.
>another C-like language
Oberon is also a system programming language.
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.
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.