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

71–80 of 116 posts

Re: The Oberon+ Programming Language

#71

Post by pjmlp »

zabzonk wrote: post #10
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…

apart from that (which i agree with) is that in most pascal-like languages you have to define variables at the top of a function, and their scope is the whole function. both c (nowadays, define at top of a {} scope) and c++ (define anywhere inside a function) do much better which, together with irritating long names, may explain why c and c++ won out over the pascal-likes. speaking as an ex professional delphi progra…

Delphi supports local variable declarations for quite some years now, and Ada does it since its introduction in 1983.

Re: The Oberon+ Programming Language

#72

Post by pjmlp »

mpweiher wrote: post #37
pjmlp wrote: post #9

Earlier quoted context omitted.

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.

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

Re: The Oberon+ Programming Language

#74

Post by pjmlp »

carapace wrote: post #22

The whole Oberon system is great fun. https://people.inf.ethz.ch/wirth/ProjectOberon/index.html It's a single-user workstation, developed from the CPU on up, compiler & language, OS with unique GUI, all documented in a book, and you can run it online in a browser via a JS emulator for the CPU: http://schierlm.github.io/OberonEmulator/ People used it at ETH as their main system to run the University!

Note that the evolution of it was Active Oberon and AOS operating system, much more closer to modern languages and OS stacks.

Re: The Oberon+ Programming Language

#75

Post by Jtsummers »

illiarian wrote: post #70
Rochus wrote: post #61

Earlier quoted context omitted.

> without extracting into a procedure That's a one second problem; just give back the value via VAR parameter; the design decision is well justified in the referenced article. > do everything you can do with Java expressions "exceptions", not "expressions"; what do you think one cannot do with the Oberon approach? > you need to have an external variable that gets populated That's the Pascal philosophy; even an index…

> That's a one second problem; just give back the value via VAR parameter Ah yes. "Just". And these people accuse other languages of having complex syntaxes or complexities in general. > what do you think one cannot do with the Oberon approach I think it's obvious what I wrote. You can't wrap blocks of code, to do that you need to extract it into a proc that among other things (like actual params passed to it needs a…

> 1. There's nothing wrong with complexity

But you don't like the distinction between procedures and functions or different types of loops? Pick a side here.

Re: The Oberon+ Programming Language

#77

Post by mpweiher »

pjmlp wrote: post #72
mpweiher wrote: post #37

Earlier quoted context omitted.

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.

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

EXACTLY.

Re: The Oberon+ Programming Language

#78

Post by Rochus »

illiarian wrote: post #70
Rochus wrote: post #61

Earlier quoted context omitted.

> without extracting into a procedure That's a one second problem; just give back the value via VAR parameter; the design decision is well justified in the referenced article. > do everything you can do with Java expressions "exceptions", not "expressions"; what do you think one cannot do with the Oberon approach? > you need to have an external variable that gets populated That's the Pascal philosophy; even an index…

> That's a one second problem; just give back the value via VAR parameter Ah yes. "Just". And these people accuse other languages of having complex syntaxes or complexities in general. > what do you think one cannot do with the Oberon approach I think it's obvious what I wrote. You can't wrap blocks of code, to do that you need to extract it into a proc that among other things (like actual params passed to it needs a…

That's like ranting about wine instead of just ordering a beer ;-)

Re: The Oberon+ Programming Language

#80

Post by rightbyte »

stefncb wrote: post #51
zabzonk wrote: post #28

Earlier quoted context omitted.

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.

Isn't the first row both the declaration and definition is this case?

(I assume f() is a call.)

Post reply on HN