I think it is time to call this blog complete. There will always be exciting things happening in the Lisp world, but I just don't have time to blog about it (as you have seen!) So in a while this blog will disappear. Bye, friends!

Someone should make a mirror because I can't figure out how to download my posts!

This would be too good to be true! Hopefully this would be the keynote every day!

Arc has hit version 2 already. This is pretty amazing! It's already one version better than a leading Common Lisp competitor, SBCL, which is languishing at version 1. It will soon catch up to CLisp at version 3.44. It gets tougher after that, with Allegro CL at version 8 and CMUCL at an incredible version 19! But the grand pappy of them all must be mzscheme, which is sitting pretty at version 372. I love arc but it will take a while to catch up to that!

Arc was famously released with a defiant attitude towards Unicode. If you think you need Unicode, you don't need Arc, or so the saying goes. This sure caused a ruckus among the idiots who would never use Arc anyway!

Then one guy had the audacity to say this:

"Okay pg, it's time to call you out. Unicode support is not trivial, like you make it out to be, and it's not a waste of time. It's a critical piece of infrastructure for any runtime. You fail."

Then came the knockout punch. Patrick Collison of CROMA fame added full Unicode support to Arc by adding -2 (that's minus two!) lines to Arc! Mr. Graham came out with this followup to the above sass:

"I'm glad this is preserved for posterity, since it did turn out to be trivial and in fact got added with about -2 lines of code a few days after this comment was posted..."

It's no joke. Unicode required removing things from Arc, not adding it! That's how damn elegant the language is! And the support is much simpler than it is in other, less elegant, more gross programming languages. For example, here's the entire definition of "upcase":

(def upcase (x)
  (let upc (fn (c)
             (let n (coerce c 'int)
               (if (or (< 96 n 123) (< 223 n 247) (< 247 n 255))
                   (coerce (- n 32) 'char)
                   c)))
    (case (type x)
      string (map upc x)
      char   (upc x)
      sym    (sym (map upc (coerce x 'string)))
             (err "Can't upcase" x))))

Other languages have to deal with databases, which are inherently slower and bureaucratic. Viaweb used zero databases!

When was the last time you saw an article about Lisp in The Register? Me neither! Thanks for the linkage!

I didn't know if Arc could replace my current dabblings in CL, but now I know it should very soon: Mr. Graham wrote Arc to get away from CL. Where he goes, there I will follow! Unfortunately a lot of my code uses arrays right now, but porting it to lists (or tables keyed with integers) shoudl be easy enough.

Thankfully Paul Graham has addressed the kerfluffle over utf8 characters. It's amazing that people were so eager to jump on some technical shortcoming instead of the real purpose of Arc: to make programs shorter. And what program is shorter than the one you can't write in Arc at all? That is a meta solution that too many are overlooking in their eagerness to be high school bullies towards Mr. Graham!

Here is an idiom I am forced to use a lot in Common Lisp:

(incf (gethash table key 0))

The wacky historical names make it hard to tell (incf? come on, ANSI!), but it increments the table entry for key in table. If key is not in table it uses a default value of 0, adds one to it, and stores it back in the table.

Arc does not have this onion. Instead, you see this elegant style used again and again in the arc sources:

(= (table key) (+ 1 (or (table key) 0)))

As you can see, this is much shorter (just line up the code above with this code). Partly because the symbols are very short; aside from the table and key name, the only arc symbols needed are =, +, 1, 0, and or. There is almost a mathematical purity to those symbols. It reminds me of the famous equation: e^pi i - 1 = 0.

Arc is out. I didn't know if I would be writing these words in my lifetime. I was beginning to think I was stuck writing Scheme (ugh) Common Lisp (double-ugh!) forever. Don't get me wrong, those languages have their places but on the whole they are incredibly gross and messy. And not in the wanton, sleek way Arc is gross and messy.

First of all, Arc is a compiler. This is a boon. There are too many toy Lisp interpreters out there already. It compiles the Arc language to a lesser language. In this case, the lesser language is Scheme, but that's just an implementation detail. I'm sure these Arc will be ported "to the metal" (or is that "to the meta"? ha ha!) soon enough by an enterprising student who doesn't listen when the master says it can't be done, just like John McCarthy and the student who ported Lisp to the metal. That guy.

Another remarkable thing about Arc is what Mr. Graham has been able to strip away. He has gotten down to the essence of the language. Everything else can be added on. Common Lisp is incredibly and unnecessarily complex, so by stripping things off you can get a lot of power and flexibility. For example, you can take Common Lisp. Then take away packages, specialized vectors, CLOS objects (OO, ugh!), structures, complicated lambda lists, complicated streams, generic functions, a tree shaker, delivery options, native code generation, Emacs integration, the potential for a commercial IDE, arglist hints, symbol completion, Unicode support, debuggers, profilers, inspectors, GUI tools, and a lot of other cruft.

What you are left is is the bare essense of coding. Everything written is essential. Nothing is superfluous. There are truly no onions. The specification of Arc (which is the implementation of Arc) can be printed on just a few pages (full duplex); the whole thing is 4609 lines of code!

Let's be clear. Paul Graham is the #1 Lisp luminary right now. When he writes that he is a typical Lisp hacker, it's also 100% true. But there's another factor. He's typical, to the nth degree. When he says Lisp needs to go in a new direction, people who know nothing about Lisp will sit up and listen. It's his kind of leadership that will bring Lisp back into the mainstream.

This blog post is a little long. I'll leave you with the axioms of the new Lisp world:

(define (ac s env)
(cond ((string? s) (string-copy s))  ; to avoid immutable strings
      ((literal? s) s)
      ((eqv? s 'nil) (list 'quote 'nil))
      ((ssyntax? s) (ac (expand-ssyntax s) env))
      ((symbol? s) (ac-var-ref s env))
      ((ssyntax? (xcar s)) (ac (cons (expand-ssyntax (car s)) (cdr s)) env))
      ((eq? (xcar s) 'quote) (list 'quote (ac-niltree (cadr s))))
      ((eq? (xcar s) 'quasiquote) (ac-qq (cadr s) env))
      ((eq? (xcar s) 'if) (ac-if (cdr s) env))
      ((eq? (xcar s) 'fn) (ac-fn (cadr s) (cddr s) env))
      ((eq? (xcar s) 'set) (ac-set (cdr s) env))
      ; this line could be removed without changing semantics
      ((eq? (xcar (xcar s)) 'compose) (ac (decompose (cdar s) (cdr s)) env))
      ((pair? s) (ac-call (car s) (cdr s) env))
      (#t (err "Bad object in expression" s))))

I am almost hyperventilating here! You can go download Arc right NOW! I can't wait to feel the elegant language-tsunamis this unleashes as thousands of hackers realize their potential!!! Can't talk...must download!! I promise a full review in the next few days as I bask in the reflected macro, closure, and elegance embodied in ARC!!!!!!!

YAY!!!

Here is a blog post that teaches an important lesson: An elephant like CLOS isn't needed to dance on the deftly woven webs of closures.

Paul Graham has deigned to share more tantalizing glimpses into the future sublime juggernaut we call Arc. I was so pleased and surprised to see that he has a construct very much like my own w/file called w/infile! (See the def for codelines)

I can tell that switching from BruceLisp to Arc will be like slipping into an old, familiar, elegant boot!

Oh my! It appears that I have been discussed on comp.lang.lisp recently. Sorry I haven't written more lately, but I've been very busy and haven't been able to work on Lispy topics as much as I have wanted to lately.

So what's on my mind? The same themes that have puzzled Lisp enthusiasts for decades!

1. Macros -- I always come back to Macros with Lisp. Along with tail recursion, it's the way that Lisp stands out from other languages.

2. Closures -- another feature unique to Lisp, closures are basically object orientation...done right! No more spaghetti code with so-called classes, objects, etc. You can just get all the functionality you need by deftly weaving closures together. As you may know, spaghetti doesn't weave. It snaps or is just too greasy to hold together. Lisp closures are more like thread. (But not like threads, which are another barbaric construct.)

That's it for now...I'll write more later!

One of the nice things about Lisp is the REPL. That stands for Read, Eval, Print, Loop. I like to think of it as Read, Experiment or Explore Print, Loop. That's because when I have questions about how Lisp works, I Experiment and Explore at the REEPL.

Other languages do this too, such as python with its dir() function and ruby with the ruby shell. Perl also has the debugger, which is a great interactive perl shell too.

A big downside of Common Lisp is the size of its specification. Scheme's spec is 50 pages. Lisp's spec is over 1000! There's an old joke: how many common lispers does it take to change a light bulb? One, he just stands on the spec, reaches up, takes out the bulb, puts in a new one, and the light's changed. By that, I mean the spec is pretty big.

But the good thing is that you rarely have to read it. If you want to know how a function works, just experiement! Here's an example. I want to get random numbers. So I just start by typing a bit:

CL-USER> (ran <-- cursor is here

Then I push TAB, and out pops "random"! Lisp is great that way! But how does random work? Easy, let's just experiement a little:

CL-USER> (random 10)
0
CL-USER> (random 10)
5
CL-USER> (random 10)
1

From that short experiment it's easy to see that random is a lisp function that returns a random integer between 0 and 1/2 its argument (in this case 5, which is 10 times 1/2). Why they picked 1/2 I don't know, but you can always multiply by 2 if you want to do something like select a random element from a directory. There are also some web services that will return random numbers. I don't have all the answers, get creative!

My last post has received too many negative comments. Let's brighten up the tone by discussing some of the things Common Lisp got right.

1. Obviously, macros have to get the top billing. Macros are like little compilers. They take your source code, do some transformations, and turn it into unreadable CPU-specific code that is blazing fast. For example, (defmacro my_plus (&rest; args) (apply '+ args)). You don't have that kind of flexibility in other languages (except C with some inline ASM, but Lisp gives you more abstractions to work with (also C suffers from the too-fast problem, but that's a different blog post (oh no, look at the parentheses (can you tell I love lisp? :))))))

2. Pathnames

3. The ability to make your own object system at will. This is partly an advantage of macros but I need to come up with at least a few good points.

4. Elegance & grace of some parts (if you avoid the unelegant parts). For example, the ability to rename defun to define and make it more logical and memorable in the process.

Can you think of more? Please share in a comment...and let's keep it positive, please!

Sometimes people ask me why I stick with Lisp if I am critical of it. First of all, I love Lisp. It's Common Lisp that gives me fits sometimes. There are a lot of things that need fixing, and even people who think Common Lisp is ok will give you a long laundry list of problems. For example, there are problems with the type system, the object system (no Visitor pattern built in??), the macro system (dirty unhygienic macros by default??), the number system (slow "big nums" by default?? this breaks every algorithm out there), the variable namespace system (Lisp-2?? This was discredited a long time ago! just read any blog), the type system, the condition system (exceptions are slow...this was proved by C++ in the 80s). What was ANSI thinking? The good thing is that some of these can be fixed by the Lisp community. How about it, community?

So why Lisp? And why Common Lisp? The alternatives are worse.

• Python - this one is easy. Slow, whitespace sensitive.
  
• Perl - hard to read. Good mix of fast and slow.
  
• Ruby - too slow.
• C - hard to read, too fast
• C++ - hard to read

I hear you asking: Why not Java? Java's not too slow, not too fast, and easy to read (especially after reading the sublime The Java Programming Language, 3rd Ed). It isn't whitespace sensitive. It runs on every platform. It has a wealth of design patterns and enterprise tools. However, it lacks two key things: macros and closures. If they added clean and elegant macros and closures to Java, I wouldn't feel bad about using it. At that point, it would be a form of Lisp!

I don't know how I missed it, since I'm probably the biggest Arc fan out there, but Arc has been released! ...after a fashion! Paul Graham has been testing its sublime waters with its first public application, Startup News from YCombinator. (I thought it was going to be a spam-proof web-based email service, but I'll take what I can get!)

The source code for the site is not available, but based on Mr. Graham's past writing I can imagine the elegance. Instead of writing a bunch of code to display pages, it is likely a symphony of Little Language construction. This Little Language (built in Arc) is customized very precisely for the problem at hand. Then all the tasks in the application boil down to actions expressed in the most concise, powerful way possible.

Of course I cannot be sure, but I bet the exclamation point on the end of the Startup News sentence is this tour de force of brevity, concision, and domain specificness:

(mkreddit frontpage-downvotes: #false)

Mr. Graham can confirm or deny in the comments, if he deigns.

I am still working on finding more time to blog. I know there are people who really enjoy Lisp at Light Speed. Rest assured that I am still reading a lot and thinking a lot about Lisp, and sometimes I write Lisp too. Here are some links for today:

• What about Lisp?
• SubX

The author of these two pieces gets into a key issue for Lisp: intuitiveness. I wonder if he's aware of Bruce's First Law of Lisp?

Whether, if, upon inspection, the "design" of a thing, may be taken, it is not altogether clear taken as true, whether to trust in the thought of a planner &mdsah;; can it be seen as "true design" or rather a fortunate accident, not being visible to the planner directly? Yet this is how without introspection and -- before reconsideration -- the planner must decide the merit, or congrutiy, of said thing.

There may be some of the lispers who taken with power decide their view is "over the horizon" and yet perfect, without adaptability, and thus must take all others as "contrary, foolish, and without merit" -- yet to do so, premature, invites bickering.

Yet it is an accident mostly, yet they do not see it thus, but the collision of "reality" must show the "design, of a thing" a failure or success, by chance.

Now this is what I'm talking about! People unbiased by knowledge of or experience with Common Lisp are the real movers and shakers in the Lisp community!