On: Why is Dart keeping certain cruft from other languages?

[seanmcdirmid]

A small but very vocal sub community of programmers hates semicolons. Really, semicolons are nice for readability and nice for your tools, as they make statement termination explicit. I was on the losing side (a semicolon lover) of this debate when it came to scala.

[icebraining → seanmcdirmid]

I think this is mostly bikeshedding, but I can't agree with your statement.

The claim is not that we shouldn't have explicit statement terminating characters. It's that we already have one - new lines - and that mandating semicolons is both redundant and bug prone.

Personally, and while it doesn't really affect my choice of languages, I think you should be able to use one or the other, but not two consecutively.

In any case, excuse me for posting this, and I promise I won't discuss it here any more.

[AndrewDucker → icebraining]

I frequently split long statements over multiple lines for readability purposes. Having an explicit statement terminator makes this possible.

[anonymoushn → AndrewDucker]

You can do this without an explicit statement terminator. In Scala, you can write something like this and just have it work.

  foo.bar(arg, objectToComputeArg2.computeArg(innerArg1, innerArg2,
    innerArg3), arg3)

You can do the same in Python or in Lua. Lua will yell at you when it's actually ambiguous, as in

  function_returning_a_function(arg)(arg_to_returned_function)
  (it_is_not_clear_whether_this_is_a_call_to_the_value_returned_by_the_previous_line())

You can disambiguate this with parentheses or using a semicolon, though. There's never actually a need to use a semicolon.

[jerf → AndrewDucker]

Having an explicit terminator makes it maximally flexible, but certainly not "possible". Python does it just fine, but the rules, while mostly sensible, do have a couple of corner cases that can catch you. Javascript does it somewhat less fine, with quite a few more corner cases, including a couple that definitely routinely hit people. But in both cases, it can be done. Nor are those the only two examples.

[rdtsc → AndrewDucker]

I program in Python (no semicolons) and I also frequently split long statements over multiple lines. One doesn't need an explicit statement terminator to do it. You can do it inside parentheses for ex.

[mbell → AndrewDucker]

I do this all the time in Groovy and don't use semicolons...

[vorg → mbell]

> I do this all the time in Groovy and don't use semicolons

Groovy's semicolon-less mode has lots of syntax restrictions. E.g.this doesn't compile...

  println true
   ? "yes" : "no"

[mbell → vorg]

> Groovy's semicolon-less mode has lots of syntax restrictions. E.g.this doesn't compile...

I would't say 'lots'. It pretty much boils down to one thing: 'leave the operator on the previous line'

println true ?

        "yes" :

        "no"

For example is just fine.

[vorg → mbell]

This compiles and runs OK in Java...

  class Hello{
    public static void main(String[] args){
      System.out.println( true
       ? "yes" : "no" );
    }
  }

In order to work without semicolons, Groovy's grammar must restrict some things that work in Java. Semicolon-less mode in Groovy has a price.

[mbell → vorg]

That compiles just fine in groovy as well, the parathesis of the println call delimit the statement. Same is true for other delimiters:

  reportData = orders.collectMany {it.items}
                     .groupBy {it.product}
                     .collect { key,value -> [product: key,
                                               vendor: key.vendor,
                                                cases: value.sum() {it.actualQty},
                                        productCharge: value.sum() {it.totalProductCharge},
                                       platformCharge: value.sum() {it.portalCharge},
                                       shippingCharge: value.sum() {it.shippingCharge},
                                          dueProducer: value.sum() {it.totalDueProducer()}]}

Is perfectly valid groovy, spread on multiple lines with no semicolons.

You seem to be making this out like its some huge inconvenience. It is very rarely an issue and its not like there are 5000 things you can't do. Its really just line breaks in statements that aren't delimited any other way that are effected and all you have to do it put the operator on the line prior to the break...

[JoeAltmaier → vorg]

Ok, I've always wondered about that '?' operator. What's the point?

It was said (at the time) that C-like syntax meant a program was a series of expression, not statements. So something like

   (void)1;

is valid syntax. Even compound expressions are valid:

   a=5, b=6;

Where I feel abandoned (betrayed?) is this: why then aren't compound statements also expressions? E.g.

   {
   int x=Foo(50);
   Bar(x);
   }

The value returned could just be the value of the final executed expression (Bar yields a value). No need for 'return' at all.

And no need for '?'.

   int x = { if (i > j) 5; else 6; }

[vorg → JoeAltmaier]

You're right about statements being expressions and returning the last executed expression. In fact, since using Clojure I've gotten used to these, e.g.

  (-> (Foo 50) (Bar))
  (def x (if (> i j) 5 6))

I do miss the static typing and more readable syntax, though, and have appreciated Haskell in this regard. Too bad things like powerful macros and convenient syntax don't seem to gel together well in the same language.

[seanmcdirmid → icebraining]

I have first hand experience that semicolons are good for tools. I've also helped people debug their Scala compilations by having them add semicolons on various lines to make the error messages more comprehensible.

If we didn't have multi-line statements, new lines would work great as statement terminators.

[agumonkey → seanmcdirmid]

Isn't this part of a trend to reduce the presence of statements (enforcing order-based reasoning) ? With javascript ubiquity and mainstream presence of lexical closure people converge toward functional, encoding of patterns, even sequences.

[seanmcdirmid → agumonkey]

I think you are right but I disagree with the trend. Debugging a wide horizontal expression is much harder than debugging a tall vertical sequence of statements.

[agumonkey → seanmcdirmid]

'for now'. Current debuggers aren't built to handle this point of view. I agree it's quite frustrating, but I'd bet it will be fixed soon.

[seanmcdirmid → agumonkey]

I work in this area and I'm not so sure the fix will be easy. There seems to be a real "cognitive" cost to abstractions such as deep chains of combinators, which spills over into debugging. How the heck are you supposed to debug something when the control flow is abstracted N-layers deep? You really can't, which means you have to resort to something like data-flow debugging.