Also, it's hard to describe exactly what the problem is, but scrolling up and down definitely feels weird and frustrating. For example, a light push that normally goes down a few lines of text on any other page seems to go down a full page. It also seems "stickier", like any scrolling takes a split second to "kick in". As a more contrived example, if I hold two fingers down on the trackpad and scroll up and down in place, any other page will scroll up and down following my fingers, but this page seems to jump around in an inconsistent way.

Something on the page is trying to intercept scroll events and do something smart, but at least on a trackpad on Mac OS in Chrome it makes scrolling feel much worse and less predictable. It looks like Chrome, Firefox, and Safari all behave differently here, with Chrome behaving the worst.

Your users know better than you how fast they intend to scroll. Always.

Both have merits though.

Your brain is excellent at turning words, even long ones, into instantly recognizable shapes. That's why transposing lteters as I'm doign in this sentnce doesn't harm readability very much.

Good, easily-maintained code is not poetry, and it's not math. It's Hemingway: short, terse sentences that say only what they need to say and nothing more. They are self-contained and self-evident.

On a semi-related note, there's a study showing that non-programmers have a much easier time reading code with more white space. To adapt your example above:

  var newCustomers = getNewCustomers()
  
  foreach(var newCustomer in newCustomers)
  {
     newCustomer.this .that etc.
  }

function a(b) ... requires reading the whole function definition to understand what it does.

function createNewUser(userInfo) ... tells you exactly what it is and what it does. Especially if you're dealing with pure functions, it makes reading and understanding a code base much faster (and decreases the need for documentation).

That said, it doesn't attempt to read your mind, so the intellisense only kicks in when the type you're interacting with is unambiguous. So, for example, you'll need to explicitly state a function parameter's type before intellisense will help you figure out what methods you can call on it.

The F# compiler used to emit "tail." prefixes in every case that was eligible. But not only does the CLR have lots of restrictions, it was slower to request tailcalls.

Maybe that changed in the last version or two.

Edit: OK I found the email where I had asked fsbugs why tailcalls were no longer generated. But that was in 2009 so I'm more out of date than I remember.

In the release notes[1] for the May 2009 release, there's this section:

Optimizations for Tailcalls

On some implementations of the CLI, normal calls can be more efficient than tailcalls. An optimization is now applied to determine if a function is “closed” in the sense that it never takes any tailcalls outside a finite non-recursive callgraph. If so, the use of tailcalls is suppressed.

1: http://blogs.msdn.com/dsyme/archive/2009/05/20/detailed-rele...

It sounds like he's calling the F# functions directly.