Archive for July, 2010

Functional Programming in the News

July 27, 2010

Once again, the news leads my way.

First, it seems that chip designers had no choice but to create multi-core processors — even though it was a risk, even with all the unknowns.

And now Apple is announcing a twelve core machine.

And second, the best way to deal with this situation is not threads, but functional programming — not mentioned are OCaml, Haskell and others, but Clojure and Erlang get the nod of approval from Tim Bray.

So I’m still on the right track, or others are now catching up.

I’d like to hear other people’s experience with functional programming.  How did you come to it, and what are the results?

Functional Programming, Haskell Frustration and Change of Venue

July 14, 2010

First, I’m long overdue “explaining” functional programming. Then, I’m frustrated w/ Haskell GUI issues. Finally, my non-technical writing is moving to a different blog.

I became interested in functional programming, over a year and a half ago, because of an article in Dr. Dobb’s Journal, and the confluence of other factors.

This is a very readable introduction to functional programming, here is a comparison with imperative programming- specifically with respect to Haskell.

I describe functional programming in terms of these aspects:

  • everything is a function (“variables” don’t exist — symbols don’t change once set; recursive functions are encouraged and preferred)
  • because of the above, side-effects are eliminated — a function only takes input and produces output; it does not change global variables, or alter the state of execution, and, therefore, always produces the same result, whether called first, third or last in program order.  Also, if a function is called ten times, repeatedly, with the same input, the output is always the same.

In imperative programming (and not necessarily, but in what I call “normal” programming) a lot of the work gets done by side-effects.

A typical example might be a hospitalprogram — where setting the patient name would initialize a new admission record, presuming that this is the desired operation.  But there is nothing per se about setting a person’s name that implies a new record should be initialized.  So that operation would be a side-effect of the function “set patient name.”

  • Now, frequently, this is how things happen.  Most “normal” programs operate some sort of finite state machine — that is, the program should do something different, even when the same function is called, at different point in the execution timeline.  But this is precisely what makes debugging so difficult.
  • Also, because of the changes to global variables and state, “parallelizing” code to run in a multi-threaded or multi-processing environment is non-trivial — nay, is next to impossible.
  • And those last two points are part of the primary motivation for the current interest in functional programming: ease of debugging, and simplicity of parallelization for multi-processor and multi-core computers.

    I strongly urge anyone truly interested in functional programming to do more, better research than that, but I hope I spark an interest in some to do that…

    Haskell “libraries”

    The problem I’m having is that too many Haskell libraries seem to be Unix-centric. For instance, here is  a program using FileManip, but that requires the unix lib. from hackage, and you can guess my luck getting that running under Windows.  WxHaskell required wxWidgets, and specifically wxConfig, which didn’t build for Windows (although most of the rest did).  Gtk2Hs worked almost completely, but some Glade files were/are missing; and along the way, I found out that I have two cabal installs, or something screwy with my setup, so I might try something else, we’ll see…

    Blog Separation

    Finally, I’d like to note that my non-technical blogging has moved.  I may move some previous entries there later.  I once ran across a blog, the ideas of which were mixed — some software engineering principles were dead-on, then there were some more crackpot ideas, and I found it a little dis-heartening to try and keep the thoughts separate:

    yes, I agree with these things; no, I don’t agree with those.  I know it’s the same person, but one shouldn’t invalidate the other.

    I don’t think my personal beliefs, here, invalidate, my comp. sci. musings, but it might be a distraction to some.  My personal reflections, whether you agree or not, should not influence your reception of my technical thoughts.  And you shouldn’t have to filter through one to find the other (some people, if you can believe it, don’t care about my technical blogging, but only my “writing”).

    I Feel Vindicated

    July 2, 2010

    This is a little tooting my own horn, but I had to share:

    I found out that I’m not the only one — I tried to control IE from Java (I know, several attempt exist), and got stymied.  More precisely, I tried using j-interop via DCOM interface to programmatically control Internet Explorer, but when  I went to get the frames, it failed all means I could think of — directly and a couple of indirect methods, and experiments around the edges;

    Then I searched for a different means, found jiffie, and went straight to work on my problem.  This code was right there:

    // We should be able to execute the code below to retrieve the
     // document's frames collection directly, However this fails
     // withh a "No such interface supported" error. This means we
     // have had to implement the required functionality ourselves.
     //Variant frames = getVariantProperty("frames");
     //return (JiffieUtility.getElementFactory().createElementList(getParentBrowser(), frames));

    And there you have it: (a) persistence pays off — they do have code that works after these comments; (b) I’m not the only one, but also (c) I’m on the right track (or, google is your friend).

    Now I need to add an update to the preceding with some notes about functional programming.