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

101–110 of 191 posts

Re: Functional programming jargon in plain English

#101

Post by marcosdumay »

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…

As a hint, any time you read "just" in mathematics, replace it with "exactly". That may make it clearer.

Re: Functional programming jargon in plain English

#102

Post by garethrowlands »

rswail wrote: post #14
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…

Functional programming is actually mathematics based on lambda calculus. Imperative programming isn't. OOP is a failed metaphor, unless you use composition, not inheritance, even then, the actual basis for OOP was about the messages between objects, not the internals. > The world is made of state and processes No, the world is made of objects that have state and messages (events) between them.

There are limits on what lambda calculus can model though. For example, it doesn't model IO very well. So, these days, lambda calculus is only one of the parts of maths that informs functional programming.

Re: Functional programming jargon in plain English

#103

Post by aeonik »

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's all live.

A proper functional program really looks like a series of mappings from a collection of data sources to a collection of data sinks.

The keyword for this is referential transparency: https://www.braveclojure.com/functional-programming/

There are other benefits like composability, designing your programs this way will give you access to algorithms that works otherwise not work with your code. The simplest example is Map, Filter, and Reduce. These functions are by their very nature parallel because a compiler knows that there are no intermediate steps, unlike a for loop.

Re: Functional programming jargon in plain English

#104

Post by cratermoon »

stingraycharles wrote: post #13
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…

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…

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 to look up a handful of things I wasn't already familiar with.

Re: Functional programming jargon in plain English

#105

Post by cratermoon »

naillo wrote: post #33

"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." Oh ok. Plain english.

Best comment in this thread. The guide does a so-so job of building on terms previously defined. The term accumulator, for example, is not defined before use. The first appearance of it is under Catamorphism, where the guide says, "A reduceRight function that applies a function against an accumulator and each value of the array (from right-to-left) to reduce it to a single value."

I note, in passing, that the actual guide is just titled "Functional Programming Jargon". It does not claim to be "in plain English".

Re: Functional programming jargon in plain English

#106

Post by ebingdom »

jimbob45 wrote: post #84
rswail wrote: post #14

Earlier quoted context omitted.

Functional programming is actually mathematics based on lambda calculus. Imperative programming isn't. OOP is a failed metaphor, unless you use composition, not inheritance, even then, the actual basis for OOP was about the messages between objects, not the internals. > The world is made of state and processes No, the world is made of objects that have state and messages (events) between them.

The lambda calculus is an entirely arbitrary way to organize things in math. It’s not based on nature or truth at all. The real problem, though, is that FP doesn’t do anything well. It’s never the fastest method of programming, which means that it needs to excel in some other way for its proponents to be right about it. Is it the most maintainable? Maybe if you have zero side effects but then any paradigm would be in…

> The lambda calculus is an entirely arbitrary way to organize things in math. It’s not based on nature or truth at all.

Lambda calculus, category theory, and logic are essentially 3 sides of the same coin (the Curry-Howard-Lambek correspondence). The rules of lambda calculus match those of natural deduction. It runs quite a bit deeper than you're suggesting here. It's not just some arbitrary formalism.

Re: Functional programming jargon in plain English

#107

Post by [deleted] »

garethrowlands wrote: post #102
rswail wrote: post #14

Earlier quoted context omitted.

Functional programming is actually mathematics based on lambda calculus. Imperative programming isn't. OOP is a failed metaphor, unless you use composition, not inheritance, even then, the actual basis for OOP was about the messages between objects, not the internals. > The world is made of state and processes No, the world is made of objects that have state and messages (events) between them.

There are limits on what lambda calculus can model though. For example, it doesn't model IO very well. So, these days, lambda calculus is only one of the parts of maths that informs functional programming.

[deleted]

Re: Functional programming jargon in plain English

#108

Post by labrador »

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 should probably add that I program mostly C# so I'm getting Functional benefits like Map and Filter because Eric Meijer added LINQ. He made it his life's work for a few years to bring functional programming to the masses.

But I was minimizing state long before that because state makes any program much harder to understand.

Confessions of a Used Programming Language Salesman: Getting the Masses Hooked on Haskell http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72....

Re: Functional programming jargon in plain English

#110

Post by ebingdom »

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?
Post reply on HN