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

171–180 of 191 posts

Re: Functional programming jargon in plain English

#171

Post by Akronymus »

labrador wrote: post #100

When I was an assembly programmer, I knew C could help me When I was a C programmer, I knew OOP could help me When I was a JavaScript programmer, I knew TypeScript could help me. I don't know how functional programming can help me, but I'll keep trying to find a reason because people say it can

https://fsharpforfunandprofit.com/ This might provide a pathway to groking FP. As you mentioned in another comment to have c# experience, you should already have all the tools installed to get started in f# as well.

Re: Functional programming jargon in plain English

#172

Post by Akronymus »

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?

Because once you /get/ monads you see them everywhere.

Re: Functional programming jargon in plain English

#173

Post by IshKebab »

ebingdom wrote: post #110
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 agree about the math terminology, but I think it would be more confusing if we created a completely different set of vocabulary for the same concepts. So I don't really know what to do: refer to something by its proper name, or create a new, less precise name to make it sound less scary? Why do we find certain identifiers scary in the first place?

I don't. FP terminology is so bad that clearer names (Mappable, Chainable, etc.) would really help adoption.

You might say "but it will make it more confusing for people who already know the FP terms", but those people are a tiny minority of programmers so it doesn't make sense to cater to them. At least if you want your language to be popular among anyone except academics.

Re: Functional programming jargon in plain English

#174

Post by xigoi »

fhars wrote: post #39
ogogmad wrote: post #18

Earlier quoted context omitted.

Monads are (for better or worse) contagious. So when one function calls a monad, then it needs to be included in the monad as well. It makes introducing memoisation to a file, randomisation, and memoisation not-to-a-file (without using lazy evaluation to express it) difficult. I don't know whether the alternatives (effect systems for instance) help with this. I personally don't use functional languages because I find…

But then monads are a way to think about computations sequentially. If I write highly sequential code in a C-like language, in many cases most of the code is just boilerplate made necessary by the absence of native support for monads: int ret = doStepOne(); if (ret == RESULT_OK) { ret = doStepTwo(); } if (ret == RESULT_OK) { ret = doStepThree(); } return ret; would just be doStepOne() >>= doStepTwo() >>= doStepThree(…

You can have support for monads without using them for IO.

Re: Functional programming jargon in plain English

#175

Post by zaphirplane »

aeonik wrote: post #103
labrador wrote: post #100

When I was an assembly programmer, I knew C could help me When I was a C programmer, I knew OOP could help me When I was a JavaScript programmer, I knew TypeScript could help me. I don't know how functional programming can help me, but I'll keep trying to find a reason because people say it can

The biggest benefit I see is lack of side-effects. With a functional program you can be sure that your can safely call any function without having to worry about the current state of your app. A proper functional program can start to do very cool things safely: like hot reloading of code. When I'm debugging a Clojurescript app I can have a live running game, and update the physics without even reloading the page. It'…

I am finding “lack of side affect” to make reading reloading, updating, game hard to read

Re: Functional programming jargon in plain English

#176

Post by hither_shores »

b3morales wrote: post #139
cratermoon wrote: post #104

Earlier quoted context omitted.

Assuming that this guide is aimed at people entirely unfamiliar with these concepts, I think it fails to explain the concept. Yes, it is plain English, but it is not simple or common English, and it's mostly code examples. I'm familiar with the concepts, but not fluent, and functional programming jargon I already knew is not clearer to me now than it was before I read it. Good sample code, though. It only required me…

I agree, and not just the English. There is use of particular notation that does not explain anything unless you already know what it means: > f is a morphism from a -> b, and g is a morphism from b -> c; g(f(x)) must be equivalent to (g • f)(x) If I don't already understand (g • f)(x) this is not helpful at all. This other one especially jumped out at me (perhaps because I've personally never seen this "bent equals…

> What does that sign ≍ mean?

Normally, `f ≍ g` means `f \in \Theta(g)`. Here, the author is using it as an equals sign. I have no idea why.

Re: Functional programming jargon in plain English

#177

Post by Iceland_jack »

xigoi wrote: post #174
fhars wrote: post #39

Earlier quoted context omitted.

But then monads are a way to think about computations sequentially. If I write highly sequential code in a C-like language, in many cases most of the code is just boilerplate made necessary by the absence of native support for monads: int ret = doStepOne(); if (ret == RESULT_OK) { ret = doStepTwo(); } if (ret == RESULT_OK) { ret = doStepThree(); } return ret; would just be doStepOne() >>= doStepTwo() >>= doStepThree(…

You can have support for monads without using them for IO.

Separating IO is kind of the killer feature, something like `rand()` is not an int unless you're reading dilbert[1] or xkcd[2]. Basic equations break down in the face of an Int-valued IO-action being conflated with an Int

[1] https://dilbert.com/search_results?terms=Random+Number+Gener... [2] https://xkcd.com/221/

Re: Functional programming jargon in plain English

#178

Post by jerf »

jstanley wrote: post #127
jerf wrote: post #97

Earlier quoted context omitted.

I'm not trying to dodge your question, but the answer to your question is that until you work with it for a while you're not going to understand it. Any blog-sized, bite-sized snippet isn't impressive. You have to work with it for a while. I speak many computer languages, and one of the ways I measure them is, "what do I miss from X when using Y?" The answers will often surprise you; the thing you'd swear up and down…

Couldn't I "curry" a function f(x,y) to "partially apply" it on x=3 with just: function(y) { return f(3,y); } ? And then I've "partially applied" f. Is this what currying is? The syntax I posted is ambivalent about which arguments you're partially applying, isn't that superior to only being able to provide the first argument?

This is why I said to be sure to consider all the things you can do with function arguments. You can't in general assume that f(3) for a two-part argument can be read by the compiler as a curry, because the second argument may have a default. You also have to watch out in dynamic languages because the resulting function instead of a value may propagate a long way before being caught, making refactoring a challenge. (In Haskell it'll always blow up because the type system is strong, although you may not get the nicest error.) Imagine you have a whole bunch of code using this approach, and then you set a default value for the second argument. Imagine you're applying it to a whole bunch of code that wasn't written to optimize the first parameter as the one you want to partially apply.

The end result is you need a lot more noise in the partial call to indicate what it is you are doing, no matter how you slice it, and it interacts poorly with default parameters (which almost every language has nowadays) anyhow.

Re: Functional programming jargon in plain English

#179

Post by jerf »

skybrian wrote: post #121
jerf wrote: post #97

Earlier quoted context omitted.

I'm not trying to dodge your question, but the answer to your question is that until you work with it for a while you're not going to understand it. Any blog-sized, bite-sized snippet isn't impressive. You have to work with it for a while. I speak many computer languages, and one of the ways I measure them is, "what do I miss from X when using Y?" The answers will often surprise you; the thing you'd swear up and down…

That's an example of why Haskell code is often hard to read, and why I'm glad this isn't available in other languages. Why not write out the callback given to map using a let block? Then you can give meaningful names to intermediate values so it's easier to see how the pipeline works. (Though, functional programmers would probably pass up the opportunity and use one-letter variable names.)

"It depends". My long pipelines were still usually nice to read because I had context-relevant names and I didn't tend to name them with single letters. You could still read off from them what they were doing. However honesty compels me to admit that by Haskell standards I tended to write long variable names. Not everywhere; there's a lot of "f" in Haskell for "functions that I only know about them that they are funcitons" for the same reason one you aren't winning in C by insisting that every for loop has to use a descriptive variable rather than "i". But I tended towards the longer.

In real code I probably would have named it, but example code is always silly.

Re: Functional programming jargon in plain English

#180

Post by goto11 »

garethrowlands wrote: post #91
goto11 wrote: post #31

Earlier quoted context omitted.

They are used pervasively in Haskell, less so in other functional languages. In Haskell, you can't write a "Hello world" program without using monads, so you cant really avoid learning about them. IMHO monads are only really useful in Haskell because it has specific built-in syntax sugar to support them. Without this syntax sugar, they would be very cumbersome to use. So it's not really the monad type per se which is…

While it's true that `IO` in Haskell has a `Monad` instance, you don't really have to know that to do `IO` in Haskell. Certainly you don't need to know `Monad` in the abstract to use `IO` concretely. I like Haskell's `do` notation, which is its syntax sugar for monads, but it's really not that bad without. For example: do name isn't really that much nicer than: getLine >>= \name-> putStrLn ("Hello " ++ name) or even:…

You do need to understand the mechanics of monads in order to do even simple IO. E.g you can write:

    do name
But you cant write:

    do name
You have to write:

    do let name = "Buddy"
       putStrLn ("Hello " ++ name)
Now try to explain that without basically explaining what a monad is.
Post reply on HN