YAWN
Functional thinking: Why functional programming is on the rise
21–30 of 86 posts
Re: Functional thinking: Why functional programming is on the rise
#22Why 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 heard this too but in my exploration of functional programming I found little to back this up. Automatically deciding whether it's worth running a given function on a different processor or not (i.e. whether the overhead is greater or less than the savings on the wall clock) is not so much different than the halting problem and many implementations either don't try it or don't do it well. Also, every practical functional program needs to deal with the real world, whether it's in a "pure" (Haskell) form or not, and one way or another this introduces ordering constraints that work against parallelization.
Re: Functional thinking: Why functional programming is on the rise
#23Highly recommend LiveScript if you like CoffeeScript or JavaScript or functional programming.
Re: Functional thinking: Why functional programming is on the rise
#24Quite off-topic, but the underscores for the variable names in the first code snippet are totally irritatingly useless and anachronistic in the most ugly looking way.
Re: Functional thinking: Why functional programming is on the rise
#25Earlier quoted context omitted.
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 ef…
You should really take a look at Haskell. What you describe in your 3rd paragraph is precisely the ST monad.
It's true we're still pretty limited in how effects are typed (most effectful stuff still ends up in the "IO sin-bin"), but this is an area of active research and experimentation. This is the way haskell's going, and no one else is even close (afaict).
Re: Functional thinking: Why functional programming is on the rise
#26Earlier quoted context omitted.
Functional programming, by definition, is expressing a program as a function to be evaluated. That implies that, at least to some extent, all functional programs are written in a declarative style. However, we use a declarative style for other kinds of language as well: Prolog, SQL and CSS are three very different examples, none of which is a functional programming language similar to ML or Haskell or Clojure.
I don't think there is one uniform definition of functional programming. It's a vague characteristic of a language in the same sense as "object oriented."
> I don't think there is one uniform definition of functional programming.
Only because people are lazy in their words and thinking.
Re: Functional thinking: Why functional programming is on the rise
#27Doesn't this just bend back to Moore's law? Sure, there are more "efficient" data structures for use in functional styles now than there were in the past, but they all seem to treat memory as if it is free. Basically, now that we have such impressive computing resources, we can start thinking of the programs we are writing in terms of the abstractions themselves, and less in terms of the abstraction that is the computer. (That is, many of us are lucky enough to not worry about caching strategies, threading concerns, etc.)
The entire debate about immutable structures is amusing when you consider old resources where there is not spare room for a new copy of a string just from a different starting point. (Referring to the new Java behavior of .substring)
Re: Functional thinking: Why functional programming is on the rise
#28Earlier quoted context omitted.
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 ef…
What you describe reminds me of Rust's typestate, which they removed. But the "branded types" replacement, combined with the unique pointers, sound promising - see http://pcwalton.github.com/blog/2012/12/26/typestate-is-dead...
I am new to Haskell, but I also have objections to Haskell's notions of purity. For example, accessing your pid or your argv do not have side effects, and certainly do not perform IO, yet these are grouped in the IO monad next to file deletion.
Re: Functional thinking: Why functional programming is on the rise
#29Earlier quoted context omitted.
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 ef…
That's very attainable in Haskell and is often well-modeled off the ST monad. You also have a number of "Data types a la carte"-like methods which allows you to build very specific effect contexts in order to precisely guarantee things like the fact that mutable array code never produces events in the UI. These can be achieved by products and compositions of applicative types, free monads, monad transformers, or the "sum of effects" "a la carte" method.
Another big deal that comes out of these more specific effects is that you can have the compiler produce stream fusion to automatically optimize some inner loops, though I don't know how often that actually happens as of today.
(Oh: if you want to play with "Data types a la carte" they're in the IOSpec package, http://hackage.haskell.org/package/IOSpec and are described---somewhat densely---in http://www.staff.science.uu.nl/~swier004/Publications/DataTy...)
Re: Functional thinking: Why functional programming is on the rise
#30Some 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…
To me, the future will most likely be languages that allows both functional and OO styles to interoperate. Programmers will pick the style or mix of styles most appropriate to the particular sub-problem they're solving.
We already do this with some of our high-level languages like Ruby and JavaScript. With these, we have higher-order functions, map and friends, closures, etc.. But we also have our familiar OO constructs. Almost every program I write in these languages uses all of the above, not just the functional or OO subset.
I so far have not seen any practical advantage in going purely functional. I've tried it a number of times, but I always find that the real-world programs I write need to be stateful. Yes, functional languages do of course have facilities for handling state, but they always seem super awkward, especially compared to the elegance of state handling in OOP.
For example, consider a simple, 1980s-style arcade game. There are a bunch of entities on screen, each with attributes like velocity, health, etc.. How do you maintain this state in a purely functional language? I've seen various suggestions, but they all seem to boil down to setting up a game loop with tail recursion, and then passing some game state object(s) to this function on each recursion. Doesn't sound so bad, but what happens when you have a bunch of different types of entities? E.g. player characters, monsters, projectiles, pickups, etc..
Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state a function is updating, because it just receives and returns the big game state hash. You don't really know what data your functions depend on our modify. Effectively, it's almost like you're using global variables.
I'm using games as an example here, but the same sorts of problems come up with almost any stateful application.
This is why I prefer languages that allow you to seamlessly mix functional and OO styles. They give you many of the benefits of FP without forcing you to deal with the difficulties described above.