Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Three flavours of programming

graydon has a particularly interesting post:

I think the programming world we are living in has about 3 major styles of activity:

1. small, precision-engineered objects which operate as fast as we can possibly make them go, over very specialized mathematical structures, in extremely delicate circumstances. objects like this are RDBMSs, LAPACK/ATLAS/GSL, DSP codecs, renderers, embedded realtime controllers[...]

2. distributed systems made of sloppy, forgiving, easily modified, adaptive jumbles which connect together several objects of type #1.[...]

3. frustratingly large and inflexible "business logic" programs. this sort of program is what most cobol, java and C# code is for.[...]

I think it's a good map.

Furthermore, you can distinguish some design patterns to do with moving between these spaces.

One approach is to use different languages for different parts: call C libraries from PHP; write a Python client for a C++ server. OK. Works well, but there is a transaction cost in crossing the boundary. Things like Swig or CLR might make it cheaper.

Alternatively, don't pay the transaction cost, but stay in a single language and write in different styles. For example in C you can go to a very data-driven form, in which constant initializers form almost a simple scripting language, of which printf is only the beginning. (See the discussion of mini-languages in The Practice of Programming and The Art of Unix Programming.)

The saying that large C programs tend towards containing a half-assed implementation of lisp is true but not necessarily bad. It's entirely possible that you need just a little bit of lisp, and the pain of writing it yourself is less than the pain of linking in a real interpreter.

(This touches on the class and insoluble debate of whether you should add a real lisp because you might need it later, or suffer later because you wrote your own...)

For some problem spaces, adding a half-assed Perl or Forth or Fortran may be a very good approach. GNU Arch contains a reimplementation of unix pipeline primitives like awk and uniq in a way that can be easily called from C... This aided translation from a prototype written in shell, and provides a good language for the problem anyhow.

posted Tue 21 Sep 2004 in /software/languages | link

Copyright (C) 1999-2007 Martin Pool.