Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programming jargon in plain English

github.com

Post reply on HN
Print view View original

41–50 of 191 posts

Re: Functional programming jargon in plain English

#41

Post by ncmncm »

lordnacho wrote: post #28
singaporecode wrote: post #10

All these niche functional programming languages are an exercise in pseudo intellectualism Give me an object oriented language any day. The world is made of state and processes, (modern niche) functional programming goes too far to derecognise the value of state in our mental models The good thing about functional programming is stressing to avoid side effects in most of the code and keep it localised in certain plac…

Doesn't every mainstream language these days allow you to pick what style you want according to the situation?

That practically defines mainstream language, alongside having been blessed with a non-repeatable miracle.

But C, Java, and Go don't.

Re: Functional programming jargon in plain English

#42

Post by TrackerFF »

While I appreciate FP using terminology from its math origins - I do think it's a huge barrier for entry, and not really sure languages that cling onto them, will see much real mainstream success.

But then again, I don't think the language maintainers et. al. are too concerned with widespread success. Just some observations, but the majority of people I know that actively use FP languages, are academics. I've encountered some companies that have actively gone with a FP language for their main one - but some have reverted, I guess due to the difficulty of hiring.

With that said - functional elements are becoming more common in widespread languages, but not all the way.

Re: Functional programming jargon in plain English

#43

Post by ncmncm »

TrackerFF wrote: post #42

While I appreciate FP using terminology from its math origins - I do think it's a huge barrier for entry, and not really sure languages that cling onto them, will see much real mainstream success. But then again, I don't think the language maintainers et. al. are too concerned with widespread success. Just some observations, but the majority of people I know that actively use FP languages, are academics. I've encount…

A "functional language", like an "object-oriented language", is an exercise in futility. But support for a functional approach in a general language will often be useful.

Re: Functional programming jargon in plain English

#44

Post by ncmncm »

mjburgess wrote: post #34
stingraycharles wrote: post #13

Earlier quoted context omitted.

I completely understand what you’re saying, but assuming that this guide is aimed at people entirely unfamiliar with these concepts, I’m not sure whether these “ideas” provide any meaningful explanation to them. Demonstrating by example what e.g. currying actually looks like is much more powerful, at least from my point of view. In that regard, I’m actually pleasantly surprised this guide does a very good job at that…

Currying is one of those cases where the code is the explanation I think in many cases this isnt right, eg., Monads. The reason flatMap() "flattens" is just that "flattening" is really just sequencing, denesting the type using a function requires a sequenced function call: f(g(..)) This applies to many of these "functional design patterns"... theyre just ways of expressing often trivial ideas (such as sequencing) und…

We need an explanation why we should care about support for currying. Where it is really just to support variadic argument lists, it is a big hammer for a little problem.

Re: Functional programming jargon in plain English

#45

Post by reuben364 »

mjburgess wrote: post #25
shikoba wrote: post #16

Earlier quoted context omitted.

> Functor = context for running a single-input function No a functor is a "function" over types that can transport the arrows: (A -> B) -> (F A -> F B) for a covariant functor (A -> B) -> (F B -> F A) for a contravariant functor With the sum and product there is also the exponential: B^A = functions from A to B

In my simple language, `F` is that context. And (A->B) is a single-argument function. // Int -> Float oneArgFn(x) = x + 1.1 // List of Int -> List of Float ctxOneArgFn(xs) = ListFunctor(oneArgFn, xs) //ie., map()

Single-argument doesn't capture the difference between functor and applicative.

  ex1 :: Functor f => f (Int, Int) -> f Int
  ex1 = map (uncurry (+))
Applies a multi-argument function within a functor. What applicative allows you do is take a product of contexts to a context of products, and lift a value to a context.

  pure :: a -> f a
  zip :: (Applicative f) => (f a, f b) -> f (a, b)
This can then be used to make ex1 into a multi-argument function of contexts, which is not the same as (uncurry (+)) being a multi-argument function

  ex2 :: (Functor f) => (f Int, f Int) -> f Int
  ex2 = ex1 . zip

Re: Functional programming jargon in plain English

#48

Post by cinntaile »

goto11 wrote: post #36

Pet peeve: The word "just" when used to gloss over something with the author don't know how to explain. Using "just" shift the burden from the author to the reader, since it signals it is the readers fault if they don't understand. > A homomorphism is just a structure preserving map. In fact, a functor is just a homomorphism between categories as it preserves the original category's structure under the mapping. How a…

This is left as an exercise to the reader.

Re: Functional programming jargon in plain English

#49

Post by mgaunard »

mjburgess wrote: post #4

These definitions don't really give you the idea, rather often just code examples.. "The ideas", in my view: Monoid = units that can be joined together Functor = context for running a single-input function Applicative = context for multi-input functions Monad = context for sequence-dependent operations Lifting = converting from one context to another Sum type = something is either A or B or C.. Product type = a recor…

Currying is just systematic partial function application for each argument.

Re: Functional programming jargon in plain English

#50

Post by stingraycharles »

ncmncm wrote: post #44
mjburgess wrote: post #34

Earlier quoted context omitted.

Currying is one of those cases where the code is the explanation I think in many cases this isnt right, eg., Monads. The reason flatMap() "flattens" is just that "flattening" is really just sequencing, denesting the type using a function requires a sequenced function call: f(g(..)) This applies to many of these "functional design patterns"... theyre just ways of expressing often trivial ideas (such as sequencing) und…

We need an explanation why we should care about support for currying. Where it is really just to support variadic argument lists, it is a big hammer for a little problem.

And precisely because of the code sample, it should be obvious that currying is not the same as variadic function arguments.

Instead, it allows for very concise partial function application, as demonstrated by the code. I can just call any function with a subset of its arguments, and it automatically returns a “new function” which you can call with the remainder of the arguments. It allows you to reason about calling functions in a different way.

Currying is one of those concepts done very well in languages such as Haskell (not a coincidence, as both derive their name from Haskell Curry).

But saying it’s a “big hammer to implement variadic function arguments” is like saying that pattern matching is a big hammer to implement a switch statement. Yes, it provides that functionality, but also much more in a very elegant manner.

Post reply on HN