For one thing, the op mentioned that, while functions should be small, they usually aren't.
Functions shouldn't be small just to be small. Functions should be exactly the size needed to encapsulate their function. I had to wade through a few thousand lines of JavaScript in which every function was made as small as possible (since functions are supposed to be small). Stuff like (and I am not exaggerating):
var xor_it = function(a,b) {
return a^b;
};
var xor_them = function(l) {
out = 0;
for (x in l) {
out = xor_it(l[x], out);
}
return out;
};
Turns out that, when functions are written based on small size alone, it is nearly impossible to build a mental model of a system. I've reverse engineered some ugly code (the previous worst was an object oriented system hand-built in C (with constructors, vtables, and all)). That was child's play next to a few thousand lines of three-line functions.
On topic, I tend to agree with you. The best parts of Light Table have existed in one form or another for years, but that doesn't mean it isn't worthwhile to "Try, try again". Approaching an old problem with new vigor can result in amazing things, or nothing, but if you aren't willing to listen to criticism, you will never make a better mousetrap.
I agree that code with too small functions can be hard to understand, especially if the naming of functions is not top notch. And naming things is one of the hardest parts of programming. Ability to give good names requires thorough understanding of concepts involved, which often isn't true the first time (or even second time) you write the code.
There's also interesting discussion about "optimal" function length in Steve McConnell's Code Complete. If I recall correctly, there was no evidence that functions of even 100 LoCs for complex algorithms were significantly more error prone than similar code with shorter functions, and that very short functions actually lead to more bugs than code with functions with reasonable length. I think it is because of naming: it's hard to name hundreds of small things well.
That's definitely pathological, but not from a "small function" point of view. xor_it is simple unnecessary to write and xor_them is just a fold on xor_it. This is undue multiplication of names.
Functions shouldn't be small just to be small. Functions should be exactly the size needed to encapsulate their function. I had to wade through a few thousand lines of JavaScript in which every function was made as small as possible (since functions are supposed to be small). Stuff like (and I am not exaggerating):
Turns out that, when functions are written based on small size alone, it is nearly impossible to build a mental model of a system. I've reverse engineered some ugly code (the previous worst was an object oriented system hand-built in C (with constructors, vtables, and all)). That was child's play next to a few thousand lines of three-line functions.On topic, I tend to agree with you. The best parts of Light Table have existed in one form or another for years, but that doesn't mean it isn't worthwhile to "Try, try again". Approaching an old problem with new vigor can result in amazing things, or nothing, but if you aren't willing to listen to criticism, you will never make a better mousetrap.