
CoffeeScript's Time is Waning For Me - bpierre
http://mattgreer.org/articles/coffeescripts-time-is-waning/
======
omni
"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?

~~~
reeses
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?

~~~
aiiane
Which is why you set your editor to use something other than the same number
of spaces as your indent levels. It works especially well if one isn't a
multiple of the other - e.g. having the editor display tabs as 5-space width.

------
rmrfrmrf
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!

~~~
jbeja
I couldn't agree more.

------
kodablah
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.

~~~
ilaksh
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](http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish))
since the main advantage of JavaScript is not having to supply types.

~~~
kodablah
I disagree. TypeScript not only attempts to be inline w/ upcoming ES/Harmony
standards, but it is not pushed on you in any way. It's Apache licensed and
it's not like MS is putting a TypeScript VM in their browser. I love
TypeScript's typing system, especially type declarations which are based on
whether something has something vs on its named type (i.e. duck typing). There
are many editors from MS's free VS express to WebStorm plugins to event IDE's
written in TypeScript themselves. I find the language work by MS these days
(this, f#, etc) to be really community friendly as opposed to locking in.

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.

------
jgalt212
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)

sweet.js

[http://sweetjs.org/](http://sweetjs.org/)

pretty neat pattern matching library written with sweet.js

[https://github.com/natefaubion/sparkler](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
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.

~~~
subsection1h
> will have to waste a bunch of time learning it.

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.

~~~
pikachu_is_cool
A couple of hours is a quite a bit of time IMO. Especially if there's alot of
people that need to learn the language.

~~~
pikachu_is_cool
I mean, obviously a few hours isn't honestly that much. But in terms of the
actual benefit you're getting by learning CS makes it not worth it at all.
Workflow improvements are negligible (if anything, it probably worsens your
workflow because of the extra compilation step). There's no compelling
performance enhancement. You aren't getting any real benefit from learning
CoffeeScript other than some feel-good syntactical sugar.

------
ahoge
> _[tooling] is perfect with JavaScript_

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
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.

------
brianchu
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.

[https://news.ycombinator.com/item?id=6078969](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
> If you’re contributing to the JS community, you’re better off writing in
> JavaScript. More people will contribute and/or adopt your code.

Quality, not quantity. Maybe the higher quality contributors are more likely
to get excited about a cs project over js.

~~~
spion
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.

~~~
rmrfrmrf
I'd argue that that's a feature. You're _asking_ for decreased code
comprehension and bugs when you start using identical variable names
everywhere.

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.

~~~
spion
No, I'm not asking for bugs. I'm asking for a basic feature of natural
languages: to define a context where I work, where short, concise words have a
precise meaning. This is an elementary thing - its the basis behind
namespaces, the drive behind object oriented programming. Its a fundamental
design mistake to put limits on this.

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.

------
bookface
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.

~~~
mcphage
> 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.

------
lucisferre
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.

~~~
ilaksh
This is how I do setTimeout:

    
    
      delay = (ms, func) -> setTimeout func, ms
    

So you can write it like this:

    
    
      delay 100, -> console.log "100 ms passed"

~~~
lucisferre
The problem is it isn't the only situation this comes up in, and the fact that
this has to be done at all is a testament to the problems with adding
significant whitespace to a language not completely designed for it.

------
lucidrains
I hope coffeescript supports generators.

~~~
tdumitrescu
coming soon: [https://github.com/jashkenas/coffee-
script/pull/3240](https://github.com/jashkenas/coffee-script/pull/3240)

------
laureny
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.

I'm curious which one will emerge, though.

------
krallja
I avoided learning the fashionable thing for so long, now I'm fashionable!

------
AdrianRossouw
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.

[1]
[https://gist.github.com/Vertice/ac357533da976990dc4d](https://gist.github.com/Vertice/ac357533da976990dc4d)

------
jbeja
I literally stop reading when he start whi..talking about hate on significant
whitespace.

~~~
elwell
I literally hit downvote when he start whi..talking about whi..talking about
hate on significant whitespace.

~~~
jbeja
Unlike the whitespace in my code, your downvote is insignificant to me.

