Gary's Blog

I wish Microsoft would stop fragmenting their own Market...I use their tools to avoid that crap...personally, I couldn't give 2 rats asses about F#, i wish it would bugger off, my head is still spinning from linq, xaml, entity frameworks, and all the myriad of other brain drains they release....you could spend your whole life learning all this crap and not actually produce anything useful.....the fragmentation means you are powerless to do anything about it....maybe time to change careers yeah?  

Oh dear Nacho, you sound like you are having a bad day. Let me tell you why you should care about F#. We are moving to a time of multi cores, we are - you could argue - already there. This means you must parallelise your code to take advantage of multiple cores. Now, let's say - as you do - that you we don't give a rat's ass about that, well that will mean that we are only taking advantage of one of the cores. That's not a huge problem if there are only two cores on a chip, we'll be running at a maximum efficiency of 50% and that may not matter for our application, that may be fast enough. But what about quad core? Eight core? Can we afford to be running at a maximum efficiency of 25% or 12%? I say, that would be totally unacceptible.

So we have no choice but to parallelise our code. Now, since OO programming builds applications by composing objects together, that leads to a lot of shared data, shared data that has to be handled. To do that, you can either shoe horn an OO language into immutability, or you can use a functional language like F#. I contend that the latter is the better path.

You may not care a rat's ass about F# now, but you will in the very near future or you may find yourself changing career paths afterall. :-)

I'm Sold.

Will be checking out F# for sure...

I'll have to investigate more, but I thought the parallel framework was supposed to get us to the promised land? And if this immutability is so important to parallelization, how does creating an XPObject with mutable properties help us? Or maybe I'm just having a bad day too since that 40 for age only reminds me of my next birthday. :-)

Hello Ron, the parallel framework will help, but why learn a new framework - that will shoe horn the OO pradigm - when you can use a functional language and get immutability out of the box.

Using XPO with F# is a different matter though, that was just to show that if you are interested in F#, as a language, then you can still use the 3rd party libraries that you are used to... in this case, XPO

<quote>In a functional language, applications are built by composing functions, unlike Object Orientated languages where applications are built by composing objects. This functional style helps the programmer to build robust applications as the base unit of construction is finer grained and is, therefore, less prone to error.</quote>

You mean like we used to do until we were told that was evil and object orientated approaches solved all of the problems and was "less prone to error" or is this something different again?

Call me a Friday cynic but the all time classic in It has to be the: Mainframe is evil PC is Good - and now we have virtualization that allows us to run lower spec PCs because our apps are running on a powerful application server rather than the local host...

I remember my father lecturing me that flares would be back in fashion soon enough.......... mutter mutter mutter.... bah humbug!

Hi Steve,

<quote>

You mean like we used to do until we were told that was evil and object orientated approaches solved all of the problems and was "less prone to error" or is this something different again?

</quote>

No this is something different again. In the beginning (well not quite the beginning but close to it) we had a seperation of data and the functionality that operated on that data. There were issues with that, mainly because the data and functionality were not encapsulated then there were issues with roundtripping to the database and bringing back too much data, or too little data, or just the wrong data altogether.

Then we moved to the OO paradigm, which solved that particular problem and it allowed us to solve the next generation of software problems as an object helped us to model the world in a more real life sort of way.

Now we are bumping up against the limitations of the OO paradigm, in as much as because OO brings a lot of complexity with it then it is hard to write solutions to complex problems using OO, for example devs not fully understanding the difference between composition and aggregation and the fact that you can not be fully certain of a property's value unless you go and check it (data not being immutable in most OO languages).

A pure functional language (which I do concede F# is not) will help solve these problems, along with issues of concurrency and parallelisation, and enable us to solve the next level of problem complexity. And then there'll be the next thing... :-)

" and the fact that you can not be fully certain of a property's value unless you go and check it"

huh? should we instead check quantum potentials instead? Should we instead check the registry? sorry, i must be having a cobol moment here ;)

Hi Drew,

No you're not having a cobol moment, it's pretty simple. Most OO languages are not immutable and so if you set a property you can not be certain that another thread has not come along and changed it out from underneath you, thus leaving you to retrieve a different/wrong value. There are two ways to prevent this, you can use locking - which is expensive - or, if you don't want the expense of locking, you can check that valueNow == valueThen before you perform your action.

Functional languages, on the other hand, are immutable by nature, and so when you bind a value you can be certain that no thread will change the value out from underneath you.

This means that you can concentrate more on solving your business problems and less on solving the issues of "plumbing together" a solution.