Live data from Hacker News

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

news.ycombinator.com

31–40 of 112 posts

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

#31
post #23

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?

I mean, that’s on a case by case basis. I personally tend to do most of my FP in OCaml and F#, which have less of the tendency towards infinite abstraction that people sometimes accuse Haskell programmers of. I don’t think the approach you describe is elegant, but this is highly subjective.

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

#32
post #23

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?

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?

#33
I 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 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?

#34

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

Doomed is a bit of a strong word. I personally prefer static types because they reduce the number of unit tests I have to write, and at a higher level (following from this) they can inform the design of a system in a way that encourages robustness. Algebraic data types are not really inherent in functional programming at all; as you mention you can do it just fine in a dynamic language and a good chunk of ADTs and type stuff translates to say Rust as well.

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

#35

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

It’s definitely not _always_ just about code reuse, particularly when you start really stacking GHC pragmas and such.

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

#36

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

This is wrong, those variants are value constructors. The type constructor there is “answer,” there’s only one of them.

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

#37
First, you probably don't need to read academic articles to learn about functional programming. There's really nothing magical or complicated with functional programming. For instance, Scheme or OCaml are routinely used as beginner programming languages in schools around the world.

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

I think this is a great question because it tends to come up a lot.

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.

[1] https://en.wikipedia.org/wiki/Monoid

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

#39
I guess the answer is simply: just study funcional programming. 30 minutes into any basic haskell course (e.g. the wikibook, or real world haskell) and you would know what a type constructor is. I don't know, you can't expect to magically know things without studying them first? :) What you mean when you say "functional programming speak" is just common technical terms with a specific technical meaning. You wouldn't complain you don't understand the meaning of "Minkowsky metric" before learning relativity :p

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

#40

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

> The hardcore “sound types” crowd believes that anybody using dynamic types is doomed.

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.

Post reply on HN