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
I’ll be presenting (in french) with Jean-Laurent de Morlhon at ValtechDays 2009 on November 17th a talk titled “Where are my Beans, Contracts and workflows? WOA and Rest: An enterprise mindset shift”
Jean-Laurent did a brief introduction to the talk on his blog.
“With the rise of web 2.0, Rest and Web Oriented Architecture emerged as inevitable solutions to today’s business challenges. However, to realize the benefits of this approach requires a comprehensive look at the whole model together with its composing technologies, design patterns and best practices. In this talk, we will go with you discovering this approach, highlighting its principal elements (standard Web technologies, linked data, Mashups…) helping you finding architecture values you care about in a dynamic, extremely extensible model, hoping you get an “AHA!” moment by the end of the day.”
If you’re a JavaScript hater, a SOA lord or a GWT geek come in to exchange with us on the differents views to solve a common problem
And yes there is one slide about functional programming with JS )
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
This was a not satisfying test of integrating a google wave in the blog. I’ll make a summary of the wave later.
I’ll remove the wave for now from the blog because 1: It is not viewable by eveyone 2: It takes quite some time to load.
Sorry for inconvinience…
If you look at Haskell, Erlang, Scala and F#, what do you see? If you look at Haskell, you see something which, within its context, within the little framework it sets up for its sandbox, it’s very consistent, it’s very beautiful. You look at Erlang, it kind of fits, the bits fit together nicely. Of course, they don’t fit together nicely with the JVM or with .NET or anything like that. If you want to use all the nice things that are there, you can’t use them, or you can use them, but it’s difficult. So the other approach is, you say “Let’s use the JVM and target lots of different languages, so that the different languages can use each other” or you can do that within the .NET framework, you get Scala and you get F#.
The benefit there is you can use all these other things that are available, but in order to do them, you have to break them, massively corrupt and break these abstraction boundaries and I don’t like that. I think you are breaking abstraction boundaries in the wrong place. How I would like to see systems built is through communicating back boxes. And I would like to see the type systems applied to the definition of the protocols themselves and I haven’t seen that done.
Joe Armstrong from http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell
ps: reminds me of “And you get all the VM libraries for free! Is it actually what I want when I switch languages?“
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…)
Jim Webber from http://www.infoq.com/interviews/robinson-webber-rest 00:37:08:
We did put abstraction after abstraction onto our distributed system infrastructure and you know what: it hasn’t worked out that well for us. Some of the largest and most sophisticated distributed systems on the planet haven’t been all that large or sophisticated and then this kind of crappy protocol comes along that insists on being synchronous, and insists on being text-driven and it scales globally. That’s shocking and does not make sense to us as engineers. That’s the web paradox – it’s the rubbishest thing on the planet, but it scaled and for me that is what’s hit the reset button because I was totally up for XML-based protocols that do all sorts of funky stuff.
Those that follow my twitter @sadache , me @infoQ or my blog have certainly already noticed that I am quite interested in Scala on languages’ axis and in Domain Context Interaction DCI pattern on architecture axis. I always search new ways for delivering quality code which is modular and concise. Modularity offers the opportunity to think about the problem in parts, which is typical of the way brains work, whereas conciseness makes use of imaginary system (reading code blocks like images).
Recently, I’ve been working on a Web Api system where, thanks to support of @jeanlaurent http://morlhon.net/blog/, I used Scala applying DCI architecture in a real world project. This post is about reporting benefits of using this approach. Other posts will follow that will be more focused on the use of Scala and Functional Programming in that project. Code included is a bit simplified and parts of the system that are not of interest are omitted.
(more…)
from Rich Hickey on Clojure’s Features and Implementation
Clojure multimethods are just another level of that same logic, in fact they are a realization of the last sentence I just said. They are dispatch based upon an arbitrary function of the arguments. You define a multimethod and you say “Here is a function of the arguments I’d like you to use” You could look at the first argument, you could look at the 5th, you could look at all of them, you could look inside them, some member of an argument, it could look at the types or not or the values. Now, you could look at relationships between arguments, you have dispatch based upon an arbitrary function of the arguments and you have a vastly wider set of polymorphic possibilities than you had before and it’s quite powerful. In particular, it allows you to do Runtime dispatch on Runtime attributes. You don’t usually represent something like being hungry as part of something’s type, it’s some attribute that it acquires while the program is running or being outdated or things like that. Now you can access those things and you can do things polymorphically based upon that and take a lot of switch statements out of your code.
Should I call it first class Pattern Matching? or Pattern Matching in disguise?
