"As my project grows in size, significant whitespace becomes more and more of a problem. It’s just plain not readable or visually parsable. Your files become a wall of dense text. Damn you Python, damn you to hell!"
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'm curious about this statement as well. It sounds like the author might be:
- 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.
I did find that odd. Whitespace helps you get away from "a wall of dense text." I'm not clear on how mandatory whitespace could exacerbate the "wall of dense text" problem.
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.
Anyone who has maintained Makefiles will have a strong opinion on semantic whitespace.
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?
I'd really like further explanation, too. If you're not properly indenting code in large projects — whatever the programming language is — I'd really hate working with you.
just want to drop another vote against against significant whitespace...
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).
The author uses CoffeeScript for completely different reasons than I do. While a lot of the convenience features of CoffeeScript are awesome, I use CoffeeScript more to compile JS to standards-compliant, consistent code. Variables are hoisted, commas are automatically inserted, semi-colons are taken care of, and the entire script is put into a lovely self-invoking function that helps fool-proof things.
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!
Unlike the author, I love significant whitespace and am enjoying nimrod lately with it.
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.
I love CoffeeScript and am excited about nimrod, but I don't see the point of TypeScript. Honestly I am fairly certain that it was largely created by Microsoft as part of the EEE strategy (http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish) since the main advantage of JavaScript is not having to supply types.
I don't do a ton of js programming, but I did poke around with cs a bit. For me, clean iteration seemed like the biggest win. And then I discovered underscore/lodash. So I don't do as much cs anymore.
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)
I gave CoffeeScript a shot, and frankly I don't like these JS "wrapper" languages.
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.
My point is JS tools work with JS as intended, and work with CS to varying degrees of success and with a variety of ways they handle CS. I was a C# developer for many years, so I know what I'm missing.
Also relevant: a big question is how CoffeeScript is going to deal with ES6 and the overlapping syntax between ES6 and CS, which may involve breaking backwards compatibility or leaving out ES6 features.
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.
Initially I got excited about CS, until I discovered that it forbids shadowing and conflates variable declaration with assignment at the same time, leading to random bugs happening all over the place as I introduce a name that I've used somewhere in a deeper scope. No, identifier names are one of the big problems of all languages and CS gives you even less name locality. Bad.
That would be true if there wasn't a very vocal swath of developers that won't even use a CS project out of prejudice, much less contribute to it. I don't know why that religious war came to exist, but it's the unfortunate reality.
Can anybody explain some good use cases of implicit return? When I was doing a project in CoffeeScript last year (the only time I've used it), I found myself just using the return keyword explicitly because it was more readable, and I never ran into the issue the article talks about where it can be bad to accidentally return something from a function that should return null/undefined.
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.
> 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.
I have similar issues with coffescript, specifically the pain of significant whitespace is noticable whenever I find myself recalling how to write a simple `setTimeout` (or any similarly structured function) calls correctly, which is pretty much every time I use one as I don't find it particularly natural or intuitive.
Personally, though I'm looking at Dart rather than ES6.
CoffeeScript is waning for me as well but not for the same reason: Dart and/or Typescript seem to be superior solutions, both backed by companies that are going to keep their language alive for a very long time.
the only thing from coffeescript i think i will end up really missing is switch expressions. When used with conditional assignment it makes for code that is far prettier and more concise than nested if-then-else chains.
[+] [-] omni|12 years ago|reply
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?
[+] [-] bengotow|12 years ago|reply
- 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.
[+] [-] jarrett|12 years ago|reply
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.
[+] [-] reeses|12 years ago|reply
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?
[+] [-] zachwill|12 years ago|reply
[+] [-] fat0wl|12 years ago|reply
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).
[+] [-] elwell|12 years ago|reply
[+] [-] rmrfrmrf|12 years ago|reply
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!
[+] [-] jbeja|12 years ago|reply
[+] [-] kodablah|12 years ago|reply
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.
[+] [-] ilaksh|12 years ago|reply
[+] [-] jgalt212|12 years ago|reply
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
http://sweetjs.org/
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.
[+] [-] pikachu_is_cool|12 years ago|reply
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.
[+] [-] subsection1h|12 years ago|reply
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.
[+] [-] ahoge|12 years ago|reply
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.
[+] [-] city41|12 years ago|reply
[+] [-] brianchu|12 years ago|reply
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.
[+] [-] elwell|12 years ago|reply
Quality, not quantity. Maybe the higher quality contributors are more likely to get excited about a cs project over js.
[+] [-] spion|12 years ago|reply
[+] [-] ricardobeat|12 years ago|reply
[+] [-] kansface|12 years ago|reply
[+] [-] city41|12 years ago|reply
[+] [-] bookface|12 years ago|reply
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.
[+] [-] mcphage|12 years ago|reply
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.
[+] [-] lucisferre|12 years ago|reply
Personally, though I'm looking at Dart rather than ES6.
[+] [-] ilaksh|12 years ago|reply
[+] [-] lucidrains|12 years ago|reply
[+] [-] tdumitrescu|12 years ago|reply
[+] [-] laureny|12 years ago|reply
I'm curious which one will emerge, though.
[+] [-] krallja|12 years ago|reply
[+] [-] AdrianRossouw|12 years ago|reply
[1] https://gist.github.com/Vertice/ac357533da976990dc4d
[+] [-] jbeja|12 years ago|reply
[+] [-] elwell|12 years ago|reply