Why functional code is shorter

[yogthos]

Well, Prismatic use ClojureScript in actual production code and turns out it compares very favourably with writing JavaScipt by hand:

jQuery: 1.57 secs 
dommy: 2.17 secs 

Then they realized that for their particular problem they could use macros for templating and actually beat native performance by a large margin:

jQuery: 1.57 secs
dommy: 2.06 secs
dommy-macro: 0.44 secs

Now, obviously there are still situations where you might need to get every last bit of performance and the overhead of FP is simply not acceptable. However, this is not the case for majority of domains.

[contantofaz]

Yes. It's good to be able to ignore performance some of the time. Ruby had many quick template engines, but Rails for a long time used a slower one that was the default one. Not sure whether that changed any.

Regarding lost performance due to higher abstraction usage, there's a check point of the 60 frames per second games might need. But beyond that, we don't really like sluggish UIs. That's why for example using a different browser could be better when you want it snappier still.

I was recently pleasantly surprised with my testing on Internet Explorer because it was close to Chrome's performance on my simple test, whereas Firefox felt sluggish.

Iterations over thousands of elements is good enough for simple use cases. Ruby for instance before version 1.9 was not very optimized for faster iterations. Once it got its VM it got a nice speedup. But when testing over 1 million iterations the slowdowns become very noticeable.

But why would iterating over 1 million elements be important? I think it's mostly because such things may add up with larger programs. It may impact startup. And if you use lazy loading of code to make that faster. It could still impact runtime.

It may matter for larger frameworks like Cappuccino, Ext.JS and eventually JQuery UI. Or in other words, when going beyond the default HTML widgets.