Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Oberon+ Programming Language

oberon-lang.github.io

Post reply on HN
Print view View original

81–90 of 116 posts

Re: The Oberon+ Programming Language

#81

Post by peterfirefly »

chrisdhal wrote: post #62
iroddis wrote: post #19

Earlier quoted context omitted.

I also find curly braces/parens/etc annoying to type, but recently had my mind blown when I saw a typing tutor program that recommended using left-shift to create those characters. For 35+ years I’ve been using right-shift for things on the right side of the board, cranking my hand and stretching my fingers and complaining about programming languages with poor typing ergonomics. It’s taking forever to break the habit…

When I took typing in high school (mid-80s in the US), on an IBM Selectric, we were taught that way. If the key you wanted to capitalize (or needed the shift for) was on the left hand, you would use the right shift key and vice versa. I didn't know it at the time, but that one semester class was immensely useful for me throughout my career.

I took typing as an elective class in school in Denmark fully expecting it to be useful for decades. And I was right :)

The teacher was a bored and unpleasant secretary and the typewriters were mechanical (and the shift keys so heavy for our pinkies) but it was still the most useful thing I did in school since I learned to read in first grade.

Re: The Oberon+ Programming Language

#82

Post by illiarian »

Jtsummers wrote: post #75
illiarian wrote: post #70

Earlier quoted context omitted.

> That's a one second problem; just give back the value via VAR parameter Ah yes. "Just". And these people accuse other languages of having complex syntaxes or complexities in general. > what do you think one cannot do with the Oberon approach I think it's obvious what I wrote. You can't wrap blocks of code, to do that you need to extract it into a proc that among other things (like actual params passed to it needs a…

> 1. There's nothing wrong with complexity But you don't like the distinction between procedures and functions or different types of loops? Pick a side here.

I don't like people pretending that the language is simple, and commenters berating other languages for being complex while the language they promote and defend has quite a few of complex things and awkward workarounds for no reason.

Re: The Oberon+ Programming Language

#83

Post by illiarian »

Rochus wrote: post #78
illiarian wrote: post #70

Earlier quoted context omitted.

> That's a one second problem; just give back the value via VAR parameter Ah yes. "Just". And these people accuse other languages of having complex syntaxes or complexities in general. > what do you think one cannot do with the Oberon approach I think it's obvious what I wrote. You can't wrap blocks of code, to do that you need to extract it into a proc that among other things (like actual params passed to it needs a…

That's like ranting about wine instead of just ordering a beer ;-)

[flagged]

Re: The Oberon+ Programming Language

#84

Post by badsectoracula »

skybrian wrote: post #79

The justification for putting generic types on modules is interesting. It seems they tried a lot of other variations but couldn't find one that was simple: https://oberon-lang.github.io/2021/07/17/considering-generic...

A few years ago i was also thinking of how Oberon-07 could be extended to support more generic types - mainly so containers, etc, can be more type safe - and pretty much came to the same conclusion that putting types on the modules themselves is by far the simplest approach. Though my approach was a bit different (judging from the code examples) in that parametric modules were more like templates that were specialized during import.

Specifically in Oberon-07 when you have a module "Foo" with a type "Bar" you use it in another module as "Foo.Bar". With parametric modules, a "Foo" module would need to be imported an a specialized form as -e.g.- "Foo" and thus the "Bar" type would need to be used as "Foo.Bar".

In my mind that was both the simplest and smallest change that would allow for the most flexibility (the parameters would be any token acceptable by the language, not just types, meaning that they could be used for constants or even affect other imports).

I did consider implementing a compiler for this, but then i decided that if i'm going to make a compiler for an incompatible language that already practically nobody uses, might as well make my own language that also changes some things i dislike about Oberon-07 (like the uppercase keywords, using # for the inequality string and * to export stuff from modules).

Re: The Oberon+ Programming Language

#85

Post by illiarian »

sedatk wrote: post #56
illiarian wrote: post #24

> During my work with Oberon and systems implemented in Oberon, I kept asking myself what properties the language would need to have so that I could use it for my own systems too, without giving up the goal of making it as simple as possible. From here: https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne... And yet it carries over all of the inanities of the many Oberons before it like: - Four different loop…

> Four different loops I think that having four different loops is better than jumping through four different hoops for different loop styles.

You don't jump through different hoops in most languages [1].

In Oberons you jump through the hoops because only `loop` is allowed to have `exit`, for example. Which is a constraint for the sake of constraints. Repeat is a do/while, but it doesn't have while's elseif statement. Again, because reasons. And so on.

Oberon is nothing but hoops instead of loops.

[1] Go's decision to not include do/while is on par with Oberon's decisions for loops: stupid and unreasaonable.

Re: The Oberon+ Programming Language

#86

Post by illiarian »

flykespice wrote: post #65
illiarian wrote: post #24

> During my work with Oberon and systems implemented in Oberon, I kept asking myself what properties the language would need to have so that I could use it for my own systems too, without giving up the goal of making it as simple as possible. From here: https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne... And yet it carries over all of the inanities of the many Oberons before it like: - Four different loop…

> - useless dinsctintion between procedures and functions? Uh? care to elaborate?

A proc is a function with no return.

A function is a function that returns something.

Oberon+ keeps it's predecessors' idiotic distinction, but takes it one step further: both functions and procedures are decalred with `proc` or `procedure`, functions are `proc`s that have a return type.

And yet:

- procedure calls don't have to specify parameters apparently, but function calls must specify all parameters

- functions cannot be used in Oberon+'s weird exception handling. [1] You do a call with `PCALL(res, P, args)` where res is a variable that will hold the result of the exception if it happened, and P is the procedure. You cannot pass functions (aka procedures which have a return type)

As the spec so wonderfully says [2],

--- start quote ---

There are two kinds of procedures: proper procedures and function procedures. The latter are activated by a function designator as a constituent of an expression and yield a result that is an operand of the expression. Proper procedures are activated by a procedure call. A procedure is a function procedure if its formal parameters specify a result type. Each control path of a function procedure must return a value.

--- end quote ---

[1] https://github.com/oberon-lang/specification/blob/master/The...

[2] https://github.com/oberon-lang/specification/blob/master/The...

Re: The Oberon+ Programming Language

#87

Post by illiarian »

timbit42 wrote: post #40
illiarian wrote: post #24

> During my work with Oberon and systems implemented in Oberon, I kept asking myself what properties the language would need to have so that I could use it for my own systems too, without giving up the goal of making it as simple as possible. From here: https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne... And yet it carries over all of the inanities of the many Oberons before it like: - Four different loop…

I like having a few different loops to keep code more readable. I think there should be two at a minimum for whether the condition is before or after the looped code. I agree with the rest, but the rest of the language is great.

> I like having a few different loops to keep code more readable.

When they have similar semantics, and are not arbitrarily designed.

In Oberon:

- while has an elseif statement. Repeat is a do/while, doesn't have an elseif statement

- loop is allowed an exit. No other loops are allowed to terminate early. And that is literally the only reason loop exists

etc.

Re: The Oberon+ Programming Language

#89

Post by layer8 »

illiarian wrote: post #87
timbit42 wrote: post #40

Earlier quoted context omitted.

I like having a few different loops to keep code more readable. I think there should be two at a minimum for whether the condition is before or after the looped code. I agree with the rest, but the rest of the language is great.

> I like having a few different loops to keep code more readable. When they have similar semantics, and are not arbitrarily designed. In Oberon: - while has an elseif statement. Repeat is a do/while, doesn't have an elseif statement - loop is allowed an exit. No other loops are allowed to terminate early. And that is literally the only reason loop exists etc.

The last point is very likely by design: Only when you see a LOOP do you have to worry about early exits. For the other, more common constructs, you instantly know there won’t be an exit somewhere in the middle, and you can reason about its termination behavior solely based on the loop conditional.

Re: The Oberon+ Programming Language

#90

Post by chadcmulligan »

sedatk wrote: post #55
sfpotter wrote: post #3

I don’t like how verbose Pascal-like languages are. I don’t want to have to type tons of keywords to get anything done. Curly brackets are a big improvement over pairs of “begin” and “end” all over. Makes it hard to see the forest for the trees when skimming some code to figure out what it does. That on its own makes something like this a complete nonstarter for me, leaving aside issues like support, quality of imple…

I'm actually okay with begin and end, but, writing a function's name twice on both the declaration and after the end statement sounds like a HUGE chore. If that's mandatory, it's immediately a mood killer for me about Oberon+.

The idea was you have all the methods on the object available in a small list, and (originally at least) it aided one pass compiling. Delphi continues this and in the IDE you can just go Ctrl-Shift-C in the definition and it will fill out all the method implementation boilerplate automatically, you can then ctrl-click between the implementation and definition. It is useful, say you're in a method body, you ctrl-click to get to the definition, then ctrl-click to the next implementation body you want to code. It means the code is easier to find than in say something like C# or even swift where you can have methods all over the place.
Post reply on HN