Most of my projects are on Bitbucket at the moment but will be moved to GitHub soon due to the shutdown of mercurial support.
See: https://bitbucket.org/labscript_suite/
Location
Australia
Education
PhD (Physics), BSc Advanced with honours (first class honours in Physics, majors: physics, maths)
I see something like this written in almost every article on functional programming:
"But, as you can see, the imperative code is verbose and not immediately clear. On the other hand, the declarative approach is readable and explicit, because it focuses on what we want to obtain."
Authors seem to treat it as objective fact that the declarative approach is clearer, and yet often I find myself able to be certain of what the code does (particularly with edge cases) when reading the imperative code, not the declarative code. Anyone with a familiarity of any programming language would be able to understand the imperative example, but I don't feel the same is necessarily true of the declarative example.
Is it just me, or are people who promote functional programming blinded by their experience and familiarity with that paradigm?
This is not to say one style is better than another, I just find such statements really jarring to read because it's not the case for me.
Agreed. Imperative was clearer to me in these examples. I use a combo of programming paradigms personally. Depends on the the situation.
The FP vs. OOP dichotomy is silly. They are and can be compatible with each other. In general, I take advice that suggests to use X in every situation with a grain of salt.
Of course. Every programming paradigm is clear to the person who internalized it. Same as with natural languages -- yes, there are a few "universal idioms" common to all (or most), but almost everything is based on familiarity, not on some high clarity independent of experience.
Just to show how easy it is to make this mistake: you make it too. :-P Look:
Anyone with a familiarity of any programming language would be able to understand the imperative example
Of course this is not true. There are many functional programming languages, and more and more people are starting with them, since more and more schools are realizing the benefits of FP (again, those benefits are not some lofty clarity ideals, but practical things like easier piecewise testing, and thus easier grading;). But I completely understand that it seems this way to you, precisely because your first experience is with imperative programming.
Your issue is about the concept of "abstraction", not really about paradigms. Indeed also OOP hides imperative code.
Let's put it in another way: the imperative approach exposes you to the implementation of some task. But it doesn't communicate clearly and immediately what's the purpose of your code.
When you find yourself in front of 1000+ lines of imperative code (maybe written by someone else) you'll only see a long block/blob of low-level code (until you decode it). This leads often to lose sight of the "why" or "what" the code is trying to accomplish.
Sometimes you don't even need to know the actual implementation. Often because is crystal clear what the function is supposed to do, or because a simple analysis of inputs/outputs will clarify the operation performed.
In any case, functions/classes/modules etc. are written by someone, so when needed you can dive into the actual implementation. Same for built-in functions: the specs are clear about what they do and how.
So the point here is: the declarative style/code abstract away from low-level stuff (zoom out) so you can understand what's the goal/direction of the code in front of you. But you can always dig into the actual implementation if you need/want.
I see something like this written in almost every article on functional programming:
"But, as you can see, the imperative code is verbose and not immediately clear. On the other hand, the declarative approach is readable and explicit, because it focuses on what we want to obtain."
Authors seem to treat it as objective fact that the declarative approach is clearer, and yet often I find myself able to be certain of what the code does (particularly with edge cases) when reading the imperative code, not the declarative code. Anyone with a familiarity of any programming language would be able to understand the imperative example, but I don't feel the same is necessarily true of the declarative example.
Is it just me, or are people who promote functional programming blinded by their experience and familiarity with that paradigm?
This is not to say one style is better than another, I just find such statements really jarring to read because it's not the case for me.
Agreed. Imperative was clearer to me in these examples. I use a combo of programming paradigms personally. Depends on the the situation.
The FP vs. OOP dichotomy is silly. They are and can be compatible with each other. In general, I take advice that suggests to use X in every situation with a grain of salt.
Assuming a little bit of JS knowledge the declarative approach is absolutely clear.
Of course to appreciate the declarative style you have to know the language or the used functions.
Anyway, as I said in the article,there's no best choice. Any situation needs the right approach.
Of course. Every programming paradigm is clear to the person who internalized it. Same as with natural languages -- yes, there are a few "universal idioms" common to all (or most), but almost everything is based on familiarity, not on some high clarity independent of experience.
Just to show how easy it is to make this mistake: you make it too. :-P Look:
Of course this is not true. There are many functional programming languages, and more and more people are starting with them, since more and more schools are realizing the benefits of FP (again, those benefits are not some lofty clarity ideals, but practical things like easier piecewise testing, and thus easier grading;). But I completely understand that it seems this way to you, precisely because your first experience is with imperative programming.
Your issue is about the concept of "abstraction", not really about paradigms. Indeed also OOP hides imperative code.
Let's put it in another way: the imperative approach exposes you to the implementation of some task. But it doesn't communicate clearly and immediately what's the purpose of your code.
When you find yourself in front of 1000+ lines of imperative code (maybe written by someone else) you'll only see a long block/blob of low-level code (until you decode it). This leads often to lose sight of the "why" or "what" the code is trying to accomplish.
Sometimes you don't even need to know the actual implementation. Often because is crystal clear what the function is supposed to do, or because a simple analysis of inputs/outputs will clarify the operation performed.
In any case, functions/classes/modules etc. are written by someone, so when needed you can dive into the actual implementation. Same for built-in functions: the specs are clear about what they do and how.
So the point here is: the declarative style/code abstract away from low-level stuff (zoom out) so you can understand what's the goal/direction of the code in front of you. But you can always dig into the actual implementation if you need/want.
Good point, though!
I do this all the time but problem is that by time I get lot of this helpers scatter around the code base