Live data from Hacker News

Ask HN: How to be fluent in functional language speak?

news.ycombinator.com

21–30 of 112 posts

Re: Ask HN: How to be fluent in functional language speak?

#21
Question 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 some people writing about FP I feel there is some risk of people doing this.

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…

> 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?

#23

Question 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.

Re: Ask HN: How to be fluent in functional language speak?

#24
post #14

Give 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.

I am not sure. Approximately 5-10% of of tools I interact with are written in Haskell. So I think you are wrong.

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"?

Because the concept is category-theoretic in nature and they wanted to foreground that.

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"?

That would probably have been clearer to newbies, but they already had a complete terminology ready to go from category theory and it's not hard to remember "Functor ~ Mappable". Plus, "obvious" names break down once you start building up hierarchies of these properties. One of the reasons people have a hard time communicating the (simple) ideas behind other algebraic objects like Applicatives, Monads, etc. is because it's hard to come up with short, self-descriptive names for them. The search for such names has resulted in several famously bad analogies, such as "a Monad is like a Burrito".

Re: Ask HN: How to be fluent in functional language speak?

#27

Question 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…

I've outsmarted my future-self on several occasions. So yeah, there's a risk.

Re: Ask HN: How to be fluent in functional language speak?

#28
post #23

Question 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.

On that, I have seen lot of TypeFunctorMapMutatorKeywordsBeingImported to shorten the code and make it elegant...of course from the standard library or modules.

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?

#29
post #20

Earlier 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.

No, because it is possible to add power without adding features. This is typically called generality. In fact, adding features really can’t do much to change how fundamentally expressive a language is.

Re: Ask HN: How to be fluent in functional language speak?

#30

I 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.

You run the risk of being lynched by the Haskell mob, with talk like that. But I agree, in principle.

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.

Post reply on HN