Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

181–190 of 513 posts

Re: Functional programming should be the future of software

#181

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…

Totally agree. As a Javascript dev I got functional code pushed on me in 2016. It's definitely good practice for devs to learn some of the pitfalls that FP prevents and solves, but implementing it on a massive scale front-end application just seems impractical. Having worked on a large streaming service and considering the author's 3 MONTH struggle after his 40 YEARS experience, I'd estimate that a re-write of our co…

Functional programming, and it's degenerate cousin, cramming random functional constructs (array comprehension methods, willy-nilly currying, ...) in Javascript has been the worst thing to happen to web programming.

What that has done is made a whole generation of developers completely detached of the impact on heap allocation and GC. If web programs are slow and bloated, it's partly because of using nuggets from functional programming just for the sake of it.

Re: Functional programming should be the future of software

#183

I believe functional programming is interesting, and fun. But it is not going to replace the world. My background has spanned from working on AAA games, to simulations for the DoE, to owning my own business developing embedded products, and graduate school (yes, I went back as a gray haired, and did that late). I fell in love with Lisp many years ago on a TI Explorer. Functional languages are inherently difficult to…

>Functional languages are inherently difficult to develop applications that require state to change in non-deterministic ways. In fact, I challenge you to develop a first-person shooter in Haskell (Have fun). Don't know about Haskell but it would be very fun to do it in Lisp. Performance sold separately.

Common lisp has a "pretty OK" story for calling C code whenever some speed is needed [0,1]. In my opinion, they suffer from some of the documentation/quick start problems that common lisp has, but they're otherwise usable.

Some of Naughty Dog's late 90's/early 2000's games (Jak and Daxter, Jak II) were written in a lisp called GOAL, Game Oriented Assembly Lisp [2]

[0] https://github.com/rpav/cl-autowrap [1] https://github.com/cffi/cffi#cffic2ffi [2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Re: Functional programming should be the future of software

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

As someone that's left scala and come back to dotnet land... depending on the domain, functional programming results in much cleaner solutions. A lot of the code messes in functional paradigms that I dealt with and also created were mostly due to people that didn't understand how to think functionally. It took a long time for me to figure it out. I find myself missing features all the time now, and spending a whole l…

This rings true - experiencing different paradigms opens you up to more elegant solutions. That's why years later I now see the value of the "Programming languages" course I had in university - every lecture covered a new language and had homework to implement a program in it. I haven't touched LISP or Prolog since, but just being exposed to them made me write better code in "traditional" languages.

Re: Functional programming should be the future of software

#185
> The biggest problem with this hybrid approach is that it still allows developers to ignore the functional aspects of the language. Had we left GOTO as an option 50 years ago, we might still be struggling with spaghetti code today.

This is demonstrably false, as C has always had a goto and its use by custom and in practice is greatly circumscribed.

Re: Functional programming should be the future of software

#186
post #66

Earlier quoted context omitted.

I think tsoding has the wrong idea here. Most mathematicians are not working on GHC or Haskell standards or even using Haskell. Most are still doing mathematics on pen and paper. Many use packages like Sage or Wolfram alpha. Few are using interactive theorem provers like Lean. Haskell is a poor language to be doing mathematics in. I’d say the majority of people working GHC are software developers and CS researchers.…

I think he counts academic computer scientists more as mathematicians than developers.

C++ and Java wouldn't be where they are without CS researchers, so I think the point still stands. These people aren't doing useless work. They're the ones making sure Concepts won't break the entire ecosystem and that have made the JVM the beast it is.

Grit and determination will get you far but like it or not there is a ton of work that requires knowledge of mathematics and theory that you can't avoid if you want to make good things.

What's kind of neat about Haskell is how closely researchers can work with users and collaborate on solutions.

Remember, the GHC team is pretty small. Their IRC channel isn't huge. Releases still get made fairly regularly and GHC is running one of the most advanced industrial strength programming languages out there with a large ecosystem.

Re: Functional programming should be the future of software

#187

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.

Eh, I doubt it. I've encountered a few Haskell snobs in my time, but most people that I know who use FP do so completely silently and will discuss the merits and (and challenges) with you freely. I think the real issues with FP are lack of good tooling, package management, and being a major shift in thinking for most developers. It's a common theme for someone to say that learning FP (seriously) was the most impactful thing they've done to improve their software chops.

> The other major impediment is gatekeeping

??? what? I guess you could argue that pure vs non-pure functions are gatekeeping, but there are absolutely legitimate benefits to pure functions that basically everyone can agree on.

Re: Functional programming should be the future of software

#188
post #35
post #23

Earlier quoted context omitted.

If the first thing you talk about is performance and not quality and maintainability, then you're already missing the point. Most software just isn't in some super high-perf environment - what matters is fewer bugs, easier maintainability, better communication with other engineers (through declarative code). The code we work on in the 2020s is much, much more complex than code written 20 years ago. We need better pri…

I just disagree that performance isn't a concern in almost every context. There's a hierarchy of concerns, to be sure, and if you haven't written reliable code which solves the problem yet you shouldn't be worried about performance, but if your PL itself imposes a performance tax, that's something which has to be paid every time your program gets executed, by every user. As programmers, our job is to not to play with…

But Python/Ruby (and JS? Not sure how far they are with optimising that or what the comparison would be) are very slow compared to Haskell. So people are paying that price all the time without getting any benefits that Haskell (etc) can over next to it. I agree with the GP; performance is really not very interesting for most projects and most (Py/JS are the top dev languages by far I think) programmers/companies are agreeing with that by using low performance environments that make them productive. So productivity seems to win out.

For sake of the environment and hardware upgrades, I think we definitely should make an effort and we can see that improvements in compilers and PL theory do help with this when the goal is practical programming languages using these techniques; Rust does, Haskell was meant as academic language for a long time.

I think robustness/security should go first anyway as hierarchy of concerns; that's where things are really breaking now.

Re: Functional programming should be the future of software

#189

JavaScript is functional if you write in functional. There's nothing stopping you from writing pure functional code in JavaScript or TypeScript.

I think this is something a lot of people overlook too quickly, too. It's pretty easy to get some of the benefits of FP without using Haskell/Scheme/ML/whatever in a lot of languages:

- Write pure functions

- Postpone side effects until necessary (as in, set up the side effect in a way that the side effects inputs are testable)

- Return things when possible, in order to increase the expressiveness of your code

It's also important to not fight the language you're working in. If you're constantly breaking idioms and your teammates can't read your code, FP isn't providing any benefit.

Re: Functional programming should be the future of software

#190
Arguably the single most determining factor in using a language is the size of the ecosystem relative to the use case. If I'm writing a data science app I'll probably use Python because I can access a large number of well-tested libraries in the space, not because Python is a superior language itself. Same argument for Java (come on, who actually enjoys Java?) Whether it's OO or FP isn't going to be a major consideration. I enjoy Ruby over any other language, but don't use it much at work because ... ecosystem.
Post reply on HN