|WikiProject Computing / Software||(Rated Start-class, Low-importance)|
|This is the talk page for discussing improvements to the Oberon-2 article.
This is not a forum for general discussion of the article's subject.
"Designed by Niklaus Wirth, Hanspeter Mössenböck" gives a wrong impression. Hanspeter Mössenböck designed the language as an extension of Oberon. He is also the first author of the Language report: 
||This article may be too technical for most readers to understand. (September 2010) (Learn how and when to remove this template message)|
This has been discussed here and elsewhere, but I'm not sure what came about from the discussion. Can the Oberon-1 and Oberon-2 pages be merged into just an Oberon page? There wasn't really an "Oberon-1", there was just Oberon, and then Oberon-2, and now Oberon-07. Each of the changes/revisions could just have their own sections. Bishopmartin (talk) 01:19, 26 August 2008 (UTC)
The source of information for the summary of extensions is Differences between Oberon and Oberon-2 by Hanspeter Mössenböck and Niklaus Wirth.
Chris Burrows 14:24, 10 October 2005 (UTC)
Niklaus Wirth's languages have very striking differences, hidden among their similarities. Almost Introvert/extrovert. For example Algol could talk to any other language, and be mixed in to build a product, an extrovert. Pascal in it's native form would have to be recompiled to point to a different file, an introvert. Modula II was out there again. Interfacing other languages. It was a great language for real world problems. Definitely an extrovert. Oberon (an Oberon-2) have their own environment again. They don't want to touch the real world. And although they are nicely written languages, they are not good for much beyond teaching. A major introvert.
So Niklaus has had plenty of time to write yet another extrovert language, but I am not seeing anything out there.
Anonymous 14:30, 21 February 2007 (UTC)
-- Funny analysis :-). To me, the main characteristic of Wirth's languages are the warts :-P (not by evolution, but on purpose... i cannot understand that...). For example: Oberon has operators "&" and "OR". Why the former is a symbol and the latter is a word? This looks stupid (and i'm inclined to think that it is stupid). And Pascal had the wrong precedence for "and" and "or", which forced you to always use parenthesis (among other annoyances). I could never find a rationale for those decisions. -- unsigned
No, that's not right. Oberon-2 is one of my favourite languages simply because it IS useful for things beside teaching. Remember, the Obeon-2 compiler and operating system were written in Oberon-2, so it can certainly claim a place as a systems programming language. Oberon is a bigger better Pascal, and Pascal has been used for a great many real-world applications, including (until recently) the user interface system at the London Stock Exchange.
OrangUtanUK 13:13, 27 April 2007 (UTC)
Does anyone mind if I make the code examples a bit clearer? Most of them don't do anything when they run, and some of them don't even compile cleanly.
- Good idea. I'm not too worried about the ListClass example as anybody who would be able to understand the additional details could fill in the blanks anyway. However the 'birds' example surely could be replaced with something more realistic. Shapes (rectangles, squares, circles) and their areas perhaps? However, this is an encyclopaedia so again, just a skeleton illustrating the main issues is sufficient. Examples should include valid declarations statements, expressions etc. but it is not necessary (or advisable) to include complete compilable working examples.
- Chris Burrows (talk) 01:07, 11 January 2008 (UTC)
Oh, good. Yes, I agree. Code examples in a dictionary should be primarily (a) understandable - hence short, (b) useful - hence showing a range of language elements, and (c) correct. My concern about compilability relates to the third point.
I think it would be best to take fragments of code from the papers and key reference books, where possible.
In the example method
PROCEDURE (l : List) Add* (v : Integer);
List Example correct?
Is the List example actually correct? Procedure
Add is bound to the pointer type
Add is tested if the receiver parameter
NIL (same again in
Get). But how can Oberon perform dynamic binding to
List::Add (sorry for C++ idiomatic expression when talking about Oberon, but I think it clarifies what I mean) when
NIL and thus doesn't carry any useful type information?
I concede this point does not take effekt until there are more types in a hierarchy, and the static type of the pointer used to call
Add is not sufficient to determine whether
T is any subtype of
List) should be called. --Lile221 (talk) 08:23, 21 January 2015 (UTC)
Image copyright problem with File:OberonLogo.gif
The image File:OberonLogo.gif is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check
- That there is a non-free use rationale on the image's description page for the use in this article.
- That this article is linked to from the image description page.
Add new page about Keiko bytecode
In section "Implementations" I suggest to replace external link "Keiko Virtual Machine" by new page Keiko bytecode. An introduction about Keiko is written on http://spivey.oriel.ox.ac.uk/corner/Design_overview_for_OBC#The_Keiko_Abstract_Machine . A text will be as short summary. Its planned to add section History too. Then one can mention Keiko in section Bytecode#Examples.