Talk:Oberon (programming language)

I don't have the information to correct this, but

"It also offers an interesting feature which is only recently becoming available in more prominent development systems: exportability of procedures. Imagine that for some program you create a PNG viewer procedure and that you export it: any program on the system will be able to view PNG files merely by calling the viewer! That's true reusability."

is bogus. Code libraries predate Fortran, and shared libraries date back to or before MTS and the late 1960s. CORBA and things like it do this too. I'm sure there's something mildly unique, but I don't know exactly what it is. Likewise,

"The code will be both smaller than that in nearly all other programming languages..."

leaves me sceptical; it sounds like ad copy instead of an accurate statement. Oberon is in the same family as Modula-3, Ada, Pascal, and Java, and more distantly C, so it's not going to produce a huge difference in code size. Perl, Mathematica and APL will blow away any of the above languages in the right problem domain.

"...(mistakes will be less easily lost in a forest of detail)"

Which doesn't follow from the statement it's parenthetical to. Languages that add the detail of a variable definition for every variable save people from many mistakes that were made in Fortran. APL and Perl are both known for small code, and both are known for being hard to read.

"less opaque (fewer language 'features' mean less chance of confusing/misusing them)"

Love the scare quotes around features. How does removing enumerations and forcing people to use integer constants make things less opaque? In general, you have language features because otherwise you have to write a lot of code to emulate them, or because it's more efficent to have the compiler handle it. I had a professor who would honestly argue that programmers should just use a Fortran with extra features added until everyone was happy. Whether or not Wirth's minimalist strategy is good is still being debated, but the average programmer uses a programming language more complex than Oberon, and frequently much more complex than Oberon (C++, Perl, Common Lisp, Fortran 95).

"less subject to error problems from data typing problems"

C programmers might point out that strict data typing like Oberon has is a pain and can add to a lot of type changing, from integer to float, for example, and even worse if you want to start bitwiddling character input. An Ada programmer, like me, would point out that in exchange for that pain, you catch a lot of errors; but Oberon doesn't catch nearly as many errors as it can, and is less portable than it should be, because it doesn't include enumerations and ranges that catch errors and avoid depending on an implementation specific integer type.

This presents Oberon as the perfect language, and doesn't include any concept that it's not, that the design principles may have tradeoffs. This is not unique: Ada programming language doesn't include much discussion about the tradeoffs either, but mentions the features as facts, instead of saying how much better it is than "almost every other language".

Sure it's enthusiastic. But worrying about POV is not needed.

The article is enthusiastic. There is evidence that simpler languages have greater reliability. The above comments are all true. Calling an enthusiastic article NPOV seems overreacting. The article could be more encyclopedic by incorporating the comparisons noted above into the article. Kd4ttc 19:57, 2 Jun 2004 (UTC)

If in the article on Christanity that "Christians were better people than non-Christians", that would slapped down instantly as NPOV. Writing that "Oberon programs are also less likely to be buggy" is no less NPOV, even if it brings up less emotional responses.

I've read about studies to prove that Ada is less buggy than C and C++, but I'm not going to add "Ada programs are also less likely to be buggy" to the Ada programming language page. If I was interested in doing so, I'd have to make it clear the details of the studys, which might give me the right to say that, in many cases, it appears that Ada can have a significantly lower defect rate than C and C++. If studies were made comparing Oberon and other languages, they need to be cited, and then you can say that in the instances of the studies Oberon performed better than the other languages studied.

I can't incorporate my corrections into the article, because I don't even know what it's talking about frequently. --Prosfilaes 08:31, 3 Jun 2004 (UTC)

Religion and politics get the strongest response so discussions on Mac vs Windows sure get exciting! (Politically incorrect comments on (delete groups) deleted) Wikins seem to be very tolerant. I think the comment on studies regarding correctness of programs would be very useful in Ada. The article on Eiffel could benefit there as well, with the interesting observation that commercial success seems inversely related to how clean the programs are, and that commercial success measures only sales of compilers, not utility of languages. The studies that discussed what goes into creating a reliable language seem to have been lost on a whole generation of programmers. Lucky grad students in the future, who can rediscover all those studies. Me: I'm just an old fart medical doctor. Not up to date on the studies we've discussed obliquely. I'd like to see the Algol families come back. I get ill just looking at C code. At least I'm in good company with Dijkstra feeling the same way. Once a port of something like Pascal, Oberon, or Modula port to Mac OS and is tightly integrated in the IDE I'll get entusiasm for programming again. Till then PHP, mySQL, and Apache will have to do. Kd4ttc 01:36, 4 Jun 2004 (UTC)

Libraries versus features

"It has likewise been argued, failure to include a feature may force the programmer to reimplement the feature in his code, causing many people to code the same algorithms, frequently with bugs or inefficently; however, this ignores the concept of libraries. Java is an example of a simple-enough language surrounded by an enormously rich class library."

First place, it's beside the point; Oberon does not have the rich class library. Second place, it's overstating your point; libraries have different strengths than features. There's no enumeration library that's going to do the compile-time checking and clarity and succinty of built-in enumerations. You can't provide templates in a library, either, and emulated templates aren't as type-safe as the real thing. Likewise, libraries don't give compilers as much information as features do; compilers will frequently give awful error messages with the STL because they're seeing the inside of the template rather than the feature.

Also, are you still a simple language if you have a Java-sized standard library? Implementations still have a long row to how, and it's not like it's any easier or less required to learn about a feature if it's stuck away in a library. --Prosfilaes 12:19, 27 Jun 2004 (UTC)