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.
