hckrnws

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

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!

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.

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.

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.

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;

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.

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.

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.

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)

I thought the background context by the author was interesting to read:

https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne...

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 implementation, uptake, etc.

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 braces are easier to type.)

I don't think there is much practical difference between curly-braced vs keyboard based syntax. Both are similarly easy to read, especially with syntax highlighting. After a while, your brain will automatically parse "begin" and "end" as a symbol, same as curly braces, so you won't notice the "noise".

As for the pros and cons:

Pascal style syntax is slightly better for new people learning to program. Learning how to even type those weird curly braces and understanding the difference between all the styles of braces just takes focus away from actually learning how to program.

Curly braced C-style syntax is better for people that already know how to program because everyone is already familiar with at least one curly braced language.

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, but so far it feels so much better.

When I took typing in high school (mid-80s in the US), on an IBM Selectric, we were taught that way. If the key you wanted to capitalize (or needed the shift for) was on the left hand, you would use the right shift key and vice versa.

I didn't know it at the time, but that one semester class was immensely useful for me throughout my career.

I took typing as an elective class in school in Denmark fully expecting it to be useful for decades. And I was right :)

The teacher was a bored and unpleasant secretary and the typewriters were mechanical (and the shift keys so heavy for our pinkies) but it was still the most useful thing I did in school since I learned to read in first grade.

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.

Wow I'm analyzing some motor patterns I wasn't even aware of...

I think playing video games has made LeftShift + letter a really easy combo, right shift feels quite uncomfortable, but I did find that I use it when typing !

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

Ruby and Julia use the 'end' keyword in code blocks. A bit less noise compared to Pascal's 'begin' and 'end' syntax.

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

There is no difference in noise for me between curly braces or keywords because my brain parses both as a single token. I don't process "e"-"n"-"d", it is just one thing "end", same as a curly brace is.

Of course some people can't read words by shape and instead have to sound out the individual letters every time, so I guess it can be more annoying for some people.

And I don't mean to be patronizing, I actually have the opposite problem. I am faster at parsing whole words than symbols which is why I really struggle with modern UI that solely relies on icons. It drives me mad.

> because everyone is already familiar with at least one curly braced language.

so, logically, they must have learned how to use {} in the first place, probably with few problems.

i have taught god-knows how many people c and c++ (used to be a commercial trainer for those languages) and i can assure you that very, very few, if any, had problems with {}.

A normal swiss keyboard does not even have {}

If you've dismissed a whole host of languages just at a glance, you're missing out. Lua has little in common with Pascal, which has little in common with Fortran, etc. As a sister post to this says, you see them more as tokens once you are familiar. Emboldening or coloring keywords also helps, as for any language.

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

Ad hoc hieroglyphs that change from project to project indeed make it harder to read code. But as long as they are the core part of the language and they represent orthogonal features (ie they don’t bloat the number of ways you can represent identical solutions), I don’t see why it should be a problem. On the contrary, putting less visual weight on tokens with smaller information content looks natural.

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.

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.

[dead]

so, you recommend cobol?

Well, it is cloud ready.

https://www.microfocus.com/en-us/products/visual-cobol/overv...

what has this to do with "hieroglyphs"?

It doesn't have them.

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 programmer here - i have written lots of object pascal code, and have no desire to write any more.

C is declare anywhere and has been for a looong time (C99).

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;

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.

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.

Okay, that's somewhat confusing. So a declaration is when the identifier enters the scope, and a definition is for a variable specifically. So a declaration that's not a definition could be a forward declaration for a function, or a typedef.

Yes, or the declaration of an extern variable.

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

Pascal required BEGIN and END for every block, such as: IF <cond> THEN BEGIN <code> END ELSE BEGIN <code> END END, but Modula-2 and Oberon don't require BEGIN or END around code blocks: IF <cond> THEN <code> ELSE <code> END. BEGIN is now only used to denote the end of variable declaration and the beginning of the code. You can see this if you click the posted link. I think it was a valid complaint in Pascal, but not in it's derived languages.

I'm actually okay with begin and end, but, writing a function's name twice on both the declaration and after the end statement sounds like a HUGE chore. If that's mandatory, it's immediately a mood killer for me about Oberon+.

The idea was you have all the methods on the object available in a small list, and (originally at least) it aided one pass compiling. Delphi continues this and in the IDE you can just go Ctrl-Shift-C in the definition and it will fill out all the method implementation boilerplate automatically, you can then ctrl-click between the implementation and definition. It is useful, say you're in a method body, you ctrl-click to get to the definition, then ctrl-click to the next implementation body you want to code. It means the code is easier to find than in say something like C# or even swift where you can have methods all over the place.

No I meant this:

    proc Something()
    begin
      ...
    end Something

oh ok, yeah that's not pretty

I think it's less about typing them and more about reading them. Curly braces reduce the number of keywords in the language (unless the alternative is indentation sensitivity like in Python or Haskell). This means that if I see a word, it is easier to infer if it is a variable name or if it does something structural.

How about a treesitter-based editor extension that converts between begin/end and {/}, as if they were ligatures? Actually this might not even need treesitter.

> How about a treesitter-based editor extension that converts between begin/end and {/}, as if they were ligatures? Actually this might not even need treesitter.

See emacs prettify-symbols-mode (https://emacs.stackexchange.com/questions/46529/configuring-...)

I'd rather have systematic "language skinning", where different flavors (begin and end versus { and }) are isomorphisms of each other so one's tooling can fluidly translate between both forms.

Rochus is almost kind of doing this with Oberon+ versus Wirthian Oberon already, but it would be nice to go further.

> How about a treesitter-based editor extension that converts between begin/end and {/}, as if they were ligatures? Actually this might not even need treesitter.

Neovim has the conceal feature, which can convert Treesitter nodes into a single symbol, but not the other way around unfortunately.

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

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!

I studied CS at ETH from 2001 to 2006. Oberon was the main language used for teaching our introductory CS courses IIRC. Fun times. :-)

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

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

For anyone wondering about the funky asterisk against some of those identifiers, the docs say:

    An identifier declared in a module block may be followed by an export mark (* or -) in its declaration to indicate that it is exported

This is from normal traditional Oberon, however.

The justification for putting generic types on modules is interesting. It seems they tried a lot of other variations but couldn't find one that was simple:

https://oberon-lang.github.io/2021/07/17/considering-generic...

A few years ago i was also thinking of how Oberon-07 could be extended to support more generic types - mainly so containers, etc, can be more type safe - and pretty much came to the same conclusion that putting types on the modules themselves is by far the simplest approach. Though my approach was a bit different (judging from the code examples) in that parametric modules were more like templates that were specialized during import.

Specifically in Oberon-07 when you have a module "Foo" with a type "Bar" you use it in another module as "Foo.Bar". With parametric modules, a "Foo<T>" module would need to be imported an a specialized form as -e.g.- "Foo<INTEGER>" and thus the "Bar" type would need to be used as "Foo<INTEGER>.Bar".

In my mind that was both the simplest and smallest change that would allow for the most flexibility (the parameters would be any token acceptable by the language, not just types, meaning that they could be used for constants or even affect other imports).

I did consider implementing a compiler for this, but then i decided that if i'm going to make a compiler for an incompatible language that already practically nobody uses, might as well make my own language that also changes some things i dislike about Oberon-07 (like the uppercase keywords, using # for the inequality string and * to export stuff from modules).

Besides that, Active Oberon already supports generics in a way similar to Modula-3.

The original Active Oberon (Reali, 2004) didn't have generics; you probably mean the ETH Oberon (2019) Language Report draft by Felix Friedrich; I don't think it's implemented somewhere.

Naturally I mean the latest version.

As for it being implemented, I was assuming that by now it already was, given that it is still being actively developed.

The language proposed by Friedrich is actually a different one than Active Oberon, even if the latter is mentioned as a basis.

I didn't find a compiler yet which implements the proposed templates; if you know one please post a link.

I was looking for coroutines. Modula had them, but I couldnt find them here. Just a note I mean coroutines, not preemptive threads.

Here is how it looks like in Modula-2.

https://www.modula2.org/reference/isomodules/isomodule.php?m...

I did coroutines under Turbo Pascal wayyyyy back in the 1980s[1]. It's really just a matter of copying the stack and some book-keeping.

Free Pascal has threads.

[1] https://www.pcorner.com/list/PASCAL/TASKER4.ZIP/TASKER.PAS/

I have so much respect for the design aesthetic of Wirth, but I don't like OO. What would a Wirthian FP language look like?

I asked the oracle

> Wirthian functional programming language would emphasize simplicity, elegance, and readability while incorporating functional programming concepts such as immutability, first-class functions, and recursion. It would provide strong typing, modularity, and a minimal standard library, staying true to Wirth's design principles.

It also tells me that Elm, Idris, PureScript, F* and Gleam share many of these same qualities.

The thing that I didn't appreciate about the design of Wirthian languages earlier is that he really focused on mechanical and compiler-writer sympathy, designing languages that were fast and easy to compile.

I just discovered Pascal-S, it is like Cool or ChocoPy, a subset language designed for compiler students to implement.

https://static.aminer.org/pdf/PDF/000/530/289/pascal_s_a_sub...

Easy, Standard ML.

If you want a scalable GC:

- Don't throw everything into a single global heap

- Don't rely on stop the world GC

- Support actors and zero-copy message passing

.. in other words, be like Pony's ORCA.

Any relation to the Oberon operating system?

https://en.wikipedia.org/wiki/Oberon_(operating_system)

There is a version of the Oberon System compatible with the Oberon+ toolchain and IDE, see https://github.com/rochus-keller/OberonSystem

Only the language part of it

> 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 loops (while, for, repeat, and loop)

- Useless distinction between procedures and functions

- Randomly selected ASCII symbols to show what is exported and/or read-only

- extremely awkward and limited exception handling (you have to call a procedure that cannot hav a return type using a built-in pcall procedure that writes exception info into a variable you pass into it)

and so on.

All of Oberons are just walking around in circles re-implementing the same weird ideas again, and agian, and agian, and again.

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.

> I like having a few different loops to keep code more readable.

When they have similar semantics, and are not arbitrarily designed.

In Oberon:

- while has an elseif statement. Repeat is a do/while, doesn't have an elseif statement

- loop is allowed an exit. No other loops are allowed to terminate early. And that is literally the only reason loop exists

etc.

The last point is very likely by design: Only when you see a LOOP do you have to worry about early exits. For the other, more common constructs, you instantly know there won’t be an exit somewhere in the middle, and you can reason about its termination behavior solely based on the loop conditional.

It's not by design, not really.

Early Pascal/Modula/Oberons were extremely anal about loops (of any kind) never having any early exits, ever.

Then they ran into the real world.

So each consecutive version of Oberon either added early returns or removed early returns. Sometimes like clockwork. And also added/removed other types of loops in pursuit of some unspecified ideal of simplicity.

You can see part of that history in the overview of differences: https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w...

So it's a self-imposed constraint that makes very little sense.

> extremely awkward and limited exception handling

The design is well-balanced and simple, and you can do essentially everything you can do with Java exceptions, just without complicated syntax constructions; see https://oberon-lang.github.io/2022/05/15/towards-exception-h... for more details.

PCALL(P), P cannot have a return type

You cannot handle handle exceptions in a block of code without extracting into a procedure... that cannot return anything.

Yeah, I doubt you can "do everything you can do with Java expressions.

And of course Oberon's syntax construction is more complex: you need to have an external variable that gets populated, you need to match on three different types etc.

> 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 variable of a FOR loop has to be declared up front in the declaration section; either you like it or not; personally I prefer the in-place declaration approach, but the language would become much more complex and it doesn't make sense to just rebuild C++ or Java.

> 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 an additional parameter) needs an awkward `out` parameter etc.

Is the result sorta kinda equivalent to Javas? If you squint hard enough, yes

> That's the Pascal philosophy; even an index variable of a FOR loop has to be declared up front in the declaration section

I know the Pascal philosophy: create awkward verbose languages with useless constraints while claiming it's for the sake of simplicity.

> but the language would become much more complex and it doesn't make sense to just rebuild C++ or Java.

1. There's nothing wrong with complexity

2. There a multiple languages that don't have Pascal/Oberon's constraints, decisions, and awkward workarounds which are neither Java nor C++

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

[flagged]

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

I don't like people pretending that the language is simple, and commenters berating other languages for being complex while the language they promote and defend has quite a few of complex things and awkward workarounds for no reason.

> Four different loops

I think that having four different loops is better than jumping through four different hoops for different loop styles.

You don't jump through different hoops in most languages [1].

In Oberons you jump through the hoops because only `loop` is allowed to have `exit`, for example. Which is a constraint for the sake of constraints. Repeat is a do/while, but it doesn't have while's elseif statement. Again, because reasons. And so on.

Oberon is nothing but hoops instead of loops.

[1] Go's decision to not include do/while is on par with Oberon's decisions for loops: stupid and unreasaonable.

I wasn't trying to defend Oberon per se but separate goal-specific loop constructs. Yes, not having `exit` in other loop types sounds problematic.

> - useless dinsctintion between procedures and functions?

Uh? care to elaborate?

A proc is a function with no return.

A function is a function that returns something.

Oberon+ keeps it's predecessors' idiotic distinction, but takes it one step further: both functions and procedures are decalred with `proc` or `procedure`, functions are `proc`s that have a return type.

And yet:

- procedure calls don't have to specify parameters apparently, but function calls must specify all parameters

- functions cannot be used in Oberon+'s weird exception handling. [1] You do a call with `PCALL(res, P, args)` where res is a variable that will hold the result of the exception if it happened, and P is the procedure. You cannot pass functions (aka procedures which have a return type)

As the spec so wonderfully says [2],

--- start quote ---

There are two kinds of procedures: proper procedures and function procedures. The latter are activated by a function designator as a constituent of an expression and yield a result that is an operand of the expression. Proper procedures are activated by a procedure call. A procedure is a function procedure if its formal parameters specify a result type. Each control path of a function procedure must return a value.

--- end quote ---

[1] https://github.com/oberon-lang/specification/blob/master/The...

[2] https://github.com/oberon-lang/specification/blob/master/The...

Is this what it used to be component Pascal?

No, much younger. See https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne...

I really see how Nim was influenced by Oberon now. Will Oberon+ actually compete with Nim in some ways?

That's like competing apples with oranges; some people like the former, some the latter, some both; if you prefer a Python like syntax an a much more complex language, then Nim is your choice.

I like it is not using uppercase keywords. Is the grammar still LL(1)?

It's mostly LL(1) with a few LL(2) and one LL(k) productions.

that Fibonacci implementation has exponential complexity

but why? what would i use Oberon+ for? I used pascal and delphi in the past but for r, python, julia i can use for data science, js/ts for web dev, and python for general stuff.

what's oberon+ for?

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

> oberon that actual uses the same language for the shell

This is a common misconception. Oberon's text-based user interface lets you invoke commands in the M.P form, but it doesn't really have a shell language—at least not in the familiar sense—and to the extent that something like one kind of exists, it certainly isn't the same as Oberon-the-language.

SyntaxError: expected ')', found end of comment

How does Unicode support make it harder to audit code?

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.

It's more readable than innumerable symbols like in C++ or Rust.

The funniest thing i see is programmers are getting prroblems to grok functional programing concepts.