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

31–40 of 116 posts

Re: The Oberon+ Programming Language

#31

Post by ghodith »

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…

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.

Re: The Oberon+ Programming Language

#33

Post by canadianfella »

pjmlp wrote: post #9
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…

Code is read much more times than written, and hieroglyphs don't help.

[dead]

Re: The Oberon+ Programming Language

#34

Post by bluedino »

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…

That seems like it would be a simple thing to change.

Re: The Oberon+ Programming Language

#36

Post by hota_mazi »

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…

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

Re: The Oberon+ Programming Language

#37

Post by mpweiher »

pjmlp wrote: post #9
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…

Code is read much more times than written, and hieroglyphs don't help.

Actually they do, particularly for reading, as they separate language boilerplate from actual content.

For example, to call a function, we just use the name of the function and parentheses, rather than saying "call". This is useful, because it allows the reader to focus on what is of interest.

Re: The Oberon+ Programming Language

#38

Post by ZoomZoomZoom »

shadowofneptune wrote: post #27
ZoomZoomZoom wrote: post #18

Oberon and Oberon+ are very interesting and are certainly a step forward from Pascal. Wish Oberon+ had moved forward a few more steps, like making everything an expression, for example, or more lax variable declaration rules (which probably require scoping rules changes). If only the FPC compiler supported it and allowed combining units in Oberon with Pascal ones in one project! The language specs: https://github.com…

You appear to be familiar with Pascal, so I am surprised you find the statement-heavy approach an issue. What would be the benefit of making this change?

My Pascal days are far in the past, but I recently used Lazarus to quickly prototype a simple GUI app (not many tools beat it yet for the task) and was a bit annoyed by the syntax.

Relying on expressions greatly reduces the need for transitory variables, and in case of Pascal, where you can't just declare them as you go, this would be especially important to clear the code from ops inessential to the task at hand.

`let foo = if (bar > 0) then bar else frobnicate() end` would be nice to have, as well as begin-end blocks with their own scope (can't fathom the reasons it's not allowed) and evaluated to the last statement. Rust and Nim get it mostly right.

Re: The Oberon+ Programming Language

#39

Post by Rochus »

ZoomZoomZoom wrote: post #18

Oberon and Oberon+ are very interesting and are certainly a step forward from Pascal. Wish Oberon+ had moved forward a few more steps, like making everything an expression, for example, or more lax variable declaration rules (which probably require scoping rules changes). If only the FPC compiler supported it and allowed combining units in Oberon with Pascal ones in one project! The language specs: https://github.com…

Oberon+ is not set in stone; if there are good ideas that fit into the concept of simplicity and add significant value, they should be considered. From my point of view, however, one should rather avoid proliferation, as one can observe it with e.g. C#, C++ or TypeScript.

Re: The Oberon+ Programming Language

#40

Post by timbit42 »

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.

Post reply on HN