The programming world peaked with structured and modular styles. Everything else is random noise.
Keep your programs nicely structured and easy to follow. No code "architecture" nonsense, please.
Functional programming should be the future of software
201–210 of 513 posts
Re: Functional programming should be the future of software
#202Earlier quoted context omitted.
I'm really happy with Meson, as a lot of Wayland (the new display protocol for Linux, the "successor" of X11) apps seem to be built in C, so using meson is super simple and I don't have to worry about tooling (I don't deal much with C/C++, so let me make my change and run away please). Rust is the same, you can even define a nightly version if you want, so even the correct version is ran with rustup. It's fantastic,…
> I don't deal much with C/C++ that is because there is no such thing.
C/C++ is just 1 in the limit, right?
Re: Functional programming should be the future of software
#203JavaScript is functional if you write in functional. There's nothing stopping you from writing pure functional code in JavaScript or TypeScript.
> 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.
https://m-cacm.acm.org/magazines/2014/6/175179-the-curse-of-...
Re: Functional programming should be the future of software
#204The properties mentioned in the article are not really tied to functional programming. - Not allowing null-references can be done with any paradigm. For example with object-oriented programming there really is no reason why it wouldn't work to not allow null references. - Immutability can also be done with every paradigm. The Java String for example is both object-oriented and immutable. I think the paradigm is actua…
Tis doesn't give you 1) ease of use and 2) composability.
Re: Functional programming should be the future of software
#205Functional programming, as a paradigm, is way better than object-oriented programming, and also equally more complicated than object-oriented programming. My observation, over the past 30 years, is that 90+% of programmers aren't even capable of doing object-oriented programming - so getting them to do functional programming is a pipe dream.
Re: Functional programming should be the future of software
#206The 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.
> Specifically, FP requires expansive working memory,
What? FP increases local reasoning!
> in OOP one can reason from the perspective of the object
In FP one can reason from the perspective of the function?
Re: Functional programming should be the future of software
#207I 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…
What does gatekeeping mean in this context? Genuine question.
Re: Functional programming should be the future of software
#208I like and agree with much of the advantages of FP, but I’ve never used it exclusively.
A number of years ago, we worked with a startup that was based around a new FP language, focused on image processing pipelines[0]. It’s actually quite cool. We came from a C++ background.
Learning the language was difficult, but our team was very capable, and very experienced. We did it.
But it was just too limited, and the advantages never appeared for us. We were doing it for an embedded implementation.
It was a really neat experience, but ended up as a failure. I am sorry for that, as I actually thought they had the right idea, and I think that management failure was as much to blame as technical hurdles. The language had many limitations, but we were still able to work with it. That’s what you get, with a highly capable team. The startup we worked with, had some real rockstars.
These days, I program in Swift, which has many FP features. I enjoy it.
Nonetheless, I think that many of these “new paradigms” are built around the premise that most programmers suck, and need to be forced to write good code, which never seems to work.
Companies seem to be desperate to hire crappy engineers, and get them to write good code, as opposed to hiring decent engineers, in the first place, who can write good code, regardless of the tools.
Re: Functional programming should be the future of software
#209Lot of the time arguments for Functional Programming seem to describe some form of total programming and avoiding partial functions. Like enforcing null checking or exhaustive matching, avoiding panics etc. When I was going through Functional Programming classes in Haskell, the teacher tried to separate total programming and functional programming. For instance Rust programs rarely use function composition compared t…
Arguments from academic and mathematicians will/may favor provability.
Pure Functional where everything is function composition have more hope of producing a valid mathematical proof for a block of code. CS/Math will favor this over the aspects that get grouped into total programming, which often don't help provability.
Re: Functional programming should be the future of software
#210Earlier quoted context omitted.
There is nothing magical about functional programming, it is the elimination of non functional programming features that is important. A language that can do either is exactly the wrong thing, from the perspective of TFA
> There is nothing magical about functional programming How come not? I read that F# gives you compiler exception when you didn't match all possible values. Or when you didn't handle __maybe__ cases. JS even doesn't mind comparing strings with ints and incorrectly summing them together and not throwing a runtime exception less alone a compiler complaint. "1" == 1 true "1" + 1 '11'
I view this as one of JavaScript’s myriad flaws. Adding “1” to 1 is nonsensical and the result of “11” is even more so.