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

371–380 of 513 posts

Re: Functional programming should be the future of software

#371

Post by SkyMarshal »

leidenfrost wrote: post #370
mpweiher wrote: post #342

Earlier quoted context omitted.

> An anecdote of one person with bad manners shouldn't be representative of the whole. It is so incredibly widespread, it's not just "an anecdote of one person". The entry-level courses at TU-Berlin where I studied had just been taken over by FP disciples when I started studying, and it was crazy. "Let me tell you about our Lord and Saviour Functional Programming, Hallelujah". And of course the reality didn't come cl…

imho the whole thing about FP it's not about a objectively superior way of coding, but a way of coding that's better suited to the current high level, highly distributed world. There are A LOT of developers, a lot of custom made software and a lot of web applications. And unless you really need performance, most web services are an ideal use case for FP practices. Even if you do it in plain Javascript. Some people ar…

> current high level, highly distributed world

That's one area it's well-suited for. Also in error-handling and prevention, and in refactoring, and configuration management. All personal pain points for me previously.

Re: Functional programming should be the future of software

#372

Post by knaekhoved »

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…

> there's very little evidence that it produces better software in the long term.

Have you used other software? 99% of it is dogshit.

> libraries were full of bugs and performance problems

This is a really wild claim to me. IDK about Scala, but libraries in Haskell, Ocaml, and Elixir are all vastly better than libraries in C++, Java, Python, despite a smaller userbase.

Re: Functional programming should be the future of software

#373

Post by jancsika »

jerf wrote: post #267
sidlls wrote: 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…

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…

> The second is, well, mostly annoying to me because of the vigor of its advocates far out of proportion to either its programming utility or its mind expansion characteristics.

Thanks to closures, map/reduce function callbacks in Javascript are extremely handy.

Please link me to something like a stackoverflow answer with "vigor" greater than this, I'd love to read it.

Re: Functional programming should be the future of software

#375

Post by knaekhoved »

goostavos wrote: post #273
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?

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

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

Re: Functional programming should be the future of software

#376

Post by tsimionescu »

the_af wrote: post #298
AnimalMuppet wrote: post #275

Earlier quoted context omitted.

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

Well, try understanding the Haskell docs around Applicative, Functor or Monad without understanding at least basic category theory - not to mention the heavy use of notation/operators in place of traditional programming idioms (named functions).

Here [0] is an example:

> This module describes a structure intermediate between a functor and a monad (technically, a strong lax monoidal functor). Compared with monads, this interface lacks the full power of the binding operation >>= [...]

[0] https://hackage.haskell.org/package/base-4.17.0.0/docs/Contr...

Re: Functional programming should be the future of software

#377

Post by nequo »

brmgb wrote: post #104
capableweb wrote: post #72

Earlier quoted context omitted.

> it is heavily influenced by FP Is it really? I agree with the rest of your post, that Rust provides great tooling, but not sure it's "heavily influenced by FP", at least that's not obvious even though I've been mainly writing Rust for the last year or so (together with Clojure). I mean, go through the "book" again ( https://doc.rust-lang.org/book/ ) and tell me those samples would give you the idea that Rust is a f…

Considering Rust pretty much started as a way to have a ML for system programming and was written in Ocaml, yes, I think it's fair to say it was heavily influenced by FP. It became less and less ML-like as time went on but it still as a ton of features it inherited from Ocaml and Haskell: variant types, pattern matching, modules, traits come directly from type classes, etc.

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 all they also exist in Python, and second, they need to be sandwiched between .iter and .collect unless one is working with iterators which makes the code noisier and pushes the needle toward loops.

The influence of OCaml and Haskell is clear though, and it makes the language more pleasant to use.

Re: Functional programming should be the future of software

#378

Post by initplus »

torginus wrote: post #199
alanwreath wrote: post #111

Earlier quoted context omitted.

>> navigating all of the offerings, examining their trade-offs the amount of time you're afforded for that exercise better fit neatly inside a very small window of implementation (in other words you're probably not going to do it, or at least do it justice) >> figuring out which ones fit best to the system being built in terms of constraints constraints will always get ya. It always ends up to being what is the tool/…

I am sorry, but you sound like you know for a fact that functional programming is better, but you have trouble making others recognize that fact. Imho, FP has many tangible weaknesses, just a few off the top of my head: - Immutability is non-intuitive: If I were to ask someone to make an algorithm that lists all the occurrences of a word on a page, they wouldn't intuitively come up with an algorithm that takes a slic…

On this friendship example, I think already FP is showing you something useful about the way you are designing your model.

A friendship is really an edge in a graph. if you manage friendships by recording a collection of friend PersonId's on each person, you are modelling a graph by recording the same edge in two different places, and then hoping the programmer is diligent enough to never make a mistake and update the edge in one place but not the other. If you model the friendship graph as a collection of id pairs, not encapsulated inside a specific person structure, this invalid state is no longer possible.

I'm not sure what you are on about regarding making transitive updates - that idea is obviously not going to work on any moderately sized network. Imagine if Facebook tried to record all your transitive friendships on your account!

Sure immutability is non-intuitive, but it's really helpful! Like borrow checking in Rust, immutability helps eliminate an entire class of bugs. And immutable code is often much easier to reason about, you need to keep significantly less of the context in your head.

Re: Functional programming should be the future of software

#379

Post by dmitriid »

jve wrote: post #86
jvanderbot wrote: post #26

Earlier quoted context omitted.

There is nothing magical about functional programming, it is the elimination of non functional programming features that is important. A language that can do either is exactly the wrong thing, from the perspective of TFA

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

Re: Functional programming should be the future of software

#380

Post by tsimionescu »

packetlost wrote: post #239
AnimalMuppet wrote: post #232

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…

SQL is intrinsically tied to set theory and borrows a ton of terminology and logic from set theory. Whether you understand that it's from mathematics or not doesn't really matter. You are using set theory and it's terminology regardless. I've only really ever seen monoids referred to in Haskell. If you actually read my comment, Haskell is not all FP (no PL is). It's not even a significant portion of FP. So just don't…

SQL was explicitly designed to appeal to business people, and uses strictly familiar words and phrases. It was very explicitly designed (though I would say it has mostly failed) to read like pseudo-natural language.

SQL DBs and the precise semantics of SQL are somewhat based on relational algebra, but SQL syntax is definitely not. It's also not using set theoretic terms in general, with the exception of UNION and INTERSECT.

Post reply on HN