Didn’t you found Lisp?

I’m trying to learn java and lisp(scheme) at the same time. But why should I. Won’t I be replaced by a programmer in the third world?

I’m learning Common Lisp now for a class, after taking Scheme several years ago, and programming professionally in Java for a few years.

My highest level impression of Lisp is that it’s too clever. I can see how Lisp enables certain very elegant programming structures, how a 20 year veteran could whip something up that would wow an audience in less than 100 lines, how it’s an extremely artful language. And that may be its problem.

At the same time as Lisp offers great aesthetic possibilities, it stands in my way of accomplishing small things simply. I’m left with the nagging suspician that I’m doing something wrong, even after I’ve wittled things down to a beautiful, recursive nubbin of a function. It’s all parentheses and nested closures, and it seems incredibly un-intuitive, such that I despair of making it to that expert level where the universe unfolds for me in Lisp.

If I may analogize it to my art education, Lisp seems like brush drawing: a tool of great skill and delicacy allowing impossible things, but also one that seems out of reach to most actual artists. It seems to rarefied to be useful to most.

Fazal,

In truth, many areas have too much healthcare (see http://www.dartmouthatlas.org/) – and “more” often does not translate to “better”. As I’m sure you’re aware, the same can be said for software engineering. Possibly why Lisp gets short-shrift?

Two other quick comments:

- The debate over the MMR vaccine and autism stemmed from a highly flawed study published in The Lancet (e.g. very small, non-random sample). The concern with Thimerosal (mercury-containing vaccine preservative) has more scientific merit.

- I believe France has socialized medicine, which means the government foots most of the bill.

Having learned Lisp over the eight months and presently being in the process of creating a product using Common Lisp, I could not resist to commetn on this thread.

Boradly speaking todays Common Lisp implementations offers all I can get from the SUN Standard Edition java except a cross OS/hardware/Common Lisp implementation GUI toolkit.

Yes Common Lisp of today does have threads and tcp/ip sockets. Though they are not a part of the ANSI standard, libraries exists that gives them a uniform API no matter which Common Lisp implementation you are targeting. The threads comes on both flawors, ie. in-process simulated ones (called green threads in java), and threads the OS is aware of and can spread over multiple CPUs etc. Of course you can also fork in Common Lisp.

What Common Lisp gives me that Java does not give strait away me is:

macros (which again can give me a great amount of features unavailable in java, C++, c#, VB etc.)
continuations (only available in CL after a little extra work – see “ANSI Common Lisp”)
signals and restarts
generic functions and the dispatch model of CLOS
multiple return values, optional arguments
type checks that can be switched on and off as needed in the various phases of program creation
multiple vendors of mature compiler and runtime implementations

Regarding the alleged lack of substitutes for J2EE, Xerces etc. I have experienced this as less of a disadvantage than I had anticipated. It turns out that by using macros and lambda functions combined with restarts and signals while taking advantage of closures it is possible to do what JSP/Servlets/EJB are trying to do, and do it with so few lines of code that J2EE seems extremely cumbersome in comparison. Basically what is happening is that you are able to get a few layers of abstraction above the level on which J2EE operates, and this is what gives the productivity gain. I am exploring this at the moment, and being both surprised and very pleased at what I discover!

Regarding the programming environment it is a mixed bag. The Franz implementation has a wonderfully productivity enhancing IDE while implementations such as the CMU CL comes without an IDE, and you are supposed to use xemacs, which btw. is a surprisingly effective way of working with the ilisp package.

What I am doubting at the moment is how well Common Lisp lends itself to projects with more than two-three programmers, or with programmers who are less than very good at understanding a program in great detail as well as on all the higher levels of abstraction at the same time.

Java seems to be very good for situations where you need to enforce processes upon a great number of programmers in order to avoid having them shoot each other in the foot, and instead actually being able to produce something. This makes Java a likely “COBOL for the 21 century”.

Language features seem like OS features — bring in the investment, they’ll be shoved in somehow.

Someone (whose name escapes me — an AI guy who famously telecommutes for $35/hr) proposed to a large Common Lisp vendor that he’d happily contract with them to build .NET support. Xml, soap, yadda yadda. He says they haven’t taken him up on that offer. If they’re at all rational, and they did survive the AI winter, we can assume their customers haven’t exactly been clamoring for these features. I would extend this to type-inferencing and design by contract.

But I wonder why anyone would assume Lisp is in a terrible position. People are slowly ingesting the usefulness of optional typing.. functional style.. gc.. is it maybe that the world needs to learn block by block?

Love what’s under LISP, have a lot of trouble reading it. Total lack of signposts in the language; it doesn’t get tokenized by my brain very well.

The most powerful thing about Lisp is eval, and s-expressions. In fact, that pretty much defines the language.

The barrier I’m worried about is how well the runtimes behave in the large. Java runtimes run very comfortably with multi-gigabyte, heavily collected heaps these days, which is something our customers play with every day. I haven’t see or heard much about how the LISP runtimes play in those kinds of environments. I’m curious.

Old-style Lisp or Scheme is not the best we can do. Languages with the kinds of semantic straightjacketing you mention, however, do indeed result in programs that are excessively resistant to exploratory development.

But consider one way to adress this deficiency: instead of using formal specifications purely to constrain what the programmer can do, we could use them to enable richer, more meaningful changes. After all, we want restrictions on our programs that will make them do the right thing when they can, and make it clear when they cannot. The problem is too many unneccessary alarms. But your language (or development environment) could tell you where and why you broke a precondition or failed a type check, and offer you options for fixing this including changing types or broadening preconditions. Then you could not only explore and improve the program but rework the straightjacket so that you end up with the strongest rules supporting the most essential parts of your program, and flexibility where it is required.

Automatic tools can already help you move a method between classes, but that’s elementary. What if you could find out exactly what changes would be needed to have some off-the-shelf component handle a new kind of input? Type systems and preconditions help a lot when doing the kinds of formal analysis that could help answer a question like “how is this input to this function used?”.

Sure, some of the changes you make will only be small steps to recovering the flexibility of less structured languages. But the changes will be fast and no-risk, made automatically by your IDE. The payoff, hopefully, would be to take advantage of constraints by using them not just to eliminate options but to discover them.

Actually, Lisp is lurching forward into the 21st century as people develop new IDEs, SOAP implementations, web tools, etc.–a good place to keep up with new developments is John Wiseman’s weblog, Lemon Odor: http://www.lemonodor.com

Be sure to read the archives too.