This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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". (comment by user:Prosfilaes, May 2004)
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)
"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)
I'm posting to the talk page so maybe we can discuss a consensus, instead of back and forth changes.
"Oberon code is typically smaller, and so faster, than equivalent code in many other languages."
Is bullshit. It is absurd to say that Oberon code is typically smaller if you don't specify languages and projects. Likewise, smaller doesn't mean faster. In Code Complete, Steve McConnell shows several functions in C to calculate the integer log base 2 of an integer; the fastest function is the longest.
Or let's look at Hello, World.
10 print "Hello, world"
echo Hello, world
#include <stdio.h> int main (void) { printf ("Hello, world\n"); }
MODULE HelloWorld; IMPORT Out; BEGIN Out.String("Hello World!"); Out.Ln; END HelloWorld;
Gee, Oberon produces the most code. Do you really think that means that the code will be slowest?
Should slim binaries (roughly: dictionary encoded abstract syntax tree of code) get mentioned in the article? See [1] for a little further info on slim binaries. Zarutian 01:06, 22 june 2005 (UTC)
I've proposed that the 'Oberon-2 article should be merged into this one. My reasons are --
If you look at the Oberon-2 article, you'll see it's quite short, because once you've discussed Oberon-1, there's not much more to say about it. So, without any negative feelings towards Oberon-1 or -2, I think these two articles should merge; and the Oberon-1 article is larger and better linked into Wikipedia.
What do you guys think?
OrangUtanUK 13:23, 10 August 2006 (UTC)
Makes sense to me. RainbowCrane 15:25, 10 August 2006 (UTC)
Good suggestion - assuming that it is set up so that anybody looking for information on 'Oberon-2' ends up directly in the right place in Wikipedia. Chris Burrows 23:58, 10 August 2006 (UTC)
Oberon programming language → Oberon (programming language) – Conformance with WP naming conventions atanamir
See: Wikipedia talk:WikiProject Programming languages/Renaming poll
Oberon-1 → Oberon (programming language) The first version of Oberon is never referred to as 'Oberon-1', just as 'Oberon' (similarly to Modula and Modula-2). Oberon already exists as a WP entry so Oberon (programming language) is the next best option. This is consistent with other Wikipedia entries for languages that have ambiguous general-usage equivalents (e.g. Lisp). It also helps to distinguish Oberon the programming language from Oberon the operating system Chris Burrows ( talk) 02:19, 26 August 2008 (UTC)
That's the first time I've ever seen "Oberon-1", and it should go away. Oberon (pl), Oberon-2 (pl), and Oberon (os) should be the names, IMHO, with all three linked directly from the Oberon disabiguity page. htom ( talk) 04:16, 28 August 2008 (UTC)
I've been unable to move "Oberon-1" to "Oberon (programming language)" as "Oberon (programming language)" already exists as a redirect page. Chris Burrows ( talk) 06:14, 28 August 2008 (UTC)
A recent edit by Taw included an edit summary noting the article said oberon was not object oriented. As this can be achieved in various ways, including that used by Wirth et al in the design of Oberon, I suggest that this edit is confused as to the underlying facts. And in any case, the article also says plainly the O is object oriented, just not in the C++, Java, or Smalltalk fashion. Comments? ww 05:22, 20 October 2006 (UTC)
I merged the Oberon-2 article in, following what looks like consensus and passive acceptance. Please feel free to vituperate me ... ! OrangUtanUK 18:49, 20 October 2006 (UTC)
I think they shouldn't have been merged. The article started with "Oberon is a reflective programming language" (reflection was added in Oberon-2), and then started to mix them randomly. Like here - "The design continued the Wirth tradition/strategy of attempting to simplify without loss of power. Oberon may be thought of as a Modula-2 with full object oriented class/object capabilities". OOP wasn't a design goal of course - it happened (to the extend it even happened, Oberon-2 was more component-oriented than object-oriented) many years later.
Maybe an article about both that cleanly separates them would be possible, but it's better to have two articles, than one that mixed things up so much. Taw 18:01, 31 October 2006 (UTC)
Noticing the problem (as above) as between Oberon-1 and Oberon-2 and all the merging and renaming and all, user:Mets501 attempted to help us with our confusion. There is now a disambiguation page for Oberon, pointing to the two articles. WP can endure a lot, but surplusage in disambiguation pages is too much.
We must delete the disambiguation page, rename the Oberon-1 article to Oberon and, if the merging is complete, delete the Oberon-2 article.
Merger folks, where do we stand on the merge...?
Ok, folks, let's get going... And, ...let's be careful out there. ww 03:26, 4 November 2006 (UTC)
Obliq is from Modula-3, not Oberon. —Preceding unsigned comment added by 24.46.21.229 ( talk) 23:27, 29 September 2007 (UTC)
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:10, 26 August 2008 (UTC)
I've logged a move request to rename Oberon-1 back to Oberon (programming language). This is consistent with other Wikipedia entries for languages that have ambiguous general-usage equivalents (e.g. Lisp). It also helps to distinguish Oberon the programming language from Oberon the operating system. Chris Burrows ( talk) 02:14, 26 August 2008 (UTC)
Is it really named after the moon, and not the moon's namesake, the King of Elves? 88.159.72.252 ( talk) 12:23, 5 March 2010 (UTC)
Both. See Page 8 of the Project Oberon book listed in the references. The moons of Uranus and the "king of elfs" are both mentioned. Chris Burrows ( talk) 00:11, 6 March 2010 (UTC)
After reading the article through I find myself lacking a lot of elementary information on the language. I don't know what term Oberon uses for functions (proc? function? subroutine?). I don't know if it has record structures or something comparable. I don't know how its objects differ from those in C++, just that they differ. I don't know whether a language feature must be declared before use, as in Pascal. I don't know whether arrays of different sizes are considered different types, one of the most criticized features of Pascal, and which most other modern languages try to circumvent. I don't know if the language supports JAVA-style interfaces. I don't know what the entry point of the programming is -- a "main" routine as in C? Sample source code would help, but the only sample source code I've seen was on this Talk page, not in the main article. In short, this article needs a lot of work. CharlesTheBold ( talk) 01:42, 17 June 2012 (UTC)
Both procedures and functions that return a result are called procedures.
Oberon has record structures. Additionally, unlike Pascal and Modula-2 these are extensible and so variant records are no longer required.
Identifiers must be declared before use apart from pointer references.
Name-compatibility is used rather than structure-compatibility as in Pascal and Modula-2. However, the dimensionless 'ARRAY OF <type>' can be used to allow arrays of arbitrary size to be passed as procedure parameters.
Interfaces are not supported.
On a suitably capable operating system (e.g. the Oberon operating system) any parameterless exported procedure may be an entry point - programs are constrained to just one entry point.
Note that this is an encyclopedia article not a Language Reference. Refer to the external links for more in-depth information about the language. Chris Burrows ( talk) 11:50, 17 June 2012 (UTC)
The article seems to me to have a POV problem. It sounds like a booster of the language wrote it.-- 76.169.116.244 ( talk) 03:13, 26 December 2014 (UTC)
This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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". (comment by user:Prosfilaes, May 2004)
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)
"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)
I'm posting to the talk page so maybe we can discuss a consensus, instead of back and forth changes.
"Oberon code is typically smaller, and so faster, than equivalent code in many other languages."
Is bullshit. It is absurd to say that Oberon code is typically smaller if you don't specify languages and projects. Likewise, smaller doesn't mean faster. In Code Complete, Steve McConnell shows several functions in C to calculate the integer log base 2 of an integer; the fastest function is the longest.
Or let's look at Hello, World.
10 print "Hello, world"
echo Hello, world
#include <stdio.h> int main (void) { printf ("Hello, world\n"); }
MODULE HelloWorld; IMPORT Out; BEGIN Out.String("Hello World!"); Out.Ln; END HelloWorld;
Gee, Oberon produces the most code. Do you really think that means that the code will be slowest?
Should slim binaries (roughly: dictionary encoded abstract syntax tree of code) get mentioned in the article? See [1] for a little further info on slim binaries. Zarutian 01:06, 22 june 2005 (UTC)
I've proposed that the 'Oberon-2 article should be merged into this one. My reasons are --
If you look at the Oberon-2 article, you'll see it's quite short, because once you've discussed Oberon-1, there's not much more to say about it. So, without any negative feelings towards Oberon-1 or -2, I think these two articles should merge; and the Oberon-1 article is larger and better linked into Wikipedia.
What do you guys think?
OrangUtanUK 13:23, 10 August 2006 (UTC)
Makes sense to me. RainbowCrane 15:25, 10 August 2006 (UTC)
Good suggestion - assuming that it is set up so that anybody looking for information on 'Oberon-2' ends up directly in the right place in Wikipedia. Chris Burrows 23:58, 10 August 2006 (UTC)
Oberon programming language → Oberon (programming language) – Conformance with WP naming conventions atanamir
See: Wikipedia talk:WikiProject Programming languages/Renaming poll
Oberon-1 → Oberon (programming language) The first version of Oberon is never referred to as 'Oberon-1', just as 'Oberon' (similarly to Modula and Modula-2). Oberon already exists as a WP entry so Oberon (programming language) is the next best option. This is consistent with other Wikipedia entries for languages that have ambiguous general-usage equivalents (e.g. Lisp). It also helps to distinguish Oberon the programming language from Oberon the operating system Chris Burrows ( talk) 02:19, 26 August 2008 (UTC)
That's the first time I've ever seen "Oberon-1", and it should go away. Oberon (pl), Oberon-2 (pl), and Oberon (os) should be the names, IMHO, with all three linked directly from the Oberon disabiguity page. htom ( talk) 04:16, 28 August 2008 (UTC)
I've been unable to move "Oberon-1" to "Oberon (programming language)" as "Oberon (programming language)" already exists as a redirect page. Chris Burrows ( talk) 06:14, 28 August 2008 (UTC)
A recent edit by Taw included an edit summary noting the article said oberon was not object oriented. As this can be achieved in various ways, including that used by Wirth et al in the design of Oberon, I suggest that this edit is confused as to the underlying facts. And in any case, the article also says plainly the O is object oriented, just not in the C++, Java, or Smalltalk fashion. Comments? ww 05:22, 20 October 2006 (UTC)
I merged the Oberon-2 article in, following what looks like consensus and passive acceptance. Please feel free to vituperate me ... ! OrangUtanUK 18:49, 20 October 2006 (UTC)
I think they shouldn't have been merged. The article started with "Oberon is a reflective programming language" (reflection was added in Oberon-2), and then started to mix them randomly. Like here - "The design continued the Wirth tradition/strategy of attempting to simplify without loss of power. Oberon may be thought of as a Modula-2 with full object oriented class/object capabilities". OOP wasn't a design goal of course - it happened (to the extend it even happened, Oberon-2 was more component-oriented than object-oriented) many years later.
Maybe an article about both that cleanly separates them would be possible, but it's better to have two articles, than one that mixed things up so much. Taw 18:01, 31 October 2006 (UTC)
Noticing the problem (as above) as between Oberon-1 and Oberon-2 and all the merging and renaming and all, user:Mets501 attempted to help us with our confusion. There is now a disambiguation page for Oberon, pointing to the two articles. WP can endure a lot, but surplusage in disambiguation pages is too much.
We must delete the disambiguation page, rename the Oberon-1 article to Oberon and, if the merging is complete, delete the Oberon-2 article.
Merger folks, where do we stand on the merge...?
Ok, folks, let's get going... And, ...let's be careful out there. ww 03:26, 4 November 2006 (UTC)
Obliq is from Modula-3, not Oberon. —Preceding unsigned comment added by 24.46.21.229 ( talk) 23:27, 29 September 2007 (UTC)
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:10, 26 August 2008 (UTC)
I've logged a move request to rename Oberon-1 back to Oberon (programming language). This is consistent with other Wikipedia entries for languages that have ambiguous general-usage equivalents (e.g. Lisp). It also helps to distinguish Oberon the programming language from Oberon the operating system. Chris Burrows ( talk) 02:14, 26 August 2008 (UTC)
Is it really named after the moon, and not the moon's namesake, the King of Elves? 88.159.72.252 ( talk) 12:23, 5 March 2010 (UTC)
Both. See Page 8 of the Project Oberon book listed in the references. The moons of Uranus and the "king of elfs" are both mentioned. Chris Burrows ( talk) 00:11, 6 March 2010 (UTC)
After reading the article through I find myself lacking a lot of elementary information on the language. I don't know what term Oberon uses for functions (proc? function? subroutine?). I don't know if it has record structures or something comparable. I don't know how its objects differ from those in C++, just that they differ. I don't know whether a language feature must be declared before use, as in Pascal. I don't know whether arrays of different sizes are considered different types, one of the most criticized features of Pascal, and which most other modern languages try to circumvent. I don't know if the language supports JAVA-style interfaces. I don't know what the entry point of the programming is -- a "main" routine as in C? Sample source code would help, but the only sample source code I've seen was on this Talk page, not in the main article. In short, this article needs a lot of work. CharlesTheBold ( talk) 01:42, 17 June 2012 (UTC)
Both procedures and functions that return a result are called procedures.
Oberon has record structures. Additionally, unlike Pascal and Modula-2 these are extensible and so variant records are no longer required.
Identifiers must be declared before use apart from pointer references.
Name-compatibility is used rather than structure-compatibility as in Pascal and Modula-2. However, the dimensionless 'ARRAY OF <type>' can be used to allow arrays of arbitrary size to be passed as procedure parameters.
Interfaces are not supported.
On a suitably capable operating system (e.g. the Oberon operating system) any parameterless exported procedure may be an entry point - programs are constrained to just one entry point.
Note that this is an encyclopedia article not a Language Reference. Refer to the external links for more in-depth information about the language. Chris Burrows ( talk) 11:50, 17 June 2012 (UTC)
The article seems to me to have a POV problem. It sounds like a booster of the language wrote it.-- 76.169.116.244 ( talk) 03:13, 26 December 2014 (UTC)