Can I state for the record that almost every C compiler still supports GOTO?
Rust supports the best traits of both Functional and Imperative languages.
Ergo: The future is Rust. Rust is the future.
Functional programming should be the future of software
191–200 of 513 posts
Re: Functional programming should be the future of software
#192I 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…
> In fact, I challenge you to develop a first-person shooter in Haskell (Have fun).
https://hackage.haskell.org/package/frag
> There are many types of applications where functional languages are perfect, but there are more that it would be a disaster.
Can you give an example or two of an application in a functional language would be a disaster?
> To make broad sweeping claims, such as this article, just encourages unnecessary discourse, and shows the ignorance of the author, and his limited understanding
No, it's an opposing viewpoint to the popular "right tool for the job" and "take the best from functional, best from imperative, and smash them together".
See "The curse of the excluded middle by Erik Meijer".
> As an employer, I don't hire people for their functional programming skills.
I certainly choose my jobs with language and ecosystem in mind.
Re: Functional programming should be the future of software
#193Imo 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…
> Imo functional programming is one of those things that makes sense from a theoretical perspective, but comes with compromises when it comes to reality.
Ironically whay you say is true in theory, but not true in the real world.
Source: real world Senior Haskell programmer
Re: Functional programming should be the future of software
#194Earlier quoted context omitted.
Why do you think that functional programming results in data duplication? I would think it's rather the opposite. With strong immutability like in Haskell, you can share values even between threads and can avoid defensive copying. Two versions of the same immutable tree-like data structure can also share part of their representation in memory. (Haskell has other problems causing increased memory usage, but not relate…
Not the poster you’re responding to but I think they’re referring to the current need to allocate more memory when updating immutable data structures. Not that there aren’t ways to represent mutability in Haskell, just that the de facto use of immutability causes excess allocation.
Efficient functional programming often uses tree-like data structures. These can be immutable but still avoid duplication.
Consider if you "duplicate" a Data.Sequence Seq (finger tree) for modification. You're not actually copying the whole structure, you are creating a new root node and re-using as much as possible of the common structure.
The end result is that a bit more memory is used in the simplest case, but not due to duplication I think.
The benefit is that a thread can make a modified value at cheaper cost without affecting another thread that is still using the original value. I also think it's easier for the programmer to understand the code.
Re: Functional programming should be the future of software
#195I 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. (The other major impediment is gatekeeping) I think one of the major reasons is because IO doesn't really fit well into the FP paradigm. All the theory and niceties take a second place when you find out that something as simple as "print a line here to console" is…
Isn’t this IO thing a bit overused? There are more FP languages that are not as pure as Haskell, but even if we only do IO through a special monad it is not too bad at all.
And I say that as someone who is very much fore “practical FP” — I do think that local mutability is sometimes simply the better fit for a problem.
Re: Functional programming should be the future of software
#196The first text sums it up: It’s hard to learn Which is refreshing to see just stated up front: FP is for smart people who have some motivation to learn something hard, even when there's a whole world of alternatives that are not "hard" to learn. in this writer's case, it appears to be they own a company and they've mandated everything be written in Haskell or PureScript, which will select for employees that are willi…
Specifically, FP requires expansive working memory, which is a normally distributed trait across the population. Meanwhile, in OOP one can reason from the perspective of the object and the interfaces it's interacting with, easing the burden on programmers, but there are obviously drawbacks there as well.
Re: Functional programming should be the future of software
#197Earlier quoted context omitted.
I don't disagree that manipulating deep arrays and graph data can be harder in an immutable functional language, at least with default commands.. however many fp languages have powerful and mature libraries that let you work with deep data structures very gracefully and correctly. Clojure has Specter, Haskell has lenses and stuff. For me, the FP dream ( and we aren't quite there yet) is that your program is an airtig…
See my cousin comment; I just wanted to make the point that working with tree-like data structures in FP feels rather natural.
Tree data structures are pretty prevalent in compiler. Like that, perhaps?
Re: Functional programming should be the future of software
#198Earlier 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…
Sure -- people have the right not to try things, which is basically what messing around with a programming language in a new language paradigm for 1 day is. That's fine, although it should also be expected that their opinions on things they haven't tried won't be given much weight.
Re: Functional programming should be the future of software
#199I 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/…
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 slice of text and a list of occurrences, then returns an extended list, and an linked list with one more occurrence.
- Immutability can cause more problems than solve: If I were to create a graph of friendships between people, chances are that if I were to add a link between A and B, then not only A and B would need to be updated, but everyone who transitively knows A and B (which, since no man is an island would probably mean, everyone). This is highly complex, and probably just as bad as living with mutability.
- FP is not performant: FP code tends to be full of pointers and non-performant data structures like linked lists that have very little memory locality. It also makes optimizations such as updating things in a certain order to avoid recalculation impossible.
- FP has to deal with side effects: The real world has side effects, and your FP code is probably a bit of business logic that responds to a HTTP request, and fires of some other request in turn. These things have unavoidable side effects.
Re: Functional programming should be the future of software
#200Hybridization 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.…
> Hybridization of object-oriented and functional approaches seems like a decent approach to theses problems.
It's too complex and loses a lot:
> Contemporary imperative languages could continue the ongoing trend, embrace closures, and try to limit mutation and other side effects. Unfortunately, just as "mostly secure" does not work, "mostly functional" does not work either. Instead, developers should seriously consider a completely fundamentalist option as well: embrace pure lazy functional programming with all effects explicitly surfaced in the type system using monads.
https://m-cacm.acm.org/magazines/2014/6/175179-the-curse-of-...