Lambda the Ultimate

Yes. The IDE can permanently infer a semicolon as a service to the user. By this, I mean, the semicolons become sticky and future changes to the code will not blow them away, and this is probably a good thing. But many users are uncomfortable about this kind of reference; they also get annoyed when the IDE infers a closing brace.

These inferences could also be made invisible and transient--the IDE infers a semicolon closing brace so it can provide decent feedback. But this, and then, if the code is left untouch (a semicolon, closing brace wasn't typed manually), can add a permanent token as above.

invisible and transient

... or visible but faded and semi-transparent, such that the user must type it or move on for it to become permanent.

Ya, that's how it worked in the Scala IDE (for parenthesis at least, we didn't bother with semi-colon inference, but probably should have).

Well, look at Haskell, which is minimally non-redundant, and just see how hard it is for new users to grock Haskell's syntax compared to something more redundant like Java (where redundancy comes from syntax and formatting). I believe some amount of redundancy is beneficial to readability.

Semicolons are for humans, its obvious that the compiler can do without them. However, semicolons do make the job of the compiler easier in forming decent error messages, but I argue that is for humans also.

Haskell does a lot of things non-redundantly, and I think it's useful to look at the features independently.

For example, do you think adding braces and semicolons to Haskell would improve readability of the code (for someone who has been using the language for, say, one month)?

I must remark (in reaction to Kannan's reply) that Haskell syntax *has* semicolon and braces, that can be used anywhere locally as an alternative to the most common whitespace-sensitive syntax.

Sean, I am not at all convinced by your statement that "it is hard for new users to grock Haskell's syntax compared to something more redundant like Java". This typically sounds like a claim that is believed but has not been empirically validated (orelse I would be interested in references).

I think any unease you could observe may very well be a "familiar vs. new" difference rather than something about Java or Haskell syntax (as Java syntax is basically C syntax and therefore minimally different from what people already see all around). I have heard of Haskell being used to teach non-programmers (ie. a programming course in a mathematics programme), and have not heard of particular syntactic difficulties.

We also often hear the argument that Python syntax (not that far to Haskell's) is nice and easy to work with, and look like most intuitive pseudo-code. My guess is that there is some truth in this idea, though I haven't heard of concrete experiments. On the other hand, Chris Okasaki reports that indentation-sensitivity was a great help to teach programming to beginners, by forcing them to pay more attention to the code structure.

Of course optional doesn't mean required, but dealing with other peoples' styles is a curse to having "choice;" language consistency is another dead horse to beat later.

I would argue that some amount of redundancy leads to reinforcement, which leads to both (a) quicker learning of the language and (b) better readability when looking at some code you didn't write. Oddly enough, books used to be written without periods. Punctuation is actually a recent and extremely useful invention. Familiarity is obvious one factor that would have to be accounted for in an empirical study, right now I'm just working off of anecdote.

When I look at Haskell code, is that I always get lost without redundant syntactic signage and type annotations. I'm not really talking so much about semicolons in this case (type annotations are probably more important), I was only using Haskell to make a point (I would use Scala more to debate semicolons).

Your link to Okasaki's report seems to be incorrect.

Thanks, I just fixed it. In the process I noticed that it had been mentioned on LtU before, but without really starting a discussion.

and we all know how easy it is to copy-and-paste-and-auto-indent-correctly python code of any significant length. not that we should actually be doing much copy and paste, but it does have to happen sometimes, and i freaking hate whitespace sensitive languages then. and other times, to boot.

Is there anything that you find valuable in the link you gave? I've glanced over it and found little more than trivia and unstructured discussion -- with the historical remark that whitespace significance was promoted by ISWIM a long time ago.

If it makes specific points that are pertinent to this discussion, please feel free to quote them more precisely.

The way JavaScript does automatic semicolon insertion is very hacky and hence shouldn't be taken as an argument either way. If you want to look at a more reasonable example, look at Haskell.

I don't get it, indentation is about blocks, not statements, which are demarcated by new lines right? Then I have know idea why python would be any better than scala, unless you are saying python doesn't support unblocked multiline statements. If so then semicolons aren't necessary.

I'm not sure about Scala. Python does support unblocked multiline statements. But I'm not sure how that validates the case for the semicolon?

I don't think Sean was at all attempting to elevate semicolons vs whitespace into the level of lazy vs strict or pure vs impure. He was just raising a discussion about one aspect of concrete syntax design. If you think it's too trivial to discuss then by all means don't discuss it.

If some one were to show up and go "Hey, I implemented an Ocaml, but changed so you only have to use one colon for list cons, instead of two!", everyone would be like "Um, why?"

If, however, somebody showed up saying "Hey, I implemented a Haskell, but fixed it to properly use single colon for type ascription", then that would be a BFD indeed. :)

Finding yet another example of Parkinson's Law of Triviality does not indicate the design space, even for languages near Smalltalk-80 and Algol-68, is even close to fully explored or optimal, not even within the mainstream features. A few areas of significant variation today include traits/inheritance models, reflection, concurrency, persistence, partial failure handling, module systems, libraries, and even syntax (which is often more significant than a semicolon).

Granted. But I don't see those ideas having much of an impact on the mainstream. Maybe I just read too much hacker news and reddit, but as far as I can see, to the extent that there is a debate in the mainstream about what languages to adopt, many if not most of the arguments are about trivialities- semicolons and compilation speed.

And I don't even mean to cast aspersions on the importance of syntax in language design. I suppose the no-semicolons claim could be a stand in for a much larger collection of syntactic changes, which in aggregate make for a sufficiently improved programming experience. But I haven't seen that argument made. And I would expect if that were the case, there'd be something less trivial that could be the symbolic change- maybe significant white space or something like that.

Orders of magnitude improvement in any facet, even compilation speed, is never a trivial detail. Quantity impacts quality! If the arguments are about small differences in compilation times, it's trivial. If the arguments are about the orders of magnitude difference between Go and C compile times, it is not trivial - at that point you'll have a significant and visceral impact on programmer experience and productivity.

But, that aside, people will persist in arguing trivialities. I think you'll find that people arguing trivialities on hacker news and redd.it are also consistent in failing to convince anyone to adopt a language. There is at least a subconscious recognition of the triviality in most participants. But people tend to argue where they feel they can contribute, even if only for the trivial.

Really, bike shedding is focusing on a trivial aspect of a language when there are more important things to argue about while I'm bringing up the semicolon topic in isolation of other issues, which admittedly would often take priority. However, making semicolons optional in Scala was a big deal with many important consequences. Its a detail to be sure, but a very important detail.

Once we figured out how to eliminate the need for semicolons via clever parsing (talking Scala here, Javascript is much less sophisticated in its semicolon inference), many people thought it was a no brainer to just get rid of them. If they aren't necessary, why should they exist? However, I'm arguing that the extra signals they provide about programmer intent (I meant here to be a statement boundary) as well as an invested reader (ah, the statement boundary is really here) can be very useful, that we lose something and therefore "optional semicolons" must be considered as another tradeoff to be made. Or to put it another way, a minimal syntax is not necessarily an ideal one.

No one is going to bother building a language out of one syntax improvement. Rather, there is a buffet of features to grab on to. In the context of my current research, live programming, I need the compiler to be extremely responsive, I need the compiler to be incredibly robust with respect to transient errors, so having non-optional semicolons might be very useful in that regard.

While semicolons might serve your purpose, I think you could find other features that would serve the same purpose without the visual clutter of semicolons. Syntax can be designed with localizing errors in mind, as can be IDEs.

One useful technique is to build localization rules into your probabilistic, error-robust parser: multiple blank lines indicate progressively lower probability of a relationship. Even without an offsides rule or significant whitespace, this should often be sufficient.

I would argue that such techniques are orthogonal and probably composable in their benefits.

I agree with that. Unfortunately, such techniques are also composable in their disadvantages. Be careful what you choose.

Strange analogy since most track race cars designs don't have doors that open and the driver enters and exits through either the window or open cockpit. That's done not because of a misstep in user interface design but to improve safety and weight. Which is to say it's a good design for that domain.

To bring this back to ground. racing is often justified as a research bed for technology improvements that might make it into consumer cars. I don't expect anybody will be climbing through the window of their family minivan, but it does seem as least plausible to do research on say engine monitoring technology in a racing domain without worrying about user interface elements like cupholders and doors.

Same deal with language research - not all research needs to deal with every aspect of language design equally.

Yeah, not exactly a perfect analogy.

Certainly much research (investigating new "engine" designs) can be done on languages without all the amenities that the average programmer expects. That said, there is also plenty of room for research on the human/social aspects of language design.

For anybody who isn't doing pure research, though, and intends to make languages that programmers actually use, it seems worthwhile to take a measured, pragmatic interest in issues of user interface.

Novices certainly have a tendency to get over-invested in issues of syntax, but that doesn't mean that disinterest in syntax is required for expertise.

The C# language is an interesting example to me. While we may disagree with this or that choice, it is clear that many of their design choices with respect to syntax, scoping, etc. were motivated by actual study of programmer practices. For example, C# has rules related to local variable scoping that are intended to reduce the likelihood of certain errors caused by copy-paste programming.

Bringing up C#, its also a language where eliminating the need semicolons is pretty straightforward (with the rest of its grammar mostly unchanged, like Scala) but will probably never happen given that the developers they target really value good error messages and consistency in readability.

There are many PL folk who consider syntax very important. John Shutt, William Cook, Sean McDirmid, Jonathan Edwards, and myself are just a few among them.

One of my goals is to unify UX and PX - bringing them together via live programming, reactive semantics, tangible values (or naked objects). I have ideas for programming grammars based on widget composition, and I'm especially interested in set-based or proximity-based composition (similar to traits models in OOP) where the system can auto-wire the components in a predictable manner. The effects of PL semantics on UI - on what is easy, and therefore on what is actually achieved - is deeper than one might expect. I'd like to elevate both PX and UX, e.g. to support programmable UIs, open composition, mashups, cooperative work (externalize state, @unhosted), secure interaction designs (object capability model).

Sean is another who considers UX a very important part of PL design. There seems to be a group of such people gathering (slowly) in the augmented-programming google group.