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

411–420 of 513 posts

Re: Functional programming should be the future of software

#411

Post by OkayPhysicist »

softwarebeware wrote: post #351
thosakwe wrote: post #344

Earlier quoted context omitted.

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.

"all that's necessary" implies there's something fundamental about imperative languages that's intrinsically more basic. In fact, the opposite is true. If you're problem statement is "in response to event X, transform Y into Z, stick it in a database, then take A from the database, reshape it into B, and send it back to the user" then weak functional approaches are the natural solution. (languages like Elixir or idiomatic JavaScript).

Re: Functional programming should be the future of software

#412

Post by cole-k »

tsimionescu wrote: post #388
the_af wrote: post #381

Earlier quoted context omitted.

Counterpoint: I learned about Applicative, Functor and Monad by reading docs and tutorials, and I haven't the faintest idea about category theory. These are the building blocks of Haskell. You learn them as you go, just as you learn what a "method" is when learning OOP. You don't need to know category theory.

Learning what Applicative, Functor and Monad are is category theory. It's like saying "you can learn how to do unions, intersections, and differences on collections of unique objects without understanding set theory".

That seems a little silly to me and I think we're splitting hairs with what it means to do category/set theory. I don't know category or set theory, so I hope you will forgive me for using yet another allegory.

Let's say I make a type class for Groups (in the abstract algebra sense). The rationale behind this is that there's an algorithm for exponentiation which is O(log(n)) versus the naive O(n) algorithm. So if you make an instance that's a Group, you get to use this fast exponentiation.

Sure, to understand and use this type class you have to understand what a Group is. However, I think it's a bit of a stretch to tell someone "in order to use Group you must first learn abstract algebra" because they'll think you're telling them to take a university level course. In actuality, they don't have to know much at all (they don't even need to understand _why_ the exponentiation algorithm works) - they just need to know what is a lawful Group.

The first day of the intro to abstract algebra course I took introduced much more information than you'd need to use this made up type class, and I expect the same of the others.

Like this is my understanding of Functors/Applicatives/Monads. I kind of know their shape and how to use them. If you asked me about any of the underlying math I would shrug and maybe draw a pig (https://bartoszmilewski.com/2014/10/28/category-theory-for-p...).

Re: Functional programming should be the future of software

#413

Post by OkayPhysicist »

aryehof wrote: post #257

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…

The problem is sometimes you lose a lot of functionality when you allow for that flexibility. For example, let's say you want your functional language to allow for side effects. Immediately you've lost locality: the explicit arguments of a function no longer guarantee their results. Or maybe you want to allow mutability: there goes thread safety. The fewer hard restraints a language can impose, the less lifting the language can do on your behalf. Give up on Lisp's S-expressions, and the macro system becomes vastly more complicated.

Likewise, a language has a limited amount of space for syntax before you end up a mess. So languages adopt a paradigm, and optimize the language for that paradigm. Functional-style Java is bloated to hell, because Java is built for Object Oriented programming.

Frankly, I'm of the opposite mind of the quote: the middle ground is often worse than either extreme. I'll happily write Object Oriented C#, or Functional Haskell, over a tepid mess of C++.

Re: Functional programming should be the future of software

#414

Post by m463 »

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…

I've always kind of wondered about something weird in relation to this type of programming style:

reversible computing.

Ever since I read some stuff feynman wrote years ago about computing it seems like quantum computing and/or max energy efficiency would be achieved if information was not destroyed.

And I thought functional programming might be a programming paradigm to support this kind of thing.

Re: Functional programming should be the future of software

#415

Post by knaekhoved »

_dain_ wrote: post #401
knaekhoved wrote: post #375

Earlier quoted context omitted.

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

Care to elaborate? You literally wrote 3 words

Re: Functional programming should be the future of software

#416

Post by the_af »

tsimionescu wrote: post #388
the_af wrote: post #381

Earlier quoted context omitted.

Counterpoint: I learned about Applicative, Functor and Monad by reading docs and tutorials, and I haven't the faintest idea about category theory. These are the building blocks of Haskell. You learn them as you go, just as you learn what a "method" is when learning OOP. You don't need to know category theory.

Learning what Applicative, Functor and Monad are is category theory. It's like saying "you can learn how to do unions, intersections, and differences on collections of unique objects without understanding set theory".

That's not really true. When some people claim you must learn category theory to use Haskell, they mean they have to learn the math-subject-capital-letter Category Theory, which goes way beyond programming and comes with a lot of baggage.

They never mean you have to learn Functor, Applicative, etc as used in Haskell and taught in every tutorial. If they did mean the latter, it would be a tautology, which is not very useful.

Compare "in order to do OOP you have to learn what an object truly is, its essence, and possibly take some courses on the philosophy of being" vs "you have to learn about methods and objects".

> It's like saying "you can learn how to do unions, intersections, and differences on collections of unique objects without understanding set theory".

You can totally do unions, intersections and differences without knowing set theory.

Re: Functional programming should be the future of software

#417

Post by bbarn »

yonaguska wrote: post #364
BlargMcLarg wrote: post #353

Earlier quoted context omitted.

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…

I'm trying to push unit testing, as a means to get rid of some of those negatives you pointed out. But it's not a panacea. And obviously, I don't want to test for the sake of it either.

I'll be honest, most of the unit tests and integration tests I write are mostly because it's more fun than cranking out "features"

Re: Functional programming should be the future of software

#418

Post by knaekhoved »

blep_ wrote: post #321
epgui wrote: post #299

Earlier quoted context omitted.

In life, there are a lot of obvious things that are very difficult to teach. For example, I'm a biochemist with 12 years of education, and I can't seem to be able to convince anyone that vaccines are safer than no vaccines. Humans just don't like new things or changing their mind, and that's a very generalizable fact, even among very smart groups of intelligent engineers.

The typical argument for vaccines is much less shaky than the typical argument for pure FP. For one, vaccine people can actually explain why vaccines are good. FP people seem to mostly just repeat variations on "it's easier to reason about" and showing trivial functions that are generally not easier to reason about. Imagine trying to get people to accept vaccines, but in a world where we have other types of medicine…

> The typical argument for vaccines is much less shaky than the typical argument for pure FP.

I suspect you aren't that knowledgeable about either.

> For one, vaccine people can actually explain why vaccines are good.

Unless you have a very particular background, I'm suspicious that you can actually follow the frontier of that argument. More likely, you're getting the ELI5 explanation.

> FP people seem to mostly just repeat variations on "it's easier to reason about" and showing trivial functions that are generally not easier to reason about.

Well-designed FP languages reify coherent low-complexity formal semantics. When FP advocates say "reason about", they mean in a (semi-)formal sense. No popular imperative language has any kind of denotational semantics, so good luck reasoning about the compositional behavior of C++ libraries, unless your definition of "reason about" is "think about informally".

Re: Functional programming should be the future of software

#419

Post by rowanG077 »

BlargMcLarg wrote: post #346
rowanG077 wrote: post #332

Earlier quoted context omitted.

Do you have actual, recent, examples of this? I keep reading the same attitude you have here, but I have never seen it first hand.

Git, Vim and general GUI come to mind, specifically on this site. There is always someone berating individuals for not using shortcuts, not using the console instead of a visual tool, using an IDE, etc. Specifically using Git with a GUI primarily is a great way to get flak from several subreddits, too. NB: This is not an invitation for discussion on the pros and cons, to berate either preference, or gatekeep.

I only see people saying it's superior. But that's not the same thing as berating.

Re: Functional programming should be the future of software

#420

Post by knaekhoved »

jjav wrote: post #410
knaekhoved wrote: post #234

Earlier quoted context omitted.

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

If you believe in the epistemic power of "studies" to convey useful information in these domains, I have bad news for you - you are the one in a religious fervor.

The only semi-objective metric you've proposed is compiled code performance, which is a fairly small component of most people's utility function, especially when the difference disappears in all but numerical-computation-centric applications.

Post reply on HN