Hacker News Reader

Comment by eutectic | Hacker News Reader

Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages.

Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness.

The real problem with OOP is not that it forces you to do things a particular way, it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad, and what's good about it (encapsulation, polymorphism) is not new.

View on HN

The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them.

For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language.

Things OO languages 'force' us seem to be relatively easy to use: sending a message to a certain object, thinking in categories (elephants, houses, chairs, moveable objects, ...), state (position, speed, size, shape),... Thus it is not surprising that the overwhelming majority of software written in the last 10 years has been written in OO languages.

I work in a group of teams that is mostly new college grads and nobody has trouble writing pure FP business logic in Scala. We don't go as far as doing pure FP for all effects though (although we are starting to do that more as well)

If we can do it, so can everyone else ;)

They come Berkeley and MIT, colleges that are renowned for teaching functional languages in their intro to programming courses, don't they.

Nope we mostly come from either state schools of our original residence or small liberal arts schools. I know of two hires from those schools, and I am the one who taught them pure typed FP.

I'm the only one who came in knowing pure FP at all and I didn't learn it via classes.

That's a bit biased. Berkeley and MIT students are pretty pragmatic, and are not typically FP enthusiasts (as in, many aren't even if some are on their own accord). Many European universities have more of an affinity to FP, comparatively speaking.

I went to a state College (Mizzou) and everybody I knew that was in a CS degree took a Haskell course.

Err, not exactly, Berkeley and Mit use python now and have been for a while.

I can't speak for MIT but Berkeley has essentially translated SICP material to Python and then you have to write a Scheme interpreter.

Students there have more FP experience than most.

In my experience, business logic is often relatively easy to express in pure FP. Where things start to get trickier is the boilerplate and boundaries, e.g. I'm writing a Rails app at the moment where the business logic is in pure functions, but the boundaries with other systems like ActiveRecord and external webservices tends to end up being more object-oriented.

For example, the ruby library I use to connect to webservices is very OO, and requires you to derive from its base class to build each webservice client.

This is of course very natural in Ruby, but I do see lots of OO in Scala libraries too (e.g. Spray).

> In my experience, business logic is often relatively easy to express in pure FP.

Agreed. This makes it a pretty easy sell to get everyone to commit to using immutability and purity and all those nice things in the business logic layer.

> Where things start to get trickier is the boilerplate and boundaries, e.g. I'm writing a Rails app at the moment where the business logic is in pure functions, but the boundaries with other systems like ActiveRecord and external webservices tends to end up being more object-oriented.

We're in the same boat, except in an in-house Java-based service framework. The "shell" of the program reads from the DB/makes service calls to gather input, passes this input to the pure business logic layer, and then based on the output throws exceptions, writes to the DB, makes other service calls, etc. This conscious division between effects and logic alone makes programs better.

In areas where we need concurrency or have more complicated effects we wish to unit test, we have started to use scalaz.concurrent.Task and scalaz.Free.

To what extent does the proving of theorems about your code play in your development process? I ask because that was singled out as one of the main reasons for using functional languages by Eutectic in the comment that started this sub-thread.

I'm going to answer this question in the larger scope of "how does pure FP help us be confident that we are pushing correct code to production?"

"Prove it" is our first line of defense. By always writing total functions, we can be confident that our services and jobs don't fail in uncontrolled ways. "Proving of theorems" is what you end up doing as you write total functions. NonEmptyList, ADTs, Options, Coproducts, These, singleton types, sized collections. All these things can provide powerful proof that is used to write total functions. The proof that various types provide makes it easier to write total functions as we can use Scala's powerful type system to greatly restrict which programs we even have to think about. And (thinking in reverse), forcing yourself to write pure, total programs ends up forcing you to prove various things about your program in order to achieve those properties.

So all in all, we perform the "proving of theorems" all the time. It just doesn't look or feel like it. But a large portion of CR discussion is about the types used in a program, which is in effect a discussion about which theorems we think we should prove before we push the code to production.

I would argue this is inertia and a hype train that never slowed down -- up until the last 2 or so years that is.

I do agree with you that thinking in FP takes a bit more experience however.

Actually, from what I've seen, pure FP forces people with less experience into design and structures of their code that they'd only do in imperative settings with considerably more experience.

Eg when I asks students to do some simple exercise like "write a function that finds the shortest path through a given graph", in impure languages their solutions tend to return a path if they find one, but just give up with eg a message printed to screen when there's no path.

In pure and types languages, I see more people reaching for a Maybe or Either return type to express that the function as asked for might not succeed.

Funny choice of exmple, the algorithms I am aware of for finding shortest paths require mutable vertices that store the scores and pointers (edges) for the best part found so far.

No doubt there ways to do it in a pure functional language -- but that requires a bit of thought. Compared to that difficulty, this business of return values seems trivial.

Worse, a language that forces people to Do The Right thing, might be acceptable for experienced programmers who want to work within that limitation. But when given to student, it just encourages closed minded rule-following.

> Worse, a language that forces people to Do The Right thing, might be acceptable for experienced programmers who want to work within that limitation. But when given to student, it just encourages closed minded rule-following.

Citation needed. I find the safety net of that kind of language empowering: I can concentrate on thinking about the actual problem, and be confident that the language won't let me shoot myself in the foot.

> [...] the algorithms I am aware of for finding shortest paths require mutable vertices that store the scores and pointers (edges) for the best part found so far.

No problem. Traditional loops with mutable variables translate straight-forward to tail recursive calls, if you want to write your algorithm like that.

Though actually my argument was less about not mutating your functions internal variables---but about interacting with the world outside your function via a well defined interface. (In this case, via arguments and returned values.)

The most 'mainstream' language that encourages such a strong adherence to declared interfaces is Haskell. But the imperative D can do something similar:

"In a slightly less precise way, this means that pure functions always have the same effect and/or return the same result for a given set of arguments. As a consequence, a pure function for example cannot call other impure functions, or perform any kind of I/O (in the classical sense)."

http://klickverbot.at/blog/2012/05/purity-in-d/

>Worse, a language that forces people to Do The Right thing ... just encourages closed minded rule-following.

I think experience shows that freedom to do the wrong thing frequently leads to the wrong thing happening. There are many case studies to be found in security and concurrency.

I'm sure you're right. Apologies for me misleading. It appears I'm twisted by years of OOP during the start of my career.

Haha. No worries. Mine is also just an observation I made with the few people I'm mentoring and teaching.

Also, they seem to grasp recursion much better via Haskell than in Python or Java. I believe that's mostly because Haskell makes structural recursion real easy (ie recursion along the structure of your data type, eg like along a tree)---and once they are comfortable with the basic idea from that, other patterns of recursion are easier to understand.

Algebraic datatypes and pattern matching on them are a great benefit for that structural recursion.

The majority of software written ever has been written in the world's most popular functional programming language: Excel.

Yes but the majority of excel sheets consist of calculations. The source code of many OO programs will also consist of pure functions if that program is focused on calculation. So calculations are easy to express as pure functions, everybody knows that.

On the other hand, if you want to make an interactive application in excel you use VBA which exposes a large and rich set of objects.

>On the other hand, if you want to make an interactive application in excel you use VBA which exposes a large and rich set of objects.

Please don't encourage this. Because honestly debugging VBA written by consultants has definitely shortened by lifespan by a couple years

Yes, VBA is a break away from the nice purely functional world of spreadsheets.

Simon Peyton Jones once did some work on giving Excel more programmatic power without having to go to VBA.

http://research.microsoft.com/en-us/um/people/simonpj/Papers...

The paper deals with more examples of calculations: convert fahrenheit to celcius, calculate volume. It does not cover interactive applications. I hope you are not redefining the problem to fit the solution which can be a weakness of pure mathematicians and functional programmers (and negative though it is I have to add: Its a waste of everybody's time. It would be much better if people were direct about what their solution addresses instead of leaving it vaguely defined in the hope that people will think it is of practical use for more than it actually is)

Yes, Excel is limited. Yet, people manage to solve lots of business relevant problems within its constraints.

Excel is very interactive: you can change input and immediately get a different output. (I think you were trying to talk about a different restriction. Excel is very limited in the kinds of inputs and outputs you can make, and even more so in the kind of side-effects you can cause.)

99.99% of what people do with Excel does not qualify as "software", unless you classify "A1+C3" as "software", in which case calling it "functional" becomes meaningless.

In that sense Excel is comparable to Bash.

Oh God, if you saw the Excel workbook my previous boss created as the back end for the financial calculations used in all our applications you'd scream in horror. Like just about every contingency in the process was done within the excel workbook and not just as a wrapper around some simplified formulas.

There are things that are painful to express in a pure functional language. I'll give you an example: rasterize a triangle to a mutable buffer. (An inherently mutable and stateful algorithm). You can certainly do this in a purely functional language, but I doubt it will be any clearer or more performant than its procedural C counterpart.

I think pure functional programming is super useful in other contexts, for instance, a compiler. I'm weary of people suggesting that a specific school of thought is universally applicable, though.

While I agree, within the same context, I want to point out that right next to rasterization you have shaders, which are a poster child for functional programming.

A vertex shader just transforms an input vertex (and some other inputs) into an output vertex, and a fragment shader just transforms an input fragment (and some other inputs) into an output fragment. This is done at a scale so massively parallel that we have dedicated hardware for it, because your CPU doesn't have enough parallelism.

Sure, HLSL and GLSL are locally procedural. The most recent fancy versions ofo them even allow for some shared state mutation within a thread wave, useful for certain niche uses. But in in their traditional contexts? I find even local mutation for most use cases to merely be a source of bugs and obfuscation via poor naming. And most of the built-in functions are pure.

> Sure, HLSL and GLSL are locally procedural.

Just wanted to add that shaders lend themselves very well to the functional / dataflow paradigm. There are numerous visual node-based shader editing tools where you construct shaders from blocks, which essentially are pure functions.

> Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation.

And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is true of statically typed OO also).

> The real problem with OOP is not that it forces you to do things a particular way, it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad, and what's good about it (encapsulation, polymorphism) is not new.

Encapsulated state has its own benefits and drawbacks (having explicit unencapsulated state limits reuse as they are reflected in type signatures), and anyways, is not unique to OOP (any commonly used language sans Haskell supports encapsulated state). The only way to get encapsulated state in Haskell is World -> World, which would pollute all function signatures it buried through (there is some good work in parametric effect systems, but its still early).

OOP also is not very new, being formed from the culmination have patterns used in the 70s, and is about the same vintage as FP.

Any sort of thinking about what the code does or does not do is essentially proving theorems about it, is it not? It seems to me one does that all the time when debugging.

I don't think about coding that way. To me debugging is more like a Sherlock Holmes investigation rather than a formal theorem proving process. I guess we maybe work on different kinds of programs.

You're still, at some point, simulating the steps of some abstract machine in your head to understand what the debugger is telling you.

The simplest case is replacing an expression with its value, given an environment of lexical bindings that are apprent from the source program. Not much investigation necessary. That's FP.

For OO code, you just need to keep track of a lot more context: the state of the receiver of the currently executing method, its heirarchy of parent classes, the runtime class of each object because late binding is pervasive. Of course you can write code that doesn't use any OO features, but the languages clearly aren't designed for it. See: any number of "functional C++" articles.

And, of course, you can get the same kind of highly dynamic behavior in FP languages by explicitly using open recursion, higher-order state and hiding everything behind existentials. But very few codebases do that because the vast, vast majority of the time just one of these features is enough to solve a problem.

OO context is internalized linguistically, via lots of metaphors. Those metaphors can lie, of course, but your brain can apply abstractions to the state of the machine to deal with its complexity, for better or worse. Ideal FP debugging, which I don't think exists in practice, relies on ultimate truth with equational reasoning realized through techniques like referential transparency. In the ideal case, you just reason about the equation and there are no hidden surprises, fuzzy metaphorical reasoning is minimized. In practice, there is still plenty of metaphorical reasoning going on for any non-trivial program as even explicit state necessarily becomes implicit as it increases in quantity (our brains can't handle seeing everything even if it is technically all in front of us).

OO thinking optimizes for the less ideal cases that are far more common. Ideal FP has this ideal mathematical view of the world that rarely pans out in practice, while less ideal FP just resorts to OO-style metaphors and abstraction in practice. For the kinds of experiences I work on (heavily reactive, lots of state, complex interactions), this works well for me, and we are developing techniques to make it less painful (live programming). "Worse is better", as RPG would say.

It sounds like we agree that lexically scoped immutable values are easier to understand, either precisely or with fuzzy metaphors. I'm not sure what "ideal" FP is or how it might have a certain "mathematical view of the world". The features I mentioned are just a subset of semantics that every high-level language programmer already knows, but are pointlessly hobbled in popular languages.

Why should expressing something basic like a tagged union require a detour through the quirks of a particular object system? Ditto for polymorphism, modularity, etc, etc. Clearly we disagree on how useful objects really are in practice, fine. Why not add these domain-specific features on top of a core language with simple semantics? It worked fine for lisps. Luckily, after a couple of decades of "everything is an object!" nonsense, that seems to be where newer languages (Rust, Swift) are headed.

You mean CLOS? This is exactly the context RPG coined "worse is better".

Languages are not so much a collection of features but mindsets. So polymorphism, dynamic dispatch, subtyping, etc...do not define OOP so much as they are leveraged by those languages to enable reasoning with names and metaphors. Calling them just domain specific features misses the point like talking about some dish only as the sum of its ingredients.

Tagged unions and GADTs are quite different in expressiveness and modularity, I still remember the mega case matches used in scalac. Should one function really be given so much functionality when a layered design with several virtual method implementations would be much more amenable to change and modular reasoning? Well, I guess it's a matter of how you view code.

  Languages are not so much a collection of features ...

If you want to define objects precisely, even just to have a language spec, they are absolutely made up of sums, products, recursive types, etc. Whatever useful metaphors one might have to work with objects doesn't change what they actually are. If you give the programmer access to these building blocks, you get ML.

  Calling them just domain specific ...

I meant that the particular way they're combined to get OOP is domain-specific.

Again, I'm just asking: why mess with the basics? Why require encoding simple, universal concepts in terms of an ad-hoc object system? You can still have an object system on top, if you find that helps with the really complicated cases, but why encode the parts of your code that are simple in terms of much more complicated, derived concepts?

Debugging is a time to stop thinking and start looking.

Thinking is probably what got you the bug in the first place, so to kill it a different angle is usually preferable.

In practice, this means sending in test data to see what happens and/or stepping through the code to see where it diverges from what we think it does.

The "proving theorems" stuff is definitely overstated. People always toss that term around, and it's true in principle, but in practice hardly anyone ever uses correctness proofs in real world code.

But to flip it around and make a less grandiose version of the same point: the majority of bugs are to do with state. (I don't actually know if that has been "proved" but it's definitely what I find in practice!) Pure FP gets rid of a whole swathe of potential bugs at one stroke. Of course it makes programming harder in some other respects, as often it can be hard to figure out a pure function that's as efficient as the obvious imperative algorithm, or even to figure out how do a state-y thing in FP in the first place.

I agree with this mostly. You can get rid of state in OO programs, and that often involves a bit of functional programming. Struct/values in C# help a lot in keeping the performance up (well, if GC is a problem, you can also inline your closures to prevent boxing...lots of crazy things like that). Essential (rather than accidental) state is impossible to eliminate in any case.

Yes, I think just trying to use an FP style where possible is a great approach.

As a weaker form of going around and proving stuff: people do care a lot about properties. We just check them via QuickCheck, instead of formally proving them.

And we organize our programs such as to get nice properties.

If you ask me what's the opposite of "proving", I'd say it's "testing". You call that "weaker"? It's the weakest form of validation I know of.

It may be weak, but by hell it's practical. Tons of tooling, tons of engineers who understand it, and with a pragmatic approach, eliminates many bugs and regressions.

And automatically testing lots and lots of examples gets you closer in spirit to proving than example-based vanilla unit testing.

> And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is true of statically typed OO also).

"What the type system can provide for free" isn't static. Part of working in that kind of language is structuring your code such that important properties end up being proved by the type system.

It rarely rises to the level of a "theorem", but "is this piece of code equivalent to this other piece of code?" is what I'd venture to suggest programmers spend most of their day asking, and Haskell-like languages make that easier to answer.

> "is this piece of code equivalent to this other piece of code?" is what I'd venture to suggest programmers spend most of their day asking, and Haskell-like languages make that easier to answer.

It is a boring question to ask, and one that doesn't come up much in my work. Does this mean Haskell-like languages are not appropriate for my domain?

It means your domain is alien to mine, and I can't tell you what is or isn't appropriate.

For me programming is about automating some business process or at least something you already know how to do, so it's a case of: 1) transcribe the doing into plain code 2) factor out patterns/redundancy in the code. (In practice this is interleaved, and 2) results in building up a language for expressing the domain in code which in turn simplifies 1) - indeed, when adding new functionality it's often a case of first transforming the current code into a representation that makes the new functionality simple). 2) is where the vast majority of the work lies and what takes up the time. Just as good writing is good editing, good coding is good refactoring. At least in my domain.

I do research working on new experiences, like live programming environments. Nothing is really known, there is no spec, everything is a design prototype, code is disposable in a fail-fast kind of way. So I'm pretty extreme, I can see where other domains are very different.

> And how often does that occur in practice for most of the programs people write?

Very frequently. The simple theorems that equational reasoning supports are very convenient for refactoring and optimizing code. Understanding components in isolation is useful for testing, isolating bugs, and refactoring of subprograms independently from their contexts. Since I do testing and refactoring frequently, I make good use of what FP offers.

Sure, this isn't equivalent to full 'correctness' proofs. The lightweight equational reasoning FP offers for expressions and behavior doesn't prove you have 'correct' expressions or behavior. But it doesn't take theorems of correctness to be useful.

> that is true of statically typed OO also

Not really. Statically typed OO doesn't prove nearly as much about the behavior. This is mostly due to potential for aliasing of stateful sub-components. If you have capability secure OO, like E language or NewSpeak or Joe-E, that can help a lot, but the potential for hidden communication via aliased components still hinders a lot of useful equational reasoning.

> only way to get encapsulated state in Haskell is World -> World

That's simply untrue. Encapsulated state in Haskell can be modeled by a variety of types. One is `Machine i o = i → (o, Machine i o)`. Such machines can be composed, each component machine having its own internal, encapsulated state.

> OOP also is not very new, being formed from the culmination have patterns used in the 70s, and is about the same vintage as FP.

I'd say pure FP is a lot younger. The idioms for purely functional expression of IO simply didn't exist in the 70s. E.g. even in the mid 80s, you had languages like Miranda with impure 'readFile :: FileName → Bytes'. The Clean programming language using uniqueness types for IO was a new thing in the mid 80s. The modern use of monads harkens to Wadler in the mid 90s. I tend to think of `pure FP` as more a mid-90s paradigm. It really is a different paradigm - a different way of thinking about and constructing programs - than the ad-hoc impure FP of Lisp and OCaml.

> Very frequently. The simple theorems that equational reasoning supports are very convenient for refactoring and optimizing code.

I was generalizing across all programmers. Of course individual cases may vary, and it really depends on the code that you write!

> Not really. Statically typed OO doesn't prove nearly as much about the behavior. This is mostly due to potential for aliasing of stateful sub-components.

Haskell simply avoids aliasing with value semantics, and even then you can add it back and get the same problems.

> That's simply untrue. Encapsulated state in Haskell can be modeled by a variety of types. One is `Machine i o = i → (o, Machine i o)`. Such machines can be composed, each component machine having its own internal, encapsulated state.

I'm not disagreeing. My point is that you have to bury the state in something else, which is then exposed via a signature (well, in Haskell which supports this, of course).

> I'd say pure FP is a lot younger.

We could debate a lot on what pure FP is, what pure OO is, and who climbed the ladder faster. But the fact that paradigms developed around the same time is probably due to the programming field maturing in that time frame.

> generalizing across all programmers

I think the relevant question is whether functional programmers, not all programmers, regularly leverage the lightweight equational reasoning, refactoring, and context-independent behavior that is available with purely functional programming. I believe most do.

> avoids aliasing with value semantics, and even then you can add it back and get the same problems (...) you have to bury the state in something else, which is then exposed via a signature

In a programming model without side-effects, it is necessarily the case that all 'effects' are modeled in the call-return behavior. The type signature, too, for a strongly typed language. And I agree that, upon modeling state or aliasing, we get to deal with not just the feature but all of its associated problems.

OTOH, the problems of state and aliasing don't implicitly leak into every subprogram. The precise control over effects can be very convenient.

You couch that control in pessimistic terms like "pollute all function signatures it buried through". But in practice I've never had difficulty anticipating where I'll need to model effectful behavior, nor with extending the set of effects as needed. Oleg's recent development of freer monads with more extensible effects [1] is compelling in its potential to remove remaining drudge-work.

[1] http://okmij.org/ftp/Haskell/extensible/more.pdf

> We could debate a lot on what pure FP is, what pure OO is (...) paradigms developed around the same time

Pure FP (programming with mathematical functions, no side-effects) and impure FP (i.e. first-class procedural programming) are essentially different paradigms. They require different patterns of thinking, reasoning about, and constructing programs. Despite the ongoing battle over the "functional programming" branding, it isn't wise to conflate the two paradigms. It was impure FP that developed around the same time as OOP. Pure FP is about twenty years younger, more or less.

(The mention of 'pure OO' seems an irrelevant distraction. Do you believe pure OO vs. impure OO, however you distinguish them, require significantly different design and development patterns and are thus distinct paradigms?)

> I think the relevant question is whether functional programmers, not all programmers, regularly leverage the lightweight equational reasoning, refactoring, and context-independent behavior that is available with purely functional programming. I believe most do.

This begs the question of who is a functional programmer, and how typical are they? I know a few FP programmers who are able to stay in the abstract world for a long time, thinking symbolically, equationally, and don't need petty things like concrete examples (most of the members of WGFP, for example). Then there is the rest of us!

> In a programming model without side-effects, it is necessarily the case that all 'effects' are modeled in the call-return behavior. The type signature, too, for a strongly typed language.

You can always default to World -> World in a pure language, and ya...technically you don't have side effects anymore, but for all practical purposes you do! For this to be useful at all, you have to keep your effects fine grained, and for functions that call other functions (like a general ForEach), effects have to be parametric as well, or you wind up polluting everything (or worse, being unable to express something).

Pure FP culminates from a bunch of experience in the 70s (I'm not talking about Lisp), which happens to be where OO came from as well. Pure OO doesn't really make sense...OO can't be pure but rather organic.

Methinks you misunderstand the programming experience of FP. A nice property of 'equational reasoning' is that, as a universal property of code, I don't have to think about it. It just becomes a law of code - conservation of meaning. Abstraction, splicing, refactoring, and reuse happens easily and fluidly because I don't need to think about whether those actions are safe or correct. It isn't about hand-wavy abstract worlds at all, but rather concrete manipulation of source code. Concrete examples are also very common and useful with pure FP, e.g. use of REPLs is common.

A pure `World→World` effects model is NOT a practical equivalent to introducing side-effects. Unlike with side-effects, it's trivial to constrain a subprogram from access to the whole World, e.g. use divide and conquer tactics to hide parts of the world, or limit a subprogram to a constrained subset of monadic commands that an interpreter uses to access and update the world in limited ways.

No experience from the 70s left academics or industry prepared to support purely functional IO models. It should go without saying that you can't have a complete programming paradigm without an effective story for IO. Miranda, an attempt at a purely functional language of the mid 80s, made a valiant attempt at pure IO, and failed. Even early Haskell, up through the early 90s lacked an effective, coherent story for IO. I find your repeated assertions that pure FP was somehow a child of the 70s to be very dubious.

REPLs don't help out with refactoring, splicing, or even abstraction, at least with the current tool chain we have.

IF you add a World->World effect to your function, it is the equivalent to saying it has unconstrained side effects, is it not? It is the practical equivalent, even if its implementation can pair off the world as needed.

Hindley Milner, Landin, ISWIM, APL, list comprehensions, etc...are all children of the 70s. The IO problem wasn't solved until Wadler in early 90s, but then again we didn't get type parameters in OO languages before then either.

Wat? It's equational reasoning that lets us manipulate concrete code easily. REPLs are just proof that functional programmers like working concrete examples, too.

A World->World function is unconstrained in its effects upon the given world, modulo substructural types. But it is not a "side effect". Among other important differences, your program can't describe an infinite loop with observable effects on that World.

I don't consider type safety, list comprehensions, etc. to be essential for pure FP. Immutable values, first class functions, and explicit effects models on the call-return path (instead of side effects) are the critical ingredients. Comparing the essential IO problem to "type parameters" (which aren't even a problem for a rich ecosystem of dynamically typed OO) seems disingenuous.

Side effect free functional programming was taught using Lisp in the 60s.

See "Pure Lisp", a style and subset, where no side-effects has been used.

I wasn't able to find much on this via search. The papers I found date to 96. Do you know how 60s Pure Lisp handled IO?

> Except that there is a real advantage to using pure functional programming

That's only true for certain values of "real". In real "real" terms, the advantage is purely virtual - even very simple programs require hundreds of pages of proof. In effect, formal proofs are almost never done in real reality and the "advantage" remains purely virtual.

> what's new about it (privileging the first argument of each procedure

Multimethods, CLOS, Dylan?

> inheritance

Don't use it if you don't like it that much...

> lots of hidden mutable state

It's not hidden, it's encapsulated. Do you know Smalltalk? If not, you should try learning it; I liked Pharo very much. Look at Morphic, work with it for a while and you'll see the difference. You can also try devising purely functional equivalent of Morphic while you're at it (good luck!).

For some values of "pure", sure. The problem is, keeping this level of purity - that allows to strictly prove theorems about your code - is very hard. And most real code would compromise, while still pretending that they are pure and their results are proven. That's not a road to a good place.

I seriously doubt there's much industrial code made in functional languages that has been proven to be correct. And I'm not talking about halting problem, etc., not that deep, I mean just writing a spec of what the code would do in every situation and proving that indeed it does that. I haven't seen any. Maybe in theory it'd be possible, in practice, it doesn't happen. In fact, if that happened frequently, unit testing in functional environments would not exist - you don't need to test what you can prove to be correct. In reality, it very well exists.

> There is a reason why the majority of proof assistants are implemented as functional languages.

It's not the direction you need to prove though. Surely, it is easier to express things we can prove in functional terms. The challenge, however, is to see if it's easy to prove that code follows certain specs when that spec is not specially fit for being expressed in functional terms.

> it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad

Hidden mutable state is not mandated by OOP in any way. And arguing that inheritance and special arguments are bad would require some more than just saying "it's bad".

> and what's good about it (encapsulation, polymorphism) is not new

So what? Where's the problem if it's not new? Letters we're using aren't new, so aren't numbers, still serve us well. Not everything good must be new, if it's old and still good - even better. I fail to see how "it's not new" is any meaningful criticism - it's like criticizing a math library that the result it returns for 2+2 is not new. Why would we want it to be new?

"Pure" functional programming isn't the only alternative. There's plenty of benefit from just using a language with reasonable semantics (e.g. ML) that doesn't force you to contort simple programs into bizarre "OO" patterns.

Whether or not you want your language to enforce segregating (most) effects is a separate issue, about which reasonable people can disagree.

Agreed. And for the record, I also like imperative languages (e.g. C), where appropriate.

>>Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation.

How much of the Haskell (a pure FP language) library code is formally proved? Just curious.

Also I wonder, if code like xmonad can be proved at all.

XMonad comes with quite a few QuickCheck properties. See https://donsbot.wordpress.com/2007/05/17/roll-your-own-windo... and https://donsbot.wordpress.com/2007/05/01/roll-your-own-windo... for some readable introduction.

One might consider proving the properties instead of just checking them with a few thousand random examples.

The problem I have with the functional paradigm is that it's couched in the idea that all problems can be reduced to same kind of algorithms. It's better to accept that all problems can be reduced to some king of algorithm whether or not it follows neatly along with the functional paradigm. That's why OOD sometimes works better for some problems over others and vice versa. Plus, I think not all functional programming languages are equal in this regard. I have a bias toward Ocaml since it's fairly easy to get into it without having to abandon previous knowledge. You can learn Ocaml even if most of your professional life you've written code in C. Whereas Haskell you have to unlearn lots of old idioms which worked well in C to get a basic comprehension of Haskell. So, just picking up Haskell because you think a specific problem is easier within the functional paradigm is a bad idea IMO. Unless you have plenty of time to learn then go for broke.

I don't believe FP has any strong assumption that all problems reduce to the same kind of algorithm. Rather, different kinds of algorithm are modeled typefully - e.g. with various monads or abstract data types.

As you mention, pure FP does require learning different idioms. OTOH, a lot of those idioms can be applied effectively to imperative programming, so learning isn't necessarily a wasted effort even if you spend most of your time wrist deep in C code.

I see you point. I just think there's better options if you're going to approach FP. I think picking a language that's flexible about it's enforcement is one approach. I think I've learned more from Common LISP and Ocaml about FP than I ever did from Haskell. It's not to say Haskell is a bad language, but it's just not one you can pick up in a day.

> pure functional programming; being able to easily prove theorems about your code

I believe you're referring to a type system. That is different. There is little about functional programming that allows you to easily prove theorems about your code.

No, FP is great for analyzing your code! Internal state and side effects are the main things that make code hard to analyze, and it's exactly those things that FP avoids.

How is that related to easily proving theorems about the code?

It's easier to prove stuff about simpler code.

Reply on news.ycombinator.com