I was a bit confused at slide 35 where he said that Go's declaration syntax is "easier to parse -- no symbol table needed" as I don't typically think of a symbol table being involved in parsing. Here's an interesting comp.compilers thread from 1998 about parsing C++: http://compilers.iecc.com/comparch/article/98-07-199
Couldn't pass this one up seeing as I should actually be dealing with this for a class instead of commenting on Hacker News. What it means is that certain sets of symbols cannot be parsed unambiguously without information generated during the parse itself (the grammar is not context-free).
The link in the sibling comment has the canonical example:
foo * bar;
can either be parsed a multiplication or a declaration depending on whether "foo" has been typedefed previously. So you need to keep track of typedefs in a symbol table to correctly parse things.
The biggest problem with this is that many parser generators (including yacc) are much harder (if not impossible) to use with context sensitive grammars.
To me it looks like Go is designed to make compiler writer's life easier rather than programmers. Why is it so important to save on symbol table if it does make language less intuitive (at least for people with C background)?
We should be moving towards compilers that are capable of dealing with even more closer to natural semantics, not the other way around.
I'm suspecting similar mindset was at work when making decisions on error handling which, IMO, is the most appalling part of Go. If you have coded in C most of your life then it's same ugliness as usual but for others it's a huge move backward. Again the designers of Go could have implemented exceptions and let programmers choose what mechanism they prefer. This would be same as in Java or C# where a programmer can choose to return error values instead of raising exceptions. But I guess that would be more work for compiler writers.
Easier to parse is not only good for the compiler. There is lots of other stuff, which needs to parse a language: syntax highlighting, style checker, reformatter, static program analysis, automatic refactoring. Some simple syntax changes makes it tremendously easier to develop all these tools.
C++ is known for being really hard to parse. Rumors say there is no complete C++ compiler so far. Java avoided those pitfalls. As a result you can see that Java has much better IDE support (e.g. refactoring) than C++.
Why is it so important to save on symbol table if it does make language less intuitive (at least for people with C background)?
Because Pascal-style declarations are superior in readability. With type inference, they also allow less typing ("foo :=" instead of e.g. "auto foo =").
You are going a learn a completely new language, new idioms, new standard library, new tools, and you're arguing that switching to a different style of declarations, a very very minor detail, is "less intuitive"? I'm not sure how intuition applies there: are you learning a language by trying to compile what you typed without reading any documentation or what?
Again the designers of Go could have implemented exceptions and let programmers choose what mechanism they prefer.
Because making them optional doesn't work well. If someone uses exceptions and someone not, combining code from those two people will make you use both exceptions and error returns. It would be even messier than indicating errors in C (does this function return 0 on error or -1 or what)?
It's arguable that the Pascal-style declarations are superior in readability.
I've discussed this with colleagues in the past, and those who were raised with English as their native language, for example, often find C-style declarations easier to comprehend. They find the adjective (that is, the type) coming before the noun (the variable name) more natural.
The opposite happens for those whose native language is one where adjectives follow nouns. They find the Pascal convention easier to comprehend.
The English speakers must not have taken many math courses: there type declarations much more commonly come after the variable name than the other way around, although both styles are used. I mean "Let G be a group and f an automorphism of G" is much more common than "Consider a group G and an automorphism of G, f".
I think that the argument generally goes that if the grammar is unambiguous then it's also easier to read (once you're accustomed to the syntax) because there can only be one interpretation and so you don't need to keep knowledge of what's a type and what's a value in your head to understand a line.
