JavaScript: The Good Parts 162
Anita Kuno writes "JavaScript: The Good Parts is about the good parts of JavaScript and how to use them. This book takes a realistic look at the strengths and weaknesses of JavaScript and tells you how to use it to its best advantage. The code samples deal with the language and its merits — creating web pages is not discussed. How to understand the language, to execute the operations you want, is the focus of the book, not how to make rounded corners. The author, Douglas Crockford says, 'My microwave oven has tons of features, but the only ones I use are cook and the clock. And setting the clock is a struggle. We cope with the complexity of feature-driven design by finding and sticking with the good parts.'" Keep reading for the rest of Anita's review.
Intended for those familiar with object-oriented programming, who understand inheritance, functions, variables, arrays, and enumeration, it identifies its audience as programmers new to JavaScript as well as those with some familiarity who wish to improve their interaction with the language. People who want to have a good relationship with JavaScript and those who wish to improve the relationship they have will find it most useful. There are lots of books and tutorials that deal with JavaScript but this approaches the language from the point of view of a survivalist.
| JavaScript: The Good Parts | |
| author | Douglas Crockford |
| pages | 153 pages includes the index |
| publisher | O'Reilly Media Inc. |
| rating | 8 |
| reviewer | Anita Kuno |
| ISBN | 9780596517748 |
| summary | The Good Parts of JavaScript. |
I expect this little field guide to retain its usefulness for many years. As Brendan Eich, the creator of JavaScript, states on his blog, "What was needed was a convincing proof of concept, AKA a demo. That, I delivered, and in too-short order it was a fait accompli." JavaScript was a mock up that got a stamp of approval. His first draft became the language. I find that rather shocking. But Brendan alludes in his blog to the idea that there were many other considerations in play at the time, so the story-boarded code got the go-ahead. Crockford's book fills a niche for users explaining how to code with JavaScript and be a better programmer because of the experience.
Douglas Crockford writes in a relaxed, conversational style establishing a connection with the reader that continues through the book's contents (all 100 pages) and the five appendixes ( 50 pages total for the appendixes). I read the book in an evening-away-from-the-screen kind of mood and only followed one piece of code as outlined in the book. The book is approachable with a cursory acknowledgment of the code and it is also informative with a detailed examination of said code.
Special mention goes to Chapter 7: Regular Expressions. There are some topics which are so complex that other authors either skip over them, or use so much jargon as to render the effort useless. Douglas Crockford gives a guided tour of a regular expression designed to parse a url and it is intelligible and informative. He identifies the shortcut he uses in his regular expression code and acknowledges the risks he accepts by using it. I found his twelve and a half pages on regular expressions gave me a reasonable introduction to the subject.
He uses quotes from Shakespeare as an icebreaker for each chapter and appendix. The book contains code snippets and some recipes for adding your own functions and methods which Douglas feels should have been in the language and aren't. This I find to be a very interesting feature of the book. Like the staples for a good kitchen: ganache, bechamel, mirepoix; Crockford identifies the staples of a scripting language and gives the reader the recipes for the features that JavaScript doesn't have; .integer, .trim, and .curry (which allows the creation of a new function by combining a function and an argument).
One of the things that is missing from this book is the DOM (the Document Object Model). I couldn't be happier about that. Every other reference I have approached mashes JavaScript to the DOM so fast that as a newcomer to the language I thought that aspects of the DOM were properties of JavaScript. Douglas Crockford has an episode on Yahoo! Video talking about that very topic and it was a breath of fresh air for deciphering JavaScript. By the way, the amount of characters, in the above sentences about the DOM, is about the quantity of characters dedicated to the topic in JavaScript: The Good Parts. For me, this is a plus.
The author states that the necessary equipment for writing JavaScript programs is a browser and a text editor. Since both are readily available in a variety of flavors and styles, I am fairly confident that every programmer wanting to learn about the good parts of JavaScript can do so.
My previous attempts to learn JavaScript had not gone well and I didn't have an understanding about why the topic was proving so confusing for me. Knowing the history of the language and the environment at its birth, I now have a better appreciation for the abilities of this language as well as a higher level of acceptance for its quirks. I understand now why I should use "var" when assigning a variable, and also why it is a good idea to conclude the line containing "return" that is followed by a block, with the left curly brace that begins the block. I didn't have the patience to accept these idiosyncrasies before and now that I know the history of JavaScript, I can see why it is a good idea to use Crockford's suggestions as a consistent coding style.
Charles Jolley suggested that I read JavaScript: The Good Parts as a basis for learning JavaScript. His tag line was: "I read it in three hours." Now, that may be an inappropriate reason for reading a book, but after spending hours and hours with various media trying to understand JavaScript, three hours seemed like a reasonable investment of time. (It took me a little longer reading at home with the occasional interruption but I still did my first pass in an evening.) The author wrote the book as an enumerable (the recipient of an action one or more times) with each reading revealing layers of understanding.
In the appendixes, there is an appendix entitled "Awful Parts" and one entitled "Bad Parts". Global variables head the list in "Awful Parts". There are discussions throughout the book about why to avoid JavaScript's default to global variables and how to do this in your coding style. The explanation, of why global variables should be avoided in JavaScript, is detailed in the "Awful Parts" appendix. Also making an appearance in "Awful Parts": scope, semicolon insertion, and reserved words. The "Bad Parts" appendix includes: == (double equal sign) which can be evaluated unpredictably depending on the circumstances, "with" which can also have unpredictable results, and "eval" which passes a string to the JavaScript compiler and executes the result. "eval" slows the result when compilation isn't required and can also compromise the security of your application. But what about its use in JSON you ask? Crockford suggests using the JSON.parse method instead of "eval". The file which creates the JSON object with the parse method can be found here. If this is of interest to you, I suggest you check the link and access the book to hear it from Crockford directly.
I find Douglas Crockford's perspective on JavaScript in JavaScript: The Good Parts to be useful in my own relationship with JavaScript. His style is accessible and intelligent.
You can purchase JavaScript: The Good Parts from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Maligned So It Must Be Useful (Score:5, Insightful)
Javascript has its uses and works fine. Platforms have been the problem for me in the past. But with new libraries like jQuery, Javascript has become quite the tool.
Re:Maligned So It Must Be Useful (Score:5, Funny)
Why would anyone need anything other than VBScript for client-side web scripting? :)
Re: (Score:3, Interesting)
Re: (Score:2, Funny)
>> Ugh....we've inherited a site that does just that.
Hang in there trooper. Just remember that the world isn't all bad. There are still lots of people out there who care and are trying to make a difference.
I will pray for your soul.
Re: (Score:2)
Me, I use Python for client-side scripting and expect people not only to use MSIE but also to have Python support (by way of ActivePython) in their computer's WSH.
Oh I just kid.
One browser? (Score:4, Informative)
The author states that the necessary equipment for writing JavaScript programs is a browser and a text editor.
You need waaay more thane ONE browser to write JavaScript. There are still so many cross-browser incompatibilities with javascript today you pretty much have to write one script for firefox and one for IE each time you code.
Re:One browser? (Score:5, Informative)
Re: (Score:2)
... Netscape 4 and below had some interesting quirks too, but those browsers are beyond the memory of most modern web-designers.
"...and get off my lawn."
There were just so many things to hate about the 4th-gen browsers, weren't there...? Ah, those were the days. ;)
Re:One browser? (Score:5, Informative)
Not all JavaScript is intended to be executed in browsers. Server-side JavaScript was introduced a year after client-side JavaScript, and desktop scripting in JScript has been available in Windows for a decade as part of Windows Scripting Host.
You don't need more than one browser to write a JavaScript program, you need more than one browser to develop a website. These are two very distinct things.
Actually, there are very few incompatibilities between JavaScript implementations. It's the DOM that is the cause of most incompatibilities, and all the major libraries like jQuery, Prototype, etc, abstract those difficulties away. Modern JavaScript development is not a case of writing two different scripts. In fact, even without the help of libraries, that style of development was mostly obsoleted when Netscape 4 died.
Re: (Score:3, Interesting)
Not to mention applications like Adobe Fireworks, Flash, Photoshop, 7 a whole host of other applications utilize Javascript for extensions. Lookup "JSF" with Macromedia or Adobe context for more on that.
Some Apple applications use both Applescript & Javascript
Re: (Score:1, Insightful)
This is a red herring as webites are not the topic and theoretically you don't need a browser to develop a website at all. Simplest: yum install apache. Done. If you are going to take the comment out of context, be consistent.
Re: (Score:1)
To display anything at all with javascript requires you to reference the DOM means that they are effectively parts of the same problem.
You seem to be under the mistaken assumption that Javascript only executes in the browser. A lot of my one off scripting is done in Javascript which I run using Rhino, a standalone Javascript interpreter. There are many other Javascript interpreters which are not tied into the browser.
The fact that Javascript is widely used for browser scripting does not mean that Javascript can only be used to do browser scripting. Hence it is completely valid to dismiss claims of Javascript incompatibilities between b
Re: (Score:2)
I understand that. I don't see why that matters. To whit:
The original quote makes no mention of serverside scripting, it makes mention of a browser. Therefore any reference to javascript is assumed to be executed within a browser. The points summarized were:
The article
Re: (Score:3, Informative)
How do you propose that web developers test server-side scripting? Telnet to port 80 and type the requests by hand?
Yes, you want a web browser when you are writing server-side JavaScript. No, that doesn't mean that it is executing within a browser.
I n
Re: (Score:3, Interesting)
How can it be a "red herring"? What do you even mean by that? If you are talking about browser testing, you are talking about websites. I was pointing out that multi-browser testing isn't as mandatory as Benbrizzi claims because browsers aren't the only place that JavaScript is used.
Re: (Score:2)
Not all JavaScript is intended to be executed in browsers. Server-side JavaScript was introduced a year after client-side JavaScript, and desktop scripting in JScript has been available in Windows for a decade as part of Windows Scripting Host.
You don't need more than one browser to write a JavaScript program, you need more than one browser to develop a website. These are two very distinct things.
Very true, I even use JavaScript in some pieces of software completely unrelated to a browser or a web server. With Rhino and the likes, the JavaScript can be executed from about any other software, so it can provide a scripting language to extend a software and customize it to fit a specific customer need. Actually a scripting language by itself.
No browser! (Score:2)
> You don't need more than one browser to write a JavaScript program, you need more than one browser to develop a website.
Indeed. Well actually, you don't even need a browser to execute a JavaScript program.
About two years ago I stumbled across SEE, the Simple ECMAScript Engine. It is a standalone JavaScript interpreter. I find it excellent for teaching the fundamentals and flexibility of JavaScript in a non-Web context. No DOM references, no browser oddities, no picking through a JavaScript Erro
Re: (Score:2)
At the very least, display an error telling me that the site only works with JavaScript enabled! I can't believe how lazy (or is it stupid?) some developers are. How long would it take to stick a piece of text in there that you immediately hide with javascript?
Re: (Score:2)
Okay, you're a troll. What does checking in Firefox have to do with server-side or desktop JavaScript that isn't even designed to run in a browser? What "trust" do you think is dangerous here and what does your opinion of Flash being a waste of bandwidth have to do with it?
Re: (Score:1)
"waaaay... thane... JavaScript... javascript... firefox..."
You may have some other troubles getting in the way of your consistent codebase.
Re:One browser? (Score:4, Informative)
Of course, the vast majority of those incompatibilities are due to inconsistencies in implementation of the DOM — which the book under review explicitly chooses not to address. Take the DOM out of the picture, and the core JavaScript language is fairly consistent across all modern browser implementations. In the context of the language as covered in this book, a single browser is probably a pretty safe requirement.
Re: (Score:2)
To be more precise, I suppose you meant that there are still many cross-browser incompatibilities with DOM, CSS and HTML, not on the javascript language itself, isn't it ?
Re: (Score:2)
Don't forget the event handler. It's not even about IE vs FF. It's like IE does things one way, and every single browser on the fucking planet does it another way, and they're all compatible with each other. IE is the one black sheep of the web world. VIC20s will have good browsers before Microsoft makes one.
Re: (Score:2)
He didn't. The DOM includes events [w3.org].
Re: (Score:2)
You need waaay more thane ONE browser to write JavaScript.
No you don't. To simply *write* it, all you need is a text editor. Why bother testing in *any* browser, much less all the common ones. Either you're that good, or you shouldn't bother. :)
Re: (Score:2, Insightful)
Re: (Score:1)
Re:One browser? (Score:4, Insightful)
Stop confusing C# with .Net, stop confusing Obj-C with Cocoa, stop confusing C++ with STL. Stop confusing C with stdlib. Stop confusing COBOL with mainframe.
Yes, a language and an API are unrelated, but I've rarely seen one without the other. Have you seen many javascript running outside web browsers lately? And while you are correct that you don't have to learn DOM to get into Javascript, you'll need it sooner than later, and using a coherent/compliant implementation of it is crucial in its learning.
Re:One browser? (Score:4, Interesting)
As I said elsewhere in this thread, just because Javascript is widely used for browser scripting, does not mean that is its only use. Your blurb at the beginning is completely irrelevant to this topic.
Re: (Score:2)
Actually, I do a lot of Windows scripting in JScript. WSH may not be the nicest environment in the world, but once you dump VBScript it gets a bit better.
Re: (Score:2)
Amen to that. Another weird data point: JScript has a built-in sort. The last time I checked vbscript didn't.
Re: (Score:1)
Exactly. It's the same thing as optimization: first code something clean and standard / best practices compliant then add the smallest amount of dirty hacks to make it fast or IE compatible.
Just the good parts (Score:1, Troll)
So... it's a blank note pad with a different cover?
Re: (Score:2)
the only problem with javascript (Score:4, Insightful)
is its neigbhorhood, where it is used. you spend 90% of your programming time dealing with the quirks between different browsers. ie isn't even the biggest offender, safari is
which is to say, there is nothing wrong with javascript. it a diamond trapped in a cage made out of shit
Re: (Score:2)
ie isn't even the biggest offender, safari is
Depends on whether you are developing on Safari or on IE, doesn't it? :)
I actually use Firefox for the initial development and then test/fix for the others. Since I've started using jQuery, I spend a lot less time fixing stuff between browsers.
fuck safari (Score:3, Interesting)
i just wrote some script to handle anchor tag clicks globally. firefox, fine. opera, fine. ie, fine. safari: doesn't work in safari, because safari insists on doing the default action no matter what
http://codingforums.com/archive/index.php?t-30983.html [codingforums.com]
you can't cancel dom events in safari! fuck safari. so now i have to completely write off safari support, or completely alter my programming model because of its stupidity, and do some really guly hacks
or perhaps, no hacks possible!:
http://www.peterblum.com/Sa [peterblum.com]
browser fucking (Score:4, Informative)
Are you really required to support older versions of Safari? I only have 3.1.2 and that page that you linked to works as described - so it appears to have been fixed.
that example is old then (Score:2)
but safari still does default actions. you can't globally cancel a click, for example. i can't globally take over all anchor tag actions. safari will try to follow the href link still, no matter what you do in code. its really infuriating and im thinking of just dropping safari support
Re: (Score:2)
Hmmm, I just tried it here:
Sample page showing disabled a tag clicks [vantcm.com]
Seems to work well enough, though I am using the aforementioned jQuery. Do you have a little example of what you are trying to do?
its simple (Score:3, Informative)
document.onclick=function(){
blah blah
}
then cancel event bubbling and default action, according to normal ie and firefox methods
the anchor tag is not modified in any way. the href goes nowhere
and i've tried to cancel the default action in safari in myriad ways, but it always tries to follow the bogus href ;-(
Re: (Score:2)
This may not be the end of the world, right? If your create your links as javascript function calls, then there are no standard link click actions on a global level that you have to cancel - just the javascript function call, which you can always catch, and modify the original destination if needed.
Not certain this will work for your particular application, of course, and there may be other drawbacks to using function calls instead of normal href links (Google and other search engines may not crawl your pa
well that's the whole point (Score:2)
do i give up all of my work and program from scratch according to a new approach? or do i just ignore safari?
Re: (Score:3, Insightful)
do i give up all of my work and program from scratch according to a new approach? or do i just ignore safari?
That depends. Starting from scratch with a new approach might result in code that's even more compatible with other browsers you haven't thought of, and it might even work better on the browsers you already do support.
Not only does the iPhone use WebKit, but my Nokia phone does as well. How many mobile users access your web site?
Re:that example is old then (Score:4, Informative)
Do you have a test case showing what you're doing then? Because document.addEventListener("click", function(event) { event.preventDefault(); }, false); and document.onclick = function(event) { event.preventDefault(); } both work fine in 3.1.2 here.
i didn't use addeventlistener (Score:2)
i'll try that method
thanks for the tip
still a pain to change the whole programming model of how my page works just for safari
i'm current using document.onclick as a global handler
Re: (Score:3, Informative)
Safari (actually, I believe you mean WebKit) is the biggest offender? +4 insightful? Are you fucking kidding me?
I'd like to see an example of what you mean by offensive, because WebKit is the most standards compliant browser in existence. Internet Explorer is less offensive than Safari? Give me a fucking break.
Every commit in WebKit causes the JavaScriptCore code base to run thousands of regression tests, including FireFox's. These test virtually every aspect of JavaScript, including specifications tha
Re:the only problem with javascript (Score:4, Informative)
Reminds me... (Score:4, Funny)
...of a t-shirt I saw once, it read "But what about all the good things Hitler did."
In all seriousness though with Prototype I don't find javascript browser inconsistencies nearly as problematic as css browser inconsistencies.
Re: (Score:3, Interesting)
In all seriousness though with Prototype I don't find javascript browser inconsistencies nearly as problematic as css browser inconsistencies.
Yeah, wait until you start using javascript to manipulate css, the you get the best of both worlds (of pain).
I'm coming out (Score:2)
I love JavaScript :)
Am I a crazy mad man?
Good parts? (Score:2)
[html]
[head]
[/head]
[body]
[script type="text/javascript"]
document.write("This message is written by JavaScript");
[/script]
Here?
[/body]
[/html]
Scoping is Awful? (Score:4, Informative)
I must admit that JavaScript's method of scoping isn't the best (mostly because it has variables that can be reassigned, and scoping binds to the variables, not the values) but I can say that scoping is a time-saver if you do it right and (for example) have a bunch of anchors that all need slightly different arguments in their onclick event handlers.
I've more than once used something like:
It would be nice if it treated scope by binding values, not variables though... (If you tried doing the above by replacing onclickGenerator(i) with function() { doSomething(i); }, every element would end up calling doSomething(elements.length);, instead of doSomething(value_of_i_at_onclick_set_time);
Re: (Score:1)
Easier to read IMHO:
var elements = document.getElementsByTagName("a");
for (var i = 0; i < elements.length; i ++)
elements[i].onclick = new Function("doSomething(" + i + ");");
Re: (Score:3, Informative)
Extend function.prototype a bit:
bleh.onclick = doSomething.bind(null, {one: 1, two: 2});
bleh.onclick = doSomething.curry("...");
(also, you should use level 2 events, but that's another issue).
Re: (Score:1)
All Prototype's bind does is hide the fact that it's creating and calling a generator function anyway... It still fundamentally has to wrap the function in a closure-generating function because JavaScript doesn't have block scoping.
By the way, if you like level 2 events, I hope you don't have any clients using IE!
Re: (Score:1)
Requires an eval.
Ok, but it happens once. Not too bad a performance hit unless you have a ton of links. As I said, I think my code is easier to read and figure out what it's actually doing.
What if you need to pass a string or an object?
I'm not coming up with any idea of an example that would require that, but I'm sure if I had to I would make it work. Probably I'd put the string or objects that I needed to use as arguments into an array and then they'd be referenced by an integer like in the previous example. (Most likely the purpose of passing i in the example was beca
Re: (Score:1, Interesting)
Easier to read IMHO:
elements[i].onclick = new Function("doSomething(" + i + ");");
No. You should never use "new Function()" for anything. You'd be better off using a closure.
There isn't anything wrong with the scoping (Score:2)
function createCounter()
{
var i = 0;
return {
incr: function() { ++i; },
decr: function() { --i; },
getValue: function() { return i; }
}
}
Re: (Score:1)
That's because {} in javascript doesn't create scope, so you're always capturing the same lexical scope (the same /i/ variable) when creating a closure inside the for, that's why /i/ has the .length value, if you do "i = 0" after the for you're changing also the /i/ captured in the closures you've created because it's the same variable. the only thing that creates a new lexical context in javascript is a function call so you can alternatively write:
for (var i = 0; i < elements.length; i++) { (function(i)
Re: (Score:2)
Re: (Score:1)
To be clear, parent is comparing lexical to dynamic scope.
The above silly example, is an example of not taking advantage of block structure.
If you write everything as if it were a C program, yeah, lexical scope can be weird.
My apologies. I suppose I'm confusing my closures with scoping, but the way closures are done in Javascript belies the fact that it doesn't have single-assign variables.
Re: (Score:1)
Try to keep up with the times.
Re: (Score:2)
You really should do for(var i = 0, e = elements.length; i < e; i++)
Otherwise, elements.length needs to be re-evaluated every iteration of the loop.
isn't being evaluated there anyways when it's assigning it to e? How about something like
for(var i = 0; var e = elements.length, i < e; i++)
Re: (Score:2)
wow, I fail at for loops
confused my commas and semicolons, thinking that the commas seperated the 3 expressions - which doesn't even make sense, since there is only 1 comma there. Which is why I read it wrong in the first place. *boggle*
sorry about that.
TiddlyWiki (Score:2, Interesting)
To see some incredible (IMO) JavaScript functionality, check out TiddlyWiki [tiddlywiki.com].
Shortest Book Ever? (Score:1, Funny)
> JavaScript: The Good Parts
Shortest book ever?
JavaScript: The Good Parts (Score:2, Funny)
Re: (Score:1, Flamebait)
Yeah, the single line "Javascript supports C++-style line comments." can't possibly count as a book, can it?
I guess the rest is just 'this page intentionally left blank' filler!
Re: (Score:2)
I can tell from the title alone that this has got to be the shortest book ever written.
Just wait for his next book, "Microsoft Bob: The Good Part."
The author's website (Score:5, Informative)
Crockford's website has a bunch of great articles about JavaScript. I've learned quite a bit from there.
http://www.crockford.com/javascript/ [crockford.com]
One sitting... (Score:1)
JavaScript: The Good Parts
Must be a quick read.
This best part of JavaScript is (Score:2)
JQuery [jquery.com]
Crockford's instructional vids (Score:3, Informative)
Alternative? (Score:2)
I'm a hobbyist and haven't programmed professionally in quite a while but if not Javascript, what (and I'm not using VBScript)? I'm not doing gigantic web sites, but little one off tools for my Shadowrun game. I'd like to have one page for inputting numbers, calculations, and the results are posted in the last field (like a total). Is there something I can use that's more appropriate?
[John]
Re: (Score:2)
Really? What's the right way to do it with php on the server side?
It's a form with say 10 fields. Field number 10 is read only and contains just the calculated value from the other 9 fields.
If I type '3' in field 1, field 10 should immediately display '3'.
If I type '2' in field 2, field 10 should immediately display '5'.
And so on. I've used php to build pages, but not interact with the client.
The idea is during combat, I can bring up the page and enter in the necessary values and pass field 10 to the attack
Well Written (Score:4, Insightful)
No .trim??? (Score:2, Informative)
There you go.
Great book - try out the online 'debugger' (Score:3, Informative)
I really like this book. The author does not treat you like an idiot or make 'oh so funny' jokes to make you feel comfortable with the text. The writing style is friendly and fluid, while the content is always to point. I wish more programming books were as dross-free as this one.
Many readers are likely to read through sections twice or a few times. Crockford warns, 'This book is small, but it is dense', and it is certainly is cramed with useful information. The author states no intention of writing a JavaScript reference but has certainly written a book that I will pick up frequently on JavaScript projects
I am surprised the reviewer didn't mention JSlint [jslint.com] a free, online JavaScript 'verifier', written by the author, that can be used to 'debug' and write better code. It may even be worth a try before you buy the book.
But is it current? (Score:2)
With the recent introduction of classical inheritance to JavaScript (which may or may not be a good thing, that's besides the point), is this book still current though?
Re: (Score:1)
console.log('yes');
Re:No (Score:4, Funny)
document.location.href='bubblyboobsxxx.com';
Re:No (Score:5, Funny)
You have no idea how disappointed I was when I found out that web site didn't actually exist.
Re: (Score:2)
function itsPossible () {
var itsPossible = document.createElement('div');
itsPossible.appendChild(document.createTextNode('It's possible'));
document.body.insertBefore(itsPossible, document.body.childNodes[0]);
)
itsPossible();
Re: (Score:1, Funny)
slashdot = {
[...]
humor : function() {
while (this.story.hasActivity()) {
if (joke.isLame()) {
joke.recycle();
}
Re: (Score:1)
Re:No (Score:5, Funny)
Four spaces baby; the way God indented.
Re: (Score:1)
Set the plain old text mode in the options. ;)
No idea how to do syntax highlighting, though
Re: (Score:2)
I tend to think of programming languages the same way I do hammers; they're tools to be used to accomplish a goal. That being said, I have to say I've always found Smalltalk to be a very cool language.
Re: (Score:2)
And Lisp: Lisp is a hammer with all the power of a jackhammer and all the artistic merit of The Last Supper. :-)
Re: (Score:1, Funny)
lithp ith for fagth.
Re: (Score:1)
Re: (Score:2)
Or how about the C hammer? It's a rock.
javascript/lisp connection (Score:4, Informative)
Javascript itself is a relative of scheme, which is a descendant of lisp.
It offers macros, closures and of course recursion.
The big difference is that javascript is not list based.
Re: (Score:2)
Since when is ANY programming language "cool"?
I myself don't find JavaScript cool, but I couldn't say the same about Prolog, Forth or LUA. On top of that, INTERCAL and LOLCODE also manage to be funny. ;-)
On a more serious note, if you can "feel" something as uncool, others can feel them as cool. Feeling nothing translates into perfect indifference. And since you posted a comment, your post itself is proof that inanimate tools do cause emotions and sentiments, your own words notwithstanding.
Re: (Score:2)
maybe not cool in the sense of popularity by the people world as a whole... But by that sense, not much, if anything, is 'cool'. In the popularity sense, 'cool' tends to be geared towards a culture or grouping. Be it Americans, western culture, eastern culture, Russians, British, business executives, geeks... The slang word cool tends to be used in a rather flexible manner.
Also, it's a word rooted in OPPINION, which means SUBJECTIVE and not OBJECTIVE. That's probably related to the relative-to-grouping conc
Re: (Score:1)
I hear you. But is this YOUR pissy opinion?
Re: (Score:1, Offtopic)
http://en.wikipedia.org/wiki/List_of_Jewish_American_sportspeople [wikipedia.org]
Re: (Score:1, Offtopic)
http://en.wikipedia.org/wiki/Airplane! [wikipedia.org]
Re: (Score:1)