151–160 of 513 posts
Earlier quoted context omitted.
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.
Don’t need to, look at F#. Its functional first and OO is bolted on.
Earlier quoted context omitted.
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…
> 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…
In my experience from University CS education and later on in industry, a quite large group of students or engineers, programmers never grasp the functional way of thinking. It don't just take longer time, it doesn't happen. For this reason I'm skeptical that FP will ever be able to replace imperative (and object oriented) programming.
One could almost say that functional programming will always be the future of software.
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 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/…
> advocacy among unbelievers is always gonna come off like this, especially when the evangelists have dealt with so many naysayers and the apathetic majority.
If an advocate sees unbelievers and naysayers around it is more a reflection of the advocate tactics. No offense intended. Most developers will gladly hear an overview of how a new technology can make doing X easier, better or faster. Even when there is a steep learning curve. They may not switch to it quickly or at all, but they are likely to form positive impression of it.
But if an advocate starts with "your tools are bad", "stop doing Y", "you need to unlearn Z" he is usually digging a hole for his technology, not advancing its adoption. If an advocate cannot produce powerful, convincing examples showing the goodness of his technology (without bashing existing tech) he should stop advocating and start learning. My 2c.
How do I know? A thought leader told me so!
Nothing against functional programming, which certainly has its uses and advantages, but this article is basically substance-free.
I guess it's really an ad for the author's company and book? Considering the shear number of things conflated with functional programming here, I'm not sure it would be worth the time.
Why did the GOTO statement fall out of favor with programmers? If you look at Knuth's famous article weighting the importance of GOTO (https://pic.plover.com/knuth-GOTO.pdf) you can see many calculations where the GOTO statement can save you a tiny bit of runtime. Today, these matter far less than all of the other optimizations that your compiler can do (e.g. loop unrolling, inserting SIMD instructions etc). Similarly, in some domains the optimizations that functional compilers can do matter more than the memory savings mutation could bring.
Personally, I believe that with in the next decades memory usage will matter more, but even then functional programming languages can do well if they can mutate values that only they reference(https://www.microsoft.com/en-us/research/uploads/prod/2020/1...). This does not break the benefits of immutability, as other program parts can not observe this mutation.
I disagree with the articles premise that it is "hard to learn".. it might be today but it doesn't have to be. Monads are usually difficult for beginners, but algebraic effects are almost as powerful while being much simpler. They have slowly become mainstream (and might even make it into WASM!). It is an exciting time for functional languages and many people are working to make them even better!
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.
Also: "But many functions have side effects that change the shared global state, giving rise to unexpected consequences. In hardware, that doesn’t happen because the laws of physics curtail what’s possible."
The laws of physics? That's complete waffle. What happens when one device trips a circuit breaker that disables all other devices? What happens when you open the door to let the cat out but the dog gets out as well?
It's funny, I'm calling cover effect (forgot the idiom, but basically when big medias put you up, your uptick is over) on simple FP. I think mainstream absorbed most of the idioms (map filter reduce, decorators, composability, lazy streams etc) and there's nothing else in that bag to push.
That said, I do believe that FP as an abstract multi stage modeling language is still gonna help in the future because it raises provability which is something that I personally miss every day in most mainstream languages. You're never too sure about anything and it's tiresome.