Oberon Community Platform Forum
December 07, 2019, 08:12:38 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: 1 2 [3]
  Print  
Author Topic: Comparison of the C and Oberon-2 langauges  (Read 69528 times)
Wlad
Newbie
*
Posts: 14


« Reply #30 on: July 07, 2011, 09:43:14 AM »

What about Go, the Google's recently released language?
http://golang.org/
Opinions?
Go = Google's Oberon  Smiley

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!!!! Smiley
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.
Logged
Dsar
Newbie
*
Posts: 40


« Reply #31 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.
Logged
Wlad
Newbie
*
Posts: 14


« Reply #32 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.
Logged
ronin
Newbie
*
Posts: 3



« Reply #33 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.
« Last Edit: September 27, 2011, 09:29:44 AM by ronin » Logged
cfbsoftware
Full Member
***
Posts: 107


WWW
« Reply #34 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/
Logged

Chris Burrows
Astrobe v7.0 (Feb 2019): Oberon for ARM Cortex-M3, M4 and M7 Microcontrollers
http://www.astrobe.com
ronin
Newbie
*
Posts: 3



« Reply #35 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.
« Last Edit: September 27, 2011, 12:20:15 PM by ronin » Logged
Dsar
Newbie
*
Posts: 40


« Reply #36 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.
Logged
ronin
Newbie
*
Posts: 3



« Reply #37 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.

« Last Edit: September 28, 2011, 09:29:43 AM by ronin » Logged
Bernhard T.
Administrator
Full Member
*****
Posts: 164


« Reply #38 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 and
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


Bernhard
« Last Edit: September 29, 2011, 09:23:32 AM by Bernhard T. » Logged
Pages: 1 2 [3]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!