Oberon Community Platform Forum

General => General Discussion => Topic started by: dukester on May 31, 2011, 04:37:31 PM



Title: Comparison of the C and Oberon-2 langauges
Post by: dukester on May 31, 2011, 04:37:31 PM
Hi ...

Is there a document hiding somewhere that objectively compares the 2 langauges? pros and cons! :)

I'm not talking about the availability of C libraries -vs- Oberon modules. Just the language itself.
--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on May 31, 2011, 06:40:41 PM
I found this - not C, but close:

http://www.modulaware.com/mdlt49.htm

Anything else? :)
--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: cfbsoftware on June 01, 2011, 02:32:34 PM
To avoid trying to "compare apples with oranges" it makes more sense to compare C++ and Oberon-2 as, unlike C, both have a number of features specifically designed to be used for object-oriented programming.

It might be fairer to compare original Oberon (or the more recent version, Oberon-07) with C.  

While preparing my presentation "ARM Embedded Development Using Oberon-07" for last week's Oberon Day 2011 symposium I attempted to get some measure of the comparative reliability of C and Oberon-07 when used for embedded software development. To do this I took the 142 rules of the MISRA-C:2004 "Guidelines for the use of the C language in critical systems" and applied them to Oberon-07. I discovered that more than 70% of the rules are not required when programming in Oberon-07. They are either already enforced by the language or are not applicable.

Examples of MISRA rules that are not applicable to Oberon-07:

  Rule 14.4: The goto statement shall not be used. (Oberon-07 does not have GOTO)

  Rule 14.5: The continue statement shall not be used. (Oberon-07 does not have CONTINUE)

Examples of MISRA rules that are enforced by the design of Oberon-07:

  Rule 14.7: A function shall have a single point of exit at the end of the function.

  Rule 16.6: The number of arguments passed to a function shall match the number of parameters.

The remaining 30% of MISRA rules that also need to be checked when using Oberon-07 include:

  Rule 2.4 (advisory): Sections of code should not be "commented out".

  Rule 20.4: Dynamic heap memory allocation shall not be used.

More information about MISRA and their guidelines can be found on their website:

  www.misra.org.uk (http://www.misra.org.uk)  

The Oberon and Oberon-07 Language Reports can be downloaded from:

  www.inf.ethz.ch/personal/wirth/Articles/Oberon.html (http://www.inf.ethz.ch/personal/wirth/Articles/Oberon.html)


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 01, 2011, 03:36:00 PM
To avoid trying to "compare apples with oranges" it makes more sense to compare C++ and Oberon-2 as, unlike C, both have a number of features specifically designed to be used for object-oriented programming.

It might be fairer to compare original Oberon (or the more recent version, Oberon-07) with C.

Sure! I actually meant the "C family of languages". Whatever - I was hoping to find some documentation somewhere that would say - in a nutshell - something like: "Anything that you can do in C/C++ , can be done in Oberon-x, etc, etc" :)  

Quote
While preparing my presentation "ARM Embedded Development Using Oberon-07" for last week's Oberon Day 2011 symposium I attempted to get some measure of the comparative reliability of C and Oberon-07 when used for embedded software development. To do this I took the 142 rules of the MISRA-C:2004 "Guidelines for the use of the C language in critical systems" and applied them to Oberon-07. I discovered that more than 70% of the rules are not required when programming in Oberon-07. They are either already enforced by the language or are not applicable.

That probably answers my question! Have you published your presentation yet? Would you think that Modula-3 would do as well?
--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: leledumbo on June 01, 2011, 06:14:36 PM
Other than that document from modulaware, I never find anything good enough. But if you have enough experience in both language families, you could feel the pros and cons yourself. For me:
  • Oberon
    • Pros
      • Ultra high compilation speed (decreases development time in waiting for the compiler to compile)
      • True modular programming (no linker errors except when interfacing with external modules)
      • Garbage collected
    • Cons
      • Limited OOP (no interfaces, single inheritance)
      • UPPERCASE keywords (it still hurts my fingers...)
      • Not really widely used
  • C++
    • Pros
      • Good marketing strategy (thanks to MS and AT&T)
      • Widely used, many ready-to-use libraries available
    • Cons
      • Still pertaining C's cumbersomeness in modularization approach (via preprocessor, module interdependency check is either difficult, requires additional pass, or impossible to do)
      • Susceptive to link-time errors
      • Super duper complex language (esp. in incoming C++0x), requires unlimited lookahead for parsing
      • Many errors that could actually be detected at compile-time, become impossible due to lack of proper semantics


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 01, 2011, 07:45:23 PM
@leledumbo  ???

Anyway .... Thanks for your comments. I take it that outside the Oberon family of OS, you use C++ for most of your programming requirements/work?
--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: cfbsoftware on June 02, 2011, 02:07:47 AM
Have you published your presentation yet?
Presentations from previous Oberon days have been published on the relevant websites so I assume the same will happen again. They also filmed the whole event this time and are planning to publish some of the recordings on the website:

http://www.oberonday2011.ethz.ch/

Quote
Would you think that Modula-3 would do as well?
Probably but can't say for sure - it's more than 20 years since I last looked at it. Try asking in one of the modula-3 discussion groups / forums.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 02, 2011, 04:14:32 AM
@Chris
The Modula-3 newsgroup appears to be as quiet - if not more so - that the Oberon or Modula-2 NGs. Could be yet another adventure. :) Thanks.
--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Dsar on June 05, 2011, 10:52:01 AM
Would you think that Modula-3 would do as well?
Modula-3 is very nice, if you were looking for a valid alternative to C++ this would be a good choice. Ada is another valid choice, but it's becoming too big for my taste. Anyway, gnat and opencm3 compilers are well maintained.

C++ is the worst language ever designed. There is a (classic) paper by Ian Joyner titled "A critique to C++", where it is widely discussed.
http://archive.adaic.com/intro/ada-vs-c/cppcv3.pdf

Some quotes from the past ;-)

 "Fifty years of programming language research, and we end up with C++ ??" - Richard A. O'Keefe

 "I invented the term 'Object-Oriented', and I can tell you I did not have C++ in mind." - Alan Kay, creator of Smalltalk

 "C++ is impeding the progress of the programming technology." - Ian Joyner

 "There are only two things wrong with C++: The initial concept and the implementation" - Bertrand Meyer, creator of Eiffel

 "C++ is an insult to the human brain." - Niklaus Wirth

 "Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said, 'OK, we'll do them both'. So the language is too baroque for my taste" - Donald Knuth

 "C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it." - Linus Torvalds



Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 05, 2011, 11:12:48 AM
Would you think that Modula-3 would do as well?
Modula-3 is very nice, if you were looking for a valid alternative to C++ this would be a good choice. Ada is another valid choice, but it's becoming too big for my taste. Anyway, gnat and opencm3 compilers are well maintained.

I just installed the Critical Mass Modula-3 compiler complete with the web-based IDE.  What a nice system! I'm loving it! The tutorial is great; as is the IDE "User Guide". This language truly deserves more exposure, IMHO.

Quote
C++ is the worst language ever designed. There is a (classic) paper by Ian Joyner titled "A critique to C++", where it is widely discussed. http://archive.adaic.com/intro/ada-vs-c/cppcv3.pdf

Until I met the Oberon-2 language, I shied away from all OOP languages. I never did go near C++. However, lately, I had a notion that I should learn C, as it seems that just about everything is written in C (or one of its derivatives). Then, my old hang-ups with the C syntax quicky surfaced again, and I got to wondering if Oberon-2 et al , can do everything that C can, and then some - OOP capabilities notwithstanding.

You've nailed it for me, though. I won't ever go near C++; and I'll learn Oberon-2 and its successors well, before investing any time with C. However, now that I've discovered Modula-3 ...  :D

Thanks for the input!
--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Dsar on June 05, 2011, 09:25:43 PM
Until I met the Oberon-2 language, I shied away from all OOP languages.

Well, Oberon-2 is (imho) superior to C++ because it is well designed. Anyway, learning OOP from Oberon-2 is very straightforward. The Mossenbock's book about OOP with Oberon-2 is the clearest one I've read.

I had a notion that I should learn C, as it seems that just about everything is written in C (or one of its derivatives).

I was a C programmer, some years later I switched to Ada and now I code mostly in Oberon-2 for my personal projects (I still use Ada). With these ones I learnt a lot about security and software engineering in general. Now I'm not able to think how C can be used today! I feel the emergency that all C projects should be converted to a sane language to make the world better.
With a sane language 70% of security bugs could be avoided.

Cons of C:
- No modularity.
- No strong typing.
- No knowledge of type range (char a = 1000; is legal).
- No boolean type.
- No true concept of array.
- No direct support for bounds checking.
- No safe type-casting.
- No safe union.
- No separation of unsafe code.
- No by reference parameter passing (simulated with pointers).
- No set type (C programmers use the unreadable bitwise operators for simple stuff).
- No nested procedures (useful for error recovery).
- Dangling else.
- Ternary operator.
- Broken include preprocessor (you have to use an include guard to avoid double inclusion!)
- Pointer arithmetic.
- Ability to mix expressions and statements (the most DANGEROUS and NON-SENSE feature! I've spent a lot of months for an unrevealed error in an IF expression with a = b instead of a == b. I'm still furious with it!)
- Awful and inconsistent standard library (character functions use integer parameter as character because it is also used for error reporting !!)
- ... and others omitted just to keep the list short ;-)

I don't see any pros in C, I cannot help you in this, sorry.

I got to wondering if Oberon-2 et al , can do everything that C can, and then some - OOP capabilities notwithstanding.

Oberon is also an operating system, then you can do everything. Oberon, compared to C, is less flexible and restricted. The real question is: is this flexibility really needed during programming? My answer is: No, it doesn't. The world need rules to avoid chaos.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 05, 2011, 10:34:07 PM
Much obliged!    +2

--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Bernhard T. on June 06, 2011, 02:50:45 PM
although it is not possible to apply it directly, I remember vaguely a comparison of Modula-2 and C in the Journal of Pascal Ada & Modula-2 back in the 1980ies.

Browsing through ACM pages, I found it: http://portal.acm.org/citation.cfm?id=69405
but I have no idea if/where it can be found online.


Title: Comparing Modula-2 and C.

Authors:  R. Bray  B. Fairless   R. Gile   S. Waller   R. Maxey   D. West   

Published in: Journal of Pascal, Ada & Modula-2, Volume 8 Issue 2, March/April 1989

SIGS Publications, Inc. New York, NY, USA

Maybe some brave soul has a copy and could scan the three pages.

Bernhard
 


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 06, 2011, 03:12:17 PM
@Bernhard

Thanks for digging that up. I can almost guess what the artcle will say. :)

This is an uninformed opinion, but I think that the Modula/Oberon family of languages can probably compete nose-to-nose with C/C++ for most tasks. However, the availability of the various compilers, and how well they are maintained, would probably influence programmers toward the C family (or another language) and away from Modula/Oberon. The old saying still applies, I'm afraid, i.e. "You snooze; you loose!"  ;(

I've moved way from the C/C++ vs Oberon-2 comparison, to wondering how Modula-3 compares to Oberon-2 +? I installed the Critical Mass M3 system on my Xubuntu box.  It's very good! IMHO.

You might be interested in test-driving it ...  http://opencm3.net/

Thanks for the input!
--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: leledumbo on June 06, 2011, 04:24:53 PM
Quote
@leledumbo ???

Anyway .... Thanks for your comments. I take it that outside the Oberon family of OS, you use C++ for most of your programming requirements/work?
Sorry for the long reply. Nope, I just know C++ quite deep because I like to explore programming languages. My real work uses either Java (academic, university), Pascal (everything as long as allowed, usually private and open source projects), PHP (for short time web-based app), C (if I can't say "no" to my boss).


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Bernhard T. on June 07, 2011, 08:44:46 AM

[...]
to wondering how Modula-3 compares to Oberon-2

It's very good! IMHO.


I had a deep look at Modula-3 in the mid 1990ies, but I prefered the Oberon design and its "art of simplicity" approach compared to the "art of complexity" approach used in the design of Modula-3.

In the mean time I discoverd Hoare's quotation : "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." (see http://en.wikiquote.org/wiki/C._A._R._Hoare#The_Emperor.27s_Old_Clothes). I am not convinced that the complexity approach of Modula-3 is really helpful, although I also had sometimes the impression that too many useful features had been eliminated in Oberon.

regards
    Bernhard


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: leledumbo on June 07, 2011, 04:36:01 PM
One thing I don't like about Modula-3 is that its developed independently without any accordance with Prof. Wirth. I feel somehow it has lost the main touch of Pascal family of language: simplicity without (too many) features sacrificed.

Why can't it look at Oberon? Method implementation right in the class definition (taken by Java), exceptions as rescued statement in blocks (taken by Ruby), this shows Oberon's influential features despite its very simple language grammar (33 productions, even a toy language from compiler construction class in my university has 80 productions!), which IMHO Modula-3 should consider.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 07, 2011, 08:08:20 PM
I am not convinced that the complexity approach of Modula-3 is really helpful, although I also had sometimes the impression that too many useful features had been eliminated in Oberon.

I'm not getting the impression that the current Opencm3 "system" is overly complicated. Just the opposite! It has a nice web-based IDE; a great tutorial! CM3 syntax is as easy as Modula-2 or Oberon-2, IMHO. The compiler is stand-alone - no need for yet-another-OS.  :)  Of course, I'm still test-driving, and have not gone too deep.
--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 07, 2011, 08:12:56 PM
One thing I don't like about Modula-3 is that its developed independently without any accordance with Prof. Wirth. I feel somehow it has lost the main touch of Pascal family of language: simplicity without (too many) features sacrificed

http://opencm3.net/doc/reference/complete/html/1_1History.html

--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: greim on June 08, 2011, 11:17:42 AM
 
....C is not a "very high level" language, nor a "big" one, and is not specialized to any particular area of application. ...



Brian W. Kernighan  Dennis M. Ritchie

Preface of "The C Programming Language"

(my personal copy of 1978)

M. Greim


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 08, 2011, 01:15:54 PM
....C is not a "very high level" language, nor a "big" one, and is not specialized to any particular area of application.

Sorry! I'm missing your point ....

--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: leledumbo on June 08, 2011, 04:33:43 PM
One thing I don't like about Modula-3 is that its developed independently without any accordance with Prof. Wirth. I feel somehow it has lost the main touch of Pascal family of language: simplicity without (too many) features sacrificed

http://opencm3.net/doc/reference/complete/html/1_1History.html

--
Duke
That doesn't prove Prof. Wirth was part of the committee (and AFAIK he was not), he only gave blessing to the language to born.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: dukester on June 08, 2011, 06:32:26 PM
Quote
That doesn't prove Prof. Wirth was part of the committee (and AFAIK he was not), he only gave blessing to the language to born.

Exactly! And if he had wanted to be further involved, I'm sure that he would have been accomodated.  But what's the difference? Wirth "zigged"; and Modula-3 "zagged" - a little bit. It still appears to be a great language with or without Wirth having held their hands, and wiped their noses while it was being developed.  :)
--
Duke


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Dsar on June 08, 2011, 11:27:33 PM
This is an uninformed opinion, but I think that the Modula/Oberon family of languages can probably compete nose-to-nose with C/C++ for most tasks.
My opinion is different, C/C++ cannot compete with a language of Modula-2 family ;-)

Anyway, efficiency depends a lot by the compiler. It's easy to generate fast code with C because it has nothing, in a strongly typed language instead you should bring (for example) type information and other stuff in the binary file. But you can program a Modula-2 compiler that generates fast code as C without these checks and informations, the real question is: is it worth to lost these important checks and informations? A safe C program does these checks with macros written by the programmer and becomes slow. Then it has no sense.

I had a deep look at Modula-3 in the mid 1990ies, but I prefered the Oberon design and its "art of simplicity" approach compared to the "art of complexity" approach used in the design of Modula-3.
Modula-3 and Oberon are different successors of Modula-2 with different thinking about the term of "simplicity", as it is documented in the report of Modula-3. Wirth had his ideas, at DEC they had their ones. Anyway, Modula-3 is not so different from Modula-2, it was the answer to the complexity of Algol 68, Ada, C++ and other languages of that period and starting from Modula-2 was a good base. If you compare Modula-3 with other languages, it is not so complex.
If you think Modula-3 is a complex language, I invite you to give a look at Ada, if you want to master the language in all details there is a an annotated reference manual of about 1200 pages. One day I wanted to investigate the behaviour of the new operator, and it behaves differently on the kind of data, in some cases it allocates on the stack, in other in the heap. Maybe they thought it should be invisible to the programmer in an high level language and it allows full control and optimisations by the compiler.
But it is really impossible to master the language in all details for a non-professional programmer like me.
Complexity is: when there are a lot of information to remember, no exact definition of a particular behaviour and a lot of missing information.
Simple concepts and predictable behaviours are an important aspect of a language. I consider Modula-3 simple.

I've moved way from the C/C++ vs Oberon-2 comparison, to wondering how Modula-3 compares to Oberon-2 +? I installed the Critical Mass M3 system on my Xubuntu box.  It's very good! IMHO.
Modula-3 is a revised Modula-2 with some issues corrected, for example name clash in enumeration and export/with qualification (in Modula-3 WITH is an alias tool). It also added genericity, multithreading, exception handling and OOP in a minimal way.
Wirth instead used another approach, remove non-essential features.
If you are interested in the motivation of these changes, I suggest "From Modula-2 to Oberon" by Wirth and the report of Modula-3.

It's not easy to do a comparison between Modula-3 and Oberon-2. Both are excellent languages, the use depends on your needs. For my needs I use Oberon-2, because for example I don't need subranges and other features. It has all the safety I need for my personal projects. Also, I prefer simple and reliable compilers for a language that doesn't have a large community.

Brian W. Kernighan  Dennis M. Ritchie

Preface of "The C Programming Language"
WARNING!
This is the most DANGEROUS book I've ever read!
Authors give a lot of BAD ideas to the newbie programmers! They often suggest a lot of unreadable syntax and wrong concepts, and say that professional programmers prefer these forms! some examples from this book:

Code:
while ((to[i] = from[i]) != '\0') ++i;

while ((s[i++] = t[j++]) != '\0'); <-- this is a statement!

return (bufp > 0) ? buf[--bufp] : getchar();

for ( ; --lim > 0; w++) { ... }

This book should be banned from bookstores.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: leledumbo on June 09, 2011, 05:36:05 PM
Quote
WARNING!
This is the most DANGEROUS book I've ever read!
Authors give a lot of BAD ideas to the newbie programmers! They often suggest a lot of unreadable syntax and wrong concepts, and say that professional programmers prefer these forms! some examples from this book
Well... since C was designed not to be coded readably and structured, I think the authors had done it as intended ;D


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Cleverson on June 16, 2011, 06:50:10 PM
What about Go, the Google's recently released language?
http://golang.org/ (http://golang.org/)
Opinions?


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: leledumbo on June 17, 2011, 04:01:05 PM
Quote
What about Go, the Google's recently released language?
An uglified (C-ed) version of than Modern (Object) Pascal, with built-in map data type (isn't it supposed to be library's job?), built-in concurrency support (Ehm... Active.. Ehm... Oberon...), and type bound procedures a la Oberon-2.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Dsar on June 18, 2011, 11:21:21 AM
What about Go, the Google's recently released language?
http://golang.org/ (http://golang.org/)
Opinions?

Go is very similar to Oberon-2, but it has a simpler form of polymorphism (interface based), it is limited to 1 level of extension (then no type hierarchy) and only to record with type bound procedures (interface types), this allow a safe multiple inheritance that is useful in component oriented programming.
It also has concurrency. About this argument I strongly suggest to read "Thread cannot be implemented as a library" by Hans-J. Boehm. There are some issues about correctness if concurrency is implemented as library. If concurrency is on the compiler side, it can optimize the memory model. Ada and Fortran have proved a great performance in multitasking/multithreading programs.

Anyway, I don't like Go. It shares syntax with C and It's easy to code unreadable programs by mixing some of these (unusual) operators: &^ , &^= , <<= , <-.



Title: Re: Comparison of the C and Oberon-2 langauges
Post by: ewnuz on June 19, 2011, 01:49:38 AM
While this thread has digressed a bit from the original question, language comparisons are an interesting topic, even interesting enough for me to create an account here. Let me first criticize the forum administrators for forcing me to install Flash in order to solve their stupid captcha, which apparently doesn't have the effect of keeping spammers out, which I can tell from yesterday's topic "wholesale designer handbags". Flash, seriously? I am actually considering to check the registration form at some point in the future for the removal of that requirement and leave this place on general principle in the event that that insanity is kept in place, but well, I'm here for now.

To the topic, let me first say that while I know neither of the languages discussed so far to the point that I'd be able to do programming with them without a cheat sheet next to me, I have looked at and read a lot about a number of different languages, so that I'd like to join the club, so to speak.

There seems to be some confusion about Modula-3, which I would like to resolve, as I happen, perchance, to have obtained a copy of "Systems Programming with Modula-3" rather recently, which turned out to be a good idea, given the interest I had to learn about its design. I cannot see how Modula-3 would embrace "the art of complexity", as somebody remarked, given the language designers' self-imposed constraint to keep the language report within 50 pages. While I'd consider some of its design decisions of questionable value, all in all I'd say the result is not exactly a bad one. As regards the involvement of Niklaus Wirth, the book says that it was proposed to develop Modula-3 as a successor to Modula-2 starting from Modula-2+ (delevoped earlier at DEC by Paul Rovner, Roy Levin, John Wick et al.), to which he gave his blessing. While he was not in the design committee itself, the book says: "He also reviewed the evolving design and made many valuable suggestions—not one of which was a suggested addition. Indeed, he inspired us with the courage to pull out a number of deep-rooted weeds." The last chapter gives an account of the discussions within the committee that elucidates well why certain decisions in the design have been made. It should be an interesting reading for anybody interested in language design.

As regards Ada, it has seen a number of extensions over the years despite the extensiveness of the language description being said to have been the major criticism from the beginning. Given that it was intended for large-scale software development, the justification for a large language might have been there. My impression of it is that it is not as much of "an insult to the human brain" as C++ has been said to be, but I wonder if a simpler design could not have achieved similar qualities. It seems to have a number of little, useful features for certain usecases, but the ignorant developer might not be unlikely to reimplement their functionality otherwise, for he has either never learned or already forgotten about a particular feature's existence before he first happens to encounter a situation in which it might be useful to him. All in all, featuring a language reference manual of around 800 pages, Ada looks somewhat overengineered to the point where the standardized rules add more complexity than their benefit would justify.

Dsar, as you seem to like Ada, you might be interested in ParaSail, a pet project of Tucker Taft, chief designer of Ada 95. He has blogged (http://parasail-programming-language.blogspot.com/) about it during the design phase. The reference manual that resulted is on par with Modula-3's 50-page report and can be found at the language's Google Group (http://groups.google.com/group/parasail-programming-language). There's no compiler as of yet but I'd expect a first one to get ready this year. Maybe you even feel like comparing ParaSail to the Oberon family languages?

I wonder what people here think about functional programming. Did somebody look at Dylan (as you should find its syntax attractive) and has an opinion? Or Scheme anyone? Should syntax be included in the list of language features that should be omitted for simplicity? Opinions welcome, if that is not too much digression from the original topic (well, it is, but we bother not many people here, no?).


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Dsar on June 30, 2011, 03:15:20 PM
As regards Ada, it has seen a number of extensions over the years despite the extensiveness of the language description being said to have been the major criticism from the beginning. Given that it was intended for large-scale software development, the justification for a large language might have been there. My impression of it is that it is not as much of "an insult to the human brain" as C++ has been said to be, but I wonder if a simpler design could not have achieved similar qualities. It seems to have a number of little, useful features for certain usecases, but the ignorant developer might not be unlikely to reimplement their functionality otherwise, for he has either never learned or already forgotten about a particular feature's existence before he first happens to encounter a situation in which it might be useful to him. All in all, featuring a language reference manual of around 800 pages, Ada looks somewhat overengineered to the point where the standardized rules add more complexity than their benefit would justify.

I've something against the number of pages of a reference manual.
Okay a lot of details have a benefit, Ada is the only language I've ever see that compiles equally on every compiler. I did a big project with gnat, when I tried to compile it with ObjectAda and PowerAda it worked flawless (both compilation and execution!). Instead, every compiler of any other language had always some differences in the implementation, 20 or 50 pages are not sufficient for a compiler writer.
But 900 pages for a normal or professional programmer are too much and 1300 pages for a compiler writer is an impossible task, you cannot implement an Ada compiler alone. It requires a large number of programmers and a initial badget. A conformant Ada compiler requires a commercial support.
And a normal programmer that would master the language has a lot of details to remember.

Ada should be simplified, it has a lot of redundant features that can be replaced by a general one (like discriminant type with tagged type) like ParaSail, but honestly I don't like it.

I wonder what people here think about functional programming. Did somebody look at Dylan (as you should find its syntax attractive) and has an opinion? Or Scheme anyone? Should syntax be included in the list of language features that should be omitted for simplicity? Opinions welcome, if that is not too much digression from the original topic (well, it is, but we bother not many people here, no?).

With a lot of code they become unreadable for my taste.



Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Wlad on July 07, 2011, 09:43:14 AM
What about Go, the Google's recently released language?
http://golang.org/ (http://golang.org/)
Opinions?
Go = Google's Oberon  :)

I started my experience in programming in Modula-2 on Kronos processor. May be this fact became the basis of my preferences in prog.languages. But same time I learned C.
Aprox. 10 years after that I tried to use C/C++ in my projects, but ironically all my success projects was developed in Modula-2/Turbo(Borland)Pascal/Delphi. Every time it happened something that "switched" to Pascal-like language from C/C++ to make a project be done.
After several years I had decided to make "solid soultion" to work in C/C++ in embedded systems field.
I do it during last 10 years.
And it is revealed more ironical things.
The programs for embedded system frequently HAVE NO ANY "airbag" beneath application code.
There is NO an operating system or a runtime environment which can "catch" programmer's mistakes and process them (exceptions handling).
There is NO "classic" C/C++ libraries with a great deal of functions and algorithms.
A programmer IS LEFT ALONE WITH THE PROBLEMS AND THREATS. Note: it happens in the field of VERY CRITICAL APPLICATIONS. (for example I worked in space industry and now developing control systems for the aviation)

The responsibility of programmer's decisions and solutions (expressed in code) IS very high and critical. The risks are very high (life of peoples).

Any sane person would choose the most secure means under such conditions.........
BUT NOT PROGRAMMERS!!!! :)
They choose C/C++ family!

Paradox?

NO.

This is more psychological effect of imitation!
Everyone will agree with the requirements of security and reliability. When these requirements concern any OTHER things. But the majority of programmers has the examples of legends and myth how famous and successful systems was created in C/C++. These programmers think that the fact of having "famous" means (language) automatically makes their skills and knowledge much higher and stronger.

We all DO make mistakes. The price of certain mistakes IS very high!
More logically is to choose means which helps not to make such mistakes. It IS VERY desirable to do this at early stages of development. And it is logically to choose pascal-like languages to develop such critical systems. On other hand oberons (as a family of languages) ARE not overwhelmed and ortogonal in means and basic notion. It helps not to "fight" against "language's features and properties" but TO SOLVE THE DOMAIN PROBLEMS.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Dsar on July 07, 2011, 01:50:07 PM
This is more psychological effect of imitation!

It was due to popularity of UNIX, it became more and more popular, then C programmers were looked for jobs. In the accademy professors did their class of operating system laboratories with the UNIX model, then C was required. Every new operating system were started with C because students were used to it, they gained experience in operating system with C.
Today if you want to avoid the overhead of an higher level language or use directly the API of your operating system, you should use the language of the operating system, C.

This is why C is so popular.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Wlad on July 08, 2011, 12:26:59 PM
It was due to popularity of UNIX, it became more and more popular, then C programmers were looked for jobs. In the accademy professors did their class of operating system laboratories with the UNIX model, then C was required. Every new operating system were started with C because students were used to it, they gained experience in operating system with C.
Today if you want to avoid the overhead of an higher level language or use directly the API of your operating system, you should use the language of the operating system, C.
This is why C is so popular.

I know about the disease. I'm talking about the pathologies to which it led, and about the treatment.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: ronin on September 27, 2011, 03:16:14 AM
Go is very similar to Oberon-2,


Well, in fact there are some similarities but they are not many. Similar to Oberon, Go is using var/const/type/func syntax in declarations. Go is using "backwards" variable declarations (that is, type specification follows variable names) - but they are common for many languages in Algol tradition and are recently becoming again fashionable in the language design (see, for instance, Scala). Yes, there are type bound procedures in style of Oberon-2, although in Go they have rather different semantics (and, ironically, in Oberon self this style has been abandoned long ago in favour of object syntax of Active Oberon). There are packages similar to Oberon modules (but nowadays many languages support modules/packages).

What else is similar? The syntax is borrowed mainly from C. Multiple function return values and composite literals are similar to those of Mesa and are completely foreign to Oberon. Variable declarations in Go can be intermixed with statements and there exist short variable declarations without an explicit type specification. There are no variable function arguments. Semantics of arrays is rather different and there is a builtin data type for Unicode strings. Go supports function closures - Oberon doesn't. Polymorphism in Go is implemented using a fully different approach. Approach towards concurrency is also completely different to that of Active Oberon (and Oberon-2 provides no support at all for concurrency at the language level). Go supports a very advanced form of run-time reflection - Oberon has none. Semantics of pointers in Go is very different from that of Oberon and in Go there is the address operator which would be unthinkable in Oberon.

This is just to list a few principal differences. There are, of course, many lesser features that are available in Go but not present in Oberon.

but it has a simpler form of polymorphism (interface based),


This depends on how we define "simple". Go provides embedding for structures and interfaces which in principle can support a far more sophisticated kind of polymorphism than classical single inheritance of Oberon-2 or Active Oberon. In fact, Go's approach towards polymorphism is much closer to that of Zonnon.

it is limited to 1 level of extension (then no type hierarchy) and only to record with type bound procedures (interface types), this allow a safe multiple inheritance that is useful in component oriented programming.


There is no type hierarchy per se but there is embedding of structures and interfaces and the number of levels of embedding is not limited. Furthermore, records with type bound procedures in Go are not interface types and type bound procedures can be associated with any user-defined type, not just with records.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: cfbsoftware on September 27, 2011, 09:31:06 AM
Go supports a very advanced form of run-time reflection - Oberon has none.

For information about the reflection capabilities of Oberon systems refer to the papers published at the University of Linz by Hanspeter Mössenböck and Christoph Steindl at Institut für Systemsoftware at Johannes Kepler Universität Linz:

http://www.ssw.uni-linz.ac.at/Research/Projects/Reflection/


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: ronin on September 27, 2011, 12:14:46 PM
Thank you for information. I did not know that.

However (please correct me if I am wrong), it seems that the features described in these papers are not available in the current official ETH implementations of Oberon - at least, I could find the "Ref" module neither in ETHOberon nor in A2 distribution.

Anyway, I would correct my original statement and say instead that the run-time reflection support in Go is different from that of Oberon.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Dsar on September 27, 2011, 06:38:42 PM
However (please correct me if I am wrong), it seems that the features described in these papers are not available in the current official ETH implementations of Oberon - at least, I could find the "Ref" module neither in ETHOberon nor in A2 distribution.

Oberon is just a base language that is designed to be simple and easy to implement while safe. Of course it is different from Go but its design guideline is from Oberon plus dissertations. Oberon has been extended in a great number of ways, but not all of these extensions were merged in ETHOberon.
Think about Oberon as a birthplace of new programming language features.

For example Szyperski was a Wirth's student and he's one of the prominent authors of the interface based paradigm. He discusses it in his book about component programming where Component Pascal (an Oberon-2 descendant) is a case study.

Robert Griesemer (one of the Go's authors) was a Wirth's student and had written some dissertation about compiler and language extensions.


Title: Re: Comparison of the C and Oberon-2 langauges
Post by: ronin on September 27, 2011, 11:49:08 PM
Oberon is just a base language that is designed to be simple and easy to implement while safe. Of course it is different from Go but its design guideline is from Oberon plus dissertations. Oberon has been extended in a great number of ways, but not all of these extensions were merged in ETHOberon.
Think about Oberon as a birthplace of new programming language features.


Of course, Go has been substantially influenced by Oberon - but Oberon was certainly not the only source of ideas for Go. And, although Oberon has indeed served as a platform for the extensive research in programming language design, Go implements many ideas that originate not from this research. In particular, many features of Go have their foundation in the previous work of Go authors at Bell Labs.

For these reasons I would not say that Go is based on Oberon. There are just too many language features in Go that are not originated from Oberon or related research work and are designed quite differently.



Title: Re: Comparison of the C and Oberon-2 langauges
Post by: Bernhard T. on September 29, 2011, 09:07:28 AM
Go supports a very advanced form of run-time reflection - Oberon has none.
more information about the reflection capabilities of Oberon systems are in Josef Templ's PhD thesis
http://www.inf.ethz.ch/research/disstechreps/theses/show?serial=10655&lang=en (http://www.inf.ethz.ch/research/disstechreps/theses/show?serial=10655&lang=en) and
ftp://ftp.inf.ethz.ch/pub/publications/diss/th10655.ps (ftp://ftp.inf.ethz.ch/pub/publications/diss/th10655.ps)

Reflection (know in the Oberon world as meta programming) in Go is nicely described in http://blog.golang.org/2011/09/laws-of-reflection.html  (http://blog.golang.org/2011/09/laws-of-reflection.html)


Bernhard