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

431–440 of 513 posts

Re: Functional programming should be the future of software

#431

Post by theCodeStig »

feoren wrote: post #280
commandlinefan wrote: post #213

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…

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.

Re: Functional programming should be the future of software

#432

Post by bee_rider »

Iwan-Zotow wrote: post #427
xdavidliu wrote: post #302

Earlier quoted context omitted.

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

> the ++ operator only acts on integer types no, I believe it works on pointer types and enums as well

It is also defined for floats.

Using it seems like a bad move though -- for large values it can round back to the input value.

Indeed, the following stupid test program works, although it may heat up your laptop slightly.

    #include 

    void main()
    {
      float C   = 1.0f;
      float Cin = 0.0f;
      int i=0;

      while (Cin != C)
      {
        i++;
        Cin = C;
        C++;
      }
      printf("%i %e\n", i, C/C++);
    }
And, it finally lets us confirm what the mathematicians never could. When does the limit happen? 16777216. No further questions.

Re: Functional programming should be the future of software

#433

Post by theCodeStig »

leidenfrost wrote: post #361
kstenerud wrote: post #318

Earlier quoted context omitted.

Addendum after watching this thread blow up: What's interesting to notice about this thread is how many messages are just oozing with smug superiority and disdain for anyone who doesn't share their knowledge. Yes, some are from genuinely humble and even-handed FP practicioners, but when we look at people who are vocal about FP, this small example shows around 90% of them in the gatekeeper camp. And the punchline is I…

On the other hand, it's really frustrating to explain this kind of things to the most Juniors. Many of them were too confident on their code because "they had everything in their heads" and anything else was like an incoherent and overcomplicated ceremony. "Why do all that when I can do a simple index.js file and add a simple if and that's it?" There's a catch with FP, where many of their implications impose you to w…

In contrast, I find juniors to be the easiest to teach. Those with more experience, are stuck in their ways, often stubbornly.

Re: Functional programming should be the future of software

#434

Post by bart_spoon »

valenterry wrote: post #312
ahartmetz wrote: post #217

Earlier quoted context omitted.

I strongly agree. Rule one: avoid and simplify state (e.g. recalculate data if it's cheap instead of updating it when any of its inputs change). Rule two: if you need state, keep it coherent by tightly managing it (go through functions that maintain the invariants) and exposing as little as possible. That is where classes come in.

Pure functional programming is orthogonal to that. In other words: you can have your class that contains a maximum simplified state, no problem. Extending this to be pure functional means that in addition to everything else that you said, the calls to the class that manages the state are now considered as needing "special treatment" in the sense that you can't merely call them, you have to also explain what should ha…

Could you ELI5 or perhaps give an example? I’m not sure I understand.

Re: Functional programming should be the future of software

#435

Post by packetlost »

TexanFeller wrote: post #426
packetlost wrote: post #239

Earlier quoted context omitted.

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 tables are not actually sets at all since you can insert duplicate rows! In practice they usually are though.

You can't actually insert a complete duplicate row because the ROWID (or whatever your particular RDBMS calls it) is a implicit, but unique property of each row (and corresponds to the offset in the file the row is located at). Further, while tables can be the identity element of all records they contain, they themselves aren't really a set. Usually when people associate set theory with SQL, it's with queries (and their results).

Re: Functional programming should be the future of software

#436

Post by theCodeStig »

mpweiher wrote: post #342
SkyMarshal wrote: post #290

Earlier quoted context omitted.

An anecdote of one person with bad manners shouldn't be representative of the whole. I'd estimate there are three kinds of FP advocates: 1) People (like me) who have experienced personal pain in building or maintaining complex systems in imperative or other paradigms, and are genuinely astounded and relieved when we learn how Haskell and other FP languages can mitigate or eliminate that pain. They tend to advocate FP…

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

> Not a pure function at all. And not really a function either. Just a mapping.

A function is a mapping of an input to an output.

Re: Functional programming should be the future of software

#437

Post by sidlls »

knaekhoved wrote: post #418
blep_ wrote: post #321

Earlier quoted context omitted.

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…

> 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 for why vaccines are good required "frontier" level discourse.

> Well-designed FP languages reify coherent low-complexity formal semantics.

This is such a great example of what so many of us have noted about FP evangelists. It's so divorced from writing software as to be gibberish.

Re: Functional programming should be the future of software

#438

Post by theCodeStig »

softwarebeware wrote: post #349
tikhonj wrote: post #309

Earlier quoted context omitted.

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

And yet today we only have partially-OOP languages being mostly used in procedural ways.

Exactly my point above, about Java.

Re: Functional programming should be the future of software

#439

Post by epgui »

sidlls wrote: post #437
knaekhoved wrote: post #418

Earlier quoted context omitted.

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

> 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 very little and are more skeptical of others than they are of their own understanding: instead of searching for ways in which their mental models need adjusting, they try to poke holes in your explanations. They'll repeat whatever objections they've seen or heard somewhere, whether or not the objection is relevant or adequate. This undermines both "ELI5" approaches (because what you gain in simplicity you lose in nuance and correctness) and more pedantic approaches (which require more prerequisite knowledge, experience, or patience).

If you disagree with me because that is not your experience, it's possible you surround yourself with unusually insightful and wise people.

Re: Functional programming should be the future of software

#440

Post by nequo »

narrator wrote: post #54
skohan wrote: post #3

Imo functional programming is one of those things that makes sense from a theoretical perspective, but comes with compromises when it comes to reality. The thing about functional programming is that the confidence you get from immutability comes at the cost of increased memory usage thanks to data duplication. It's probably going to create a ceiling in terms of the absolute performance which can be reached. There are…

The other problem with functional programming is it's harder to look at code and figure out the time complexity. At least with non-functional languages I can easily figure out why there are performance problems with it. Stuff like lazy evaluation may seem cool, but it's not when you have to figure out why something's slow.

In addition to sibling’s recommendations, consider OCaml too for a strict language that is vaguely similar to Haskell and performs similarly well in benchmarks:

https://cs3110.github.io/textbook/cover.html

Post reply on HN