Live data from Hacker News

Functional programming should be the future of software

spectrum.ieee.org

111–120 of 513 posts

Re: Functional programming should be the future of software

#111

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…

>> 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/paradigm that you (and your project manager) are most comfortable with because you'll most likely use it in leu of anything else (especially given you are not the only one that has to be convinced -- engineers don't operate in a vacuum, and they love predictability, ie what they already know)

>> You won't get a very optimal solution by ...

YAGNI. Premature Optimization. KISS.

I am not saying that ^^^ is true, I'm just introducing you to your new conversation buddies for the foreseeable future. People always bring'em along for the conversation.

>>> trying to talk you into a religion

advocacy among unbelievers is always gonna come off like this, especially when the evangelists have dealt with so many naysayers and the apathetic majority. And this is probably the crux of the entire issue. Students' first languages in school are generally imperative languages. They are taught in their youth a path away from functional programming. Which is funny to me because my school was always promoting that their studies were there to help you grow one's intellect and not necessarily fit into some cog of the industry. But, I don't recall much playtime given to functional languages (not as much as they deserved at least).

My point is that it would be nice if FP was the first tool that was given to students that pour out of universities into developer teams. It would be nice if the easy button for a group was FP, not the other way around. Then it would be much easier to beat the other drums (like the testing drum).

Re: Functional programming should be the future of software

#112
Functional programming proponents like the blog's author remind of Linux users who sweared by it as a user-friendly OS, thought of everyone else as idiots, and refused to admit its serious flaws as a general-purpose OS. I am not criticizing FP. It has great ideas and many of them have been actively borrowed into other languages. But it's just annoying to see bad analogies that get repeated again and again, like these:

> Now, imagine that every time you ran your microwave, your dishwasher’s settings changed from Normal Cycle to Pots and Pans. That, of course, doesn’t happen in the real world, but in software, this kind of thing goes on all the time.

> Let me share an example of how programming is sloppy compared with mathematics. We typically teach new programmers to forget what they learned in math class when they first encounter the statement x = x + 1. In math, this equation has zero solutions. But in most of today’s programming languages, x = x + 1 is not an equation. It is a statement that commands the computer to take the value of x, add one to it, and put it back into a variable called x.

Deja vu! I read exact same arguments 10 years ago. Maybe if FP did reduce the bugs, you'd have some stats and successful projects to back them up.

I worked at a company where FP was heavily used. It didn't magically reduce the number of issues we had to fix. Possibly increased them because of number of things we had to build from scratch. The company is default dead[1], now. Maybe bugs are not a symptom of the paradigm, but how strongly the systems and teams are architectured to prevent them.

[1]: http://www.paulgraham.com/aord.html

Re: Functional programming should be the future of software

#113

I like the philosophy of Rust (and some other languages) of "safe by default". Rust variables are immutable by default, but can be made mutable using "let mut". Rust is memory safe by default, but can be made unsafe using the drumroll "unsafe" keyword. As for null references, other languages still have them but enforce "strict null checking", such as Kotlin and TypeScript. They force you to verify a reference is not…

> but without the verbosity of an Optional or Maybe type

Without the safety of having that encoded in the type system.

Re: Functional programming should be the future of software

#114
post #76

Earlier quoted context omitted.

Tooling is why Go gets its foot in the door much quicker than other languages IMHO. A single binary with no dependencies that does pretty much everything.

I've seen go programs fail to start because they were dynamically linked to some .so file I happened to not have.

Yeah ‘Fully static’ requires some extra linker flags.

Re: Functional programming should be the future of software

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

That's an Haskell issue not a functional programming issue. Haskell is pretty much the only functional programming language which is lazy by default. It's the sole one for the reason you give. Every other ones are eager by default and you can opt in to lazy evaluation when needed.

Re: Functional programming should be the future of software

#116
post #97

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…

> You gave up using a programming language after a day? And Haskell after installing/building some dependencies for 20mins... I'd do the same. It's 2022. There are so many options without this friction, why would you fight your way through it? If either language had some magic power or library, that'd be one thing, but their only selling point is the FP paradigm, which is only arguably somewhat better than what other…

Haskell's promise is not only FP. That's part of it though, of course, to have an ecosystem, which encourages to continue in an FP style. Haskell's promise is also strong type safety and, as a distinguisher to many langauges, lazyness by default. Aside from that, its implementation is quite performant, if one needs to worry about such things.

I will take a 20min build process for dependencies (probably a few commands, which hopefully are documented in the project's readme and probably only once for most of the lifetime of a project on your personal machine) over a language, that is quickly up and running, but breaks any number of basic principles (for example looking at JS) and lets me shoot myself in the foot. Some languages and the lessons we take from learning them are worth some initial effort. Of course it is not great, that things are not as easy, as they maybe could be, but if the language has other perks making up for that, it might still be worthwhile.

Re: Functional programming should be the future of software

#117

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…

This is just an appeal to the law of averages. I don't believe that you're actually considering ada, cobol and forth for new projects.

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

This is never really a reason for anything, it's a personal attack on people who advocate the thing that you don't want to do. FP people are not bullying you, or shoving anything down your throat.

Re: Functional programming should be the future of software

#118
post #24

Functional programming won't succeed until the tooling problem is fixed. 'Tsoding' said it best: "developers are great at making tooling, but suck at making programming languages. Mathematicians are great at making programming languages, but suck at making tooling." This is why Rust is such a success story in my opinion: it is heavily influenced by FP, but developers are responsible for the tooling. Anecdotally, the…

I think F# has a good tooling story, since it's part of .NET and a first-class citizen in Visual Studio. It doesn't get as much love from Microsoft as C#, but it's still quite nice to use.

After learning a bunch of programming languages and their corresponding ecosystems (incl. Rust, Lisps, Scala), F# is still my favorite by a long shot. Its only serious shortcoming, imo, is the tooling.

Visual Studio is great, but if you're not on Windows, your only practical choices are VS Code + Ionide (I was a sponsor for a while; ultimately lost hope), or JetBrains Rider, which is powerful, but heavy.

Comparing my 10+ years focused on C# with ~5 years focused on F#, I was ultimately more productive in F#. But:

1. Tools for refactoring and code navigation were better for C# 2. Testing was more predictable with C#; I often just tested from the CLI with F# (so much love for Expecto, though) 3. Paket and dependency management between projects caused days of pain, especially during onboarding

Re: Functional programming should be the future of software

#119

Hybridization of object-oriented and functional approaches seems like a decent approach to theses problems. > "Nearly all modern programming languages have some form of null references, shared global state, and functions with side effects..." Which is to say, code is organized into discrete classes, instantiated as objects, but those objects only use the functional paradigm with respect to their bound functions, i.e.…

Someone should bolt object-oriented features on top a functional programming language to see what it would look like. That would be an interesting research project. They could call it O-something and do a pun with an animal name.

Re: Functional programming should be the future of software

#120

Functional programming proponents like the blog's author remind of Linux users who sweared by it as a user-friendly OS, thought of everyone else as idiots, and refused to admit its serious flaws as a general-purpose OS. I am not criticizing FP. It has great ideas and many of them have been actively borrowed into other languages. But it's just annoying to see bad analogies that get repeated again and again, like these…

Did you mean to comment on the analogies you quoted other than to say that they are often used? Is being useful a problem for an analogy?

> But in most of today’s programming languages, x = x + 1 is not an equation. It is a statement that commands the computer to take the value of x, add one to it, and put it back into a variable called x.

This is on page 1 of every basic programming book when it's explaining how "variable" differs between math class and programming class. I can't for the life of me see what upsets you about it.

Post reply on HN