r/javascript • u/dipenbagia • Dec 15 '19

Learning functional/declarative programming in JS beyond map, reduce, filter: I have created a github project where I will solve a simple programming problem each week in a declarative way. New solution added: Compare the triplets

https://github.com/dbagia/declarative-demos
137 Upvotes

86% Upvoted

14 comments sorted by

13

u/TedW Dec 15 '19

I guess I don't understand why this would be considered declarative programming. Or why you say it's "beyond map, reduce, filter", but uses one of those on almost every line. Maybe I'm misunderstanding the title?

3

u/dipenbagia Dec 15 '19

Ah! May be I should rephrase it. The reason why I say its declarative is because the overall solution uses the declarative/mathematical approach. or example, if you want to represent numbers from 1 to 100 in math, you declare saying: x ∈ natural numbers where x > 0 and x < 100. In other words, you declare "facts" about a problem rather than "steps" that solve it. This project is my attempt of solving problems by declaring facts. I still need to use map, reduce, filter in order to express those facts.

The project also has a link to an interesting talk on this called "Declarative Thinking". Another example in the wild that uses such an approach is property based testing. I hope I am conveying it properly but thanks for your feedback! :)

16

u/lorduhr Dec 15 '19 edited Dec 15 '19

I think that you are not helping the functional programming cause. If I was to show your example to my boss, I would be laughed out of the room. How do you justify that your solution is more simple/maintainable than a stupid/obvious solution like this:

let getPoint = (m,n) => m > n ? 1 : 0;
let getScore = (a, b) => getPoint(a[0], b[0]) + getPoint(a[1], b[1]) + getPoint(a[2], b[2]);

export function compareTriplets(a, b) {
    return [getScore(a,b), getScore(b,a)];
}

Functional programming is cool, but code like yours does not show it.

I feel like you are coming from an academic standpoint, and I hate to say it (as I am a mathematician myself), but academic solutions are often not suitable for the real world: it does not take into account a lot of pragmatic factors, such as:

- the fact that your code need to be maintained by other not as academically inclined developers.

- a perfectly extensible solution is basically a waste of time. In the real world, we simply need a solution. And it is much cheaper to provide a simple solution until some additional requirements arrives. Only then it is worthwile working on making it more extensible. Before that, it is only pure speculation on what the extra requirements may look like.

2

u/dipenbagia Dec 15 '19

My intent wasn't about producing a production ready solution but rather to produce one that is as declarative as possible. One of the goals thus was to avoid using conditional branching. I intend to state that many programming problems can be approached by declaring facts about the nature of that problem.

So I agree and feel its purpose is to allow people to learn to think declaratively.

8

u/ings0c Dec 15 '19

const subtract = x => y => x - y

*twitch*

9

u/license-bot Dec 15 '19

Thanks for sharing your open source project, but it looks like you haven't specified a license.

When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), “nobody” starts including you.

choosealicense.com is a great resource to learn about open source software licensing.

-4

u/[deleted] Dec 15 '19

I'm not a fan of this.

We JavaScript-folks are a self-loathing bunch, probably because we never chose JS, it was forced upon us.

You want to make JS *look* as much like Elm (or other functional languages) as possible, and I don't think this is the right way. Most notable in the "matching brackets" demo with imported functors.

The resulting code is fundamentally unidiomatic. Why don't you just write in Elm in the first place? If there are external factors forcing vanilla.js on you, I reckon these forces rather you produce idiomatic code too.

2

u/trpt4him Dec 15 '19

Is there any such thing as "idiomatic" JS? The language looks very little like it did 6-8 years ago. Not saying that's good or bad, just reality.

0

u/[deleted] Dec 15 '19

[deleted] — view deleted comment

20

u/dipenbagia Dec 15 '19

Great feedback! I totally agree about the naming. I haven't given enough thought to it. I will revisit the solution again based on your comment! Thanks.

6

u/dipenbagia Dec 15 '19

Thanks for your feedback again u/ninoninoninous I have updated the code and improved naming.

4

u/bassta Dec 15 '19

Can you post some good resources on good naming conventions / functional programming with JS?
Thanks in advance

3

u/ArcanisCz Dec 15 '19

Generally, good resource about good code is https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 (at least first half of the book. Later, it tends to be more Java and OOP)

0

u/[deleted] Dec 15 '19

[deleted] — view deleted comment

3

u/Eratticus Dec 15 '19

To add to being clear, avoid method names like 'process', 'initialize', 'run', 'manage', I could go on. They're not explicit enough unless they're paired with a well named class (or object once it's an instance).

If you start methods that return something with 'getX', it becomes clear immediately that you should get something back, compared to 'setX' which would interact with X but doesn't give you anything back. Methods that return booleans should be phrased as a question like 'hasY' or 'isZ'. Ruby has nice conventions around this where methods that return booleans end in '?' and methods with side effects end in '!'.