Why must a modern language have Curly Braces?

What is your alternative to curly braces? Indentation, as in python, or begin/end as in Algol-style languages (I also count languages where the "begin" is implicit, as in Erlang), or some other way?

Python is definitely not ideal in this case, just look at lambdas and reindentation.

(I
 (so much wish
   (Swift had seen the light and)
   (gave us  s-expression
     (that which do not require colons commas or other noise)
     (have a uniform syntax)
     (and pave the way for code  generation at compile time))
   (but one doesn't dream anymore)) :-)

So do I, sincerely.

Ah, of course. I totally forgot S-expressions. My excuse is that S-expression based languages are so different syntatically. The begin/end and indentation approaches are easy to use in Algol-derived languages.

They are not "easy" they are familiar. Violin is extremely difficult for me, but ask a professional violin player!

So is German, but I'm sure that Angella Merkel does just fine, and that Mr Putin has no problem whatsoever with the Cyrilic alphabet.

s-expressions are _simple_ (as opposed to complex) because there are very few rules and even less syntactic markers.

You might want to check Rich Hickey's "Simple made easy" on QCon.

You don't have to tell me. I meant "easy" as in begin/end and indentation-based blocks are easy to apply to the Algol-derived syntax. S-expressions would not be easy to apply to Algol-derived syntax. That doesn't mean that there is anything wrong with S-expressions, just that you have to design the syntax explicitly for them.

Ha. 🙂

Lisp/Scheme is very cool, but I don't miss functions that end like this: )))))))), or nested lets drifting rightward. And how to blend the Lisp syntax style with OO syntax style (object.method, obj.property), which is often very clean, and useful for IDE auto-completion. One call looks fine. (obj.method 1 2 3) But now chain calls on that. ((obj.method 1 2 3).method2 a b). Yuck.

Rob

ps. I first wrote obj.m e t h, but it censored it. See: obj.****. No Breaking Bad discussion here.

Yeah, you only need to look at how useless Python lambdas are to see why significant indentation would be a poor fit in Swift.

Is there a hybrid solution (since Swift seems to favor hybrid solutions) where closures have braces (hence also method and function definitions), but scopes have indentation?

(Re-indentation seems like a non-show-stopping problem, especially if you posit IDE support for indentation-aware editing.)

Prior art:

- Dylan is effectively a Lisp with OO, generic methods, and Algol-style syntax: http://opendylan.org/

- Haskell makes use of significant whitespace via the "offside rule". It also admits a curly braces style. You can convert between the two notations losslessly: https://www.haskell.org/onlinereport/lexemes.html#sect2.7

To the original question:

- This isn't just a new language. It's a replacement for Obj-C. To succeed at that, it needs to be readily adopted by Obj-C programmers, and would-be iOS developers coming to the platform from other languages. And most languages in widespread use unfortunately remain punctuation-filled, so the trend perpetuates itself.

I guess its all about safety. In python you get nasty mixed-indentation error messages because one of your collegues isn't using spaces instead of tabs. And keep your fingers crossed that code merges don't mess things up. In Swift curly braces are mandatory for things like if-statements to prevent bugs by misaligned code. So don't count on curly braces getting replaced by indentation :)

Steve had nothing to do with this great concern of yours.

If something as trivial as this gets you this upset, I see an unhappy life ahead.

Personally, I really strongly dislike python's look and use. I love the curly braces. I think it depends on where you come from: If you come from scripting languages, you don't like curly braces. If you come from compiled languages, you do.

Braces are critically important and are here to stay.

Otherwise quick glances over code can lead to devastating assumptions..

I don't mind the curly braces if there are two or more lines of code, but if there is only one line of code it should be optional and not mandatory (like in Objective-C). People always put the focus on how improtant it is for Swift to be easy to read and mantain and that "less is more", so I think that this would be something to be taken into account to write just a tiny bit less redundant characters in your code. Just a thought, thanks.