Lisp and Concurrent Programming

Bill Clementson has a huge list of Lisp-related concurrent programming references. And if you haven't looked at Erlang yet, it is a list-based semi-functional language. Too bad it doesn't use Lisp syntax.

Bill refers to Dirk Gerrits, building an Erlang-like concurrency mechanism in Common Lisp. Something like this was done for Python as well, called Candygram.

Also related is the ETOS compiler for Erlang that generates Gambit Scheme, which scales as well as Erlang/OTP.

The mind spins, concurrent thoughts swirling all around.

This and That in Politics

I'm reading this and that near each other in my bloglines. They both alarm me for reasons that are not dissimilar.

PyCon DC 2005: IronPython

I didn't see anything on IronPython at the March conference, but Sam Ruby pointed out the keynote.

Structure and Notation of Computer Programs

Agreed...

We're not so much building on the programming state of the art as continually have each generation of programmers rediscover it.
-Bill de hOra

OOP Is Much Better in Theory Than in Practice?

Lambda the Ultimate discusses the merit of an article as well as its content. Again against the object.

I think OOP is better in practice than in theory. But then I value practice more than theory.

Guessing from the Terminal

Mountains of wisdom from the Mountain of Worthless Information...

Next time you're in a meeting with folks and somebody asks you how long you think it'll take, be sure to tell them whether this is a "from the terminal" sort of guess, or a "from the ground" sort of guess. The difference? Until you've been-there-done-that, and have something against which to measure their requests (meaning you have some kind of experience with the things in question, ideally having built something like it before), your estimates are likely to be all "from the terminal" guesses, and highly likely to be wildly off base.

Smug Lisp Weenies

John Stephen Jacob Anderson, apparently a SmugLispWeenie if there ever was one, writes...

Python was the subset of Lisp that was understandable by C++ programmers.

Being at least a former SmugLispWeenie myself I am having trouble disagreeing. Which is not to say Python is bad, it just loses in certain significant ways that Lisp does not.

Update based comments:
"outside of the CS department"

Ouch.

I think Lisp is safely outside the CS dept. If we could get it *into* the CS dept. maybe things would improve a bit.

"Listing those significant ways"

Syntax extension, syntax itself, closures, continuations (Scheme in this case), to name the top of my list.

I would also include as a result of these, Lisp is a good vehicle for language experimentation (or just defining new object systems), whereas Python provides a simple object system it is more restricted in where you can take it.

Which is not to say that I would not choose Python over 90% of the industry's languages. I would.

Cairo as well as OpenGL

From "The (Re)Architecture of the X Window System" a progress report on Cairo...

This integration of the familiar PostScript operational model within the native application language environments provides a simple and powerful new tool for graphics application development...

Cairo's rendering algorithms use work done in the 1980's by Guibas, Ramshaw, and Stolfi [GRS83] along with work by John Hobby [Hob85], which has never been exploited in Postscript or in Windows. The implementation is fast, precise, and numerically stable, supports hardware acceleration, and is in advance of commercial systems...

Cairo is in the late stages of development and is being widely adopted in the open source community. It includes the ability to render to Postscript and a PDF back end is planned, which should greatly improve applications' printing support. Work to incorporate Cairo in the Gnome and KDE desktop environments is well underway, as are ports to Windows and Apple's MacIntosh, and it is being used by the Mono project. As with Xft2, Cairo works with all X servers, even those without the Render extension.

Also regarding X and OpenGL...

Using OpenGL as the basis for the X server itself will place X objects such as pixmaps and off-screen window contents inside OpenGL objects allowing applications to use the full OpenGL command set to manipulate them...

Whether the "core" X graphics will require any OpenGL extensions is still somewhat an open question.

In concert with the new compositing extensions, conventional X applications can then be integrated into 3D environments such as Croquet, or Sun's Looking Glass. X application contents can be used as textures and mapped onto any surface desired in those environments.

I think this is huge. (Yes, even huger than Avalon). Turning X, per se, into a legacy window system within a portable, modern vector and 3D graphics environment. Just remember, Don't Fidget With Widgets, Draw!

Where did those OpenGL patents go, again? Oh. Yeah. Now I remember.

Via Miguel de Icaza. (Microsoft must be wetting their pants trying to get de Icaza to sign up with them. I'd like to see the offer sheet.)

From the "What's That Again?" Department

From CNN...

"Poll: Nation split on Bush as uniter or divider"

Well then, apparently we have our answer.

Models for Backwards Navigation

Nice alternative implementation of a continuation-like web mechanism for languages without first-class continuations.

Unwittingly explains the *conceptual* model of continuation-based web servers. Languages with continuations offer a better *programming* model by simplifying the web programmer's *mental* model.

If you are familiar with web programming but unfamiliar with continuations, read this one first to get the concept, then read about continuation-based implementations.

Wiki and Comment Spam

I've not written my own wiki or blog system, and not thought about this problem at all. Given that, what if a form of "email authentication" was used to approve wiki edits and blog comments? (I think I've seen this somewhere but can't get google to remind me where.)

1. Someone edits a wiki page or adds a comment.
2. The change is suspended until "authenticated".
3. At this point the person enters an email address (of some determinably accountable, non-transient nature).
4. The change or some indication is sent to the email address.
5. Upon receipt of the response or via an http form in the email, the change is accepted.
6. In addition to other filtering and governing, the site now also has an email address.

Being FIT

Will Stott writes about using FIT via Excel.

Proof Carrying Code

I've only read a surface amount about Proof Carrying Code. In spite of my default stance on types, I am interested in ML and Haskell style type inference. So this book looks interesting, covering both topics and then some.

Via Lambda.

Can You Have It Your Way?

Guido's latest wandering around the world of type checking are disturbingly non-committal. I'd like to see his thinking get back to root causes and work forward to solutions. As it stands he's kind of wandering around the space of semi-solutions to unspecified problems.

Uninteresting and not a good use of my time at this point. If you've read this blog you know I am not interested in types much if at all. But whereever you are on the spectrum you most certainly would benefit from language changes being rooted in clearly outlined problems statements and solution explorations.

Objects are Easy? (Maybe Not)

A comment on Scott Rosenberg's blog post about concurrent programming...

Herb Sutter's analogy to object- oriented programming is completely bogus - OO is a bag of tricks for making it *easier* to write programs (often at the expense of making them a little slower), and especially easier to debug and maintain those programs; parallel programming makes it *harder* to write programs, and dramatically harder to make them correct, debuggable, and maintainable. It's just not going to happen.

First I would argue that programming with objects is not easier. But then the question is easier than what? The commentator does not say.

Objects are a code organization mechanism. As the complexity of a system grows, objects help through organizing the complexity. Progammers can use objects to focus on specific problems without being overwhelmed by uninteresting aspects of the system.

But objects are not easy. However I would agree that concurrency is even more difficult, especially given the languages and tools of the past several decades.

The commentator appears to be making an assumption though that the languages and tools of the past will not improve and there will be no incentive to improve...

As a software engineer with over 20 years experience, including a good deal on highly parallel machines, I can tell you for sure that there is not going to be a revolution in software development. Explicit parallelism is just too difficult to get right in general, and the applications that benefit from it have already been optimized for multi-cpu machines since the 1980's.

This sounds a lot like previous infamous predictions like no one needing more than 640k RAM.

Objects are hard, but they offer better notational organization. Processes are hard too, but they offer better dynamic organization. We just need better notations and tools for processes and someday someone may be writing something like "concurrency is a bag of tricks for making it *easier* to write programs".

The same commentator adds in a subsequent comment...

People don't get smarter, so this problem is not going to be solved no matter how much Intel would like it to be.

The same might have been said about programming sequentially before objects, or even modules and structured procedural improvements. The software industry has gotten smarter, perhaps not as quickly as any of us would like.