Live data from Hacker News

Functional programming is finally going mainstream

github.com

131–140 of 171 posts

Re: Functional programming is finally going mainstream

#131
post #16

Earlier quoted context omitted.

The biggest problem I have with functional programming is debugging. On imperative code, execution is easy to follow. Instructions go one after the others, loops loop, function calls and local variables go on the stack, globals are always visible. Optimization aside, what you code is what the computer runs. You often have a debugger to step through your code, or some logging facilities, even if it is just a printf. O…

>I love pure functions, but in the end, I think it is just a tool. A solution to a set of problems, I'm tired of seeing this analogy everywhere. Everyone knows it, there's nothing new here. When we talk about things like FP or OOP, the real opinions live at the extremes. Where one tool is definitively better than another tool or where some tools are complete garbage. Saying that everything is a tool for different thi…

I call it a "thought terminating cliche" of software development: http://h2.jaguarpaw.co.uk/posts/thought-terminating-cliches-...

Re: Functional programming is finally going mainstream

#132
post #107
post #99

Earlier quoted context omitted.

If that were true, the past 30 years of progress in programming languages would be meaningless. But it is not: a more powerful language enables expressing what a weaker language does not. A language meant for use by professionals should get powerful features, without regard to any spurious notions of "purity".

Understanding what that equation means in practice is the difference between having a degree and a six month bootcamp as X Developer.

Do you really think you want to go there?

Re: Functional programming is finally going mainstream

#133
post #92
post #89

Earlier quoted context omitted.

"Subproblem" is likely an exaggeration here, otherwise I vehemently disagree. Take Erlang for example, it's theoretically a general purpose language but highly specialized. Would WhatsApp reach a billion users with 50 engineers without this specialization? I doubt it. It's absolutely fine for things to be heavily specialized, as it is fine for our entire civilization to rely division of labor. As the number of develo…

There are very successful insects.

No creature is limited to the use of a single programming language, but a lot of programs are. You can learn more than one language and choose one that is appropriate for the task, unlike an insect whose tools are limited so he must have only a few to do everything it needs to. Multi-paradigm is the insectisation here.

Re: Functional programming is finally going mainstream

#134
post #132
post #107

Earlier quoted context omitted.

Understanding what that equation means in practice is the difference between having a degree and a six month bootcamp as X Developer.

Do you really think you want to go there?

I have a thick skin.

Re: Functional programming is finally going mainstream

#135

My experiences with the encroachment of FP into otherwise imperative or OO languages has mostly been: 1. Write a bunch of functional code. 2. Marvel at how clean and neat things are. 3. Get customer reports of performance problems. 4. Spend a lot of time ripping out FP components and replacing them with imperative code.

> Spend a lot of time ripping out FP components and replacing them with imperative code.

Or use the functional code as a form of tests?

Re: Functional programming is finally going mainstream

#136

Learning generalized concepts of FP just make a lot of sense IMO. Knowing that you can map all functors the same way wether it's an Optional, List, Future or Either is a useful tool to have. Using it in a language with syntactic sugar to compose map and flatMap (>>= in Haskell) operations helps to write clean code a lot. For me, solving problems in a functional way is not always as intuitive as the imperative approac…

IME it is much easier to start with FP and later on introduce OOP rather than the other way around.

And yeah, sometimes stepping down into mutability and such is necessary for performance.

Re: Functional programming is finally going mainstream

#137
post #86

Earlier quoted context omitted.

The big mistake is in believing there is any value in this - or that -oriented programming, or in a this - or that -oriented language. An engineer uses what is available to produce an economically balanced solution. Done well, that may involve a few OO-ish bits, some functional bits, data-oriented bits, reactive bits, plus hybrid combinations of those and others. The problem dictates the form of the solution. Every b…

I completely disagree with the kitchen sink language approach. The benefits in many coding paradigms really kick in once they're used 100%. For example, consider GOTOs. If 99% of your functions don't use any GOTOs but they other 1% does, you can't be sure how the flow of logic lead to any one function. Immutability works in a similar way. I have a far easier time debugging in concurrent code I'm unfamiliar with if it…

> have a far easier time debugging in concurrent code I'm unfamiliar with if it's written in Elixir than if it's written in JS/TS, even if the project in question uses Immutable.js heavily.

How much of that comes from belief rather than reality, and potentially some room to grow on your end? I can debug well written code in any language I jump into, but I've found poorly written and hard to debug morasses can be written in any language.

Poor naming, branch/loop structuring, scoping, data modeling/normalization, module structuring, logging, and dependency selection/integration have all contributed to debugging hassles far more in my production experience than any particular language.

Re: Functional programming is finally going mainstream

#138
post #2

Functional programming with immutable state cannot possibly win in the general case. There are two truths that ensure the dominance of imperative software: 1. At some level of software complexity, programmers MUST start to organize data into composite objects. They have to do this because working outside of well-defined problem domains is a recipe for buggy software and spaghetti code. 2. Copying memory around to ena…

2. Copying memory around to enable to facilitate these immutable structures is SLOW. This is categorically wrong. You actually don't know what you're talking about. In an functional programming language, because everything is immutable, the compiler just MOVES everything around. There is ZERO copying in a functional programming language. In fact there's no explicit command for it either. There is zero reason for you…

> What you're referring to is more of what happens when someone is writing functional code in a language that's not functional.

And even then, there is the question of whethwr it is a deep or shallow copy on receiving or write.

Re: Functional programming is finally going mainstream

#139

Earlier quoted context omitted.

No but it popularized practical functional programming through react.

React functional components have nothing to do with functional programming. Hooks are stored in global variables.

Is Erlang functional programming? Anything in an Ets table is a global variable. There's even mutable state hiding in the process dictionary! You might have to access a database, which is global state! The horrors!

Re: Functional programming is finally going mainstream

#140

Earlier quoted context omitted.

They are usually not hidden, so they are at least easier to identify.

This is the crux of the matter. Every paradigm is argued about using small program examples, but the real-world issues come as the codebases become large (1M LOC or so). Then the cracks become worriesome. Imperative non-OO codebases become swamps of maybe (hopefully?) layered code, where each layer contains its own sinkholes and completely bizarre structure (or lack thereof). It's basically a bunch of mini-codebases…

Do you pick the lesser of 3 evils, or are there solutions to these cracks?
Post reply on HN