Earlier quoted context omitted.
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?
Ask HN: How to be fluent in functional language speak?
31–40 of 112 posts
Re: Ask HN: How to be fluent in functional language speak?
#32Earlier quoted context omitted.
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?
2. It's harder to understand. "Why didn't this use the standard library function? Is it doing something different? It doesn't look like it, am I missing something?"
Re: Ask HN: How to be fluent in functional language speak?
#33For example:
type answer = | Yes | No | Maybe
The type is 'answer'. The constructors are Yes, No, and Maybe (these are actually called type variants but now we're getting into jargon). I presume an 'abstraction over type constructors' means you want to generalize that type, so you can use the constructors to produce an abstract type that works with any type but I've never heard that specific term.Re: Ask HN: How to be fluent in functional language speak?
#34I 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 9…
Re: Ask HN: How to be fluent in functional language speak?
#35Earlier quoted context omitted.
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?
1. It's code reuse. Don't rewrite code that's already written. 2. It's harder to understand. "Why didn't this use the standard library function? Is it doing something different? It doesn't look like it, am I missing something?"
Re: Ask HN: How to be fluent in functional language speak?
#36I also dislike unnecessary use of programming jargon. A type constructor is all the possible ways to make a value of that type. For example: type answer = | Yes | No | Maybe The type is 'answer'. The constructors are Yes, No, and Maybe (these are actually called type variants but now we're getting into jargon). I presume an 'abstraction over type constructors' means you want to generalize that type, so you can use th…
Re: Ask HN: How to be fluent in functional language speak?
#37You can start with the basic concepts and eventually build your way up to more abstract constructs when you realize you need them. But even there, you don't need to know the academic terminology (or if you do, it'll make more sense when you get familiar with the language).
I frequently use monads and functors, yet I don't know much about category theory (and the little I know doesn't make me a better programmer).
Re: Ask HN: How to be fluent in functional language speak?
#38"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"?
What do you call the following common operations?
- 1 + 0
- 1 * 1
- "string" ++ ""
- [1, 2, 3] ++ []
As far as I know there is no term for this grouping of operations outside of functional programming languages which use category theory.We call it a "monoid" based on the following precise definition:
> In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single associative binary operation and an identity element[1].
I used the "identity element" specifically in my examples above since they tend to be a good way to grasp what is going on.
It turns out a "functor" has more properties than just being "mappable", which is why we like using the more precise term in our literature. However, it's still a decent intuition if you aren't familiar with the concept.
For example, in the parent comment the 'f' in the second line of code shows that it is some kind of structure that adheres to a Functor, and also infers that this structure can also be mapped over. This is a nice property because without caring about the implementation, we can still do functor-specific operations over abstract structures.
Re: Ask HN: How to be fluent in functional language speak?
#39Re: Ask HN: How to be fluent in functional language speak?
#40I 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 9…
What they believe is that "dynamic types" is a misnomer, and if you think your program is checking dynamic types, it is in fact doing runtime pattern matching over a variant record. There's nothing wrong with pattern matching and variant records; but conflating them with types is just nutty, and using them pervasively as part of the ordinary flow of code is no different than programming in old-style VB.