Stephan Sokolow's Blog

Before I begin with my argument, let me say that I generally like Google Chrome (or more correctly, Chromium, the open-source release). It’s the only reasonably responsive open-source (not Opera) browser for tabbed-browsing freaks on Linux, the minimalist UI and “prevent amateur authors from cluttering things” extension API work very nicely to keep things clean yet functional, and I love the little touches like extending the active areas of edge widgets like scrollbars and the tab bar all the way to the edge of the screen in maximized windows.

I also agree that, to make progress, you have to experiment. However, when the Chrome devs start making not-so-smart changes, ignoring mass-complaint by the users of their “Dev Channel” releases, not even compromising with a simple checkbox, and marking well-starred issues as WontFix, they start to approach the level of arrogance and hubris I once thought reserved for the developers of The GIMP. (They’re not quite there since, in my experience, GIMP developers will also insult you or dismiss valid complaints as rude before setting RESO INVALID or RESO WONTFIX)

Here are a few of the more controversial changes, to put it politely, which they have forced on Chrome users in the last few months:

• Chrome Linux single click does not select all (An “experiment” that has now lasted roughly 6 months, proven a bit divisive in the early-adopter community, and received neither the requested checkbox nor a satisfying response from the devs.)
• Type-ahead-find [2] (Apparently, the devs feel keybinding purity is more important than users… and “/” without modifiers is impure)
• Warn when closing with multiple tabs open (Apparently data loss is preferable to modal dialogs with “remember my choice” checkboxes)
• URL bar no longer shows http:// (A pointless nod to space-constrained cellphone address bars which has caused various regressions… including some not mentioned in the bug tracker)
  • It makes novice web developers more likely to produce broken links
  • It makes life more difficult for professional web developers
  • It’s not that different from the old “change for change’s sake” that UI design best practices warn against.

…and that doesn’t even cover the many issues that should be trivial fixes but have languished for months or even years… presumably while the UI change reviews required by Google are continually de-prioritized in favor of whatever it is that the devs actually care about. (eg. native RSS support, reliable middle-click, debugged pop-up blocker, file associations, working blur()/focus(), download completion protection, a comfortable download shelf [1] [2] [3], and various others.

I’m not saying they should do things my way, but I find it, at the very least, insulting to be forced to do things their way without so much as an about:config or hard-to-find checkbox.

To be perfectly honest, for all its flaws, if Firefox 4.x can provide compact toolbars and a properly responsive GUI on Linux, I’ll switch back in a heartbeat. It may be a messy free-for-all with an extension system based on fragile monkey-patching and a rendering engine that’s more sumo wrestler than rocket, but at least it doesn’t presume to tell me how to use my own browser.

Update: As I mentioned in one of the following comments, another reason this really gets to me is the condescension, arrogance, and hypocrisy of claiming to make these changes “for the user” and then implicitly qualifying it with “We know what you want better than you do”. There’s a reason I don’t like Apple, there’s a reason I don’t like Microsoft, there’s a reason I don’t like the Apple fanboys in charge of GNOME and Ubuntu UI design, and now it looks like I also have a reason to not like Google… especially given the good arguments for reverting and the convoluted excuses against reverting that I’m seeing on the issue tracker entry for the removal of http:// from the omnibar.

Update 2: And, in what seems like an admission of defeat to me, the Google Chrome devs have now marked the issue entry for the removal of http:// read-only. In my experience, that’s the corporate equivalent of  “Ohh, nothing’s going my way. Mom!”

Update 3: While Google still seems to be convinced that their “we know you better than you do” approach to UI design is correct, they are not completely immune to reason. According to the Chrome 5.0.375.17 ChangeLog, they’ve temporarily reverted “http:// truncation, star icon, etc…”. Their official stance is “We are currently examining ways to address the usability issues that were raised and plan to reintroduce in a future release” though, so I doubt they’ll be willing to admit that stripping http:// on a non-cellphone browser is inherently a dumb idea.

Update: Part 2 is finally available.

Despite the growing interest in functional programming, most people (myself included) seem to have a lot of trouble grasping the core concepts and constructs. (Probably because the early adopters are all, to some extent, math geeks who have never needed to practice explaining things to the lay-person.) Since I finally decided to sit down and figure these things out, I thought it only fair that I share the Google results that led me to my various epiphanies.

Note: The closest I’ve come to actual functional programming languages is adopting parts of the functional style in Python. If my terminology is a little off but I got the gist of the thing, be diplomatic in your complaints. (I’ve had too much experience with math teachers who seem to think that it’s pointless to know how to use math without perfectly comprehending the relevant proofs and being able to write your own.)

The Easy Stuff

First, let’s cover a few things which are generally easy to understand… but only if you’ve heard of them:

Higher-order Function

A function which takes another function as an argument. To make this more comfortable, many languages treat functions and data equally. (In object-oriented languages, this is “everything is an object” taken to its logical conclusion). This allows for things like results = filter(arbitrary_test, input_data). This is an especially useful feature when combined with other features like closures. (explained later)

Pure Function

A function that only uses its arguments as input, doesn’t modify variables visible outside itself, and provides all of its output using the language’s “return” statement (or equivalent). In other words, a function with no hidden inputs or side-effects. Pure functions are a Good Thing™ because you know that, with a given set of arguments, they’ll always do the same thing. This helps immensely with testing and debugging. (and makes unit testing much easier and more reliable)

Tail Recursion

Getting loop-like behaviour by having functions re-call themselves as the last thing they do. People consider this a good thing because it lets you write loops in a purely functional fashion. (see previous explanation) Functional languages generally optimize this internally so you still get the speed and stack-avoidance of a loop.

List Comprehensions

Practically speaking, a list comprehension is just a shorthand for saying “Take the elements from list X that satisfy condition Y and perform operation Z on them, then return a list of the results”. The benefit of list comprehensions is that they’re a quick, easy, concise alternative to declaring an empty list and then wrapping a function in a for loop and an if statement. (Technically speaking, they let you build one list from another using set builder notation.)

For example, In Python, you could get the squares of all positive numbers in a list with new_list = [x**2 for x in old_list if x > 0]. Keep in mind, however, that list comprehensions aren’t limited to working with numbers. I often use one to quickly implement a simple, one-line input normalizer that, in plain English, would be “Take all lines which aren’t empty or beginning with # and strip leading and trailing whitespace.”

Monads

As one answer on StackOverflow put it, “Monads are simply a way [of] wrapping things and provid[ing] methods to do operations on the wrapped stuff without unwrapping it.” It’s a clear definition… but its doesn’t really give you that “Aha!” moment I was looking for. If you have any experience at all with Javascript, the explanations and examples in jQuery is a Monad should do just that. In short, Monads are useful for changing the set of verbs and how they behave.

The final realization of how useful they can be (and my first recognition of how nifty it can get when you mix functional and imperative styles in a compatible language came from another StackOverflow answer (same question) which showed how, in F#, you can use a monad to do Javascript-style asynchronous HTTP I/O without having to explicitly write callbacks.

Lazy Evaluation

When a programming language is given a statement or block of statements, there are various ways it can do things, ranging from fully strict evaluation to fully lazy evaluation. These are usually easier to explain with examples.

The most common subset of lazy evaluation is probably short-circuit evaluation. This means that, if I run something like fileContent = getFromCache(url) or getFromWeb(url) in Python and getFromCache returns something other than None, an empty string, or the like, getFromWeb will never run because “True or anything” will always be true, so why bother evaulating the second half? This can be confusing if you don’t expect it, but as my example shows, it can also be very useful.

As you probably guessed, strict evaluation operates on the premise that “they said to run it, so we run it… whether or not we’re throwing away the output”. Naturally, in every language, if/then/else constructs use lazy evaluation.

The area of lazy evaluation that is sometimes confusing is eager evaluation versus delayed evaluation. If you’re still reading this, you’re almost certainly familiar with eager evaluation. For example, if you look at a list, you might see something like [1, 2, 3, 4, 5, 6].

The gist of delayed evaluation is that, at any given time, that list could look more like [1, 2, 3, ...] with the language evaluating further into the “...” as needed. This is useful because you can do things like creating an infinite list (Wikipedia uses the Fibonacci sequence as an example) and then retrieving specific values from it.

On a more mundane note, lazy evaluation is also commonly used for improving program performance. For example, in graphical systems where drawing is done only at the last minute so that “Oops. Looks like those pixels aren’t visible to the user after all” doesn’t impair performance.

Haskell

I haven’t actually used Haskell yet, but from what I’ve seen, I think I’ll try to make time for it soon. (When I do, I’ll update this post) Here are the posts that brought me to that conclusion (In concert with what I’ve already linked, of course):

• Why Haskell is Beyond Ready for Prime Time (This is the more convincing one in my opinion)
• 37 Reasons to Love Haskell

Among other things, I love the idea of a code repository where you can search for functions by specifying the inputs and return types you need.