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

91–100 of 191 posts

Re: Functional programming jargon in plain English

#91

Post by garethrowlands »

goto11 wrote: post #31
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?

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:

    getLine >>= \name->
    putStrLn ("Hello " ++ name)
The main reason that monads are important in Haskell is that programs that do IO simply are not functions in a mathematical sense. If Haskell were limited to functions, it wouldn't be able to do IO.

Re: Functional programming jargon in plain English

#92

Post by jhrmnn »

automatic6131 wrote: post #90

The absolute state of github projects. This project should be exactly 1 (one) file. The readme.md. LICENSE - There is a license? Why? Someone might steal the text for their own blog post? So what? The license won't stop them. package.json - to install dozens of packages for... eslint. Just install globally. It's just markdown and code examples. Yarn.lock - ah yeah let's have this SINGLE, NON EXECUTABLE TEXT FILE be o…

The document appears to have 80 contributors, that's hard to do with a blog post. It could have been a wiki page. But then I'm not sure if hosting a single repo on Github is harder than hosting a wiki. And of course Github provides superior platform for collaboration compared to a wiki.

Re: Functional programming jargon in plain English

#93

Post by seandoe »

automatic6131 wrote: post #90

The absolute state of github projects. This project should be exactly 1 (one) file. The readme.md. LICENSE - There is a license? Why? Someone might steal the text for their own blog post? So what? The license won't stop them. package.json - to install dozens of packages for... eslint. Just install globally. It's just markdown and code examples. Yarn.lock - ah yeah let's have this SINGLE, NON EXECUTABLE TEXT FILE be o…

I think it's cool that it's a repo. Now other people can submit pull requests and improve it. As for the files, bah whatever. Go find a squirrel to bark at.

Re: Functional programming jargon in plain English

#95

Post by sanderjd »

ncmncm wrote: post #35

This is more helpful than anything I have ever encountered on the topic. Comments: 1. It should explain map somewhere before it is used. 2. For the more abstruse and abstract concepts, a comment suggesting why anybody should care about this idea at all would be helpful. E.g., "A is just a name for what [familiar things] X, Y, and Z have in common." 3. It goes off the rails halfway through. E.g. Lift.

Expanding on your #1, I think they could use some more definitions. As you say, they use "map" in its functional programming sense before defining it, but I think more confusing is this one:

> A category in category theory is a collection of objects and morphisms between them.

What is a "morphism"?

I think this is a great starting point though, which could use some expansion.

Re: Functional programming jargon in plain English

#96

Post by garethrowlands »

ratww wrote: post #24
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…

Monads themselves aren't really contagious, it's the actions that would otherwise have side-effects that are, and also the fact they have to be executed in sequence. This is also true for other things in other paradigms, such as async functions in javascript. This is a good thing, however. In imperative programming, you have invisible temporal coupling. In pure-FP you have the same coupling, but it's exposed.

While I broadly agree with you, I think the post you're responding to has a point. You can't, in general, get a value back out of a monad, so if you call a monadic function, you may well have to return a monad. The obvious example is IO: there's no (safe) way get the `a` from `IO a`, so IO is kinda contagious.

Then again, there are lots of monads, such as `Maybe` and `List`, where you can get values out. These aren't contagious at all.

I agree with you that this is a good thing. Effects show up in the type signature - and it's all about those effects and managing them.

Re: Functional programming jargon in plain English

#97

Post by jerf »

ncmncm wrote: post #57
stingraycharles wrote: post #50

Earlier quoted context omitted.

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…

Saying "it allows for very concise partial function application" does nothing but repeat the definition. It does not, in particular, offer any reason to want that. What is so special about the first argument, that I want to fix it? Why not the third? Why is what I do to fix the third not just as good for the first? Pattern matching is a good example of a language feature included because they could not figure out how…

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 you'd miss from X you may never think of again if you leave the language, and some feature you hardly consider while you're in the thick of programming in X may turn out to be the thing you miss in every other language for the rest of your life. For me, one of the things I deeply miss from Haskell when programming elsewhere is the fluidity of the use of partial function application through the currying syntax. I see so many people trying to force it out of Haskell into some other language but there just isn't any comparison to the fluidity of

    map someFunc . filter other . map (makeMap x y) $ userList
Currying enables that syntax. If you don't see how, I'm not surprised. Sit down and try to write a syntax extension for an Algol-descended language that makes it work that well. Be honest about it. Run some non-trivial expressions through it. What I show above you should consider the minimum level of expression to play with, not the maximum. If you pick something like Python to work in, be sure to consider the interaction with all the types of arguments, like positional, keyword, default, etc. It can absolutely be done, but short of re-importing currying through the back door I guarantee the result is a lot less fluid.

The question about "what is special about the first argument" is backwards. The utility of the first argument is something you choose at writing time, not use time. The reason why map's first argument is the function to map on and the second is the list to map over is nothing more and nothing less than most of the time, users of map use it as I show above. There's no deep mathematical or group theory reason. If you don't like it there are simple functions to change the orders around, and the goal of picking function argument orders is just to minimize the amount of such functions in the code. Nothing more, nothing less.

Re: Functional programming jargon in plain English

#98

Post by Otek »

automatic6131 wrote: post #90

The absolute state of github projects. This project should be exactly 1 (one) file. The readme.md. LICENSE - There is a license? Why? Someone might steal the text for their own blog post? So what? The license won't stop them. package.json - to install dozens of packages for... eslint. Just install globally. It's just markdown and code examples. Yarn.lock - ah yeah let's have this SINGLE, NON EXECUTABLE TEXT FILE be o…

Wow, where should I start

> LICENSE - There is a license? Why? Someone might steal the text for their own blog post? So what? The license won't stop them.

But it’s still good that author underlined that he don’t want it to be copied. What’s wrong with that?

> package.json - to install dozens of packages for... eslint. Just install globally.

Then other contributors won’t know what version he used, what config he had, he won’t be able to easily recreate it on different computer, etc…

> Yarn.lock - ah yeah let's have this SINGLE, NON EXECUTABLE TEXT FILE be opinionated on the javascript package manager I use.

That’s author choice. Any good argument against it or you will just criticize for the sake of it?

> This should have never been a github repo. This is a blog post. It's a single, self contained post.

It’s a blog post with 270 different revisions, 80 contributors and a bunch of different languages. Show me how to easily do that with a blog post.

> I hate this crap. We have 9 files just to help 1 exist. It's aesthetically offensive

Why number of files is offensive to you? We have a couple tools good at what they do to keep things consistent and organized. Better to have these tools to keep standards than not.

Re: Functional programming jargon in plain English

#100

Post by labrador »

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

Post reply on HN