Hacker News new | ask | show | jobs
by asdasf 4515 days ago
I think this shows that Walter has lots of compiler experience, not so much lots of language design experience. You can't get good error messages without semicolons? How can anyone say something that absurd in a serious article? Have you tried a language without them? It works just fine.

Minimizing keywords is important not because of a word shortage, but because of an overlap with words the programmer wants to use. It is obvious that if you make "i" a keyword, someone will likely murder you. But there's tons of grey area where you might be stepping on toes and getting in the way, so minimizing the amount of toe stepping is good. Especially since there is absolutely no reason to have lots of keywords.

2 comments

Full context: "Redundancy. Yes, the grammar should be redundant. You've all heard people say that statement terminating ; are not necessary because the compiler can figure it out. That's true — but such non-redundancy makes for incomprehensible error messages. Consider a syntax with no redundancy: Any random sequence of characters would then be a valid program. No error messages are even possible. A good syntax needs redundancy in order to diagnose errors and give good error messages."

Given the context I think it isn't so much that Walter is saying you can't have good error messages without semicolons. He's saying you can't have good error messages without redundancy (in this example a statement terminator).

>Walter is saying you can't have good error messages without semicolons

That is what he said though. I understand it is one example for a larger point, but it is an example that doesn't support that point at all. It is pretty hard to judge the overall point when the example is nonsense.

I think you're really missing the point.

Your goal is to write a whole programming language.

Calculating where each statement starts and ends in order to serve a good error message is misdirected effort. Just use a terminating character, and use the standard one: a semi-colon.

> Just use a terminating character, and use the standard one: a semi-colon.

Significant whitespace is popular as well. You can argue all day about it, but at the moment I think making a language "look like python" is the safer bet for a new language.

Significant whitespace is _also_ redundant, just along different metrics. Badly indented Python gets caught before execution the majority of the time, and in presentation, it surfaces to the programmer quickly.

His argument is essentially against something like Lisp or Forth where you have such a paucity of syntax that many erroneously written statements are syntactically valid and make it to runtime.

Lisp and Forth are the extreme case, which is especially bad, because you get no error message at all.

But the middle ground are languages that can detect a syntax error, but can't figure out exactly what it is. You don't get an error message saying "You should have a semi-colon here, want me to insert one?" Instead you get some vague message like "didn't expect this keyword here" a few lines after the missing semi-colon.

It's debatable. I know two languages with significant whitespace, that's Python and Haskell. And Haskell's rules are a pain.

For the language I'm working on, I had started with significant whitespace. Then I realized that it would be a pain for things like anonymous callbacks (the kind of thing JS code is littered with) and that it was distracting. At least when you start, don't get hung up on the syntax, focus on basic things. What's important is what you are going to do with your AST, the lexer/parser part are the least important areas, unless you are doing a "syntactic skin" over a language (eg, coffeescript). You can always change the syntax later.

There's also F#, CoffeeScript, Yaml, Sass/Stylus, Haml/Jade and several others, just among the popular languages.

And if we mean "significant whitespace" as in "newlines can act as statement and expression terminators" (since we were discussing semicolons as the alternative) we can also add a ton of other languages, like Ruby, JavaScript, Go, Scala, Visual Basic and Lua.

I'm curious why you felt anonymous callbacks were problematic in a significant whitespace language. They seem to work just fine in coffeescript, as an example.
> It's debatable. I know two languages with significant whitespace, that's Python and Haskell. And Haskell's rules are a pain.

But it's optional in Haskell's case.

>And Haskell's rules are a pain.

How?

> at the moment I think making a language "look like python" is the safer bet for a new language

Why Python? Clojure and Elixir are two new languages with growing communities and they look nothing like Python.

You could also say that newlines always terminate statements unless a continuation character is used. That's a trivial policy that works very well in practice.
I don't know how you think that was the point. He doesn't say anything like that. In fact he takes the exact opposite position when dealing with parsing, saying to just write more code. Why would something which literally requires no extra effort (producing useful error messages without semicolons) be misdirected effort, while writing a more complex parser is cool?
I re-read the article and I concluded that we are both right. I direct you to the following statement:

"The principles are rarely orthogonal and frequently conflict."

Producing genuinely useful error messages at all requires a complex parser, IMHO. It's not computationally obvious to look at a line of code and say 'actually you just missed this one character'. Requiring a terminating character gives you at least a sanity check starting point to work with - it alone will catch whole categories of errors.

Forth doesn't have 'keywords' per se, but i is predefined for you. It has the effect of placing the index of a 'do' loop on the stack.