Robert Griesamer *is* Niklaus Wirth? On Tue, 2019-02-05 at 09:19 -0800, Michael Jones wrote: > Go learns from Oberon via Go and Oberon insider Robert Griesemer, > whose > Wirth-number is zero. > > On Tue, Feb 5, 2019 at 3:47 AM Gerard <gvdsch...@gmail.com> wrote: > > > > > Hello everyone. There has been one issue in Go that has never > > gotten out > > of my head, so it went on and on. The problem is modules. > > > > In the beginning there was Oberon. Let's just face it. Oberon was a > > brilliant designed piece of engineering. Oberon did have some > > marvelous > > features that just don't exist today, such as GC for everything, > > including > > closing files (anyone ever seen that), and their memory system was > > also GC, > > including modules entirely. So they made a counter for each module > > that was > > being used. You add one, the counter increase. You lose one, the > > counter > > went down and when that counter went zero that module got erased > > from > > memory. Pretty clever. > > > > Oberon also got very small compiled modules. They were compiled and > > the > > API was being check-summed. And they didn't got generics ;-) There > > was no > > need for that since the basic types were so simple, a lot simpler > > than in > > Go. > > > > Why were they using this compiled API file? That was only used for > > identification. Everything that has public code goes into the > > compiled > > header file. There is AFAIK no no linking. The only thing that is > > being > > used are the compiled modules and compiled header files. > > > > Now I have explained everything that I know that I know about > > modules. > > What are the areas of interest? The only answer that I can find out > > is OS > > design. But for that the benefits are huge, but only if you have > > the guts > > to really gutter the whole thing down. > > > > What compiles: > > That is pretty easy. Everything that is public will be part of a > > header > > file, the rest stays inside the module itself. > > > > The benefits: > > > > 1. This maps a lot better for OS development. > > 2. No linking involved. > > 3. updates could have been "on the fly", with just a couple of > > LOC you > > can download and compile an entire module, as long as the API > > hasn't > > changed. > > 4. Fit well with systems such as apt-get, GNU GUIX, but also go > > get. > > > > > > The downsides: > > > > 1. This could confuse people who tend to use it. How can you use > > it? > > That is why I think that this could probably only work for OS > > design. You > > just don't want to download a half baked module. > > 2. It could have been used proprietary. Personally I have a lot > > against proprietary code. > > > > > > Questions: > > > > > > > > Links: > > > > 1. http://members.home.nl/jmr272/Oberon/ModToOberon.pdf > > 2. https://en.wikipedia.org/wiki/Oberon_(programming_language) > > 3. http://www.ethoberon.ethz.ch/WirthPubl/ProgInOberon.pdf > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups > > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, > > send an > > email to golang-nuts+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* >
-- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
