Hacker News Reader

Comment by zuj | Hacker News Reader

Completely off topic but, after doing python for ages, recently started writing Rust and semicolon does seems useless. We are doing the indentation and new lines anyway, why not just make them as default language construct as python does.

(autodidact developer here, feel free to ELI5 and enlighten me)

View on HN

Well, have you ever run into the

    x = some_long_expression
            + another_long_expression

problem? In Python you need to be careful to wrap that in () or use a \ before the newline to avoid it parsing as two lines, e.g.

    x = some_long_expression;
    + another_long_expression;

In particular, if you have a builder expressions

    let x = someBuilder()
            .setVal(x)
            .build()

You'd need to wrap the entire thing in () to avoid it getting mad, right?

So if you're going to terminate expressions with ), and start them with (, why not just terminate them with ; instead?

Javascript is a "Semicolons Optional" language, but it's actually the worst of both worlds, as you have to be very careful not to wrap lines like

    function() {
         some stuff;
         return
            really_long_named_thing;
    }

As it'll just insert a ; on the return, returning undefined for you.

Love the examples, thanks for ELI5.

To be fair, that's really more of a python-specific deficiency than a general problem with significant whitespace. Haskell for example interprets further-indented lines as a continuation of the current expression, only ending the expression when it sees a new line of the same or lesser indentation.

As I wrote, you have to do similar things when using Haskell (or F# or OCaml) in the REPL. Python just doesn't have a special 'non-REPL' syntax.

> In Python you need to be careful to wrap that in () or use a \

I guess that's because in the REPL Python need's to know whether the line has finished yet or not. OCaml and F# uses two semicolons ';;' for that purpose, but only in the REPL. In Haskell you can use braces and semicolons or '{:' and ':}' in the REPL.

It's not just in the repl.

At least Python will give you a diagnostic. Ruby is worse; even with parentheses ...

   salary = 100500
   newsalary = (salary * 0.02
       + salary)

newsalary will the same as salary. There are no diagnostics.

Yes, you can fix it by moving the + up a line but this should be a purely style thing, not semantics.

It's a lot easier to format code arbitrarily when a language is whitespace-independent.

For example, to do method chaining across multiple lines, Python requires parentheses around the whole chain. That's a quirk of being a whitespace-dependent language.

In general, I think people who advocate for braces and semicolons just find it easier to reason about the code when they know that the formatting doesn't matter. All the flow is done via visible glyphs.

Haskell has an alternative parens-and-braces syntax to the offside rule; that was meant particularly for machine-generated code if I remember correctly.

Edit: I meant to add: you need to decide whether ";" is terminates or joins statements if you have statements in the language.

It's a trade-off. You can either assume all statements end at the end of the line, and require a continuation character (backslash in Python) if that isn't the case; or you can require a statement terminator (semicolon/closing brace in Rust) for all statements.

The downside of assuming statements end at the end of the line is that you need to have special rules for when that isn't the case (such as Python's implicit statement continuation inside braces), while always having a terminator is simpler and more consistent (all statements end with a semicolon) at the cost of extra characters.

Thanks, this makes perfect sense. Python we are using \n instead of ; as the statement terminator.

Just didn't got what you mean by "python's implicit statement continuation inside braces" ?

I think he is referring to

    x = (
      object
      .method1()
      .method2()
    )

Right, gotcha!

There are people who hate python because of the forced indentation. They indent their code in their language of choice, they just don't want something FORCING them to do it.

I'm always flabbergasted at this argument.

I don’t indent my code, my autoformatter does. It is way less effort to get the braces right and then have the indent level inferred automatically

Automated tools get in my way of thinking. I turn off intellisense, auto-formatters, etc...

I'll run auto tools during check-in, but not during coding sessions.

No find and replace, either? ;)

I use those. But how would those be automated exactly? How would they know what I want to find and replace?

By understanding the language, so it can do magic things like "rename this field (including uses of it)" without changing other uses of the same string. As a separate operation from general find and replace, of course.

You tell it what you want to find and replace with and then it automates the rest.

My point being that where you draw the line between what you consider automated vs not is pretty arbitrary.

> I turn off intellisense

Unless you are doing this for performance reasons, this one I'll never understand.

I'd much rather type "x.someP" and hit tab then type in "x.somePropertyThatHasARidiculousNameIAlwaysForget" after having to consult the documentation yet again to get the name.

I already know what I want to type. Having something pop up with "suggestions", often obscuring the lines I need to read, is worthless to me at best and disruptive of my thinking at worst.

If I can't recall "x.somePropertyThatHasARidiculousNameIAlwaysForget" then there are other more serious problems.

> If I can't recall "x.somePropertyThatHasARidiculousNameIAlwaysForget" then there are other more serious problems.

I just prefer to press less keys. It shouldn't obscure anything in a decent IDE.

Often you are working with other people's code and having to "recall" every single property, method, etc declared is not practical, hence why I mentioned having to keep referring to the documentation for things you are not accessing very often.

If I keep forgetting that a property is .lastname and not .lastName in a library I'm using I can just type "last" and press tab.

This is even more crucial in dynamic languages like JS, where you will get a failure at runtime and not compile time.

It doesn't make you any "less of a programmer", it makes you a more efficient one once you are used to it.

If you have properties with ridiculous names, that's a bigger problem.

Autocomplete in code seems to mostly be papering over design smells that should be fixed.

> If you have properties with ridiculous names, that's a bigger problem.

I have no control over third-party dependencies and how they name things.

I tend to solve that by wrapping inane APIs. At most I deal with ridiculous names and other API-brokenness once.

> I tend to solve that by wrapping inane APIs.

That is just another layer of abstraction which leads to even more confusion.

These abstractions can be taken to the extreme in things like Java, that's how you end up with a class named "InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState".

If you wrap that in a new interface "IFIFTPIFTPMBWNFS" or even "crazyFrameStuff" (ridiculous enough), now you have to figure out what that actually is while debugging.

If one just comes to terms with the fact that Intellisense (and showing the method signatures while implementing) is extremely helpful even to very senior developers, life can be much easier.

It's not cheating.

No, I end up with classes like that because when I wrap APIs the point is to simplify, so I simplify. Though that is a last effort if ditching the broken API entirely isn't an option - e.g. if it's a third party API we can't avoid. That is rare to begin with.

You're free to find Intellisense etc. useful. I just don't. I go to great lengths to have an uncluttered view of the code when I work, because I find it far more preferable to focus on just the code. I'm not against it in principle - I've just not seen any solutions like that which works for me. I don't tend to need to look up methods much; when I work on a piece of code I tend to hold the APIs in memory pretty effortlessly, so that's just not much of a consideration.

I spent years actually looking at implementing visual languages because I liked the idea of providing more contextual information and views of information flows etc. to aid development, but I've yet to find something that works better for me than an uncluttered view of the text.

All usable editors also infer the indent levels of brace-less languages. Sometimes you have to change that using a <tab> or <shift>-<tab>, but sometimes I have to write braces in languages with braces too.

I suppose I don't quite match the reasoning you're describing, but here's mine. I indent; I just don't want semantic meaning ascribed to whether or not I'm missing an indent. I'll handle the {}s, my editor handles the indent level, and everyone gets along fine.

In Rust, a block that ends with an expression without a semicolon returns that expression. It lets you write terse things like

    let x = if y { a } else { b }

Kotlin does the same but without semicolons so it would seem not to be essential.

Because then there'd be ambiguity between a function ending and returning unit (nothing) or returning whatever the last line expression returns. You could change things around this, but Rust has a goal of unambiguous syntax, hence also the turbofish::<>

Python and Rust have two fundamentally different philosophies. Python is all about quick and intuitive programming and it's pretty good at that, though in turn you can get more kinds of bugs and runtime errors that could have been avoided with proper type checking and other measures.

Meanwhile Rust avoids any kind of behaviour that isn't clearly visible in the code. That includes unambiguous syntax, like the mandatory curly braces for loops and conditions. And of course the semicolon as a clear separator, which comes in handy when iterators or the builder pattern are used.

That argument has the flaw of not working with Haskell, OCaml or F# ;)

Really, Rust only doesn't look like OCaml because less people would use it if it wouldn't have braces and semicolons.

Found this post, for example: https://news.ycombinator.com/item?id=5607912

Rust uses the semicolon to distinguish between statements and expressions.

Yes, coming from python it took a while for me to wrap my head around this.

In Rust, omitting a semicolon has a special meaning, ie a return from an expression. So, you can't just ditch it.

I wouldn't mind Python's whitespace indents in Rust though!

> In Rust, omitting a semicolon has a special meaning, ie a return from an expression. So, you can't just ditch it.

Of course you could, because a semicolon-less return doesn't work in the middle of a statement.

You can't do

    bla;
    a
    bla bla;
    b

instead of

    bla;
    return a;
    bla bla;
    b

Yes, the code after the `return` isn't reachable and the Rust compiler doesn't like that ;)

But that would mean

  {123 456} + {789}

was 1245 instead of 124_245.

I'm pretty happy with the choices made in rust and python. Just want to note that the : in Python is just as superfluous (as rubyists will tell you) and kept only for readability, not for parsing.

Reply on news.ycombinator.com