5 ms·

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

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-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc https://github.com/oberon-lang/specification/blob/master/The...

shadowofneptune 4y ago
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?
- ZoomZoomZoom 4y ago
  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.
  - shadowofneptune 4y ago
    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.
    - ZoomZoomZoom 4y ago
      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.
    - neutrono 4y ago
      Ada 2012 has expression functions declare function f (i: Integer) returns Integer is ( i * 2 ); x : Integer; begin x := f(21); end;
Rochus 4y ago
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.
- ZoomZoomZoom 4y ago
  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!
  - Rochus 4y ago
    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.
    - ZoomZoomZoom 4y ago
      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.
abecedarius 4y ago
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.)
- ZoomZoomZoom 4y ago
  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.
mikewarot 4y ago
The reason pascal is so easy to work with is that each phase of a program is separate... you have your Units, then types, variables, functions, procedures, and blocks of code all separate making a mish-mash of variable declarations and code would make it quite easy to inadvertently add a new variable similar, but not identical to an existing one, for example. It's good that procedures and functions in pascal are different. One of the big problems with C is that you can leave function results dangling, which works against the clean separation of purposes... procedures have side effects, functions tend not to (but can). One of the most clever things in pascal is assignments := are very hard to confuse with tests for equality =. You're not likely to accidentally confuse them.

shadowofneptune 4y ago

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?

ZoomZoomZoom 4y ago
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.
- shadowofneptune 4y ago
  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.
  - ZoomZoomZoom 4y ago
    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.
  - neutrono 4y ago
    Ada 2012 has expression functions declare function f (i: Integer) returns Integer is ( i * 2 ); x : Integer; begin x := f(21); end;

Rochus 4y ago

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.

ZoomZoomZoom 4y ago
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!
- Rochus 4y ago
  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.
  - ZoomZoomZoom 4y ago
    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.

abecedarius 4y ago

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

ZoomZoomZoom 4y ago
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.

mikewarot 4y ago

The reason pascal is so easy to work with is that each phase of a program is separate... you have your Units, then types, variables, functions, procedures, and blocks of code all separate making a mish-mash of variable declarations and code would make it quite easy to inadvertently add a new variable similar, but not identical to an existing one, for example. It's good that procedures and functions in pascal are different. One of the big problems with C is that you can leave function results dangling, which works against the clean separation of purposes... procedures have side effects, functions tend not to (but can). One of the most clever things in pascal is assignments := are very hard to confuse with tests for equality =. You're not likely to accidentally confuse them.