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

291–300 of 513 posts

Re: Functional programming should be the future of software

#291

Post by DonaldPShimoda »

zelphirkalt wrote: post #87
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…

You gave up using a programming language after a day? And Haskell after installing/building some dependencies for 20mins? Tbh, this sounds like you were not really trying. What kind of experience with a programming language do you expect to have after a mere day? Learning takes time. Anyone might spew some not idiomatic code within a day, but really becoming proficient usually takes longer. Do you have any references…

> Do you have any references for the "Rust is heavily influenced by FP" thing? To me it does not feel that much FP.

The original implementation of Rust was in an ML dialect (I think OCaml?), so from that we know immediately that the original authors were familiar with FP and used it for their own purposes. It seems odd, then, to assume that there would be no influence of their own language.

But if we look at the actual feature set, we find a lot of things that previously belonged almost entirely to the realm of FP. The type system as a whole has a fairly FP feel, plus algebraic data types, exhaustive structural pattern matching, maps and folds, anonymous functions, the use of the unit value for side-effecting work, the functioning of the semicolon operator (which is identical to the OCaml usage)... there's quite a lot, and those were just the examples off the top of my head!

Re: Functional programming should be the future of software

#292

Post by alanwreath »

AnimalMuppet wrote: post #256
alanwreath wrote: post #180

Earlier quoted context omitted.

For the most part, agreed. But the arguments for FP are old and like you’re mentioning could be sold easily by the right orator (those teachers/evangelists exist btw in droves on YouTube and elsewhere). I’m only saying that given what academia and collective professional experience has proven around FP, it would be nice if FP or FP patterns were the first option(s) most stressed to budding SWEngineers/Developers and…

But why should FP be the basis for understanding? Let's say I run a CS department. And let's say that I've accepted that what my department is really doing is jobs training for software engineers. Well, what are their jobs going to be, imperative or functional? For most of them, for most of their careers, the jobs are going to be imperative. Why should we start with FP? You could say "FP is better", but then we're ba…

It’s about rope. Imperative languages generally give you a lot of flexibility (for x or y) and, therefore, rope to hang yourself. I don’t believe that starting students here, from a pedagogical perspective, is a good strategy. FP languages/paradigms, on the other hand, are all about restrictions(immutability, side effects, etc), and thus less rope. Less places to hang yourself, so to speak.

Also, even though, as you’ve stated sw engineers tend to work in an imperative environment (which I’m arguing is an artifact of their formative years), junior sw engineers should at least start with a bit of trepidation to use that rope (if only in their heads).

Plus, utilizing a functional style (and understanding the whys of functional style, where pragmatic) would improve many aspects of industry (e.g reducing the friction of adding tests - did I mention that I love tests??)

Re: Functional programming should be the future of software

#293

Post by valenterry »

gjulianm wrote: post #127
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. (The other major impediment is gatekeeping) I think one of the major reasons is because IO doesn't really fit well into the FP paradigm. All the theory and niceties take a second place when you find out that something as simple as "print a line here to console" is…

I think the context here is pure functional programming. So not just replacing e.g. loops with mapping and such things, but actually making effect-handling explicit. The IO type (or otherwise deferred-type) is essentially for that. Saying it doesn't fit into the FP paradigm doesn't make sense. Without IO, FP is useless because you simply cannot "do" anything at all.

Re: Functional programming should be the future of software

#294

Post by DonaldPShimoda »

Rochus wrote: post #274
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…

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.

Re: Functional programming should be the future of software

#295

Post by skierguy »

a_wild_dandan wrote: post #258
pessimizer wrote: post #117

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…

I think a lot of the "religious" feeling I get from FP advocates is the constant focus on purity and the "No, you AREN'T DOING IT RIGHT!!!" kinds of tantrums. You HAVE to understand the nuance. You HAVE to participate in these strange little paradigms that esoteric thinkers have come up with. Ultimately, I think of FP languages like Haskell as playgrounds to pilot bleeding-edge ideas before the best ideas get incorporated into languages that are widely used in production.

Ultimately, some real-world processes are just procedural, and procedural languages are easier to apply to them. When it comes to callbacks, mapping functions to a list, etc., it's pretty clear to me that FP paradigms are superior.

In other words, I think it's part fad/religion, but as with anything, you can learn from it and take the good parts.

Re: Functional programming should be the future of software

#296

Post by bcrosby95 »

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…

Using Haskell as the classical example of FP is a bit like using Rust as the classical example of imperative programming.

You can do it but they're much harder than most other languages in the class and not anywhere near representative of the whole class.

My FP journey was: Scheme (different but okay) -> Haskell (wtf) -> Erlang -> Clojure -> Elixir. Nowadays when I reach for an FP it's Clojure or Elixir, mostly based upon the problem at hand.

Re: Functional programming should be the future of software

#297

Post by DeathArrow »

GaryPalmer wrote: post #214
DeathArrow wrote: post #167

Functional or procedural or whatever, it doesn't matter much for me as long as the paradigm is not OOP. I strongly believe that data should live separate from the actions performed on it. I also believe that inheritance is a bad thing as there are other, better means to achieve polymorphism. I do believe in a data oriented programming where we waste as little CPU cycles as possible and introduce as little abstraction…

I am working on a java game where I threw all OOP knowledge out the window and use C-style pure data-classes with public fields and no methods. It's pretty refreshing to work this way compared to the design pattern madness you see in enterprise applications - but I guess it's not very safe if multiple people are working on this and some don't know what they are doing. There has to be some middle ground, I think peopl…

Me too, I use .NET but try to use in the least OOP way as possible. Of course, for interviews I can recite all things about OOP, countless patterns and their "advantages", SOLID, DDD done OOP way and most of the Uncle Bob "wise" teachings.

Re: Functional programming should be the future of software

#298

Post by the_af »

AnimalMuppet wrote: post #275
the_af wrote: 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.

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

It's funny because the community knows some people too deep in the rabbit hole come across that way, but because the community acknowledges this is a hilarious assertion that would alienate newcomers -- if said with a straight face -- then it cannot be gatekeeping.

Gatekeeping would be if the community said this with a straight face and everyone got impatient when you just "don't get it".

> I've seem the claim that you can't really use Haskell without [knowing category theory], here on HN, more than once

I've almost never come across this assertion; it's certainly not common in the community (or wasn't when I was learning Haskell). I can tell you it's certainly false: you can very well write Haskell without knowing or studying category theory.

Re: Functional programming should be the future of software

#299

Post by epgui »

fsdjkflsjfsoij wrote: post #241
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?

> people who have figured out that something is obviously beneficial? If it's so beneficial then those people can prove it by building something exceptional. I worked with Haskell and Scala for almost a decade and libraries were full of bugs and performance problems. A lot of bugs just hadn't been reported because so few people were using them. FP certainly has its strengths but so far there's very little evidence th…

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.

Re: Functional programming should be the future of software

#300

Post by aranchelk »

gjulianm wrote: post #245
kaba0 wrote: 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.

Pure functional languages model IO with monads, which are very much functional (function composition within a context) and IMO easy to use. This ease of use is probably why JS adopted the pattern with native promises -- async/await. They fit well into otherwise imperative code and people seem to to like them.
Post reply on HN