Functional Programming in a Dysfunctional World

https://underthehood.myob.com/functional-programming-in-a-dysfunctional-world/

by GarethX • 11 years ago

93 67 11 years ago

underthehood.myob.com

Virtually all of the concepts that the author listed are completely orthogonal to functional programming, and moreover FP is equivocated with statically typed FP.

chc• 11 years ago

It seems pretty obvious from context that the author is discussing Haskell's flavor of functional programming in particular. It's somewhat lazy phrasing, but it doesn't seem unclear to me if you read more than the headline (and if you didn't read more than the headline, you wouldn't know he was talking about something more specific anyway).

nickpsecurity5• 11 years ago

What's the best resources you would recommend for someone to really wrap their head around functional programming, foundations and practical use?

yogthos• 11 years ago

I hear people find my Clojure Distilled guide helpful for understanding the general concepts https://yogthos.github.io/ClojureDistilled.html

pdpi3• 11 years ago

Learn You a Haskell For Great Good is a great introduction, if you're willing to just pretend you know nothing of programming for a little while.

pdpi3• 11 years ago

"A nice side effect (hmm) of immutability is you end up with pure functions."

No, immutability doesn't magically give you purity. E.g. Rust gives you immutability by default, yet you don't need anything to be mutable to get IO.

teacup50• 11 years ago

IO is by-definition mutation.

kstenerud• 11 years ago

The Virtus issue is simply an example of bad design. When you add magic that can't be guaranteed by the language, you're eventually going to run into problems. Just look at Hibernate.

As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry.

And advanced type systems are not unique to functional languages.

I'm also not clear on why the example testing code is better. It doesn't look much different from what I'd write in any language (excepting boilerplate).

So yeah, correctness and testability. It's available in most languages.

Also, what's up with all the single-letter variable names?

donjigweed• 11 years ago

<< As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry.

All of the FP languages I'm familiar with provide easy access to mutable collections.

sbergot• 11 years ago

a language with no mutable types

If we are talking about haskell, mutability is absolutely an option when it is the only way to write fast code. This is exactly what is done here: http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-...

And advanced type systems are not unique to functional languages.

"Advanced type system" does not really mean much. A bit like the weak/strong static typing distinction. However there are still significant differences between the c#/java/scala family and the haskell one. The fact that objects are not nullable by default and the absence of subtyping are considered as two big advantages for many people.

Also, what's up with all the single-letter variable names?

when the code is abstract and the scope of a variable is less than three lines, it can be ok to use one letter for its name.

the_af• 11 years ago

As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry.

There are always escape hatches for when you absolutely need mutability.

And advanced type systems are not unique to functional languages.

True. It's just that a lot of progress (but not all, of course) in advanced type systems is pioneered by languages which are often described as functional.

So yeah, correctness and testability. It's available in most languages.

Correctness and testability are properties of the software, not the language. As such, of course you can achieve them with your favorite one. But some languages provide better tools to achieve some degree of correctness and testability which would require a greater effort with other languages.

Also, what's up with all the single-letter variable names?

This is standard practice in many functional languages. Whenever the abstractness goes up (or the "more general" something is), the identifiers become shorter, since the name itself "means less". Hence why you see code that does something to every x in some kind of container xs; what would you gain with longer identifiers, except maybe misleading the reader?

PaulAJ• 11 years ago

Also, any imperative algorithm can be translated into a functional algorithm with, at most, O(log n) increase in complexity, and usually with none.

kazagistar2• 11 years ago

Also, what's up with all the single-letter variable names?

Words are not useful if your variables don't really have semantically meaningful names. Also, if your code is a simple one-liner, it does not really add too much benefit to name everything, if it is obvious from the (very local) context.

For example, when I look at something like:

    ordered (x:y:xs) = x <= y && ordered (y:xs)

I could do something like:

    ordered (first:second:remainingList) = first <= second && ordered (second:remainingList)

... but if anything, that will make it harder to read.

SparklingCotton2• 11 years ago

Then why did you call your variables x and y, and not y and x? Surprise: because there IS a semantic meaning to the order.

The haskell variable naming convention is bad. What is worse is that when someone points it out, there is ALWAYS this one or two variable example being put forward, when the problem exists in the 90% of functions that have 5 or more variables in scope.

I see a lot of haskell code that looks like FORTRAN. Haskell code is yet not written in large companies where there is a readability requirement. I just hope more programmers with a better taste for readability joins the Haskell ranks. The readability story needs to improve (and I see it improving a bit..)

agentultra3• 11 years ago

The idea that "memory doesn't matter" and "we're mostly waiting on the network anyway" seems like red herring.

It's not a "micro-optimization" to think of your data first. A program is a sequence of transformations on a stream of data. Figure out what your data is and how you want to transform it and your program will become evident.

FP is a fine tool for programmers to have but you still have to think about the data regardless. If you don't realize how the allocator works in your VM you might end up fragmenting your pools and over-allocating virtual memory for a simple process. For some applications that might matter.

nickpsecurity5• 11 years ago

I agree that it's foolish to ignore memory issues. We've had horrific performance and scaling in much software that did that. Anyone thinking otherwise can feel free to disable their processor or app cache to see how unimportant memory concerns are. ;)

Any HLL should give performance-concerned designers a clear, mental model of the performance aspects of their code. C and C++ programmers, for instance, understand the costs of their abstractions, how to code in a cache-efficient way, and so on. I read on the old LISP web sites and mailing lists where they similarly could estimate the cost of certain constructions and had tricks to squeeze out extra performance that they hid behind macros, etc. So, I'm sure these other functional languages can do something similar.

rdtsc4• 11 years ago

Memory didn't matter in the past. At some point caches weren't important, CPU were not running as fast compared to main memory. Then CPUs were getting much faster and caches started to become very important.

Then at some point networking was very slow and it didn't matter if you wrote your code in a scripting language, if all you did was wait for network packets. That was around Pentium 4 days or so. CPU speed was doubling quickly and 1Gpbs cards and switches were still kind of fancy and expensive.

But then it all kind of changed. Caches are important now. You thrash your cache around and you can take a serious performance hit. Even kernel code can't keep up with network wire speed at 10G range.

Long story short, a lot of performance heuristics and folk knowledge about it has be re-evaluated periodically.

agentultra3• 11 years ago

Totally agree.

Hence why I find glib comments about FP languages and memory management being unnecessary to be disingenuous at best.

You should still be aware of these things even if you're freezing a thunk off to a queue while your thread processes some other stack until that network message comes back. The hardware is your friend! Feed it right and it will reward you.

pekk• 11 years ago

What you need is really much more about the particular workloads you have. It is still often true that code is waiting on network packets or disk I/O. That didn't just change with the decade. This kind of folk wisdom is pretty useless on the whole and we should push people much harder to measure and find their specific problems rather than operating by rule of thumb.

taeric4• 11 years ago

At what point in the past did memory not matter?

SparklingCotton2• 11 years ago

But "real memory" is neither what C presents or the copy semantics that is used in FP.

The CPU will keep memory in 64-byte cache lines. There is a complex bus protocol to shuffle cache lines and subparts of cache lines to main memory.

There are additional complex protocols for cache coherence.

The cost of reading 64 bytes from memory into a cache line and when doing a write-back, storing it at a different location in main memory is zero.

Memory is always being copied into our L1 and L2 cache.

Copying data eliminates most of the cache coherence protocols that are complex and costly.

Yes we get a lot of this for free in the CPU implementation, but there is a lot of complexity that goes into imposing what is really beginning to be an unnatural model (mutable memory) on a hierarchical memory system.

FP is using a log-based model. You write to fresh memory, no aliasing, no coherence, no conflicts. You then, during GC, remap memory.

Current hardware cant "remap memory" efficiently, but it seems like the FP approach, in one form or another, is the better approach for dealing with high scalability and deep memory hierarchies: write to fresh memory, then expose a remap operation at the hardware level.

SSD disks are a bit like that internally.

millstone• 11 years ago

On the other hand, pointer chasing is decidedly not memory friendly. And mutable memory has a great deal of mechanical sympathy! A function's entire stack frame can live in the L1 or L2 cache. Imagine something like determining the length of a linked list, and then GCing all of the intermediate values.

I am not sure what the cost is of the cache coherency hardware, but if it were high, then presumably single-core CPUs would have a big advantage on single-threaded workloads. That doesn't seem to be the case.

nudpiedo• 11 years ago

I found it correct: what the says is that we should focus first on the actual bottlenecks before we worry about other optimizations; not that we should just look to another side.

If your bottle neck is in that point (copy of data structures) then there are functional data structures as well. And if still your performance is so critical in that point you can use a mutable data structure which is thread safe, and separate data from code in the rest of your code having still a big chunk of functional code where it is easy to reason about.

agentultra3• 11 years ago

I am referring to data-oriented design[0], not optimization: thinking about your data, access patterns, and transformations is not a premature optimization in the Knuth-ian sense. It's just plain, old engineering.

It's not incorrect per-se, just misleading in my opinion.

[0]http://dataorienteddesign.com/site.php

wcummings• 11 years ago

you have to be wary of using Java and .NET types which are still prone to NPEs

Java8 optionals are a maybe monad

http://stackoverflow.com/a/19932439/4658666

quchen• 11 years ago

I think your post only takes non-null values into account, which is what OP seems to talk about. What would this code do?

    Optional<Int> foo = null;
    foo.flatMap(x -> Optional.of(x));

Obeying the Monad laws would mean getting null as a result, via `m.flatMap(x -> Optional.of(x)) = m` for all m (or `m >>= pure = m` if you prefer Haskell syntax).

rdtsc4• 11 years ago

Did you ever attempt to get to the bottom of an intermittent error that was driving you insane, only to discover much later that a private variable wasn’t synchronized properly? Have you ever spent hours stepping through the lifecycle of an object, going through many different components spread out across the codebase and wished that you had spent all that time solving new problems instead?

I see 3 issues here.

1) Most people haven't dealt with those issues enough. There are complex programs but there are also many simple program as well. And unless one deals with hard to debug concurrency / pointer / mutable state errors they will not appreciate immutability. They might pay lip service to it, because it is cool, but they will not appreciate it enough to start rewriting their codebase in it. That is a bit like fault tolerance, unless they have been woken up at 3am because their main larger server process segfaulted and had to debug, they will not think about isolated units of failure, about supervision, durable peristent snapshots/checkpoints, monitoring etc. They of course will say that "fault tollerance is good" but it is good in an abstract, general way.

2) Those that dealt with these issue might accept the state (pun indended) of affairs and never realize there is another way of doing things. I mean they just accept that you have to have locks and mutable state and mutexes and dangling pointers and then spend months debugging hard to track concurrency errors at 3am. That is just how software development works and it is as good as it gets.

3) People realize there is something better, they know about, read about, played with it. But they don't have enough energy, political power, or time do fix it.

golergka• 11 years ago

Most people haven't dealt with those issues enough

This really surprises me. Surely, most programmers have experience with big and complex codebases with a lot bugs coming from mutable state, no?

rdtsc4• 11 years ago

For 1) I meant that there are lot of utilities, micrservices, small web backends, scripts, and hopefully, applications that have already been split into isolated components that can fail and restart separately (in other words someone did the work already). So if one starts dealing with those in their careers they just might never have a compeling reason to look at Haskell, F#, Erlang, OCaml and such.

Also note that quite often one way to deal with large mutable state is to simply shove it in database. Usually good databases just make it explicit what happens to shared state.

taeric4• 11 years ago

I see another issue. Have I ever gotten to the bottom of an intermittent error only to determine it is a synchronization error? Yes.

The problem is I have also gotten down to the bottom of a problem and found it was a stale data problem. In a system that was performing gymnastics to keep things immutable. To the point that fixing it was not a simple matter of just updating the variable.

Worst were the Multiversion concurrency control (MCC) systems I have seen rolled to "help keep all facts of the system immutable." Suddenly, we had to have database implementation experts just to run basic software...

sigmaml2• 11 years ago

I have similar experiences too.

Trying to keep data immutable introduces scenarios involving stale data, and a new problem to solve. I have seen interesting problems with cache coherence that were quite subtle in their manifestations.

Understanding the system-wide implications of immutable-only data is a non-trivial design task.

zyxley• 11 years ago

political power

This is the big one for me. I deal with assorted systems that I can't get migrated off ancient shitty middleware platforms because any comprehension of them vanishes into the ether somewhere around the upper management types.

"Functional programming" isn't even anywhere on the radar when I currently have no chance of even completely getting rid of PHP.

z3t4• 11 years ago

If your program has state, it doesn't matter if it's mutable or immutable state, you will still run into the same problems when working with concurrency. You either have to use locks, make sure functions are executed in the right order, or the preferred way: designate/central state.

So functions vs object orientated is mostly a matter of preference.

One advantage with functional programming though, is that it will be much easier so serialize the state.

JBiserkov• 11 years ago

I respectfully disagree. I also encourage you to take a look at http://clojure.org/state

codygman7• 11 years ago

If your program has state, it doesn't matter if it's mutable or immutable state, you will still run into the same problems when working with concurrency. You either have to use locks, make sure functions are executed in the right order, or the preferred way: designate/central state.

What about using STM:

https://www.fpcomplete.com/school/advanced-haskell/beautiful...

Functional Programming in a Dysfunctional World

Related Stories