Live data from Hacker News

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

news.ycombinator.com

11–20 of 112 posts

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

#11
In Java terms, a "type constructor" would be a generic class like, say, `ArrayList`.

A constructor can be viewed as a function that takes values for the fields of a datatype and gives a value of the datatype in return. Not all functions are constructors, but some are.

At the type level, if we squint a little, "Maybe" or "List" behave a bit like constructors. They take types like "Int" or "Bool" as parameters, and give types like "Maybe Int" and "List Bool" in return. Not all type-level "functions" are type constructors (for example, in Haskell type families are not type constructors) but some are.

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

#12
Practice programming in a functional language. They enforce a lot of restrictions that you won't be used to, and in overcoming these restrictions, you'll begin to learn and understand the reason for the jargon.

It's really hard to explain "abstraction over type constructors" in a pithy manner despite being a relatively simple statement because the obvious follow-up is "but why?" And the answer to that question isn't going to satisfy you without an understanding of the functional programming environment.

It's exactly like when novice programmers get thrown into Java land in CS101 and you have to tell the to just ignore the whole class, public, private, static, etc jargon. They need to gain experience programming in that environment to really appreciate those concepts.

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

#15
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.

This comment is a textbook example of the Blub Paradox.

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

#16
"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, Maps and Options and so on (aka "Functors" in Haskell parlance). We've "abstracted (the function map) over the type constructor (of the data structure being mapped over)".

To answer your more general question, if you just learn functional programming on a language with a powerful type system (Haskell is probably the most germane example) you will learn at least some of these terms. Most of them turn out not to be very deep, just hard to explain (for reasons unclear to those who understand them), but still very useful.

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

#17
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.

This comment is a textbook example of the Blub Paradox.

I had a very visceral experience of Blub in my formative years. I don't recall how old I was, certainly under 11. I was explaining to my father the many things I could do in LOGO, and he asked about arrays. LOGO supports arrays, of course, but it was beyond anything I'd dealt with. I remember that feeling of entirely not understanding why you'd want to bother with arrays instead of just making more variables.

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

#18

Earlier quoted context omitted.

This comment is a textbook example of the Blub Paradox.

I had a very visceral experience of Blub in my formative years. I don't recall how old I was, certainly under 11. I was explaining to my father the many things I could do in LOGO, and he asked about arrays. LOGO supports arrays, of course, but it was beyond anything I'd dealt with. I remember that feeling of entirely not understanding why you'd want to bother with arrays instead of just making more variables.

I had a similar experience also at age 11 - I was learning C++ to solve my math homework problems. I heard about Python, tried it out, and went on IRC to ask how I could write "goto" statements in Python. I couldn't believe it when people told me they weren't necessary, and linked "Go To Considered Harmful"!

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

#19

I found it equally tough because while there are a lot of resources to cover the basics and get you coding in Haskell there isn’t much to bridge the middle ground from there to the level the deep enthusiasts and experts are at. All I can say is keep trying and reach our for help on IRC channels or at a local functional programming meetup (and by local these days you could remote in to any meetup you like!). They’ll b…

> type constructors take a type and return a type

Ordinary constructors, which everyone here is familiar with, construct values. They may take some arguments, which are themselves values.

A type constructor constructs types. It may take some arguments, which are themselves types. List is a great example of a type constructor with one argument. `Bool` is a type, and arguably a type constructor with no arguments. `Either` is a type constructor with two arguments.

In C++, `Pair` is a type constructor with two arguments; although there are more constraints on how you can use it (or at least were last time I delved deep in C++).

An example of "abstraction over type constructors" would be something that lets you pass in a type constructor as an argument, giving different behavior (whether parametric or ad-hoc - sorry, more jargon...) depending on what you pick.

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

#20
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.

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.

Post reply on HN