6 ms·

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 ove

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.

nequo 4y ago
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.
- armchairhacker 4y ago
  > 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-prettify-symbols-mode https://emacs.stackexchange.com/questions/46529/configuring-...)
- xigoi 4y ago
  > 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.
- cxr 4y ago
  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.
pjmlp 4y ago
Code is read much more times than written, and hieroglyphs don't help.
- LudwigNagasena 4y ago
  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.
- zabzonk 4y ago
  so, you recommend cobol?
  - pjmlp 4y ago
    Well, it is cloud ready. https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv...
    - zabzonk 4y ago
      what has this to do with "hieroglyphs"?
      - pjmlp 4y ago
        It doesn't have them.
- canadianfella 4y ago
  [dead]
- mpweiher 4y ago
  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.
zabzonk 4y ago
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.
- unwind 4y ago
  C is declare anywhere and has been for a looong time (C99).
  - zabzonk 4y ago
    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.
    - stefncb 4y ago
      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.
      - rightbyte 4y ago
        Isn't the first row both the declaration and definition is this case? (I assume f() is a call.)
        Jtsummers 4y ago
        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.
cardanome 4y ago
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.
- zabzonk 4y ago
  > 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 {}.
  - 082349872349872 4y ago
    A normal swiss keyboard does not even have {}
- iroddis 4y ago
  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.
timbit42 4y ago
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.
shadowofneptune 4y ago
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.
bluedino 4y ago
That seems like it would be a simple thing to change.
sedatk 4y ago
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+.
- chadcmulligan 4y ago
  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.
  - sedatk 4y ago
    No I meant this: proc Something() begin ... end Something not the interface/impl declarations. Which actually makes this worse.
    - chadcmulligan 4y ago
      oh ok, yeah that's not pretty

nequo 4y ago

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.

armchairhacker 4y ago
> 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-prettify-symbols-mode https://emacs.stackexchange.com/questions/46529/configuring-...)
xigoi 4y ago
> 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.
cxr 4y ago
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.

pjmlp 4y ago

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

LudwigNagasena 4y ago
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.
zabzonk 4y ago
so, you recommend cobol?
- pjmlp 4y ago
  Well, it is cloud ready. https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv...
  - zabzonk 4y ago
    what has this to do with "hieroglyphs"?
    - pjmlp 4y ago
      It doesn't have them.
canadianfella 4y ago
[dead]
mpweiher 4y ago
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.

zabzonk 4y ago

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.

unwind 4y ago
C is declare anywhere and has been for a looong time (C99).
- zabzonk 4y ago
  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.
  - stefncb 4y ago
    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.
    - rightbyte 4y ago
      Isn't the first row both the declaration and definition is this case? (I assume f() is a call.)
      - Jtsummers 4y ago
        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.

cardanome 4y ago

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.

zabzonk 4y ago
> 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 {}.
- 082349872349872 4y ago
  A normal swiss keyboard does not even have {}
iroddis 4y ago
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.

timbit42 4y ago

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.

shadowofneptune 4y ago

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.

bluedino 4y ago

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

sedatk 4y ago

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

chadcmulligan 4y ago
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.
- sedatk 4y ago
  No I meant this: proc Something() begin ... end Something not the interface/impl declarations. Which actually makes this worse.
  - chadcmulligan 4y ago
    oh ok, yeah that's not pretty