Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

Post reply on HN
Print view View original

351–360 of 513 posts

Re: Functional programming should be the future of software

#351

Post by softwarebeware »

thosakwe wrote: post #344
kstenerud wrote: post #57

I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all. The reason why multiple paradigms exist is because here in the real world, the competing issues and constraints are never equal, and never the same. A big part of engineering is navigating all of the offerings, examining their trade-offs, and figuring out which ones fit best to the system being built in terms of constra…

Another reason is that imperative languages have a lot of business inertia around them. It's expensive to rewrite existing code or switch to a new language, and most businesses can't justify this cost. I love functional programming, but I doubt most companies that sell CRUD apps care about it.

Another reason is that imperative languages are all that's necessary for many (maybe even the majority) of business use cases.

Really a lot of it boils down to if this else that, and little more.

Re: Functional programming should be the future of software

#352

Post by inimino »

kstenerud wrote: post #57

I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all. The reason why multiple paradigms exist is because here in the real world, the competing issues and constraints are never equal, and never the same. A big part of engineering is navigating all of the offerings, examining their trade-offs, and figuring out which ones fit best to the system being built in terms of constra…

It is similar to a religion, because if everyone agrees to adopt the same reality, then there's easy communication and a shared background understanding that makes it easy for everyone to work together. Picking a religion is a society-wide coordination problem, and strategies of shaming and in-group/out-group exclusion make sense in this context, where they wouldn't about flavors of ice cream, for example. We see the same thing happening in tech all the time. I don't want to learn a new technology, which means I don't want you to learn it, because I don't want it to become something that engineers are expected to know. And so on.

The point is to understand that "right tool for the job" and "C++ for everything" are religious positions, too. There might even be a dominant religious position, which likes to style itself as just the disinterested rational viewpoint.

The FP folks might be a somewhat more fervent (crazy mathematical) sect, but there's no getting away from religion, though we can call it by other names (fashion, "best practices", ...).

Re: Functional programming should be the future of software

#353

Post by BlargMcLarg »

bbarn wrote: post #310
yonaguska wrote: post #165

Earlier quoted context omitted.

As someone that's left scala and come back to dotnet land... depending on the domain, functional programming results in much cleaner solutions. A lot of the code messes in functional paradigms that I dealt with and also created were mostly due to people that didn't understand how to think functionally. It took a long time for me to figure it out. I find myself missing features all the time now, and spending a whole l…

.net, and C# especially are absolutely fantastic tools for programming. The problem is just that they are embraced by large companies and that is where crappy engineers tend to congregate, in my experience. The bigger the company the easier it is to get lost in the crowd. I enjoy functional programming, but I'm a wizard with C# and .net, and I can pull a much higher salary continuing to focus there. I can write my ow…

It's also laziness and controversy. Unit testing is something aggressively pushed in many of these places, but then they continue to litter side effects, long flows, loads of complex objects, void methods, and more which inherently make it more difficult to test. FP guidelines help a lot of these cases, and you don't need to understand monoids, monads or any of that to grasp the concept of simple functions with clear output.

Meanwhile, FP is kind of a pain to connect things in, for most people.

Re: Functional programming should be the future of software

#354

Post by yodsanklai »

zamalek wrote: post #24

Functional programming won't succeed until the tooling problem is fixed. 'Tsoding' said it best: "developers are great at making tooling, but suck at making programming languages. Mathematicians are great at making programming languages, but suck at making tooling." This is why Rust is such a success story in my opinion: it is heavily influenced by FP, but developers are responsible for the tooling. Anecdotally, the…

> I seriously couldn't figure out the idiomatic Ocaml workflow/developer inner loop after more than a day of struggling.

I tend to agree but, compiling C++ isn't just about typing "make". And it did take me more than one day to figure out python/js workflow.

Re: Functional programming should be the future of software

#355

Post by ajuc »

beders wrote: post #255
ajuc wrote: post #19

Earlier quoted context omitted.

My problem with functional programming is refactoring. If you don't have side effects when you want to do 2 things deep into the call tree to something that is in completely different call tree branch - you have to extract it all the way up to the common parent and pass it through all the intermediates just so that one function deep there can access it. It's incredibly frustrating when you work in a functional langua…

I like that aspect because it gives you a hint that your call tree is not how it should be. Lifting out side-effects and passing the data back in is one approach, but not the only one. Turning a deep call tree into a flat pipeline is a popular other approach and often leads to less complexity, better compos-ability.

I like it when I'm done. I very much dislike it when I'm not sure yet what my code should do so it changes constantly. And that's most of the time in gamedev for example.

Re: Functional programming should be the future of software

#356

Post by siknad »

adamwk wrote: post #307

This article reads like something from 2010. Other than Go, new languages no longer have null references and you don’t need a purely functional language to do so. I kept waiting for more examples for why we need FP but the article yada-yada-yada’d the rest I think FP came and showed everyone how to design expressive types, how to define flatMap on more than arrays, and that’s it. It turns out you don’t need Haskell,…

> I kept waiting for more examples for why we need FP

Dependent types, allow a lot more type safety (ex. shader program type parametrized by description of its uniform variables, getting rid of `INVALID_OPERATION` on wrong uniform location/type).

> you can incorporate those features in imperative languages like Rust and Swift

Incorporating dependent types into imperative languages with unrestricted effects is hard (impossible?).

Re: Functional programming should be the future of software

#357

Post by tsimionescu »

hresvelgr wrote: post #163
kstenerud wrote: post #57

I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all. The reason why multiple paradigms exist is because here in the real world, the competing issues and constraints are never equal, and never the same. A big part of engineering is navigating all of the offerings, examining their trade-offs, and figuring out which ones fit best to the system being built in terms of constra…

> One of the big reasons why FP languages have so little penetration is because the advocacy usually feels like someone trying to talk you into a religion. This is a part of it. The other part is FP's a bit of a mind fuck if you're used to procedural programming. Take a classic example: Haskell. To do anything remotely productive it's advisable to understand how monads and the various monad design patterns fit togeth…

> The other part is FP's a bit of a mind fuck if you're used to procedural programming

It's not "if you're used to procedural programming" - FP is simply hard for people to reason about. You can often very intuitively reason about imperative programs, while FP always requires putting your abstract thinker cap on. Look at any non-software person describing describing how to do something and see how often that sounds like an imperative program vs an FP one. Hell, most algorithms papers are themselves using imperative pseudo-code, not FP pseudo-code (unless they're specifically describing novel algorithms important for FP of course).

> I am convinced the more we try to make mutable state, and concurrency safe and correct, the more FP concepts will leech into future languages.

Concurrent mutation is fundamentally hard regardless of what paradigm you chose to implement it in. Parallelism can be made safer by FP, but parallelism is actually pretty easy in every paradigm, with even a little bit of care. And concurrent updates of mutable state are just a fundamental requirement of many computer programs - you can try to wrap them in monads to make them more explicit, but you can't eliminate them from the business requirements. The real world is fundamentally stateful*, and much of our software has to interact with that statefullness.

* well, at least it appear so classically - apparently QM is essentially stateless outside its interactions with classical objects (the Born rule), but that's a different discussion.

Re: Functional programming should be the future of software

#358

Post by AnimalMuppet »

hither_shores wrote: post #333
AnimalMuppet wrote: post #322

Earlier quoted context omitted.

So, ELI5: What do you do instead, where you return a modified object, but still have immutability? Or do you avoid the problem by not trying to do that?

In most situations, you use persistent data structures where you only have to copy the modified leaves. If you really need your type to be backed by a contiguous block of memory, you batch updates (stencils, SIMD, etc.)

But if you modify the leaf, don't you also have to modify the branch node that points to the leaf, so that it points to the new one? And every node from there to the root?

Re: Functional programming should be the future of software

#359

Post by darksaints »

kstenerud wrote: post #57

I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all. The reason why multiple paradigms exist is because here in the real world, the competing issues and constraints are never equal, and never the same. A big part of engineering is navigating all of the offerings, examining their trade-offs, and figuring out which ones fit best to the system being built in terms of constra…

Thank you. I learned functional programming first, and I do think there is a lot of merit to it in a large proportion of software development tasks. But there are far too many people trying to fit square pegs in round holes with it. Pure functional applications which manage large amounts of complex and messy state are a nightmare to work with. There is a reason why game developers and simulation developers have almost defaulted to object oriented programming. There is a reason why cryptography developers have defaulted to procedural programming. There really should be a No Free Lunch theorem for programming methodologies.

Re: Functional programming should be the future of software

#360

Post by BlargMcLarg »

tsimionescu wrote: post #357
hresvelgr wrote: post #163

Earlier quoted context omitted.

> One of the big reasons why FP languages have so little penetration is because the advocacy usually feels like someone trying to talk you into a religion. This is a part of it. The other part is FP's a bit of a mind fuck if you're used to procedural programming. Take a classic example: Haskell. To do anything remotely productive it's advisable to understand how monads and the various monad design patterns fit togeth…

> The other part is FP's a bit of a mind fuck if you're used to procedural programming It's not "if you're used to procedural programming" - FP is simply hard for people to reason about. You can often very intuitively reason about imperative programs, while FP always requires putting your abstract thinker cap on. Look at any non-software person describing describing how to do something and see how often that sounds l…

Eh, it really depends. Some people find trees easier to navigate through recursion than iteration, same for lists and graphs. Some do better using decomposition on a list to get a combined value or create permutations than doing it through iteration and indexing. FP commonly becomes problematic when things are far more trivial to do stateful than stateless, with side-effects than without, and more.

FP usually shines in small sections of easily isolated code, where it is still trivial to grasp for most and its strengths show more than its weaknesses. Given that code isn't more easily expressed using iteration, anyway. The moment things have to be woven together and not leave any side-effects is when the difficulty jumps to 11.

Post reply on HN