Live data from Hacker News

The Oberon+ Programming Language

oberon-lang.github.io

41–50 of 116 posts

Re: The Oberon+ Programming Language

#41

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…

I guess you could make changes like that while keeping backward compatibility with older Oberon, but that's probably kind of a pain, no? I agree that such changes would make Oberon more to my taste.

Maybe what we really want would be semantically close to Oberon+ but abandoning Wirth's surface syntax. (You could still respect the design discipline of allowing a simple fast compiler.)

Re: The Oberon+ Programming Language

#42
Related:

Show HN: New Oberon+ to C99 transpiler for near native performance - https://news.ycombinator.com/item?id=29591993 - Dec 2021 (2 comments)

The Oberon+ Programming Language - https://news.ycombinator.com/item?id=27864582 - July 2021 (4 comments)

The new Oberon+ programming language – modern simplicity - https://news.ycombinator.com/item?id=27855767 - July 2021 (4 comments)

Others? (Lots of original Oberon, of course)

Re: The Oberon+ Programming Language

#43
First time I read about Oberon was when I saw Ginger Bill presenting Odin language and visited his website to learn more. It was when I visited its FAQ [1] that saw the major influences that inspired him to design a new language and one of them was Oberon-2 which is an extension to Oberon itself.

Fascinating stuff!

[1] https://odin-lang.org/docs/faq/

Re: The Oberon+ Programming Language

#45

Earlier quoted context omitted.

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. `l…

This does feel then like a matter of taste. While Pascal's predecessor language Algol did allow syntax like that, adding it back to Pascal-like languages would make it into a different kind of language.

Re: The Oberon+ Programming Language

#46

First time I read about Oberon was when I saw Ginger Bill presenting Odin language and visited his website to learn more. It was when I visited its FAQ [1] that saw the major influences that inspired him to design a new language and one of them was Oberon-2 which is an extension to Oberon itself. Fascinating stuff! [1] https://odin-lang.org/docs/faq/

Yea I was going to comment and say if anyone is interested in a modern language the follows in the tradition of Pascal/Oberon they should look into Odin

Re: The Oberon+ Programming Language

#47
post #39

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.

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 for something typed which compiles to straight Lua and was surprised seeing the scope of the project.

In any case, I wish you all the best in the development of the language!

Re: The Oberon+ Programming Language

#48

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…

I guess you could make changes like that while keeping backward compatibility with older Oberon, but that's probably kind of a pain, no? I agree that such changes would make Oberon more to my taste. Maybe what we really want would be semantically close to Oberon+ but abandoning Wirth's surface syntax. (You could still respect the design discipline of allowing a simple fast compiler.)

I'm fine with Nim for my limited set of problems, but it's its own thing and not exactly in the family. Ideally, it would be something supported by the FPC compiler.

Re: The Oberon+ Programming Language

#49
post #39

Earlier quoted context omitted.

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.

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

Re: The Oberon+ Programming Language

#50

Earlier quoted context omitted.

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. `l…

This does feel then like a matter of taste. While Pascal's predecessor language Algol did allow syntax like that, adding it back to Pascal-like languages would make it into a different kind of language.

What makes the language what it is is rather a philosophical question. I don't think I agree with you on this specific point.

I'm not against evolution, especially when you have others to test the feature extensively for years. But I'm not a language designer and my opinion on the matter holds no weight.

Post reply on HN