Computation Abstraction: Going beyond programming language control syntax, or what we’ve missed from FP for so long in mainstream
For a long time, and due to the lack of main FP concepts in most mainstream languages, we missed opportunities to abstraction and code expressiveness and conciseness. With today’s democratization of FP, Computational Abstraction is what will enable us to be less dependent on specific programming language syntax offering; creating libraries of control structures and composition forms that help find concise and expresive solutions to enterprise programming challenges (null, lists treatment, error handling), capturing elegantly important business concepts in code, and programming at the right level of abstraction.For a long time, and due to the lack of main FP concepts in most mainstream languages, we missed opportunities to abstraction and code expressiveness and conciseness. With today’s democratization of FP, Computational Abstraction is what will enable us to be less dependent on specific programming language syntax offering; creating libraries of control structures and composition forms that help find concise and expresive solutions to enterprise programming challenges (null, lists treatment, error handling), capturing elegantly important business concepts in code, and programming at the right level of abstraction.
Slides: http://sadekdrobi.com/wp-content/uploads/2009/12/Computation-Abstraction666iiioii6jjjjjjhjj-5.pdf
Google wave: https://wave.google.com/wave/#restored:wave:googlewave.com!w%252BPgcakhgiA
Most of my Erlang programming is side effect free. I think I probably write very unusual Erlang programs that look a lot like Haskell ones. Now and then, I do write side effecting code. For example, when I use the random number generation libraries that comes with Erlang, it has a side effecting interface. It’s very tempting when you are building something on top of the library with a stateful interface to build code on top of that that also has a stateful interface.
That’s what I did the first time I tried to use it. That has caused me so much trouble. I think every single bug that I spent hours trying to track down has been caused by a side effect. In a way, I’ve been programming Haskell for so many years, that I’d forgotten just how devastating side effects are and just how difficult they make debugging. I’ve learnt that lesson again and nowadays, if I want to use a stateful library, I usually build a side effect free interface on top of it, so that I can then use it safely in the rest of my code.
from my interview with John Hughes at Erlang Factory
Code included here is over simplified for clarity, I hosted a better implementation code on CodePlex. These modifications change strictly nothing for the client code and are only an implementation detail. I use a continuation rather than a delay, and I chose to design a custom continuation class rather than using a delegate because of a type system limitations.
Most GUI frameworks, including Silverlight and WPF, are shipped with a fundamental problem: long use of the main thread causes the Window to blackout, and using different threads requires you to get your hands dirty with the Dispatcher stuff and freezable objects. Worse, you wont learn the necessity to do so until you get a surprise of “The calling thread cannot access this object because a different thread owns it.” exception when all what you were doing is to use available methods on an object that seemed you have access to, at lease it seemed until runtime! This post illustrates a solution based on Monads abstraction and LinQ syntax.
(more…)
An interview I did with Paul Hudak that begins with a discussion of when to introduce difficult Haskell concepts like monads, moves to a discussion of the philosophy of higher order programming, the success and influence of Haskell, its use in the mainstream, and concludes with the idea of teaching computer music and Haskell simultaneously.
http://www.infoq.com/interviews/paul-hudak-haskell-Qcon-SF-08&language=en
From my QCon09 London presentation slides.
LinQ is often understood in terms of introducing a Domain Specific Language to work with data to C# and .Net in general. The fact is:it is not, and there is a considerable difference between LinQ syntax nature and a DSL. The problem is that DSL definition is blur enough to take anything interesting or cool under it!
(more…)
A great discussion I had with Don Syme at QCon SF. Don is one of the heroes to thank for .Net generics and he is a major contributor to F# design, Thanks Don!
http://www.infoq.com/interviews/F-Sharp-Don-Syme
Erik Meijer talks about less known LINQ features, like meta programming, about the differences between functional languages and OO ones, asynchronous computation, and others.
(more…)
