Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror
Programming IT

Erik Meijer: The Curse of the Excluded Middle 237

Posted by samzenpus
from the almost-good-enough dept.
CowboyRobot (671517) writes "Erik Meijer, known for his contributions to Haskell, C#, Visual Basic, Hack, and LINQ, has an article at the ACM in which he argues that 'Mostly functional' programming does not work. 'The idea of "mostly functional programming" is unfeasible. It is impossible to make imperative programming languages safer by only partially removing implicit side effects. Leaving one kind of effect is often enough to simulate the very effect you just tried to remove. On the other hand, allowing effects to be "forgotten" in a pure language also causes mayhem in its own way. Unfortunately, there is no golden middle, and we are faced with a classic dichotomy: the curse of the excluded middle, which presents the choice of either (a) trying to tame effects using purity annotations, yet fully embracing the fact that your code is still fundamentally effectful; or (b) fully embracing purity by making all effects explicit in the type system and being pragmatic by introducing nonfunctions such as unsafePerformIO. The examples shown here are meant to convince language designers and developers to jump through the mirror and start looking more seriously at fundamentalist functional programming.'"
This discussion has been archived. No new comments can be posted.

Erik Meijer: The Curse of the Excluded Middle

Comments Filter:
  • by jeffb (2.718) (1189693) on Sunday April 27, 2014 @07:20PM (#46855593)

    "The examples shown here are meant to convince language designers and developers to jump through the mirror and start looking more seriously at fundamentalist functional programming."

    Or, perhaps, to acknowledge that it's very hard to do anything useful without side effects.

    You can write beautiful, elegant, purely functional code, as long as it doesn't have to touch a storage system, a network, or a user. But, hey, other than that, it's great!

    • by jythie (914043) on Sunday April 27, 2014 @07:29PM (#46855625)
      I take this as a good example of why we should not strive for universal languages to use everywhere. Functional languages are really useful in their domains, while procedural and OOP languages are really useful in their domains. Language designers, or maybe just programmers who do not want to learn more then one language and thus find the One True Language, keep trying to extend languages to handle everything.
      • I take this as a good example of why we should not strive for universal languages to use everywhere.

        I take it as a good example of how programmers don't know what "excluded middle [princeton.edu]" means.

        • I take it as an amusing commentary on much of the functional programming debate. "If we assume that whether to use functional programming is a binary choice, then we can't decide to use it in some places and not others, because the middle is excluded in a binary choice!"

        • by rwa2 (4391) *

          Well, would you rather be faced with a false dichotomy, or would you like to have other options?

    • by catmistake (814204) on Sunday April 27, 2014 @08:04PM (#46855785) Journal

      You can write beautiful, elegant, purely functional code, as long as it doesn't have to touch a storage system, a network, or a user. But, hey, other than that, it's great!

      Speaking as an sysadmin, sounds like Heaven.

      The other way to make code safer, of course, is to eliminate the programmers.

      • by PPH (736903) on Sunday April 27, 2014 @08:59PM (#46856001)

        Speaking as a sysadmin [wikipedia.org], you should have said, "eliminate the users."

        • you should have said...

          No, I sort of meant what I said and not really as a joke. And I am kin to BOFH, in that I'll come down hard on users, but only when they fuckup, and I guess that's where we diverge, also, my skill set is much more narrow, unfortunately.

          To illustrate the point about programmers, we need to take a little walk, because I like programmers... they are my compadres.

          I really love that Superuser forum site and the others like it ("how do you do x under these circumstances on some platform?") where someone posts

      • by Belial6 (794905)
        You can simulate the exact same effect by just quiting your job and never working in the field again.
      • No safer (Score:5, Funny)

        by SuperKendall (25149) on Monday April 28, 2014 @12:13AM (#46856705)

        The other way to make code safer, of course, is to eliminate the programmers.

        You would think so, but as a programmer I can assure you that over time code changes itself.

        No way *I* wrote that...

        • The other way to make code safer, of course, is to eliminate the programmers.

          You would think so, but as a programmer I can assure you that over time code changes itself.

          No way *I* wrote that...

          Of that I have no doubt. And I know it couldn't be your fault. (And the set up goes like:) Its more likely due to cosmic ray's, man, and eddy's in the space-time continuum!

    • by fractoid (1076465)

      Or, perhaps, to acknowledge that it's very hard to do anything useful without side effects.

      Exactly. Outside of an ivory tower or some very niche applications, everything we do with computers inherently has side-effects. Trying to pretend otherwise just leads to elaborate castles in the sky.

      • by Anonymous Coward on Sunday April 27, 2014 @09:50PM (#46856229)

        Nobody is trying to pretend that there are no side effects you idiots. The point is that there are a lot of benefits that come when you clearly separate the parts of the program that have side effects from those that are pure and referentially transparent.

        It's trivial to ask a user for input, send packets across the network, query a database in Haskell and various other purely functional programming languages.

        • Re: (Score:2, Funny)

          by fractoid (1076465)
          ITT: Functional language fanboys get defensive.
          • You start off with ad-hom (Ivory Tower...) and wonder why people get defensive. Frankly, I think the claims of FP are massively overblown and Haskell isn't going to take over the world. But I can see that on it's relative de-merits, not by aking up straw-man attacks like you.

            • by jbolden (176878)

              FP has already taken over the world. Have you looked at what's happening with compilers at this point. Your imperative languages are more and more interpreters running against functional engines (though running against very low level imperative code).

      • by Pseudonym (62607)

        So you didn't read TFA either, then?

        • by timeOday (582209)
          Well I read it, and I genuinely do not see anything new in it. "Use monads." "Functional programming didn't fail us, we failed it. It's be best thing since sliced bread and the only reason it's not used much is because people are too lazy and uninformed to use it. If only they knew." I'm sorry, but that is (still) not it.
      • by rtb61 (674572)

        Well, mostly functional programming does work technically it is working right between your ears. Consider many programs running simultaneously, all tackling the same problem in different and or the same way, the outcome is the average result of not only the outcomes but the strength of the outcomes. Why useful? It allows the greater investigation of methods and outcomes and it allows for the reality of bumps on the heads and other maladies that damage the hardware the programs run on, which in the digital

    • by rabtech (223758) on Sunday April 27, 2014 @10:23PM (#46856369) Homepage

      Or, perhaps, to acknowledge that it's very hard to do anything useful without side effects.

      You can write beautiful, elegant, purely functional code, as long as it doesn't have to touch a storage system, a network, or a user. But, hey, other than that, it's great!

      This is a huge misconception about functional programming, one that I used to have myself.

      With a functional programming language, you can have side effects, you are just forced to be explicit about those side effects with specific language features in specific places.

      Basically functional programming requires you to "opt-in" to side effects only where necessary.

      Traditional imperative programming requires you to "opt-out" by taking huge steps to enforce immutability, generating mountains of code to accomplish any task because the compiler doesn't help you.

    • The solution is to use functional style for high-level control flow, and imperative style for low-level (optimized) functions.

      There. That wasn't so difficult.

      • by Twinbee (767046)
        With an infinitely fast CPU, would it make sense to use functional style even for low-level control flow?
        • No. With an infinitely fast CPU, we would let the computer do the programming :)

          • by Twinbee (767046)
            Seriously though, without AI, I was just wondering if the benefits of not using functional programming for low level functions had anything to do with speed, or if it was an ease of code writing or some other issue.
            • Yes. With increasing CPU speed, it makes sense to sacrifice "performance" for ease of programming.

              • by Twinbee (767046)
                Interesting. Would you say (again assuming an infinitely fast CPU) that for maximum ease of programming, that it would be best to write code in an entirely functional style, or use a mix of functional and traditional imperative programming?
              • by gstoddart (321705) on Monday April 28, 2014 @01:45PM (#46861675) Homepage

                Yes. With increasing CPU speed, it makes sense to sacrifice "performance" for ease of programming.

                I worked with a guy who used to say that.

                He wrote shitty, un-maintainable code which he thought was elegant, and which in practice was garbage, full of ridiculous assumptions, and giant inefficiencies all in the name of him being able to invoke something in as few lines of code as possible, or without consideration for the cost of his framework. Half of his code went through massive setup tasks every time it was invoked or naively did something assuming it wasn't expensive. Over and over and over again.

                He said you should write first, and the optimize later. By the time we realized his code was so slow as to be unusable, he had painted himself into a corner, and there was no way to optimize his code except to get rid of it.

                Sometimes the things passed off as "ease" of programming is a thinly veiled decision to use known terrible methods in the expectation they're prettier.

                In my experience, some of these claims don't produce good code. They produce things the coder believes to be pretty, but which in practice is quite a mess.

                I've yet to be convinced you should start writing your code in a way you know is inefficient because your belief in your elegant solution, which is anything but. I've seen an O(n^2) algorithm called O(n^2) times, all because it was "cleaner" code, and the code assumed everything was a zero cost operation (or had hidden all of the aspects of that, so you don't find it until later).

                Performance is a real thing. I lament that people have now decided it's irrelevant to consider it.

        • by jbolden (176878)

          I don't think so. FP is good when you need to do complex things with simple state issues. If you need to do complex things with state and simple things to the data FP are just bad imperative languages.

    • by jbolden (176878)

      You can write beautiful, elegant, purely functional code, as long as it doesn't have to touch a storage system, a network, or a user. But, hey, other than that, it's great!

      You write beautiful elegant functional code for the algorithms and then messy imperative code that invokes those algorithms for stateful operations. If you do it in the functional language itself Monads work well. Otherwise you just invoke the functional code as a library.

  • by smoothnorman (1670542) on Sunday April 27, 2014 @07:27PM (#46855609)
    to interact with an imperfect world one needs monads. to have monads is to compromise functional programming. ipso-facto-quod-splut: i always did rarther fancy Fortran. (hsst: don't tell anyone, but Forth is the -only- way to go, (and by 'go' i don't mean "Go" (or "Dart")))
    • IF you read the article, you'll find that his advice for doing functional programming without compromising it is to use monads.: but then I always did fancy reading the article.
    • by Pseudonym (62607)

      to have monads is to compromise functional programming.

      [citation needed]

  • Wow (Score:4, Insightful)

    by xdor (1218206) on Sunday April 27, 2014 @07:34PM (#46855657)

    After programming for 16 years, I finally realize I have no idea what I'm doing. I'm so glad these people are out there to point this out.

  • by Anonymous Coward on Sunday April 27, 2014 @07:42PM (#46855687)

    what does Bennett Haselton think about this topic?

  • by quietwalker (969769) <pdughi@gmail.com> on Sunday April 27, 2014 @08:12PM (#46855819)

    I remember he used to lament the fact that we had to use computers to run programs, because they were always so impure. Hacked up with model-breaking input and output considerations. He loved APL. Had us write our programs as math equations and prove that they had no side effects. On paper. Step by step, like how elementary teachers used to have you write out long division. He was a computer scientist before they HAD computers, he'd point out.

    To be fair, APL was a wonderful language, and perfect so long as you didn't want to actually /do/ anything.

    Well, that's unfair. As long as you meant to do a certain type of thing, these languages work out fairly well. The issue is the old percent split issue you normally see with frameworks and libraries - by making it easy to do some percent, X, easily, you create a high barrier to performing the remaining percent, Y. The problem with adhering to pure functional languages is that Y is not only high, it's often the most common tasks. Iterating, direct input and output, multi-variable based behavior, a slew of what we'd call flow conditions - these are very hard to do in a pure functional language. The benefit you get is far outweighed by the fact that you could use C, or the non-functional aspects of OCaml, or some other so-called 'multi-paradigm' language to fix the problem in a fraction of the time, even with side-effect management.

    Then, have you ever tried to maintain a complex functional program? There's no doubt you can implement those Y-items above. The problem is that it makes your code very specific and interrelated as you're forced to present a model that captures all the intended behaviors. It's a lot of work. Work that will then need to be repeated each time you need to make additional changes. Adding a mechanism to - for example - play a sound at the end of a processing job based on the status - that's a line of code in most languages. Not so in a functional language.

    The problem here isn't the oft-cited 'Devs just have to think of things differently, and they'll see it's better.'. It's more basic. It's simple throughput. Functional languages might be a theoretical improvement, but they're a practical hindrance. That, in a nutshell, is why they're not in common use in a corporate environment, where "value" loses it's theoretical polish and is compared to hard metrics like time and cost for a given quality.

    • Re: (Score:2, Interesting)

      by msobkow (48369)

      I agree completely, and have experienced this problem with Erlang. We got most of a complex system built at my last job over 2 years using Erlang for the servers and data I/O services.

      Then we came to the scheduling algorithm, which had originally been prototyped with Visual Basic. It did the job, and had for many years.

      But have you ever tried to express an n-length array and process it in a functional language?

      In the end we had to cancel the project and blame the fellow who'd made the decision to u

      • by Pseudonym (62607)

        But have you ever tried to express an n-length array and process it in a functional language?

        You're going to need to expand on this. Pretty much every functional language I know (and I know a lot of them) has support for arrays, either in the language or in a library.

        • by msobkow (48369)

          Erlang expressed arrays as lists internally. Any obvious implementation sucked donkey balls for performance.

          • by Pseudonym (62607) on Sunday April 27, 2014 @09:23PM (#46856109)

            Erlang expressed arrays as lists internally.

            Actually, it uses a 10-ary tree, which has O(log n) lookup, update, etc with a pretty low constant factor. Or, at least, that's what it does now.

            It doesn't have to be this way. Haskell has O(1) arrays, but they live in a monad (either ST or IO) if they're not read-only. Plus, of course, Haskell has lazy evaluation, so read-only arrays are not necessarily as read-only as you might think.

            Without knowing more details (and since I'm just some random guy on the Internet, you probably don't care enough to give details, so that's cool) it's difficult to say if you really needed imperative arrays for your algorithm, or you only thought you did because that's what the Visual Basic prototype used. Most people don't learn pure functional data structures in their undergrad classes, so they not always the solution which springs to mind when you have a problem to solve.

          • by jbolden (176878)

            A0 = array:new(10).
                10 = array:size(A0).

            Will give you a fixed sized array.

            ____

            If you need a mutable array datatype you just create a monad and do it in there. Which incidentally has been done for Erlang as opensource libraries.

        • by msobkow (48369)

          And I am far from an Erlang expert. Therein lay the problem. The only expert at the language who recommended using the language was the first one to fuck off and run away when the going got tough and it was too late to change course to a language the whole TEAM was familiar with, like Java or C#.

      • by gnalre (323830)

        Sounds more like a loss of faith rather than a language problem. I have sympathy, but if you are not an expert in a domain, whenever a problem arises the 1st reaction is to go back to safe ground.

        Unfortunately while all programmers know imperative languages, few are taught functional techniques when first programming. Until that happens it is unlikely that functional languages will ever be much more than a sideshow despite there obvious advantages because there are very few problem domains that can only be

        • by jbolden (176878)

          I suspect the mixed paradigm languages will make functional techniques more popular. Heck they are having to introduce them into Java now they've become so popular. The .NET compiler is all functional. Javascript, Scala, Perl6, Ruby... are mixed paradigm. I think the change is happening.

  • Not really (Score:4, Insightful)

    by phantomfive (622387) on Sunday April 27, 2014 @08:22PM (#46855865) Journal
    I use function techniques even when I'm using Java or C. Writing functions that have no side effects is useful and achievable, even when the language doesn't strictly enforce it.

    Furthermore it can be mixed with imperative, or even object, programming. It's a useful technique for minimizing bugs.
  • by RedMage (136286) on Sunday April 27, 2014 @08:47PM (#46855967) Homepage

    I'm not an expect in functional programming, but I am an expert in other (object, etc) styles. While I appreciate the functional toolbox in languages such as Scala (which I use every day), I don't really see a way to do my day to day job in a purely functional way. Others have mentioned the I/O dilemma, but I think it goes deeper than that. Functional != Efficient for many of the tasks I perform, which are rather iterative. For many of my tasks, the overhead of the functional structures required are either much more memory intensive, or impose a run-time overhead that isn't acceptable. In the end, when what I have to do is move 300 fields from one data structure to another with edits, COBOL would be sufficient...

    • by lgw (121541)

      Function programming optimizes well in a functional language. That was the point of Guy L Steele's dissertation, lo these many years ago: a tail call is just a branch. Tail recursion is just a different way to spell iteration, and a compiler should understand that.

      I enjoy blending both styles, each where it's useful, in C# with its linq extensions. All the proper list processing constructs (albeit with ridiculous names: "select"? really?), all quite efficient and lazy.

      OTOH passing lambdas around everywh

  • Bad Summary. (Score:5, Interesting)

    by thestuckmud (955767) on Sunday April 27, 2014 @08:59PM (#46855999)

    The synopsis completely misses the qualification, made in the first sentence, that TFA is discussing "concurrency, parallelism (manycore), and, of course, Big Data". Purely functional programming eliminates some significant issues in this type of programming (while introducing its own set of limitations). Meijer's point is that mostly functional programming is not really better than imperative here

    For other types of programming, mostly functional style (using multi-paradigm languages) can be very nice. At least that's my position.

  • I like to use a combination of procedural, functional, and OO. I find some things are better for different things. Restricting yourself from options doesn't necessarily make you a better programmer.

    If you want to hear a good one that will make you cringe on side effects: When I write personal code for myself that no one else will touch, I use a globally mutable systems and I have no issues. Globally mutable systems are bad in teams if you're trying to track down who's code is causing the problem beca
  • by mbstone (457308) on Sunday April 27, 2014 @09:03PM (#46856025)

    If Republicans are elected, expect fundamentalist programming to become mandatory.

  • I write lots of state machines that control external world gadgets, which input new results to my program to use to compute the next state. Consequently I can only wonder about this idea of removing side effects as: "WTF?"

    That said, I tend to write modules so that they only write to globals within that module.

    Writing an IIR filter without memory is a pretty funny idea.

    • by ultranova (717540)

      I write lots of state machines that control external world gadgets, which input new results to my program to use to compute the next state. Consequently I can only wonder about this idea of removing side effects as: "WTF?"

      newState = deriveNewStateFromDeviceMessage (oldState, message)

      (bitsToSendToDevice, newState) = getHardwareCommandForSomeAction(oldState, action)

      That said, I tend to write modules so that they only write to globals within that module.

      So, basically, if someone plugs two gadgets into the sa

  • by Pseudonym (62607) on Sunday April 27, 2014 @09:29PM (#46856131)

    Am I the only person whose first thought on reading the headline was that Erik Meijer (of all people) should know that the law of the excluded middle is not a theorem in the type theories that he advocates?

  • by Alomex (148003) on Sunday April 27, 2014 @10:22PM (#46856361) Homepage

    So Erik Meijer is arguing that mostly functional programming which is widely used in industry "does not work" and suggest instead purely functional programs which have been around for decades and gone nowhere?

    Through the looking glass indeed.

  • by Alomex (148003) on Sunday April 27, 2014 @10:25PM (#46856379) Homepage

    From TFA:

    mostly secure does not work

    Spoken like a true academic. Mostly secure does work in practice. My house is mostly secure, my car is mostly secure, my bank is mostly secure. None of them are perfectly secure, as all of them would fail to a sufficiently strong attack, but generally they do fine.

    So does mostly functional programming. It works great in practice even though it is not 100% safe but neither is functional programming once you allow monads which are needed to make FP Turing complete.

    • by Pseudonym (62607)

      Mostly secure does work in practice.

      But it doesn't scale to the truly big, which is kind of Meijer's point. Those responsible for the NSA mass surveillance system have been reassuring you of its "mostly secure" nature for almost a year now, but I think we know that doesn't work in practice.

      • by Alomex (148003)

        It does scale. I've got news for you but there are no 100% completely secure systems out there. They are all mostly secure but if I really want in I can send the Army, NSA, FBI and CIA and compel you to break the system open for me. I don't know if you follow the news, but we have several recent examples where this took place.

  • by Animats (122034) on Sunday April 27, 2014 @10:42PM (#46856427) Homepage

    It's frustrating. Functional programming is painful when you actually have to do something, not just compute some result. But the real problem is older. We never got concurrency right in imperative languages.

    Classic pthread-type concurrency suffers from the problem that the language has no idea what's locked by a lock. This problem is in C, wasn't fixed in C++, and isn't even fixed properly in Go. It was addressed more seriously in Modula and Ada, where the language knew which variables where shared and which were not. The Ada rendezvous approach was too limiting for anything otther than hard real-time, but it was on the right track.

    Java addressed this with synchronized objects. This was a step in the right direction. The basic concept of a synchronized object is that, when executing a method of the object, nothing else can affect the state of the object. Java's synchronized objects don't quite get that right - you can call out of an object, then back into it, from within the same thread. This can break the object's invariant, in that the callback function is entered while the object is not in its stable, nobody-inside state. This is a classic cause of trouble in GUI systems, which involve lots of objects calling each other through dynamically changing collections. (If some unusual order of clicks crashes a program, there's a good chance the bug is of this type.)

    The inside/outside issue for state protected by locks is a big one. This also comes up when a thread blocks. Many programs have sections where a thread unlocks a lock, blocks, then relocks the lock. This constitutes control leaving the block, but the compiler doesn't understand this. There's no syntax that says "I am now leaving this object to wait", with the language checks to insure that no internal object state gets passed to the code outside the object. The Spec# group at Microsoft (Spec# is a proof of correctness project using a form of C#) attacked this problem, and came up with a solution of sorts, but it never went mainstream. It's hard to fix this with a language bolt-on.

    Objects ought to be either immutable, synchronized, or part of something that's synchronized. Then you're safe from low level race conditions. (You can still deadlock. However, deadlock bugs tend to be detectable and repeatable, unlike race condition bugs. So they get caught and fixed.) if this is built into the language, the compiler can check and optimize. Compilers are good at catching things like a local variable being passed to something that might save a reference to it and mess with it concurrently. Humans suck at that. Machines are good at global analysis of big data.

    I had great hopes that the Go crowd would have a solution. They claim to, but there's a lot of hand-waving. They claim "share by communicating, not by sharing memory", but the examples in "Effective Go" all share memory. It's also really easy to share memory between goroutines in Go inadvertantly, because slices and dicts are reference objects. Pass them through a pipe and you've shared data and can have race conditions. The problem is bad enough that Google AppEngine limits Go programs to one thread.

    Mixed functional/imperative programming has all these problems, plus the illusion that the problem has been solved. It hasn't.

    • by bytesex (112972)

      Agreed on main points. A few remarks:

      - In C's pthreads library, you *can* tell the 'system' 'I'm leaving this object to wait' of sorts (pthread_condition_wait requires you to pass a mutex).

      - Overall, there are many, *many* programs out there that, justifiably, do not use threads at all. To require these programs to incur the overhead associated with threading even though they don't use it, seems a bit much.

      • by Animats (122034)

        - Overall, there are many, *many* programs out there that, justifiably, do not use threads at all. To require these programs to incur the overhead associated with threading even though they don't use it, seems a bit much.

        That's why threading needs language support. The compiler can identify many objects that are not being shared across thread boundaries, and optimize out locking. Libraries can't do that; they can't do global analysis.

        This is also true of subscript checking. Most subscript checks can be optimized out, if the compiler knows they're subscript checks. This is especially true of inner loops, where most subscript checks can be hoisted to the top of the loop, and often optimized out entirely. But compilers have

    • That's an interesting post. I'm not sure solving the 'inside outside' problem will really fix all threading issues though, because sometimes you want to go outside while maintaining the lock.
      • by Animats (122034)

        sometimes you want to go outside while maintaining the lock.

        That's OK. What's not OK is coming back in.

        This is difficult to get right, which is why pthreads offer "recursive locks". Go doesn't.

  • I am a low level programmer, and found this paper quite hard to grasp. In my opinion it terribly fails on the vulgarization front.

    I gave up after I understood the problem to fight was that there were state in objects. I understand removing state makes the program simpler (and easier to mathematically prove), but I suspect this brings false assumptions, since the underlying environment (OS, computer, network) is full of hidden states. For instance a memory allocator may succeed or fail regardless of the para

  • Twenty years ago a CS grad student and fellow at the research center that I worked at, told me that he was certain that after object orientation the next big thing would turn out to be functional programming.

    I thought that made perfect sense and bought into the notion. So I am still waiting.

  • The article just notes that the hybrid approach doesn't magically address the problems in concurrent and parallel programming that other have claimed that they do. No where in the article does the author say that these approaches aren't useful. And I agree, you do need that purity to get those advantages for concurrent programming.

    But, purity comes at a cost. Monads add a order of magnitude of complexity compared to imperative models of I/O. The author notes that other approaches to the problem of side effe

    • by MadAndy (122592)
      Agreed. I've been working in this industry for 25 years, even actively like functional programming, but monads still blow my fragile little mind.

      A few years back I came across an plain-english explanation of them that made perfect sense, and boy am I annoyed that I didn't bookmark it. I might try to beat my head against the issue again at some point. If anyone thinks they might know where a good description is please post a link :-)
  • Haven't these guys ever heard this saying? I have never seen a more comprehensive and obvious example of letting the perfect be the enemy of the good.

  • I remember the "OOP everywhere" fad. Turned out OOP works well in some parts of applications but not others. Functional Programming probably has a similar profile in that it's a nice tool to have for certain applications or parts of applications, but that doesn't mean it should be everywhere. The skill is in knowing when to use it and when not to.

  • by pr0nbot (313417)

    I'm too lazy to evaluate the arguments.

  • Well, in the end even the languages itself have to be created using lowlevel languages which don't have all the lazy crap languages have been bloated with these days..
    So it all depends on which level you write your application.
    And there are many ways to do stuff, there is no one right way, and 'good' code is all in the eye of the beholder..

  • for programming, is that it solves nothing.

    Let us imagine for example web servers. Any http daemon should be easy for a single C/C++ programmer to implement.Yes the more all the bells and whistles will take a lot more work, but something functional. --no problem. These things run massively parallel yet have no problems? Why. There is no need for the threads to communicate.

    Where do web servers have conncurency problems?
    Answer, when the execute processes that access shared data For example order processing p

  • So "Mostly functional programming is unfeasable"? Oh, really? No shit.

    There's a name for 'mostly funcitonal programming' - it's called 'I-just-started-with-programming-and-Basic imperative spagetti code'.

    There is one situation were functional programming makes sense, and that is when you're not sure which segment of which procedure will come first, either because you can't wrap your head around it due to the complexity of the domain you're just programming your way into or because you really can't know. UI

"Free markets select for winning solutions." -- Eric S. Raymond

Working...