I don't think this is fair to Swift. Swift seems to have taken a view that the langauge will force you to be explicit about what you want. For example, the "indirect" keyword. Early Swift did not let you have recursive enums, apparently this can be something of a performance killer I guess was the reasoning. However they are really useful, so Swift added them. However rather than just automatically using an indirect Enum which is easily detectible, Swift forces you to use the "indirect" keyword. Rather than implicitly doing work for you, the Swift compiler stops to ask "are you sure this is what you really want to do? Do you understand the tradeoffs you are making?"
Personally I'm a fan of the Swift approach even if it does balloon the keyword count a bit.
I feel it's better to add keywords like that than to over load keywords based on context. See the keyword const in C/C++.
Also better to trust the end used to decide what trade offs they want to make. For instance code that converts a user click to a database query, clean and understandable is more important than performance. If it takes 10ns or 10ms the user ain't going to know the difference.
> The class condition determines whether the content of a data item is alphabetic, alphabetic-lower, alphabetic-upper, numeric, DBCS, KANJI, or contains only the characters in the set of characters specified by the CLASS clause as defined in the SPECIAL-NAMES paragraph of the environment division.
Can you give some examples? IIUC there are builtins (macros/functions that couldn't be expressed in the language) but no keywords. There are lots of syntax elements that could be keywords like ' (quoting) but I am not aware of any true keywords.
Personally I don't think that really counts. IIUC you can override those names, so they aren't reserved, and you can implement any one of these as a macro so you don't need to remember anything outside of the core language.
(You can't implement them all as macros, but IIRC there are disjoint built-in sets that can give you the full behaviour)
Sure. I think the point he was trying to make is that some languages are more complex than others. And in that context, the fact that Lisp has the flexibility to override just about anything actually makes the language more complex. Because now you can't make any assumptions about anything. In some ways Lisp is the most complex language in existence because it encompasses an infinite number of sub languages (ergo Racket's tagline "The programmable programming language"). In other ways it's the most simple language ever.
Personally I'm a fan of the Swift approach even if it does balloon the keyword count a bit.