It’s all about being productive
savanne.be
savanne.be
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]
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.
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.
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)
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.
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/
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.