Pensieri di un lunatico minore
As I was perusing an interesting posting by the gang at Matasano, I came across a reference to Mosquito Lisp, which is a varient of Scheme designed specifically for mobile code injection in the network security arena. It was summarized on Smallworks as:
- Designed for network applications, Mosquito is highly concurrent and provides simple and efficient network and process APIs.
- Mosquito is highly portable, written in ANSI C, and is currently in active use on Darwin/PPC, Linux/x86, Windows 2000/XP, and OpenBSD/x86.
- Mosquito is compact, with the virtual machine weighing in at close to 128k on some platforms.
- Mosquito can be self-contained, applications may be linked on any Mosquito platform to run stand-alone on any other Mosquito platform.
- Bytecode generated by Mosquito’s compiler may be employed on any host platform without recompilation.
- The Mosquito environment is rich, with over 300 primitive functions and 200 library functions in the standard library. (Not including additional libraries specific to MOSREF.)
- The Mosquito environment is available under the LPGL, and is obtainable from Sourceforge.
I wasn’t familiar with it, so after much searching, I found a vestigial bit on Sourceforge. It’s not lost, but it looks to have been abandoned by the original authors 2-3 years ago. Time to look deeper into it.
4 thoughts
Franz has finally released the express version of Allegro Common Lisp v8.0. Unfortunately, it still has a silly 50MB heap limit, but it’s at least enough to get your feet wet. This includes a version for MacOS X on Intel—which is what I’m using. Also, it includes AllegroCache for object persistence.
Comments Off
I admit it: I hate assembler. I hate C, C++, and most everything else other people consider “programming languages.” They are glorified switch-flipping on the front panel of a PDP-8e that we no longer have sitting in front of us. They are tuned for the benefit of the computer, and honestly, as an arrogant bastard, I find my time infinately more valuable. Computers are servants. Technology must bend to my will, not the other way around. That’s just the way I am.
So, it is with great glee that I find the resurgence of discussions about more advanced programming languages. Take an article from eWeek published yesterday.
The man from Mars sees development languages being chosen for the convenience of machines, despite attendant productivity penalties and difficulty of delivering high-quality code, instead of being chosen for the convenience of the developers who are the actual scarce resource.
Continually, I have reminded people that talented developers are expensive, CPU cycles are asymptotically approaching free. They are not being “wasted” when we burn them to make the developer’s life easier—we are freeing his own cycles to contemplate better algorithms, more advanced approaches, more adaptive reasoning.
Like anything that’s been around for several decades, LISP carries the baggage of what “everyone knows” about it that is no longer true.
“Everyone knows,” for example, that LISP is an interpreted language and, therefore, too slow for production applications—except that modern LISPs can compile functions for run-time speeds competitive with those of C or C++ programs in algorithmically complex tasks.
I remember the first time I ran into LISP in a high-performance computing environment. This was in the days when Cray ruled the world of supercomputers, and every cycle was expensive. Some of the fastest programs ever written for a Cray supercomputer came out of their LISP compiler. Why? Because the algorithm could be the focus of the intellectual power of the developer, and not bit-twiddling. It was a shock, and yet logical all at once.
The trade-offs are clear. In a study performed in 2000 by Erann Gat, a researcher at the California Institute of Technology’s Jet Propulsion Laboratory, programmers writing in LISP produced programs with less variability in performance than more experienced programmers writing in C and C++.
The fastest versions of C and C++ programs were faster than most LISP implementations, but the median performance of the LISP implementations was actually twice as good as the median performance of the C and C++ code performing typical tasks (more at www.flownet.com/gat/papers/lisp-java.pdf).
For real-world teams, such reduction of technical risk and improved worst-case scenarios arguably outweigh best-case results.
And that’s the thing. We live in the real-world, and that world is swimming in CPU cycles, memory, and un-tapped resources of our systems. Use them. Don’t waste your time worrying about saving 1 cycle when it means the real problems go unsolved. You might find out that, by focusing on the underlying problem, that the solution comes sooner, with more certainty, and thorugh more interesting work.
These observations to me also apply to Smalltalk and other “research languages,” that people dismiss as “interesting,” but not fast enough. Ruby is another such beast, as is Python, or even Perl—trading “performance” for expressiveness. Worry about “performance,” in it’s myopic traditional measure, when, if you solve the underlying problem first.
Fill your tool-belt with all the tools you need to solve the problem. You might be able to build the Taj Mahal with a pair of dental tweezers and an ice-pick, but it sure won’t be much fun.
[via Phil Windley’s Technometria]
2 thoughts
There’s a whole big discussion on comp.lang.lisp that I became aware of through a posting on Lemonodor and further commentary by Dan Moniz. All I can say is: Get a freaking grip guys! How someone licenses their software is their decision, and whether you like it or not only affects whether you give them money, not whether you have to respect it.
If I want to give something away—and I have given away a lot of bits of code over the years—then that’s my choice. If I want to charge, then that’s also my choice. This kind of back-biting is totally counter-productive to both the problem at hand, as well as the Lisp community as a whole. There are some outstanding free implementations of Lisp. Are they as “good” as Franz’ Allegro Common Lisp, probably not. But they also don’t cost money, and as my mother once told me: you don’t get what you don’t pay for.
Is ACL expensive? Yes. Is it worth it? Probably. Are the guys at Franz flexible and interested in working with you? Yes, totally. They, along with the gang at Cincom are very flexible in coming up with licensing terms that make sense for everyone at the table. They want to make money, but they also understand that they don’t make money if you aren’t making money. Having said that, I think that Franz should follow along with Cincom’s lead in offering a non-commercial release that is free and without any limits other than its non-commercial bits. Even if they can’t include all their doo-dads and gee-gaws (due to paying other people money for licensing), they could probably share most of it. If not, perhaps it makes sense to share with the community why they can’t do that.
Just a few thoughts. We don’t live in a world where anything is truly free of cost—everything has a price—even if you don’t bear the brunt of it.
Comments Off
There is an odd and disquiting conversation going on on comp.lang.python about adding symbols to Python. Every other language I use regularly (Smalltalk, Ruby and Lisp) has the concept of a symbol in the language. The Wikipedia contains the following definition for a symbol:
A symbol, in its basic sense, is a conventional representation of a concept or quantity; i.e., an idea, object, concept, quality, etc. In more psychological and philosophical terms, all concepts are symbolic in nature, and representations for these concepts are simply token artifacts that are allegorical to (but do not directly codify) a symbolic meaning.
In Lisp, symbols are actually objects in the system, and to quote the hyperspec:
Symbols are used for their object identity to name various entities in Common Lisp, including (but not limited to) linguistic entities such as variables and functions.
In fact, because of the structure of macros in the Lisp world, you actually have ways to generate symbols that are held as placeholders for other symbols, in the form of GENSYM. For Smalltalk, the definition is a little different, but also it is a specific type of object (from Squeak):
Symbol is a subclass of String, and understands, in large part, the same messages. The primary difference between a symbol and a string is that all symbols comprising the same sequence of characters are the same instance. Two different string instances can both have the characters ‘test one two three’, but every symbol having the characters #’test one two three’ is the same instance. This “unique instance” property means that Symbols can be efficiently compared, because equality (=) is the same as identity (==).
And in Ruby:
Simply, a symbol is something that you use to represent names and strings. What this boils down to is a way to efficiently have descriptive names while saving the space one would use to generate a string for each naming instance.
The common theme that runs through all of these implementations is that symbols are really just placeholders. We don’t particularly care what they are placeholders for, only that we can make comparison decisions based on them, and the only comparison that matters is equality. No other manipulation really matters. (This is not totally true in Lisp, but without macros, the rest vaporizes).
In the Python world, a symbol is a name for something. For example, when you define a function:
def myFunction(x, y, z):
pass
The name of the function, myFunction is a symbol, as are the variables x, y and z. The idea exists, however because it’s never been formalized in the same way they have in other languages. Python even has a symbol module, but it’s really not the same thing.
Symbols can be thought of as a parallel namespace (or in the case of some languages, multiple name spaces, each attached to a package) with a whole set of strings in them which will always be the same. A veritable garden of global names. For example:
x = 'string'
x = :string
are two seemingly similar things in Ruby, but the second reffers to a symbol that will always be the same. The reality is that the Python world has been using strings as symbols for a very long time, but without a lot of the advantages in implementation that the exposure of real symbols can bring (lots of reduced evaluation context costs).
1 thought
Several years ago, I started using the Regex Coach written by Dr. Edmund Weitz. It’s simply the best tool for interactively developing regular expressions. Not only does it provide visual information about grouping, it has step-by-step walkthrough of your regex, and the ability to do some basic debugging. For anyone working with regexes on a regular basis, it’s indespensible.
It’s a 2MB download.
Comments Off
There is a common thought that every language in the world is “written in C.” This is probably largely a recent thing with the rise of Python, Ruby, Perl, etc., where the core system is written in C, and a large amount of the code is in C. Bill Clementson talks about this in the context of Common Lisp, and comes back with what I think is the accurate observation from Edi Weitz:
Saying that CMUCL is partly implemented in C is a bit of a stretch IMHO. It’s like saying that Apache is partly implemented as a shell script… :)
There is also a look at Allegro Common Lisp, which is the premier implementation in terms of functionality and performance.
Comments Off
John Gruber (one of the great bloggers, in my opinion) writes about the issues with Applescript, concluding it’s an abyssmal failure
But saying what you mean, in English, almost never “just works” and compiles successfully as AppleScript, and so to be productive you still have to understand all of the ways that AppleScript actually works. But this is difficult, because the language syntax is optimized for English-likeness, rather than being optimized for making it clear just what the fuck is actually going on.
While I think he’s a bit harsh, and that Applescript has been used in a lot of cases to do things that are impossible on most machines, I do think that it’s attempt to model English, rather than abstract spoken language, and that makes people expect more flexibility than is really natural in a computer-parsable language. English has massive amounts of context that is both implicit and explicit—all of which are nearly impossible to duplicate in a computer language.
I think languages like Smalltalk, with a simple, regular syntax, are better suited to this sort of thing. There’s even F-Script on the Mac, which exposes all of the Applescripty goodness for automation.
The goal, rather than trying to make the user’s language “natural,” something that is still decades away—thanks Marvin—is to make it regular, predictable and comprehendable. In addition, it must be discoverable. All of these things are attributes of Smalltalk, and to some lesser extent (in the discovery domain) Lisp.
Power, and learning, come from simplicity, not complexity.
1 thought
Something ocurred to me last night, as I was drifting off to sleep. You could implement a full security mechanism in Lisp using just the condition system. While some macros would be handy for simplicity, you could easily implement it without. Once I get moved, I want to spend some time figuring out the way to do this, but I think that simply defining a proper set of conditions, and then using SIGNAL to bring them into the right frame would work.
More thinking ahead.
3 thoughts
Over the past year or so, as I’ve gotten my teeth back into Smalltalk and Lisp I’ve had the excellent opportunity to work with some of the technical (and product) people at both Cincom and Franz. My experience has been beyond excellent.
I have had excellent discussions with people about minute detail of implementation, and they’ve provided feedback that has been excellent at moving ideas along. Offers of help with proof-of-concept have been offered, insight into product roadmap, and even honest discussions of where things don’t work, have been the hallmark of both organizations. This is a stark contrast with most companies.
All I can is both companies have some of the most brilliant people I’ve ever had the opportunity to talk to, and their insight is illuminating. It’s nice to see there are a few places where true technical excellent is still critical. Helping your customers be successful will always help you be successful.
Comments Off
There are many reasons why Symbolics, who employed perhaps one of the greatest collections of minds ever, died. This is one of them. What did $185K buy you, before discount? 8MW RAM, and a pretty loaded box. But just one of them.
Ouch. Don’t drop that on your foot either. The big 3600 series were the size of a refrigerator. Maybe you were paying by the pound? I do miss my 3620, which was a small “tower” that was a manageable size. Unfortunately, it didn’t survive the move from TX to VA.
1 thought