// good, returns the object
return { ... }

// wrong! returns undefined
return
    {
        ...
    }

Fair enough. Lately i’ve been doing more and more ruby. Ruby is a language universally praised for its elegant, easy to read syntax. One of the strong points of the syntax is its terseness, that is, you can omit a lot of punctuation. Semicolons as well. Wait a moment…

def test
    return
        {
            ...
        }
end

test # returns nil !!

Same thing! Having the meaning of a program change due to an end-of-line is not a good thing in ruby as well, but it’s widely accepted because of the benefits. This must be true for javascript as well, so first point:

“Removing semicolons and other punctuation clutter is not just a liability. It actually makes your code look better.”

So both the languages have to decide when a statement implicitly terminates. But is ruby implementation really the same as javascript? It turns out it’s not, ruby takes a quite safer approach. A statement in ruby is finished on an end-of-line if it’s syntactically valid by itself, it spans multiple lines if it’s not:

# this works, the trailing dot means the statement is not finished
object.
    method1.
    method2.
    method3

# syntax error, first line is a valid statement by itself, second line calls method1 on nothing
object
    .method1
    .method2
    .method3

It’s safe because how a line is parsed depends on the line itself, not by other lines that could be written “by others”. The bad part is how it makes method chaining on multiple lines look ugly. This is why ruby 1.9 introduced the exception “the statement continues if the first character of next line is a dot”.

Javascript takes a step further to solve this bad part. A controversial step. A statement is finished on an end-of-line if the first character of the next line cannot be correctly parsed as if it was part of the line. Otherwise, the statement goes on. This removes the clutter and gives nice chaining:

// just works
object
    .method1()
    .method2()
    .method3()

Unfortunately, you now have a nasty problem. 2 lines which are supposed to be 2 different statements, but with the first character of the second line being a valid continuation of the first, will be treated as one statement with unpredictable results. This practically happens only when a line starts with either ( [ + - /

// function call instead of grouping
var a = b + c
(d + e).print()
// is really
var a = b + c(d + e).print()

// array index instead of array literal
var a = ["a", "b", "c"]
[0, 1].forEach( … )
// is really
var a = ["a", "b", "c"][0, 1].forEach( … )

// binary math operator instead of unary
var a = b + c
-1 == string.indexOf(query) || die()
// is really
var a = b + c – 1 == string.indexOf(query) || die()

// division instead of regular expression
var i=0
/[a-z]/g.exec(s)
// is really
var i=0 /[a-z]/g.exec(s)

Well, this sucks, so what should you do? I could say that i remember being caught by this problem just once in many years of javascript. The return problem or starting a line the nasty way is something extremely rare. But even if you don't want to afford the risk, why avoid ASI without even knowing about it? Without even thinking about a reasonable fix, given the nicer syntax? And this leads me to the second point:

"To write semicolon-free code and avoid getting bitten, you just need to remember 2 rules

1) Don't put an end-of-line between return, break, continue, throw, postfix ++, postfix -- and their operand
2) Avoid starting a line with ( [ +  - / but if you have to, prepend it with a semicolon"

// everything's fine
return { ... }
continue label
break label
throw error
counter++
counter--

var a = b + c
;(d + e).print()

var a = ["a", "b", "c"]
;[0, 1].forEach( ... )

var a = b + c
;-1 == string.indexOf(query) || die()

var i=0
;/[a-z]/g.exec(s)

Is it that taxing to remember? Automatic semicolon insertion is of course controversial, but using it is not a complete failure. It's a matter of taste, a trade-off between cleaner nicer code and some tough albeit avoidable pitfall.

While i'm at it, let's debunk some well known myths that always show up

• "I could know ASI but others don't and they will mess things out"
  Well this may be true. It depends on where you work, the skill of your peers, etc.. To me, a javascript programmer is just supposed to know this stuff as he knows of prototype and first class functions. If they don't, supposing they got the opposable thumbs, as they can be told to put semicolons everywhere, they can be told to remember the above 2 simple rules.
• "It's not gonna work the same way on every browser"
  It's in the specs since more than a decade. I think browser bugs are a thing of the past and even proponents of this theory look unable to find something newer than 5 years ago, so.
• "It breaks the tools. You cannot minify code anymore, etc..."
  Let's be clear about this. It's officially part of the language. A tool unable to cope with ASI is a broken tool, period. Anyway, i have never had a problem with google closure compiler.
• "Jslint doesn't work with it"
  Jslint enforces the vision of Douglas and it's pretty strict about it. This is fair, yet for those having another vision nothing is wrong with using Jshint which has an option to accept ASI. 

Let's close with two very nice articles that explain the details and of course you can always read the ecmascript specs:

The most well-written comprehensive article

Very good explanation of the pitfalls

The plain specs

Here it is.

update: now i am linking to the extended version which i gave at phpday 2010

Until, from the midst of this darkness, a sudden light broke in upon me, a light so brilliant and wonderous, and yet so simple. Deep practice, eradicate errors and deep practice again. I alone succeeded in discovering the secret of bestowing skill. Nay, even more, I myself became capable of bestowing mastery upon apprentice matter.

It could work.

At the end of august 2009, while i was reading about the importance for a programmer to touch type, i found out many programmers could type at 80 wpm and above. I tried myself and consistently scored 60 wpm or below. I have been spending many hours a day at the keyboard since at least 1996. How could it be i am not as fast? I already knew about the importance of practice, but i did practice for years, didn’t I? Well, uhm, no.

Think of the career of a professional football (soccer) player. How does he get there, does he play all the time for years? Actually, he spends most of the week training: stretching, pushups, sprints, weights, long runs, ball work, etc… Only a small percentage of time is indeed to play short games and the main game on sunday. That’s because play alone can only push your performance to the upper end of the range set by current skill. It’s not going to push you to the next level, to the next order of magnitude, and it doesn’t keep you from developing bad habits. And that’s where i got, very fast at typing in my very flawed 7-fingers posture. Not able to improve any further, not even in more than 10 years.

I really wanted to get better, so the questions were How? and How long will it take? I didn’t know the answer to the latter but the former was by then clear in my mind. Find a keyboard dojo, do keyboard katas and take the needed time. After trying a lot of viable solutions i found my dojo at www.typingweb.com. To add some salt to the challenge i switched keyboard layout from italian to U.S., which is quite better for programming, and i started practicing daily with their courses, routinely taking tests to record my progress. Two pomodoros a day for the first two months, then one, then again two when i was reaching the end. Always striving to get 97% or above accuracy at the higher possible speed for every single lesson.

Now, five months and about 120 pomodoros of deep practice later, i am writing this to shout to the world that IT COULD WORK. Next i’ll be moving to vim katas, while still having some fun at www.typeracer.com, because you never really stop to practice right?!

Yours sincerely,
ten fingers typist
american layout
80 wpm average
up to 100 wpm under a good moon
Federico.

]]> http://federico.galassi.net/2010/01/27/how-i-did-it-touch-typist-in-five-months/feed/ 0 http://federico.galassi.net/2009/11/15/javascript-performance-make-the-browser-happy-and-you-sad/ http://federico.galassi.net/2009/11/15/javascript-performance-make-the-browser-happy-and-you-sad/#comments Sun, 15 Nov 2009 20:40:11 +0000 federico http://federico.galassi.net/?p=193 The browser is emerging as the best platform for applications, so a large community is growing to address its final weakness: speed. Google, Yahoo and various independent programmers are all pushing a bunch of clever techniques to boost performance and please end users. That’s nice, yet as Mark Twain once said, half of the results of good intentions are evil and i see potential danger in many of the suggestions made. Here a representative short list of them:

• Avoid for-in and forEach in favor of optimized while loops
• Before making modifications to a DOM node remove it and then re-insert it
• To insert multiple DOM nodes, first insert them into a Document Fragment and then add it to the DOM
• Join all scripts into a single file
• Load javascript files on demand

Let’s make it clear for once, execution speed is not a human problem, that’s what computers are for, they execute our commands fast. The human problem is programming speed and writing down clear, readable, maintainable commands aka programs. forEach loops make sense to me, they say “i want to do something on each item”, optimized while loops make sense to computers. If i want to add DOM nodes or modify one, i don’t care of removing it or document fragments, browsers care. To me it’s just noise. Almost all of the problems addressed by those techniques stem from lack of smartness in the browser, and that’s where fixes belong to, on the machine side. The fact that there are inept browser makers is no excuse. Fixes still belong to the machine, they’re repeatable and can be made automatic. We have a long history of programs automatically converting human friendly code to machine friendly code. They’re called compilers and the output either machine code or optimized javascript doesn’t matter.

So, learn about javascript performance since knowledge is always the way, but don’t turn yourself into a machine, you’d be an awful one. Use the tools and wait for browsers to catch up.

• Aptimize
• Closure Compiler
• YUI 3 use

Code katas, a term first coined by Pragmatic Programmer Dave Thomas, are small programming exercises geared to hone a specific programming skill. Traditionally, they tend to be algorithmic like parsing or visiting graphs but could as well aim to improve understanding of particular programming paradigms, like functional or object oriented, or a specific language. Also, as remarkably pointed out by Matteo, katas can be crafted to master a certain technology like web or database. While, as you may guess, Coding Dojos are sites, groups or communities which propose and maintain collections of katas hopefully with solutions and reviews.

So, how do you practice? I suggest you solve a kata, review your work, compare it to other solutions, share your code with others and discuss it. Then solve it again trying to take a different path, balance pros and cons, then solve it again and again, until you feel you internalized the essence of the problem. Finally, you can move to another kata. If it feels like a lot of work, then you got it right. No question mastership requires time and effort but, then again, masters are those destined for greatness.

Resources

• Katacasts
• 21 Code Katas by Dave Thomas
• Lots of Code Quizzes with Ruby Solutions
• Matteo Vaccari’s Technological Katas
• Coding Dojo Code Katas
• Corey Haines Video Solution in Ruby of String Template
• Uncle Bob Code Katas (search “kata”, ie bowling kata)
• Micah Martin on Code Katas and Video Solution in Ruby of Langton’s Ant
• Micah Martin’s BattleShip Tournament
• Google Code Jam
• Jeff Atwood on Code Katas
• Steve Yegge on Code Katas
  
• Peter Norvig on Deep Practice

Actually this has been something known to humanity for at least a century and it’s best explained by this quote from Thomas Edison:

Genius is 1% inspiration and 99% perspiration

The point is that becoming great at something is largely a matter of the amount and quality of practice one does. While God given talent can only boost this process, but it’s by no means the most influential factor.

About the amount of practice, there’s the old “Ten Years Rule” and a more refined study by Anders Ericsson who sets in 10000 hours of committed practice the time taken to achieve expert level. From the Pomodoro Technique, we know one can do about 5 hours/day of efficient work (10 pomodoros). That means 5 years and a half, 5 hours every day of hard work could be a good guess to the question “How long does it take?”.

About the quality of practice, the book calls the good one “deep practice”

working on technique, seeking constant critical feedback and focusing ruthlessly on shoring up weaknesses

So deep practice has a pretty simple recipe:

• practice just beyond your current ability
• focus on errors
• fix them
• repeat

Basically, it’s tenacious, steady continuous improvement, so it’s not surprising Kaizen is mentioned in the book.

In the end, we are left with two news: one bad, one awesome. The bad one is if you fail to reach master level in a discipline you care of, there’s no one to blame but yourself. Sadly, you got to take responsibility even for that. But the awesome news is you can really become what you want be. Just keep working.

Let’s close with this sweet advice from great italian poet Giovanni Papini

Chiunque, purché sappia chiaramente cosa vuol divenire e non perda un solo secondo della sua vita, può issarsi al livello di coloro che dettano le leggi alle cose e che creano vite più degne. (Da “Diventar Genio” – 1912)

and my rough translation

Anyone, as long as he clearly knows what he wants to become and doesn’t waste a single second of his life, can raise himself to the level of those who lay down the law of things and create more worthy lives (From “Becoming Genius” – 1912)

Is Vim amazing software? Yes. Is Vim simple? No. This could imply that simplicity is a highly overrated software value, but i think it’s not. It just implies that, as any other thing under the sun, simplicity is a relative value. Relative to what? I guess to user’s knowledge of the domain. Let me explain.

Simple software is one that provides a few objects and a few rules to compose those objects coherently into newer more complex abstractions. This makes an optimal hotbed to learn. Few objects are easy to understand and remember. Few corner case free rules give confidence while exploring the unknown. It’s important that the learner is not exposed to further possibly useful complexity which is not ready for yet. Only some to ignite inspiration, but greater power cannot come a priori, but as a consequence of greater understanding of the domain. This way user and software evolve together.

“Good” Complex software, which still tries to minimize basic objects and rules and completely avoid corner cases, may ship equipped with many levels of abstraction relevant to the domain. That’s for the sake of efficiency, so that the skilled user will be able to manage complex scenarios by quickly referring those abstractions. Give something too simple to the master and he will end up bored and unproductive. Give something too complex to the apprentice and he will run away confused.

Vim is extremely good and complex software which comes with a plethora of short keyboard commands to make any conceivable manoeuvre on text at top speed. Optimized for being efficient with keyboard, which already happens to be the most efficient input device, usually much better than mouse. That’s heaven for touch typists as i am. The nice thing about efficiency is that it can be easily quantified by time. Same goal, the faster the better.

Let’s close with a fulgid example of vim capabilities with a common editing pattern: swapping two words.
An usual hybrid keyboard/mouse approach on windows:

• Select the first word (click/drag the mouse or double click)
• Cut (ctrl+x or right click and use menu)
• Move the cursor after the next word (move the mouse and click)
• Paste (ctrl+v or right click and use menu)

I guess it takes 3-4 seconds to complete correctly

Vim keyboard based approach:

• type dwwP

An average good typist can do 50 wpm which means it takes about 1 second to type 4 characters. That’s efficient.