Hacker News new | comments | show | ask | jobs | submit login

This post left me feeling pretty bad about Coffeescript. Those semantics weren't well thought out at all.



In defense of CoffeeScript, I'm not convinced that semantic issues like this are at all obvious during the creation of a programming language. Honestly it'd be dumb luck landing on this one in particular since you can imagine that the grammar definition for lambdas and invocation/application aren't sitting right next to each other. That's what got me thinking about how you could explore the term space automatically.


Flaws like this arise from trying to be too clever with syntax. Function application with parentheses, literal regular expressions without clear delimiters, etc. Syntax should be describable in a handful of universal rules. Lisp is the extreme in this regard, the rule is simply: parentheses nest properly. But you can build surprisingly rich syntax with a simple set of rules so long as you lay out those rules first and conform the syntax to them as you go.


Io language is another great example of a language with a minimal set of universal rules yet incredibly rich metaprogramming.

http://iolanguage.org/


This particular issue was discussed during the design of the function definition and application grammar. (see above comment)


Right, but it's possible that the trade offs inherent in supporting both forms of method/function invocation and how they interact with function literals may not have been obvious to a different person.

Moreover in a different language it seems like it would be exceptionally hard to know how everything will interact, which is where a tool that can help you explore the term space automatically has value.


I dunno, I think the regex example that Ashkenas posted is a pretty good argument that the syntax decision wasn't a mistake, even if the actual decision is up for debate. Syntactic sugar has inevitable tradeoffs and edge cases if the goal is to minimize the alteration of existing symbols and grammar.


I'll keep on using JavaScript.


I hope you came to this conclusion by actually trying out the language.

I have written thousands of lines of coffeescript and I have never faced the mentioned problems.

Besides, you can always use the pragmatic approach and use parenthesis in case of ambiguity.


I work in teams scattered across the globe with different experience levels, so we all tend to avoid fashion languages.

On top of that, experience shows that transpiling to JavaScript increases the debugging overhead as now besides debugging our own code, we need to debug what the Transpiler has generated.

Source-maps won't cut it, because they are not available in all browsers we usually are required to support.


Check out Dart. It has less problems than JavaScript, not more.


Let me know when it is supported natively in all browsers.

The teams I work with won't use any language that translates code into JavaScript.


I assumed your comment would be related to the article, my bad.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: