CoffeeScript. An Outsider Opinion(blog.nuclearsandwich.com)
blog.nuclearsandwich.com
CoffeeScript. An Outsider Opinion
http://blog.nuclearsandwich.com/coffeescript-an-outsider-opinion
7 comments
Quick point of clarification. The post says:
What's in a name? That which we call a class by any other name would smell as sweet.
Call it a prototype if you like -- it's the same thing in code.
> As it turns out that isn’t entirely true since coffeescript
> is a class based object oriented language and javascript is
> prototype based. This was actually a mark against
> coffeescript for me since part of my desire to learn
> javascript was to dally in prototype based OOP.
What's in a name? That which we call a class by any other name would smell as sweet.
Call it a prototype if you like -- it's the same thing in code.
thanks Jeremy, do you mind if I insert your comment in the main body of my post?
I am still a student of computer science and in my university's Java encapsulated worldview they've not discussed the finer points of non class-based OOP. I will do more research on the subject.
I am still a student of computer science and in my university's Java encapsulated worldview they've not discussed the finer points of non class-based OOP. I will do more research on the subject.
Go for it. In a nutshell:
An object is a unit of code and data that can be treated as a distinct entity. Classes and prototypes are both way to make objects. With a prototype, you start with an actual object as an example, and make more objects just like it. With a class, you start with the abstract set of properties that describe a type of object, and make more objects from that blueprint.
Think of it as the Platonic ideal of a thing (the class), versus the canonical example of a thing (the prototype).
To get specific: The idea of Bicycle, versus my blue bike with red streamers. Both can be used to make more bikes, in JavaScript.
An object is a unit of code and data that can be treated as a distinct entity. Classes and prototypes are both way to make objects. With a prototype, you start with an actual object as an example, and make more objects just like it. With a class, you start with the abstract set of properties that describe a type of object, and make more objects from that blueprint.
Think of it as the Platonic ideal of a thing (the class), versus the canonical example of a thing (the prototype).
To get specific: The idea of Bicycle, versus my blue bike with red streamers. Both can be used to make more bikes, in JavaScript.
newBike = new Bicycle
newBike = Object.create(myBlueBike)Awesome. Thanks for that. I've always enjoyed the link between Platonic forms and object Classes.
ahhhphilosophy.jpg
ahhhphilosophy.jpg
Do semicolons really distract people from thinking about the behaviour of their code? Really? Would these people like their novels and articles decompiled so that every sentence is on a new line, and thus periods wouldn't distract them so much from the meaning of the text? Or is it just transparent after a while, as the way you end something?
Books and code have different usage patterns.
In books, you typically start from the beginning and read to the end. You consume the book serially and the only breaks you are concerned about are pauses (period, comma, colon, etc.) and page breaks (chapters).
In code, you typically scan. Scanning a book is a painful experience. The sentences never start in the same spot. In code, the heirarchcal structure and text layout helps for scanning and identifying quickly. As someone said previously in this thread, cookbooks are done the same way and for the same reasons.
In books, you typically start from the beginning and read to the end. You consume the book serially and the only breaks you are concerned about are pauses (period, comma, colon, etc.) and page breaks (chapters).
In code, you typically scan. Scanning a book is a painful experience. The sentences never start in the same spot. In code, the heirarchcal structure and text layout helps for scanning and identifying quickly. As someone said previously in this thread, cookbooks are done the same way and for the same reasons.
I'd prefer a Coffeescript that restored semicolons and braces and didn't depend on indentation to denote block structure. Fixing some of Javascript's most serious warts is a great idea but, IMO, significant whitespace is a bad idea here just as it is in Python and Haskell. It just makes routine code manipulations like copy & paste and block refactoring a lot more tedious.
IMO, significant whitespace shines when used along with a proper editor.
Also, even without an editor, the cleanliness pays off. And you would indent properly anyway...
Also, even without an editor, the cleanliness pays off. And you would indent properly anyway...
There are many other compile-to-JS languages that might be more to your liking. Perhaps try Objective-J? It's a strict superset of JavaScript.
http://altjs.org/
http://altjs.org/
I already curse Objective-C for its verbosity, so that's not the right direction for me. Coffeescript is in the right ballpark, I'd just rather have a more explicitly structured syntax, perhaps closer to Ruby.
>Would these people like their novels and articles decompiled so that every sentence is on a new line
Isn't that how we write cooking recipes?
Isn't that how we write cooking recipes?
I see your point. Punctuation is a vector for meaning and clarity but is Javascript's syntax any more informative than Coffeescript's? It isn't in my observation. It certainly offers more flexibility in style, but why would you need it? I can't conceive of a reason besides minification.
Your comparison with novels I think is a bit skewed. Literature has a whole different set of readability enhancements such as fully justified text, variable-width fonts, as well as margins and padding. Punctuation in English has been evolving for centuries as people settle on the minimum needed to convey the full meaning as unambiguously as possible. But English also has many many more sets of valid (as well as various definitions of valid) constructs than Javascript does and thus may require a more robus set of punctuation.
Your comparison with novels I think is a bit skewed. Literature has a whole different set of readability enhancements such as fully justified text, variable-width fonts, as well as margins and padding. Punctuation in English has been evolving for centuries as people settle on the minimum needed to convey the full meaning as unambiguously as possible. But English also has many many more sets of valid (as well as various definitions of valid) constructs than Javascript does and thus may require a more robus set of punctuation.
There's a principled point about aesthetics and removing unnecessary redundancy. But that shouldn't be confused with whether semicolons affect your ability to think about code. Really I can't imagine how someone could be significantly distracted by semicolons, once they're used to a language, to the extent that it occupies their conscious brain in any way whatsoever. It does take familiarity to get there, but I can't imagine having a mind where this didn't seem transparent and rather irrelevant very quickly.
You're absolutely right, I spent most of the past three years writing Java, C++, C, and C# and they all use semicolons and I certainly forgot about them whilst coding in those langs. But the penalty is in transitioning between languages that use or don't use those features. When I'm writing in C and the like, I tend to stick within that language. But with JavaScript and Ruby, I do a lot more context switching back and forth. Anything I can do to reduce the penalty of moving between one and the other is worth doing in my opinion. Especially when it doesn't affect the final result.
I'll use anything that fixes the way javascript handles scoping. Take this gem, for example:
<html> <body> <ul> <li>First</li> <li>Second</li> <li>Third</li> <li>Fourth</li> </ul> </body>
<script type="text/javascript"> els = document.getElementsByTagName('li'); for(i=0; i < els.length; i++){ els[i].addEventListener('click', function(){alert(i);}, false); } </script> </html>
<html> <body> <ul> <li>First</li> <li>Second</li> <li>Third</li> <li>Fourth</li> </ul> </body>
<script type="text/javascript"> els = document.getElementsByTagName('li'); for(i=0; i < els.length; i++){ els[i].addEventListener('click', function(){alert(i);}, false); } </script> </html>
Javascript has a few gotchas like this one. These are annoying for people new to the language but after knowing they exist they're easily avoided.
CoffeeScript has some nice benefits but in my opinion not having to deal close curly braces or add semi colons hardly qualifies as a reason to use one language over another.
I'm still using Javascript at the end of the day, I'm just doing so via an interface that I find more readable and writeable. I don't see it as much different than letting a minifier optimize my javascript rather than writing it that way by hand.
Though I love CoffeeScript, I feel it's very important to understand how JavaScript works. It's a great language, but only if you understand what is going on, and why you do have to use hasOwnProperty.
I'm working on it. I did mention that I'm learning Javascript at the same time. I should add Crockford's JavaScript: The Good Parts to my coffeescript resources list. Can you link me to an article explaining hasOwnProperty?
Personally, I really like the whole coffeescript/sass/haml trio. (I really don't like SCSS).
It drastically reduces the amount of errors in your code, at the expense of a syntax that's a little different.
It drastically reduces the amount of errors in your code, at the expense of a syntax that's a little different.
Yeah, you've hit on what really appeals to me about those three and others like them. They shift focus to what's really important in each case.
In HTML I want to focus on document structure, not closing my tags. In CSS I want to focus on style and visual consistency, not nesting. In Javascript I want to focus on application behavior, not semicolons.
In HTML I want to focus on document structure, not closing my tags. In CSS I want to focus on style and visual consistency, not nesting. In Javascript I want to focus on application behavior, not semicolons.
Last time I looked into sass/scss/less, I decided Stylus is for me. Looked into that? Not just getting rid of semicolons and curlies, but even colons :) plus macros, functions, variables, calculations, all the "usual" stuff.
Interesting, I noticed npm install stylus, does this mean Node only? Or is there a ruby/rails version?
You might also like LESS.
I'm guessing someone who prefers SASS over SCSS is going to also prefer SASS over LESS.
One of the reasons we did not switch from HAML/SASS/SCSS to LESS/Jade/Stylus is the output. HAML and its cousins do the extra little things to help developers diagnose problems like adding comments with the original line # and file; pretty-printing, etc. All these options can be disabled for production of course.
YES:
It's not the time saved while writing the code that matters here -- although I do believe it adds up quickly if you work on a project that might occupy you for months or years and have invested the initial week of getting fully into CoffeeScript mode.
NO, it's the time saved reading your code time and again as you revisit your code-base over these months or years of refining your project going forward.
CoffeeScript's "easier writability" may be debatable, but it's its "easier readability" where it really shines. I can glance quickly at my way-fewer-lines of CoffeeScript and parse it much more smoothly than I ever could a curly C-style language. Maybe it's because I first started out in, boohoo, BASIC. But indented lines with no superfluous { syntax; decorators } just flow into my brain much faster.
If you're a fire-and-forget coder who writes line after faultless bugless line that you never need to revisit, review or simply recall and still get a meaningful composition of a program, app or site that isn't just a house of cards built on quick-sand or a simple batch job at the end of the day -- I envy you! In my case, 99% of my classes and functions are an API to each other. So I look up how the stuff I wrote days, weeks or months ago was supposed to be called or initialized constantly. I read my code more often than I write it.
I like writing CoffeeScript but what matters is -- I love reading it. Before, I liked writing JavaScript -- but I hated reading it.