smart stuff

Arc released

Paul Graham released the first version of arc a new Lisp dialect.

Clojure from Ruby

A JVM-based Lisp interacting with JRuby.

Robin Bhattacharyya posted this on Jan 13 to clojure@googlegroups.com

 I was playing with JRuby and wondered how hard it would be to consume
 Clojure from JRuby.

 It turns out that it was not hard at all.

 For anyone interested, I attached a working interface.

 Robin

groups.google.com/group/clojure/browse_thread/thread/41e811c158d7881f/b31dc456fb5280ed?lnk=gst&q=JRuby#b31dc456fb5280ed

Average Salary of Lisp Jobs is greater than that of Java, C# or Ruby coders

Interesting statistic. A Lisp coder earns on average $85k, while a Java-guy $76k. I wonder whether that statistic would change if one takes out the age-factor. :-)

Let’s admit it, Lisp coders are on average very smart, but so are the early ruby adapters .. and they get only on average $60k. Sniff ..

The Common Lisp Directory release 2 is online

The Common Lisp Directory release 2 is here: www.cl-user.net It’s powered by LWL 4.4.6 on a Debian server.

Made with secret alien technology

Enjoy the humor :-)

 ---- Forwarded Usenet-message ----
 From: "Pascal Costanza" <pc@p-cos.net>
 Newsgroups: comp.lang.lisp
 Subject: Re: Lisp Logo Madness!
 Date: Sat, 29 Oct 2005 00:21:40 +0200
 URL: news://<3sfmjlFnv7dfU1@individual.net>

 drewc wrote:
 > Alan Crowe wrote:
 >
 >> drcode@gmail.com writes:
 >>
 >>> I have built a logo set that I hope can fill this void.
 >>> There's several logos in different shapes and styles all built around a
 >>> central design.
 >>>
 >>> http://www.lisperati.com/logo.html
 >>
 >> The creature is very cute, but I think he should have a
 >> fifth leg, to match having five eyes.
 >>
 >> Alan Crowe
 >> small rock
 >> 93 million miles out
 >  This is a popular newbie request. In Common Life is is trivial add such a
 leg, and if you look around it has been done before. While i might agree
 that it is a useful feature, it's not worth revising the standard simply
 because the legs and eyes don't match.

 It's actually an advantage that the numbers of eyes and legs don't match
 because this allows you to infer from just partial information what you
 are dealing with. So, say, you see the number 4 mentioned in your
 program source, you will immediately realize that this is about the
 legs. Vice versa, if you see the number 5, you know that this is about
 the eyes.

 Schemers think that it is an advantage that their language has exactly
 one leg and exactly one eye, and they claim that a hygienic organ system
 can help you disambiguate the possible confusions arising from this. So
 when you see a 1 mentioned, the organ system can infer from the lexical
 scope whether it is a leg or an eye. However, I think this just appeals
 to some weird mathematical aesthetics. The 4-legs-5-eyes system has been
 around for nearly half a decade now, and noone in the Lisp community
 really has ever had any problems with that.

 > You must be a troll.

 Don't be so harsh. There is a whole chapter in Peter Seibel's "Practical
 Common Life" in which the 4-legs-5-eyes system is explained, so it seems
 to be a real problem for newbies - at least for those coming from other
 languages.

  Pascal

Another myth debunked

Source: groups-beta.google.com/group/comp.lang.lisp/msg/df76d0d07a750854?hl=en

 Mike wrote:
 > What is a smaller lisp implementation that runs on both
 > gnu/linux and windows?

 Let's see, the user will have to install Linux to run the program, but
 the footprint of that program has to be small. :)

 Have you run a system call trace lately on, oh, the ``ls'' program?
 Tons of shared libraries attached. System calls flying left and right.
 A bazillion nonexisten files searched after.

 Linux is not exactly small and lightweight (any  more).

 Here is a comparison between a directory listing and evaluating a
 single expression with CLISP:

 machine:$ strace clisp -norc -q -x '(+ 2 2)' 2>&1 | wc
    260    1963   19729
    machine:$ strace ls /dev/null 2>&1 | wc
        111     870    8225

 It only takes about 2.5 times as many system calls to start up CLISP to
 evaluate an expression than to fetch a directory listing for a single
 file.

 The size of this Lisp system is less than 3 megabytes: a 1.2 meg
 executable and a memory image that is about 1.4 megs.

 Then we add up the shared libraries:
 machine:$ ldd ~/lib/clisp/base/lisp.run | gawk '{ print $3 }' | xargs
 du --total --dereference
 176     /usr/lib/libreadline.so.4
 852     /usr/lib/libncurses.so.5
 16      /lib/libdl.so.2
 1540    /lib/tls/libc.so.6
 20      /usr/lib/libgpm.so.1
 112     /lib/ld-linux.so.2
 2716    total

 The shared libs are as big as the program.  The kernel on this system
 (the uncompresed vmlinux file, not the compressed vmlinuz!) is about
 3.5 megabytes, whoa! Of course, all these executable images have
 run-time storage requirements as well.

 This particular Lisp system is smaller than the kernel, smaller than
 the total size of the shared libraries attached to it, and cranks out
 only about 2.5 as many system calls to evaluate an expression and quit
 as ``ls /dev/null''.

Lisp success story: CliniSys

Kenny Tilton posted this on May 26 to comp.lang.lisp

 The question is _where_ is it gaining ground...
 as a hobby (which I presume is what most c.l.l readers,
 myself included, use it for), or as a substantial outfit
 in a company or in academics, and in the latter I see none
 of it in the last couple years (the almighty Java seemingly
 smothering all and everything).  Any recent success stories
 (i.e. new or significantly increased use of Lisp) here from
 non-hobbyist camps that someone is willing to share?

Sure, CliniSys. Clinical drug trial management. Don’t ask. It is a big problem. Sites by FDA requirement must operate independently of the drug sponsor in conducting trials, which the FDA further want conducted in precise fashion and with elaborate documentation. Investigators are busy people and often screw up. Monitors from the sponsor visit every six weeks to corral things temporarily.

Our mission was to bring everything under control with a thick client installed at the site guiding sites thru the process, enforcing business rules, and basically seeing to it that the whole process runs right while documenting everything and with a precise audit trail of that process and documentation. The thick client also meant we needed a sophisticated application-level partial replication scheme to move clinical and audit data around a wide-area network of collaborating trial professionals.

The hard part is that every trial is different. Even within a trial, the documentation can vary from site to site. On the wish list is customizing documentation to individual patients to support adaptable trials. To make things worse, the documentation can change in the middle of a trial, but data collected under one version of a document must remain associated with that version as other versions come along.

And getting the documentation right means applying arbitrarily sophisticated edits. eg, The pregnancy test result on Visit 2 is required if the gender collected at Visit 1 was female, otherwise it must be "Not applicable".

The final challenge is scaling any successful result to hundreds of trials a year. Existing software does a small fraction of our intended functionality and is so hard to configure to each trial that (a) they can get $500k to do a big trial and (b) vendors max out at a couple dozen trials a year. They hope sponsors will run the software (they call it "technology transfer") and figure out how to configure the software themselves faster than could the vendor. They do worse, and a lot of these vendors go out of business.

So we needed to do WYSIWYG DTP, ICR (scanning and reading documents), our own DBMS, workgroup software to support remote monitoring, and a full browser app for reviewing and collaborating on the documentation set. ie, we needed a GUI, too.

I knew right away that we would have to be able to configure the application for a new trial without programming. Well, there would be a scripting language, but it would be the kind of thing power users master all the time. I also figured out pretty quickly that it would be easier to make a programmable application with a programmable language.

The project was two years old and $2m spent when I signed on to take over software development. My predecessor had just quit. In an exit interview I determined that he was making the right move for himself, but that I would like the gig.

The angel founder trusted me to use the right software, which only makes sense since he was betting $3m on me succeeding. I brought on one other person and in four man years we produced a system that was vastly superior to systems built with tens of millions of dollars. 80kloc Lisp.

People in the business agree our system will revolutionize the conduct of clinical trials. Some nice big partners have joined the effort to make our case to our first customer. That helps since it is a little stange for a three-person operation to have done what no one else even thought possible (which is why they were all trying to use the Web to solve the problem). Making progress, though. Close brushes more often <g> getting both customer and investment.

How did we do it? First, I had done this programmable application thing a couple times before. Second, Common Lisp. Third, Cells. Fourth, AllegroCL’s AllegroStore database. Fifth, AllegroCL’s IDE and Franz tech support.