“Mostly functional” programming does not work (2014)

https://queue.acm.org/detail.cfm?id=2611829

73 140 11 years ago

queue.acm.org

moron4hire2• 11 years ago

Well now, what the hell have I been doing all this time?

According to TFA, apparently nothing that "works".

If you're working in C#, you're most likely working in Visual Studio (Mono is just such a terrifically small proportion of C# users, and even then, some Mono users are using Visual Studio), so you have access to one of the best (and easiest to use!) debuggers in the world. This isn't embedded C++. It is common for .NET developers to know how to use the debugger. People don't use printf-style debugging, and even if they thought they would want to, there is no easy way for such an undertrained developer to do it. You have to make a special build to get the "console" window, and it's a setting most developers I've encountered just plain don't even know exists.

And if you're using LINQ, it's because you know you want deferred execution and that's explicitly what you're hoping for. Developers who don't know this feature/limitation of LINQ just plain don't know about LINQ.

So after all these C# strawmen, his proposed solution is... rewrite your entire world in Haskell. Yeah, that's totally going to happen. I'm going to get my stakeholders on board for that, I'm going to have all of the libraries I've come to love available to me, or reasonable analogues (Just looked at HDBC, it looks like a toy compared to ADO.NET). We're just going to switch to Haskell and everything is going to be peaches and cream.

TazeTSchnitzel20• 11 years ago

People don't use printf-style debugging

Firstly, no, people still do. Not everyone, but people do.

But even if nobody did, that doesn't change anything. The article isn't about the dangers of printf, it's about the dangers of side effects: printf is just an example. A printf inside an otherwise pure function is not the only possible example of a side effect.

And if you're using LINQ, it's because you know you want deferred execution and that's explicitly what you're hoping for. Developers who don't know this feature/limitation of LINQ just plain don't know about LINQ.

So? You can still make mistakes here and your compiler won't catch them.

moron4hire2• 11 years ago

But what he's showing is "not even close to functional", not "mostly functional".

sebastianconcpt2• 11 years ago

What if you do not-functional software in ways where parallelism and concurrency are non-problems? there is no elephant in the room?

TazeTSchnitzel20• 11 years ago

Pure functional programming provides benefits in domains where you don't need parallelism or concurrency, too. It controls side effects, allowing safe composition of functions.

seanmcdirmid2• 11 years ago

Right. Just like it is often useful to avoid functional code in cases where parallelism is needed for performance reasons (e.g. in CUDA).

RyanZAG3• 11 years ago

As far as I can tell, the argument is that allowing side effects inside functions allows programmers to make mistakes, and therefore "mostly functional" programming is broken.

I'll happily extend this: "fully functional" programming does not work because I can define a mathematical function that divides by 0, and therefore does not work. I'd go a step further even: all programming does not work, because I can solve a problem in the wrong way if I make a mistake.

spdionis• 11 years ago

Your way of thinking is not really helping though. The goal is to minimize the amount of mistake, not eliminate them (because it is impossible).

You can either think that everything is broken or nothing is broken, or you can try to make everything the least broken possible.

reitanqild• 11 years ago

Your way of thinking is not really helping though.

RyanZAG does not think that way, just tries to point out that the premise of the article seems broken.

hawleyal• 11 years ago

The article is proposing these points.

laumars• 11 years ago

His point was you cannot fix against bad programmers. While I'm sure we'd all agree that it's preferable that languages enable developers by throwing up the least amount of hidden traps, at some point we need to stop blaming our tools like the proverbial bad workman.

TazeTSchnitzel20• 11 years ago

Mostly functional programming is broken because it cannot solve the problem it sets out to, namely controlling side effects. Because the language type system does not control them, "mostly functional" programming is no more useful than standard imperative programming.

viraptor5• 11 years ago

I feel like the author makes it easy for himself, by both defining what other languages try to achieve by being mostly functional and how they fail to achieve that. I don't believe he's right with his assumptions.

It's not like linq, Erlang, f#, ocaml, or even python func/itertools designers said - we're going to be as pure as possible and functional to get that almost-purity. Some problems are just easier to solve with functional-like approach. Whether you're doing it in a pure way or not doesn't matter. Some languages give you a way to write that functional-like solution. I doubt many think of purity while using them, but problems get solved. And we're still better off than writing nested loops instead.

For example I'm happy with write:

    items.filter(f1)
        .map(f2)
        .map(f3)
        .reduce(...

and I really really don't need or want an IO monad to be returned from f2 if it happens to need to log some warnings. It would be completely counterproductive.

MaulingMonkey• 11 years ago

Programmers can control side effects. While mistakes can/will occur, lessening the benefits compared to language enforced control over side effects, there's a big difference between lessening and eliminating. As such, I'd hesitate to say it's "no more useful".

visarga3• 11 years ago

Mostly functional programming is good enough to make cooperative multitasking and asynchronous programming, which makes for faster servers and easier to reason about user interfaces.

You just have to remember a few globals and try to keep things uncomplicated. Also, having tests helps a lot.

1ris• 11 years ago

Who says that "Mostly functional programming" sets out to control side effects?

How the hell do you get to the conconculsion that's it's no more useful than standard imperative programming? That implies that e.g. first class functions do not have merit, which is, excuse me, horseshit.

Lisp doesn't do that and it works wonderful. Same for ML/F#, PerformunsaveIO, Ocaml, you name it.

calpaterson• 11 years ago

Nonsense! That works fine in Haskell:

  cal@hp-elitedesk ~/s/b/i/ops> ghci
  GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
  Loading package ghc-prim ... linking ... done.
  Loading package integer-gmp ... linking ... done.
  Loading package base ... linking ... done.
  Prelude> 1/0
  Infinity

da_chicken• 11 years ago

Well done, Haskell. You're not even wrong.

RyanZAG3• 11 years ago

1/0 is not infinity, it is undefined. The limit as x tends to 0 of 1/x is infinity, but there is no value for 1/0, which is why doing a calculation that involves a divide by 0 is mathematically invalid. That Haskell let's you do it and gives an approximate answer is OK, but if it was in a calculation for the number of apples you can eat, it would be a useless answer. You could end up with that if you made a mistake in defining your logic. In the same way, you can make a mistake when doing all manner of other things such as using a non-pure function or adding instead of subtracting. They're all forms of logic error that are either allowed or disallowed by tools. The tool isn't broken if it let's you make mistakes though.

A power drill will let you drill a nail into your leg. That doesn't make power drills broken. A smart drill that turned off the drill if your leg was in front would be better - but we still use drills without that function because there are trade offs when you make your drill do that. There are trade offs in functional languages too. That doesn't make C# "broken" for being a tool that let's you drill into your leg if you point your drill there.

juliangregorian• 11 years ago

JavaScript will do the same, as will Ruby for floats.

michaelochurch• 11 years ago

You can blow up the runtime with integer division by zero, however.

    λ 1 `quot` 0
    *** Exception: divide by zero

With `1/0`, it uses `Double` because `(/)` requires a Fractional type.

Also, partial functions like `head` or `fromJust` can burn you:

    λ head []
    *** Exception: Prelude.head: empty list

The latter is a legacy behavior that is generally considered undesirable. The former is more debatable; some would say that you should avoid integer division by an unknown value as much as possible.

In Haskell, exceptions in non-IO code (other than deliberate hard crashes) are generally considered a wart to be avoided and mitigated as much as possible (because they interfere with functional programming).

NoGravitas• 11 years ago

a) All programs include at least one bug.

b) All programs can be reduced by at least one line of code without affecting their behavior.

Therefore: All programs can be reduced to a one-liner, which doesn't work.

agumonkey2• 11 years ago

"fully functional" programming does not work because I can define a mathematical function that divides by 0, and therefore does not work.

Unless you have wheels : http://www2.math.su.se/reports/2001/11/2001-11.pdf

erikb• 11 years ago

I started out reading not believing that pureness is a necessity and sadly the arguments weren't framed in a way that I could understand them. So, I'm still quite unconvinced because I haven't seen how it doesn't work. But of course I know from experience that it happens that things are true I haven't seen yet. Can anybody try to explain it for people who don't live on Haskell planet?

Example time: I program python, not C++. And in the example with the try-catch I would have wrapped it around the loop anyway. So for me it wasn't quite convincing that there is a problem in the first place. Sure someone who hasn't crashed a few programs due to lazy evaluaton might run into trouble in such kind of situation. But after a few times you understand that being defined and being executed are different things and then you wrap the execution. As far as I can see the whole problem described with the example doesn't exist if you intuitively wrap the foreach loop and not the definition statement for q.

So, would really appreciate if someone could explain it in a more nooby fashion to me. Thanks.

maehwasu2• 11 years ago

But after a few times you understand that being defined and being executed are different things and then you wrap the execution.

In this example, you've had to internalize a bit of extra knowledge, and have an extra "gotcha" to watch out for. A job that could have been done by a computer, if things were kept pure, now has to be done by you, incurring slight amounts of mental overhead.

I don't program routinely in Haskell (although things are quickly headed in that direction), but I think the sentiment of that community is: 1. Keeping a large system consistent in your head is hard 2. Offloading the constant checking of that consistency, in any amount, to a computer, is a huge win that compounds quickly over time.

Note that the "hardness" of holding a large system in your head, and the "hardness" of Haskell's learning curve have to be qualitatively different for those assumptions to hold. In my experience, they are; essentially, you're making a large upfront cognitive investment in order to save slight amounts of mental overhead every day.

AnimalMuppet3• 11 years ago

I think you just refuted the article.

Offloading the constant checking of that consistency, in any amount, to a computer, is a huge win that compounds quickly over time.

True. And therefore offloading a less amount to the computer (by being mostly but not totally functional) is less of a win, but still a win.

jimbokun• 11 years ago

"And in the example with the try-catch I would have wrapped it around the loop anyway."

It's very likely that, in reality, you would forget the exception could be thrown until it happened in production.

So the advantages of the Haskell type system and purity guarantees, I think, often come down to the compiler preventing you from making certain errors that don't surface in other languages until you run the program. (Disclaimer: not a Haskell programmer.)

maehwasu2• 11 years ago

The example of the exception being thrown late (essentially, an exception being a type of side-effect) is quite good.

Would it be fair to say that this is an advantage of the Haskell approach of (for example) encapsulating an operation that might fail inside a Maybe? You get to make the failure aspect explicitly part of a monad, and make sure you "know" where it's happening?

TazeTSchnitzel20• 11 years ago

Well, Haskell also has something similar to the more traditional exceptions within the IO monad (ioError).

j-pb2• 11 years ago

Here's your perfect counterexample.

The only language that allows you to build things that won't fail even when the hardware breaks.

Erlang.

TazeTSchnitzel20• 11 years ago

Even when the hardware breaks? What?

If radiation hits the CPU, Erlang won't save you.

klibertp3• 11 years ago

It will, if by "Erlang" you mean "language + set of libs + set of conventions (all of this battle-tested for years)".

In short: (some) Erlang systems have backup hardware and support moving running systems from one machine to the other (or one cluster to the other, etc), achieving very high "uptime" values.

r0naa• 11 years ago

It would be nice if you could add a citation, or elaborate a little bit!

vezzy-fnord• 11 years ago

I think the parent poster's point is more that the article's extensive focus on side effects and monadic encapsulation as the central concern for reliable software engineering is short-sighted, as Erlang is a dynamically typed impure functional language that nevertheless is robust in its use of multi-node distribution, supervisor trees, sophisticated error/exception models, scheduling guarantees, SMP, dynamic code upgrade as first-class VM constructs, as well as the language itself being homoiconic and driven by a small number of basic data structures (tuples and lists).

The language's module system offers namespacing and then the OTP framework implements standard behaviors that have (in gen_server's case) state calculation, supervision, code change, termination and messaging callbacks all exported.

I presume "surviving hardware failures" was in reference to native Erlang epmd machine distribution, which is intended for fault tolerance and based on heartbeats. It's one step further than most languages go.

Ultimately, there is much more to be considered than state and side effects.

hueving• 11 years ago

What? The only possible way that constraint could be satisfied (working under any hardware failure) would be if erlang didn't let you write any programs that did anything.

fnordsensei• 11 years ago

Excuse the aside, but this reminds me of this old Bash quote:

  <FreeFrag> The most secure computer in the world is 
             one not connected to the internet. 
  <FreeFrag> Thats why I recommend Telstra ADSL.

Also, agreed. Some elaboration on that point would be most welcome.

thyrsus• 11 years ago

The argument is that Erlang (and its OTP environment) gives you the tools to distribute your system in such a manner that hardware failure is observed and that the failed portion of the system is restarted elsewhere. The granularity provided is better than most STONITH models. It provides a lot of help, but one still needs to make an effort to assure that, e.g., merchandise is not sent unless an invoice is generated.

STONITH: https://en.wikipedia.org/wiki/STONITH

marcosdumay7• 11 years ago

In theory, Haskell could do that too.

Some people even started a fork of GHC aimed at cluster parallelism a few years ago, but I don't think they got it working.

davexunit6• 11 years ago

I don't buy this. The paradigm I use often depends on the level of abstraction I'm working with. A functional runtime is ultimately built upon an imperative foundation. I write mostly purely functional code in Scheme, but from time to time I add my own imperative components to the foundation. I don't really want to use languages that restrict me to a single paradigm.

TazeTSchnitzel20• 11 years ago

A functional runtime is ultimately built upon an imperative foundation.

Not necessarily. Functional language compilers are very sophisticated and do not necessarily compile code the way you might think.

knz42• 11 years ago

The functional runtime (i.e. not compiler) is built upon an imperative foundation. This is necessarily so as long as hardware computer are built upon state-modifying processors and random access, in-place updatable memories.

davexunit6• 11 years ago

That code is ultimately compiled to run inside of a register machine. A language may give you a functional interface to something like disk I/O, but the underlying implementation is inherently imperative. Or how about the purely functional programming language Elm, whose runtime is imperative JavaScript?

For the record, I prefer purely functional programming, but it's not the only tool in the tool box.

DanWaterworth2• 11 years ago

A functional runtime is ultimately built upon an imperative foundation.

Memory safe languages are ultimately built upon an unsafe foundation.

davexunit6• 11 years ago

Sorry if I'm being dense here, I understand the pattern of argument you're using, but I just don't understand what point you were trying to make. Could you explain?

TazeTSchnitzel20• 11 years ago

but from time to time I add my own imperative components to the foundation

Why? Do you not know how to perform a specific task within functional code?

In which case, you should probably take that opportunity to find out how to do it.

davexunit6• 11 years ago

Do you not know how to perform a specific task within functional code?

It's not that I didn't know, it's that the process was imperative at its core. For example, I am working on a rendering engine using OpenGL. The high-level scene graph interface is purely functional, but rendering such a scene graph is an imperative process: binding textures, vertex arrays, shaders, writing to a framebuffer, etc. This low-level rendering code is the functional runtime for the high-level API.

mpu2• 11 years ago

I find it hilarious that all the examples he gives in the beginning have weird semantics only because of LAZINESS, mixing effects with laziness gives nonsense, give a cbv semantics to the language and you get the intended behavior (intended even by HIM who is arguing for laziness). Unbelievable.

Edit: in my comment, oppose pureness (that is put forward in his rant) to laziness (what he unintentionally is arguing against).

TazeTSchnitzel20• 11 years ago

Laziness is just one way you'd see that issue crop up. It's merely an example of the dangers of functional programming in a language with side effects. When you compose functions, you have to be very careful that they either 1) have no effects, or 2) have very predictable and controlled effects. This isn't a problem you can have in a purely functional language, because it's a compilation error.

Also, it's not an argument against laziness. Laziness is fine in a purely functional language. It's one of the things that makes Haskell so pleasant.

tome5• 11 years ago

And yet the first example is in C# which is not a "lazy language". The problem is that in any language you do want lazy behaviour from time-to-time. For example in "get me the first element of this list that is positive" you do not want to traverse the rest of the list after you find your positive element. Laziness always has a weird interaction with effects and you always want (the potential for) some laziness, hence the problem.

marcosdumay7• 11 years ago

1 - Why would you ever want to add a logger to a pure function?

2 - If you really, for some unknown reason, wants to do that, you can pass the logger as an argument to f2, and have it run inside the IO monad somewhere outside of that fragment. But really, read #1 first.

qznc3• 11 years ago

What if you could do "fully functional" programming within a language that also allows OO, procedural, and generic programming?

My exhibit would be D. Here is the 'identity' declaration:

    T identity(T)(const T me) pure nothrow @safe @nogc;

It cannot have side effect (do IO,start a thread,etc) because "pure". It cannot throw any exceptions because "nothrow". It cannot do any pointer-magic shenanigans because "@safe". It cannot modify the argument because "const". It even guarantees that no memory will be allocated through the garbage collector because "@nogc".

(Yes, pure by default etc would be better, but such a change would break too much code at this point. Yes, Haskell looks cleaner, but this article is not about beauty.)

TazeTSchnitzel20• 11 years ago

How does "pure" work? How does the D compiler know the functions it calls do not have side effects?

More importantly, however, D's type system is not as expressive as Haskell's.

qznc3• 11 years ago

Pure functions can only call pure functions.

Details: http://dlang.org/function.html#pure-functions

And Haskell's type system is not as expressive as D's. E.g. records.

mpu2• 11 years ago

But what a type! I would be much more inclined to annotate effectful code instead.

qznc3• 11 years ago

Well, it can be done simpler. The D compiler can infer those annotations for template functions such as this. So with an implementation you can write:

T identity(T)(T me) { return me; }

bjlkeng• 11 years ago

One thing that bothers me with these articles is how they never address the software engineering challenges of writing large complex systems in a pure functional style. There are some tasks where just adding a sprinkle of imperative programming can make the design of the entire system much easier to understand (a kind of "mostly functional"). An article that really crystallized this point is here:

http://prog21.dadgum.com/54.html

TazeTSchnitzel20• 11 years ago

That post's been on HN before. I don't know if it's really making a good point.

Imagine you've implemented a large program in a purely functional way. All the data is properly threaded in and out of functions, and there are no truly destructive updates to speak of. Now pick the two lowest-level and most isolated functions in the entire codebase. They're used all over the place, but are never called from the same modules. Now make these dependent on each other: function A behaves differently depending on the number of times function B has been called and vice-versa.

This is a complaint that the programming language is preventing you from introducing a hidden dependency. This is a strange complaint, given that hidden dependencies are a problem in software maintainability.

I mean, yes, it's convenient now to be able to "just" add global state here and there, but it will come back to bite you later.

[Single-assignment form] is cleaner in that you know variables won't change. They're not variables at all, but names for values. But writing [single-assignment form] directly can be awkward.

Well, you don't have to write single-assignment form functional code. If you want to modify state within a function in the same way we all know and love from C, you actually can do that. In Haskell you could do this with the state monad, for example. Purely functional programming enables the composing of operations in many different ways, so you actually have a huge amount of freedom in what style you write your code.

For me, what has worked out is to go down the purely functional path as much as possible, but fall back on imperative techniques when too much code pressure has built up. Some cases of this are well-known and accepted, such as random number generation (where the seed is modified behind the scenes), and most any kind of I/O (where the position in the file is managed for you).

Random number generation doesn't require threading the seed if you really don't want to. In Haskell, for example, you can also:

* Generate an infinite list of random numbers

* Call the IO monad function to get a new random number, which advances the generator behind-the-scenes

While the author might have a point that some things are simpler in imperative code, I don't think their examples really support this. Perhaps they had not delved very deep into functional programming.

agumonkey2• 11 years ago

I wish I could find that article again, it's just a claim in a comment at that point but that guy said his team rewrote a c++ system deemed first in class / world class (real time trading or something close) and unbeatable by its 30-years-in-the-field authors. Yet the F# (IIRC) was smaller AND faster, because they had better abstractions to describe the system, find and solve bottlenecks while the previous team members were drowning in c++ LoC and hubris.

stewbrew• 11 years ago

It's funny to read this from somebody who called scala "his new love".

visarga3• 11 years ago

He's still soul searching.

bitL2• 11 years ago

I would suggest the following:

- write all functions related to math/geometry/combinatorics in pure functional style, even better with accompanying mathematical proofs to be sure they are principally sound (you won't avoid problems with floating numbers etc. that way)

- think about using functional programming in parallel/distributed tasks if you can manage communication complexity directly (i.e. this is not handled to you by some opaque, un-debuggable monad)

- write everything else in imperative style of your choice

I/O is the elephant in the room of functional programming, monads are "imperative" hacks to make functional programming useful in any real-world-related way, and most monad tutorials will only confuse you about what they are actually.

visarga3• 11 years ago

I found that as I was learning functional programming, I started changing the way I was writing code even in imperative mode. I was separating things better, programs became more semantic and there are many opportunities to use functional style, but I still think imperative code is faster and easier to write for small functions, up to 20-30 lines of code.

Also, because it is so similar in a way, I learned a new appreciation for unix pipes and the shell syntax for composing programs.

I will continue to learn FP just to upgrade my programming skills.

TazeTSchnitzel20• 11 years ago

monads are "imperative" hacks to make functional programming useful in any real-world-related way

Monads are a quite clever solution to control IO: instead of allowing functions to directly perform IO, allow them to compose a sequence of IO operations and return them, such that you can compose a program which the runtime will then execute.

They're not imperative: they represent programs in a purely functional way, and they don't let you opt out of any of the guarantees a purely functional language provides. And they're not a hack, they fit properly into the type system.

Unlike "mostly functional" programming, use of monadic IO in a purely functional language will force you to cleanly separate IO and computation. Not only does this make a more maintainable program (no side effects everywhere), but you get nice bonuses, like lazy computation.

and most monad tutorials will only confuse you about what they are actually.

Perhaps because many monad tutorials try to hide how they work, despite this really being quite simple.

klibertp3• 11 years ago

use of monadic IO in a purely functional language will force you to

have `unsafePerformIO` in the language.

viraptor5• 11 years ago

I've been very excited by many approaches before, then Haskell, and now I'm past it. While pure functional language will force you to cleanly separate computation and IO, with an app big enough you'll find yourself one day in a situation where independent data from 3 different places comes together in a way that the only reasonable way to proceed is to log a warning, tweak the value, and continue the computation. And that's what you'll do in any unpure language. In a pure one, you'll start to think how to redesign the computation to allow this... It's not wrong, but in many cases it's pointless.

dragonwriter2• 11 years ago

Monad tutorials are a problem because they try to teach you to play football without first learning to walk. Progressive tutorials/introductions on the category theory constructs leading up to and including monads are better.

polymatter• 11 years ago

do you have any recommendations on such tutorials/introductions that teach category theory?

bitL2• 11 years ago

The problem is that category theory is "elitist", i.e. most programmers aren't equipped to comprehend even the basics properly if they didn't study theoretical computer science, computability theory, recursion theory etc. or even philosophy :-(

coldtea5• 11 years ago

Condidering that

1) mostly imperative programming has worked wonders for ages with a huge body of work to show for (almost every basic infrastrcuture, all major OSes, almost all popular programs etc are writen in one of C/C++/Pascal/Obj-C/Fortran/Ada/Java). Might have its security and stability warts, but it has shown pragmatic results.

2) "fully functional" might have its security and stability assurances, but it has little of importance historically to show for all its boasting (the AI winter is not something to be really proud of).

I'd call BS, and say that "mostly functional" works fine, thank you very much, in that it takes (1) that already works (with some issues) and makes it even better with a touch of (2).

tincholio• 11 years ago

Did you even read the article? His point was that introducing some functional features to imperative languages do not confer them the safety benefits found in type systems such as Haskell's. It has absolutely nothing to do with pragmatism or any such thing.

coldtea5• 11 years ago

Did you even read the article?

I did, did you?

His point was that introducing some functional features to imperative languages do not confer them the safety benefits found in type systems such as Haskell's.

And my point was that I don't want ALL the safety benefits found in type systems such as Haskells. If I would, I would be using Haskell. Or rather, while I might want it, I also want other things more, so I wouldn't sacrifice all of them to get it.

His point was that mostly functional "does not work" which is a BS thing to say, because it's an absolute statement. And his whole article revolves around that absolute, e.g.:

The idea of "mostly functional programming" is unfeasible. It is impossible to make imperative programming languages safer by only partially removing implicit side effects.

Nope, you can very much make them safer. It might not make them the "safest" it can be, but it can totally make them safer. Even merely substituting for loops with map and fold will eliminate lots of potential bugs.

Heck, you can even make C much safer by just removing pointer arithmetic or just adding a built-in string type. Either of those two things alone would eliminate tons of bugs while the language would remain the imperative thing that it is.

AnimalMuppet3• 11 years ago

It has absolutely nothing to do with pragmatism or any such thing.

Yeah, well, for those of us who actually write programs, pragmatism matters a lot. If you're going to tell us how we should do it, but without anything like pragmatism, you're not going to get much of a hearing from the people you think you're trying to talk to.

bumeye• 11 years ago

I think the author means to say that it's kind of an all or nothing thing. You either go purely functional and get all the benefits, or you don't and barely get any benefits at all.

You could say that "almost functional" does not really exist, just like "almost secure" does not exist.

And yes, you can still program with a non-functional language just fine he does not refute that.

coldtea5• 11 years ago

I think the author means to say that it's kind of an all or nothing thing. You either go purely functional and get all the benefits, or you don't and barely get any benefits at all.

Yes. And what I say is that "I get enough benefits from going halfway functional, thank you very much".

You could say that "almost functional" does not really exist, just like "almost secure" does not exist.

You could say that but you would be wrong. Most Lisp coders for example have also used imperative code where they need it, with side effects and all. Nobody cared much about such total "functionalness" and purity as you get today from Haskell programmers (most of them non professional of course since there are far more Haskell programmers than Haskell jobs) and the like...

ksherlock• 11 years ago

ahem pure lazy functional. One could read the article and walk away believing that laziness is the problem.

commentzorro2• 11 years ago

Every time I try to play with Haskell I give up in just a few days. Too much math! Maybe you don't need a PHD, but from my perspective you do need more than an undergraduate in Engineering.

So, what's a good purely functional language that's easier to learn than Haskell. One that I can learn more by hacking about than trying to keep so many things juggling about in my memory all at once?

Ideally one that runs native on Windows and Linux and is suitable for web and business apps? So I might actually end up with something I could put in (light) production.

octatoan• 11 years ago

Have you tried Learn You a Haskell? I think it doesn't need more than a little previous programming experience.

erokar• 11 years ago

Check out Elm. Only for Web though.

kyllo• 11 years ago

Maybe you don't need a PHD, but from my perspective you do need more than an undergraduate in Engineering.

You just need a lot of patience. Learning Haskell takes a lot more than a few days. But it's worth it.

Haskell is the only industrial-strength purely functional (i.e. referentially transparent) programming language. The other popular functional languages (SML, OCaml, F#, and various Lisp and Scheme dialects) are all impure--they all have type systems that allow side effects anywhere in your code.

Haskell does run on Windows, Mac and Linux and is suitable for web and business applications. It has several fully-featured web programming frameworks: https://wiki.haskell.org/Web/Frameworks

I am using Yesod and I highly recommend it. It's like Ruby on Rails except the compiler automatically typechecks everything when you make a code change and tells you if you messed up. It is virtually impossible to even have a broken link.

cschneid• 11 years ago

Don't confuse new terminology with math. Programming has lots of terminology, and some of it is backed by mathematically rigorous definitions, but that doesn't require you to know that in order to use them.

OO has 'Inheritance', 'Subclassing', 'SOLID', 'Liskov', every design pattern name, 'Object', 'Class', 'Overloading', 'Factory', etc, etc.

Haskell has similar words, covering both core concepts, and common patterns of implementation. 'Monoid', 'Monad', 'State', 'Reader', 'Function', 'Lambda', 'Typeclass' are all examples of terminology in Haskell

None of those words are inherently more difficult than the OO ones, you're just not familiar with them.

The best way to learn Haskell is to follow along with a course that has you do exercises, and actually do the exercises. See the https://github.com/bitemyapp/learnhaskell course for some class recommendations.

commentzorro2• 11 years ago

Not just terminology. It's more like there's only two levels of Haskell: first it's understandable and I say, "Okay just step by step and I got this. Then all of a sudden we run smack into something like this big wall of WFT:

  * The infix application function (ma>>=\a->f(a)), commonly called bind, executes the computation ma to expose its effects, calling the resulting value a, and passes that to function f. Evidently, the result of this application (f a) should again be a potentially side-effecting computation; hence, the type signature for bind looks like this:

  (>>=):: M a -> (a -> M b) -> M b.

  * The injection function (return a) injects a pure value into a computation. Its type signature is: return :: a -> M a.

  In practice, each effect usually comes with so-called nonproper morphisms. These domain-specific operations are unique to that effect ...

Seriously, how can I hack around and understand this?

bunderbunder4• 11 years ago

This article's core premise, given in the first sentence, strikes me as a blatant straw man.

Normally I've seen mostly functional programming being sold as a pragmatic solution that merely gives developers some tools that are helpful in certain situations. It's deeply uncharitable to suggest that users of multiparadigm languages are so naive as to believe that the mere presence of paradigm A erases the pitfalls of paradigm B.

I'm also deeply suspicious of any language evangelism that makes a whole lot of noise about the pitfalls of other languages and then implies that one's own favored language has no pitfalls whatsoever. This one just comes down to Occam's razor. Which is more likely: That your favorite language just happens to be the first perfect, wart-free language ever invented, and its relative lack of popularity is just because the rest of the world can't recognize its blinding awesomeness? Or that you've become so attached to your favorite language that your perception of it has become deeply biased?

white-flame• 11 years ago

The specific strawman that is being presented is the free intermixing of functional and imperative. We have really nice codebases where the execution of side effects is specifically constrained to known locations.

From an optimization perspective, imperative behavior can be introduced if the functional API is not affected. Caching systems fall into this category. The functional benefits and freedom of usage is not impeded; the difficulty of creating and optimizing a caching system is the same as any other project.

Any quality from a project comes from discipline. Even purely functional programs can become unwieldy spaghetti with copy/paste code, memory leaks, etc. It's less about the programming languages, and more about proper experienced perspective of what to do and how to design.

bunderbunder4• 11 years ago

C# is a language where functional and imperative are freely intermixed, most notably through the LINQ library that shows up in some of the author's C# code examples. The purpose in doing so is not to constrain side effects. It's to make code more declarative and enable the use of compositional patterns.

I think that's where the article really comes across as tone deaf. If you're going to write an article with a title like, "Mostly functional programming does not work," then you better be prepared to demonstrate that mostly functional programming fails accomplish the thing it sets out to do. Instead, what he really demonstrates is that he fails to understand that there are desirable things about functional programming aside from purity and laziness. Which is in itself a rather fascinating thing to miss considering that the majority of functional languages are neither lazy nor pure.

chaoky• 11 years ago

Scheme is not "fully functional". Neither is Common Lisp. No one will say they are mostly imperative either. But they work; before AI winter there were many machines and OS's built on top of them and their immediate predecessors.

If this author's definition of "does not work" means that they can't be used to build operating systems or high level AI programs well...

dang• 11 years ago

Previously: https://news.ycombinator.com/item?id=8084302, https://news.ycombinator.com/item?id=7654601.

AdieuToLogic2• 11 years ago

Reading many of the comments in this thread reminds me of Plato's "Allegory of the Cave":

http://platosallegory.com/TheStory.aspx

Food for thought and all that.

“Mostly functional” programming does not work (2014)

Related Stories