Saturday, July 28, 2012

Software visionaires and opportunities

When I saw Steve Jobs in some of his presentations I thought: oh boy! You got it. It's all about simplicity and how to get things done the right way. An enabler for the masses. An opportunity for creating opportunities. Jobs was an enabler for co creation. He always defined Apple as a software company. And so it is, I think!

The exact same emotion came to my mind as I saw the amazing Rich Hickey keynote Simplicity Matters from the railsconf 2012. Fast forwarding the next five years I see more and more developers using functional programming, because the paradigms of software development seem to shift into a more data flow centric direction. At least, this is my very personal opinion. Internet, SQL, Linq, Reactive Programming, Parallel Computing. It's all about data and stream processing. And speaking of streams its the same exact thing as a list. Eventually, in the very near future functional programming will be used everywhere.

How do I achieve this task of data flow processing? The Internet is really the best example of how to do it. Data flow and functions that transform state. Not objects being responsible for tracking state. There are really good reasons to do it this way. And some others, most likely saving resources, to do it the OO style. I'm practicing the data flow approach even in python with its dict and list built in types. Actually, everything in python itself is an object containing dict's or list's. Dict and list are the most optimized data types in python and you'll see them everywhere floating around. Guido, AFAIK, is not a FP believer, so your mostly stuck in mutable OO paradigms. You're free to use whatever approach you like, but python will never be a real functional language. Never the less it's quite an awesome experience getting up to speed with python. There is data on the one side and functions on the other. Nowadays I dislike heavy class hierarchies for certain kind of problems.

Now what are the functional alternatives? You can walk along the traditional fashioned path the Lisp, Haskell, OCAML way of life or have a look at more modern approaches, entering the mainstream ready languages like F#, Scala or Clojure. Why? Because they run on top of enterprise grade VMs using the, and inter operating with libraries build over one or two decades. That's not an indicator for success, but it is a strategy for getting the masses to think about and use functional programming. It's a smooth way of migrating your skills and start new projects. I can easily play around with the concepts and integrate them step by step. This is simplicity from another point of view. As a vendor how can I attract the million developers out there to get in touch with? It's simplicity of getting used to the new tech. Take their comfort zone (.NET or Java) build a new language and let them adopt the new paradigm step by step. Don Syme has done it many years ago with F# and I think Rich Hickey with Clojure will be another great guy on the JVM side. Both are functional programming languages but differ in their approach.

Having used python as a real dynamic language the last 3 years in production I'm very comfortable with this modular style of programming. It's a pleasure to have all the freedom of choice and not being nagged by intriguing compiler error messages. No limitations and no inherent compiler laws. With great power comes great responsibility. And I decided to take this challenge 3 years ago. Now Clojure as a Lisp derivation is a real dynamic language, too. I don't know whether it is a good choice for enterprise grade solutions. I never really had a chance to test it. Twitter was built with ruby, and later replaced by java. Well, it's quite a different beast to deal with. A gazillion messages floating through the pipe. Python is simple to learn, really simple. Clojure is different, if you've never really been in touch with the Lisp style of programming - yet simple. Have a look at Clojure.core! You're free to invent whatever new "keyword" or operator you want. Just do it. hygienic macros and the way Lisp has been built. Amazing.

Simplicity is very subjective. Simple for me can be hard to manage for anyone else and vice versa. I'm very pleased with the amount of code I have to write to solve a problem. Give it a try and get inspired by simplicity.

Thursday, July 12, 2012

ClojureCLR with WPF - REPL and Compile

In order to run a ClojureCLR script with a non blocking WPF UI we have the two basic options
  1. in a REPL - being able to modify the window
  2. as console app executable
The solution to both scenarios are not quite obvious if you're not familiar with WPF or the threading models. For WPF and COMInterop the threading model has to be a Single Threaded Apartment. My first thought was to use the documented STAThreadAttribute which the .NET compilers are using. In ClojureCLR .NET attributes can be applied with the meta data syntax ^{}. Either Clojure.Compile.exe isn't aware of the STAThread feature at the moment or I haven't found the option yet. Have to digg into the code later. My first try to apply it to the -main function failed.

Kick starting my approach from Marius Kjehldahl's ClojureCLR post on running a WPF Window in a REPL you'll get option 1. I've shamelessly copied his solution and created my own quick workaround where a new Thread is spawn setting the AppartmentState to STA with the ability to load a .xaml.

For option 1, I created two gists from hist post for the REPL solution with some minor modifications:

For option 2 have a look at the following gist for compiling instructions and some background information regarding the threading model.


UPDATE: Here is a quickfix for the Clojure.Compile.exe allways appending the STAThread attribute to the  main executable. There is the generation from the clojure source file left.

Tuesday, July 10, 2012

Welcome

Today I decided to start a new blog over here to post about my functional programming experiences. Where does the name belong to? I've lived most of my time in Franconia and planning to relocate again to Nuremberg this year. Starting in the near future I'm planning to host a user group about functional programming, with my personal focus for functional languages running on top of .NET. My initial interest in fp was born 4 years ago getting started with some Lisp and Scheme tutorials using Common Lisp, Scheme and IromScheme for evaluation. Later on in my career as .NET developer (mainly C#) I fell in love with F#. In the meantime I focused on Boo for meta programming but dropped that too - in favor of F#. Back in 2010 I had great interest in learning Clojure/ClojureCLR but dropped it, guess - in favor of F#. Currently as a software engineer I'm using Python for production code and industrial automation. I'm running a German blog but there was only few activity the last 2 years because of the decision to have fun with my 2 year old sun.

You can expect me to start posting about Clojure and ClojureCLR and the trial of porting some libs. Some getting started topics and tutorials or links that helped me getting started. Thanks a lot for reading and stay tuned.

Cheers,
Rainer