So far I've failed three times to write something that is short and to
the point but brevity has never been my strong point. If you're in the
mood for a long read, well at least you've been warned in advance and
I've put a fitting title on it.
The Common LISP Road Block Manifesto
The gardeners project seems to be pointed at making Common LISP more
appealing, yet in a strange way, this implies CL is not currently
appealing. Have you ever made the mistake of telling a woman she would
be *more* attractive if...
Regardless of what you say about Common LISP, you stand a reasonably
good chance of seriously offending someone. Please understand I have no
intention of offending other people.
All the freedom provided by the Common LISP specification along with the
creative solutions provided by language implementors makes for a very
powerful and flexible language which is excellent for researching and
solving very difficult problems.
The most significant road block is the overwhelming majority of problems
faced by programmers are not difficult. When the goal of the programmer
is to create a simple application like an open source MP3 player or a
system maintenance tool to backup files to another place, the
flexibility and power of Common LISP actually get in the way of getting
the job done because various implementations have vastly different ideas
of how to do the trivial tasks.
With the exception of providing ways to read and write files, the Common
LISP specification generally ignores the operating system running under
the implementation. Simple things like accessing environment variables,
running shell command, using threads, using streams, OS pakage/install
systems, native executable formats and even the dreaded type definitions
needed to communicate with programs written in other languages are not
covered by the Common LISP standard. This has it's advantages, like
allowing implementors to code any solution they want but it also has
disadvantages, like allowing implementors to code any solution they
want.
Whether you consider this freedom and the result of this freedom to be a
failure or a success of the Common LISP standard is nothing more than a
personal opinion and voicing either opinion will most likely incite a
riot in the comp.lang.lisp group of usenet.
Though the flexibility and freedom provided by the Common LISP standard
enables the people to a lot of amazing things, it also means all
implementors, and more likely developers, are forced to reinvent the
wheel every time they want to do something very common.
POINT #1: LIBRARY
I think most would agree modifying the real, certified STANDARD for
Common LISP would be a long, painful nightmare, so the only working
solution is developing a "de facto" standard through adoption of a
library containing commonly needed functionality by all Common LISP
implementations. In other words, the library would be included and
available in all implementation distributions.
POINT #2: LICENSE
The difficult part is promoting adoption. When you look at all the
various Common LISP implementations you'll hopefully notice they all use
different licenses. This is a huge issue. If you want code to be
adopted, incorporated and used by all implementors, the license must be
free from restrictions and free from risks.
Some of the issues and debates regarding licensing of Common LISP code
are caused by the way in which Common LISP works, namely, you are always
dealing with what could be considered a "Compilation" by copyright law
and often you're dealing with both a "Compilation" and a "Derivative
Work" at the same time. The reason you re dealing with a "Compilation"
is there is no clear or distinct dividing line between the language
implementation itself and the additional application code running within
the implementation. Since Common LISP is specifically designed to modify
itself on the fly, by doing so, "Derivative Work" is created. Copyright
law is based on the idea of clear distinctions and inheritance of
derivatives so copyright law is woefully unprepared and inadequate to
deal the way LISP normally works.
Since "fixing" Common LISP to "work" within the expected bounds of
copyright law would only destroy the language and fixing copyright law
to handle Common LISP would be darn near impossible, the result is we
just need to accept the situation and live with it. None the less, we
need to accept the fact that unique operation of Common LISP, in spite
of being quite powerful, presents a risk for anyone concerned with
copyrights.
Gaining both industry and individual support for a useful technology, is
now, and always has been, a matter of easing adoption. The easiest way
to promote adoption is by reducing the potential risks posed by the
adoption and incorporation of the technology.
I do not wish to insult or offend the good folks at the GNU or in any
way discredit the hard work they do, instead, I only want to point out
and explain the cause and effect of their licensing in regards to the
adoption of a Common LISP library. More importantly, you do not need to
agree with *my* personal interpretation of GPL/LGPL usage on Common LISP
code to witness the _effect_ of its usage.
If your common lisp code is under a GNU-GPL or GNU-LGPL license it
is not usable for any purpose. Both the restrictions of the license
and the fact that *some* consider the LGPL to be vague will prevent
wide spread adoption of your code.
You may or may not personally agree with the statement above but if you
look at the real world, you will see that it still proves to be true.
If the license you choose to release your code under has unnecessary
conditions or is any way legally vague, the risk posed by "guessing"
what would happen in a legal battle is simply not worth any possible
reward you would gain from using the code. This means that anyone who
wants to do something painfully simple like read system environment
variables is forced to reinvent the wheel by writing their own code
rather than just using the existing CLOCC/PORT code. The sad part is the
developers of CLOCC/PORT (Sam Steingold and Marco Antoniotti) very
intentionally used the less restrictive LGPL rather than the GPL in
hopes of wide spread adoption without any license problems.
Unfortunately, things have not worked out as planed.
Everything survives by correctly managing risk. When you look in your
fridge and see that left-over piece of steak that you cooked a number of
days ago, you mentally manage the risk of whether or not it's still safe
to eat. Even if you are unaware of it, you are still making a life or
death decision.
Well run businesses are really no different; they manage their risks.
Though you may not personally think there are risks caused by using a
GNU license designed for C/C++ on the source code of a language that is
vastly different, you still need to accept the fact that others disagree
and the disagreement thwarts further Common LISP standardization and
adoption. You also need to accept the fact that the GNU will probably
not be able to "fix" their licenses so they properly address how LISP
variants work. The legal tools necessary (i.e. copyright law) to deal
with how LISP variants work, simply do not exist, so any attempt by the
GNU to "fix" the situation will most likely weaken their legal stance.
If perchance you are a license zealot, don't waste your time trying to
blame the GNU for the lisp license problem. It's not their fault and
they can't fix it.
Whether you're a commercial software company, a BSD zealot, or you're
want to help the GNU take over the world, the end result of Common LISP
licensing conflicts is the current status quo, namely, de facto
standards can not be reached to augment the formal specification.
We do not need a yet another recreation of November's comp.lang.lisp
license debate threads, instead, we just need to do is accept the fact
that there are differing opinions on acceptable risk and try to find a
consensus that works for everyone from commercial implementors to open
source implementors. The goal would be a single source tree that all
implementations can incorporate and sync with regardless of their
preferred licensing.
I guess I should make the "One Ring To Rule Them All" joke around here
someplace but really it's more like a single library source code
repository that all implementations can share regardless of the
particular licensing creed they chose to follow.
POINT #3: HUMILITY
It takes a certain degree of pragmatic humility for a developer to admit
to himself that End Users simply don't care what programming language is
used to write the program. End users are really only concerned with
three things: (1) the program works correctly, (2) the program saves
time for the user, and (3) the program is easy to install and use. There
is also (4); the program gets bonus points if it looks cool.
Anything routinely needed by developers to quickly and accurately
address the three or four concerns of their users should be included in
the language implementation or should be dead simple to add to any
implementation. In other words, developers are only End Users of
implementations, so the three/four concerns mentioned above also apply
to language implementations.
We also need to understand another fundamental difference between End
Users and developers. Personally, I think it's fun to have *dozens* of
language implementations and versions of those implementations installed
on a system as well as deal with the resulting conflicts as they
occur... -End Users think people like me are nuts. Personally, I think
flexibility offered by the multitude of possible ways to distribute
Common LISP programs is absolutely fascinating... -End Users think
people like me are nuts. Personally, I think its wonderful to have
debuggers and REPL's always running and I don't mind memorizing tomes of
arcane syntax to load, launch or query exactly what I want, exactly how
I want and exactly when I want... -End Users think people like me are
nuts.
Are you beginning to see the pattern?
Regardless if you choose to use CL, C, C++, Scheme, Java, Perl, Python,
Ruby, Eifel, Erlang or even brainf*ck, End Users will still think you're
nuts if you try to explain the reasoning of your technical choice to
them. End Users don't care.
Now let's pretend you are a developer using CL for the first time. In
this sense, you are a new End User of a Common LISP implementation. You
don't care who wrote the language specification or why it was written
the way it was, instead you only know that you can't use streams or
threads or access system environment variables... and just like any End
User YOU DELETE THE BROKEN PIECE OF TIME WASTING TRASH YOU MISTAKENLY
INSTALLED ON YOUR SYSTEM!
Yes, it's a bit harsh but it's true, painfully true.
I'm sure we've all done that more times than we would like to remember,
all users do. Neither End Users of applications nor End Users of
implementations want to be forced to jump through flaming hoops while
doing the cha-cha backwards and spinning fine china plates on long
sticks. When things are difficult to use, they are not used. It's just a
fact of life.
Another fundamental difference between developers and end users is
developers simply don't mind having to install, configure and set up an
whole bunch of stuff just to make something work. We enjoy making things
work and that's probably the reason why we are developers. End Users
don't want a bunch of stuff they'll never use installed on their
systems. Yes, as hard as it may be for the Common LISP crowd to admit,
End Users do not want a REPL they will never use installed on their
system. More importantly they do not want a full language implementation
installed for every single application they want to run. It's a waste
and could cause nightmarish conflicts that the user does not know how to
solve.
What Common LISP implementations really need is a way to produce a
simple runtime as object code, possibly as a shared object (.dll/.so)
and a way to generate executable loader for the target platform. Yes, I
know this suggestion is totally unlispworthy but it would make things
simple and easy to use.
In MS-Windows nomenclature it would be something like:
loader.exe -something the user can double click on
loader.ini -configuration information for the loader
cl.dll -a simple common lisp runtime
app.dll -the actual application
defsys.dll -an additional defsystem needed by the application
In the Apple world of MacOS you'd have an "Application Bundle" directory
with equivalent files in it. In the Unix world, the same kind of thing.
The goal is not to remove the freedom we have to choose some of the very
cool yet very esoteric delivery methods offered in various Common LISP
implementations, instead, the goal is to give End Users what they want,
provide them with a choice and grant them a freedom they want. As long
as Common LISP is determined to shove the "LISP Way" down users throats,
adoption will meet resistance and resentment.
With obligations to life, work and other open source projects, the time
I have available to hack on my own EE/EDA/CAD tools project is limited.
I simply don't have the time necessary to fight with implementation
specific idiosyncrasies, missing functionality or esoteric application
delivery. No one does. I just want to write some programs that people
can use on a lot of different combinations of hardware and operating
systems. I'm not expecting a million FOSS developers to descend on my
project out of nowhere to help out, instead, I expect to be the only
person hacking on it, so it really comes down to what I can do with the
time I have.
So after spending a good chunk of time investigating Common LISP, I've
realized it can not do what I need it to do. There is no realistic way
to make Common LISP work as a decent cross-platform and
cross-implementation scripting language for the developer build tools in
my project without writing a ton of code to abstract the implementation
differences and produce an easy to use delivery method for every CL
implementation. -If I really wanted to work on a programming language
implementation, I would rather write my own programming language from
scratch.
Lastly, the Common LISP Gardeners are looking at a difficult task but
the real difficulty is not technical, instead it's personal. I've spent
*many* years working with OpenBSD and communicating over the OpenBSD
mailing lists. Those lists have never been known for being friendly or
polite but the kinds of crap I see crossing the comp.lang.lisp usenet
group is just unbelievable. Sure, a bit of competition between
implementations, implementors and advocates is a great thing in
moderation but it shouldn't be a personal blood fest. If you want Common
LISP to survive and prosper, everybody will need to try accepting
differences of opinion and working together towards a goal. Until the
Common LISP community decides to drop the personal grudges, academic
pedantry and constant in-fighting, nothing will get done and you'll
continue to drive talented people away.
After my experiences on comp.lang.lisp I am honestly expecting to get
slapped for making the mistake of telling the Common LISP world that
they would be *more* attractive if ...
Unfortunately, there is no reward without risk. Before you decided to
start typing up inevitable the hate mail replies, please realize that I
thought enough of the language and you, the user base, to spend my
birthday giving you the most fair assessment of the situation that I
could.
Kind Regards,
JCR
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners
