Flow Based Programming is the second edition of Paul Morrison's book describing his data flow centric progamming methodology. FBP is a coordination language Paul developed at IBM well suited for connecting components to model and implement business processes. It lends itself to graphical representation, an FBP flow chart really is the program and tools exist to transform the graph into a list of components and links that an FBP engine can execute. Non-programmer domain experts may develop and maintain applications with appropriate component collections. Morrison's claim that FBP makes business applications easier to maintain seems plausible.

The flow of data from one component to the next resembles the Unix shell use of pipes to link the output of one utility to the input of another or tacit programming in J. Where these are linear, FBP supports tree and looping constructs. The components may be realized loosely coupled processes distributed across multiple cores or computers. FBP promises a path to take advantage of the proliferation of cheap, multi-core computers that challenges conventional development methods and languages.

Primitive components may be written in any language convenient for providing the necessary functionality, often assembler or PL/1 at IBM, but C/C++, Java, Python, and others have also been used. While components may be written in any language, their essentially functional nature seems to be a good fit for Erlang, Haskell, and the Lisp family of languages. I may experiment with FBP in Racket, since it seems to be a good environment for building domain specific languages.

I'd recommend this book for those interested in software development alternatives, multi-core, or distributed processing. While useful and readable as it is, new material for the second edition is appended to that of the first with insufficient integration of the text.

I've been playing with the Racket Slideshow language for an upcoming presentation. It is domain specific languages for describing pictures and slides. As such Slideshow is a good choice for programmers unhappy with standard presentation applications (they all suck swamp water).

I've also tried Bruce - The Presentation Tool, which is attractive because it's a Python application. However, I didn't find it as fast, well documented, or easy to blend into my work-flow as Slideshow.

After 15 years of development, the Programming Languages Team (PLT) has decided to rename their development system, PLT Scheme, to Racket with version 5.0 to emphasize the differences. Only time will tell if this is a good marketing move, but the system itself is impressive.

Racket is a modern Lisp with a modern development environment that combines the classic simplicity of Scheme with a well designed module system, an extensive collection of third party extensions (batteries included), and a good balance between research and pragmatism. If you're a programmer, I think you'll find Racket interesting and inspiring. If you're not, but are interested in programming, you couldn't find a better place to start.

I'm not taking very well to Haskell, so I've installed PLT Scheme and have begun to do some scheming.

I've been interested in J, a dialect of APL using ASCII characters, since it's inception and have used it off and on over the years. I've mostly used it as an array based calculator, but may begin using it for more applications development. With J 7.01 beta it is becoming more interesting to me as it becomes less windows centric and severs the Java dependency of the non-windows IDE with it's web browser and GTK based front ends. The revised architecture seems more suited to community contributions. This promises to be a long beta cycle, but I think the result will be worth it.

We had our first DenHUG meeting yesterday. It was just Ben Atkin and myself, but we had a good chat about Haskell and why we're interested in it. We're taking different approaches to learning Haskell, Ben is downloading and studying applications written in Haskell, while I'm reading Real World Haskell, and we're both experimenting as we explore the Haskell ecosystem.

Ben asked me what my expectations were for the DenHUG meetup group. I told him that it was an experiment to see if it would help me learn Haskell. This got me to thinking that I should probably have better defined goals for the group. Here's a rough cut:

• Learn Haskell and explore it's potential.
• Meet others interested in Haskell, and more generally, Functional Programming.
• Determine where Functional Programming works better then other programming paradigms and where it is a poor fit.
• Find out why one would choose Haskell over functional languages like Erlang, Ocaml, or Scheme.

Data Parallel Haskell: a status report presents promising results from the project. While still a work in progress, good multi-core speedups have been demonstrated. The approach maps the data parallel computations to a gang of threads whose execution can be interleaved with task parallel threads by the scheduler.

MongoDB is a scalable, high-performance, open source, schema-free, documented oriented database written in C++. It has interfaces for Haskell, Python, and a number of other languages. "Documents" consist of binary JSON like data structures called BSON. It looks promising for real time analytics.

The Eucalyptus Open-source Cloud-computing System provides a way for organizations to build private cloud computing infrastructures to flexibly provide computer resources to their users. Eucalyptus implements Amazon's EC2 and S3 cloud computing interfaces and runs user applications on virtual machines on a computer cluster for isolation and redundancy. It features a virtual network so that user applications need have no knowledge of the physical network.

Cassandra is a distributed database for structured data developed by the facebook team. They open sourced it in 2008 and is now an Apache incubator project and used by a number of other companies for data sets as large as 150 TB. It's written in Java with bindings for a number of other languages including Python, Haskell, and Erlang. Combining Amazon's Dynamo distribution model with Google's Big Table data model, Cassandra looks promising for Ultra Large Scale (ULS) systems.

Darcs is an interesting distributed version control system based upon a theory of patches and written in Haskell . I'm considering using Haskell for future projects and will use darcs for revision control for some work I'm doing to see how a non-trivial Haskell application performs in everyday use.

I've been interested in the Palm Pre and WebOS since they debuted at the 2009 CES, but it was only available on Sprint and I prefer Verizon. The Palm Pre Plus is now available on Verizon so I've upgraded to it from my trusty Palm Treo. The graphics are stunning, touch screen interaction intuitive, and mult-tasking outstanding. The biggest down side is the unimpressive battery life, it's been making it through the day with moderate use, but there isn't much reserve. I think WebOS has a lot of potential, but it'll take some time to get used to doing some things differently than Palm OS.

I've been doing some thinking about Cyber Renaissance and the system management problems the company is trying to solve. It's still an early stage startup and we're exploring some ideas about using autonomic clusters of computers to do useful work. This is an interesting problem domain, and may prove to be profitable.

We're looking at using a functional programming language such as Erlang or Haskell to implement this since they promise improved reliability and effective use of the multi-core processors that are now mainstream. As we develop our ideas, we'll experiment with the functional programming paradigm to see how well it fits both the problem domain and our brains.

I've begun playing with Haskell a bit and thought it might be worth while to meet others interested in Haskell and Functional Programming. When searching for a local user group failed to turn anything up, I decided to be proactive. I started a meetup for DenHUG, the Denver Area Haskell Users Group. We'll see how it goes.

FANN, the Fast Artificial Neural Network library, is an open source project from the University of Copenhagen. It is written in C with bindings for C++/Java, Haskell, Python, and other languages. It is well documented and seems to have an active community.

The Brian Simulator is a Python package for rapid development and testing of large neural network models. It achieves relatively quick execution speed by using NumPy to execute many calculations in each time step. For large models it up to 75% of the speed of a pure C implementation, but smaller ones suffer more from Python's interpretive overhead.

I recently downloaded the 2009-11-10 version of SLAPP (Swarm Like Agent Protocol in Python) and worked through the examples to see how it's coming along. It's still alpha quality and not organized as a package, but improving. Some file and directory names include spaces which is inconvenient for working on the command line. The code looks like Objective C written in Python. Tutorial 6 is under development but is functional. It converts a schedule.xls file to schedule.txt and fails if you don't have the xlrd module installed. Tutorials 7 and 8 are simply placeholders at this point. I also downloaded the Swarm documentation and Objective C source to help fill in the gaps.

I'm using Tutorial 6 as the starting point for a simple traffic simulation model. This consists of a four way stop intersection with the base case of drivers (agents) following the standard rule of proceeding through the intersection in the order they stop and yielding to the driver on the right when multiple drivers arrive at the intersection at the same time.

I'll massage the code from the tutorial to make it a little more Pythonic, package the core pieces to better support multiple models, and ensure compatibility with both Python 2.6 and 3.1. The tutorial has the beginning of a GUI interface using Tk which I may work on, though I'd like to see OpenGL and browser based interfaces as well.

After taking another look at JavaScript, I'm still not inclined to use it for server side or command line scripting. When I do need to use it, I'll keep JavaScript: The Good Parts handy. This slim volume tells you what you really need to know to write good programs with the language. In addition to showing you how to use the good parts of JavaScript, it provides guidance for avoiding or working around the bad parts. Since JavaScript has more than its share of warts, this is invaluable.

I've dabbled a bit with JavaScript in the past, but never seriously. It may be time to revisit it. Some of the reasons:

• It's the only language that you can expect to be supported on modern web browsers, so it's the first choice for interactive web interfaces.
• There's a healthy competition to produce the fastest JavaScript engine. Contenders include the V8 engine from Google and TraceMonkey from Mozilla.
• It integrates well with Java and C/C++. While object oriented, it supports functional programming.
• Server-side scripting with JavaScript is resurgent, partly because this allows functionality to be moved between client and server as needed.
• The CommonJS effort is providing a standard module system and standard libraries for common tasks not covered by the ECMA standard, improving portability.
• Node.js provides event driven I/O.
• CouchDB, a robust, distributed database uses JavaScript as a query language.
• Palm's WebOS uses JavaScript as it's primary application development language.

I'm interested in Agent Based Simulation and have played with Swarm a bit. While Objective-C is OK, I prefer dynamic languages and have thought about building something in Python.

Pietro Terna has already done this as he describes in Agents in Simulation Models, using a Swarm-like Agent Protocol in Python. His SLAPP package is available here. SLAPP is still young, but can be used to build interesting models.