Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: CoffeeScript: Accelerated JavaScript Development

samzenpus posted more than 2 years ago | from the read-all-about-it dept.

Book Reviews 100

Michael J. Ross writes "For decades, programmers have written computer code in one language, and then programmatically translated that code into another, lower-level form (typically machine code that can be run directly by a microprocessor, or some sort of bytecode that can be interpreted by a virtual machine). For instance, source code written in C or C++ is compiled and assembled into machine code. In web programming, there are emerging languages and other tools for translating code into JavaScript. For instance, Google Web Toolkit allows the programmer to create web apps in Java. The latest addition to this category is CoffeeScript, a language that can be compiled into JavaScript, and is intended to reduce source code size and clutter by incorporating some of the best operators from other Web scripting languages, particularly Ruby. It is also the topic of a new tutorial, CoffeeScript: Accelerated JavaScript Development." Read on to learn what Michael thinks of this book.This book is authored by Trevor Burnham, who is credited as one of the early contributors to the project by Jeremy Ashkenas (the creator and project lead of CoffeeScript) in his foreword to the book. Published by Pragmatic Bookshelf on 3 August 2011, under the ISBN 978-1934356784, CoffeeScript: Accelerated JavaScript Development fills only 138 pages, which is certainly a change of pace from the majority of programming tomes now being released. This book's material is grouped into six chapters, plus four appendices — aside from a preface, which introduces CoffeeScript as well as a word game, which is used as the example project throughout the book. Oddly enough, the preface mentions jQuery, but not as one of the well-known attempts to streamline JavaScript code.

The first chapter, "Getting Started," begins by briefly explaining how to install Node and npm (Node Package Manager). These instructions assume that you are following along in a Linux environment or some emulation thereof. They also seem to assume that nothing goes wrong in any of the steps, because no troubleshooting guidance or references are provided. Given the number of moving parts required to get CoffeeScript running, as well as the technical pitfalls that could ensnare a Windows or Mac user, the author should have provided more clear and detailed installation instructions. Also, readers unfamiliar with Linux/Unix may be puzzled by some of the instructions. For instance, page 3 appears to state that the way to check that those two aforesaid packages are on your path, is to simply type in "PATH" (whereas what is needed is "echo $PATH"). From that point forward, the narrative gradually becomes more opaque, with cursory coverage of text editor plug-ins, the "coffee" command line compiler, REPL, "the soak" (an existential chain operator), and the limitations of trying to debug CoffeeScript code. It is quite possible that by the end of this chapter, many readers will decide to not bother trying to learn CoffeeScript, and instead to stick with plain JavaScript, possibly supplemented with jQuery (which is not to say that jQuery code is any easier to read).

In the next three chapters, the author presents the basics of CoffeeScript, including how to: define and use functions and their arguments; test conditionals; throw and catch exceptions; understand variable scoping and context; create arrays using splats; accept input from the console; create objects, arrays, and soaks (in more detail than before); iterate over collections; match patterns; define namespaces using modules; and create prototypes and classes. He makes extensive use of examples, which thankfully are concise (unlike some programming books whose example code span far too many lines, and sometimes even multiple pages — forcing the reader to dig through the code, trying to find the important lines). Also, the brevity of CoffeeScript syntax is undoubtedly a factor. However, his concise style extends to the narrative as well, and will likely cause newbies to have to read the material several times — and even then wonder whether they fully grasp the concepts. It seems that the author understands CoffeeScript extremely well, but is not always able to communicate that knowledge to the reader in a patient and comprehensible manner.

Chapter 5 is a primer on jQuery, and is apparently included in the book so that the example application (the word game) can be made to work in a web browser — since none of the code or narrative (aside from the example app) appears to be related to CoffeeScript. It would have been more efficient to simply point the reader to an online jQuery tutorial, and then present only the CoffeeScript-specific differences — or just briefly explain how to load CoffeeScript files in an HTML file, which could have been done in a sidebar. The last chapter demonstrates how to run CoffeeScript on a web server, utilizing Node.js, and also explores how the lack of threads in JavaScript can impact Node programming. The example project is made multiplayer using Node, Connect, and WebSocket.

The appendices provide answers to the end-of-chapter exercises, alternative methods of running CoffeeScript code, a JavaScript cheat sheet, and a list of a half dozen bibliographic references. This book concludes with a suspiciously-short index, at less than three pages long, which appears to provide only the first or earliest occurrences of the major terms. Consequently, anyone who tries to use this book as a reference work for looking up key terms quickly — or for finding their later occurrences — will likely need to obtain an electronic version of the book, since all e-readers have search functionality. Furthermore, the index is missing some key terms used in the text, such as "function callbacks" and "arbitrary expressions" — heck, it's even missing "expressions," a fundamental concept in any programming language.

Prospective readers who wish to learn more about the book, can visit Pragmatic Bookshelf's page, which offers brief descriptions of the book and its author — as does O'Reilly Media's page. But, as of this writing, only the former makes available an e-book version, pre-publication reader comments, a discussion forum, the example source code used in the book, and a link to a page for reporting errata, which already has more than half a dozen items listed. More are present in the text: "add [a] multiplayer capability" (page xx); a lone ")" missing its matching "(" (in Exercise 6, page 34); "in a lot in functions" (page 107; should read "in a lot of functions"); "a[n] overhead" (page 110); "everyone and their dog is" (page 116).

The author's writing style is sometimes quirky, which in most cases adds a bit of levity, but occasionally leads to the misuse of terms, e.g., array ranges usage described as "fantastical" (page 43). "BDFL" (page xiii) will prove puzzling at first to most readers. On page xvi, the reader is told that JavaScript "contains multitudes." — multitudes of what? And nothing can excuse the groan-inducing "automagically" (page 100).

In terms of the ordering of the topics, one of the most exasperating aspects of this book is the way that many language concepts — such as chained comparisons, and variables being true or false (or "truthy" or "falsy") — are not presented up front, on their own, but mixed in with discussions of other topics, including development of the game application, and even in the answers to the chapter questions (Appendix 1). This makes the book generally unsuitable as a reference, especially when combined with a disappointing index.

One might assume that the modest size of this book is a result of the small size of the language itself. But another factor is surely the pithy presentation style for even some of the most important concepts in the language. Perhaps worst of all — especially from the perspective of someone relatively new to programming — some basic concepts are not addressed, or the example code does not address common use cases. For instance, in CoffeeScript, how does one create a block consisting of multiple lines of code? On page 17, indentation is briefly mentioned, but the sample code shows single-line blocks only. Other important ideas are "saved as an exercise" (which may induce flashbacks to exasperating technical college textbooks). Some readers may conclude that the author didn't want to make the effort of fully describing the language, in a more canonical fashion, which would have resulted in a much longer, but more valuable book.

It is unclear as to how much of the likely mystification and frustration of the average reader will be due to the writing choices made by the author, and how much can be blamed on the sometimes cryptic syntax of CoffeeScript, evident in the discussion of topics such as function binding (Chapter 2) and keywords (e.g., from page 106, "what.x and @x are, of course, equivalent if and only if what is this." Of course!). Readers are told in the introduction that they do not need to be experts in JavaScript to understand the book's material, and can be amateurs (page xviii). But there are several places in the book where intermediate-level knowledge, at a minimum, would be needed. That sort of difficult material may be another point in the CoffeeScript journey where some readers will decide to eschew learning the language.

The production quality of the book is fine, except that the chosen font's ratio of height to width is more than what is usually found in books nowadays; when combined with inadequate spacing among the words within many of the sentences, it makes it difficult for the reader to rapidly scan the material. The e-book version reflects the same minor problem. Yet it makes excellent use of color for syntactically highlighting the code — a feature not seen in the print version.

So if you would like to do some JavaScript programming, but without writing any JavaScript, then one possible place to start your journey is CoffeeScript: Accelerated JavaScript Development. As of this writing, it is the only CoffeeScript book on the market. Yet should the language continue growing in popularity, then more substantial and recommendable books will probably become available.

Michael J. Ross is a freelance web developer and writer.

You can purchase CoffeeScript: Accelerated JavaScript Development from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

100 comments

Sorry! There are no comments related to the filter you selected.

What's wrong with jQuery? (0)

Anonymous Coward | more than 2 years ago | (#37268496)

It is already the write less, do more library...

Re:What's wrong with jQuery? (0)

Anonymous Coward | more than 2 years ago | (#37268592)

Obligatory xkcd

https://www.xkcd.com/927/ [xkcd.com]

Re:What's wrong with jQuery? (0)

Anonymous Coward | more than 2 years ago | (#37268762)

Obligatory XKCD
http://xkcd.com/865/ [xkcd.com]

You have to click it! CLICK IT NOW!!!!

Re:What's wrong with jQuery? (-1)

Anonymous Coward | more than 2 years ago | (#37268596)

yes but there are more important questions. does the word "nigger" offend you? what are your feelings about niggers? do you not agree there is a big difference between a person of African descent who cares about other people and has a legitimate job and tries to better himself and responsibly raises his family versus a ghetto nigger who will hate your guts just because you're white, who sells crack for a living, joins a gang, and abandons his many bastard children so they too can embrace thug life in the near future?

if blacks ever accomplished ANYTHING of lasting value like just one stable black nation, or one revolutionary technological advancement, or if having lots of blacks in a neighborhood meant it was improving and becoming a more pleasant place to live (instead of what that means now that your once beloved home is turning into a crime-ridden drug-filled ghetto where it's not safe to walk the streets), ANYTHING like that, ANYTHING AT ALL, that would do more to end racism than all the liberal political correctness brainwashing in the world. no doubt about it.

Re:What's wrong with jQuery? (-1)

Anonymous Coward | more than 2 years ago | (#37268644)

This is insightful.

Re:What's wrong with jQuery? (1)

rtfa-troll (1340807) | more than 2 years ago | (#37268636)

Which part of "You can use any existing JavaScript library seamlessly (and vice-versa)." is it that you are unable to read?

Re:What's wrong with jQuery? (1)

Anonymous Coward | more than 2 years ago | (#37268866)

I think he's trying to say why do you need an additional wrapper when JQuery makes it really easy on its own? Specifically isn't it pointless to write JS in ruby when you're not using ruby anyhow? Why bother learning another language just to write javascript.

Re:What's wrong with jQuery? (1)

slim (1652) | more than 2 years ago | (#37273256)

CoffeeScript isn't really a whole other language. It's Javascript, but with a new and -- arguably -- nicer syntax. There's an awful lot more to a language than syntax. Syntax is one of Javascript's weakest areas.

Why do people choose Javascript? Not, generally, because it's a beautiful language. More because it's the only language natively available for manipulating the DOM in a browser.

Node.js is an interesting rebuttal to that argument. It seems to be very popular, despite there being plenty of alternatives on servers. I sense a few of reasons for this. One is a bunch of web developers have JS skills they honed on the browser, for the reason given above. Another reason is that the callback oriented programming style required by Node.js is familiar to people writing JS for the browser. And finally -- a technical reason -- because you can now write code once, and run it both on the client and the server.

I really like CoffeeScript. It takes an afternoon to learn, it protects you from some of JS's nastiest gotchas (e.g. the weirdness of '=='). It frees you up from the parenthesis hell you get in JS, especially when using anonymous functions as parameters to function calls.

Re:What's wrong with jQuery? (1)

rock_climbing_guy (630276) | more than 2 years ago | (#37274860)

Can you please elaborate on what you think is wrong with JavaScript syntax?

The only thing I find wrong with it is that its seeming similarity to Java and C# makes it easy to expect something in JavaScript to act like something in C#.

Re:What's wrong with jQuery? (1)

slim (1652) | more than 2 years ago | (#37275130)

Without being too exhaustive...

When written in the Crockford-approved idiom, I find it awfully verbose:

MyClass.prototype.myMethod = function (x,y) { ... }

When working in a functional style (and it would be a shame not to) I find bracket management terribly fiddly. It's common to find yourself struggling with ')})});' -- it's worse than LISP, since at least with LISP all the brackets are of the same type!

But mostly, it's a subjective feeling that there's a load of punctuation and fluff on screen that gets in the way of the meaning of the code.

I keep forgetting that parentheses are optional in CoffeeScript function calls; I always feel the code is clearer when I remove them.


streams[i].pipe(streams[i+1]) // versus
streams[i].pipe streams[i+1]

Re:What's wrong with jQuery? (1)

overlordofmu (1422163) | more than 2 years ago | (#37276986)

I will take this as an opportunity to demonstrate restraint and ask you politely to show some respect for LISP.

Parentheses and white spaces alone do make some magically readable code once you become accustomed to it.

Re:What's wrong with jQuery? (1)

slim (1652) | more than 2 years ago | (#37283760)

I did not for one second intend to demean LISP.

Re:What's wrong with jQuery? (0)

Anonymous Coward | more than 2 years ago | (#37268870)

Can you use qooxdoo with it easily?

http://www.qooxdoo.org

Re:What's wrong with jQuery? (1)

rtfa-troll (1340807) | more than 2 years ago | (#37269976)

That's definitely what Google suggests..

Re:What's wrong with jQuery? (1)

slim (1652) | more than 2 years ago | (#37273270)

Think of CoffeeScript as a Javascript generator. You can generate any JS with it, including JS that calls qooxdoo, or whatever you like.

You can even embed literal Javascript, although I've never needed to do it.

Re:What's wrong with jQuery? (0)

Anonymous Coward | more than 2 years ago | (#37268662)

CoffeScript solves a different problem than jQuery. Though it does have a query library, the core 'compiler' provides an improved language syntax and object system compared to Javascript. You can use jQuery with CoffeScript if you like, it works perfectly.

Re:What's wrong with jQuery? (0)

Anonymous Coward | more than 2 years ago | (#37269024)

I don't consider it an improvement. Maybe if you get a hard on for ruby or python.

Re:What's wrong with jQuery? (1)

luis_a_espinal (1810296) | more than 2 years ago | (#37273794)

I don't consider it an improvement. Maybe if you get a hard on for ruby or python.

Subjective, ain'tcha?

Re:What's wrong with jQuery? (0)

Anonymous Coward | more than 2 years ago | (#37268834)

It's a hackish DOM wrapper, and little more.

Re:What's wrong with jQuery? (1)

omnichad (1198475) | more than 2 years ago | (#37269286)

To be fair, being hackish is a requirement of being cross-browser. At least you don't have to write hackish code yourself when using jQuery, everything is more likely to "just work" with a few exceptions.

Re:What's wrong with jQuery? (1)

rickkw (920898) | more than 2 years ago | (#37269358)

What's wrong is that jQuery is NOT CoffeeScript. In the computer science world, someone (must) come along to invent a new language to satisfy his own inflated ego. If I take a wild guess, I'd say that behind all the mumble jumbo, putting his name on a language, and eventually publishing a book about it is the real motivation.

Re:What's wrong with jQuery? (1)

e4g4 (533831) | more than 2 years ago | (#37270302)

Except the author of the book isn't the creator of coffeescript.

Re:What's wrong with jQuery? (1)

slim (1652) | more than 2 years ago | (#37273976)

What's wrong is that jQuery is NOT CoffeeScript. In the computer science world, someone (must) come along to invent a new language to satisfy his own inflated ego. If I take a wild guess, I'd say that behind all the mumble jumbo, putting his name on a language, and eventually publishing a book about it is the real motivation.

You might claim that Ruby is the product of an inflated ego, since it postdates Python. Or that Guido's egotism was what led him to create Python, rather than us all stick with Perl. I would disagree with you -- but at least it wouldn't be a nonsensical claim.

But CoffeeScript is not an attempt to supersede or replace jQuery. CoffeeScript is a compiler that produces Javascript. jQuery is a Javascript library for DOM manipulation and event processing.

CoffeeScript and jQuery happen to complement each other very well.

So who will write ExpressoScript? (1)

Dareth (47614) | more than 2 years ago | (#37268566)

And then who will write ExpressoScriptDoubleShot?

Re:So who will write ExpressoScript? (1)

XxtraLarGe (551297) | more than 2 years ago | (#37268726)

I'm on it, let me polish of this Red Bull first.

Re:So who will write ExpressoScript? (0)

Anonymous Coward | more than 2 years ago | (#37268838)

I'm waiting for AmericanoScript - watered-down and overpriced.

Re:So who will write ExpressoScript? (1)

wsxyz (543068) | more than 2 years ago | (#37269162)

I'm waiting for Americano...

Now I'm going to have to break out the Campari and Cinzano.
My evening is shot and it's all your fault!

Re:So who will write ExpressoScript? (1)

tgv (254536) | more than 2 years ago | (#37268864)

Shouldn't that be LatteText? Or MaccchiatoSculpt?

Re:So who will write ExpressoScript? (1)

bjoast (1310293) | more than 2 years ago | (#37269066)

What is this? Slashbucks?

Re:So who will write ExpressoScript? (1)

Quirkz (1206400) | more than 2 years ago | (#37274666)

I think it's StarDot. Me, I'll have a SoyLatteCursive.

debugging (1)

Anonymous Coward | more than 2 years ago | (#37268684)

It must be such a joy to debug programs written in these higher level languages. Especially on internet explorer, where error messages are practically meaningless.

Re:debugging (1)

Anonymous Coward | more than 2 years ago | (#37268792)

It's actually pretty easy; CoffeeScript is almost a line-for-line translation to JS, so it's easy.

It more than pays off for itself with its terse syntax for routine tasks in JS, like defining functions and re-binding callback functions in the current contexts, something jQuery actually makes less intuitive.

And the code is a LOT more legible.

Re:debugging (2)

Elf Sternberg (13087) | more than 2 years ago | (#37269316)

Hell, yeah.

I've been writing with Coffeescript, HAML, and Stylus for about a year now, and I'm not looking back. Most IE-specific errors these days are parser errors rather than semantic errors, so JS-Lint takes care of that. And you can't use Coffeescript without knowing Javascript, you just can't; too many libraries are written in JS for you to be unable to read them. And Coffeescript has a node.js mode that rocks.

Re:debugging (0)

Anonymous Coward | more than 2 years ago | (#37270318)

I can't speak to Coffeescript, but debugging GWT is actually one of the bigger selling points of the framework. Even in internet explorer, you can use the Java debugger in your IDE to step through your code just as you'd do with a actual Java application.

The only thing that could trip you up is a bug in the framework, but those are pretty much non-existant.

not even close to ruby syntax (0)

Anonymous Coward | more than 2 years ago | (#37268778)

it's an interesting little language but it's syntax when doing callbacks could be cleaner and it's return policy is not so fun in node.js

Re:not even close to ruby syntax (1)

slim (1652) | more than 2 years ago | (#37273424)

it's an interesting little language but it's syntax when doing callbacks could be cleaner and it's return policy is not so fun in node.js

Odd. I find it very convenient for callback based programming, especially in Node.js. Lots of Node programmers use CS.

I was experimenting with stream processors with a functional-programming flavour.

wc = new InjectStream 0, (acc, line) ->
        acc + line.split(' ').length

emits the JS:

wc = new InjectStream(0, function(acc, line) {
    return acc + line.split(' ').length;
});

It tends to be nice and neat, as long as the callback is the final argument -- which is usually the case.

I personally find all those '});' -- and worse -- bracket clusters in JS and Java, distasteful.

Re:not even close to ruby syntax (1)

metamatic (202216) | more than 2 years ago | (#37276132)

I personally find all those '});' -- and worse -- bracket clusters in JS and Java, distasteful.

I find Python-style semantic indentation distasteful. So here we are.

yet another language (0)

nurb432 (527695) | more than 2 years ago | (#37268882)

Just what we need.

Re:yet another language (1)

bl4nk (607569) | more than 2 years ago | (#37268904)

It's frustrating. I work with jQuery/JavaScript daily. I want to contribute to the Chosen project (Chosen [github.com] ), but it's written in CoffeScript. I can't be bothered to learn coffee script to contribute. So I'm complaining on Slashdot instead.

Re:yet another language (2)

royallthefourth (1564389) | more than 2 years ago | (#37268958)

It's frustrating. I work with jQuery/JavaScript daily.

Same here. I don't understand why people think that JS is so bad that it's actually better to write in another language and have the JS automatically generated. From C to Assembler the choice is obvious, but JS is already not terribly difficult to use, especially with the libraries available today.

Re:yet another language (0)

Anonymous Coward | more than 2 years ago | (#37268998)

The problem with JavaScript is that it's tough to get a team on the same page for quality. CoffeeScript helps solve some of those issues.

Re:yet another language (1)

bl4nk (607569) | more than 2 years ago | (#37269068)

At the same time forcing your team to learn a "new language".

Re:yet another language (0)

Anonymous Coward | more than 2 years ago | (#37269122)

Maybe get a less shitacular team. If they spent more time writing decent code rather than rubbing one out over the latest web-programming craze, they might get something useful done.

Re:yet another language (1)

rickkw (920898) | more than 2 years ago | (#37269394)

Sure, commit a team to a non-standardize language that can change on a whim. That's a lot of problems CoffeeScript is going to help solve. In the mean time, I have just invented a superior language called CrapScript that compiles into native CoffeeScript. You should use it.

Re:yet another language (0)

Anonymous Coward | more than 2 years ago | (#37270018)

I think it boils down to the same methodology that produces templating languages for use in PHP, etc. People want to be on the bleeding edge, even if that blood has a bit of Hepatitis C.

javascript is inferior (0)

Anonymous Coward | more than 2 years ago | (#37270622)

I am inclined to say javascript sucks, but it is better than many, lesser known languages. The official language for the web browser should be at least somewhat good, like Python.

Re:yet another language (1)

outsider007 (115534) | more than 2 years ago | (#37270726)

Partly because JS is just not nice to look at, and partly because there's just so many ways to do something in JS, it makes it hard to collaborate on a project. Look at constructors for example. CoffeeScripts solution is to take the return value of when an anonymous function calls itself and assign that to a variable. I'm sure there's a good reason why it's done that way but it really drives me crazy to have to look at code like that.

Re:yet another language (0)

Anonymous Coward | more than 2 years ago | (#37270798)

you can blame it on python programmers who can't wrap their head around anything that doesn't have significant whitespace. Python programmers who want to do front-end web development tend to hate javascript because it doesn't conform to their favorite syntax, and so we end up with the clusterfuck that is coffeescript. Back-end python programmers really won't get much done on the front-end anyway if they don't already have much experience with javascript, and no professional javascript coder is going to jump to coffeescript. coffeescript is really best for personal projects of python/ruby programmers, and should not be used for front-end projects where people are contributing front-end code. choosing coffeescript as the base for the front-end code is to cut out many, many experienced front-end developers from contributing to your project, because they just don't need coffeescript and they shouldn't have to learn it.

Re:yet another language (1)

drb226 (1938360) | more than 2 years ago | (#37271708)

CoffeeScript is really not *that* different than JavaScript. Just learn a couple new syntax rules for the same old things. Can you honestly glance over this [github.com] and tell me it would be "difficult" for you to learn CoffeeScript after already knowing JavaScript?

Re:yet another language (1)

slim (1652) | more than 2 years ago | (#37273292)

If you already know Javascript, I reckon it'll take you less than 3 hours to learn CoffeeScript.

The brief documentation at http://jashkenas.github.com/coffee-script/ [github.com] , is pretty much all you need. On the same page, you can type CoffeeScript in, and see the generated JS. You'll be there in no time.

COBOL calls you. (1)

luis_a_espinal (1810296) | more than 2 years ago | (#37273548)

Just what we need.

That's what our COBOL forefathers used to say. Seriously, I will never understand why people who make their careers in software decide to make statements like that. Yes, there are always problems with language proliferation, but the alternative is stagnation. We always know more about how to make better software over time, and that inevitably brings changes in tools, languages and paradigms. And you cannot foreseen how much variation is too much (or too little) after the fact.

If there weren't people pushing the envelope (even when things go bad), we would still be wondering whether it is possible to write code without GOTO statements or higher-level languages.

From someone who has had to work with JavaScript, I can say that anything that can bring some more sanity to its syntax is a good thing. When one has to rely on a book that explicitly says to cover only its good parts [amazon.com] (a good book mind you), that tells you a lot about the language.

Even Brendan Eich, its creator admits its shortcomings (as he was pretty much arm-twisted into rushing in it out before it was ready with a clear mandate to make it look like Java.) Yes, it can be a reliable workhorse, you can still create applications (good applications) with JavaScript as-is ... provided you tuck your elbows, true of any languages, but for a very high-level, sandboxed application language, it is not that much acceptable.

But if there is a language that needs a saner-replacement (even if it is just an abstraction as a source-code compiler), JavaScript is that language. With that analogy, I could write modern apps using Java 1.0 instead of Java 1.5 or Java 1.6, but why would you? Same in this case.

I have one better (1)

roman_mir (125474) | more than 2 years ago | (#37269004)

I have developed even a better computer language, here is the syntax:

DO WHAT I WANT

this is the output:

# Assignment:
number = 42
opposite = true
 
# Conditions:
number = -42 if opposite
 
# Functions:
square = (x) -> x * x
 
# Arrays:
list = [1, 2, 3, 4, 5]
 
# Objects:
math =
  root: Math.sqrt
  square: square
  cube: (x) -> x * square x
 
# Splats:
race = (winner, runners...) ->
  print winner, runners
 
# Existence:
alert "I knew it!" if elvis?
 
# Array comprehensions:
cubes = (math.cube num for num in list)

it does all that, then it adds $1,000,000 to my bank account and gives me a blow job.

Re:I have one better (0)

Anonymous Coward | more than 2 years ago | (#37269278)

So funny! You must be famous around here.

Re:I have one better (1)

rubycodez (864176) | more than 2 years ago | (#37269510)

That's far inferior to what I have. I give any js task to my nubile red headed Scandinavian assistant whose javascript skills are marginal, who gives a great blow job, and who cares about the money in the bank shit?

Re:I have one better (1)

Anonymous Coward | more than 2 years ago | (#37269678)

I bet he is lying about his heritage.

Re:I have one better (1)

jc42 (318812) | more than 2 years ago | (#37269814)

I give any js task to my nubile red headed Scandinavian assistant ...

That red hair has gotta come from a bottle, because everyone knows that Scandinavians are all blond(e).

Maybe (s)he's actually Irish or Scottish, and just pretending to be Scandinavian?

(I have ancestors from all the above areas, so I can get away with mocking the stereotypes of all of them. I couldn't find a way to also mock my French ancestors in this reply, but maybe next time ...)

Re:I have one better (1)

rubycodez (864176) | more than 2 years ago | (#37271252)

on the serious side, I know some Norwegians that are redheads. no, they do not code nor do they give me head.

Re:I have one better (1)

jc42 (318812) | more than 2 years ago | (#37280078)

Yeah, and there are blond(e) Scots, too. In both countries, the presence of the stereotype hair color of the other country is generally attributed to invaders in previous centuries. Actually, the people doing DNA analysis have already concluded that there are no statistically significant genetic differences between the populations, or between populations in the north-western half of Europe. The perceived differences are attributable to confirmation bias (and use of cosmetics ;-).

Re:I have one better (1)

Rizimar (1986164) | more than 2 years ago | (#37271262)

Eh, I must be new at this. My input looks the same:

DO WHAT I WANT

But the result is this:

Hello World!

Re:I have one better (1)

roman_mir (125474) | more than 2 years ago | (#37273020)

You just want the wrong thing, it's a nube thing.

Uphill both ways in the snow. (1)

b.honeydew (1087465) | more than 2 years ago | (#37269048)

Maybe I'll change my mind in the future but I've been dealing with JavaScript for years and I'm not really interested with learning another yet another scripting language, especially one which deliberate collides with JavaScript. Maybe if the syntax was totally different to JS then I'd be interested. I guess now I know how ASM/C programmers feel about C++.

Re:Uphill both ways in the snow. (3, Informative)

Aladrin (926209) | more than 2 years ago | (#37269252)

I felt the same way until I went to a local coding dojo and they had chosen Coffeescript as the language that week. 2 hours later, I'm a convert. Seriously, it's pretty nice, if for nothing other than dealing with classes in a sane and safe way.

One of the things they said that convinced me was that the javascript it outputs is much, much better than the equivalent javascript you'd write by hand. And I have to agree... it was very thorough and complete.

Re:Uphill both ways in the snow. (3, Interesting)

Barefoot Monkey (1657313) | more than 2 years ago | (#37269720)

I would like to be a convert too. The functionality of CoffeeScript is wonderful and I like the grammar but the way it handles variable scoping seems like a huge step backwards. It's counter-intuitive, unclear and unpredictable - as though the designers put an enormous amount of effort into removing an aspect of Javascript that worked well and imitating an outdated version of Python instead. If it actually is a good idea and someone could help me see the light and understand the motivation behind it I'd gladly switch over.

Re:Uphill both ways in the snow. (1)

slim (1652) | more than 2 years ago | (#37273330)

Can you expand on that point about variable scoping please?

My perception is that CoffeeScript does the same as Javascript, except that globals are harder to create (good!)

The JS generated by CoffeeScript pushes variable declarations to the top of the function, so it's clear what the scope is. That's a real gotcha for JS newbies.

Re:Uphill both ways in the snow. (1)

Aladrin (926209) | more than 2 years ago | (#37274028)

Maybe he means http://jashkenas.github.com/coffee-script/#lexical_scope [github.com] ?

Some discussion on why it could be bad: https://github.com/jashkenas/coffee-script/issues/712 [github.com]

Personally, I tend to use classes extensively, so this is a lot less likely to happen. (Because you need to use "this." or "@" for class variables.)

Re:Uphill both ways in the snow. (1)

angel'o'sphere (80593) | more than 2 years ago | (#37274498)

Personally, I tend to use classes extensively, so this is a lot less likely to happen. (Because you need to use "this." or "@" for class variables.)

I really wonder when in time the meaning of "extensiv(ly)" changed that so many people use it liek you do. In other languages, like german extensiv is used as the opposite of intensiv. In fact the word extensive is rarely used but e.g. in agriculture you would say intensive agriculture, meaning you use a relatively small area and irrigate it and use fertilizer etc. or extensive agriculture where you use a lot of land, likely a less fertile one, and e.g. hold free running cattle there.
However I see what you want to say with "I tend to use classes extensively", somhow intensiv and extensiv are both the opposite of "rarely" ;D kinda strange, isn't it?

Re:Uphill both ways in the snow. (1)

slim (1652) | more than 2 years ago | (#37275666)

In the common usage, "extensive" means "having a large extent".

In agriculture and physics, it can be used as the opposite of "intensive", but it would only be understood among subject expert peers.

Re:Uphill both ways in the snow. (0, Informative)

Anonymous Coward | more than 2 years ago | (#37270634)

this is bullshit. it doesn't produce better javascript. that is part of the false hype that coffeescripts spew, among many many other false statements. coffeescript is a clusterfuck that's only reason to exist is to cater to python/ruby programmers who don't want to write javascript. Those people shouldn't be coding a front-end language anyway, they don't have the mindset needed for it. A programmer who focuses on front-end javascript will produce far better code than anything a python programmer with coffeescript can produce.

Reviewer is illiterate (0, Informative)

Anonymous Coward | more than 2 years ago | (#37269170)

On page xvi, the reader is told that JavaScript "contains multitudes." — multitudes of what?

OF NOTHING IN PARTICULAR, you illiterate fucktard. If you can't be bothered to actually be educated, at least bother to Google stuff before proclaiming your ignorance in public - it's a reference to Whitman's Song Of Myself [wikipedia.org] .

On the upside, your review made me want to buy the book as I'm utterly sick of technical authors who seem to feel the need to hold my DICK while I take a piss. Not everything can (or should) be spoon-fed to n00bs; maybe they should just let the adults work and wait for the Coffeescript For Dummies class at DeVry.

Re:Reviewer is illiterate (1)

rubycodez (864176) | more than 2 years ago | (#37269536)

Whitman's use of "multitude" meant a large number of people; he was not speaking as an individual.

Too much layers (-1)

Anonymous Coward | more than 2 years ago | (#37269324)

This appears to be the evolution of every programming language
1. Super-complicated (ASM)
2. Super-easy, but hard to understand, and errors are not picked up at compile time (C, Perl, PHP, Javascript)
3. Extensions and Frameworks (OBJC,C++, C++2011, STL, PEAR, CPAN) to make things "easier" but all they do is make things more bloated and aren't adopted by the masses.
4. New programming language that compiles into an older one. (JAVA,LLVM,"Managed" C/C++/Javascript, etc)

Too much API cruft in the way.

What needs to happen is that these upper-most languages need to "flatten the layers" to use a photoshop analogy, down to just a CPU/GPU-neutral LLVM JIT compiler. This isn't what happens now. I mean, gods, this is exactly what Google Chrome is doing with NACL, except it doesn't get rid of the API cruft in the way.

I imagine 30 years from now we'll be wondering why computers still suck at doing basic things. Quit reinventing the damned wheel for no reason. If N00B's were meant to code, they'd want to learn it, they don't need their hand held.

Re:Too much layers (1)

ArcadeNut (85398) | more than 2 years ago | (#37269412)

2. Super-easy, but hard to understand, and errors are not picked up at compile time (C, Perl, PHP, Javascript)

C does not belong in that list....

What needs to happen is that these upper-most languages need to "flatten the layers" to use a photoshop analogy, down to just a CPU/GPU-neutral LLVM JIT compiler. This isn't what happens now.

Except in .NET... All .NET languages compile down to an IL, which is then compiled by a JIT on the platform it is run on....

Re:Too much layers (1)

the linux geek (799780) | more than 2 years ago | (#37269748)

Where does Lisp go in your list? How about Haskell?

Re:Too much layers (1)

royallthefourth (1564389) | more than 2 years ago | (#37269816)

In the "irrelevant" pile since nobody uses them outside the university.

Re:Too much layers (0)

Anonymous Coward | more than 2 years ago | (#37271488)

2. Super-easy, but hard to understand, and errors are not picked up at compile time (C, Perl, PHP, Javascript)

Tons of errors are picked up at compile time with C.

3. Extensions and Frameworks (OBJC,C++, C++2011, STL, PEAR, CPAN) to make things "easier" but all they do is make things more bloated and aren't adopted by the masses.

Since when was C++ not adopted by the masses? And complaining about C++0x note being adopted when it was only just finalized? Seriously?

Re:Too much layers (1)

ultranova (717540) | more than 2 years ago | (#37271632)

Quit reinventing the damned wheel for no reason. If N00B's were meant to code, they'd want to learn it, they don't need their hand held.

Most people don't want to learn things for their own sake, they want to get something done and learn just enough to accomplish that.

Thanks, but no thanks. (1)

Anonymous Coward | more than 2 years ago | (#37269450)

It also makes it 100x harder to track down problems because you're not writing the code in the same language as what it is compiling in to. Trying to guess what line number reported by a browser lines up in your coffee script is going to be a real pain in the ass, especially in larger scripts.

Re:Thanks, but no thanks. (1)

Gorimek (61128) | more than 2 years ago | (#37272844)

Debuggers have been handling this for decades already. You just embed the original line numbers in the generated source.

Someone is bound to write that debugger plugin, if they haven't already.

Re:Thanks, but no thanks. (1)

slim (1652) | more than 2 years ago | (#37273344)

In practice, it's not that hard.

When you're debugging, you debug Javascript. Then you figure out what part of the CoffeeScript generated that Javascript. This tends to be straightforward.

To be sure, it's a negative. But it's vastly outweighed by the legibility of the CoffeeScript, how much faster it is to write, the code quality it engenders.

Isn't this a worse solution ? (3, Insightful)

ptr2004 (695756) | more than 2 years ago | (#37269512)

I thought the problem with javascript was it was weakly typed , dynamic and not typesafe so it was very hard to maintain a really large javascript project. I thought coffeescript would be something more like java so that it was easier to write maintainable code.

Re:Isn't this a worse solution ? (1)

BradleyUffner (103496) | more than 2 years ago | (#37270048)

I thought the problem with javascript was it was weakly typed , dynamic and not typesafe.

I agree with you... But I have friends who argue that those exact problems are actually its strengths. It boggles the mind.

Re:Isn't this a worse solution ? (1)

Anonymous Coward | more than 2 years ago | (#37270694)

in 15 years of coding javascript, I can't say that I've run across any serious problem caused by dynamic typing, even on large codebases (80,000+ loc). JavaScript is extremely predictable once you know how it works. The people who hate dynamically typed languages can't grasp why it isn't the clusterfuck they think it is, so they always put down JavaScript for something they don't know how to deal with.

Re:Isn't this a worse solution ? (0)

Anonymous Coward | more than 2 years ago | (#37272394)

in 15 years of coding javascript, I can't say that I've run across any serious problem caused by dynamic typing, even on large codebases (80,000+ loc).

There are some drivers who never have an accident, but they see a lot in their rear view mirror...

Re:Isn't this a worse solution ? (0)

Anonymous Coward | more than 2 years ago | (#37270468)

I thought the problem with javascript was it was weakly typed , dynamic and not typesafe so it was very hard to maintain a really large javascript project. I thought coffeescript would be something more like java so that it was easier to write maintainable code.

I'm a big fan of strongly-typed languages for the simple reason that I'd rather see code fail and embarrass me at design time instead of popping up in the middle of production.

But the biggest frustration for me with JavaScript is that, as implemented in web browsers, trying to simple test datatypes and null objects is a major exercise in frustration. Putting a civilized veneer over JavaScript is all very well and good, but someone really needs to clean up JavaScript itself.

Re:Isn't this a worse solution ? (1)

slim (1652) | more than 2 years ago | (#37273394)

But the biggest frustration for me with JavaScript is that, as implemented in web browsers, trying to simple test datatypes and null objects is a major exercise in frustration.

Coffeescript:

solipsism = true if mind? and not world?

emits the Javascript:

if ((typeof mind !== "undefined" && mind !== null) && !(typeof world !== "undefined" && world !== null)) {
    solipsism = true;
}

(example taken from the CS homepage)

someone really needs to clean up JavaScript itself

I think the JS community is united in recognising the defects JS has. What's recognised is that the install base is there, and if you want to develop for real people with real browsers, you're stuck with it. Crockford has done a great job in recognising the bad parts, recognising the good parts, and carving out a subset of the language that allows you to code in an elegant, efficient manner. The community has developed a number of conventions that work around Javascript's nastiest aspects in a pretty satisfactory way -- for example the export/require module system used by Node.js and elsewhere.

CoffeeScript has the nice property of working within these guidelines.

Re:Isn't this a worse solution ? (1)

slim (1652) | more than 2 years ago | (#37273658)

I thought the problem with javascript was it was weakly typed , dynamic and not typesafe so it was very hard to maintain a really large javascript project.

For the second time this week, I find myself arguing that strong static typing is not something that particularly helps you with large projects. If you write something big, you should be modularising it, and type mismatches aren't easy mistakes to make when communicating between modules.

No, strong static typing is most useful when you're writing the small, detailed, bit-twiddling parts of your code.

Fortunately, that kind of work is seldom what you're doing in Javascript.

Re:Isn't this a worse solution ? (1)

angel'o'sphere (80593) | more than 2 years ago | (#37274418)

the problem with javascript was it was weakly typed

JavaScript is not weakly typed, it is dynamic typed, yes but still strong typed.

Re:Isn't this a worse solution ? (0)

Anonymous Coward | more than 2 years ago | (#37285756)

the problem with javascript was it was weakly typed

JavaScript is not weakly typed, it is dynamic typed, yes but still strong typed.

Yes it is weakly typed. Try this in JS: alert(8 + "5"); A strongly typed language wouldn't allow this, but JS does conversion for you to allow it to happen.

It's also dynamic typed, but like you point out, those two things are very different.

Response from the author (2)

Trevor Burnham (2451014) | more than 2 years ago | (#37270102)

Thanks for the review. The book is aimed mainly at the many developers for whom JavaScript is a secondary language, something they just use to add a little pizzazz to their web pages with jQuery. That's why much of the book is devoted to explaining how scope works, what "this" means, and how prototypal inheritance works—because once you understand the underlying JavaScript, CoffeeScript really is a very simple language. I know you would have preferred a more substantial CoffeeScript book, but there already is a good comprehensive reference: The official site at http://coffeescript.org/ [coffeescript.org] It offers examples of nearly every one of the language's features. If you're fluent in JavaScript, that's probably all you need to get up and running with CoffeeScript. If not, then I hope this book will help. An updated ebook release will be available shortly to address the errata you mentioned. And I'm currently working on a more advanced screencast series, which I hope you'll check out.

Re:Response from the author (0)

Anonymous Coward | more than 2 years ago | (#37276522)

If you're fluent in JavaScript, that's probably all you need to get up and running with CoffeeScript.

If you're fluent in JavaSCript why would you bother? What's the gain?

Re:Response from the author (1)

maraist (68387) | more than 2 years ago | (#37297580)

classes in javascript are hodge-podge at best, hard-to-read. Inheritence is not worth the trouble. The undefined v.s. null v.s. false-valued is a bug-death-trap. To a lesser degree, equality. scoped/packages are a hack at best. These are all things the language can be forced to do against it's will, and if you exclusively deal with libraries like jQuery you can usually avoid it. But ultimately if you want to write re-usable code, then you have to pick a hackish paradigm. This allows you to write elegant looking software with fewer lines of code (e.g. lower risk of bugs). I see a couple gotcha's "->" v.s. "=>", the "@sym", and a couple other places where debugging will be hell. Then there's the lack of editor support, potential errors in the compiler. But it does make the language more palatable.

If you're already fine with nondeterminisitic 'this' values, and are comfortable with your own thing with modular coding, then this doesn't really bring much to the table for you. But I've read my fare share of unreadible javascript code, and normalized structure is not something that would hurt the language/platform.

Syntactic sugar (2)

Animats (122034) | more than 2 years ago | (#37272036)

CoffeeScript doesn't actually do much; it's just another syntax for writing Javascript. Javascript is an OK language, Not a great one; it suffers from some of the standard mistakes.

A classic error is thinking you don't need declarations, and then having to retrofit them. This usually leads to ugly problems, especially if declarations are optional, because the defaults will be backwards. There's a long history of this, starting with FORTRAN and continuing through BASIC and C. Python is almost the only language to successfully work without declarations.

Syntax matters! (1)

Gorimek (61128) | more than 2 years ago | (#37272822)

Then again, any language is just another syntax for writing Assembler.

Re:Syntax matters! (1)

voogzy (1418593) | more than 2 years ago | (#37274280)

Don't stop there.
Assemler too is a kind of syntax sugar for writing machine code. isn't it?
And machine code is a kind of 'syntax' so you dont have to make special circuits for everything you want it to do, right? :)

Re:Syntax matters! (1)

maraist (68387) | more than 2 years ago | (#37297860)

You make it sound like VHDL is harder to write than assembly.. I assure you it's more expressive than that primitive sequential crap that assembly (and it's higher-level derivatives) forces you to think in. :) And every bit as modular.

Re:Syntax matters! (0)

Anonymous Coward | more than 2 years ago | (#37275540)

Clearly you've not done much programming, then. Solving a problem in assembler is an entirely different thing from solving it in a high-level abstract language. Syntax doesn't even enter into it.

Re:Syntax matters! (1)

maraist (68387) | more than 2 years ago | (#37297846)

I'll take your sarcasm and raise it. Clearly you haven't done much embedded programming. Where you almost don't even notice when switching back and forth between C and assembly - and often you're frustrated with the limitations and hackish work-arounds that the high-level language forces you to make.. Why do I need to divide then modulate when one assembly instruction is all I need? :)

Re:Syntactic sugar (0)

Anonymous Coward | more than 2 years ago | (#37273054)

Well, yes, it IS just syntactic sugar.
The thing is, that's what the authors tout as its MAIN advantage.

The CoffeeScript motto is quite literally:
"It's just JavaScript"

It's on the first paragraph of the first page of coffeescript.com

shit with sugar on is still shit (0)

Anonymous Coward | more than 2 years ago | (#37273112)

Javascript is shit. Anything that compiles to shit is a shit generator, which is as close to shit as anyone gives a shit about.

A friend told me but I didn't believe. (0)

Anonymous Coward | more than 2 years ago | (#37273930)

So many comments here are a signpost that the old Slashdot is dead.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>