CoffeeScript's Time is Waning For Me
mattgreer.org
mattgreer.org
I would appreciate an explanation of this paragraph. How exactly does project size compound issues with significant whitespace? Are you indenting five levels or something?
I would argue there are bigger problems with CoffeeScript, such as empty blocks being legal. For example:
if foo
bar()
if foo
bar()
- Creating big complex methods instead of breaking code into smaller (testable) ones?
- Nesting callbacks multiple levels deep, instead of using something like Node Async to flatten out code flow?
- Choosing a Coffeescript code style that leads him to put callbacks on their own line, or something like that?
- Something else?
Not implying the author is wrong by any means - there are probably some scenarios where coffeescript isn't the best whitespace-wise. The thing is, readability is one of the huge reasons I use coffeescript, and I feel like it's largely compatible with the whitespace patterns I used in javascript. Even for large NodeJS or Angular projects, I've found that it is consistently easier to read and edit than Javascript.
Here is a typical snippet of my code as seen in my editor: http://i.imgur.com/2yVhgcz.png
IMO, those four methods really bleed together and are hard to discern, not to mention the if statements. I also think for the most part I stick with code that's "whitespace friendly", getAll there is a really long method by my standards.
Yeah, I could put more blank lines between the methods and probably some other things. But I also think a closing brace or an 'end' makes a world of difference. Really helps break up the space and compartmentalize it.
Not everyone thinks this of course. For many code like this is just fine. Like I said, it's all preference.
And instead of dropping CoffeeScript I hope you will try out ToffeeScript. But just use the basic ! thing, you don't need the other stuff like auto callback.
e, data1 = fs.readFile! 'foo'
e, data2 = redisclient.get! "thekey"
console.log data1
console.log data2I'm interested in things like ToffeeScript and JS generators. I do like what they do for code readability.
Does the author want to skip the indentation some of the time? I can think of a few marginal cases where that would be preferable. But in the vast majority of cases, you should indent any nested structure that has its own line(s). Indentation is essential for readability.
Coffeescript and significant whitespace eschew delimiters for indentation and other gimmicks, and the end result is something that is more difficult to read.
I totally agree with the author on this fact. I only see a "wall of dense text" when I read coffeescript, and when I read Javascript it is much easier to parse.
i find it slows down my coding because rather than coding & then quickly tidying i instead have to obsess over this tidying at every step or the code won't work in the first place. I find it more efficient to do the code grouping as a "post-POC" task (or when things are starting to look confusing) and to leave the visual look to my discretion. I feel like whitespace languages are kindof subliminally forcing you toward 1 code style. There are some complex functions that look better to me certain ways -- specifically in cases where a group of commands are essentially executing one simple function. Once they work they can be forgotten & the programmer can de-emphasize them in some way according to taste
anyway, I am not a CoffeeScript guy. I've been avoiding it and waiting for Dart or something like that to take hold, since I'd like to see some serious language benefits if I'm going to have to introduce a compilation step. It's one of those things I remain slightly bitter about because some shops judge you for not being into it (as well as Sass, Haml) even though they offer negligible benefits for many projects. That said, I can imagine cases where CoffeeScript would offer significant benefits (they are right there in the tutorials) but I haven't really found those types of situations too much in the wild (tons of array math etc.), and if so they can often be simplified via jQuery or the like anyway.
So yea if it works for you, great, but I am glad whitespace syntax is not de-facto in the js world. I think js should remain as Java is -- other languages can be built on top of it with their own syntax types but developers still have the choice to ignore these supposed advancements & cherry-pick the ones they like (in my case progress in pure js + Dart will be where i focus my learning).
I don't mean this as a personal attack, but your comment contains plenty of spelling errors, incorrect punctuation and capitalization, and inconsistency (e.g., use of both "&" and "and"). In my experience, people who aren't careful with syntax tend to detest significant white space, which is understandable.
Maybe not opinion, but reaction. Generally involving visceral fear or anger.
It's not that it's always bad, every hour of every day. It's that one time, at 1am, when you shouldn't be working but you are, something doesn't behave properly, and it turns out Bob the Intern re-indented a block of code to use tabs instead of spaces[1], but you couldn't see it because your editor is configured to use four spaces per tab and your coding standards dictate four spaces per level of scope.
[1] Why are you using spaces anyway, you complete and utter savage?
Furthermore, because CoffeeScript requires (sort of) a compilation step, errors are caught and debugging becomes MUCH easier than it ever was with plain JavaScript. Most text editors now have plugins that will compile selected text to JavaScript so you can preview the end result and make sure that you're getting the output you want.
The better part? When JavaScript best practices evolve, CoffeeScript can evolve with it, but the code can more-or-less stay the same. Awesome!
I'd love to see a CoffeeScript variant for TypeScript. TypeScript has the structural things of CoffeeScript and more (OO paradigms, member visibility, modules, typing, etc) but much more verbose. I have tinkered w/ the CoffeeScript grammar/parser adding in a backslash to denote to type (e.g. "(x\int) -> x * x") and the TypeScript AST and compiler are very easy to work with. I just haven't had the enthusiasm to build a complete project. That would be my dream language. Until then I think scala.js is a great fit.
With TypeScript and Dart, the type annotations are optional. You don't have to use them.
With JavaScript, you can't add any type information. Using non-standard doc comments is the only option.
Also, the main advantage of JavaScript is that it's available in browsers.
Re "main advantage of JavaScript is not having to supply types", I am a static typing fanatic so I am just going to disagree here and spare everyone the religious (or as Yegge would say, political) war.
Essentially, js isn't all that busted. The busted parts can for the most part be worked around with underscore/lodash and sweet.js (for the really ambitious)
sweet.js
pretty neat pattern matching library written with sweet.js
https://github.com/natefaubion/sparkler
I do most of my work in Python, so the above experiences and biases may be a direct result thereof.
First of all if you want anyone else to help you with your code its likely that they don't know the wrapper's syntax and will have to waste a bunch of time learning it. My boss got super excited about it when it first came out and it just caused a lot of headache and wasted time. First I (and all my coworkers) had to learn the language, and then port all of our existing code to CoffeScript. And for what? Some syntax sugar?
Honestly, I don't really see any problems with Javascript's syntax. It's everything else.
Please define "bunch of time". I'm having trouble imagining how learning CoffeeScript would require more than a couple of hours for an experienced developer.
Tooling is terrible with JavaScript. Even if you use something like Tern, it's still really bad.
You can pass arbitrary arguments to functions. Types and arity isn't checked. Optional positional/named arguments (with default values) don't exist. Passing some options object and "foo = foo || 5" is the best you can do. You can't tell, with absolute certainty, that some object doesn't have some particular property. A string might have a "lenght" property (should have been "length", that was a typo).
Your IDE can make some educated guesses and offer some auto-complete suggestions based on that.
There is also type coercion. Maybe you really wanted to create NaN in a very elaborate manner. Multiplying some array with some object is totally legit. No squiggly line for that.
That's a far cry from being perfect.
Never used something like C# or Java? Dart's tooling is also pretty good, for example. Even AS3 offers much better tooling than JS. TypeScript does of course also offer way better tooling.
JavaScript's tooling is terrible, really.
https://news.ycombinator.com/item?id=6078969
jashkenas > So in general, what I'd like to see mainline CoffeeScript do, is adopt useful ES6, ES7, and ES8 features, as soon as they land in enough platforms/browsers to be widely useful (yield may be at this point already, or very soon), and to continue to try and find a pleasing minimalist syntax for writing and reading them. If this means taking the ES* syntax wholesale, that's fine. If it means minting a new (and hopefully, but arguably, nicer) syntax, that's fine too. And if it means breaking backwards compatibility, that's also alright, as the compiled lowest-common-denominator JS output will still be perfectly compatible with the new stuff.
Quality, not quantity. Maybe the higher quality contributors are more likely to get excited about a cs project over js.
But I would be okay with this stance (yet would not use coffeescript) if the language had a mechanism to warn you when you're trying to reuse a name. Instead the language's features combine in a way that will clobber your code and lead to subtle or not-so-subtle bugs.
I have noticed a lot of "Issues" in the CoffeeScript repo from angry hackers that were mad that CoffeeScript forces them to code with some modicum of responsibility (no drop-throughs in switch statements, no var shadowing, etc.). Doesn't make sense to me why people would blast JavaScript for letting you do stupid shit then get butthurt when a solution takes those same problems away.
But its worse, because its also a silent mistake. Shadowing could be forbidden but variable declaration and assignment could still be different things, and then the compiler could warn you when you try to re-use a name. But no, coffee script will give you random bugs instead.
JavaScript has its rough edges. CofeeScript simply has a rot right in its core.
When would implicit return make code better? Maybe I'm answering my own question, but I can see them being more readable to somebody coming from a Haskell or LISP background than to somebody like me who has worked mostly in C, Java, and Python.
Ruby also has explicit returns. The idea is, every statement is an expression, and so has a return value. You don't need to figure out about whether a statement does or not, it just always does. One less thing to have to think about.
Other things, too, but that's one that that sticks out for me.
Personally, though I'm looking at Dart rather than ES6.
delay = (ms, func) -> setTimeout func, ms
delay 100, -> console.log "100 ms passed"I'm curious which one will emerge, though.