On Sun, February 14, 2016 1:28 pm, Chris Burrows wrote:

One significant feature that sets Project Oberon apart from most other open source projects I have seen is that the *design* (not just the *user reference*) is thoroughly documented - including many diagrams. You do not have to decipher source code or try to read the minds of the developers to find answers to questions like these.

I found blackbox oberon (component pascal) very hard to use compared to delphi, not because blackbox was an inferior tool but rather because it lacked examples. Delphi has millions of examples all over the internet. E. Dijkstra thought that programming by example was a terrible thing and that one should learn the fundamentals instead of programming by example. I disagree strongly and so does Wirth. Oberon may have terse, complete documentation, but without examples it's really hard to make any progress. A similar problem was found when I learned a bit of Allegro Common Lisp. It was very much like delphi GUI app creation (as is blackbox oberon component pascal) but the examples are severely lacking. The basic documentation is there, but examples virtually do not exist. I found oberon was basically a collection of libraries, without anyone actually implementing many shipped products, whereas Delphi has millions of shipped products, many open source. These are just my thoughts from learning oberon for the past few years, and I do not know oberon very well. Well I know a bit of GoLang which is actually a fork of oberon. but that's another story. Golang is full of examples and github code galore. Just because there is a lot of code doesn't mean it is all good code, i.e. java, but in order for oberon to succeed it needs more examples and real world websites discussing it, promoting it. This will likely not happen since the string problem means people don't need oberon for real work (since real work requires working with strings) but that's again another story. Another problem was of course the fact that blackbox could not ship a GUI application as a standalone exe, like delphi could. It was more like a smalltalk system where you had to download smalltalk environment. So people offer the compiler option to create stand alone exe's: however this is not an ideal solution since these compilers just produce console apps, not GUI apps that component pascal offered in it's environment. So it was basically a wild goose chase for me, finding the right oberon tools, as it was fragmented across several tools. At some point I just give up and go back to FPC, golang, plain C, sometimes even C++, php, ... due to the pressure of the "Real world" which dijkstra hated. These are just my experiences with Oberon and Component Pascal. I think the documentation is basic, and the actual documented "examples" are lacking. Examples form sometimes some of the most important parts of documentation. In order, for example, to "Get" a web page via HTTP and download the HTML content to my computer, I rarely look through hundreds of documentation pages. I find an example online by searching for "get web page content, golang" or something similar. When I tried to search for how to do GUI tasks with Component Pascal blackbox, I failed to find examples and howto's and information. It required hours of fiddling with component pascal to discover features I was looking for or ways to hook up gui widgets to other widgets. In delphi, all this was done fairly instantly since millions of internet examples existed to tell me what I needed to do. Also with Delphi you have Torry.net, full of third party tools, while component pascal just had a code repository mostly for non gui related algorithms. Actual component pascal GUI widgets weren't something easily found, as on Torry.net where you could instantly find millions of delphi GUI components that plugged right into the IDE. Not all of these are high quality, but many were close to high quality. Just my experience. Also another issue is when you discuss oberon, people do not know which oberon you are talking about as it is an overloaded term. Do I mean Gardens point, or blackbox, or oberon 07 or Oberon 2099 when it comes out, or oberon system itself. So it gets tedious having to be very specific as to which oberon one is talking about. This was discussed in Brian Kernighan's famous paper about standard pascal... the community becomes fragmented because there are so many variations of oberon and pascal, whereas something like GoLang only has one main version (it does have more than one compiler available, but they all support one major GoLang version). Variation fragments the community - it's as if Oberon keeps trying and trying to get it right, by constantly coming up with new trimmings and versions. I suppose it's similar with how PHP keeps coming out with a new version that ends up breaking old PHP3 code from back in the day, or how C keeps coming up with new C's (c++, objective C, and essentially PHP is a high level C too)