Should Functional Programming Be the Future of Software Development? - Slashdot

Posted by EditorDavid

• ›

  No (Score:3, Insightful)

  by Anonymous Coward on Sunday November 13, 2022 @12:38PM (#63047829)

  • 1 hidden comment

  • Re:

    I agree. I was on board until I came across this nonsense:

    That's not a description of a variable, that's a constant. Apparently someone doesn't understand the meaning of "variable".

    • 1 hidden comment

    • Re:

      I think they managed to somehow mess up the description. The point should be that variables cannot be modified, you just create new variables. X=1; Y = X+1; Z = function_foo(Y), etc. And that function should return the same thing for same parameters. Though I think that is for ideal functional languages, they all need to deal with side effects in order to talk to the real world.

      • Re:

        And, once again, what you are describing is a constant, not a variable. You don't seem to understand the meaning of the word "variable" or why they exist.
        
        The whole point of a variable is that you have something whose value changes or is expected to change, and you need to report the current value:
        
        The current outside temperature
        The speed of your car
        etc...
        
        A variable that does not change is pointless and useless. The fact that stupid programmers do stupid things doesn't eliminate the need for var

        • Re:

          Well, there actually is a difference between constant and immutable variable - it's whether it's evaluated during compile time or not. Constants are more or less just inlined into the code by compiler. Immutable variables (e.g. in Rust) actually have a location in memory, so you can have references to it.

          • Re:

            An immutable variable is no longer a variable.

            Stop ratfucking words to try and make them mean what you want them to mean.

        • Re:

          Fortunately you're posting as AC, because you're just making yourself look ignorant. Yes, getting your head around FP is hard because it's rooted in mathematical principles that are alien to most programmers. You have to get beyond 'I do not understand this, so it must be wrong' though.

          • 2 hidden comments

          • • Re: No

              The difference between a constant and an immutable variable, is that a constant is known at compile time, where an immutable variable is not known until runtime. Most of the time it's pointless to make any distinction between a regular variable and an immutable one.

              • Re: No

                Ah...but what if your immutable variable needs to change values during runtime?

                Nevermind, I know the answer:

                Either you give up on mathematical purity or you run up stack usage on your real imperative oriented hardware to preserve the mathematical beauty...until you run of of memory for something that in the imperative paradigm could fit onto a z80 with 128 bytes of ram.

                • Re:

                  Typically that means you're in a loop, which is something else that functional languages don't do much. They're much more likely to just invoke themselves recursively, at which point they're declaring a new variable with a new, up to the moment value, and acting on that.

                  • Re:

                    Recursion is looping, and running out of stack is running out of memory.

          • • It does vary, exactly once

              It does vary, exactly once when it goes from unset to set to its new and final value.

            • Re:

              FP variables are const by default, and have to be explicitly made mutable.

              Your code is actually a perfect example. In C:

              const float X = Get_Current_Spped();
              Display(X);

              In an ML-style FP language:

              let X Get_Current_Spped() in
              Display(X)

              In both cases, you are not changing X - you are creating a new X every time, keeping the previous X unchanged.

        • Re:

          And thus demonstrating a spectacular misunderstanding of reality. The temperature doesn't "change". It is measured at a different value at one time index and another time index. For a given moment in time, the temperature _was_ the temperature. It didn't become different when indexed correctly. Your model of reality is, as with most programmers, the fundamental problem. it's missing at least one important axis. When you philosophically correct that missing axis, you end up with an immutable model. Because

        • Re:

          Even a single class in programming language theory (particularly lambda calculus) can clear up your confusion. In mathematics "variable" refers to a symbol that can represent a value, usually brought in from outside of the function. F(x) for example. x is a variable that is set to the value passed to the function and represents that value all throughout the function's body. Assigning to x makes a new variable; it does not mutate the original variable. This may seem to you to be a trivial distinction.

      • Re: No

        I think that -- bottom line -- type hierarchy is evil. C++ programmers will shit bricks over this comment, but it's just fucking true. Inheritance in general is just a giant source of bugs, and makes your code a lot less readable.

        I'm sure angel o' sphere will give us all an example, using linked lists, of why I'm wrong, but his level of expertise is so out of this world that it simply doesn't belong in this world.

        • Re:

          C++ has a weak type hierarchy. In most functional languages with strong type systems, entire computations are typed. Use a function incorrectly with respect to its type and the compiler chucks out a hairball.

        • Re:

          Funny part is, FP languages are heavily typed these days. LISP and Clojure are not very popular at all. Also, I think the real problem is that in OOP languages we try to make all typing work through the idea of OO. Most types are not a thing that belongs in a heirarchy. However, there are plenty of things that do. The problem is trying to make 1 mathematical typing framework handle all the various ways that programmers will want to use types. It is the idea of the "one true thing" that is the problem.

      • Re: No

        One of those side effects is the complexity of multiple variations of functions needed to return a different value of an otherwise identical function. Also, there's the issue of the misleading claim that you spend less time programming. You do, but it's because it takes 10x as long to figure out what you're writing.

      • Re:

        "No" is how I'd answer if someone asked me if you knew what the word "variable" means.

        variable/verb()l/
        1) not consistent or having a fixed pattern; liable to change.
        2) able to be changed or adapted.
        3) an element, feature, or factor that is liable to vary or change.

        constant/känstnt/
        1) a situation or state of affairs that does not change.
        2) remaining the same over a period of time.
        3) a number or value expressing a relation or property which remains the same in all circumstances

    • Re:

      The author is supposedly the CTO of a software company with 40 years of experience. And yet here is his ridiculous example:

      In the formula y = x2 + 2x – 11 where does it change the value of X? It doesn't. This is a strawman argument of the worst kind. It's not even a strawman, it's just... weird.

      • Re:

        The reasons put forth in the article utterly fail to address the root causes of all the complexity being lamented here. The language isn't what is at-fault, it's the demands made by the clients.

        Companies need to produce software quickly, or their clients will buy from other companies. Producing software quickly means taking a profit-in-the-short-run attitude. Engineers hate this with the passion of a thousand burning suns. It is in their DNA to take a long-term view and to want to write code that is wel

        • Re: No

          While I agree with everything you write, the big question would still remain whether functional programming really clashes with quick delivery and time-to-market. Today it is - unfortunately imho - still a bit of a fringe phenomenon and people who pick it up are usually driven by a desire to write better code which can lead to the impressions you mentioned. But I also think that if it were taught more widely, it would have many benefits without noticeable drawbacks. Yet, in the end, it probably won't happen

      • Re: No

        It's exactly what tends to happen in concurrent programs with mutable state. Another thread changes the value of x during the evaluation of the expression, you can fix it with locking, or just realize that immutable state is automatically thread safe.

      • Re:

        The value of X doesn't change in the formula, but it may be changed in another piece of code. For example and event callback or an ISR or another thread.

        It is not a straw man argument, just an attempt to explain something to you that failed.

        Instead of X, call the variable clockCount. Hopefully now you can see how the count might change during the Y computation.

      • Re: No

        Multithreading could change x during evaluation, and that would be a bug.

        There are other ways to avoid that than immutability, of course, but that would do it.

    • Re:

      So the variables of mathematics are now constants?

    • Re: No

      Thatâ(TM)s what other languages call immutable variables. For example in Swift, a mutable variable must be set at least once before being used, an immutable variable must be set _exactly_ once, in both cases in a way that the compiler can verify. Obviously an immutable field can have a different value each time a method is called, and an immutable object member can have a different value in each object, so âoeconstantâ is not appropriate in many cases.

    • Re:

      Yes, I laughed when I read that.

      He used the word "variable", but I do not think that word means what he thinks it means...

  • Re:

    You need a while to grok it, but once you do, FP is awesome.
    And you can use most of its principles in OOP languages like Java and C#, though FP really starts to shine once you use a pure FP language like Haskell.

• This idea comes up over and over again. Every time some n00b discovers functional programming.

  Everyone should know what functional programming is and learn how to use it. The methods and ideas help when using any programming paradigm. It is not the answer for everything though. Not even most things.

  • Re:

    Agree. Anyway, the answer to everything is 42 as far as I know.

  • Re: You're not the first to ask this

    Most mainstream programming languages are slowly drifting towards functional programming anyway. Look at the release notes for the new version of c# released just this week. Improved pattern matching (switch statement), and "generic math" (exemplified by a monoid implementation). Other recent examples are immutable record types, type inference and lambdas. They should just take the plunge and give us typeclasses. Java, python and typescript all moving in the same direction.

• What is this Friday the 13th? This shit just won't die.

• Why (Score:4, Insightful)

  by Tailslide ( 1722096 ) on Sunday November 13, 2022 @01:00PM (#63047887)

  It seems like there is always a lot of wishful thinking going on in software development that goes something like this: If I can find the right magical technology, I donâ(TM)t have to hire expensive people with skills and experience and somehow my project wonâ(TM)t turn into a giant mess.

  • Re:

    Yes. It is the same thinking that is driving the development of "Artificial Intelligence". Although there are many legitimate uses for A.I., the primary driving force is pointy-haired bosses dreaming of a glorious A.I. future where all the work is done by A.I.-powered robots and they no longer have to pay any employees, allowing them to keep all the money for themselves.

    • Re: Why

      I remember gleefully being told by a city manager how their upcoming peoplesoft implementation meant they would no longer have to employ software developers⦠30 years ago. I donâ(TM)t think his plan worked out. Some things never change.

  • Re:

    I don't think you read the article, then.

    The author doesn't think this will take no effort and zero training. He says it requires a shift in thinking, and there's a steep learning curve.

    But he does think the tradeoffs are worth it. That you can write better code with fewer errors if you eliminate a huge source of the errors.

    Maybe he's right; I'm not convinced. Storing state is awfully handy. Mutating variables usually makes more sense intuitively than modifying a stream of data in flight so you can pass it

    • Re:

      I find Python generator expression to be very intuitive and allow a more functional approach to programming over imperative. A lot of times I can completely eliminate the need to store state for some tasks. Plus closures and lambda expressions have a real place. We can all benefit from functional principles and constructs without having to be purists. I have yet to understand how a monad is used.

• Obligatory xkcd, https://xkcd.com/297/ [xkcd.com]

  Functional programming languages definitely have their use cases, but the article in this case is not all that convincing to use that *everywhere*.

  • Re:

    well, if it weren't for the headline! betteridge rarely fails.

    i usually rtfa, but with these headlines... there is no point in wading through any ramblings attempting to justify such an utterly stupid headline, the author has made it bloody obvious from the start that he has no clue whatsoever about software. 99.999999% probability of bullshit that most likely isn't even funny.

• How do they propose to deal with state changes in the real world? For instance, you have a computer running a web server with database, attached to 1000 parallel clients all firing requests at it.
  • 1 hidden comment

  • • Re:

      That may be true, but if functional programming is the "future of software development" shouldn't it be capable of running 100% of the tasks ?

    • Re:

      I think you meant to post that in the Comedy Forum on Reddit.

      • Re:

        r/AccountingDepartment

      • Re:

        Well I certainly ROFLOL'd when I read that.

  • Mutable state for those clients is trivially handled in a functional paradigm by capturing the lambda monoid in a Kleisi triple [wikipedia.org] to bind the combinator in a right-identity so it can be used in a continuation-passing style of programming.

    (/s, the jargon is all from FP but probably used incorrectly in that sentence)

    • Re:

      BINGO!!!1!eins

    • Re:

      You forgot to mention functors.

    • Re:

      Ah, yes, of course. Thank you for clearing that up for us!

  • Re:

    Not sure what your concern is, but there are very many real-world examples to choose from. Look into any functional programming language for web server and database examples. A few specific ones that might be worth a look are the datomic database, the clojurescript "om" framework, the react "redux" state management framework, and more generally the notion of "single atom state".

    • Re:

      I have no concern, I'm just curious how it would work, since I have never done real world functional programming like that.

      I was hoping someone could explain in a few lines.

      • Re: real world

        In the real world, if your application code has mutable state, it's almost always a bug. Your state should be in the database (or a dedicated caching layer), otherwise it will either not be visible to the other clients when it should, or writeable by other clients when it shouldn't. Put it in the database, and use transactions.

      • Re:

        Ah, gotcha. A slashdot post is not really sufficient to introduce the topic. Typically you use immutable data structures, which are often built over a mechanism called a "path copy". Basically, your app state is stored in a data structure, and when state is updated, you create a new data structure representing the new state, using purely functional code. People often think this is slow, but it's very fast, often faster than mutable code, except in very hot loops. The bit where you update the reference to th

• A Maybe can be Nothing or Just some value. Working with Maybe s forces developers to always consider both cases.

  Couldn't get out of the summary without mixing up functional programming with type systems.

  oh, well.

  Regardless will functional programming save the world ? of course not, bad coders gonna write bad code.

  However it can help you write better code.

  I don't know how many esteemed Slashdot readers have used Standard ML, but if there was ever a language that could replace C, standard ML is it. It does

  • Re:

    It's worse than that. In my experience functional languages tend to be harder to read and understand than more ordinary languages. They also tend to be more poorly documented, and worse at being documented. They aren't up in the "obfuscated C" category, because they aren't trying to be there, but they have natural skills in that direction.

    There's a subset of use cases where functional is a good fit, but it's a rather small subset. Even Lisp and Erlang couldn't manage as pure functional languages. List

• Some things that rely on deterministically synchronizing multiple distributed whatevers require a global shared state.

  So do multithreaded/multiprocess applications packed into a finite amount of computation with hard dependencies between different portions of different tasks.

  Sometimes a global shared state is easier to understand. Some safety critical stuff is defined in terms of a state transition diagram. I suppose it's possible to implement that in a purely functional paradigm....just like it's mathemati

• I noticed the trend of increasing complexity around the year 2000 and have been horrified by surprisingly increased measures each year, ever since.

  It truly seems that most frameworks, libraries, and tools nowadays make work much harder, less reliable, and slower. At first, I migrated form C to C++ and became a big advocate of OOD and OOP but gradually came to accept that it failed in every objective. I do like OO in Javascript better and think it gives clues as to how a far better mechanism could be created. The.Net library is also overly complicated and breaks backward compatibility with each major upgrade. Strict data types and objects as parameters make for huge headaches and complexities trying to tie things together, even in the same language. How many kinds of null do you have to work with in C# and T-SQL for example? many.. why?? Why do I have to hunt through various class files to find all the required parameters to a method and ready an encyclopedia to understand what it returns?

  I strongly blame the tendency of trying to make other coders better by restricting them, in various ways. Why strict data types? Why private/public/protected, etc. classes?

  On the other hand, I don't advocate functional languages like GO, as the solution, even if it is a lot better to work with. Safe strings are great and its approach to errors and multiprocessing are great (although the V language has an even better approach to dealing with exceptions and Rust has a terrible way).

  I think Javascript was a stroke of accidental genius. It was supposed to be a simple learning language without strict types and complex classes/interfaces, etc. Those things the inventors of Java throught we advanced and lead to better software were huge mistakes and the opposite is the direction I wish we would go. In 99% of cases, the compiler will be better at determining underlying data types than you. Reflection on data structures allows for quick and easy checking of what objects look like and, can even allow you to behave different based on it, leading to easy to produce backward compatibility in libraries, among other things. Also, you don't need lambdas with anonymous functions and functions being passable objects. You have reusability in that an object's "this" will refer to whatever its under. Furthermore, it's much faster executing than classical OO that has to do gazillions of memory allocations when instantiating a class -- not to mention the underlying factor code required to do that bloating your binary.

  I think the best language would be similar to Javascript with aspects of ADA, GO, and V. ADA's ability to add constraints on data types for safety makes sense, as an option but not the rule. As a rule, it should be typeless (determined intelligently by the compiler). It should use V's method of exceptions (implicit in the return from any function), and GO's approach to multiprocessing and small vocabulary (also true with V) -- but get rid of:= (it's ugly). And objects should be as they are in Javascript (vastly superior to C/C++/java/GO/V structs and so on). However, we could improve in some ways. For example, cascading prototypes and make every function a true and complete object and vice-versa.

  If you just go functional like in GO, then you will come to realize that its just objects in the form of packages. In effect, a different syntax without inheritance, etc.. just really basic object-based, in effect... not object oriented but still. Packages are the most annoying part of GO, for me. Inflexible weak structures are the most unfortunate part, for me. Everyone has opinions, of course.

  Above all -- a language should make your work easier... and reduce your work... lead to fewer bugs. Strictness and authoritarianism sound like they would do that but in practice, they do the opposite.

  • 1 hidden comment

  • Re:

    As a rule, great projects never start out by someone thinking "I'm going to make a great project"

    • Re:

      Corollary: great projects never start (or end) with javascript.

  • Re:

    Are you sure you've ever actually used.NET? This couldn't be father from the truth. Microsoft is terrible at many things, but backwards compatibility is one of their few strengths. New.NET versions are extremely backwards compatibility. You could have a.NET Framework 1.0 program written in 2002 and compile it and run it with the latest bits with no problem whatsoever.

    Again, no idea what you're talking about. C# and T-SQL both have exactly one null type. On the contrary, the language that you claim to enj

    • 1 hidden comment

  • • Re:

      Don't disparage the boomer. I'm a boomer too. I was a hotshot programmer in the 80s. C, C++, Pascal and my favorite Assembly.
      After retiring I decided to try some software/hardware projects to amuse myself. At first I thought software development had gotten overly complicated. I didn't think any real progress had been made.
      Fast forward a bit and I see there has been progress. Just working with Python and ROS, you can actually enjoy writing code for your robot. The IDEs have improved too. That said, I

  • Re:

    I noticed the trend of increasing complexity around the year 2000 and have been horrified by surprisingly increased measures each year, ever since.

    Agreed.

    ...I don't advocate functional languages like GO...

    Ummm... go's not a functional language - it's imperative.

• No single programming language, or programming paradigm, is the best choice for solving all problems. There's a reason most operating systems and device drivers are written in C, despite fifty years of null pointer and buffer overflow errors.

  "Side-effect free" and "functional programming" are different concepts, and one does not imply the other. Many LISP dialects allow side-effects like setting a value in an array. And many languages with an imperative core allow programming in a functional style, taking Kotlin and Ruby as just two examples.

  Furthermore, "no side effects" isn't actually what I want in a programming language. If it doesn't have any side effects, why am I running the code? Data needs to be saved, logs need to be written, remote APIs need to be called, payments need to be debited and credited, emails need to be sent. I don't want a programming language that makes it difficult to produce a side effect, I want a programming language that makes it easy to reason about all the side effects my program produces. Functional languages may or may not do a good job of that, just as some imperative languages are better or worse at that.

  The solutions to the author's problem of "increasing complexity, longer product-development times, and greater fragility of production systems" are to separate components (e.g. via microservices) so that it's easy to reason about, test, deploy, and fix failures in an individual piece of the overall system. Given the choice of a million lines of C++ code split into 200 independent services or a million lines of Haskell in a monolithic binary I'll take the -crab juice- C++ any day.

• Functional principles are good to be aware of and to take time to consider how they apply to the current scenario if reasonable.

  However, like everything else, it's not the inherently better way, and in some cases trying to go functional can be maddening. The caller ends up having to own a lot more of the logistics, and while that makes for some more disciplined resource handling and fewer surprise side-effects, it also makes the task frequently far more tedious to carry out. Sometimes it's very awkward to burden the caller with a concern that normally the implementation would transparently handle, and it's hard to avoid that scenario in an absolute functional programming strategy.

• • Re:

    So Quake was the original Functional Programming Shooter?

    • Re:

      Probably Wolfenstein.

• I've been programming in various functional languages for over 30 years. Depending on the application area they can have big advantages or be a real pain to work with. Proponents have pushed a number of features over the years that continually resurface in slightly different forms, two of which are their suitability for large scale concurrency and formal correctness proofs. Both of these are possible using non-functional languages. I would still use a functional language, or at least use the functional feat

• ... type-safety, memory-safety, and all the other goodness that makes it very hard for me to overlook something dangerous.

  Except of course in the real world sometimes you need to "be unsafe" for the sake of efficiency, and sometimes there's no useful provably-correct algorithm to solve a given problem.

  So how about this: "By default" use languages and language features that make it easy for the computer to enforce various safeties and which make it easy to do a proof-of-correctness if one is possible.

  BUT ha

• • Re:

    This was a good followup to that paper: Out of the Tar Pit http://curtclifton.net/papers/... [curtclifton.net]

• I wish the industry would get over this "billion dollar mistake" nonsense. The concept of a nothing/unknown value must exist to model the real world. Whether you call that null or Maybe is meaningless. The only real difference I've seen in language implementations is whether it is an error to call method on a null value or not. There are pros and cons to having it both ways.

  The past decade has seen several major languages either be non-null by default, or introduce nullability tracking on type of their existing type systems. As far as I know, there have been no studies indicating major reduction in bugs or development time from introducing these features.

• You donâ(TM)t need functional languages to avoid null pointers. Swifts optional values do this very efficiently. And they allow everything to be optional. And since optionals are just syntactic sugar for an enum, for every type we can have any number of different cases.

  • Re: Null objects

    Most advances in mainstream programming languages these days are concepts pilfered from functional languages. Optional is just Haskell's Maybe.
• What does the "optional" pattern has to do with functional programming? They are two distinct topics but the summary seems to conflate them together.

• We have Excel, Question answered, Problem not solved.

• function AnswerToTheQuestionInTheHeadline()
  {
          return false;// Betteridge's algorithm
  }

  • Re:

    Code review nit: The function name would be clearer if reworded to be descriptive of what the function does: e.g. "getAnswerToHeadlineQuestion"

• I worked with a team that wrote in Scala. Did they have less bugs than other software? Not really.

  One data point, but the promise of functional is like the promise of anything: it depends how you use it.

• That should have been in the summary.
  A functional programming book author thinks it should be more popular.
  Most of us who tried them would agree.
  PureScript, which his book covers, has a reputation as an approachable Haskell.

• First of all, it's a click-bait for a guy to sell his book. More over, he even is trying to promote its own functional programming language! Because, well, Haskell has its limits.
  
  Second, his software is delivered to governmental agencies, that's explain a lot of things.
  
  Third, functional programming is one of many paradigms.
  
  There's no paradigm that suites all types of situation. It's the experienced developer who knows when to use FP or SP or OOP or whatever.
  
  Functional programming is not the pana

  • Re:

    Forgot to mention that another justification given by the author to use Functional Programming is that has its roots in Math:

    Just that reveals that the author is putting up a shop for his products. He is doing what the social sciences did in the 19th century to be treated seriously, use the jargon of the hard sciences.

• This is a polarizing spin. The real point would be that everyone has something to learn from FP, not that it's conquering the world.

  I'm personally more productive in a functional style. That's as far as I'll go: it's my personal preference... Would never stretch the argument to "the future of software".

• I've seen many projects where object oriented programming was simply banned, pure c, and then every function's first argument was a structure, basically a pointer to "this".

• The authors believes that GOTO disappeared in the 1960. He is deeply wrong. Even in Go, you will find a GOTO (check the keywords). CS Teachers, thanks to Dijkstra, just avoid to teach it.

  But you have also many variations on the GOTO theme (jumping elsewhere in the code)
  In Rust, there is no GOTO but you will find loop labels.
  In many languages, including purely functionals, you will find exception handling that happily setjmp/longjmp in the stack.

• Having never actually used a functional programming language for anything major, but having studied them I can say "sometimes". I think I became a better programmer from understanding a bit about functional programming languages and what they're trying to achieve. I adopted some constructs that might be considered more functional, such as a preference for C's ternary operator where it makes sense as opposed to if-else and assignments.

  However, another thing you find in functional programming is that becaus