Post by Andreas BaumgartnerI sometimes look into Plugin Oberon for Windows maintained by Emil
Zeller which is installed in one of my laptops. I would like to do more
with it, but there is not much motivation and not much sense to do
things alone and with sparse documentation at hand. Moving to Zonnon
does not seem being a alternative neither. I would rather move to Free
Pascal/Lazarus but i could be more productive with C.
Depends what you mean by more productive with C. The problem with C is there are no strings (reference counted) so you end up writing lots of verbose code just to allocate memory for pchars (pointers to chars). So I don't see how you can possibly be more productive in C since you have to continually worry about allocating memory for strings. It seems that 90 percent of programming today involves some sort of string manipulation, and any language which doesn't have garbage collected strings (or reference counted) isn't going to be productive. The only time strings aren't important, is when you are programming embedded software it seems, where you sometimes only have to deal with strings once in a while on an LCD screen or similar.
I think one of the problems with oberon is it still hasn't gotten strings right. I'm still researching the language (I have used component pascal) but from what I can tell, people end up with kludges in oberon to deal with strings, instead of delphi/fpc reference counted string where you just forget about managing your strings since it is automatically reference counted for you. To deal with pointers to array of chars, or to have to specify fixed length strings of 1024, or 2048 characters (how can you guess and be psychic and know what string size you need up front in all cases?) is a big kludge...
This is discussed here:
https://lists.inf.ethz.ch/pipermail/oberon/2010/005744.html
"Actually, there are several ways how strings are represented."
Hint: bad design warning! more than one way to do things, a million different representations of strings, rather than just one reference counted string like in delphi or fpc.. Everyone uses php, python, delphi, fpc, and ruby these days because it has something called a string! Not a pointer to array of char - let's not go back to living in caves!
https://lists.inf.ethz.ch/pipermail/oberon/2010/005743.html
"If there is no builtin way to handle strings practically, how can one build a custom tool (a type) for this?"
Oberon is difficult to use, in practice!
https://lists.inf.ethz.ch/pipermail/oberon/2010/005751.html
"In fact, the issue is that even if I can build a string type to manipulate strings, it is unusable in practice since no builtin function/procedure can use it"
...
"the impression of beeing lost inside a vicious circle."
"I'm aware I could use POINTER TO ARRAY OF CHAR to pass strings around (*), but then I need to explicitly (de)reference all strings."
Doh! what is this, low level C programming? haven't we learned our lesson .... we are not living in caves any more...
A similar problem existed in standard pascal: strings were 255 chars, and all sorts of work arounds had to be done to make the language usable in the 1990's when strings went beyond 255 characters... So now oberon let's us go beyond 255 characters as array of char, but it isn't really improving the situation much! Delphi got it right, with reference counted string that everyone loves... but Wirth never seemed to really get strings right, I'm afraid to say. Also I find it hard to contact him about this: he doesn't seem to chime in on mailing lists, he's sort fading away into obscurity unfortunately... Whereas in a development community like Ruby or PHP you'll see major developers of the language chiming in on mailing lists and obtaining feedback about their language...
Don't get me wrong, I'm not a fan of php or ruby, but I think Wirth has a different development system where he just writes a book about his language and expects you to follow what the book says - but what about user feedback and developer feedback - what if there are serious design problems in oberon that need to be addressed? It can't be solved by buying a book on oberon that's closed and finished..
Sometimes when I criticize oberon's string problems, I get Oberon patriots (fanboys) who defend the array of char with pride! They say you don't need strings, because arrays of chars work just fine.. This is ignoring the progress that we've made in high level languages: No one would use Delphi if it didn't have a proper reference counted string - turbo pascal started out with 255 character strings, and people hated that - many people left it and used C language instead... Oberon faces a similar problem: strings are serious issue. maybe not quite as bad as 255 pascal limit strings, but almost as bad!
Python is successful for a reason - it has strings! like ruby, php, delphi, and other languages. A lot of work people do involves strings these days! It's as if Niklaus Wirth really only cares about embedded programming maybe? where strings aren't as much of an issue? Component Pascal tries to address the string problem with Dollar sign hacks, AFAIK (is component pascal the next Perl?). It's been a while since I used component pascal, but even it wasn't enjoyable with regards to using strings, even with the added extensions/hacks... Compared to FPC and delphi, component pascal just an academic toy fading away into obscurity like standard pascal...
Understand I'm not completely bashing Oberon entirely here, I'm purely addressing the string problem. Other parts of the language are elegant.
So what you have here, is people are moving to Go language, nimrod, ruby, pyhon, fpc, delphi, and oberon is being left behind. Some would rather use C or java... Java has strings! C++ has strings that are a hack, but it has them. Oberon? has a difficult to use array of char that isn't a useful abstraction... maybe even less useful than standard pascal in some respects. In oberon, it's a vicious circle when using strings (quoted from an oberon user himself!)
So here's hoping Wirth is listening. You can't just develop your language, write a book, and disappear without interacting with developers. Also where is the error reporting system? (bug report: but Dijkstra would prefer the term error). FPC and delphi have something called quality central or bug reporting systems...
Regards.
Z505 Software
Skeptic and critic of programming languages
p.s..... there's more below >>
Dijkstra would be using Haskell? Not oberon?
http://chrisdone.com/posts/dijkstra-haskell-java
Haskell uses == (double equals) for equality.. like C... Wirth don't like that..
Wirth has spoken about functional languages in:
http://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas_origFig.pdf
It seems Dijkstra in his later years, embraced functional programming, while Wirth is still skeptical of it... (as am I)... also Dijkstra was against OOP while wirth embraces it for parallel processing...
And the unit testing war vs formal methods war:
http://dare.ubvu.vu.nl/bitstream/handle/1871/2633/11173.pdf?sequence=1
http://www.amazon.ca/Science-Computing-Shaping-Discipline/dp/1482217694/ref=sr_1_1?s=books&ie=UTF8&qid=1441699195&sr=1-1&keywords=9781482217698
"In 1996, Hoare, too, wrote about how the problems of computing did not turn out to be what he expected: Ten years ago, researchers into formal methods (and I was the most mistaken among them) predicted that the programming world would embrace with gratitude every assistance promised by formalisation to solve the problems of reliability that arise when programs get large and more safety-critical."102 But while programs grew very large and very critical, they bypassed the point where they could be comfortably managed by formal methods. The problems and failures of software were typically attributable to things like requirements analysis, interaction design, and inadequate management. For Hoare, it turned out that the world just does not suffer significantly from the kind of problem that our research was originally intended to solve."
In 2009, forty years after the publication of his pioneering article, Hoare reanalyzed the verificationist standpoint and wrote that the basic mistake was
to set up proof and testing as opposites, whereas they can both contribute to the reliability of programs."
Wirth has claimed unit testing is the wrong way to go.. Minix creator thinks otherwise.. Hoare thinks they complement each other, testing and verification together.. (that's my view too)
The basic problem is the specification of the program itself, can contain errors, so you have to prove that your specification is correct and complete (which it can't be, unless the application is trivial), which ends up turning into something like Godel's incompleteness theorem...
How do you even prove that the OK button and CANCEL button are in the correct location? What about the artistic properties of a program that can never be proven?
How do prove a GUI to be correct (graphical user interface)...
Only trivial programs can be proven correct, unfortunately, such as a command line program that takes text in, and puts text out - GUI programs become much harder to prove, plus you don't even know what your end users want until you have the end users test the application and find out that this feature didn't work very good (how can you prove a feature to be correct, if they are subjective, such as trying to prove whether Photoshop's spray can feature is "correct" - who is to say what a proper spray can paint should do - how many exact dots can you prove it to? many different spray cans would work in photoshop, there isn't one correct dot pattern to use for spray cans. So you end up with something very much like godel's incompleteness theorem.
How can you prove everything about your application, especially graphics?
How do you prove that The Sims or Mario Brothers game is correct? who says it's correct? you can't make a game correct - it's a game - you can only prove trivial parts of the system, not its entire artistic creation as a whole. It's like trying to prove that a house is correct. Who is to say that a house is correct when it is blue in color an with stucco compared to one with bricks? is a fireplace correct? how do you address correctness when it comes to engineering, which unfortunately software is.. (it's not 100 percent math, some of it is GUI art, and approximations that aren't provable)