Oberon in Python, ala Pyrex but instant compile?

Janto Dreijer janto_d at hotmail.com
Sat May 25 12:45:35 EDT 2002


Kragen Sitaker <kragen at pobox.com> wrote in message news:<83k7ptkt6h.fsf at panacea.canonical.org>...
> janto_d at hotmail.com (Janto Dreijer) writes:
> > I could keep on ranting (just ask) about oberon's flaws
> 
> I'd be delighted to hear about Oberon's flaws; could you elaborate?  I
> have no practical experience with the thing, only experience reading
> the "Project Oberon" book, which I find fascinating.

I have already written a fairly large document discussing all of
Oberon's faults, but I don't feel comfortable publishing it yet as I'm
planning to submit it to our CS department to try and persuade them to
change their primary language to "something else". <wink wink nudge
nudge>

Maybe I'll post something on it in the future. Probably on
comp.lang.oberon :-) But in the meantime here's a few things that
spring to mind.

The Math library has no power function.

The documenation available is of a very low quality which I think is
mostly due to weak translation. It also has a lot of blindingly
obvious errors in it. (A classic example of its silliness is where
they advise the programmer to use INC(i) instead of i:=i+1 because
"some systems are able to generate more effective code"! How much
faster will my code run if I do this?!)

Now it's the object orientation that really irritates me. I'll
demonstrate it by rewriting the following Python code in Oberon:

python
-------
class Obj:
  def __init__(self, a):
    self.a = a
  def some_string_value(self):
    return str(self.a)
if __name__ == "__main__":
  obj = Obj(3)
  print obj.some_string_value()

oberon
------
MODULE Test;

IMPORT
  Strings, Out;
TYPE
  String = ARRAY 1024 OF CHAR; (* create own string type *)
  Obj = POINTER TO TObj;
  TObj = RECORD (* think of it as a class *)
    SomeStringValue : PROCEDURE(obj : Obj) : String;
    a : INTEGER;
  END;

PROCEDURE CreateObj(a : INTEGER) : Obj;
VAR
  obj : Obj;
BEGIN
  NEW(obj); (* create in memory *)
  obj.a := a;
  obj.SomeStringValue := GetA; (* bind handler *)
  RETURN obj;
END CreateObj;

PROCEDURE GetA(obj : Obj) : String;
VAR
  result : String;
BEGIN
  Strings.IntToStr(obj.a, result);
  RETURN result;
END GetA;

PROCEDURE Run*;
VAR
  obj : Obj;
BEGIN
  obj := CreateObj(3);
  Out.String(obj.SomeStringValue(obj));
END Run;

END Test.

oberon is case sensitive, so keywords have to be in uppercase. The
reasoning behind this seems to be readability. It looks like syntax
coloring never reached that part of the world.

I don't feel like commenting on the above code as it took me half an
hour to write and I just don't have any enthusiasm left. I'm not sure
I need to explicitly pass the object to its methods but i can't find
another way to do it other than "obj.SomeStringValue(obj)"

Probably the most important thing is that coding in oberon just isn't
fun. I keep feeling like I'm coding myself into dead-ends - constantly
waiting for the language to throw something at me that'll force a
redesign.

a small example:

TYPE String = ARRAY 1024 OF CHAR;
PROCEDURE f() : String;
BEGIN
    RETURN "abc";
END f;

This is one of the classic cases where the compiler crashes. One needs
to create a temp variable to deal with this:

PROCEDURE f() : String;
VAR String result;
BEGIN
    result := "abc";
    RETURN result;
END f;

I feel kinda suicidal right now, so I think I'll just post this and go
space out for a while.



More information about the Python-list mailing list