Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

361–370 of 513 posts

Re: Functional programming should be the future of software

#361

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…

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 write better code. But it's not mandatory to go the functional way to do that, and I always try to explain the importance of those fundamental principles to other people, and they can try to implement it in whatever style they desire.

But when someone just doesn't want to learn, they always see me with a smug and gatekeeping attitude and I can't help but see them as people that just don't care at all.

Re: Functional programming should be the future of software

#362
post #95

Earlier quoted context omitted.

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…

> What kind of experience with a programming language do you expect to have after a mere day? Learning takes time. It does, which is why you need tooling to get out of the way and let you actually learn. Working out obscure tooling commands to build a hello world app then having to grok the error messages absolutely destroys the learning loop. For rust it took me approximately 3 minutes from scratch to install, boots…

As I see it, this is a completely legit beginner level perspective. When I first touched a programming language (C, Borland compiler) I was able to run a first program within minutes. I completely understand the frustration with development environments that frustrate an aspiring user unnecessarily - I had this experience with F#, VSCode an Ionide, which is a very ugly case. Haskell was not that bad, but it it certainly is not for the faint of heart.

Re: Functional programming should be the future of software

#363

Earlier quoted context omitted.

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

Problem is, it's hard to distinguish the chaff from the wheat. A lot of practices that advertised themselves as "the way of the future" and most of them faded into nothingness.

At some point people try to save time and stick with practices that stand the test of time.

Re: Functional programming should be the future of software

#364
post #310

Earlier quoted context omitted.

.net, and C# especially are absolutely fantastic tools for programming. The problem is just that they are embraced by large companies and that is where crappy engineers tend to congregate, in my experience. The bigger the company the easier it is to get lost in the crowd. I enjoy functional programming, but I'm a wizard with C# and .net, and I can pull a much higher salary continuing to focus there. I can write my ow…

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.

Re: Functional programming should be the future of software

#365

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…

FP has one distinct advantage over many other paradigms, it has very sound and well understood theoretical foundations, being essentially based on the formal mathematical logics (e.g. System F and its derivatives). This has huge implications for correctness and reasoning.

Re: Functional programming should be the future of software

#366

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…

FP has one distinct advantage over many other paradigms, it has very sound and well understood theoretical foundations, being essentially based on the formal mathematical logics (e.g. System F and its derivatives). This has huge implications for correctness and reasoning.

I'll get made to take shortcuts to get the product out before I'll be allowed to be strict on correctness if it means pushing a deadline back even a single day. I love correctness, but it's just not often important to people who aren't me and for reasons completely outside of my control.

Re: Functional programming should be the future of software

#367
post #215

Earlier quoted context omitted.

I was once at a distributed systems meetup where a member of the audience interrupted the talk to give an extemporaneous presentation on why we should all be using Haskell. FP advocates have a reputation for being zealous and pretentious. The only question is whether they’re right to be.

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…

> Try to focus on and/or associate with #1 and #2 and ignore #3.

I disagree. We are too tolerant with the zealots.

They are an obstacle to the exchange of knowledge. They don't want people to learn and get better at programming. They want to live in their own Mr Robot personal fiction.

FP is a tool. A great tool, yes. But a tool in the end. And we should promote it as such.

Re: Functional programming should be the future of software

#368

Earlier quoted context omitted.

1. Immutability is non-intuitive. If I were to hand a regular person a book, and ask him how he would list all the page's numbers where the word cheese appears, he would probably say something like this: 'I would read through the book, keeping a scrap of paper at hand. Whenever I saw the word cheese, I would write down the page number' This is an imperative algorithm. I could give more examples, but I hope you get th…

> 1. Immutability is non-intuitive. If I were to hand a regular person a book, and ask him how he would list all the page's numbers where the word cheese appears, he would probably say something like this: 'I would read through the book, keeping a scrap of paper at hand. Whenever I saw the word cheese, I would write down the page number' This is an imperative algorithm. No, that's a purely functional algorithm. Note…

> No, that's a purely functional algorithm. Note how he's just adding numbers to the end of a list and emphatically not mutating the existing items in any way.

They are clearly mutating the piece of paper to add new numbers to it. There is no linked list in sight. They are also flipping the pages of the book in order, another imperative paradigm.

The closest you could come to a pure FP algorithm expressed in physical terms would have been "Say there are still pages I haven't looked at, and say I have a stack of post-it notes on the current page; then, I would check if the word cheese appears on this page, and if it does, I would produce a post-it note with the page number on it, adding it over the stack of post-it notes; I would then flip one page; on the other hand, if I am looking at the last page of the book, I would add another post-it note to the stack if needed, and return the whole stack of post-it notes to you otherwise".

Imperative:

  foreach page in book
    if 'cheese' in page
      write(paper, page.number)
Functional:

  search page:rest_of_book post-it-stack = 
    search rest_of_book 
           (if ('cheese' `on page) 
              then number(page):post-it-stack 
              else post-it-stack)
  search [] post-it-stack = post-it-stack
Of course, we could write this easier with a map and filter, but I don't think there is any good way to express those in physical terms (not with a book - filters have nice physical interpretations in other domains though).

Later edit:

A version of the imperative algorithm closer to what was described in prose:

  repeat:
    word = read_word(book)
    if word == 'cheese':
      write(paper, current_page_number(book))
    if no_more_words(book):
      return paper

Re: Functional programming should be the future of software

#369

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…

What does gatekeeping mean in this context? Genuine question.

Something like "oh, you're using map() and filter() in your C++ program? you're not doing actually doing FP unless [...]".

See https://news.ycombinator.com/item?id=33438320 for an example of this exact attitude.

Re: Functional programming should be the future of software

#370

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…

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 are zealots about it, yes. But imho FP is a better way to trickle down those concepts instead of telling people to spend decades to become imperative code masters.

Post reply on HN