[Oberon] RISC.img format

[Lars]

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)