Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Erik Meijer: The Curse of the Excluded Middle

samzenpus posted about 3 months ago | from the almost-good-enough dept.

Programming 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.'"

cancel ×

237 comments

Jump through the mirror? (5, Insightful)

jeffb (2.718) (1189693) | about 3 months ago | (#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!

Re:Jump through the mirror? (4, Insightful)

jythie (914043) | about 3 months ago | (#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.

Re:Jump through the mirror? (1)

Geoffrey.landis (926948) | about 3 months ago | (#46856097)

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:Jump through the mirror? (1)

jeffb (2.718) (1189693) | about 3 months ago | (#46856145)

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:Jump through the mirror? (-1)

Anonymous Coward | about 3 months ago | (#46856203)

After enduring and surviving abuse from reddit, I tried to break all ties with Jim. It wasn't only because of the harsh judgments, but also because he was lying to me about wanting me for my body. He was apparently helping Jess lose weight, after telling me that she was doing it against his wishes. This was just his way of getting into my pants.

As a means of therapy and getting Jim off my mind, I placed an add on craigslist for some NSA sex. The kids were staying at my mom's for the weekend, so I figured it would be a perfect time to host. I wrote a brief description of what I was looking for and uploaded some steamy pics of myself that I'd taken with my webcam...within minutes my email was blowing up with pics of cocks. (I asked specifically for cock pics, because I like to know what I'll be working with.) There were many nice ones to choose from, so I couldn't just pick one. I decided to invite men over in intervals. One man was to come every hour for a total of 5 hours. This gave me time in between to wash up and to prepare myself for the next. it also guaranteed me no time to call or text Jim. It would certainly mean he wouldn't be on my mind.

The first guy who showed up was average.. balding. He was okay I guess. We got right down to business. He took me missionary and lasted about 10 minutes. I had hoped for a little longer, but I knew more men were on their way.

The second guy was big and tall, had a lot of chest hair. He was a bit shy, but eased into it after I began to kiss on his neck. He had some trouble with the condom, which made me think he didn't use them very often. We did it with him on top, and then eventually I rolled over on top of him and after some minor difficulty, did girl on top. He sucked my tits most of the time. I still didn't cum when he had finished. I was getting frustrated and asked him to eat me out, but he wouldn't.

I was starting to wonder if what I was doing was even worth it, considering that all it made me want to do was call Jim to get a proper fuck.

The third guy was decent. He was also a bit on the chubby side, but he had a big dick and he pushed it in and out really quickly. The motion and the girth made me orgasm. He wanted to do anal, but I told him no, and he was respectful of my wishes.

The fourth guy was very... aggressive. I'm going to have to put a trigger warning in here.. TW violent sex, TW rape

I don't feel like I was raped because I invited him into my body, but because he refused to wear a condom and wouldn't pull out, which I did not consent to, I believe it was a form of rape. Basically he began to kiss me and I took his dick out of his pants. I was wearing just a bit of sexy lingerie (no panties) when I felt him slide in. I was alarmed because he did not wear a condom. I pushed him back and told him I need him to please wear some protection so we can continue. He shoved back and held me down and said no. I hate to admit how good his cock felt in the raw, and I guess knowing how dangerous this was made me get really horny. I was wet immediately. I knew I could get pregnant and it made me unable to protest further - even though I don't want his baby. He slapped me around, pulled my hair, spit in my face and then came inside me while choking me. I was shaken up when he left. I didn't know what to do about the next guy, I wanted to call it off. I am a woman of my word though, and let it proceed.

The last guy was really skinny and young. I made sure to see his ID, he had just turned 18 and was still a virgin. I decided to let him inside of me raw as well because at this point, what could it hurt? He was very nervous and basically came as soon as he put it in .. a pump and dump if you will.

By now I'm terrified because I don't want a baby from a stranger. I don't know though, I've always thought it would be cool having a mixed baby. Something different and exotic. My other concern is some of the symptoms I'm having. I went to get an STD test today and I am waiting on the results for that. Hopefully just a UTI.

Re:Jump through the mirror? (0)

Anonymous Coward | about 3 months ago | (#46856405)

I thought it had something to do with the pitfalls of lazy evaluation.

Re:Jump through the mirror? (5, Funny)

catmistake (814204) | about 3 months ago | (#46855785)

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? (3, Funny)

PPH (736903) | about 3 months ago | (#46856001)

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

Re:Jump through the mirror? (0)

Anonymous Coward | about 3 months ago | (#46856585)

AS the MCP I agree that we need to eliminate the users.

Re:Jump through the mirror? (4, Funny)

ozmanjusri (601766) | about 3 months ago | (#46856659)

Suddenly Win8, the Office ribbon, RT, and Sharepoint begin to make sense. Thanks for the epiphany.

Re:Jump through the mirror? (1)

Cryacin (657549) | about 3 months ago | (#46856701)

As the BOFH, I firmly advocate playing with users for amusement and sport, until they eliminate themselves.

Re:Jump through the mirror? (2)

Belial6 (794905) | about 3 months ago | (#46856583)

You can simulate the exact same effect by just quiting your job and never working in the field again.

No safer (4, Funny)

SuperKendall (25149) | about 3 months ago | (#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...

Re:Jump through the mirror? (1, Interesting)

Kjella (173770) | about 3 months ago | (#46855851)

My impression of "pure" functional programming is that it's roughly like having only static classes and no static members in OOP. Basically if you can have all the information you need "in flight" with you, then it can do all sorts of neat parallelization and optimization tricks because there's no state that makes the ordering important. I guess that's great if you're running some sort of scientific simulation where all the input is set in the model and you expect a result set out at the very end. But I don't find that part hard, the hard part about OOP is when the state throws you a curve ball. You try to write to a database record but it's not there anymore or the user removed the CD from the drive or the database is full or the network connection was lost and now what? It's handling all the contingencies that is difficult. I guess if the problem is the performance of your side effect free code, functional programming may be the answer. But it's not what most developers deal with.

Re:Jump through the mirror? (-1)

Anonymous Coward | about 3 months ago | (#46855879)

It's amazing that people like you always comment on things that you obviously know absolutely nothing about.

Re:Jump through the mirror? (1)

Anonymous Coward | about 3 months ago | (#46856069)

My impression of "pure" functional programming is that it's roughly like having only static classes and no static members in OOP

Linus was right. OO programmers are brain damaged.

Re:Jump through the mirror? (0)

Anonymous Coward | about 3 months ago | (#46856197)

Unfortunately, Linus didn't realise that C programmers are brain damaged too.

Re:Jump through the mirror? (4, Funny)

jc42 (318812) | about 3 months ago | (#46856325)

... 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:Jump through the mirror? (5, Informative)

Pseudonym (62607) | about 3 months ago | (#46856353)

My impression of "pure" functional programming is that it's roughly like having only static classes and no static members in OOP.

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.

  • You are declaring a new type, called Foo.
  • You are declaring a new collection of types (also confusingly called Foo), which will turn out to be the type Foo and all its subtypes.
  • You are declaring that the type Foo is a member of the collection Foo.

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:Jump through the mirror? (1)

Geoffrey.landis (926948) | about 3 months ago | (#46856415)

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:Jump through the mirror? (1)

Pseudonym (62607) | about 3 months ago | (#46856571)

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:Jump through the mirror? (1)

Pseudonym (62607) | about 3 months ago | (#46856445)

One thing I was going to mention but didn't (because it would have confused things) is that this is true but slightly misleading:

a "type" can be thought of as a set of values

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 expected to understand this.

The only true functional program... (0)

Anonymous Coward | about 3 months ago | (#46855913)

Since input and output are side effects, and externals like running time, or even whether a program is running could be used to signal output, the only Pure Functional program is such that it is undecidable whether or not the program is even running, or can be run. But maybe reality is is a simulation run by a functional program, and the only observers are inside the system, and there's no way to tell if reality is a simulation from inside the system. So studying Pure Functional programming is just cheesy metaphysics by another name.

Don't worry (0)

Anonymous Coward | about 3 months ago | (#46856079)

My new one language to rule them all, Ruperelix, will solve all that, for 1 week only, until it's taken apart. As you rightly stated, computers are not paper.

Re:Jump through the mirror? (2)

fractoid (1076465) | about 3 months ago | (#46856107)

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? (5, Informative)

Anonymous Coward | about 3 months ago | (#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:Jump through the mirror? (1, Funny)

fractoid (1076465) | about 3 months ago | (#46856255)

ITT: Functional language fanboys get defensive.

Re:Jump through the mirror? (-1)

Anonymous Coward | about 3 months ago | (#46856331)

There are legitimate issues with purely functional programming, but you're just another clueless retard that says things that are blatantly idiotic.

Re:Jump through the mirror? (1)

Pseudonym (62607) | about 3 months ago | (#46856231)

So you didn't read TFA either, then?

Re:Jump through the mirror? (1)

timeOday (582209) | about 3 months ago | (#46856425)

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.

Re:Jump through the mirror? (4, Interesting)

rabtech (223758) | about 3 months ago | (#46856369)

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.

Wrong! (1)

For a Free Internet (1594621) | about 3 months ago | (#46855603)

Functional programming is impossible under capitalism! Only termites know how to leaf the snore of pofBen. send - it was not me.

functional programming catch-22 (3, Interesting)

smoothnorman (1670542) | about 3 months ago | (#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")))

Re:functional programming catch-22 (1)

Anonymous Coward | about 3 months ago | (#46855701)

Forth is always fun...
If you want to program using functional procedures, just use a functional language. I like ocaml.
Or try some variant of Scheme. You can use any programming paradigm you like with that...

Re:functional programming catch-22 (1)

phantomfive (622387) | about 3 months ago | (#46855839)

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.

Re:functional programming catch-22 (0)

Anonymous Coward | about 3 months ago | (#46855853)

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")))

I think it's Lisp you secretly crave.

Re:functional programming catch-22 (2)

Pseudonym (62607) | about 3 months ago | (#46855917)

to have monads is to compromise functional programming.

[citation needed]

"Mostly" by defintion isn't what you wanted... (1)

The New Guy 2.0 (3497907) | about 3 months ago | (#46855619)

If your goal is "functional" and you wind up at "mostly functional"... aren't you admitting you've got a bug in your program?

I am looking for a word ... (-1, Offtopic)

Anonymous Coward | about 3 months ago | (#46855629)

and the word is

Gobbledygook

If the best you can describe a problem is nonsense, the whole thing is nonsense.

Re:I am looking for a word ... (2, Informative)

Anonymous Coward | about 3 months ago | (#46856017)

I'll break it down into Retardese for you.

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.

Now think what would happen if we have g(x)=h(x)*x+1, where h(x) returns the previous value that it was supplied with (assume that it returns 0 on the first call if you like). That complicates things greatly, because we now have to consider everything that has been called before. You evaluate g(10) then g(5) to get 51, then reset the environment and evaluate g(5) then g(5) to get 26. That means it's no longer a function and cannot be reasoned like it is one. This means that you cannot formally prove the code correct, but you have to use a debugger to hunt down things like some sort of code monkey. It's intolerable!

Re:I am looking for a word ... (0)

Anonymous Coward | about 3 months ago | (#46856123)

Are you gay?

Re:I am looking for a word ... (0)

Anonymous Coward | about 3 months ago | (#46856219)

Sorry, I'm taken.

Or just a hybrid (0)

Anonymous Coward | about 3 months ago | (#46855639)

With CloudI [cloudi.org]

NaNL (Not a Natural Language) (1)

Anonymous Coward | about 3 months ago | (#46855655)

I suspect that this was written by a computer because even though it is is grammatically correct it still seems like a bunch of technical words strung together.

Wow (3, Insightful)

xdor (1218206) | about 3 months ago | (#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.

Re:Wow (-1, Flamebait)

Anonymous Coward | about 3 months ago | (#46855729)

Erik Meijer is a better programmer than you, has more money than you, has more fame than you, and pulls hotter bitches than you. None of these points are even debateable.

P.S. You still login to Slashdot so you're almost definitely an incompetent retard.

Re:Wow (0)

Anonymous Coward | about 3 months ago | (#46855787)

Hi Erik,

Glad you could join the discussion!

Best,

Your left Gonad.

Re:Wow (3, Funny)

PPH (736903) | about 3 months ago | (#46855991)

P.S. You still login to Slashdot so you're almost definitely an incompetent retard.

Welcome to the club. Here's your hat.

Re: Wow (1)

Anonymous Coward | about 3 months ago | (#46855837)

Just wait until you've been doing it for 30... then you'll really not know anything anymore...

Well that summary leaves me wondering (5, Funny)

Anonymous Coward | about 3 months ago | (#46855687)

what does Bennett Haselton think about this topic?

Hello (0)

Anonymous Coward | about 3 months ago | (#46856273)

I support this topic,

Bennett.

Sounds like my old comp-sci professor. (5, Insightful)

quietwalker (969769) | about 3 months ago | (#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:Sounds like my old comp-sci professor. (1, Interesting)

msobkow (48369) | about 3 months ago | (#46855961)

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 use Erlang. Maybe if he were still with the company, he'd have been able to code it (he was an Erlang "expert".) But he'd jumped ship two years before it was due, so we'll never know if even a self-proclaimed "expert" could have made it work.

I couldn't. I'd managed to shoehorn every other piece of functionality into the system, but mapping that simple array-based algorithm to a functional language proved impossible.

Re:Sounds like my old comp-sci professor. (1)

Pseudonym (62607) | about 3 months ago | (#46856023)

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.

Re:Sounds like my old comp-sci professor. (1)

msobkow (48369) | about 3 months ago | (#46856035)

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

Re:Sounds like my old comp-sci professor. (3, Insightful)

Pseudonym (62607) | about 3 months ago | (#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.

Re:Sounds like my old comp-sci professor. (0)

Anonymous Coward | about 3 months ago | (#46856111)

Then we came to the scheduling algorithm, which had originally been prototyped with Visual Basic.

Haha, there's the real problem, and your lack of skills, no offense.

Re:Sounds like my old comp-sci professor. (4, Interesting)

msobkow (48369) | about 3 months ago | (#46856525)

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:Sounds like my old comp-sci professor. (0)

Anonymous Coward | about 3 months ago | (#46856265)

You are familiar with tuples [erlang.org] , right?

Re:Sounds like my old comp-sci professor. (2)

msobkow (48369) | about 3 months ago | (#46856049)

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#.

Not really (3, Insightful)

phantomfive (622387) | about 3 months ago | (#46855865)

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.

Re:Not really (0)

Anonymous Coward | about 3 months ago | (#46856371)

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.

How DARE you use the best tool for any job!

Re:Not really (0)

Bite The Pillow (3087109) | about 3 months ago | (#46856501)

You are the reason the article exists. You talk about minimizing bugs, and the article talks about eliminating them. They are not the same.

Moving to a mostly functional language to eliminate bugs does not work. Reduce, maybe. But not eliminate. No one should make the mistake of assuming that mostly functional programming reduces bugs, either. It may just relocate them.

Mostly functional is not the same as functional, and remove is not the same as reduce. At least understand what you object to before objecting.

Re:Not really (2)

phantomfive (622387) | about 3 months ago | (#46856561)

Well, functional programming won't eliminate bugs either, so whatever

Re:Not really (0)

Anonymous Coward | about 3 months ago | (#46856605)

At the end of the day, pure functional languages are useless. So of course there are no bugs.

Ironic (0)

Anonymous Coward | about 3 months ago | (#46856745)

There is no programming language that is both useful and can ensure there are no bugs, so you'll have to excuse those of us who think it looks rather like fighting windmills.

This might be the first time ever I have seen someone use 'excluded middle' in a true to the definition ironic sense.

Safer is not the reason (1)

Anonymous Coward | about 3 months ago | (#46855869)

Removing side effects from the equation is only one advantage of functional programming. The solutions to many problems are far more succinctly written in terms of functions. That's why the reason why I like using the paradigm. "Mostly functional programming" gives you the flexibility of imperative programming with the powerful expressiveness of functional. Who said it was trying to make it safer?

Trends (-1)

Anonymous Coward | about 3 months ago | (#46855901)

This is very popular with gay programmers. Something about being differnt, beating to a different drum, and that sort of thing. Straight gals like me will never get it.

Unversity course from hell... (1)

Anonymous Coward | about 3 months ago | (#46855911)

This subject had us working in groups to code a structured editor in a functional language - we called this the "specification" but it was essentially a functional implementation of an editor with a few concessions to do the actual IO. We then "implemented" in Java. I learnt exactly 4 things from that course.

1) NEVER EVER try to build an editor in a structured language. Functional languages are a poor fit for procedural tasks.
2) Having built something in a functional language do not then try to translate directly to an object oriented language. Plenty will be lost in the translation (It's like trying to translate a book of jokes from one language to another, only worse) and you'll wind yourself up in a knot trying to define a subset of a functional language in an object oriented one. What you'll end up in the object oriented language will be an ugly inelegant unreadable mess!!!
3) The idea that you can build a provable system using a functional language is bat crap insane. In terms of proof it'll give you nothing that good unit tests wouldn't give you.
4) Spend a lot of time ensuring you work in groups where for the most part everyone pulls their own weight.

Re:Unversity course from hell... (1)

Pseudonym (62607) | about 3 months ago | (#46856043)

NEVER EVER try to build an editor in a structured language. Functional languages are a poor fit for procedural tasks.

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.

Good aspiration, bad in (some) practice (2)

RedMage (136286) | about 3 months ago | (#46855967)

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:Good aspiration, bad in (some) practice (1)

lgw (121541) | about 3 months ago | (#46856019)

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 everywhere just because that's the music you listened to in college isn't helping either performance or clarity.

Re:Good aspiration, bad in (some) practice (1)

Anonymous Coward | about 3 months ago | (#46856275)

Functional programming doesn't work very well on the JVM because of the lack of proper tail call optimization. Scala also doesn't track effects in its type system so there are a ton of optimizations that can't be done (fusion being the most obvious and probably the biggest).

It also doesn't help that the primary Scala implementation is a fucking mess.

Bad Summary. (4, Interesting)

thestuckmud (955767) | about 3 months ago | (#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 hybrids myself (1)

GoodNewsJimDotCom (2244874) | about 3 months ago | (#46856005)

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 because side effects could happen anywhere! But when your a solo guy, you know right away.

It's Not Just A Good Idea, It's The Law (2)

mbstone (457308) | about 3 months ago | (#46856025)

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

State machine programming (1)

Mr.CRC (2330444) | about 3 months ago | (#46856065)

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:State machine programming (2)

ultranova (717540) | about 3 months ago | (#46856309)

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 same control machine, Bad Things happen?

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

The idea of functional programming is to pass all information in function parameters and return values, rather than through globals.

Gobbledigook (0)

Topwiz (1470979) | about 3 months ago | (#46856101)

This just a bunch of academic rambling that has nothing to do with the real world. Real world business software developers just don't talk that way. They could care less if the language they use is functional or not and probably don't know. They just want to know how to implement a business requirement. If something doesn't work it is a bug, not an effect.

Re:Gobbledigook (-1)

Anonymous Coward | about 3 months ago | (#46856167)

It actually shows the lack of mathematical background.

Computers are mathematical devices, the only thing they can do is mathematics.

The more mathematics the programmer knows the easier the problems become.

Unfortunately, training for the "language of the day/month/year" is that none of the necessary background is provided, and that lack causes the problems/bugs/errors/catastrophes and project failures...

it is also why programs cannot be validated...

Re:Gobbledigook (0)

Anonymous Coward | about 3 months ago | (#46856365)

You are correct, but you're also missing the point. If you work long enough in the software industry you come to the realization that the benefits of rigor, be it functionality or otherwise, are near universally viewed with suspicion. Rather, ignorance is promoted as intellectual honesty, and "correctness" is always just a fix away. Good luck to the language designer if they take TFA to heart. They'll neither be understood, nor adopted.

Re:Gobbledigook (0)

Anonymous Coward | about 3 months ago | (#46856481)

Rather, ignorance is promoted as intellectual honesty, and "correctness" is always just a fix away. Good luck to the language designer if they take TFA to heart. They'll neither be understood, nor adopted.

There are small niches where you can still find really smart developers/mathematicians (finance and a lot of DoD projects for instance). You'll probably be working for some "evil" people but who really cares.

Re:Gobbledigook (4, Informative)

Pseudonym (62607) | about 3 months ago | (#46856177)

Real world business software developers just don't talk that way.

"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:Gobbledigook (2)

bytesex (112972) | about 3 months ago | (#46856731)

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:Gobbledigook (1)

Pseudonym (62607) | about 3 months ago | (#46856767)

But you have to agree that 'functional programming is the next big thing' has been said for so long now [...]

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 next big thing" for a while, along with everyone else who thinks that something else is "the next big thing".

I don't know who those people are, because I don't listen to them, but Erik Meijer is not one of them. Actually he's making a sort-of opposite point, namely, that in the world of many-core and big-data, "almost" pure functional programming (which is almost all functional programming) is useless.

Excluded middle, eh? (2)

Pseudonym (62607) | about 3 months ago | (#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?

Through the looking glass indeed (2)

Alomex (148003) | about 3 months ago | (#46856361)

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 (4, Insightful)

Alomex (148003) | about 3 months ago | (#46856379)

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:Mostly functional works quite alright (1)

Pseudonym (62607) | about 3 months ago | (#46856517)

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.

Re:Mostly functional works quite alright (1)

Alomex (148003) | about 3 months ago | (#46856639)

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:Mostly functional works quite alright (0)

Anonymous Coward | about 3 months ago | (#46856761)

I'm sorry, truly big like.. what? The linux kernel? clang? gcc? firefox? The Unreal Engine 4? The complete Windows Operating System?

What successful pure-functional projects operate at this scale (pick your metric: lines of codes, number of users*time, ...)?

Concurrency is still badly understood (4, Interesting)

Animats (122034) | about 3 months ago | (#46856427)

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:Concurrency is still badly understood (1)

bytesex (112972) | about 3 months ago | (#46856723)

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:Concurrency is still badly understood (1)

Animats (122034) | about 3 months ago | (#46856757)

- 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 to be allowed to report subscript out of range conditions "early" for this to work. That is, if a FOR loop is going to overflow an array, the compiler has to be allowed to report it at the start of the loop, instead of being required to execute all the iterations up to the buffer overflow and then report it.

One of the Go compilers does that subscript checking optimization.

Sounds like somebody "catching on" (0)

Anonymous Coward | about 3 months ago | (#46856463)

Functional programming has gotten so much buzz the past few years, despite the fact that it's as old as math. It didn't take me too long to realize that any real computer is going to have memory, which is to say... it's going to have STATE. Furthermore, much of the world is stateful. If you don't model state directly in the language, you just model it in some klutzy way. Yeah, let's tie the brains of new users in knots making the comprehend monads so we can do... what any old imperetive language does.

Terrible paper (1)

manu0601 (2221348) | about 3 months ago | (#46856475)

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 parameter it was called with.

Still waiting (1)

quax (19371) | about 3 months ago | (#46856523)

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... (1)

ndykman (659315) | about 3 months ago | (#46856783)

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 effects are complex that "one shouldn't need a PhD in computer science to code", but I think he fails to notice that monadic I/O is also incredibly complicated to the average programmer as well. It does end becoming a domain specific language very quickly, and that can be a big hammer for a very small problem.

But, the fundamental argument is sound. If you really want those gains that pure functional languages can bring to concurrency, you have to embrace that model completely.

However, I don't buy the argument that other approaches won't have merit. I found this paper (http://research.microsoft.com/apps/pubs/default.aspx?id=170528/ [microsoft.com] ) to show that type extensions really may have some promise in augmenting imperative OO languages for concurrency.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...