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.

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 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 often work out in Vibram Five Fingers and have been looking for something with a similar feel for every day wear. I bought a pair of driving shoes at a Red Wing outlet store which work pretty well, though I can only wear them with thin socks and they're not well suited to winter.

I just got a pair of Vivo Barefoot Karibas which fit the bill. I wore them to work today and they did fine in our current snow storm, like house slippers that keep your feet dry. Not as close to bare feet as the Five Fingers, but better than the Red Wings and close enough for me, and I like the look.

I received my acceptance note from the program committee, and I'll be speaking on "Agent Based Modeling and Simulation in Python" at PyCon 2010 in Atlanta next February. I've got a half hour session and will probably set up an open space meeting as well. From the reviewer feedback, I should focus more on the "why Python" section and the example.

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.

Python 3.1 was released last week. The faster IO module should go a long way toward making Python 3 a viable option for new projects.

Since I saw their booth at the Denver Auto Show, Lightning Hybrids has progressed from a body shell and bench top drive train demo to a functional prototype. I attended an open house at their facility in Loveland yesterday and am cautiously optimistic about their changes in X-Prize Cup, though I'm still skeptical about the clamshell entry and think their production schedule is a bit aggressive. I wish them luck.

I've been thinking of migrating my Plone website to something else. Release Candidate 1 for TurboGears 2.0 is out and it looks very promising.

I planned to participate in the TurboGears 2 sprint in Boulder today, but wasn't able to hook up with the Front Range Pythoneer sprinters. I stopped by Boulder Crossfit to check out their new facility, which is bigger, nicer and more conviently located. After getting back to Lyons I tackled the TurboGears 2 tutorials.

So far I'm liking TG2 better than Zope/Plone because it lets the operating system and database do what they do well rather than reinventing the needed functionality. It fits the Unix and Python development paradigms like a glove.

Tiny Core Linux provides a basic graphical desktop in on 10 MB, making even Damn Small Linux look fat. Based on Linux 2.6 kernel, Busybox, Tiny X, Fltk, and Jwm, it is a minimal platform for building a custom desktop or specialized computing appliance that boots and runs quickly on modest hardware.

Extensions include development tools like the Gnu Compiler Collection, Python, and Ruby, but not Emacs, so you have to make do with Vim or another lightweight editor or do your own port. I may just have to install this on an old laptop to check it out.

Version 2.0 of SimPy came out in January and it's quite nice for systems modeling, but can be a tad slow, so I'm taking a look at speeding it up. For a first pass I tried Psyco, the specializing Python compiler. This gave me a 45% speed improvement wit a similar increase in memory footprint. This is certainly worthwhile, but still a lot slower than the same model coded in C. SimPy depends heavily upon generators which aren't supported by Psyco yet. Cython doesn't support generators yet either, so that doesn't look like an easy speedup either.

PyPy is looking more promising all the time. Holger Krekel has it running on a Nokia 810 handheld device with an reports smaller memory footprints than CPython for most Python data structures. The base interpreter is larger, but is sharable among multiple PyPy processes. An experimental version of the interpreter is running with the Just In Time compiler. This is unstable, but when it doesn't crash it is 30 times faster than CPython. Might be time to try it for a small project.