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.
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)
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!
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).
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.
> The sensible answer to this is "just learn CoffeeScript, then".
No, the sensible answer to this is "just read the compiled JavaScript". CoffeeScript compiles down to very nice, readable JS. I would even go so far as to say that compiled CoffeeScript is easier to read than 90% of the JavaScript you'd typically find in a open-source project.
I'm trying to see what's offensive about learning CoffeeScript, or at least enough to read it? It's a 20 minute challenge at most, and at the end you've learned something.
I don't understand how the driver being written in CoffeeScript affects your ability to use it. You can download a precompiled (JS) version of the driver and just use it, right? You don't _need_ to write CoffeeScript to use the driver.
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.
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.
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.
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.
He's a great programmer and also a great troll. Yes, that's possible. Personally, I think it makes him more fun, but that might just me being too immature / non-boring.
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.
> 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.
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.
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]
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.
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.
My problem is that it's not really a newer and easier approach, it's a newer and slightly different approach.
Very much this: to those who would say, "oh, you're just invested in the old technology" I would say yes, I am; but I also posit that you are overblowing minor differences in a newer approach merely because it is newer. Even if it is significantly different, that doesn't make it better; not all change is progress. When I see something that gives me a significant advantage, whether it's old or new, I'll take it. But I'm also very discerning in what I invest my limited time and brainpower in, and throwing away previous experience, sunk though that cost may be, is foolish without good reason.
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.
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.
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/
32 comments
[ 4.0 ms ] story [ 33.7 ms ] threadThis 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)
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!
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.
No, the sensible answer to this is "just read the compiled JavaScript". CoffeeScript compiles down to very nice, readable JS. I would even go so far as to say that compiled CoffeeScript is easier to read than 90% of the JavaScript you'd typically find in a open-source project.
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.
Is C inherently unmaintainable in your opinion? Or just badly written C?
It's stuff like this: https://github.com/visionmedia/express/issues/1613 that makes me lose respect for people.
And plain JS has many warts is an opinion that some of us share.
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.
I especially like how TJ authored yet another CSS preprocessor, yet takes the time to ridicule CoffeeScript which is essentially just a JavaScript preprocesser.
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.
[not to argue analogies, of course; I see what you were going for]
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.
Very much this: to those who would say, "oh, you're just invested in the old technology" I would say yes, I am; but I also posit that you are overblowing minor differences in a newer approach merely because it is newer. Even if it is significantly different, that doesn't make it better; not all change is progress. When I see something that gives me a significant advantage, whether it's old or new, I'll take it. But I'm also very discerning in what I invest my limited time and brainpower in, and throwing away previous experience, sunk though that cost may be, is foolish without good reason.
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.
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.
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/