Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

401–410 of 513 posts

Re: Functional programming should be the future of software

#401

Earlier quoted context omitted.

>figured out that something is obviously beneficial? Case in point for the problem with FP communication. When you speak in smug absolutes, it comes off as religion. I'm pretty big into the FP world. I love Purescript. I dig Idris and exploring dependent types. I spend a lot of time at work teaching "functional" thinking. And yet, I still find most "hard core" FP evangelists insufferable for smugly explaining things…

Where did I say that FP was obviously beneficial? You're reading too much into my question. I was questioning the GP's epistemology. > talking like engineers rather than sales people. They do talk like this - go to any Haskell conference and it's 90% engineering papers - much better than e.g. a JS conference. It's just that most people don't even know what PL engineering even looks like , let alone how to interpret i…

> Where did I say that FP was obviously beneficial? You're reading too much into my question. I was questioning the GP's epistemology.

cmon fuckin guy

Re: Functional programming should be the future of software

#402

Earlier quoted context omitted.

>> navigating all of the offerings, examining their trade-offs the amount of time you're afforded for that exercise better fit neatly inside a very small window of implementation (in other words you're probably not going to do it, or at least do it justice) >> figuring out which ones fit best to the system being built in terms of constraints constraints will always get ya. It always ends up to being what is the tool/…

I am sorry, but you sound like you know for a fact that functional programming is better, but you have trouble making others recognize that fact. Imho, FP has many tangible weaknesses, just a few off the top of my head: - Immutability is non-intuitive: If I were to ask someone to make an algorithm that lists all the occurrences of a word on a page, they wouldn't intuitively come up with an algorithm that takes a slic…

FP isn’t just limited to Haskell while your criticisms seem aimed only at that one language.

Immutability may not be intuitive, but neither are pointers, hash tables, structured loops, OOP, etc. In any case, maintaining immutable code is certainly more humane than trying to reason about 10th order side effects. Finally, the majority of functional languages are immutable by default with optional mutation when needed.

Your immutable argument is a red herring. It’s the wrong algorithm. Bubble sort is much more intuitive than heap or quick sort, but you certainly wouldn’t recommend it.

You are flatly wrong about performance. Ocaml and StandardML are just as fast as languages like Go or Java. This is incredible when you realize These FP languages are maintained by a handful of people with basically no budget and are keeping pace with languages that have tens out hundreds of millions of dollars pushed into them.

FP doesn’t mean no side effects (though it does tend to encourage limiting and separating them). Outside of Haskell and Miranda, basically all the other FP languages have side effects and even Haskell has an escape hatch available.

Re: Functional programming should be the future of software

#403

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…

Totally agree. As a Javascript dev I got functional code pushed on me in 2016. It's definitely good practice for devs to learn some of the pitfalls that FP prevents and solves, but implementing it on a massive scale front-end application just seems impractical. Having worked on a large streaming service and considering the author's 3 MONTH struggle after his 40 YEARS experience, I'd estimate that a re-write of our co…

> As a Javascript dev I got functional code pushed on me in 2016.

What do you mean?

Re: Functional programming should be the future of software

#404
post #3

Imo functional programming is one of those things that makes sense from a theoretical perspective, but comes with compromises when it comes to reality. The thing about functional programming is that the confidence you get from immutability comes at the cost of increased memory usage thanks to data duplication. It's probably going to create a ceiling in terms of the absolute performance which can be reached. There are…

The other problem with functional programming is it's harder to look at code and figure out the time complexity. At least with non-functional languages I can easily figure out why there are performance problems with it. Stuff like lazy evaluation may seem cool, but it's not when you have to figure out why something's slow.

This is lazy vs strict, not functional vs whatever. I'm a fan of functional programming, not so much a fan of lazy evaluation. Look at PureScript or Idris perhaps?

Re: Functional programming should be the future of software

#405

Earlier quoted context omitted.

This is just an appeal to the law of averages. I don't believe that you're actually considering ada, cobol and forth for new projects. > 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 never really a reason for anything, it's a personal attack on people who advocate the thing that you don't want to do. FP…

To be charitable to kstenerud, FP advocacy does often sound like proselytizing. When promoting FP to folks, I think we can mitigate that issue by communicating a couple points: 1. There's no dichotomy between FP and OOP. Sprinkle it into places where it makes sense to you. Adoption can come by degrees. 2. Just thinking in composable, pure functions on projects buys you serious mileage. You don't have to wrangle monad…

> Just thinking in composable, pure functions on projects buys you serious mileage

This is exactly where I was a called a zealot and gave up because it was obvious the other person felt attacked, as if I told them "you are an idiot for using procedural and imperative style all your career" -- which I absolutely didn't say or even imply.

Ultimately, selling someone on FP is selling them a new mental model and I think a lot of us how hard that is. People by default don't want to change the way think, it's a fact of life.

Re: Functional programming should be the future of software

#406
post #267
post #150

Earlier quoted context omitted.

> FP people are not bullying you, or shoving anything down your throat. Have you ever worked with a FP evangelist? Every single experience I've had has been with a person who simply won't take "no" for an answer. The impatience, ego, and pettiness is bar none, really. Aside from that, there are objective reasons to be skeptical: it's inefficient when it comes down to actual implementations that have to work on actual…

I have spent the time with Haskell to learn how to not just use it a bit, but program it idiomatically and with some fluidity. I think there is a very interesting point you can reach if you go 100% all the way in. There are some types of programs that you can write, like compilers, that are kinda painful and dangerous and quirky in imperative or OO programming and are just beautiful in full on, no compromises functio…

Where are all the FP software products I can use? It doesn't seem to dominate a lot of software niches, no?

Re: Functional programming should be the future of software

#407

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. Eh, I doubt it. I've encountered a few Haskell snobs in my time, but most people that I know who use FP do so completely silently and will discuss the merits and (and challenges) with you freely. I think the real issues with FP are lack of good tooling, package ma…

"A monad is just a monoid in the category of endofunctors". Anyone who says that - or anything anywhere close to it - is gatekeeping, no matter how true the statement is. And it's not just the statement. It seems to me (from my outside perspective) that category theory is often used in a gatekeeping way. In contrast, take SQL. How much of the mathematical theory of relations do you need to know to be able to write SQ…

> "A monad is just a monoid in the category of endofunctors". Anyone who says that - or anything anywhere close to it - is gatekeeping, no matter how true the statement is.

Quite frankly, if you don't understand that sentence then you are in no position to judge whether the concepts could be made more accessible. Sometimes the important question is not "could this be easier to learn?" but "is learning it worth the effort?".

Re: Functional programming should be the future of software

#408
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…

> Functional programming won't succeed until the tooling problem is fixed.

I think different people have different wants and needs with tooling. I make (and use) binaries with Haskell. I wish more mainstream languages could make binaries.

Re: Functional programming should be the future of software

#409

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…

This rings true - experiencing different paradigms opens you up to more elegant solutions. That's why years later I now see the value of the "Programming languages" course I had in university - every lecture covered a new language and had homework to implement a program in it. I haven't touched LISP or Prolog since, but just being exposed to them made me write better code in "traditional" languages.

Agreed. I took a year (long ago) to learn lisp just to be exposed to a different way. And it has paid dividends in terms of providing alternate ways of thinking about code in other languages.

That said, I'd never want to use lisp in a real production project. Same for FP. Get exposed to these things, take the learnings and bring them into KISS boring production code that is fast and maintainable.

Re: Functional programming should be the future of software

#410
post #150

Earlier quoted context omitted.

> FP people are not bullying you, or shoving anything down your throat. Have you ever worked with a FP evangelist? Every single experience I've had has been with a person who simply won't take "no" for an answer. The impatience, ego, and pettiness is bar none, really. Aside from that, there are objective reasons to be skeptical: it's inefficient when it comes down to actual implementations that have to work on actual…

How do you distinguish between people who are in a religious fervor and people who have figured out that something is obviously beneficial?

> How do you distinguish between people who are in a religious fervor and people who have figured out that something is obviously beneficial?

Seems easy to me.

If it's obviously benefitial, show me:

- Performance benchmarks showing how much faster the compiled code runs

- Case studies demonstrating faster development and/or fewer time spent debugging

- Studies showing consistently better maintainability

If it is lacking this data, it comes across as religious fervor.

Post reply on HN