The Oberon+ Programming Language • Hacker News Board

Re: The Oberon+ Programming Language

#51

Post by stefncb » Sat, Mar 18, 2023, 4:51 PM UTC

zabzonk wrote: post #28

unwind wrote: post #26

Earlier quoted context omitted.

C is declare anywhere and has been for a looong time (C99).

sorry, my bad, i don't do any c programming these days. but to be pedantic, i think you mean define rather than declare, though of course you can also declare things at different scopes.

No, I think they do mean declare. In C89 you can define a variable anywhere, like so:

    int x;
    f();
    x=3;

The improvement was allowing declarations anywhere.

Re: The Oberon+ Programming Language

#52

Post by Rochus » Sat, Mar 18, 2023, 4:55 PM UTC

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…

> 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.

Re: The Oberon+ Programming Language

#53

Post by ZoomZoomZoom » Sat, Mar 18, 2023, 5:01 PM UTC

Rochus wrote: post #49

ZoomZoomZoom wrote: post #47

Earlier quoted context omitted.

It's very nice to hear and I agree that languages have to move slowly, considering each move. On the other hand, when the user base is still slim you have much more freedom to be a bit more adventurous, add and deprecate things more freely. Some of the features can also be optional and available for those not afraid to try unstable things. It's a bit interesting that I initially stumbled on Oberon+ while searching fo…

Thanks. > when the user base is still slim you have much more freedom to be a bit more adventurous, add and deprecate things more freely When designing a language, it's hard to get rid of the initial sins, so if in doubt, leave a feature out, so you don't regret it later; once enough people are involved with the language and writing code with it, any change that isn't backwards compatible is an imposition on everyone…

I agree completely.

Playing the devil's advocate: On the other hand, making a whole new language is rarely a way to GTD now, it's usually an investment in the future. For surviving into that future the language usually needs the involvement of the community. And for that one has to consider what new/different/radical things does the language offer to the public to hook them on. May be it's OK to sin a little and get straight closer to v1.0? Of course, a few will hurt but they'll live.

Re: The Oberon+ Programming Language

#54

Post by open-source-ux » Sat, Mar 18, 2023, 5:12 PM UTC

cardanome wrote: post #11

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…

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…

Ruby and Julia use the 'end' keyword in code blocks. A bit less noise compared to Pascal's 'begin' and 'end' syntax.

Re: The Oberon+ Programming Language

#55

Post by sedatk » Sat, Mar 18, 2023, 5:21 PM UTC

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+.

Re: The Oberon+ Programming Language

#56

Post by sedatk » Sat, Mar 18, 2023, 5:26 PM UTC

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.

Re: The Oberon+ Programming Language

#57

Post by vanjajaja1 » Sat, Mar 18, 2023, 5:37 PM UTC

ghodith wrote: post #31

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…

Interest, in contrast I have the bad habit of never using right shift, which is definitely inefficient when typing capital A for example. I've not been very successful changing this habit.

Wow I'm analyzing some motor patterns I wasn't even aware of...

I think playing video games has made LeftShift + letter a really easy combo, right shift feels quite uncomfortable, but I did find that I use it when typing !

Re: The Oberon+ Programming Language

#58

Post by cardanome » Sat, Mar 18, 2023, 5:46 PM UTC

hota_mazi wrote: post #36

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…

> For me, "begin" and "end" are actually much more comfortable to type, Type, maybe, but they are visual noise when you read code. BEGIN and END are also not as easy to match with editors/IDE's as pairs of symbols.

There is no difference in noise for me between curly braces or keywords because my brain parses both as a single token. I don't process "e"-"n"-"d", it is just one thing "end", same as a curly brace is.

Of course some people can't read words by shape and instead have to sound out the individual letters every time, so I guess it can be more annoying for some people.

And I don't mean to be patronizing, I actually have the opposite problem. I am faster at parsing whole words than symbols which is why I really struggle with modern UI that solely relies on icons. It drives me mad.

Re: The Oberon+ Programming Language

#59

Post by olah_1 » Sat, Mar 18, 2023, 6:17 PM UTC

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

Re: The Oberon+ Programming Language

#60

Post by illiarian » Sat, Mar 18, 2023, 6:19 PM UTC

Rochus wrote: post #52

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…

> 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.