Programming and thinking the functional way
peteratt.com
Programming and thinking the functional way
1–10 of 86 posts
Re: Programming and thinking the functional way
#2It is at the core of many mobile to internet gateways out there. At the core of WhatsApp. Some databases (Riak, CouchDB) and message queues (RabbitMQ).
Language-wise, besides concurrency constructs, you get pattern matching, immutable data structures (and bindings). Unlike Haskell, all types are dynamic (but strong).
Also a counterpart to Learn You A Haskell For Great Good is Learn You Some Erlang For Great Good:
http://learnyousomeerlang.com/syntax-in-functions#pattern-ma...
For example the quicksort sample would look like:
sort([Pivot|T]) ->
sort([ X || X = Pivot]);
sort([]) -> [].
But it is the large applications that ends up breaking my brain. I am convinced once you learn programming in an imperative or object oriented language you brain just become molded to that model of thinking and it is very hard to adjust (it is nevertheless very useful to try).Re: Programming and thinking the functional way
#3It made me think that recursion, no matter how short the code looked, was terrible.
Now I realize that recursion, thought about properly, requires so much less mental overhead. All those lines of code that vanished were really whole concepts and ideas which could vanish as well.
Of late, my style has been refined by working with theorem provers which make the ultimate connection. Recursion is absolutely nothing more than mathematical induction. Each recursive call is just you invoking the inductive hypothesis.
What that connection really drives home is that when writing a recursive definition you need to do so very few things. First, you need to make sure your definition has a good foundation—you must list all of the conditions where it terminates and ensure that they truly found and support the algorithm/proof. Then you must write the inductive engine that will burn away whatever inputs you receive down to the foundation you just made.
The release is in noticing that those inductive engines can be primed on the very tiniest actions—and those tiny actions are all you, the implementer, are responsible for.
When writing your inductive step consider only the things that are novel about this case. If I'm working with an input list and inducting on `cons` then all I must do is consider what happens to the head and tail of the list. Everything else will be handled by the turning of the inductive engine.
Now a good algorithm just feels like someone walked me into a room with a gigantic domino structure. I walk around it slowly and determine the ends and then just flick the single domino which will churn away inevitably the rest of the algorithm.
Re: Programming and thinking the functional way
#4 public class QS {
public List Quicksort(List l, Comparator comp) {
if (l.size() lesser = new ArrayList();
List greater = new ArrayList();
T pivot = l.get(0);
for (T t: l) {
if (comp.compare(pivot, t) out = new ArrayList();
out.addAll(Quicksort(lesser));
out.addAll(Quicksort(greater));
return out;
}
}Re: Programming and thinking the functional way
#5Re: Programming and thinking the functional way
#6I don't think this is a fair comment considering the in-place Haskell implementation isn't incredibly readable either.
Re: Programming and thinking the functional way
#7Re: Programming and thinking the functional way
#8Writing quicksort non-functionally doesn't HAVE to be unreadable. Not that I disagree with Haskell being great and all, I just think it's important to realize that imperative != ugly code. public class QS { public List Quicksort (List l, Comparator comp) { if (l.size() lesser = new ArrayList (); List greater = new ArrayList (); T pivot = l.get(0); for (T t: l) { if (comp.compare(pivot, t) out = new ArrayList (); out.…
Re: Programming and thinking the functional way
#9Writing quicksort non-functionally doesn't HAVE to be unreadable. Not that I disagree with Haskell being great and all, I just think it's important to realize that imperative != ugly code. public class QS { public List Quicksort (List l, Comparator comp) { if (l.size() lesser = new ArrayList (); List greater = new ArrayList (); T pivot = l.get(0); for (T t: l) { if (comp.compare(pivot, t) out = new ArrayList (); out.…
[deleted]
Re: Programming and thinking the functional way
#101) If it's simple to imagine the computer doing something, it should be easy to program.
2) If it's simple to analyze something mathematically, it should be easy to program.
The first path leads to C-style programming with pointers and loops. The second path leads to lazy pure functional programming and beyond.
Personally, I'm in the first camp. Small functional programs are often shorter and more beautiful than their imperative and OO counterparts, but large functional programs quickly accumulate so many abstractions that they become incomprehensible to me, more so than large imperative or OO programs.
Maybe that just says something about my intelligence, or maybe the functional camp hasn't yet figured out how to write large programs in a readable way. Case in point, see the list of operators defined by the popular Lens library in Haskell: http://hackage.haskell.org/package/lens-3.8.5/docs/Control-L...