9 ms·

I take huge issues with this statement > For a multitude of reasons, straight-line, sequential imperative code comes more naturally to programmers than functio

I take huge issues with this statement > For a multitude of reasons, straight-line, sequential imperative code comes more naturally to programmers than functional/declarative code in their conceptual program model On the contrary, I think most people are 'configured' to think declaratively and functionally. Many programmers on the other hand are somewhat mentally atypical in that they think quite imperatively. This leads them to pursue technical hobbies, like programming. However, we do a huge disservice to think that 'humans' are better at imperative stuff. In my experience, there's a significant subset of people that find declarative stuff significantly easier, but do not pursue programming when they take their first OOP course and are turned off. For me at least, I played around a bit with programming when young, but it never clicked for me until i started exploring the declarative and functional languages. These just came way easier to me than everything else, and had I not been exposed to them, I doubt I would have continued in this as a profession.

wcrichton 9y ago
To be clear, I mean that in an empirical sense more than a prescriptive sense. More people use imperative code than functional code, and one hypothesis is that it's simpler for people to think in terms of instructions. But as I mentioned earlier in the post, that's purely a hypothesis which should be the subject of further research!
- Roboprog 9y ago
  Good thread here. Good topic for a “multiple kinds of intelligence “ type study. E.g. most of my coworkers prefer itty bitty steps in longish methods (where I feel like the point is lost in the noise) to functional programming style compound expressions where the result/goal is on top and the details nested.
erikpukinskis 9y ago
You're right people's first thought tends to be declarative. But the problem is, programming isn't about just putting down a first order encoding of your needs. It's about bridging the gap between that encoding and the libraries actually available to you. That's where declarative programming becomes unintuitive to people. How do you bridge the gap between your declaration and the declarations provided by Rails/Vue/Webpack/etc? You need to somehow imagine the transformation that will get you there. Imperative programs, on the other hand, always have a ready axis for decomposition: time. You break your program up into tiny time slices, and then work backwards to find procedures that that get you to the first one, then the second one, etc, until you hit the end of your program. With declarative programs, you need to slice the program in an abstract space. In my experience it takes 6-12 months to get up to speed with a new declarative programming landscape like Rails or Ember.
- ak39 9y ago
  Thanks. I’ve been following this sub-thread with interest. I have very little theoretical understanding of the differences between imperative and declarative (functional) paradigms. I used this video to get a better understanding - I hope it helps others too: https://m.youtube.com/watch?v=sqV3pL5x8PI https://m.youtube.com/watch?v=sqV3pL5x8PI
- tathougies 9y ago
  Well, yes, our current implementations of computation ultimately are all imperative, which explains the preponderance of imperative thinker in the programming field. However, this is an implementation detail. Had the first processors been declarative (as they very well could have been, when you think of thing like automaton chips), we would have seen things play out differently. My point was that making broad generalizations like the one above automatically shuts out a large portion of the potential programming community.
- shalabhc 9y ago
  > Imperative programs, on the other hand, always have a ready axis for decomposition: time. Insightful comment. When using libraries, we always use the API in an imperative way. Even if the library uses a declarative model, we pass around declarative data via imperative API calls. Is this because imperative is somehow more natural and easy? Or is it is because the fundamental cross library binding model in a C/Unix world is imperative only? In a different world, what would a declarative binding model even look like? If the system provided a declarative binding model (e.g. by exposing a library as set of bindable data flow cells, instead of a set of callable functions) perhaps integrating with declarative libraries might be easier?

wcrichton 9y ago

To be clear, I mean that in an empirical sense more than a prescriptive sense. More people use imperative code than functional code, and one hypothesis is that it's simpler for people to think in terms of instructions. But as I mentioned earlier in the post, that's purely a hypothesis which should be the subject of further research!

Roboprog 9y ago
Good thread here. Good topic for a “multiple kinds of intelligence “ type study. E.g. most of my coworkers prefer itty bitty steps in longish methods (where I feel like the point is lost in the noise) to functional programming style compound expressions where the result/goal is on top and the details nested.

erikpukinskis 9y ago

You're right people's first thought tends to be declarative. But the problem is, programming isn't about just putting down a first order encoding of your needs. It's about bridging the gap between that encoding and the libraries actually available to you. That's where declarative programming becomes unintuitive to people. How do you bridge the gap between your declaration and the declarations provided by Rails/Vue/Webpack/etc? You need to somehow imagine the transformation that will get you there. Imperative programs, on the other hand, always have a ready axis for decomposition: time. You break your program up into tiny time slices, and then work backwards to find procedures that that get you to the first one, then the second one, etc, until you hit the end of your program. With declarative programs, you need to slice the program in an abstract space. In my experience it takes 6-12 months to get up to speed with a new declarative programming landscape like Rails or Ember.

ak39 9y ago
Thanks. I’ve been following this sub-thread with interest. I have very little theoretical understanding of the differences between imperative and declarative (functional) paradigms. I used this video to get a better understanding - I hope it helps others too: https://m.youtube.com/watch?v=sqV3pL5x8PI https://m.youtube.com/watch?v=sqV3pL5x8PI
tathougies 9y ago
Well, yes, our current implementations of computation ultimately are all imperative, which explains the preponderance of imperative thinker in the programming field. However, this is an implementation detail. Had the first processors been declarative (as they very well could have been, when you think of thing like automaton chips), we would have seen things play out differently. My point was that making broad generalizations like the one above automatically shuts out a large portion of the potential programming community.
shalabhc 9y ago
> Imperative programs, on the other hand, always have a ready axis for decomposition: time. Insightful comment. When using libraries, we always use the API in an imperative way. Even if the library uses a declarative model, we pass around declarative data via imperative API calls. Is this because imperative is somehow more natural and easy? Or is it is because the fundamental cross library binding model in a C/Unix world is imperative only? In a different world, what would a declarative binding model even look like? If the system provided a declarative binding model (e.g. by exposing a library as set of bindable data flow cells, instead of a set of callable functions) perhaps integrating with declarative libraries might be easier?