The Eighty-Twenty Solution

Jans Aasman and Jeff Kielty from Franz were at the Denver Area Lisp User Group meeting last night. They were interested in what Franz could do to encourage Lisp development. After we got over the obligatory discussion of Franz' pricing, we got down to the library problem. I commented that as a .NET developer, .NET integration isn't especially high on my list of wants; I'd like libraries but not necessarily the .NET or JDK libraries. For example, Python and Perl come out of the box with an array of libraries that do just about everything you'd want to do. I suggested that a SWIG binding for Franz FFI might be a cheap way to get this.

there's a ton of languages out there that have lovely syntactic constructs, but fail in one or more areas of "real world interface". It's like the OS problem, it's not especially hard to write an OS, but it's hard to support a lot of device drivers, and without that, the OS is pretty useless. So every developer's question on seeing a new language is "how does it support X?", where X is the deal breaker for your environment. My idea of the big areas a language needs to support are:

• File System and Text - a no brainer, and every languge has reasonable support. You simply can't get farther than toy status without this.
• Database - Especially if you want to use a language in a business environment, you'll probably be talking to a database. Ironically, the dynamic languages should just kill static languages in database access, but the problem is in drivers.
• GUI - Let's face it, most people use GUIs. If you're writing code for someone else to use, you'll want GUI support. One way to do this is HTML, which leads into the next 3 points.
• Networking, esp. HTTP these days.
• XML - like it or not, this is becoming the least common denominator for information interchange. If you have XML and HTTP, you can find a way to talk to other systems.
• HTML generation - if all else fails, you can output markup directly, but you're back in 1993 then. These days, a language has to compete with some great frameworks for building web applications, so a language needs to have an answer for this.

It's one thing to support these in libraries, it's even better if you can support them in syntax. So you have to ask yourself 2 questions

1. How am I going to provide these services?
2. How am I going to make it easy to program against these services?

Different languages are strong in different areas. In Perl, regular expressions are baked into the syntax, so Perl is makes text processing easy. In Python, everything is a dictionary (or at least, you can view the world that way), so organizing data in key/value pairs is easy. In Lisp, everything is a list (I know, I'm oversimplifying), so that structure is handled very naturally. I don't know of a naturally tree-structured language (setting aside XSLT, which isn't a general purpose language), though maybe Prolog would qualify. These days, there's a lot of tree oriented processing being done, so I'd expect the next big language to handle tree structures very naturally.