Live data from Hacker News

Functional programming jargon in plain English

github.com

111–120 of 191 posts

Re: Functional programming jargon in plain English

#111

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…

Why do you care? Just link directly to the rendered markdown.

Re: Functional programming jargon in plain English

#112
post #97
post #57

Earlier quoted context omitted.

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…

OK, thank you. The key seems to be that argument lists for functions in a language with easy currying are carefully designed so as to make currying maximally useful.

Re: Functional programming jargon in plain English

#113

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…

Send a PR to the repo!

Re: Functional programming jargon in plain English

#114
post #103

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'…

Julia gives such beautiful examples for composabilty: Feed 3km+-10m into an algorithm which was written with just numbers in mind and units and confidence intervals often propagate all the way through.

Re: Functional programming jargon in plain English

#115
post #16

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…

> 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

Send a PR to fix it!

Re: Functional programming jargon in plain English

#116
post #86
post #73

Earlier quoted context omitted.

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.

This is one of those things where looking at the type signature hard enough eventually gives the game away, but most writing on it sucks: bind :: m a -> (a -> m b) -> m b Because that function in the middle takes an `a`, your implementation of `bind` needs to be able to take an `m a` and pull an `a` out of it, which means it also has to evaluate however much of `m` is needed to actually get to that `a`. Because that…

Caveat: there is the trivial case of calling the middle function zero times. Which does happen (in the case of a Maybe type) but presumably any useful code needs to be able to call the function sometimes.

Re: Functional programming jargon in plain English

#117
post #5
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?

I think one of the reasons for the meme is because there's so many monad tutorials. When a Haskeller is introduced to monads they'll run across all these monad tutorials with abstruse analogies for what a monad is. Is a monad a burrito? Or a space suit? Odds are that none of these analogies will make much sense and the programmer will have to figure out on their own, what is the deal with monads after all. At some point they might have an epiphany; monads are the sort of idea that is actually pretty neat when it "clicks". They will feel compelled to write a monad tutorial, and thus history repeats itself.

Re: Functional programming jargon in plain English

#119

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

You can get a lot of mileage out of functional programming as a style without using a functional programming language, and you can do it in (almost) any other language, the big one: avoid side effects to functions as much as possible. That alone can make all the difference between a maintainable, refactorable and testable codebase compared to one that has side effects all over the place. If that's all you get out of it that's profit.

Re: Functional programming jargon in plain English

#120
post #103

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'…

Exactly.
Post reply on HN