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

451–460 of 513 posts

Re: Functional programming should be the future of software

#451

Post by fulafel »

dllthomas wrote: post #446
nequo wrote: post #377

Earlier quoted context omitted.

I think Rust is not particularly FP because it encourages using loops instead of recursion and “let mut” is quite idiomatic in my understanding. Those two characteristics are more relevant than the type system. For example, Scheme and Clojure don’t have type classes but are clearly FP because recursion and immutability are idiomatic. In Rust, even though it is true that .map, .fold, .filter, and .zip exist, first of…

The claim was that Rust is "heavily influenced by FP"; I think that's clearly the case, while "Rust is FP" is probably not (which case you make pretty well).

FPLs yes, FP no.

We might argue it's influenced by FP indirectly because those adopted features from ML etc also jive well with functional programming, for example pattern matching as a control flow construct...

Re: Functional programming should be the future of software

#452

Post by jve »

dmitriid wrote: post #379
jve wrote: post #86

Earlier quoted context omitted.

> There is nothing magical about functional programming How come not? I read that F# gives you compiler exception when you didn't match all possible values. Or when you didn't handle __maybe__ cases. JS even doesn't mind comparing strings with ints and incorrectly summing them together and not throwing a runtime exception less alone a compiler complaint. "1" == 1 true "1" + 1 '11'

These are peculiarities of type systems, not of functional or non-functional programming.

Well, we are talking about functional programming improving program correctness. Such behavior doesn't help. Better choose another language that is a fit for it.

Re: Functional programming should be the future of software

#453

Post by spion »

dottedmag wrote: post #396
spion wrote: post #67

Earlier quoted context omitted.

I wish that were true. Unfortunately, functional composition breaks down when functions have multiple return values, as is the case for everything that returns an `err, res` pair. So even with generics added, Go is still hostile to functional programming. If Go gets a Result generic type similar to the one in Rust to replace (err, res) that would work. That seems highly unlikely, however. The node.js community went t…

(res, err) is Either monad, isn't it?

Its not a single value, so its not anything.

Re: Functional programming should be the future of software

#454

Post by justcoder »

monkpit wrote: post #391
jerf wrote: post #267

Earlier quoted context omitted.

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…

If you were to write a post about taking an example imperative program and showing the conversion to FP, I’d be very interested to read it. Or if you have a link handy to someone else’s post? For me it’s difficult to immediately understand what you mean about the top level program, mapM, etc. I guess what you mean is that they entire program can be expressed as 1 call with some args? I feel like there is probably mor…

In the second part of the "Solving Problems the Clojure Way"[0] talk, the speaker shows step-by-step transformation of the heavy imperative (book-keepish) JavaScript code to a more functional approach.

As a result of transformation, ~95% of the code is easily unit-testable and the only impure code is the call to main which basically starts all the domino falling.

[0] https://www.youtube.com/watch?v=vK1DazRK_a0

Re: Functional programming should be the future of software

#455

Post by DeathArrow »

>Functional programming has a steep learning curve Not really. Learning and using F# is not hard. Same for using JS in a functional manner.

>To reap the full benefits of pure functional programming languages, you can’t compromise. You need to use languages that were designed with these principles from the start. Yes and no. F# was designed with functional principles, but you can compromise and you don't have to write 100% functional code.

Re: Functional programming should be the future of software

#456

Post by raffraffraff »

throwaway1492 wrote: post #41
dmitriid wrote: post #13

Earlier quoted context omitted.

To quote "Stop Writing Dead Programs" [1]: "If what you care about is systems that are highly fault tolerant, you should be using something like Erlang over something like Haskell because the facilities Erlang provides are more likely to give you working programs." [1] https://www.youtube.com/watch?v=8Ab3ArE8W3s

That quote is absurd because the vast majority of applications on the planet are not written in Erlang and work just fine. Working and fault tolerance are in no way related. Being generous the majority of applications with very high uptime are also not written in Erlang.

This. I came across this quote:

> If somebody came to me and wanted to pay me a lot of money to build a large scale message handling system that really had to be up all the time, could never afford to go down for years at a time, I would unhesitatingly choose Erlang to build it in

RabbitMQ might be the most famous example of a product written in Erlang. It's great, but I've seen it fall over. In my experience cluster failures typically caused by a handful of root causes like hardware error, resource exhaustion, network partitioning or operator error. Whether a system is built in Erlang or Go, I'd imagine that these same root causes would exist.

I'd love to read in-depth why RabbitMQ's Erlang underpinnings make it better than, say, ActiveMQ or Kafka. Assuming a 3 perfectly built clusters that aren't mishandled, will RabbitMQ somehow "win" over the other two because of some particular greatness in the Erlang?

Re: Functional programming should be the future of software

#457

Post by kstenerud »

epgui wrote: post #439
sidlls wrote: post #437

Earlier quoted context omitted.

> 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. People who actually understand complex things are able to provide ELI5 level explanations for people who haven't the background for more rigor. You're presenting a false representation of the OP's comment anyway: it never suggested the explanation…

> are able to provide ELI5 level explanations Yes, in theory, and this sometimes works. But it rarely works in general . In practice, people come to your explanation pre-conditioned with a lot of (often politicized) misinformation, Dunning-Kruger type overconfidence in their own ability, very little curiosity or openness to new ideas, and exhibit the attention span of a 26th percentile squirrel. People tend to listen…

It simply can't be done. It's always possible in theory but never in practice. Or at least certainly not in this special snowflake case.

Until someone bucks the trend and does it.

But for that you need someone with actual intelligence and empathy; a Feynman of that sphere so to speak.

In every gatekeeper community this is the order of things until someone finally destroys the gates to the knowledge and the monopoly of the priesthood. Until then, it's basically "blame the victim" for their own lack of understanding (e.g. "people listen very little", "people are more skeptical of others", "they try to poke holes in your explanations", "They'll repeat whatever objections they've seen or heard somewhere", etc).

Re: Functional programming should be the future of software

#458

Post by KolenCh »

dec0dedab0de wrote: post #139

I don't know any purely functional languages[], so my viewpoint is skewed here. Whenever I have seen a python developer drink the functional kool-aid they end up either storing state in global variables, environment variables or in a dictionary they end up passing to every function. I then have to explain to them that passing a dictionary around and expecting variables to be in it is just half-assed OOP. My rule of t…

I'm mathematically trained so in the beginning I really like writing python program in pure functional paradigm. Until I was facing this issue.

But, adopting OOP doesn't mean one have to give up on pure functional paradigm, there's a book which basically is talking about how you can incorporate more functional paradigm into OOP.

One way to look at it is (perhaps trivially) that methods are just functions, and class is just something with properties. So in a sense class defines a type, where the methods/functions expects this type.

In python I find properties (and the related cached properties), dataclass etc can really make the above more apparent in construction. To just give one example, having a property that returns a pure function would acts practically the same as methods (but not in docs unfortunately, and related auto completion kind of stuffs.)

Yet another way of looking at this is to treat Python class as singular dispatch in first argument only.

I find thinking this way enables me to reap the benefits of both OOP and pure functional paradigm.

Re: Functional programming should be the future of software

#459

Post by spion »

spion wrote: post #453
dottedmag wrote: post #396

Earlier quoted context omitted.

(res, err) is Either monad, isn't it?

Its not a single value, so its not anything.

That may've sounded overly harsh - but as a first step, try for example to use the output of a Go function that returns two values in another expression.

e.g. assuming `g` returns (err, res), try writing `f` in such a way that you can call `f(g(x))`.

This has implications on how higher order functions like `map`, `filter` etc can be written in a way that makes them usable with any value (including those that represent an error)

Re: Functional programming should be the future of software

#460

Post by forgotpwd16 »

theCodeStig wrote: post #431
feoren wrote: post #280

Earlier quoted context omitted.

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

Unfortunately, a lot of Java programmers write imperative code in Java. Although I have seen "good" Java programmers write "good clean code", it's the exception, rather than the norm. Most of the good Java programmers that I know have moved on to better languages and platforms.

Would like to see a collection of good and bad Java code examples.
Post reply on HN