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

211–220 of 513 posts

Re: Functional programming should be the future of software

#211

Post by bcrosby95 »

Widdershin wrote: post #20
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…

This is actually an area where there’s room to improve FP languages. If you track ownership in functional languages, you can statically determine if a value is used more than once. If it’s only used once, you can apply any updates to that value in place without allocating more memory. This gives the performance benefits of mutability with the safety benefits of immutability, in some common cases. The main trick is ad…

I get that not everyone does, but a large part of why I use Clojure is because it makes a whole class of concurrent designs easier. In particular, sharing that immutable data across multiple threads.

As a simplified example: one thread modifies the data, and another thread writes a snapshot of the data.

In the programs I write, it would pretty much never benefit from this optimization.

Re: Functional programming should be the future of software

#212

Post by throwawaymaths »

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…

I think you're completely missing an entire world of FP languages which are not pure like Haskell, ocaml, elm, etc... There are languages with side effects as an easily accessible escape hatch but don't do things which make debugging a pain like data encapsulation and inheritance.

Also, there are FP langs out there that have better data/heap locality with indirected pointer data structures, because they don't share memory and so the pointers aren't tied to anywhere except where they are directly running.

I completely disagree with immutability being non-intuitive. Try explaining to a junior/bootcamp JavaScript or python developer why when you pass an integer into a function it doesn't reflect changes you made in the called function when you jump back into your calling frame... But if you do the same with a object/dictionary...

For junior programmers immutable passing is absolutely the default assumption and so I think it's reasonable to claim it's the intuitive choice.

There's even crazymaking shit where in python if you have a default array parameter you can seriously fuck up your model of what's going on if you mutate that array anywhere.

Re: Functional programming should be the future of software

#213

Post by commandlinefan »

le-mark wrote: post #7

It would be helpful if the article started off defining what a functional language is. A lot of languages have functional features but are not “purely” functional. I think most would agree there’s a spectrum; dynamic vs static, eager vs lazy, mutable vs immutable. So what flavor of functional programming one might ask, since javascript is a dynamically typed flavor that is ubiquitous nowadays? The fine article sugges…

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

Re: Functional programming should be the future of software

#214

Post by GaryPalmer »

DeathArrow wrote: post #167

Functional or procedural or whatever, it doesn't matter much for me as long as the paradigm is not OOP. I strongly believe that data should live separate from the actions performed on it. I also believe that inheritance is a bad thing as there are other, better means to achieve polymorphism. I do believe in a data oriented programming where we waste as little CPU cycles as possible and introduce as little abstraction…

I am working on a java game where I threw all OOP knowledge out the window and use C-style pure data-classes with public fields and no methods.

It's pretty refreshing to work this way compared to the design pattern madness you see in enterprise applications - but I guess it's not very safe if multiple people are working on this and some don't know what they are doing.

There has to be some middle ground, I think people have been going way overboard with OOP in the last two decades.

Re: Functional programming should be the future of software

#215

Post by pfraze »

pessimizer wrote: post #117
kstenerud wrote: post #57

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…

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.

Re: Functional programming should be the future of software

#216

Post by zamalek »

agentultra wrote: post #186
exyi wrote: post #66

Earlier quoted context omitted.

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

> C++ and Java wouldn't be where they are without CS researchers, so I think the point still stands

I'm not sure how you gleamed that they aren't important/haven't made important contributions/aren't doing useful work from that comment. Tsoding specifically said that they don't make good tooling, but make great languages. It's not memeing about "Haskell for research," it's talking about things it needs to improve (potentially to break free of that meme).

For what it's worth, C++ tooling also sucks. We've just layered tons of kludges on top of it that make the ecosystem somewhat bearable. It's not ideal, contributing to a project for the first time usually requires some troubleshooting to get a working build.

Re: Functional programming should be the future of software

#217

Post by ahartmetz »

dec0dedab0de wrote: post #139

I don't know any purely functional languages[], so my viewpoint is skewed here. Whenever I have seen a python developer drink the functional kool-aid they end up either storing state in global variables, environment variables or in a dictionary they end up passing to every function. I then have to explain to them that passing a dictionary around and expecting variables to be in it is just half-assed OOP. My rule of t…

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.

Re: Functional programming should be the future of software

#218

Post by yxhuvud »

nayroclade wrote: post #48

It's strange to me that this article focusses so much on nullability, which seems like a tangental issue. There's nothing stopping an imperative language from enforcing nullability checks. Indeed, with full strictness enabled TypeScript will do just that, including requiring you check every indexed access to an array.

Yes, enforced nullability checks is just a type system feature. Another example that has it is Crystal, which is an OOP language.

Re: Functional programming should be the future of software

#219

Post by Test0129 »

hresvelgr wrote: post #163
kstenerud wrote: post #57

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. This is a part of it. The other part is FP's a bit of a mind fuck if you're used to procedural programming. Take a classic example: Haskell. To do anything remotely productive it's advisable to understand how monads and the various monad design patterns fit togeth…

I'm not sure why you're getting downvoted.

> I get where you're coming from but this is the end state as far as I'm concerned. Pure FP is where we're all headed. I am convinced the more we try to make mutable state, and concurrency safe and correct, the more FP concepts will leech into future languages.

Having been around the block to catch a couple "FP will rule the world" cycles I can say this is likely untrue. While FP is useful and I personally enjoy it, it is not always the most efficient, nor is it the most clear. This is true in your example of Rust as well. Functional constructs are often slower than their procedural counterparts. For example, having to pass around immutable data structures becomes pretty memory intense even with a highly developed GC.

> I could be totally crazy, but I reckon many years from now, we'll joke about mutating state the same way we joke about de-referencing raw pointers.

Dereferencing raw pointers has been joked about as long as I've been in the industry, and probably even joked about in the 70s. We still dereference pointers today. Similar, state is a very natural thing to reason about. Sure, you can argue as many FP fans do that stateful programs can be rewritten with pure functions. I have yet to see FP code that does this that doesn't negatively effect readability. Even something as simple as large map/reduce/filter chains can quickly become extremely difficult to debug when compared to a very simple loop.

All this to be said there's a lot of benefit many languages can take from FP paradigms. Map, reduce, etc are great examples. Offering immutable state, and algebraic data types could also be beneficial especially in the areas of concurrent and parallel programming. In my professional experience the problems usually start when you begin talking about pure functions which in theory are awesome but sometimes don't map to a problem domain well, or become extremely hard for Joe Developer to get used to. Often times I will think in a functional way, but rewrite things into a procedural way, because communicating your idea is often just as important as the code you write.

Re: Functional programming should be the future of software

#220

Post by Shorel »

zamalek wrote: 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…

As someone who likes both mathematics and programming, I find this comment and the article too divisive for divisiveness’ sake.

Programming is applied mathematics. An assignment is not 'sloppy' like the article posts, it is just another kind of operation that can be done.

A proof is very much like programming, except you are also the parser, the compiler, and the (comparatively slow) computer. Learning to write proofs helps immensely with learning how to program.

We should strive to make our proofs and programs easier to understand, no matter the paradigm.

Post reply on HN