Is there also a risk with FP too that people fall a little too much in love with “elegant” code only to find out later that maybe simpler is better? Reading some people writing about FP I feel there is some risk of people doing this.
Ask HN: How to be fluent in functional language speak?
21–30 of 112 posts
Re: Ask HN: How to be fluent in functional language speak?
#22"abstraction over type constructors" isn't very meaningful without more context anyway, but they're probably referring to something like the following: non-abstracted: map :: (a -> b) -> List a -> List b abstracted: map :: Functor f => (a -> b) -> f a -> f b "List" is a type constructor (it takes a type and returns a type), but we can write a "map" function that works over more types than just List - for example, Map…
Then why didn't they just call those types "Mappables"?
Re: Ask HN: How to be fluent in functional language speak?
#23Question to all the functional programming experts: When OOP got introduced people started building all these elaborate object hierarchies and design patterns only to find out after a while that simpler is better and most features should be used rarely or never. Is there also a risk with FP too that people fall a little too much in love with “elegant” code only to find out later that maybe simpler is better? Reading…
Re: Ask HN: How to be fluent in functional language speak?
#24Give up while you can. Immutable data classes and functional pipelines are great, everything else isn't worth it. Lots of people say FP is amazing but very few people use it in the real world because like you say, its unintelligible.
Lot of webdev stuff is moving to functional paradigms. Lazy evaluation, streams/iterator pattern combined with map/reduce/filter (FRP). You can pick out any modern ui framework and you would be drowning in fp soon enough.
Many attempts at building a functional language for web - purescript, elm, reasonml etc.
Re: Ask HN: How to be fluent in functional language speak?
#25"abstraction over type constructors" isn't very meaningful without more context anyway, but they're probably referring to something like the following: non-abstracted: map :: (a -> b) -> List a -> List b abstracted: map :: Functor f => (a -> b) -> f a -> f b "List" is a type constructor (it takes a type and returns a type), but we can write a "map" function that works over more types than just List - for example, Map…
> We've "abstracted (the function map) over the type constructor (of the data structure being mapped over)". Then why didn't they just call those types "Mappables"?
Re: Ask HN: How to be fluent in functional language speak?
#26"abstraction over type constructors" isn't very meaningful without more context anyway, but they're probably referring to something like the following: non-abstracted: map :: (a -> b) -> List a -> List b abstracted: map :: Functor f => (a -> b) -> f a -> f b "List" is a type constructor (it takes a type and returns a type), but we can write a "map" function that works over more types than just List - for example, Map…
> We've "abstracted (the function map) over the type constructor (of the data structure being mapped over)". Then why didn't they just call those types "Mappables"?
Re: Ask HN: How to be fluent in functional language speak?
#27Question to all the functional programming experts: When OOP got introduced people started building all these elaborate object hierarchies and design patterns only to find out after a while that simpler is better and most features should be used rarely or never. Is there also a risk with FP too that people fall a little too much in love with “elegant” code only to find out later that maybe simpler is better? Reading…
Re: Ask HN: How to be fluent in functional language speak?
#28Question to all the functional programming experts: When OOP got introduced people started building all these elaborate object hierarchies and design patterns only to find out after a while that simpler is better and most features should be used rarely or never. Is there also a risk with FP too that people fall a little too much in love with “elegant” code only to find out later that maybe simpler is better? Reading…
Generally in FP, “elegant” == simpler.
When you could have written it yourself with one or two extra lines. Why? Is it simpler? Or is it unnecessarily abstracted?
Re: Ask HN: How to be fluent in functional language speak?
#29Earlier quoted context omitted.
This comment is a textbook example of the Blub Paradox.
Thanks for introducing me to the Blurb Paradox! Though on first glance, doesn't it suggest that all programming features are good, and only their absence is bad? St. Exupéry's idea of perfection would disagree.
Re: Ask HN: How to be fluent in functional language speak?
#30I never use those terms and main programming goto is clojure. "abstraction over type constructors" might have to do with typing and not related to functional programming.
The hardcore “sound types” crowd believes that anybody using dynamic types is doomed.
I must not have the same problems they do.
First class functions; closures; higher order functions; partial function application, seasoned with the occasional variadic vs fixed arity function, and I’m good.
One can learn the other 95% of the jargon to deal with 5% of the problems later.