Paul Graham asserts, "To become popular, a programming language has to
be the scripting language of a popular system." Any opinions on why the
widespread popularity of Emacs, and thus elisp, hasn't translated into
wider popularity for Lisp? They aren't the same, of course, but they
are close enough.
I'd wager that the lack of a small Lisp environment for writing quick &
dirty utilities *might* be a reason. Anyone got a more convincing
hypothesis?
In article <························@f14g2000cwb.googlegroups.com>,
·············@yahoo.com" <············@yahoo.com> wrote:
> I'd wager that the lack of a small Lisp environment for writing quick &
> dirty utilities *might* be a reason. Anyone got a more convincing
> hypothesis?
Lisp is popular. it's just popular with a smaller segment of the
developer market. :(
As far as small Lisp environments go there are several really good ones
laying around. These aren't small Common Lisp environments mind you but
products like Xlisp or Xlisp-Stat, SIOD, and DrScheme. I've been using
Xlisp, on and off, since the late 80s first on an Atari ST and then
MS-DOS through Windows (of all versions) and I even managed to hack a
version to run under Mac OS X. Wow. Got sidetracked there...
Anyway there *are* small lisp-like environments out there. I think
Lisp's (by this I mean all Lisp-like languages) issue is getting over
the "it's a slow language for AI that has lots of parens" stigma.
Damo
In article <························@f14g2000cwb.googlegroups.com>,
·············@yahoo.com" <············@yahoo.com> wrote:
> Paul Graham asserts, "To become popular, a programming language has to
> be the scripting language of a popular system." Any opinions on why the
> widespread popularity of Emacs, and thus elisp, hasn't translated into
> wider popularity for Lisp? They aren't the same, of course, but they
> are close enough.
>
> I'd wager that the lack of a small Lisp environment for writing quick &
> dirty utilities *might* be a reason. Anyone got a more convincing
> hypothesis?
I think that's very much the reason. Paul's reference to scripting
languages is quite telling -- these languages typically make it very
easy to throw together simple applications, often as shell one-liners (I
know I've done this many times with awk and perl).
Similarly, I've done a number of quick-and-dirty personal applications
in Emacs Lisp, because it's an environment that's always accessible to
me. But since Emacs was not a commonly-used application at the company
I worked for, I wouldn't do this for anything I wanted to share widely;
I usually did those in Perl, since they could be run as simple
applications from the CLI.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> Similarly, I've done a number of quick-and-dirty personal applications
> in Emacs Lisp, because it's an environment that's always accessible to
> me. But since Emacs was not a commonly-used application at the company
> I worked for, I wouldn't do this for anything I wanted to share widely;
> I usually did those in Perl, since they could be run as simple
> applications from the CLI.
You lost an oportunity: emacs -batch loads faster than perl!
Write your CLI scripts in emacs! (or better: clisp).
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
Pascal Bourguignon <····@mouse-potato.com> writes:
> You lost an oportunity: emacs -batch loads faster than perl!
> Write your CLI scripts in emacs! (or better: clisp).
I did take such an opportunity.
Shortly--too shortly--before the transit of Venus across the Sun of
June 8, 2004, I was given the task of doing a webcast of the event
with the live images from a CCD camera with H-Alpha filter on the roof
of the Hoepli Planetarium in Milano, Italy:
http://www.comune.milano.it/planetario
Time was not much, and the video server for getting the images from
the camera, and making them available to our LAN, was delivered to us
only on the afternoon of June 7. I was able to put together a few
short Emacs Lisp scripts that periodically pulled the images and made
them accessible to the web site. The result looked like this, and we
were able to do a decent webcast:
http://217.31.114.39/doc/04/venere/transito.php4
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
············@yahoo.com wrote:
> Paul Graham asserts, "To become popular, a programming language has
to
> be the scripting language of a popular system." Any opinions on why
the
> widespread popularity of Emacs, and thus elisp, hasn't translated
into
> wider popularity for Lisp? They aren't the same, of course, but they
> are close enough.
Apparently, no one took advantage of this similarity. There is a gap
between using Emacs and using CL. What is the bridge?
Today, that's probably Slime; but on the most common personal computing
platform (Windows), Slime+CLisp is still kind of buggy. I think Lisp in
a Box is a great idea, but I wouldn't yet recommend it to anyone.
I'd also consider that CL documentation was written with an AI audience
in mind. Today, we have Practical Common Lisp.
MfG,
Tayssir
·············@yahoo.com" <············@yahoo.com> writes:
> Paul Graham asserts, "To become popular, a programming language has to
> be the scripting language of a popular system." Any opinions on why the
> widespread popularity of Emacs, and thus elisp, hasn't translated into
> wider popularity for Lisp? They aren't the same, of course, but they
> are close enough.
Probably because Emacs isn't that popular in the big picture. I'm
guessing the figures here, but suppose it had few million users in
which case there were several hundreds of millions of non-Emacs users
out there.
But relatively, ELisp probably has made Lisp more popular. Compare the
number of programs that internally use or embed a Lisp interpreter and
are written for:
- Unixen (Emacs' native platform), and
- Windows (a platform where Emacs has a fraction of popularity).
And I think there are quite a lof of hobbyist lispers, who found the
language family while tweaking Emacs. Just look at the number of
packages bundled with emacsen, plus the huge array of those that
aren't bundled.
How many of other, more popular editors actually support some sort of
a scripting language?
How many and how large such extensions have been written for those
editors?
How many people even think of _programming_ their text editor
_program_?
Looking from there, why the heck does some weird Lisp-based text
editor engine from the 80's have hundreds of full-blown applications
written on top of it, then? Still in 2005? I, too, bet that the reason
is that it has been easier to write those programs in Emacs than in
other, contemporary, programming environments. And because Lisp is
just plain fun, IMHO.
> I'd wager that the lack of a small Lisp environment for writing quick &
> dirty utilities *might* be a reason. Anyone got a more convincing
> hypothesis?
Depends on the Q&D utilities in question since they're domain
specific. The most popular domains are very simple, like the domain of
text stream processing, interacting with other programs+processes, and
managing files -- courtesy of traditional Unix shell & related
utilities. You can get away a long way with sh, awk and recently,
perl, so there has been no urgent need to roll-out Lisp instead.
br,
S
Simo Melenius wrote:
> But relatively, ELisp probably has made Lisp more popular. Compare the
> number of programs that internally use or embed a Lisp interpreter and
> are written for:
>
> - Unixen (Emacs' native platform), and
If only it were. Many's the time I've had to suffer the indignity
of having to use vi (which I consider inferior to Microsoft Notepad)
on a Unix system because Emacs was unavailable.
ITS is Emacs's native platform, where it was written, mostly by Richard
Stallman, in TECO (not ELisp). The first Unix implementation was by
James Gosling. Later, Richard Stallman rewrote it from scratch as
GNU Emacs, and much improved it in the process (including embedding
ELisp in it), when Gosling reneged on a promise to make his version
free. Other ITS refugees are info and dired (now invariably part
of Emacs).
> - Windows (a platform where Emacs has a fraction of popularity).
But it's still available, and very simple to install on Windows.
There are, of course, other operating systems, and other EMACSen,
such as Open Genera which hosts ZMACS.
> And I think there are quite a lof of hobbyist lispers, who found the
> language family while tweaking Emacs. Just look at the number of
> packages bundled with emacsen, plus the huge array of those that
> aren't bundled.
Yes, EMACS is one road to Lisp. Paging Kenny Tilton!
> How many of other, more popular editors actually support some sort of
> a scripting language?
TECO, once popular, was a complete programming language. As mentioned
above, the original EMACS was written in it.
> How many and how large such extensions have been written for those
> editors?
>
> How many people even think of _programming_ their text editor
> _program_?
>
> Looking from there, why the heck does some weird Lisp-based text
> editor engine from the 80's
1970s.
> have hundreds of full-blown applications
> written on top of it, then? Still in 2005? I, too, bet that the reason
> is that it has been easier to write those programs in Emacs than in
> other, contemporary, programming environments. And because Lisp is
> just plain fun, IMHO.
> br,
> S
--
:ugah179 (home page: http://web.onetel.com/~hibou/)
"Your head doesn't damage walls. Java damages walls."
-- Nathan Myers
Donald Fisk <············@onetel.com> wrote:
+---------------
| > How many of other, more popular editors actually support some sort
| > of a scripting language?
|
| TECO, once popular, was a complete programming language. As mentioned
| above, the original EMACS was written in it.
+---------------
Circa 1971, I wrote a form-letter generation program[1] in TECO, that was
simple enough to use that the company secretary had no trouble with it.
The key thing about TECO was that it had "EVAL", in essence, since
you could "execute" the contents of a save buffer ["Q Register" in
TECO terms, same as "vi" today]. And the "APPLY" function could in
effect be performed with the built-in editing functions [by editing
the actual args into a copy of some code you wanted to run], so there
you have it: EVAL & APPLY, what more do you want? ;-} ;-}
-Rob
[1] You know, one of those things that takes a file with a form letter
in it and a second file with addresses [e.g., a customer contact list]
to be filled in to the form letter. Yes, in retrospect I admit it,
now we'd probably call it a spam generator (*blush*), albeit with
hard-copy paper output. ;-}
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Donald Fisk <············@onetel.com> writes:
>> - Unixen (Emacs' native platform), and
>
> If only it were. Many's the time I've had to suffer the indignity
> of having to use vi (which I consider inferior to Microsoft Notepad)
> on a Unix system because Emacs was unavailable.
You could use ee or nano, which both are very annoying editors when
you are used to vi or emacs, but they are quite popular nonetheless.
>> - Windows (a platform where Emacs has a fraction of popularity).
>
> But it's still available, and very simple to install on Windows.
Yes, but e.g. XEmacs is sometimes painful to use on Windoze. Firstly
you have to install Cygwin to get some packages working and even with
Cygwin you will be annoyed by "xargs: program not found" and other
entertaining messages...
>> other, contemporary, programming environments. And because Lisp is
>> just plain fun, IMHO.
Elisp is most of the times, but the often-wished Common Lisp Emacs
would be way more fun.
Regards,
--
____________________________
Julian Stecklina / _________________________/
________________/ /
\_________________/ LISP - truly beautiful
Julian Stecklina <··········@web.de> writes:
> Donald Fisk <············@onetel.com> writes:
>
> >> - Unixen (Emacs' native platform), and
> >
> > If only it were. Many's the time I've had to suffer the indignity
> > of having to use vi (which I consider inferior to Microsoft Notepad)
> > on a Unix system because Emacs was unavailable.
>
> You could use ee or nano, which both are very annoying editors when
> you are used to vi or emacs, but they are quite popular nonetheless.
>
> >> - Windows (a platform where Emacs has a fraction of popularity).
> >
> > But it's still available, and very simple to install on Windows.
>
> Yes, but e.g. XEmacs is sometimes painful to use on Windoze. Firstly
> you have to install Cygwin to get some packages working and even with
> Cygwin you will be annoyed by "xargs: program not found" and other
> entertaining messages...
You do not need to install Cygwin to use XEmacs; Cygwin is not
involved in any way XEmacs a very nice Windows program, and comes
with a nice download/installation tool. It's easier to install than
regular GNU Emacs, which is why I often recommend it to newbies.
It's a point-and-click and sit back and watch it type of install.
In article <··············@goldenaxe.localnet>,
Julian Stecklina <··········@web.de> wrote:
> Yes, but e.g. XEmacs is sometimes painful to use on Windoze. Firstly
> you have to install Cygwin to get some packages working and even with
> Cygwin you will be annoyed by "xargs: program not found" and other
> entertaining messages...
I ran XEmacs on my XP laptop for a long while without going through any
weird steps (i.e. installing Cygwin) other than using the XEmacs Windows
installer.
Granted...perhaps part of Cygwin were installed by the XEmacs installer
but the process really was a one or two button-click process.
Damo
Damond Walker <·······@comcast.net> writes:
> In article <··············@goldenaxe.localnet>,
> Julian Stecklina <··········@web.de> wrote:
>
>> Yes, but e.g. XEmacs is sometimes painful to use on Windoze. Firstly
>> you have to install Cygwin to get some packages working and even with
>> Cygwin you will be annoyed by "xargs: program not found" and other
>> entertaining messages...
>
> I ran XEmacs on my XP laptop for a long while without going through any
> weird steps (i.e. installing Cygwin) other than using the XEmacs Windows
> installer.
>
> Granted...perhaps part of Cygwin were installed by the XEmacs installer
> but the process really was a one or two button-click process.
No. XEmacs does not install any of Cygwin. This is why igrep and the
like do not work on windows without special tweaking.
Regards,
--
____________________________
Julian Stecklina / _________________________/
________________/ /
\_________________/ LISP - truly beautiful
Simo Melenius wrote:
> ·············@yahoo.com" <············@yahoo.com> writes:
>
>> Paul Graham asserts, "To become popular, a programming language has to
>> be the scripting language of a popular system." Any opinions on why the
>> widespread popularity of Emacs, and thus elisp, hasn't translated into
>> wider popularity for Lisp? They aren't the same, of course, but they
>> are close enough.
>
> Probably because Emacs isn't that popular in the big picture. I'm
> guessing the figures here, but suppose it had few million users in
> which case there were several hundreds of millions of non-Emacs users
> out there.
>
> But relatively, ELisp probably has made Lisp more popular. Compare the
> number of programs that internally use or embed a Lisp interpreter and
> are written for:
>
> - Unixen (Emacs' native platform), and
>
> - Windows (a platform where Emacs has a fraction of popularity).
>
> And I think there are quite a lof of hobbyist lispers, who found the
> language family while tweaking Emacs. Just look at the number of
> packages bundled with emacsen, plus the huge array of those that
> aren't bundled.
>
> How many of other, more popular editors actually support some sort of
> a scripting language?
>
> How many and how large such extensions have been written for those
> editors?
>
> How many people even think of _programming_ their text editor
> _program_?
>
> Looking from there, why the heck does some weird Lisp-based text
> editor engine from the 80's have hundreds of full-blown applications
> written on top of it, then? Still in 2005? I, too, bet that the reason
> is that it has been easier to write those programs in Emacs than in
> other, contemporary, programming environments. And because Lisp is
> just plain fun, IMHO.
>
>> I'd wager that the lack of a small Lisp environment for writing quick &
>> dirty utilities *might* be a reason. Anyone got a more convincing
>> hypothesis?
>
> Depends on the Q&D utilities in question since they're domain
> specific. The most popular domains are very simple, like the domain of
> text stream processing, interacting with other programs+processes, and
> managing files -- courtesy of traditional Unix shell & related
> utilities. You can get away a long way with sh, awk and recently,
> perl, so there has been no urgent need to roll-out Lisp instead.
>
>
> br,
> S
I'm kind of curious. How many people use Hemlock in CMUCL? It has a users
and command implementor's manual from 1992. It's still a part of CMUCL so
I'm assuming it is still used by somebody. Could any Hemlock users comment
on it's advantages?
Thanks,
--Bruce
·············@yahoo.com" <············@yahoo.com> writes:
> I'd wager that the lack of a small Lisp environment for writing quick &
> dirty utilities *might* be a reason. Anyone got a more convincing
> hypothesis?
scsh, the scheme shell, is a very nice thing to write utilities
in. Would be a nice candidate to port to ECL or GCL, though.
Regards,
--
____________________________
Julian Stecklina / _________________________/
________________/ /
\_________________/ LISP - truly beautiful
Julian Stecklina <··········@web.de> wrote:
+---------------
| ·············@yahoo.com" <············@yahoo.com> writes:
| > I'd wager that the lack of a small Lisp environment for writing quick &
| > dirty utilities *might* be a reason. ...
|
| scsh, the scheme shell, is a very nice thing to write utilities in.
| Would be a nice candidate to port to ECL or GCL, though.
+---------------
I agree, Scsh is nice, but... There's a problem with trying to
implement Scsh *exactly* in Common Lisp, namely, in Common Lisp
there is no standard list representation defined for the result
of a READ of the comma or comma-at syntax, nor does Common Lisp
permit comma or comma-at syntax which is not properly nested within
backquote syntax to be read in forms to be evaluated.
In Scheme, on the other hand, backquote, comma, and comma-at are
merely read macros much like quote and sharp-quote in Common Lisp.
That is, each of backquote, comma, and comma-at are *defined*
to produce a specific internal list representation for each,
which can reliably be manipulated by a user-defined tree walker.
To say it another way, in both CL and Scheme [using "==>" here to
mean "is READ as"]:
'a ==> (quote a)
and in CL [though not Scheme]:
#'a ==> (function a)
But in Scheme -- though *NOT* in CL! -- the following all have
similarly-definite READ representations defined:
`a ==> (quasiquote a)
,a ==> (unquote a)
,@a ==> (unquote-splicing a)
That is, the QUASIQUOTE, UNQUOTE, and UNQUOTE-SPLICING symbols are
all special operators when a quasiquoted form is evaluated, but more
importantly, they have defined READ representations as non-evaluated
*data* as well. This means that Scheme macros can contain argument
forms which contains comma or comma-at syntax which is *NOT* properly
nested within backquotes, and also that the macros [and any tree
walkers they contain] can depend on the structure of the READ results.
Why does this matter? Because much of the convenience of Scsh comes
from the fact that a large number of the most-commonly-used macros
in Scsh "implicitly backquote" their arguments. For example, this
is legal Scsh:
(let ((foo "filename"))
(run (ls -l ,foo))) ; Note no backquote before the comma!
That's simply not possible with most CL readers [and certainly not
portable CL in any case].
Yes, for each short macro form there is a longer functional form that
could be made to work in CL, but it's much less succinct. The above
example could be re-written as follows:
(let ((foo "filename"))
(wait (fork (lambda () (exec-path `(ls -l ,foo))))))
Still, it might be possible to come up with CL versions of the "run",
"fork", "pipe", etc. macros that *don't* try to implicitly backquote
their arguments, and which must be given explicitly backquoted args.
That is, the original example could work in CL if it looked liked this:
(let ((foo "filename"))
(cl-run `(ls -l ,foo)))
But this is still not adequate for portability, since different
CL implementation represent the results of reading `(ls -l ,foo)
differently. For example, [if you work *really* hard to peek under
the covers] you will find CLISP gives the following [very much
like the Scheme standard, actually]:
(SYSTEM::BACKQUOTE (LS -L (SYSTEM::UNQUOTE FOO)))
whereas CMUCL gives this:
(LISP::BACKQ-LIST (QUOTE LS) (QUOTE -L) FOO)
Both will give equivalent results when *evaluated* by their
corresponding evaluators, but the unevaluated forms are sufficiently
different to make it "interesting" to implement the full set of
Scsh macros [which need to walk the unevaluated backquoted forms
rewriting them into their equivalent functional forms]. And that's
just two versions of CL...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Julian Stecklina <··········@web.de> wrote:
> +---------------
> | ·············@yahoo.com" <············@yahoo.com> writes:
> | > I'd wager that the lack of a small Lisp environment for writing quick &
> | > dirty utilities *might* be a reason. ...
> |
> | scsh, the scheme shell, is a very nice thing to write utilities in.
> | Would be a nice candidate to port to ECL or GCL, though.
> +---------------
>
> I agree, Scsh is nice, but... There's a problem with trying to
> implement Scsh *exactly* in Common Lisp, namely, in Common Lisp
> there is no standard list representation defined for the result
> of a READ of the comma or comma-at syntax, nor does Common Lisp
> permit comma or comma-at syntax which is not properly nested within
> backquote syntax to be read in forms to be evaluated.
[Schnipp explanation]
> Why does this matter? Because much of the convenience of Scsh comes
> from the fact that a large number of the most-commonly-used macros
> in Scsh "implicitly backquote" their arguments. For example, this
> is legal Scsh:
>
> (let ((foo "filename"))
> (run (ls -l ,foo))) ; Note no backquote before the comma!
>
> That's simply not possible with most CL readers [and certainly not
> portable CL in any case].
>
> Yes, for each short macro form there is a longer functional form that
> could be made to work in CL, but it's much less succinct. The above
> example could be re-written as follows:
>
> (let ((foo "filename"))
> (wait (fork (lambda () (exec-path `(ls -l ,foo))))))
>
> Still, it might be possible to come up with CL versions of the "run",
> "fork", "pipe", etc. macros that *don't* try to implicitly backquote
> their arguments, and which must be given explicitly backquoted args.
> That is, the original example could work in CL if it looked liked this:
>
> (let ((foo "filename"))
> (cl-run `(ls -l ,foo)))
[...]
Ok, as you have successfully pointed out, there is no way to do a
one-to-one port from scsh to CL. But I regard some features of scsh
superfluous. So (run (mplayer -q ,arg ,@file)) in scsh might not be
portable to CL, because of implicit backquoting and
case-sensitivity. My solution would be (run ("mplayer" "-q" arg
. file)). It's debatable whether the dot-thing is a nice idea... But
at least it is clearly recognisable from the macro's point of view
what is a variable and what is to be copied verbatim.
Opinions?
Regards,
--
____________________________
Julian Stecklina / _________________________/
________________/ /
\_________________/ LISP - truly beautiful
Julian Stecklina <··········@web.de> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > Still, it might be possible to come up with CL versions of the "run",
| > "fork", "pipe", etc. macros that *don't* try to implicitly backquote
| > their arguments, and which must be given explicitly backquoted args.
| > That is, the original example could work in CL if it looked liked this:
| >
| > (let ((foo "filename"))
| > (cl-run `(ls -l ,foo)))
| [...]
|
| Ok, as you have successfully pointed out, there is no way to do a
| one-to-one port from scsh to CL. But I regard some features of scsh
| superfluous. So (run (mplayer -q ,arg ,@file)) in scsh might not be
| portable to CL, because of implicit backquoting and
| case-sensitivity. My solution would be (run ("mplayer" "-q" arg
| . file)). It's debatable whether the dot-thing is a nice idea... But
| at least it is clearly recognisable from the macro's point of view
| what is a variable and what is to be copied verbatim.
|
| Opinions?
+---------------
I actually like using the original syntax, but manually adding an
explicit backquote where needed, e.g. (run `(mplayer -q ,arg ,@file)).
It keeps the code looking very close to the original Scsh style
[though not close enough for painless portability, obviously],
and would let you just point people at the Scsh documentation
with an addendum that said, "Oh, yeah, since this is CL you have
to manually add an explicit backquote before the arguments of
the following macros: RUN, EXEC-EPF, ..."
Looking at "cheat.txt" [quick ref] in the distribution, it basically
looks like you need a backquote in front of any EPF ("extended process
form", in Scsh terms). [Is it just that simple?!?]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607