Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

271–280 of 513 posts

Re: Functional programming should be the future of software

#271

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…

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…

> 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.

First it greatly depends on what "new project" mean here. There myriad of new projects within existing code base for which the existing used technologies are the major factor.

When it’s about creating a brand new product out of a blank slake, sure Cobol won’t be your first idea for a startup. Maybe Ada might come to mind if some high level of reliability is required, like in aeronautics and the like.

It also depends on the team skills. If you have team mates which are all Haskell advanced practioners, surely imposing J2EE for the next big thing might not be brightest move in term of crew motivation.

Re: Functional programming should be the future of software

#272

Functional programming, as a paradigm, is way better than object-oriented programming, and also equally more complicated than object-oriented programming. My observation, over the past 30 years, is that 90+% of programmers aren't even capable of doing object-oriented programming - so getting them to do functional programming is a pipe dream.

> getting them to do functional programming is a pipe dream

I don't know if that was intentional but I'm upvoting!

Re: Functional programming should be the future of software

#273
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?

>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 as "obviously beneficial." ugh.

That is a lots that sucks about pure FP. It's not all upsides. The FP community can do a lot better at "evangelizing" by talking like engineers rather than sales people.

Re: Functional programming should be the future of software

#274

I'm reminded of the following quote by the co-author of SICP - Gerry Sussman... "Remember a real engineer doesn't want just a religion about how to solve a problem, like object-oriented or functional or imperative or logic programming. This piece of the problem wants to be a functional program, this piece of the program wants to be imperative, this piece wants to be object-oriented, and guess what, this piece wants t…

A refreshingly pragmatic position for an academic. Where did you get that quote?

Re: Functional programming should be the future of software

#275
post #252

Earlier quoted context omitted.

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

Nobody claims you have to understand category theory to write Haskell. In fact, most will tell you it's not needed. The saying "a monad is just a monoid..." is a cliché and an in-joke, not gatekeeping. It's the community having a laugh at itself.

But why is it funny? Isn't it funny because the community knows it comes off that way, at least some of the time (and/or some of the people)?

> Nobody claims you have to understand category theory to write Haskell.

I've seem the claim that you can't really use Haskell without it, here on HN, more than once. (Or at least something that I interpreted as being that claim...)

Re: Functional programming should be the future of software

#276
post #215

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…

I was once at a distributed systems meetup where a member of the audience interrupted the talk to give an extemporaneous presentation on why we should all be using Haskell. FP advocates have a reputation for being zealous and pretentious. The only question is whether they’re right to be.

If there is a way to do it that you feel more efficient/enjoyable than an other more widespread one, just show other people. If they don’t look interested, changing communication style next time might help. Become more proselyte will almost neither pay positively.

Re: Functional programming should be the future of software

#278

I like the philosophy of Rust (and some other languages) of "safe by default". Rust variables are immutable by default, but can be made mutable using "let mut". Rust is memory safe by default, but can be made unsafe using the drumroll "unsafe" keyword. As for null references, other languages still have them but enforce "strict null checking", such as Kotlin and TypeScript. They force you to verify a reference is not…

You're allowed mutability, even in languages like Haskell.

Re: Functional programming should be the future of software

#280
post #7

It would be helpful if the article started off defining what a functional language is. A lot of languages have functional features but are not “purely” functional. I think most would agree there’s a spectrum; dynamic vs static, eager vs lazy, mutable vs immutable. So what flavor of functional programming one might ask, since javascript is a dynamically typed flavor that is ubiquitous nowadays? The fine article sugges…

> A lot of languages have functional features but are not “purely” functional. That was my first thought. I work mostly in Java because that's what they pay me to do, but I've almost never worked with a Java programmer who could actually write Java code using the OO features that the language is based around. When I see their Scala code... it's mostly var, rarely val, because it's easy to think about.

> I've almost never worked with a Java programmer who could actually write Java code using the OO features that the language is based around

I don't understand this. The language is based around primitive, flawed, simplistic OO features, right? Like "class Dog : Animal"? I never write code like that either, because it's bad practice. But you're saying they can't write code like that? Or that they don't use classes at all? How can you even write any Java that way?

Post reply on HN