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

61–70 of 116 posts

Re: The Oberon+ Programming Language

#61

Post by Rochus »

illiarian wrote: post #60
Rochus wrote: post #52

Earlier quoted context omitted.

> extremely awkward and limited exception handling The design is well-balanced and simple, and you can do essentially everything you can do with Java exceptions, just without complicated syntax constructions; see https://oberon-lang.github.io/2022/05/15/towards-exception-h... for more details.

PCALL(P), P cannot have a return type You cannot handle handle exceptions in a block of code without extracting into a procedure... that cannot return anything. Yeah, I doubt you can "do everything you can do with Java expressions. And of course Oberon's syntax construction is more complex: you need to have an external variable that gets populated, you need to match on three different types etc.

> without extracting into a procedure

That's a one second problem; just give back the value via VAR parameter; the design decision is well justified in the referenced article.

> do everything you can do with Java expressions

"exceptions", not "expressions"; what do you think one cannot do with the Oberon approach?

> you need to have an external variable that gets populated

That's the Pascal philosophy; even an index variable of a FOR loop has to be declared up front in the declaration section; either you like it or not; personally I prefer the in-place declaration approach, but the language would become much more complex and it doesn't make sense to just rebuild C++ or Java.

Re: The Oberon+ Programming Language

#62

Post by chrisdhal »

iroddis wrote: post #19
cardanome wrote: post #11

Earlier quoted context omitted.

For me, "begin" and "end" are actually much more comfortable to type, because I don't have too move my hands for that, I can stay pretty much on the home row. Curly Braces are way too far on the right top to do that and then you either have to use you weak fingers or move quite a bit. (Granted I am touch typing and also using Colemak layout, so rarely ever move my hands. For people that hunt and pek, I believe curly…

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.

Re: The Oberon+ Programming Language

#63

Post by 082349872349872 »

zabzonk wrote: post #16
cardanome wrote: post #11

Earlier quoted context omitted.

For me, "begin" and "end" are actually much more comfortable to type, because I don't have too move my hands for that, I can stay pretty much on the home row. Curly Braces are way too far on the right top to do that and then you either have to use you weak fingers or move quite a bit. (Granted I am touch typing and also using Colemak layout, so rarely ever move my hands. For people that hunt and pek, I believe curly…

> because everyone is already familiar with at least one curly braced language. so, logically, they must have learned how to use {} in the first place, probably with few problems. i have taught god-knows how many people c and c++ (used to be a commercial trainer for those languages) and i can assure you that very, very few, if any, had problems with {}.

A normal swiss keyboard does not even have {}

Re: The Oberon+ Programming Language

#64

Post by mikewarot »

srean wrote: post #8

I was looking for coroutines. Modula had them, but I couldnt find them here. Just a note I mean coroutines, not preemptive threads. Here is how it looks like in Modula-2. https://www.modula2.org/reference/isomodules/isomodule.php?m...

I did coroutines under Turbo Pascal wayyyyy back in the 1980s[1]. It's really just a matter of copying the stack and some book-keeping.

Free Pascal has threads.

[1] https://www.pcorner.com/list/PASCAL/TASKER4.ZIP/TASKER.PAS/

Re: The Oberon+ Programming Language

#65

Post by flykespice »

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?

Re: The Oberon+ Programming Language

#66

Post by sitkack »

I have so much respect for the design aesthetic of Wirth, but I don't like OO. What would a Wirthian FP language look like?

I asked the oracle

> Wirthian functional programming language would emphasize simplicity, elegance, and readability while incorporating functional programming concepts such as immutability, first-class functions, and recursion. It would provide strong typing, modularity, and a minimal standard library, staying true to Wirth's design principles.

It also tells me that Elm, Idris, PureScript, F* and Gleam share many of these same qualities.

The thing that I didn't appreciate about the design of Wirthian languages earlier is that he really focused on mechanical and compiler-writer sympathy, designing languages that were fast and easy to compile.

I just discovered Pascal-S, it is like Cool or ChocoPy, a subset language designed for compiler students to implement.

https://static.aminer.org/pdf/PDF/000/530/289/pascal_s_a_sub...

Re: The Oberon+ Programming Language

#67

Post by Rochus »

olah_1 wrote: post #59

I really see how Nim was influenced by Oberon now. Will Oberon+ actually compete with Nim in some ways?

That's like competing apples with oranges; some people like the former, some the latter, some both; if you prefer a Python like syntax an a much more complex language, then Nim is your choice.

Re: The Oberon+ Programming Language

#68

Post by pjmlp »

sitkack wrote: post #66

I have so much respect for the design aesthetic of Wirth, but I don't like OO. What would a Wirthian FP language look like? I asked the oracle > Wirthian functional programming language would emphasize simplicity, elegance, and readability while incorporating functional programming concepts such as immutability, first-class functions, and recursion. It would provide strong typing, modularity, and a minimal standard l…

Easy, Standard ML.

Re: The Oberon+ Programming Language

#70

Post by illiarian »

Rochus wrote: post #61
illiarian wrote: post #60

Earlier quoted context omitted.

PCALL(P), P cannot have a return type You cannot handle handle exceptions in a block of code without extracting into a procedure... that cannot return anything. Yeah, I doubt you can "do everything you can do with Java expressions. And of course Oberon's syntax construction is more complex: you need to have an external variable that gets populated, you need to match on three different types etc.

> without extracting into a procedure That's a one second problem; just give back the value via VAR parameter; the design decision is well justified in the referenced article. > do everything you can do with Java expressions "exceptions", not "expressions"; what do you think one cannot do with the Oberon approach? > you need to have an external variable that gets populated That's the Pascal philosophy; even an index…

> 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 an additional parameter) needs an awkward `out` parameter etc.

Is the result sorta kinda equivalent to Javas? If you squint hard enough, yes

> That's the Pascal philosophy; even an index variable of a FOR loop has to be declared up front in the declaration section

I know the Pascal philosophy: create awkward verbose languages with useless constraints while claiming it's for the sake of simplicity.

> but the language would become much more complex and it doesn't make sense to just rebuild C++ or Java.

1. There's nothing wrong with complexity

2. There a multiple languages that don't have Pascal/Oberon's constraints, decisions, and awkward workarounds which are neither Java nor C++

Post reply on HN