Erik Meijer: The Curse of the Excluded Middle 237
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.'"
Jump through the mirror? (Score:5, Insightful)
"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!
Re:Jump through the mirror? (Score:5, Insightful)
Re: (Score:2)
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.
Re: (Score:2)
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!"
Re: (Score:3)
Well, would you rather be faced with a false dichotomy, or would you like to have other options?
Re:Jump through the mirror? (Score:5, Funny)
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.
Re:Jump through the mirror? (Score:4, Funny)
Speaking as a sysadmin [wikipedia.org], you should have said, "eliminate the users."
Re: (Score:2)
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
Re:Jump through the mirror? (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
No safer (Score:5, Funny)
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...
Re: (Score:2)
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!
Re: (Score:3)
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.
Re:Jump through the mirror? (Score:5, Informative)
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)
Re: (Score:2)
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.
Re: (Score:2)
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).
Re: (Score:2)
So you didn't read TFA either, then?
Re: (Score:2)
Re: (Score:2)
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
Re:Jump through the mirror? (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
No. With an infinitely fast CPU, we would let the computer do the programming :)
Re: (Score:2)
Re: (Score:2)
Yes. With increasing CPU speed, it makes sense to sacrifice "performance" for ease of programming.
Re: (Score:2)
Re:Jump through the mirror? (Score:4, Informative)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Jump through the mirror? (Score:5, Informative)
If you got that impression from TFA, then I can actually understand how you got it. Meijer's article was written for people already using not-fully-pure functional languages, where "class" means something slightly different than it does in a Simula-style OO language.
The term "class" comes from von Neumann–Bernays–Gödel set theory. Naive set theory had issues like Russell's Paradox, which relies on notions like the "set of all sets". To remove this paradox, NBG set theory distinguishes between a "set" and a "class" [wikipedia.org] (i.e. a collection of sets defined by a property they have in common). Some classes are sets, and some are not. A set is a collection of values, but a "class" is a collection of sets.
In programming language theory, a "type" can be thought of as a set of values (e.g. "boolean" might be the set {true, false}). A "class" is a collection of types.
When you write class Foo in (say) Java, you're actually doing three separate things.
In the Haskell class system, these three things are separated. This is why Haskell classes look more restrictive than classes that you might find in Java: a Haskell class only contains the parts that make it a class, not the parts that make it a type.
Did that help?
Re: (Score:2)
The term "class" comes from von Neumann–Bernays–Gödel set theory. Naive set theory had issues like Russell's Paradox, which relies on notions like the "set of all sets". To remove this paradox, NBG set theory distinguishes between a "set" and a "class" [wikipedia.org]
Unfortunately, while that was a clever attempt to solve the paradox, the paradox is not solved in this matter.
Re: (Score:2)
Yes, I think that the main lasting contribution of NBG is the language. Today we would talk about the "category of all sets" or the "category of all locally small categories", rather than "proper classes".
Re: (Score:2)
One thing I was going to mention but didn't (because it would have confused things) is that this is true but slightly misleading:
Sets are unstructured, but programming language types have structure. This is part of the reason why modern thinking is to ground programming language semantics in the language of category theory. If nothing else, the "carrier sets" of types must be computable sets, and the mappings between them must be computable functions.
You are not
Re: (Score:3)
Class definition of Haskell simply contains methods defined abstractly.
For example the collections class is defined:
class Collects e ce where :: ce :: e -> ce -> ce :: e -> ce -> Bool
empty
insert
member
What this reads is there are 3 functions
empty which tells you if a collection is empty
insert which takes an element and a collection is arguments and
Re: (Score:2)
A good example of where functional can be very useful from your examples is: writing the database engine, writing the CD-decoder, writing the network stack, etc...
Re:Jump through the mirror? (Score:5, Insightful)
If you use fopen(), fread(), fclose() etc., you're already doing object oriented programming in C.
Re: (Score:2)
If you use fopen(), fread(), fclose() etc., you're already doing object oriented programming in C.
No modpoints, sadly, but I agree.
Re: (Score:3)
OO (C++) promotes data hiding (of fields in a struct/class) and using member functions to manipulate the data in a safe manner. So the above file operations in C++ would be something like:
Re:Jump through the mirror? (Score:5, Funny)
... C programmers are brain damaged too.
From the viewpoint of the general public, we can simplify it to "Programmers are brain damaged." This conclusion is often especially obvious to management, who find programmers both incomprehensible and arrogant. After all, would a truly sane person clearly tell their bosses that something can't be done the way the bosses said it is to be done? But programmers do this all the time, so they must be mentally deranged.
Re: (Score:3)
Re: (Score:2)
Re:The only true functional program... (Score:4, Informative)
Pure functional programming means state is isolated not that it doesn't exist.
functional programming catch-22 (Score:4, Interesting)
Re: (Score:2)
Re: (Score:3)
[citation needed]
Wow (Score:4, Insightful)
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.
Re:Wow (Score:4, Funny)
P.S. You still login to Slashdot so you're almost definitely an incompetent retard.
Welcome to the club. Here's your hat.
Well that summary leaves me wondering (Score:5, Funny)
what does Bennett Haselton think about this topic?
Sounds like my old comp-sci professor. (Score:5, Insightful)
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)
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
Re: (Score:2)
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.
Re: (Score:2)
Erlang expressed arrays as lists internally. Any obvious implementation sucked donkey balls for performance.
Re:Sounds like my old comp-sci professor. (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re:Sounds like my old comp-sci professor. (Score:5, Interesting)
No offense taken. I don't claim to be an Erlang expert; I hadn't even heard of the language before this project. None of the team members had worked with it. The only one who'd worked with it was the guy who architected and prototyped the system. As soon as he was done the prototype, he didn't renew the contract and buggered off.
But we had done "too much" to switch to a language we could all agree on. Oh hell, no. We had to keep on using that crap because somebody had Made A Decision and wouldn't backtrack and Lose Money.
In the end, they lost 4-5 times as much money when we couldn't make it go. And it serves them right -- sticking with a bad decision just because you've got an investment in it is stupid when everyone is telling you it's a bad decision and a bad investment. You need to listen to the TEAM DOING THE WORK, not an "expert" who buggered off before the real work started.
Re: (Score:2)
There are two issues here:
a) Was Erlang the right choice
b) Did management handle transitioning the team to Erlang the right way.
(b) could be "no" and (a) could be yes. Your argument before was that Erlang wasn't a good language. No one is arguing that FP doesn't take unlearning a bunch of ways of thinking that are typical in other languages. Also some pure learning time where you see concepts on simple examples and not in the context of real life. Redoing programming 101 type stuff.
Re: (Score:3)
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#.
Re: (Score:2)
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
Re: (Score:2)
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)
Furthermore it can be mixed with imperative, or even object, programming. It's a useful technique for minimizing bugs.
Re: (Score:3)
Good aspiration, bad in (some) practice (Score:3)
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...
Re: (Score:2)
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)
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 hybrids myself (Score:2)
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
It's Not Just A Good Idea, It's The Law (Score:3)
If Republicans are elected, expect fundamentalist programming to become mandatory.
State machine programming (Score:2)
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.
Re: (Score:3)
newState = deriveNewStateFromDeviceMessage (oldState, message)
(bitsToSendToDevice, newState) = getHardwareCommandForSomeAction(oldState, action)
So, basically, if someone plugs two gadgets into the sa
Excluded middle, eh? (Score:3)
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?
Through the looking glass indeed (Score:3)
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.
Mostly functional works quite alright (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Like map/reduce at Google.
Concurrency is still badly understood (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
- 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
Re: (Score:2)
Re: (Score:2)
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.
Terrible paper (Score:2)
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
Still waiting (Score:2)
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.
Misleading Summary... (Score:2)
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
Re: (Score:2)
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
Letting the perfect be the enemy of the good (Score:2)
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.
Another fad? (Score:2)
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.
TL (Score:2)
I'm too lazy to evaluate the arguments.
ugh... (Score:2)
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..
The weakness of statelessness as a principle... (Score:2)
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
Captain Obvious strikes again! (Score:2)
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
Re: (Score:2, Informative)
Side effects are things that change the state of the program. We don't want to store the state of the program because it gives it a memory. If it is not memoryless, then it is difficult to reason about. For instance, the equation f(x)=2x+1 is memoryless, because it does not matter what was observed the last time you observed f(x). As such, we can reason very easily with this function, and as long as we always supply the same input, we always get the same output.
No
Re: (Score:2)
This is good advice, right up to the point where you need to implement "undo". At that moment, you learn why non-destructive data structure manipulation is an excellent idea.
Re: (Score:2)
Re:Gobbledigook (Score:5, Informative)
"Real world business software developers" are those whose code ends up on The Daily WTF [thedailywtf.com].
But seriously, welcome to the future. In the 1960s, "real world business software developers" thought that all this "object" stuff was a bunch of academic gobbeldygook at worst, or niche tool for people doing scientific simulations at best, rather than anything that would be useful with their hard-nosed COBOL. And in a sense, they were right. How would it help you speed up the overnight bank transaction updates? It probably wouldn't.
This "academic rambling" probably won't help you write your business software today, but it just might help you avoid becoming obsolete tomorrow. Thankfully, you probably won't need to learn it until tomorrow.
Re: (Score:3)
But you have to agree that 'functional programming is the next big thing' has been said for so long now - it's the flying car of computer science. When people say 'any day now' for so long, some scepsis *is* in order.
Re: (Score:2)
Well... I kind of have to agree, in that it's true that it has been said. However, it's not true that this means anything either way.
I remember when transputers were the next big thing. People older than I probably remember when perceptrons were the next big thing. People talk crap, and functional programming has been around for a while, so it's inevitable that some subculture has considered it "the
Re: (Score:2)
Re: (Score:2)
I've heard this "expressiveness" claim multiple times, but have yet to see a realistic and practical code example. There have been examples where the code was more compact, but the readability of such code was either questionable or highly subjective.