Saturday, November 24, 2007

In my previous post about what people use computers for, I stated that computers are for saving state.  Duh.  I felt I needed to make that clear to myself as I explored functional programming languages like Erlang, F# and Scheme.  State seems to be a dirty word relegated to second class citizenry in a functional world.

I think that functional language have an uphill battle for mainstream acceptance.  A bit bolder, I think they are a small niche and always will be a small niche.  In fairness, I think most of literature on functional languages portray them as a special purpose languages.  As the saying goes, the right tool for the job.  Microsoft is looking for F# developers to write driver validation software. 

My goal is to find languages that are applicable to general purpose problems.  I'm not a mathematician and I don't need so solve theorems.  Most of the programming jobs I've completed involved storing and manipulating some shared stated, a database.

Yet another realization courtesy of a man seeking to explain the failure of the best language on earth

Local state in programming is just like scratch paper for mathematics.  Some rare gifted individuals don't need it and can do the calculus in their head.  For the rest of us scratch paper and number two pencils are the only alternative.

While debugging, I can inspect the state of the system, either with the debugging facilities or with well placed print statements. 

So local state helps us understand our systems.  Global state, again databases, are the reason our systems exist.  Some in the Erlang camp want to wish this away.  However, I think Erlang advocates understand that Erlang was built for telecom switches.  Erlang's usefulness in general purpose programming is yet to be determined.  If you're building a system that manipulates global shared state (most of the web applications in existence), choosing a language that waves its hands at shared state in the name of concurrency might not be your best choice.

Now we come to the revelation stage of our journey.  What can we do in mainstream languages to deal with global  shared state (databases) effectively?  I've found something in my own development work that is effective for me.  It's not a new language, but in fact, works in many languages, including C# and Python.

My solution may not be a silver bullet, but then I might not be hunting werewolves.  I can't claim to have invented it.  For from it.  All I can claim is that I've seen this pattern work across languages.  I can also tell you that it might be a wooden stake, useful if you are hunting vampires.

 

Saturday, November 24, 2007 10:16:25 AM (Central Standard Time, UTC-06:00)  #    Comments [2]
Sunday, November 25, 2007 7:15:57 AM (Central Standard Time, UTC-06:00)
So, what is your solution?
Anon1
Sunday, November 25, 2007 7:51:37 AM (Central Standard Time, UTC-06:00)
The great idea in a pure functional language like Haskell isn't the complete absence of state, but how it forces you to deal with state. If a function uses state, it's made explicit through the function's type. You can instantly know whether a function has side effects. The extra work necessary to use state also makes the programmer more likely to separate the stateless and stateful versions of their program, making it easier to reason about (no worrying about side effects, value of current global variables, etc.).

My experience is colored by the language I'm coming from (Haskell, which is not in your list), but my initial impression is that you still haven't done enough functional programming. In particular, you seem to be suggesting that functional languages have no way to declare local variables so that you can write shorter mathematical statements. This is precisely what 'let' is for (also present in Scheme and I believe F#). You can't manipulate the value stored bound by a 'let' variable, but this often makes reasoning about what happens easier rather than harder. You can also nest 'let' expressions to get more or less the same effect as a stateful math scratchpad.

Also, GHC (Haskell compiler) now has a debugger that lets you examine state. It is possible (though a bit of a hack) to do print style debugging as well.
Name
E-mail
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):