opening it up with Common Lisp

Favorite weblogs

Lisp Related

Bill Clementson

Finding Lisp

Lemonodor

Lispmeister.com

Planet Lisp

Politics

Orcinus

Talking Points Memo

This Modern World

Working for Change

Other home

Polliblog

Recent Readings

Book review: Darwinia
Reviewed: Friday, August 11, 2006

Summer reading: Spin
Reviewed: Saturday, August 5, 2006

Runner
Reviewed: Tuesday, July 18, 2006

the Omnivoire's Delimma
Reviewed: Wednesday, July 12, 2006

the Golem's Eye
Reviewed: Wednesday, May 31, 2006





tinderbox
 width=

Ah, libraries
Friday, February 10, 2006

I was just about yet another person's struggles to find existing code that would solve their problem:

We started by looking at what kind of X libraries already existed that might prove useful for our own goals. This research brought up many different existing X-related projects. Some of the more useful ones we discovered were:

  • Long List...

At this point we decided it would better suit our goals to implement our own X solution. For the A and B libraries, we had to distribute multiple files from different authors, which didn't fulfill our simplicity objective. And each library had extra functionality that we didn't need, and especially with library C, that functionality seemed to unnecessarily impact performance. All of the libraries that we looked at seemed to have performance problems.

Sounds familiar, doesn't it.

The catch is that the language is Java and the topic is graph manipulation and display. Yes, Lisp has "library" problems, but once you step off the well trod paths, every language does.

Maybe Lisp has more problems because people can do so much in it and because people have been focusing on really hard problems so that some of the easy stuff (like sockets) has seen short shrift. This isn't to excuse anything; it's just to point out that all of the computer stuff is harder that it first appears and library development is very hard.


|

Home | About | Quotes | Recent | Archives

Copyright -- Gary Warren King, 2004 - 2006