4 ms·

being a javascript/typescript developer with little knowledge about functional programming, this article renewed my interest in the matter. I would be intereste

being a javascript/typescript developer with little knowledge about functional programming, this article renewed my interest in the matter. I would be interested to see some performance tests though, to get a feeling just how much 'a little performance cost' costs

lrichardson 12y ago
I was thinking about whipping together a perfJS for the curry function and putting it in the post but ended up not... I might make one and post it back here. --- UPDATE: I made this jsperf: http://jsperf.com/curry-function http://jsperf.com/curry-function There might be better things to test, but the results were actually unexpected. Currying "manually" with nested functions is actually slower than using my "curry" function. As I mentioned in my post, if you are touching the DOM at all, I really doubt you will see much of a performance hit from using this...
- rpwverheij 12y ago
  interesting! tnx for the extra effort to put that up.
reconbot 12y ago
Unless you're in tight loops you wont notice this perf hit. Disk, Network, and DOM manipulation will be the 99% time sinks.
- ceedan 12y ago
  That doesn't justify degrading the rest of your code base.
visarga 12y ago
Me too. I thought long and hard about how I could use functional programming (aside from the usual callbacks) and came to the conclusion that functional programming is more composable - that's its strength - how you can combine stages in a pipeline. It's all centered around data flow instead of execution flow. One example would be jQuery or Underscore - how you can chain operations with the "." operator, or another common example is how we use the pipe " | " operator in the shell to compose processes. I use the latter quite a lot and am proficient at making pipelines. By contrast, procedural programming relies a lot on global variables and that makes a mess of reusing pieces of code from an app into another.
- chriswarbo 12y ago
  I wouldn't say that procedural code relies on global variables, but I would say that we find ourselves worrying about execution order a lot more when using procedures rather than pure functions. If we care about execution order, we tend to avoid higher-order patterns which may defer execution (eg. compose) or give a nondeterministic order (eg. map). If we avoid higher-order patterns, we end up hard-coding an awful lot of control-flow, which makes our code less re-usable. Simplistic attempts to avoid this, introduce a small amount of higher-order behaviour, like passing around 'callbacks', but this can be cumbersome and add a lot of boilerplate. Of course, the solution to avoiding this is to use even more powerful higher-order functions (like monadic bind) to handle the callbacks for us, but since we're trying to avoid as much higher-order behaviour as possible, this tends not to be done.

lrichardson 12y ago

I was thinking about whipping together a perfJS for the curry function and putting it in the post but ended up not... I might make one and post it back here. --- UPDATE: I made this jsperf: http://jsperf.com/curry-function http://jsperf.com/curry-function There might be better things to test, but the results were actually unexpected. Currying "manually" with nested functions is actually slower than using my "curry" function. As I mentioned in my post, if you are touching the DOM at all, I really doubt you will see much of a performance hit from using this...

rpwverheij 12y ago
interesting! tnx for the extra effort to put that up.

reconbot 12y ago

Unless you're in tight loops you wont notice this perf hit. Disk, Network, and DOM manipulation will be the 99% time sinks.

ceedan 12y ago
That doesn't justify degrading the rest of your code base.

visarga 12y ago

Me too. I thought long and hard about how I could use functional programming (aside from the usual callbacks) and came to the conclusion that functional programming is more composable - that's its strength - how you can combine stages in a pipeline. It's all centered around data flow instead of execution flow. One example would be jQuery or Underscore - how you can chain operations with the "." operator, or another common example is how we use the pipe " | " operator in the shell to compose processes. I use the latter quite a lot and am proficient at making pipelines. By contrast, procedural programming relies a lot on global variables and that makes a mess of reusing pieces of code from an app into another.

chriswarbo 12y ago
I wouldn't say that procedural code relies on global variables, but I would say that we find ourselves worrying about execution order a lot more when using procedures rather than pure functions. If we care about execution order, we tend to avoid higher-order patterns which may defer execution (eg. compose) or give a nondeterministic order (eg. map). If we avoid higher-order patterns, we end up hard-coding an awful lot of control-flow, which makes our code less re-usable. Simplistic attempts to avoid this, introduce a small amount of higher-order behaviour, like passing around 'callbacks', but this can be cumbersome and add a lot of boilerplate. Of course, the solution to avoiding this is to use even more powerful higher-order functions (like monadic bind) to handle the callbacks for us, but since we're trying to avoid as much higher-order behaviour as possible, this tends not to be done.