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

91–100 of 116 posts

Re: The Oberon+ Programming Language

#91

Post by neutrono »

shadowofneptune wrote: post #45
ZoomZoomZoom wrote: post #38

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.

Ada 2012 has expression functions

    declare
        function f (i: Integer) returns Integer is ( i * 2 );
         x : Integer;
    begin
        x := f(21);
    end;

Re: The Oberon+ Programming Language

#93

Post by imtringued »

Seeing pascal syntax for the first time, I was confused why it looks so overly verbose, like VHDL. It turns out that it was Pascal that rubbed off onto VHDL. However, this makes me think that pascal style syntax is a very poor choice for software development.

Re: The Oberon+ Programming Language

#94

Post by imtringued »

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.

The problem is some games use shift for sprinting so left shift plus wasd becomes muscle memory.

Re: The Oberon+ Programming Language

#96

Post by H4ZB7 »

looks like an absolutely uninteresting boomer language, by the fact that it just shows standard imperative stuff followed by "wow it supports unicode, we are up to date"! (which is a misfeature, btw, i like being able to audit my code before running it (not that thats possible in the current mess of misconceived computers but yeah still it would be good to start doing things in the right direction).

its interesting that there is supposedly an os in oberon that actual uses the same language for the shell or something or the kernel is written in it or something like that but this page just makes me think its not worth looking into after all

Re: The Oberon+ Programming Language

#97

Post by Jtsummers »

rightbyte wrote: post #80
stefncb wrote: post #51

Earlier quoted context omitted.

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.

Isn't the first row both the declaration and definition is this case? (I assume f() is a call.)

C (and C++) considers the declaration to be separate from the definition, though you can combine them. The declaration is the name + type, definition provides a value. The example code is meant to illustrate separate declaration and definition with some code (the call to `f`) between the two.

If you try to use `x` before it is defined (the assignment) your compiler should give you a warning, at least. If it doesn't, find a new compiler.

Re: The Oberon+ Programming Language

#98

Post by LegionMammal978 »

Jtsummers wrote: post #97
rightbyte wrote: post #80

Earlier quoted context omitted.

Isn't the first row both the declaration and definition is this case? (I assume f() is a call.)

C (and C++) considers the declaration to be separate from the definition, though you can combine them. The declaration is the name + type, definition provides a value. The example code is meant to illustrate separate declaration and definition with some code (the call to `f`) between the two. If you try to use `x` before it is defined (the assignment) your compiler should give you a warning, at least. If it doesn't,…

For block-scope declarations, it's not the definition but the initialization that you're thinking of. At least in C, every block-scope variable declaration is a definition:

> A definition of an identifier is a declaration for that identifier that:

> — for an object, causes storage to be reserved for that object; [...]

But initialization (in C) does not occur for block-scope objects without the optional initializer.

Re: The Oberon+ Programming Language

#99

Post by pjmlp »

mpweiher wrote: post #77
pjmlp wrote: post #72

Earlier quoted context omitted.

Other than BASIC, COBOL, Assembly and a few others, call isn't a thing.

EXACTLY.

Exactly what? I wasn't thinking about CALL in regards to hieroglyphs, rather the set of language design ideas out of Bell Labs and its descendants, that turn a line full of symbols into valid code.

Re: The Oberon+ Programming Language

#100

Post by mikewarot »

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…

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.

Post reply on HN