

It’s all about being productive - coffeemug
http://savanne.be/791-its-all-about-being-productive/

======
paulbjensen
I've come to the view that CoffeeScript is the marmite of programming
languages, and that issues like this will rage on for years to come.

I'd dare and suggest that TJ is JavaScript's DHH; very talented and
productive, but also very vocal about he doesn't like.

Programmers are some of the most argumentative people that I know, my father
being one of them. When you're immersed in a community, it becomes easy to
develop the kind of language bigotry that happens between Rails and Node.js,
which is sad and regrettable.

I think that mature programmers see code for what it is and don't get
religious or wound up over these things; in the end of the day it's all a
bunch of 1s and 0s.

~~~
pbiggar
Thinking of food analogies: maybe CS is the salt of programming languages.
It's not great by itself, it's just slightly nicer than what you were using
before. No-one discusses salt by itself, but they see some bland food and know
it would be better with some more salt. Some people are addicted, but nobody
thinks salt sucks. Except some zealots, but you always try to change the topic
when they bring it up.

[not to argue analogies, of course; I see what you were going for]

~~~
bostonpete
Well, I believe our bodies need salt, so eliminating it altogether isn't
really an option. Maybe the paprika of programming languages...

------
pbiggar
I can't believe this is even an issue. CoffeeScript and JS are basically the
same language; CS just has a nicer syntax.

If these guys were going to be valuable contributors, they'd take the 20
minutes it takes to learn CoffeeScript and then actually try and contribute.
You'll suffer no loss "excluding" them from your project.

~~~
mtrimpe
> CoffeeScript and JS are basically the same language; CS just has a nicer
> syntax.

I especially like how TJ authored yet another CSS preprocessor, yet takes the
time to ridicule CoffeeScript which is essentially just a JavaScript
preprocesser.

------
Riesling
I wonder how much of the hate for newer and easier approaches stems from the
fact that people made an investment by learning a more complicated technology
and are now trying to protect this investment by ridiculing the new approach.

~~~
calinet6
My problem is that it's not _really_ a newer and easier approach, it's a newer
and _slightly different_ approach. Javascript was a perfectly good language to
begin with, Coffeescript just made it shorter and with a bit different syntax
here and there and with a feature or two for handling closures better. Not
bad, surely, but not really that great either. My experience working in
Coffeescript so far has been that it's still important to understand the
javascript it's going to be translated into, to understand the subtleties of
closures and scope as they're implemented in coffeescript.

Why, then, use coffeescript? It's so much clearer for me to simply see that an
anonymous function is being defined to pass this scope and do this yada yada,
and while longer, I much prefer that over a language that hides the true
meaning in an attempt to reach some sort of syntax simplicity that doesn't
really have that big an effect in the end. It's not a protection of an
investment, it's that I can't imagine ever being able to use or understand
Coffeescript without _also_ having an expert grasp on Javascript. I don't know
of anyone who knows Coffeescript on its own. You still need to understand what
it's doing, fundamentally; or at least, it's useful to; or failing that, it's
_right_ to understand it.

I don't know if I want a developer who knows only Coffeescript. I don't want
someone who doesn't understand what it's being compiled into. Frankly, the
same goes for other languages: you really should understand what assembly
fundamentally does, and how your IF statements and loops are translated. It
makes a ton of sense that we don't write our code in ASM these days, but for
Javascript it just seems lazy. Javascript is a perfectly serviceable extremely
high-level language. It's not that hard to learn or to work in, and if you
know it well, it's actually quite nice and has many interesting features.
Coffeescript, as a rejection of Javascript, makes little sense to me because
Javascript just isn't that bad.

However, Coffeescript as a response to wanting another language on the web;
wanting a slightly clearer syntax for writing asynchronous callbacks and
classes and whatnot—sure, that makes some sense. It just still feels dirty. At
its most basic level it just feels like a lazy hack, because it's layered on
top of this other perfectly useful high-level language that might be 50% more
lines of code, but would work perfectly fine.

What it really means is that the browser is the new CPU and Javascript is the
new machine code. It's just another layer of abstraction. In the end, I don't
like it because Javascript is just not that hard. I imagine this is echoing
the arguments of C die-hards upon the advent of newer, higher-level languages.
It all makes sense, but sometimes it's hard to swallow.

~~~
beat
As a former C programmer who truly loves C... I wouldn't use it DIRECTLY for
anything except things that couldn't be done in any other language, things
where you really need that fine-grained memory control for performance or
deeper technical issues. By all means, wrap code in more abstract languages!

I feel the same about Coffeescript. A while back, I spent a couple of months
as a full-time Javascript coder. I like a lot of things about JS, but the
line-noiseish syntax (especially around callbacks and anonymous function
declaration) was damned annoying. Compared to its elegant-syntax
contemporaries like Ruby and Python, it felt awkward.

Coffeescript is a hack, yes, but it's a nice one. It plagiarizes some of the
best syntax ideas from more graceful languages (list comprehensions, splats,
whitespace significance, etc), and adds them to the good ideas and
functionality of JS. I agree that in order to write good Coffeescript, you
should be able to write good Javascript too, in order to see the gotchas. But
that doesn't mean a preprocessor is a bad thing, not if it gives this much
readability and functionality.

Sadly, I think there's a bit of machismo involved in the sneering at
Coffeescript, not a real technical issue.

------
joshontheweb
Gotta go with TJ on this one. I am unlikely to use it if it is written in
coffeescript. If the rest of your codebase is in coffeescript I guess it could
make sense but how many projects is that true for outside of Rails apps? I am
deterred by the idea of adding the extra over head of having to use another
style and fracturing my codebase. Just my two cents.

~~~
coffeemug
Slava @ rethink here. I'd like to understand your reasoning a little more --
could you explain what would turn you off from the driver? The node package
ships as Javascript, and the API is extremely rigorously defined. If you use
it from your Javascript app you never have to think about Coffeescript, nor
even know that the driver is maintained in Coffeescript.

This is an implementation detail that _shouldn't_ affect anyone but potential
contributors in any way. Would you mind taking a moment to explain your
rationale? (it would really help us)

~~~
h2s
It's because incorporating any open source product into your own project means
you _will_ need to read and/or modify its source code eventually. I work
around deficient documentation by reading source code several times every day.
And eventually you're gonna need to report or fix a bug, or in the best-case
scenario add a feature yourself.

The sensible answer to this is "just learn CoffeeScript, then". I guess a lot
of people don't want to, for whatever reason. Personally, I know I'm still a
bit skeptical of the whole affair myself. The alternative to reading and
learning CoffeeScript would be reading compiled JavaScript code. As somebody
who occasionally works on something that compiles JavaScript, I know from
experience that reading that stuff isn't very fun either!

~~~
coffeemug
I suppose this makes sense. In my experience, overwhelming majority of people
using open source software never read the code. Some minority of people _do_
read the code (but in that case, they'd be reading Javascript because that's
how we ship the driver). A small proportion of the people reading the code
actually end up modifying it themselves, and this admittedly is a problem
(though I find Coffeescript so easy to pick up, I don't think it's a serious
barrier for anyone who really wants to make changes).

~~~
whateverfor
Not that it's really an issue here because Coffescript is basically Javascript
anyway, but legible source is important even for developers who don't end up
reading it.

The people who actually read the code are a small subset of the group that
depends on being able to read the code if necessary. I haven't needed to dive
into the source for everything I've integrated into a product because of
inadequate API documentation or bugs, but it happens, and it's not something
you can generally tell ahead of time.

------
lazyjones
I can't agree ... BASIC was an extremely productive language, and so is Perl,
but both are a terrible bet in the long run due to
debugging/maintainability/readability issues. Being able to throw new code at
something isn't everything, unless you plan on throwing it all away after 5
years in favor of the next fad.

~~~
rubenv
Works both ways really, people might hate your project because you stick to
old & known C, rather than write it in e.g. Go.

~~~
lazyjones
Go is a _great_ language for maintainability, much better than C. So it would
be a good choice and arguably quite productive too.

~~~
rubenv
That's sort of not the point here. It's not always that "new fad" is better
than "old and established", it might be the other way around.

What matters is what's most productive for the project, for the people working
on it.

What doesn't help is making a fuss about it. Spend your time contributing and
get over the fact that not everyone thinks the same. Or walk away, because
nobody is forcing anyone to get involved.

Let's just stay constructive and respect what people are doing.

If you really want to do it differently, just go out and do it, prove people
wrong with results, rather than arguments and flames. That way everyone wins.

------
jongold
Well I've just lost a lot of respect for TJ - shame really.

~~~
jameswyse
Why? He just stated his opinion that JavaScript drivers should be written in
JavaScript which is an opinion many of us share. He's quite well known for
speaking his mind and he was even fairly polite about it in the GitHub
discussion.

It's stuff like this: <https://github.com/visionmedia/express/issues/1613>
that makes me lose respect for people.

~~~
jeswin
Complaining about an open source project's language choice is a bit much.
Issue 1613 would have been inappropriate only if it wasn't in response to TJ's
views on the rethinkdb thread.

And plain JS has many warts is an opinion that some of us share.

~~~
jeswin
EDIT: Not saying that I have lost respect for TJ. But the link you posted
wouldn't matter to me either. It's just a joke.

------
alessioalex
TJ didn't even know it was written in CoffeeScript. He ignored the whole repo
after finding out. Stop overreacting.

While I agree on the productivity issue, I think developing in CoffeeScript
imposes an unnecessary barrier for other people. Basho guys felt the same for
their Riak driver: <http://basho.com/a-fresh-start-for-riak-js/>

------
drorweiss
Code and religion don't mix well

------
michaelochurch
I would say the same thing-- "it's all about being productive"-- with regard
to technology wars but I take a different stance. I'm not going to limit the
focus to OS projects, though it applies to them, but also to peoples' jobs.

When Ruby programmers brag about being "Java-free for 5 years", as the
stereotype goes, what they would mean to say if they had more insight into the
situation is that they've been in _high-productivity_ programming for 5 years.
That's what actually matters. Language correlates somewhat to low vs. high
productivity, but it's actually the productivity level that matters.

On one side, there's the risk-averse corporate bullshit where you do what a
boss tells you to do and you're lucky to crank out 10 LoC per day, because
most of what you do is maintenance and catch-up and filling out on makework so
you can be evaluated (in a years-long dues-paying period) for real work, which
is allocated as a political token. Working in those jobs rots your brain, but
that probably what 75+ percent of professional programmers face.

Then there's high-productivity programming, in which you write code like it
actually matters, because it does. 100-500 delta-lines per day is typical.
(That doesn't mean you grow the codebase by 100 lines; removing 100 lines can
be just as potent.) Every day, you leave the state of the software in a
materially better state than it was in when you began the day (or,
occasionally, you fail to do so but you improve your _knowledge_ ).

Risk-averse manageosaurs like low-productivity programming because it's "safe"
and easy to commoditize. Scaling up means hiring five times as many
CommodityDevelopers. It also makes it easier to undertake Big Software
projects-- monolithic Java/C#/VB programs, with bulky Despondency Infarction
Frameworks attached, on which disengaged developers plug along at 7.35 LoC per
day. It is, however, a horrible way to build software. It makes awful
products, and it's bad for peoples' careers (except managers) because people
actually decline as the years go on.

That's what's actually at stake in language wars. It's not worth it to
alienate whole communities because you think Ruby is slightly better than
Clojure or vice versa. Agree to disagree, and use the right tool for the job
(which may be the other guy's language just because you're in a better
position to adapt than he; deal with it). It is, however, worth it to fight
for a high-productivity environment and to name and shame the horsemen of the
low-productivity apocalypse.

Unfortunately, there are a lot of people who associate JVM => low-productivity
programming and Ruby => high-productivity when they're only catching one slice
of the story. A true high-producitivity programmer uses the right tool for the
job-- sometimes Ruby or Clojure, sometimes C, sometimes Python, sometimes
Scala.

I do hate hate hate low-productivity programming. God intended the programmer-
to-program relationship to be one-to-many, not many-to-one. However, I don't
think it's useful to attack everything _Java_ just because of the historical
association (I used to be that way; then I grew up). Corporate hell is not
James Gosling's fault.

