Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional thinking: Why functional programming is on the rise

ibm.com

Post reply on HN
Print view View original

11–20 of 86 posts

Re: Functional thinking: Why functional programming is on the rise

#11

Post by tikhonj »

discreteevent wrote: post #2

The thing is that any imperative programmers who have composed SQL subqueries have have been doing this kind of thinking for years whether they realise it or not. The only substantial difference is that the data is in the process' memory as maps and lists as opposed to relational tables in the db. You end up with exactly the same kind of patterns of composition in the code.

This general idea is well illustrated by LINQ: it essentially garbs basic functional programming into SQL's garments and passes it off to C# programmers, who happily use it for a whole bunch of different things. Some of these things (like RX) are really nothing like normal SQL at all.

Re: Functional thinking: Why functional programming is on the rise

#12

Post by Chris_Newton »

jekor wrote: post #9
Chris_Newton wrote: post #3

Some ideas that are ubiquitous within functional programming are certainly on the rise, for example: - functions as first-class entities in programming languages, and consequences like higher-order functions and partial evaluation; - a common set of basic data structures (set, sequence, dictionary, tree, etc.) and generalised operations for manipulating and combining them (map, filter, reduce, intersection, union, zi…

Yes, a lot of these are characteristic of functional programming, and many are being adopted. But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. And it's this purity that divides the communities. You can take high-order functions and folds and put them in just about any language, and you could put OOP conce…

But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming.

Indeed, and it is either a blessing or a curse depending on what kind of software you’re trying to write and the sort of situations you’re trying to model.

For most of the programming work I’ve ever done myself, what I’d really like to use is languages that do have concepts like time and side effects, because they’re very useful, but which only use them in controlled ways and when the programmer actually wants them. I’ve often wondered whether such ideas might be elevated to first class concepts within future programming languages, complete with their own rules and specified interactions, just as today we have variables and types and functions, and a language will prevent errors like calling a function with only two values when it expects three or trying to use the value 20 where a string is expected.

For now, I’m hoping that functional programming, in the pure sense, will raise awareness of the potential benefits of controlling side effects rather than allowing them more-or-less arbitrarily as most imperative languages today do. With a bit of luck, the generation of industrial languages in a few years will then borrow ideas that stand the test of time from today’s research into type/effect systems, software transactional memory, and so on, and perhaps we can have something of the best of both worlds.

Re: Functional thinking: Why functional programming is on the rise

#13

Post by jerf »

jekor wrote: post #9
Chris_Newton wrote: post #3

Some ideas that are ubiquitous within functional programming are certainly on the rise, for example: - functions as first-class entities in programming languages, and consequences like higher-order functions and partial evaluation; - a common set of basic data structures (set, sequence, dictionary, tree, etc.) and generalised operations for manipulating and combining them (map, filter, reduce, intersection, union, zi…

Yes, a lot of these are characteristic of functional programming, and many are being adopted. But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. And it's this purity that divides the communities. You can take high-order functions and folds and put them in just about any language, and you could put OOP conce…

"But there's a line that neither class of languages can cross over, and that's mutable state."

I'd add another qualifier for clarity; default or reliable mutable/immutable state. And this really comes up in libraries and such; either the language affords the use of immutability and you can count on libraries being themselves immutable, or the language affords the use of mutation and you can count on the libraries being based on mutation. Immutable languages can "borrow" mutability and mutable languages can "borrow" immutability (const, etc.), but the default matters, and there has to be some sort of default.

(Though while I cast this as a binary, there are some small in-between choices that may be relevant; see Rust, for instance, whose "unique" pointers may be a successful split. If the most useful aspect of immutability is not strictly speaking the inability to mutate values, but instead to guarantee that values can not be mutated by other threads or functions you didn't expect, then what happens if you directly express only that constraint instead of the stronger and more annoying constraint of full immutability? I'm watching that language with interest.)

Re: Functional thinking: Why functional programming is on the rise

#14

Post by tikhonj »

Chris_Newton wrote: post #12
jekor wrote: post #9

Earlier quoted context omitted.

Yes, a lot of these are characteristic of functional programming, and many are being adopted. But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. And it's this purity that divides the communities. You can take high-order functions and folds and put them in just about any language, and you could put OOP conce…

But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. Indeed, and it is either a blessing or a curse depending on what kind of software you’re trying to write and the sort of situations you’re trying to model. For most of the programming work I’ve ever done myself, what I’d really like to use is languages that…

What you describe is exactly what Haskell does. You have pure functions by default, but you can have mutable state wherever you want it--it is just constrained to a particular scope by the type system. That is, you can use mutable references, mutable arrays and so on all you want inside a computation, and the compiler will guarantee that none of these references leak outside their scope. Haskell accomplishes this with "state threads" (ST[1]).

[1]: http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc...

Similarly, Haskell has the IO type for containing any side effects at all. This type, as the name implies, can have not only mutable state but also arbitrary I/O--really anything you like.

This has some very nice advantages: for example, you can create your own wrapper around the IO type which only exposes some IO operations. You could use this for ensuring that plugins can't do things like delete files, for example. (This is one of the example use cases for Safe Haskell[2], which is worth reading about.)

[2]: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-...

You can even reify time explicitly, rather than modelling it implicitly with mutable state. This leads to functional reactive programming (FRP[3]), a new and more declarative way to write things like UIs. FRP replaces event and callback oriented programming, fixing much of the spaghetti code common to most UI frameworks.

[3]: http://stackoverflow.com/questions/1028250/what-is-functiona...

Really, I think "purely functional" is a very unfortunate term for Haskell from a marketing standpoint. "Purely functional" does not mean that we cannot have side-effects, or mutation, or what have you. It just means that side-effects aren't everywhere by default, and don't implicitly permute your otherwise pretty code.

Re: Functional thinking: Why functional programming is on the rise

#15

Post by fusiongyro »

pestaa wrote: post #10
discreteevent wrote: post #2

The thing is that any imperative programmers who have composed SQL subqueries have have been doing this kind of thinking for years whether they realise it or not. The only substantial difference is that the data is in the process' memory as maps and lists as opposed to relational tables in the db. You end up with exactly the same kind of patterns of composition in the code.

Completely disagree. Composing SQL queries even on multiple levels (as in subqueries) might involve a way of thinking that remotely resembles to functional programming, it is way too simplistic for comparison with real world functional programs, at least in my experience. I know I grasped SQL really quickly, and still get puzzled by Haskell after 6 months of trying.

I disagree with both of you. I think you're underestimating what can be done in SQL--recursive queries and correlated subqueries are not part of most competent developers' "standard toolkit"--but I think you're illustrating the problem with the OP's point, which is that most competent developers get through joins and outer joins (usually inheriting a lot of weird mythology like "joins are expensive") and can select/project and that's about where the skills end. So while I disagree with you in principle, in practice most people's SQL skills are inadequate even for an analogy to functional programming.

I would not say that the thought process I use when writing SQL queries is "more like" my thought process when doing functional programming than imperative programming. In truth, the similarity is all in what isn't present: I'm not deeply worried about what the machine is going to do with my request and how it's going to process it. I remain cognizant of what's "really happening" to the extent that I want to avoid obvious performance pitfalls, but it doesn't become the overriding obsession that it is with procedural programming.

With declarative programming I worry much less about whether the result is correct, and this is the primary benefit to me.

Re: Functional thinking: Why functional programming is on the rise

#16

Post by rdtsc »

I think a big one is concurrency.

Highly concurrent application will become more popular. Functional programming via immutable data structures is one sane way to manage that. Clojure is doing it. Erlang has been doing it for years. Haskell has that.

Fear of large, mutable state is well founded.

What else I think is healthy is adoption of these patterns. It is possibly to be diligent and try to apply some of the idea using other languages (C++, Python etc). It is just a different way of thinking and structuring code.

Re: Functional thinking: Why functional programming is on the rise

#17

Post by spikels »

Why is functional programming on the rise?

I have heard several times that the big payoff with function programming comes from parallel processing. Because functions typically have no side effects they can operate on a set of inputs in parallel without modification. This is important because future increases in processing power are expected to come primarily from more cores rather than higher clock speeds as in the past.

Is this correct? The author seems to focus on other real but lesser benefits.

Re: Functional thinking: Why functional programming is on the rise

#18

Post by [deleted] »

tikhonj wrote: post #14
Chris_Newton wrote: post #12

Earlier quoted context omitted.

But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. Indeed, and it is either a blessing or a curse depending on what kind of software you’re trying to write and the sort of situations you’re trying to model. For most of the programming work I’ve ever done myself, what I’d really like to use is languages that…

What you describe is exactly what Haskell does. You have pure functions by default, but you can have mutable state wherever you want it--it is just constrained to a particular scope by the type system. That is, you can use mutable references, mutable arrays and so on all you want inside a computation, and the compiler will guarantee that none of these references leak outside their scope. Haskell accomplishes this wit…

[deleted]

Re: Functional thinking: Why functional programming is on the rise

#19

Post by Chris_Newton »

tikhonj wrote: post #14
Chris_Newton wrote: post #12

Earlier quoted context omitted.

But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. Indeed, and it is either a blessing or a curse depending on what kind of software you’re trying to write and the sort of situations you’re trying to model. For most of the programming work I’ve ever done myself, what I’d really like to use is languages that…

What you describe is exactly what Haskell does. You have pure functions by default, but you can have mutable state wherever you want it--it is just constrained to a particular scope by the type system. That is, you can use mutable references, mutable arrays and so on all you want inside a computation, and the compiler will guarantee that none of these references leak outside their scope. Haskell accomplishes this wit…

I appreciate the comment, but what I have in mind looks very different to the way monads are used in Haskell today.

For example, I don’t necessarily want pure functions by default in my idealised programming model. To me, a pure function is just a special case of a function whose effects are controlled and where the resources the function might interact with are readily identifiable, for which the sets of possible effects and interacting resources happen to be empty.

Put another way, I don’t see anything wrong, or even inferior or undesirable, with performing a quicksort of an array or some fast matrix computations destructively. However, I’d like my language to make sure I couldn’t accidentally try to use the old data again afterwards (including, for example, in other threads running in parallel). I’d like to be sure that just because my algorithm updates one set of data in-place, it doesn’t also draw a window, block to wait for user input, or kick off a background thread that will reformat my hard drive in half an hour. And in the calling code, I’d like to find out very quickly that just because I created and populated an array over here, and then ran a quicksort that changed it over there, and then printed it out down there, nothing else had any chance to modify it in between.

And I’d like to do all of that using syntax that is at least as clean and readable as today’s best languages, please, not the horrors that often seem to result when functional programming languages try to implement equivalent behaviour with realistic heavily structured/monadic values instead of the neat one-integer counter or append-only log that always seems to be used in the tutorial code samples.

I suspect that to do that will require a language that provides dedicated, specialised tools to support the new programming model. Sure, you could probably do this sort of thing using monads in Haskell, just as you could do OOP in C, text processing in C++, or write in a functional style in Python, but the results are clumsy compared to using the right tool for the job. I’m not sure that tool exists yet for the kind of programming models I’d like to use, but that’s where I’m hoping the lessons of today’s functional languages and academic research will bear fruit over time.

Re: Functional thinking: Why functional programming is on the rise

#20

Post by PeterisP »

spikels wrote: post #17

Why is functional programming on the rise? I have heard several times that the big payoff with function programming comes from parallel processing. Because functions typically have no side effects they can operate on a set of inputs in parallel without modification. This is important because future increases in processing power are expected to come primarily from more cores rather than higher clock speeds as in the p…

I've done a bunch of both 'classic' and functional programming, and for me the biggest difference is a switch in code-writing mindset.

In imperative languages, generally, I tell the computer what and how it should do - no matter if it's assembly, C, Java or [most of] Ruby.

In FP languages (Haskell or Scala, haven't worked with Lisps), I generally tell the computer what needs to be computed and expect it to figure out how to do it - what order of execution, what grouping of data, what to cache.

If you compare Java code and Scala code for the same algorithm, using the same JVM API - then the main nonsyntactic difference between them will be a pile of missing Java lines detailing the order of processing steps and loops, which probably weren't essential to the algorithm - when writing the Java code I could've written it in opposite way with the same result.

What I lose in FP is the ability to easily explicitly do time/space tradeoffs. Sometimes I need to control that, and then it's a bit trickier. However, it can be fixed with minor refinement of language and libraries - the original article cites a great example on how memoization should be implemented in all great languages.

Parallelism currently is just a nice bonus - say, I lose 3x performance by not detailing a great execution path manually in C++; but I gain 3x performance since most of the code is trivially parallelizable to run on 4 cores. For example, in Haskell it's often literally a one-line change, while in Java it'd be a pain in the butt to make everything safely threaded.

Post reply on HN