Why the hell is the Esc key so awkward to type?

And even feeling the pain, most of them just kept using it as it is, because that’s how it was conceived so it must be right. Welcome to the Historian’s Fallacy. It’s that way but it was never conceived that way. Let me show you the Grail.

This is a Lear Siegler ADM3A terminal, produced in 1975. The one used by Bill Joy while at Berkeley he developed the Ex editor and then Vi, starting since summer 1976. Now look at the Esc key. It was where today the very convenient Tab key is, just top left of the home row! That’s why he chose it. But with the need of typing escape sequences going down and down, it was moved …

Here in the IBM 83-key keyboard (1981). And it was moved …

Here in the IBM Model M, second half of the eighties. Where it was left for the next almost three decades, in the very inconvenient top left of the keyboard. Control key had the same fate, just in the other direction. The two fantastic spots close to the home row were taken respectively by the Tab key and the Caps lock key. Now you know it was not meant to be that painful. That’s the great deception, but we can fix it by answering another one million dollar question

What the hell is the Caps lock needed for?

It turns out it’s even more legacy than Esc. It dates back to mechanical typewriters (gosh) as a lock for the Shift key. Needed because pressing the Shift key physically shifted the positioning of the typebars relative to the ink ribbon, so it was tiring. It’s a dinosaur that can be sacrificed to rectify the flow and there are two reasonable ways. You could remap the Caps lock to Esc, and that would be fine. But there’s an even smarter approach i highly suggest if you have an easy to type “[” key (like in the US layout):

Remap your Caps lock to Control and use Vim alternative way to Esc, that is Control + [

Caps lock (as Control) and “[” are keys very close to the home row, hit by different hands, so hardly more difficult than typing Caps lock (as Esc) alone. What’s nice is you can also benefit when typing those Control/something combos that are pretty common. This way you’ll get the best of both worlds and guess what, if you have a nice OS that’s gonna take just 30 seconds. For the others Google is your friend.

Traditionally top universities have always been elitist with knowledge considered a precious good for a few who typically can pay big money. But with the advent of internet something changed. A first wave of web projects came out with the intent of giving free public online education. MIT OpenCourseWare and Berkeley Webcast in 2002 and later Stanford Engineering Everywhere. They all started to give out material of some of their courses and then kept expanding their offer. Free education for the masses, but with one glaring omission compared to their traditional curricula. You get this as a gift, but you’re on your own. No feedback loop, no legal recognition, no tutoring. These are for “real” alumni only.

Today, with internet getting faster, social networks exploding, technology advancing, the snowball is really starting to roll down hill. You can see it from the second wave of sites. Recently born Coursera, Udacity, MITx are now taking online enrollments, giving some tutoring through forums, real-time schedules, exercises automatically checked, short digestible video lectures, certificates of completion. The idea that excellent education, with the help of technology, can stop being a scarce good traded for another scarce good, money, is really catching on. Maybe good education can be abundant, freely available everywhere, so as to improve the entire world, digging up the actual most precious resource: talented, well educated, smart people.

What’s next? The point is education for the masses is not only good for the world, it can be also very good for the wallet. Cutting costs, giving ubiquitous access and making their curricula more flexible and self-paced can open these educators to a new world full of potential clients craving to learn from the best. You can already tell it because these initiatives are starting as private commercial companies backed by investors. It doesn’t take much to figure out which will be the last fig leaf to fall off. In the next years, we’ll see education still given for free, but greatly expanded and side by side with commercial services, more certificates and, in the end, real online degrees with legal recognition. Freemium mainstream education, what a great opportunity. Don’t miss it, start now.

1
2
3
4
5
6
7
8

// 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…

1
2
3
4
5
6
7
8

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:

1
2
3
4
5
6
7
8
9
10
11

# 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:

1
2
3
4
5

// 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 ( [ + - /

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 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

We’re witnessing the exponential rise of a neglected little broken language. A language that obviously started with something very right and grew up even better.

A language that is finally gonna get A LOT of love.

P.S. Here are my talks:

update: now i am linking to the updated version of javascript the new parts given at Javascript Day 2011.

But despite these wins, and numerous loyal fans, Wave has not seen the user adoption we would have liked. We don’t plan to continue developing Wave as a standalone product, but we will maintain the site at least through the end of the year and extend the technology for use in other Google projects.

That’s a great example of why “do one thing well” is better than “do it all”. Not only because, as Gall’s law implies, it’s easier to get a simple system straight, but also because once you get a complex system straight, you still have to make people get their mind around it. Wave made chat and e-mail play well together, with a great replay feature, bots and translation. Twitter gives short text updates. Adoption declared the winner, but we already knew it.

Here it is.

update: now i am linking to the extended version which i gave at From the Front 2011

Why is that? Why when confronted by the possibility of rewriting their untestable bloatware, customer’s reply is almost always invariably “No, we don’t need it. We’ll just have to fix known bugs and add a couple of features, because right as it is, the software works ok…”?. What does “works ok” really mean? In my experience, it translates roughly to “The software does not physically blows up our office, it does some of the things we need to do, and over the years our employees have developed a thick skin against all the nuisances and a baggage of manual tricks, passed on by mouth, to get the rest of the work done anyway. Oh, and we already paid a lot for it”.

Recently, i got a taste of this mindset myself, when i booked online 2 tickets to Avatar at the local cineplex

“Hello this is my reservation code”

“Sorry Mr, those seats are reserved”

“Sure, by me”

“No, actually by others”

“What? see, i made this online reservation…”

“I see, but we take reservations both online and by phone, sometimes they overlap and phone is given priority”

“Overlap?! No trust me, i am a programmer, overlapping reservations are not supposed to happen, because your system has to take care”

“Oh, but evidently it doesn’t”

“WTF?!?!”

“Please, don’t get mad, i am gonna give you other seats. Today is not even bad. You should see how many angry people we must manage during christmas holidays when all movies are sold out!”.

Now, given that reservation means “An arrangement by which accommodations are secured in advance”, how would you rate a reservation system that does not guarantee secure accommodations? Like a fish unable to breathe underwater, yet they live with it, and this takes me to the point.

First, humans are best when it comes to adaptation. That means we naturally adapt to pain so that we don’t feel so bad, and adapt to pleasure so that we don’t feel so good. Perception of any external stimulus in the end comes to balance. Barry Schwartz in the Paradox of Choice says:

respondents were asked to rate their happiness on a 5-point scale. Some of them had won between $50,000 and $1 million in state lotteries within the last year. Others had become paraplegic or quadriplegic as a result of accidents. Not surprisingly, the lottery winners were happier than those who had become paralyzed. What is surprising, though, is that the lottery winners were no happier than people in general. And what is even more surprising is that the accident victims, while somewhat less happy than people in general, still judged themselves to be happy.

Second, humans are also very bad at admitting sunk costs. The idea of having spent money on something not worth is the ultimate inconvenient truth. Again Barry

Aversion to losses also leads people to be sensitive to what are called “sunk costs.” Imagine having a $50 ticket to a basketball game being played an hour’s drive away. Just before the game there’s a big snowstorm—do you still want to go? Economists would tell us that the way to assess a situation like this is to think about the future, not the past. The $50 is already spent; it’s “sunk” and can’t be recovered. What matters is whether you’ll feel better safe and warm at home, watching the game on TV, or slogging through the snow on treacherous roads to see the game in person. That’s all that should matter. But it isn’t all that matters. To stay home is to incur a loss of $50, and people hate losses, so they drag themselves out to the game.

Third, as brilliantly pointed out by Ryan Brush’s “Code is Design” in 97 Things Every Programmer Should Know and by Gabriele’s “Waterfall Pitfall #1” (italian), uninformed most people understand software construction in terms of the better known building construction. Now, since programs are built out of bytes (not bricks), which are practically nothing, using mind (not excavators), which has no physical constraints, actual construction must be very cheap. This gives them the false hope of having an easy exit strategy at their disposal: fixing the software when an emergency comes up. Would they wait for a defective bridge to show the first cracks before attempting to fix it? Their unconstrained minds seem to be unable to realize that story construction aka book writing, built out of words, might represent a more fitting comparison and that The Divine Comedy took Dante, a renowned genius, more than ten years to finish.

Last but not least, mainstream has made a really good job at covering mistakes of incompetent programmers. From the almost sandboxed life cycle of a php script, to the rigid syntax of java and its self-correcting IDEs, to the plethora of useless certifications, great efforts have been devoted to make any primate with opposable thumbs able to program with very limited competence. Many and cheap, that’s how economy of scale is supposed to fail work, and that’s how we got this horde of unprofessional programmers sacking the best projects.

All of these points help to explain proliferation of crappy software. Maybe, they get it from some body rental which pays more for advertising than for the army of juniors that actually does the job. At the beginning it hurts, but they spent good money and cannot afford to accept failure, so lies are told and more time and money are invested to improve the situation. Then workarounds, albeit inefficient, come and direct suffering somehow decreases. Eventually, the pile of workarounds becomes part of company culture, and all is back to balance: the software starts working ok.

Unfortunately, this means that the quest for better software workflows can hardly come out of necessity, it must come out of vision, and vision takes inspiration fed to working brains then time for the masses to catch up. With Universe hopefully taking care of latter two, i like to think we, professional programmers, are those in charge of the former.

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.

First two words about REST. It’s a set of constraints, of simplifying assumptions which, if applied to an architecture, will guarantee a number of good properties such as simplicity, scalability and reliability. The best known implementation of a RESTful architecture is the web and its backbone protocol, HTTP. HTTP RESTfulness made it good and yet so easy to implement that it eventually emerged as the great darwinian winner. Either your router or a pretty rabbit, if it’s networked it’s likely to speak HTTP.

Instead of giving yet another list of REST rules, i am going to give you a feeling of how the web works from a REST perspective. There’s a server which keeps state of the application, split into meaningful resources. Each resource has its own name (URI). That’s all the server knows. Then there’s a client which acts as a finite state machine visiting resources and then moving to other ones through links and forms. The state of the conversation, the session, where the client have been and where it is now, it’s something the client is in full control of. Server knows nothing about it. That’s statelessness.

Having recently read RESTful Web Services, i wanted to write about the most interesting of my REST-induced epiphanies:

Form based authentication with its login/session/logout workflow, which is currently dominant on the web, is hopelessly broken.

To understand why, one has to grasp how the greatest living RESTful implementation, the web and its backbone protocol HTTP, was meant to work. In a nutshell, there’s a server that keeps the state of the web application, split into meaningful resources. Each resource has its own name (URI) and a set of available representations of itself. That’s all the server knows. Then there’s a client that acts as a finite state machine visiting resources, getting representations and then moving to other resources through links and forms. The state of the conversation, the session, where a client has been and where it is now, is something that belongs to the client. Server drives the client by feeding him a graph made of states and links to other states, but it’s the client who is in charge of following a path. That’s statelessness, the simplifying property that made the web triumph as a darwinian winner.

In this view, authentication should have been largely a client-side business. The client visits resources anonymously. If it wants to be authenticated, it just starts sending authentication data with each further request. If it wants to be anonymous again, it just stops. It could as well send a mix of authenticated and anonymous requests. The server doesn’t care of what happens between requests. If a single request carries authentication data, it checks the data and possibly replies as if the client were authenticated. If a request has no authentication data, a generic response is returned. There’s no server-side login through a form, there’s no server-side logout, and above all, there’s no temporal ordering between those two and hence no server tracked session. All of a sudden, the beauty of this comes with great force. By delegating authentication to the browser using the standard HTTP mechanism we can greatly simplify application code.

Unfortunately, in reality this is not the case. During its race to the top, HTTP lost part of its original vision, mainly due to implementation mistakes.

1. The specs failed to hit the sweet spot of authentication security. They standardized Basic Authentication which, by sending user and password in plain text, scared people to death and Digest which, due to its complexity and required server cooperation, never really caught on. A client-side mechanism with cheap yet reasonable security such as WSSE UsernameToken, later adopted by atom, would have been optimal.

2. Browsers took away login from client’s hands by showing the popup dialog to input user/password only after a 401 http error code from server. There should have been an always visible “login” button since the specs said “A user agent that wishes to authenticate itself with an origin server–usually, but not necessarily, after receiving a 401…”.

3. Browsers practically took away logout from client’s hands by requiring to close the browser in order to clean the passwords cache. There should have been an always visible “logout” button.

4. Browsers gave no chance to customize the ugly and annoyingly modal login dialog. HTML and/or CSS could have been used.

5. Browsers gave no client-side storage needed to keep session data but again turned back to server with cookies. They should have given something like upcoming HTML5 localStorage and sessionStorage.

Now there’s not much that can be done short of a collaborative effort by all browser vendors. Meanwhile we can keep dealing with authentication in application code on the server, in a never ending pile of custom solutions, each one slightly different, for yet another pretty standard problem. A problem solved 15 years ago.

• 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

Building on 1972 Dijkstra dismissal of software testing

program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.

Wirth explained that testing is treating symptoms instead of the disease, with the disease being our failure to prove correctness of programs by analytical means. This failure has its roots in distant past but it still holds today with languages and tools too complex and unreliable. Languages and tools providing proper abstraction, really hiding the system beneath, would give us the simple and rigorous ground to make programs easy to prove correct, so that no testing would be needed. Unfortunately, this looks far from happening

Programming languages are further from being mathematically nice than they were 50 years ago! They’re huge and complicated. They contain big libraries, and most of a programmer’s time is spent finding and learning the right libraries.

and again

What progress has this field actually made? We still struggle with the same problems as 50 years ago: iteration times, debugging, scratching our heads trying to figure out what went wrong.

How insightful! Empirical evidence that computer science made no sizable improvement in software construction is everywhere. It’s like a hamster in a wheel, running nowhere. Why is that? Maybe, we’ve been piling leaky abstractions on leaky abstractions, apparently hiding information without really simplifying, to the point where progress is drowning in complexity.

Testing is a nice way to easily lay down executable specifications, yet it requires maintenance and quickly degrades as we try to cover more cases. But when we code we have the chance to write self-describing programs which are executable specifications, reducing the coverage of tests needed, ideally to zero.

What does it mean in practice? Whenever it’s possible one should aim at declarative code. Domain specific languages and functional programming come to mind. The point being, if a program matches closely its specification, what’s left to test?

1
2
3
4
5
6
7

def factorial(n)
    if n == 0
        1
    else
        n * factorial(n-1)
    end
end

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 laws 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.

The Paradox of Choice by Barry Schwartz is enlightening on this respect. Humans inherently crave control, autonomy, self determination and so choices which are natural means to express this essential demand of freedom. Yet, humans used to have simple lives with limited amount of choices. Now, in these days of exponential growth and exploding options, they just can’t cope anymore. They’re overwhelmed by escalating possibilities in all fields of life ending up paralyzed, frustrated, dissatisfied if not plain depressed.

Schwartz comes to the conclusion that, to relieve distress, they have to fight back their inner impulse and learn to accept some constraints are good, that simplicity, more often than not, can be the golden path to well-being. In a later talk at Google, he goes as far as pointing out that software/product makers should embrace libertarian paternalism, which in a nutshell means: give them choices but also apply soft contraints to ease their path to “good” decisions. Those that will probably make them better.

Greek Diners in New York City. Their menus are about a thousand pages. There is no dish anyone has ever eaten it isn’t somewhere on those menus and tucked in the front cover of the menu there’s a little piece of paper with “today’s specials” - four or five items. Inadvertently you create an insoluble problem by giving people 10,000 things to choose from and then you solve it for them by giving them today’s specials and people are driven to choose, take your advice, take your recommendation.

This sheds new light on the company vs customer, simple vs full featured software picture i’m still trying to figure out. As Don Norman puts it “People want the features” and “Features win over simplicity” and as Joel Spolsky notices “With six years of experience running my own software company I can tell you that nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features. Nothing.”. That’s obvious. That’s what people naturally do, the way society drives them to do: Manifest control by claiming more options, more variety.

But then there’s the other side of the coin. Many of them will reject using such software or at least defend themselves by restricting to very basic usage and, in the end, they’ll feel bad about it. Empirical evidence is already there in stats about unused features. People also seem to feel it as the great success of “for dummies” books and simplicity buzzword in advertising underline. Using Schwartz words:

A majority of people want more control over the details of their lives, but a majority of people also want to simplify their lives. the paradox of our times.

Customers bombarded by never ending stream of choices and responsabilities are to me much like children in need of a good parent. So companies as anyone really or virtually in charge of other human beings are subjected to the same old ethical question:

Do we care for us or for them?

Are we in the business of making money or in the business of making happy customers?

If you like me value the latter, then maybe, it’s time to start acting as a lovely father who takes best choices for his offspring but as they grow safe, empower them day by day. Instead if money drives your actions, i just got one more question for you:

Do you think such economy is REALLY sustainable?

Google Wave is an impressive product. If you haven’t seen the Google IO Preview video, i highly suggest you do it know and come back later. Even if you don’t care, there’s a long list of smart ideas, patterns and neat technical solutions packed into Wave that deserve to be studied. Let me mention a few:

• One unique state, on the server

• Operational Transformations

• Statistical spell checker

• Real time collaboration

• Real time search

• Federation

• Playback of changes over time

• Applications as Robots

• Openness of protocol, api, extension

and much more, but even though all this goodness and google involvement are exciting and indeed already suggest a planetary success, i am a little skeptical.

First, in our times of overwhelming complexity, when products like Twitter can WIN not by augmenting capabilities but by restricting them (to a single short answer), Wave  rich complexity will have to prove itself. But there’s more. Something feels wrong to me in this catch-all approach to communication, and i came to believe it’s how all this empowerment is unevenly distributed among different facets of communication itself.

Let me explain trying to determine a few of those facets:

• Retention. How long information will remain available. e.g. From ephemeral spoken words to durable written words.

• Responsiveness. Whether information is taken in immediately or at a later time. e.g. From asynchronous mail to synchronous phone.

• Relevance. How much information is specific and important to a certain matter or goal. e.g. From generic chit-chat to focused articles.

It’s easy to see that high retention and asynchronicity are symbiotic. There can be no asynchronous transfer of information if that information is not stored somewhere waiting to be consumed. What’s harder to see, but empirically true afaic, is that high relevance is related as well. Maybe it’s the effort traditionally required to store information in a durable form, maybe it’s because people have more time to think on what they want to say, maybe it’s that information is produced in isolation helping to concentrate, but it seems asynchronous highly persistent communication tends to be more focused, worth and relevant.

• You’d write a book about origami, but probably not about your last vacation.

• You’d write a blog post about your last vacation, but maybe not about today’s weather.

• You’d twitter about weather, but hopefully not that you’re turning down volume on the ipod.

• Yet you could say that to a friend being around.

Conversely, as communication responsiveness bar raises up, we keep putting in more and more trivial, irrelevant, conversational stuff. That’s easily common sense. Take the word “chat” and how it often has negative connotation. Chat as a waste of time. Chat as enemy of focused productive work (pomodoro technique anyone?). It would be foolish to say that all real time communication is irrelevant, or that irrelevant information is always bad, yet down that path, we often digress from the meaningful and, in that circumstance, high retention is at least useless if not undesirable.

So what’s the problem with Google Wave?

It innovates by opening the entire spectrum of responsiveness possibilities. Users can communicate from asynchronous e-mail to true real time chat. Wonderful. But what about other facets? 

• Retention is fixed and very high. In fact so high that waves can be viewed as conversations or even documents. Stored forever in the cloud. I guess they have or will have a delete button but that would be quite coarse-grained anyway.

• Relevance has even weaker support. You have wave title and tags and that’s it.

Without further control, i don’t see how people will be kept from mixing those different kinds of communication in wrong ways, especially as number of participants goes up. I imagine carefully built documents polluted by real time blabbering, collaborative flame wars producing endless amounts of noise and whole branches of waves slipping out of topic. Trivial fast-paced conversations and relevant slowly crafted documents, all together in a persistent rich beautiful mess called the wave.

I hope to see odds of such hellish prophecy mitigated by some good moderation system and/or by giving better control on retention, otherwise Wave may become yet another perfect illustration of “giving enough rope”. In conclusion, some pretty tentative attempts to contribute:

• an additional chat system orthogonal to wave content

• tags and votes on content and ability to show/hide based on that

• content that fades away unless marked “important”

• content time to live

thank you

Fravia+, searcher and reverse engineer, 1952-2009

In the mean time, here comes a list of resources for those who want to deepen their knowledge about content of the talk:

Books

• Javascript the good parts - Kind of self explaining…where it all started. It’s slim yet dense. Some stuff is advanced.

• Javascript the definitive guide - Best reference book and more.

• Secrets of the Javascript Ninja - Upcoming Resig Book. Doomed to be good.

People

• Douglas Crockford - Senior JavaScript Architect at Yahoo! and JSON father - Listen and read EVERYTHING

• John Resig - JavaScript Evangelist for the Mozilla Corporation and jQuery author - Listen and read EVERYTHING

• Brendan Eich - Mozilla CTO and Javascript Father - Greatest historical figure

• Peter-Paul Koch - quirksmode.com - King of compatibility matters

• Steve Souders - Google employee and author of “High Performance Web Sites” - King of performance matters (together with Resig)

Videos

• YUI Theater

• YUI Theater - Douglas Crockford - The JavaScript Programming Language (4 parts)

• YUI Theater - Douglas Crockford - An Inconvenient API: The Theory of the DOM (3 parts)

• YUI Theater - Douglas Crockford - Advanced JavaScript (3 parts)

• Youtube - Douglas Crockford - Javascript The Good Parts

• YUI Theater - John Resig - The DOM is a Mess

• Youtube - John Resig - Best Practices in Javascript Library Design

• Youtube - Google - Changes to JavaScript, Part 1: EcmaScript 5

Articles

• John Resig - Javascript Language Abstractions

• Joel Spolsky - The Law of Leaky Abstractions

• Jeff Atwood - Javascript the Lingua Franca of the Web

• John Resig - ECMAScript 5 Objects and Properties

• John Resig - ECMAScript 5 Strict Mode, JSON, and More

Reference

• Mozilla Developer Center - Best reference. Beware, it’s Firefox-oriented.

• ECMAScript 5th edition - Standard specs of “next” javascript