I though the same: Clever but without practical use.
Reading the code fluently comes here to an unnecessary halt. map.has(true) ? map.get(true) : map.get('_') Reading this in a codebase makes me go WTF?!.
I tend to disagree. It mainly depends on your target audience.
Of course you could have a codebase where you enforce functional paradigms - which in itself might be not the worst idea. But in the context of Javascript this code above looks like shenanigans, stuffing patternmatching down the reader's throat. It is cool, that you found a way making your beloved pattern available in Javascript, but as I said above it disturbs the reading flow, because it makes you spent extra time to decipher what you intended.
A different example is the use of map and filter, which is native to the language: Although it might take some time for the untrained reader which was socialized with his for-loop to understand; but anybody fluent with the language does immediatly know what was intended.
For me it is a real time saver having code which is easy to read, easy to understand and therefore easy to debug.
I know it is fulfilling beating the language and making things happen, but the downside is oftentimes beating the language is beating the reader.
No offense. It might sound a bit harsh, but read it written with a mild undertone ;)
Sure I tend to agree if folks are familiar with functional paradigm and as you mention pattern matching etc then it’s a little easier and sure I probably could have kept the cata out where it looks in the Map and pulls out either when the condition is true or the default value.
I took no offense. Everyone is entitled to their own opinions.
I just got excited when I saw the post to share an alternative, which may not fit your interests or needs etc but I decided to share anyway and would do it again :)
Is there a specific benefit of this functional approach? Seems to accomplish the same thing but it took me longer to work out what it was doing.
I though the same: Clever but without practical use.
Reading the code fluently comes here to an unnecessary halt.
map.has(true) ? map.get(true) : map.get('_')Reading this in a codebase makes me go WTF?!.it depends on the codebase, again it was a quick example to showcase another alternative way :)
I tend to disagree. It mainly depends on your target audience.
Of course you could have a codebase where you enforce functional paradigms - which in itself might be not the worst idea. But in the context of Javascript this code above looks like shenanigans, stuffing patternmatching down the reader's throat. It is cool, that you found a way making your beloved pattern available in Javascript, but as I said above it disturbs the reading flow, because it makes you spent extra time to decipher what you intended.
A different example is the use of
mapandfilter, which is native to the language: Although it might take some time for the untrained reader which was socialized with his for-loop to understand; but anybody fluent with the language does immediatly know what was intended.For me it is a real time saver having code which is easy to read, easy to understand and therefore easy to debug.
I know it is fulfilling beating the language and making things happen, but the downside is oftentimes beating the language is beating the reader.
No offense. It might sound a bit harsh, but read it written with a mild undertone ;)
Sure I tend to agree if folks are familiar with functional paradigm and as you mention pattern matching etc then it’s a little easier and sure I probably could have kept the cata out where it looks in the Map and pulls out either when the condition is true or the default value.
I took no offense. Everyone is entitled to their own opinions.
I just got excited when I saw the post to share an alternative, which may not fit your interests or needs etc but I decided to share anyway and would do it again :)
Just a quick example of an alternative to the OPs object hash its similar to clojuredocs.org/clojure.core/cond or if you prefer JS ramdajs.com/docs/#cond