Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

301–310 of 513 posts

Re: Functional programming should be the future of software

#301
post #252

Earlier quoted context omitted.

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.

I've had someone do that on this very website. I was assured that affine types in Rust are too difficult to understand without a solid grounding in Category Theory. The years have proven that ease of programming and the burden of knowledge are the two most important elements of a programming language. FP zealots simply won't accept that their chosen paradigm is opaque to most for benefits that can't seem to be writte…

> I've had someone do that on this very website

On this website you will hear anyone say the wildest assertions. There's the whole human range of expression here. But what makes you think actual FP practitioners (and Haskelers) really believe this?

The proof wouldn't be what some random person here on HN tells you. The proof would be you getting involved in an actual FP community trying to write an actual FP project and being told that you just cannot do this unless you understand category theory. Which, as I said, is not something that happens... at least not in my (limited) experience.

Never confuse what people tell you here on HN, random forums or even throwaway StackOverflow comments with what actually happens in the actual communities when trying to achieve real goals and not just chat about stuff.

Re: Functional programming should be the future of software

#302

Earlier quoted context omitted.

> I don't deal much with C/C++ that is because there is no such thing.

C/C++ is just 1 in the limit, right?

two things wrong with your statement:

- the ++ operator only acts on integer types, not floats or doubles, so there is no limit to speak of here

- the expression "C++" has value equal to C before incrementing, hence the expression "C/C++" is just one for positive C, even when C is small

Re: Functional programming should be the future of software

#303
post #274

Earlier quoted context omitted.

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

> A refreshingly pragmatic position for an academic. There are plenty of pragmatic academics. It just happens that academia is about the only place that the non-pragmatic people can find long-term career success, but that doesn't mean there aren't many pragmatic people in the same space.

> There are plenty of pragmatic academics

Sure, just as there are dogmatists in the industry, as the article shows.

Re: Functional programming should be the future of software

#304
post #195

Earlier quoted context omitted.

Isn’t this IO thing a bit overused? There are more FP languages that are not as pure as Haskell, but even if we only do IO through a special monad it is not too bad at all. And I say that as someone who is very much fore “practical FP” — I do think that local mutability is sometimes simply the better fit for a problem.

> there are more FP languages that are not as pure as Haskell I mean, that's precisely the point I'm making, that IO doesn't fit into the FP paradigm and that languages that make IO easier necessarily deviate from it. And once you bring non-FP concepts into an FP language, most people will reasonably question why do that instead of the easier way, which is bringing FP concepts into imperative languages.

Arguably the best platform for the general io use case is functional.

From how when you console in to a cluster and run a command on another node, the standard io is redirected to you, to how tcp/up and up sockets are managed by the stdlib, it's really hard to beat Erlang.

Re: Functional programming should be the future of software

#305
post #113

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…

> but without the verbosity of an Optional or Maybe type Without the safety of having that encoded in the type system.

`T` and `T?` being different types is encoding in the type system.

It is a different encoding, though.

Re: Functional programming should be the future of software

#306
post #289
post #274

Earlier quoted context omitted.

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

From a quick google, likely from a talk on Youtube. Matching section timestamped - https://youtu.be/O3tVctB_VSU?t=2346

Thanks. Very impressive to hear this from the Scheme pope himself. This should make all dogmatists think.

Re: Functional programming should be the future of software

#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, you can incorporate those features in imperative languages like Rust and Swift.

Re: Functional programming should be the future of software

#308
post #280

Earlier quoted context omitted.

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

> they don't use classes at all

As much as they can avoid it, yes. The only classes I ever see are those that are auto-generated from some JSON or ORM processing tool - everything else is a static function.

Re: Functional programming should be the future of software

#309

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.

That's exactly what worked for OOP—have we collectively forgotten just how hard OOP was pushed everywhere 15–20 years ago? Way more aggressive than any FP advocacy I've seen, and I've seen a lot. When I was learning to program every single book and tutorial pushed OOP as the right way to program; procedural programming was outmoded and functional programming was either not mentioned or confused with procedural programming.

I still have to deal with the fallout from OOP evangalism; I've had colleagues who unironically use "object-oriented" as a synonym for "good programming" and managers who believe design patterns are software engineering.

Re: Functional programming should be the future of software

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

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 own fun stuff in Haskell for myself and will continue to enjoy corporate money.

Post reply on HN