Live data from Hacker News

No Semicolons Needed

terts.dev

21–30 of 92 posts

Re: No Semicolons Needed

#21

> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression. After python, it seems like every language decided that making parsing depend on indents was a bad idea. A shame, because humans pretty much only go by indents. An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and…

> An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and gives me no advice on where to go looking for the typo. The location should be obvious, as it's at exactly the point where the indentation stops matching the braces. But the parser doesn't look at indents at all, so it can't tell me that.

That's somewhat a quality of service issue though. Compilers should look at where the braces go out of kilter vs indentation and suggest the possible unmatched opening brace.

Re: No Semicolons Needed

#24

Earlier quoted context omitted.

Clearer for the computer, but not for the human. Many errors, some severe, have been caused by a human only looking at the indentation and not realizing the braces don't match.

> human only looking at the indentation and not realizing the braces don't match. If it ever gets to that point, a refactor is obligatory. Don't give the human tools to make easy mistakes. Any grammar can be abused, so blame the human for not writing clean code.

Javascript's delimeter soup ((){([]{})}); can become near impossible to parse barebrained, especially when mixed with indents and semicolons.

Semicolons are just noise. They're absolutely redundant.

Some brackets are necessary, but whitespace/indent languages make it clear there's a lot of redundancy there too.

The goal is to minimise errors and cognitive load. The fewer characters the better.

Re: No Semicolons Needed

#25
post #17

> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression. After python, it seems like every language decided that making parsing depend on indents was a bad idea. A shame, because humans pretty much only go by indents. An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and…

Scala 3 decided to go with indents.

You are not telling the whole story.

You can mix indentation and braces to delimit blocks.

It's insane.

Re: No Semicolons Needed

#26
post #7

Classic mistakes in language design that have to be fixed later. - "We don't need any attributes", like "const" or "mut". This eventually gets retrofitted, as it was to C, but by then there is too much code without attributes in use. Defaulting to the less restrictive option gives trouble for decades. - "We don't need a Boolean type". Just use integers. This tends to give trouble if the language has either implicit c…

That's what's nice about coarse-grained feature options like Rust's editions or Haskell's "languages", you can opt in to better default behavior and retain compatibility with libraries coded to older standards.

The "null vs null" problem is commonly described as a problem with the concept of "null" or optional values; I think of it as a problem with how the language represents "references", whether via pointers or some opaque higher-level concept. Hoare's billion-dollar mistake was disallowing references which are guaranteed to be non-null; i.e. ones that refer to a value which exists.

Re: No Semicolons Needed

#27

This article makes a strong case for every language to use ‘;’ as a statement separator.

Indeed it does, by showing how many different and confusing types of parsing rules are used in languages that don't have statement terminators. Needing a parser clever enough to interpret essentially a 2-d code format seems like unnecessary complexity to me, because at its core a programming language is supposed to be a formal, unambiguous notation. Not that I'm against readability; I think having an unambiguous terminating mark makes it easier for humans to read as well. If you want to make a compiler smart enough to help by reading the indentation, that's fine, but don't require it as part of the notation.

Non-statement-based (functional) languages can be excepted, but I still think those are harder to read than statement-based languages.

Re: No Semicolons Needed

#28

Looks at 11 languages, ignores Haskell or anything really different...

or Raku

Those are functional languages that generally don't use statements, so it makes sense to leave them out of a discussion about statement separators. If you think more people should use functional languages and so avoid the semicolon problem altogether, you could argue that.

Re: No Semicolons Needed

#29
It's interesting seeing all of the different ways language designers have approached this problem. I have to say that my takeaway is that this seems like a pretty strong argument for explicit end of statements. There is enough complexity inherent in the code, adding more in order to avoid typing a semicolon doesn't seem like a worthwhile tradeoff.

I'm definitely biased by my preferences though, which are that I can always autoformat the code. This leads to a preference for explicit symbols elsewhere, for example I prefer curly brace languages to indentation based languages, for the same reason of being able to fully delegate formatting to the computer. I want to focus on the meaning of the code, not on line wrapping or indentation (but poorly formatted code does hinder understanding the meaning). Because code is still read more than it is written it just doesn't seem correct to introduce ambiguity like this.

Would love to hear from someone who does think this is worthwhile, why do you hate semicolons?

Re: No Semicolons Needed

#30
post #25
post #17

Earlier quoted context omitted.

Scala 3 decided to go with indents.

You are not telling the whole story. You can mix indentation and braces to delimit blocks. It's insane.

As a casual observer who has written perhaps a dozen lines of Scala in his life, I feel like Scala approaches any “pick one” decision with “why not both?”.

Functional or OO? Yes.

Post reply on HN