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

71–80 of 191 posts

Re: Functional programming jargon in plain English

#71

Post by imtringued »

jstx1 wrote: post #5
ijidak wrote: post #3

This is great. Finally understand monads a little better. Definitely saving this for later.

Why do monads come up so often when people talk about FP? Is it a meme or are they really an important and difficult to understand concept?

public static void main(String[] args)

Why does this come up so often when people talk about Java?

Because beginners are confronted with the IO Monad if they want to write a Hello world program.

Monad is a typeclass that any datatype can implement. Monads have a then or flatmap like function that takes a Monad and a function that operates on the contents of the monad but also returns another monad of the same type which is then combined according to the implementation details of the specific monad that implements the monad typeclass.

Re: Functional programming jargon in plain English

#73

Post by urxvtcd »

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…

While I _think_ I understand monads on some rudimentary level through how join and bind operate, your "just sequencing" doesn't tell me anything. And this is a problem with a lot of these texts. Maybe that's trivial to the writers, but it makes me feel even dumber when I cannot understand a concept I already understand, lol.

Re: Functional programming jargon in plain English

#76

Post by olodus »

GnarfGnarf wrote: post #75

Can someone clarify something for me? If you build a linked list or a dynamically growing array in a Functional program, am I correct in understanding that the array is never modified, instead a copy is made and the new element is added to the copy of the array?

The result should be that after the addition you should not have affected the old array yes. The most basic way of implementing this is what you described. However, there are a number of different ways to optimize this. Since you know that the elements are immutable, if you add the new element to the start of the list you could just point it to the old elements and you now have two lists which share the majority of their elements. If you are interesting to learn about this more I would recommend looking into how for example Clojure implement their "persistent data structures". Most functional languages have similar things so you could find it elsewhere as well if you want.

Re: Functional programming jargon in plain English

#77

Post by tymscar »

frogulis wrote: post #11
jstx1 wrote: post #5

Earlier quoted context omitted.

Why do monads come up so often when people talk about FP? Is it a meme or are they really an important and difficult to understand concept?

Many important "effects" (e.g. non-determinism, IO, asynchrony, environmental context, state... etc) are modelled as monads in Haskell. You _can_ write Haskell code without understanding what a monad is, but composing and creating these things is going to be a little painful without that understanding. Additionally, it seems to be a harder concept to grasp than e.g. functors or monoids. I think this can be partly att…

I think this was some amazing insight. I understand monads and I can use/write them but I feel like the concept hasn’t FULLY clicked yet. While even now it hasn’t, I feel like your blogpost got me that step closer to it, so thank you!

Re: Functional programming jargon in plain English

#78

Post by pdpi »

GnarfGnarf wrote: post #75

Can someone clarify something for me? If you build a linked list or a dynamically growing array in a Functional program, am I correct in understanding that the array is never modified, instead a copy is made and the new element is added to the copy of the array?

Immutable, fixed size arrays are pretty easy to handle in a functional style, of course, but most functional languages only discourage mutability while not outright forbidding it, so you'll usually have access to mutable dynamically growing arrays that work the exact same way as you expect them to.

Because functional languages do discourage mutation, they tend to fallback on an implementation of linked lists where the lists are never modified (You can google for Persistent Data Structures for more). Because the list never changes, you can have two lists share a tail, by building on two different heads atop that tail (like a git branch of sorts, minus the merging).

If you want to build a pure language, you can build immutable dynamic-sizeable arrays with a copy-on-write setup. Growing the array keeps building on top of the existing buffer, if you outgrow it or need to actually mutate it, you make a copy.

If you want both purity and actual full-on mutability, e.g. Haskell has Data.Array.MArray, which locks the array behind a mutable context (like IO), so your pure code never sees any mutation.

Re: Functional programming jargon in plain English

#80

Post by dkarl »

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…

I think using math terminology is honest, in that it gives an accurate expectation of how the ideas can be communicated and learned. They are simple ideas that can be communicated in their entirety in just a few symbols, but it takes time, exposure, and practice to develop facility in their use and a feeling of "understanding."

That's the math experience. I know people hate that and would much rather it be a matter of reading some a nice explanation and then "aha" but there's no such explanation yet and after years of people trying to develop one there's no point in expecting one right around the corner.

Post reply on HN