Hacker News Reader

Comment by sfpotter | Hacker News Reader

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.

View on HN

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.

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;

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.

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

not the interface/impl declarations. Which actually makes this worse.

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.

Reply on news.ycombinator.com