Re: Decreasing the "standard deviation" of lisp

Cameron MacKinnon wrote:
Rainer Joswig wrote:
Unfortunately nothing will happens from a Usenet post.
Everything begins with working source code.

I don't think so. The Lisp community has managed to lose or misplace the source code to more functionality than has ever been written in most other languages save C. Every few years a new scripting language comes along and takes the programming world by storm, becoming vastly more popular than Lisp ever was, and it's a tautology that, in the beginning, they each had less functionality than currently exists in the Lisp world. How many languages have ever been used to build complete operating systems including assemblers/compilers, slick IDEs, network stack, device drivers and windowing systems?

If writing great code were enough, Lisp would have won a long time ago.

I think the scripting languages "take the programming world by storm" because they all explicitly or implicitly promise that "from now on" everything will be simple. They actually succeed in convincing people that that's the case by showing examples in which they are actually indeed simple. However, I am not convinced that they scale wrt a broad range of domains. Whenever a language tries to be truly general-purpose, it will reach a certain complexity that will make other more specialized languages look much simpler (and much more preferable). For example, check out some people prefer Ruby over Python.

It seems to me that Smalltalk is the only example of a language that didn't increase wrt complexity over the last few decades. However, I guess that the complexity goes into the tools / development environment. (You know, the complexity has to go somewhere, it cannot just disappear.)

Maybe all that the scripting languages prove is that domain-specific languages are indeed a good idea. The actual language framework for implementing them is typically C, which results in serious disadvantages wrt efficiency because the only sane way to implement a domain-specific language in C is by writing interpreters. (Notice that one popular way to extend those scripting language with efficient libraries is by implementing those libraries in C, not in the scripting language itself.)

What actually puzzles me is that those scripting languages, which tend to be dynamic / dynamically typed, are almost always implemented in static / statically typed languages (i.e., C). If dynamic typing is a good idea, they should, IMHO, actually be implemented in dynamic languages themselves. However, it seems to me that those who implement scripting languages subconsciously don't believe in dynamic approaches themselves.

What's also wrong with implementing domain-specific languages in a very different language is that the barrier between the two languages is too deep. It seems to me much more preferable that:

- The implemented language is closer in spirit to the host language. (For example, they should both be dynamically typed.)
- The implemented language is much better integrated with the host language, such that you don't need to cross a certain barrier to provide extensions.
- As a result, the different domain-specific abstractions can be mixed and matched in the same framework (because you may need different approaches for different parts of your system).

I think that Lisp is especially good at this kind of integration.

I am skeptical whether "we" can do both at the same time, make Lisp more accessible to a broader spectrum of programmers, including "newbies" and "average" programmers, and keep the expressive power of Lisp that makes it such a flexible and at the same time efficient language. For example, take a look at all the different "new" Lisp dialects: My impression is that they also explicitly or implicitly try to simplify Lisp, so the fact that they provide less than Common Lisp is not just an accident. I rather think that the loss of expressiveness is intentional.

It's easy to suggest cosmetic and aesthetic changes to Common Lisp, including those that would "accidentally" break existing code. However, it's hard to suggest substantial improvements, especially improvements that are not already available for Common Lisp in one way or the other, for example as vendor-specific extensions.

There are enough languages out there that aim to simplify things and make it easier for occasional programmers to write programs, including in the Lisp world (cf. ISLISP or Scheme). There isn't a substantial need for another one, but there must be room for expert languages, IMHO.

Just a few random thoughts.


Pascal

--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
.

Relevant Pages

  • When static typing is worth it
    ... typed languages like Lisp. ... developed more quickly in modern statically typed languages than ... static type system and remove run-time checks. ... incurs a run-time error if the list is ...
    (comp.lang.lisp)
  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... what MLish languages do in this case. ... If you are trying to compare my OCaml code with your Lisp translation then ... Lispers not only fail to understand the benefits of pattern matching ... but it is a Java extension just much as Clojure ...
    (comp.lang.lisp)
  • Re: LISPPA
    ... > memory resources. ... do in Common Lisp with code that runs about as fast. ... >> comparing Lisp with languages like C, Pascal and Basic, ... If by "visual programming" you mean the sort of ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... languages than there are jobs that require them as primary programming ... blog entries on Lisp. ... Lisp that sucks, ...
    (comp.lang.lisp)
  • Re: Settling on Lisp and Tcl
    ... most scientists don't program. ... > From my understanding so far there are those 'mathematical' languages ... > (lambda, functional, lisp) and there are those 'machine' languages ... programming languages, Lisp discourages functional programming. ...
    (comp.programming)