It might not be as 'hard' conceptually to use, but it just has some dirty areas that are sort of make it unpleasant to use so it leaves a bad taste in some programmers mouths.
* 0 == '' is true, really? what about 0 == '0', also true!
* What is 'this'? Well it depends on where you are and there is a long article someone posted somewhere. To figure it all out...
* Brace block != new scope.
* No nested namespaces -- all is in a global scope.
And there are others. Again. Not hard just kind of unpleasant, therefore CS.
Because someone wanted to? Folks are using it. Isn't that enough for you? On top of that, it's quite a nice little language. Comprehensions are very convenient along with regular iteration. And you get most of the jslint passing stuff for free. Plus, if you don't like it, don't use it.
I suggest you play with it a bit. It really is a "nicer javascript". The only thing it's missing is support, primarily in the form of debugging tools. But that's coming.
Experimenting and trying out new things is good in principle. Even if you don't agree with this, here's an example of JavaScript taking feedback from CoffeeScript: http://brendaneich.com/2010/11/paren-free/
jashkenas (CoffeeScript author) replied to you, but for some reason he's deadbanned:
> Thanks for mentioning it -- the fix was actually to correct a regression from a previous commit, not a true bugfix versus 1.0.1. I've removed that line from the changelog.
I (now) know that Red Dead was banned in the UAE, and pictures of the US military dead are banned by the Pentagon, but what is 'deadbanned' in this context?
If you're banned here, you aren't locked out of the site or prevented from posting. Your posts are just marked so that only you (and other users who have chosen "show dead comments" in their preferences) can see them, and there's no indication that you've been blacklisted. It's terrible.
I'm starting to really dig coffeescript. Using it in a new project and can see what people are raving about.
I wish there were better examples of creating cakefiles though. Little documentation on this. I think it assumes that everyone has a ruby background. I'd like a cakefile with a task to compile all of my .coffee files. Seems like that should be easy, but I don't see an example of how to do it.
I've looked into CoffeeScript, and while I really like the sentiment—routing around JavaScript's warts—I fundamentally disagree with the technique employed to achieve the goal.
What the world needs is less syntax, not more. Perl, Ruby, and Haskell—the inspirations for CoffeeScript, as near as I can tell—are, as a recently-linked entry called Perl, programming languages that you have to constantly use to keep your programming skills.
For all its problems, as long as you can remember to use === and friends instead of ==, JavaScript's syntax is relatively obvious, if unweildly, to anyone who grew up in a C dominated world.
Fargo, the recently-linked Scheme in JavaScript, is something I an get behind personally, though sadly Clojure is becoming the default Lisp my mind thinks in.
We need to declare a moratorium on new syntax. With Lisp, C, Python, and a couple other languages (maybe), we have all the syntax we need. Novelty is not innovation. New is not better.
We live in a world where utility players, i.e. everyone in a startup, already have to think in terms of too many different languages.
We all agree that some syntaxes are better than others. So you're willing to settle for JavaScript; that's cool, CoffeeScript is 100% compatible. (More than, if you consider that even bad CS compiles to good JS.)
But complaining about novelty reeks of telling us kids to get off your lawn. Some syntaxes are better than others. We haven't found the best one. Innovation is still possible. Hackers innovate. Get used to it.
I think that hackers invent, not innovate. Innovation is too risky to be taken by one or even little group. It is something between an act of changing values (or axioms) of system and the process of that system change.
I also think that innovation is too pompous term in the discussion of programming languages syntax.
Invention is much lesser term and much more nimble. And it could provoke innovation, of course. But for innovation we need semantics more than syntax, I think.
Ehm, I've been programming in Python for quite a few years now, and CoffeeScript syntax is pretty much Python with a smattering of Ruby (or the other way around), and some niceties like using the question mark for safe navigation or having "yes" as an alias to "true". That hardly makes for a sigil overdose.
I guess you have had some experience that explains this sentiment of yours, even though I can't guess at what it is.
To me, CoffeeScript is pretty much to Python as Clojure is to Common Lisp, as far as syntax is concerned. It's similar enough for syntax not tripping anybody up.
One of the problems with JavaScript's C-like syntax, IMO, is that it makes people think in a C-like way. CoffeeScript's syntax brings out the functional qualities of JavaScript in a nice way. Writing CoffeeScript makes me a better JavaScript programmer.
Further, if you're working on a Node stack there are a few levels where CoffeeScript and JavaScript can interact. Different modules can be written in either language. You can expose a http.Server interface in your application. If you're on Connect/Express, you can mount routes to apps written in either language, or even Zappa.
And if you want a moratorium on new syntax, I suggest you stop learning new syntax. I look forward to a future where syntax moves further into the background.
My experience stems from learning the language of the week for twenty years until getting serious about learning lisp, and coming to see that syntactic innovation at the language parser level is a waste of time. Syntactic innovation should occur through a macro facility that gives everyone, not just the parser-writing language gods, tools to build a language that suits their needs.
That is why CoffeeScript is ultimately uninteresting if perhaps useful to people who don't understand or are not in a position to use lisp.
In my experience, JavaScript's syntax has never encouraged people to think in a C-like way. In a Java-like way, perhaps, but not really even then. People seem to get, if they're remotely clueful, that JavaScript programming calls for a lispy approach. It's all the damn parens and (optional) semicolons and braces and no-win indenting scenarios that frustrate people who try to exploit JavaScript to its fullest.
Yes, CoffeeScript solves these problems and others, but through the introduction, as I said before, of yet a new set of rules that result in whitespace-sensitive line noise code that requires frequent contact to stay familiar with. And again, I'm a busy person: a new language wastes my time because I already need to write shell scripts, Clojure, and Python in a daily basis. I know JavaScript, even if I dislike it.
And if you're going to learn a language that doesn't help your resume with The Man, you may as well learn a language that can change your life. Like a lisp.
Lisp's flexibility is more of a theoretical advantage. In practice, particularly in common programming contexts, I think it's more valuable to have a richer, standardized syntax. Sometimes its better to nail down a few degrees of freedom in order to better exploit others.
I agree and disagree with you. Vehemently. Most programming tasks will not require writing macros because most programming tasks amount to solving understood problems. But those programming tasks will be accomplished and made tractable and tolerable through the use of macros that someone else wrote.
Think of the analog of writing a desktop application: there are many object-oriented desktop app frameworks where you can write pretty rich apps exclusively by instantiating existing classes, and this is possible because some domain experts designed a framework for writing desktop apps.
Macros—which I've been using as a shorthand for "syntactic innovation"—are the same way. Someone writes e.g. a web application framework that consists of some macros, perhaps of deep skankiness, that let you write clean, obvious code that solves whatever problem in the web application domain that you're currently confronted with.
I've heard this argument made many times, but where's the evidence? If true, we should see Lisp used disproportionately at the cutting edge of software design. Lisp is somewhat more common in these contexts, but no more so certainly than languages without macros like Erlang & Haskell.
I will grant you that people are doing interesting things in languages other than lisp, and in that in many of those situations, when the results are interesting, you see lispers smugly replicating those systems and saying, "That was easy; we could've done that." But they didn't.
That said, I think the various lisps out there have plenty of user—and by that I mean programmer—success stories. My favorite right now is Cascalog. It's an amazing, life changing tool for anyone who needs to analyze data sets using Hadoop. It makes something that would otherwise be too difficult (given the time I have) to even try to do into something that is fun. Nathan Marz, Cascalog's author, should be considered for a MacArthur genius grant.
Cascalog, incidentally, would not be nearly so amazing if not for the relatively few macros that tie everything together.
Someone please tell me what Hadoop, PIG, HIVE, Cascalog, et al. are doing that is fundamentally new? Reinventing the unix FILE, unix pipes, lisp, awk, sed, grep in a new "distributed bash shell"?
I don't think this stuff, while brilliant and clever and useful, qualifies for a MacArthur grant when one is standing on the shoulders of N CS giants reimplementing their ideas with few truly novel improvements.
MaCarthy, Kernigan, Thompson, Richie, McIlroy etc are those giants.
Nathan went to one of the Clojure meetups in S.F. I didn't get a chance to talk to him but somebody else did a demo of Cascalog there. Cool stuff, I agree, and a good example of the flexibility of Lisp.
I think a lot of people would still balk at the syntax though, and prefer something with similar functionality and more comfortable syntax, even if it was a lot more work to implement such a thing.
syntactic innovation at the language parser level is a
waste of time
We are all language parsers. CoffeScript makes that easier to do. It may make very little difference what to parse to the computer, but it may be big for us, humans.
learn a language that can change your life. Like a lisp.
Whoa. The language that changed my life (a bit) was English.
And by the way, do you literally mean lisp, or just functional paradigm?
I think CoffeeScript is easier for certain values of "easier". My position is that there are important senses in which easier can mean harder. You know, like how worse can be better.
I literally meant a lisp. I'm a big fan of mostly-functional programming, but a functional tendency is just one of the features that hang together—along with the absence of syntax and lexical scoping and macros and maybe something I've forgotten—that make lisp what it is.
My natural style is polemical. My thoughts tend to the nuanced. That's often a bad combination.
I totally respect that CoffeeScript is just not your cup of tea. But non sequiturs like "it's whitespace-sensitive line noise code that requires frequent contact to stay familiar with; use lisp instead" are elitist, unhelpful and just not likely to convince anyone about anything. Really, why that tone?
I'm really not being that much of a hater. If I had the freedom to choose one language and use it for everything, I might not have a problem with a language that possessed the terseness of APL or Perl or Haskell or whatever. If a language truly were the Hundred Year Programming Language, that would be fine, because the investment you make in it would pay dividends for the rest of your life, and you could keep it in your head because you'd be using it all the time. But we don't live in that world.
It's an open, actively-worked-on ticket -- and it's not just CoffeeScript debugging support. It's proper line + column number mapping for anything that compiles to JS.
It'll be a boon for straight-up minified JS as well.
Might be more interesting if V8 would support CS as an input language to compile natively in addition to JS -- this would have CS "natively" in Chrome and Node.
But then, things work fine as they are. Compiling CS to JS is not a huge performance hit and it's either part of your build chain or a one-off hit at your apps startup.
That wouldn't be useful except for debugging. You can already do this if you also include the compiler. You'd never want to include uncompiled coffeescript in production, it can't be minified to the extent that js can.
What exactly do you mean by "can't be minified to the extent that js can"? Why is that? CoffeeScript files are usually about 1/3 smaller than corresponding JS to begin with.
Well, I meant that whitespace is significant in coffeescript whereas it isn't in javascript. You have a point though, coffeescript isn't nearly as wordy as javascript so it's much less code.
I just think it'd be nice to have another scripting language for the web after all this time of JS being the sole king. And I think CS would be great because it's still very similar.
