I've been proficient at Perl and Python in the past and I'm learning
lisp. On my quest for programming enlightenment I wanted to learn the
CL way to manage packages only to find that there is no standard way!?
provide/require discussion circa 2003:
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/c6169cc8a7fd2f35/1ae65b1e44209f41?q=provide+require+deprecated&rnum=1#1ae65b1e44209f41
I think the fact that Perl and Python are standardized via the dictats
of their respective benevolent dictators is one of the major advantages
these language have over the lisp community. Perl and Python have well
developed package management systems because nobody has to haggle for
years on end in a committee to get the job done. Several solutions are
put forth, benevolent dictator chooses the best, the community moves
on. If said benevolent dictator makes too many bad decisions he is
deposes and either (a) another person assumes the mantle or, more
likely, (b) the community spliters and diminishes.
I'm sure the lisp community has the technical know how to provide a
powerful and robust package management system but we apparently lack a
charismatic benevolent dictator to make such a system the de facto
standard.
For a little while I thought Paul Graham might become the charismatic
benevolent dictator of Arc but apparently his writings on Arc are more
along the lines of "wouldn't it be cool to make a better lisp dialect,
oh, what is that over there ...". (No slight intended to P.G. -- he
simply is not driven by an all consuming passion to make Arc successful
reality).
I will certainly continue my lisp education and learn to appreciate the
things that lisp DOES do better than Python but I suspect I will
continue to lament lisp's lack of a charismatic benevolent dictator.
In the mean time I guess I will use the "implementation dependent"
behavior of 'provide' and 'require' and make use these in my code until
I out grow them.
--jfc
funkyj wrote:
> I've been proficient at Perl and Python in the past and I'm learning
> lisp. On my quest for programming enlightenment I wanted to learn the
> CL way to manage packages only to find that there is no standard way!?
>
> provide/require discussion circa 2003:
>
> http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/c6169cc8a7fd2f35/1ae65b1e44209f41?q=provide+require+deprecated&rnum=1#1ae65b1e44209f41
ASDF is a non-standard, but widely used way to declare dependencies.
<http://www.cliki.net/asdf>
-- MJF
MJF> ASDF is a non-standard, but widely used way to declare
dependencies.
Cool, I'll take a look at it!
--jfc
From: Ulrich Hobelmann
Subject: Re: MUSING: standard bodies vs benevolent dictators, popularity
Date:
Message-ID: <40n5vpF1b3rciU1@individual.net>
funkyj wrote:
> I think the fact that Perl and Python are standardized via the dictats
> of their respective benevolent dictators is one of the major advantages
> these language have over the lisp community.
That depends on your POV. As long as centralization is ok, and as long
as the direction is where you want to go, a dictatorship can be
efficient. But as soon as the direction is different from your own,
you're screwed (notice the howling and teeth-clicking when Python
removed lambda instead of making it fully powerful).
Lisp is much more bazaar than cathedral; in fact CL itself emerged from
a merging of bazaar-style languages. The world split again, into
different CLs and several Schemes, but that doesn't prevent groups from
standardizing features into several CL implementations, or users from
choosing the implementation(s) that they want.
--
If you have to ask what jazz is, you'll never know.
Louis Armstrong
From: Karl A. Krueger
Subject: Re: MUSING: standard bodies vs benevolent dictators, popularity
Date:
Message-ID: <doavsb$on$1@baldur.whoi.edu>
Ulrich Hobelmann <···········@web.de> wrote:
> funkyj wrote:
>> I think the fact that Perl and Python are standardized via the dictats
>> of their respective benevolent dictators is one of the major advantages
>> these language have over the lisp community.
>
> That depends on your POV. As long as centralization is ok, and as long
> as the direction is where you want to go, a dictatorship can be
> efficient. But as soon as the direction is different from your own,
> you're screwed (notice the howling and teeth-clicking when Python
> removed lambda instead of making it fully powerful).
Python hasn't removed ... *yawn* Never mind.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
In article <·······················@o13g2000cwo.googlegroups.com>,
"funkyj" <······@gmail.com> wrote:
> I've been proficient at Perl and Python in the past and I'm learning
> lisp. On my quest for programming enlightenment I wanted to learn the
> CL way to manage packages only to find that there is no standard way!?
>
> provide/require discussion circa 2003:
>
> http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/c6169cc8a7fd2f35/1ae65b1e44209f41?q=provide+require+deprecated&rnum=1#1ae65b1e44209f41
>
>
>
> I think the fact that Perl and Python are standardized via the dictats
> of their respective benevolent dictators is one of the major advantages
> these language have over the lisp community. Perl and Python have well
> developed package management systems because nobody has to haggle for
> years on end in a committee to get the job done. Several solutions are
> put forth, benevolent dictator chooses the best, the community moves
> on. If said benevolent dictator makes too many bad decisions he is
> deposes and either (a) another person assumes the mantle or, more
> likely, (b) the community spliters and diminishes.
If you believe Perl, Python and 'lisp' are somewhat similar, you are
probably on the wrong track.
Lisp (!) is a family of languages and implementations. Common Lisp
is a family of languages and implementations, too. Currently
ANSI Common Lisp is the top of the heap with ten or more different
implementations (each with lots of incompatible extensions).
Now pick your implementation of choice and choose a dictator.
Or stay with Perl and Python, which are already pretty good for what
they are used for. These only work anyway if you look at them
as single implementation languages. As soon as there are
two different implementations, things are starting to fall apart.
The same is true if you have two or more different versions
of the same implementation (Perl 4, 5, 6).
> I'm sure the lisp community
There is no thing as 'the lisp community'. Lisp is VERY diverse
and widely different Lisp languages and implementations serve
very different purposes. You might look for the 'free Common Lisp
on Unix systems' community - that might even exist. But
even there you can choose between CLISP, ECL, GCL, SBCL, CMUCL,
OpenMCL, ... (did I forget anyone?)
If you want to stay with a simpler situation and scripting tools,
Perl and Python are always there.
> has the technical know how to provide a
> powerful and robust package management system but we apparently lack a
> charismatic benevolent dictator to make such a system the de facto
> standard.
>
> For a little while I thought Paul Graham might become the charismatic
> benevolent dictator of Arc but apparently his writings on Arc are more
> along the lines of "wouldn't it be cool to make a better lisp dialect,
> oh, what is that over there ...". (No slight intended to P.G. -- he
> simply is not driven by an all consuming passion to make Arc successful
> reality).
>
> I will certainly continue my lisp education and learn to appreciate the
> things that lisp DOES do better than Python but I suspect I will
> continue to lament lisp's lack of a charismatic benevolent dictator.
Fine. I'm glad there isn't one. The whole 'benevolent dictator' is
just childish.
> In the mean time I guess I will use the "implementation dependent"
> behavior of 'provide' and 'require' and make use these in my code until
> I out grow them.
>
> --jfc
From: Robert Uhl
Subject: Re: MUSING: standard bodies vs benevolent dictators, popularity
Date:
Message-ID: <m3fyoozubu.fsf@4dv.net>
Rainer Joswig <······@lisp.de> writes:
>
> Now pick your implementation of choice and choose a dictator.
Problem with that is wasted effort, both on the part of implementors and
users of their implementations. On the one hand folks keep re-inventing
sockets interfaces; on the other users have to keep writing
compatibility layers.
The real question is if the advantages and disadvantages of many
implementations outweigh the advantages and disadvantages of a single
implementation. I'm really not certain, although I do notice that of
the current 'hot' languages, only Common Lisp is lacking a single,
canonical, free implementation. Java, PHP, Ruby, Python & Perl all have
benevolent dictators (to my knowledge--perhaps I err), and seem to be
doing pretty well.
Of course when the benevolent dictator loses his mind or turns
malevolent, then that's no fun at all.
--
Robert Uhl <http://public.xdi.org/=ruhl>
As convenient as it is for information to come to us, libraries do have a
valuable side effect: they force all of the smart people to come together
in one place where they can interact with one another.
--Neal Stephenson
In article <··············@4dv.net>,
Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Rainer Joswig <······@lisp.de> writes:
> >
> > Now pick your implementation of choice and choose a dictator.
>
> Problem with that is wasted effort, both on the part of implementors and
> users of their implementations. On the one hand folks keep re-inventing
> sockets interfaces;
Socket interfaces don't need to be reinvented. They have been
long done in Common Lisp. It is also not unusual for some
implementations to share code.
> on the other users have to keep writing
> compatibility layers.
Only if you don't use what is already there. I am for example
using the CLIM-SYS 'standard' which is available for 15 years
(maybe longer).
http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/P-VIII.html
>
> The real question is if the advantages and disadvantages of many
> implementations outweigh the advantages and disadvantages of a single
> implementation. I'm really not certain, although I do notice that of
> the current 'hot' languages, only Common Lisp is lacking a single,
> canonical, free implementation.
Only Common Lisp has competition and choice. Within one
language you can choose different implementations for
different purposes.
If Perl is so good, why is there Python? If Python is so good
why is there Ruby? JavaScript? And lots of these other
languages I even can't remember...
Instead of a single langauge with different implementations,
where some scale to extremely large problems, you
now have a multititude of languages which are all
providing some similar features but different. Most
of them are of little to medium performance. Most
of them don't scale in several areas.
In Common Lisp I can write demanding applications with
some of the implementations and I can do scripting with,
say, CLISP. I can easily reuse my CL knowledge.
But when Perl is not good, I use Python? Ruby? JavaScript?
Java? No reuse. Overlapping features. Incompatible languages.
That should be the new world?
Instead of one 'dictator' I now have a multitude of
dictators each in their own little country with their
own people. Which 'dictator' do I choose? Should
I use PERL? Not a general purpose language. Isn't
there some PERL stuff being written in Haskell? So I should
better use Haskell? Or not? Python? Slow and the dictator wants
to remove features I like. Ruby? Why Ruby? 50% of what I have
in Lisp? And 10% of what I have on top of Lisp.
JavaScript? I'm puzzled.
> Java, PHP, Ruby, Python & Perl all have
> benevolent dictators (to my knowledge--perhaps I err), and seem to be
> doing pretty well.
Lisp is doing well, thank you.
Btw., how is Java free? I thought it was owned by Sun?
Is Sun's implementation 'free'?
PHP is a scripting language for web pages.
Ruby is a scripting language. Python is a scripting
language. Perl is a scripting language.
Common Lisp is not a scripting language. It is a general
purpose programming language with general purpose
implementations. It can be used for scripting.
> Of course when the benevolent dictator loses his mind or turns
> malevolent, then that's no fun at all.
I think the whole 'benevolent dictator' talk is just silly.
From: Robert Uhl
Subject: Re: MUSING: standard bodies vs benevolent dictators, popularity
Date:
Message-ID: <m3psnr7koc.fsf@4dv.net>
Rainer Joswig <······@lisp.de> writes:
>
>> > Now pick your implementation of choice and choose a dictator.
>>
>> Problem with that is wasted effort, both on the part of implementors
>> and users of their implementations. On the one hand folks keep
>> re-inventing sockets interfaces;
>
> Socket interfaces don't need to be reinvented. They have been long
> done in Common Lisp. It is also not unusual for some implementations
> to share code.
And yet when I write sockets-using code I either have to write for a
single implementation, write a wrapper over a few implementations, or
use a wrapper written by another which covers a few more
implementations...
--
Robert Uhl <http://public.xdi.org/=ruhl>
You didn't want software written by a calm, happy, non-paranoid
individual to be answering port 25 anyway. --Anthony de Boer
From: Karl A. Krueger
Subject: Re: MUSING: standard bodies vs benevolent dictators, popularity
Date:
Message-ID: <dob0qf$1rj$1@baldur.whoi.edu>
Robert Uhl <·········@nospamgmail.com> wrote:
> The real question is if the advantages and disadvantages of many
> implementations outweigh the advantages and disadvantages of a single
> implementation. I'm really not certain, although I do notice that of
> the current 'hot' languages, only Common Lisp is lacking a single,
> canonical, free implementation. Java, PHP, Ruby, Python & Perl all have
> benevolent dictators (to my knowledge--perhaps I err), and seem to be
> doing pretty well.
Java has a very strict standard, but at least two major implementations:
Sun's and IBM's. Microsoft had one, but IIRC dropped it when the courts
told them they weren't allowed to use the Java trademark in violation of
the license. GNU is working on one, but it isn't particularly complete.
(I can run CGoban in IBM's Java, but not in GNU's.)
Other major languages today include C and C++ -- currently the #2 and #3
on the much-vaunted Tiobe chart, after Java's #1. Neither one has a
single canonical implementation. So none of the top three languages
today are single-implementation languages.
JavaScript is another "hot" language (being the basis of AJAX) that has
no single implementation. Again, there's a strong standard, but there
seem to be at least *four* commercially significant implementations:
Microsoft's, Mozilla's, KDE and Apple's, and Opera's.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
There are several ways to manage your "local" packages.
If you use MK:DEFSYSTEM or ASDF, all you need is to set up a directory
where you keep you packages (i.e. their directories) and work with the
facilities of your system definition library to access them.
For MK:DEFSYSTEM (http://clocc.sf.net and
http://sourceforge.net/project/showfiles.php?group_id=1802&package_id=7139&release_id=323402)
you just add in you init file something like
(mk:add-registry-location "/my/path/to/my/cl/packages/")
and you are in business. If your package sits in a directory
/my/path/to/my/cl/packages/my-package/
and it has a file named
/my/path/to/my/cl/packages/my-package/my-package.system
then at the CL prompt you can do
cl-prompt> (mk:load-system "my-package")
and everything will work as expected. Of course you can have more
complicated arrangements.
Cheers
--
Marco
funkyj wrote:
> I think the fact that Perl and Python are standardized via the dictats
> of their respective benevolent dictators is one of the major advantages
> these language have over the lisp community.
Yep. Also that they are interpreters written in C, so it is possible to
have a portable single implementation -- no need for a standard!
OTOH, CL /does/ have a standard and implementations stay close enough to
it that porting is not too painful, until you get to certain niches such
as FFI that really would be nice to have portable. But then there is
UFFI and CFFI which try to fill that gap.
You are defining the solution in terms of the things you know. That is
an understandable mistake. How could CL, formed by an ANSI committee,
now suddenly get a BDFL?
Better to whine here about something specific (as you did with packages)
and either learn how we handle them or end up joining an open source
effort to fill the gap.
> If said benevolent dictator makes too many bad decisions he is
> deposes and either (a) another person assumes the mantle or, more
> likely, (b) the community spliters and diminishes.
The problem here is that there is a pretty high threhold on "too many".
Each language you mention gets to where it is by being insanely great in
some way. The BDFL can throw in all sorts of bad decisions before losing
their audience. And they can also simply omit really good stuff that
people do not know they are missing and no one learns a thing: macros,
multi-methods, even the parentheses.
I am curious to see how your Road to Lisp plays out. keep us posted on
further such musings.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
K> How could CL, formed by an ANSI committee,
K> now suddenly get a BDFL?
Well, one implementation (e.g. CLISP, SBCL or CMUCL) could have a BDFL
and this implementation could become wildly popular.
K> Better to whine here about something specific (as you did with
K> packages)
point taken.
K> I am curious to see how your Road to Lisp plays out. keep us posted
K> on further such musings.
Will do. During the day I work as a C programmer at a networking
company. I don't see much opportunity to use Lisp professionally in
the near future. Teaching myself Lisp in my not spare time is slow
going but fun.
===
back in the 90s I started with bourne shell for scripting because it
was the de facto standard used by folks around me. Looking for
something better I gave TCL a try. Sure, TCL had real functions but I
hated the syntax so, looking for something better I decided to give
that wildly popular language Perl a try.
Perl was a breath of fresh air compared to TCL and sh. I should have
hated Perl on aethetic grounds (the language is much bigger than it
needs to be) but it made scripting fun again. Being somewhat
dissatisfied with Perl's object model, which is sort of an afterthought
with no sophisticated exception handling mechanism, I decided to give
Python a try. I find Python aesthetically pleasing and it has large
and powerful enough libraries for it to displace Perl as my scripting
language of choice.
Python is not just a scripting language though, it is a pleasant high
level language to work in (e.g. it seems to have won over Bruce Eckel).
Unfortunately one must fall back to C/C++ for performance sensitive
work.
While it would make me happy if Lisp had the libraries and cross
platform portability that would allow it to displace Python as my
scripting language of choice (this would give me more opportunity to
use it at work and thereby learn it more quickly), I am learning Lisp
for the same reason I gave Python a try: I ENJOY programming when the
underlying language is powerful.
Several things eventually led me back to Lisp. Using emacs keeps me in
superficial contact with emacs-lisp. I noticed similarities between
Python, which I quite like, and Lisp. It seems that, among the
hackers of great renown, every one of them who claims to have mastered
Lisp says it is the bee's knees.
I have only scratched the surface of lisp so far but this time around I
am noticing the elegance of the functional approach to programming.
Still, I'm at the point where I have to take the claims of the 'miracle
powers of lisp macros' on faith.
Regards,
-jfc
funkyj <······@gmail.com> wrote:
+---------------
| During the day I work as a C programmer at a networking company.
| I don't see much opportunity to use Lisp professionally in the
| near future.
+---------------
I worked for a number of years at a [then-]large computer systems
company doing networking stuff, and now work at a storage appliance
startup. Here are just a few of the things for which I've used Common
Lisp [and Scheme before it] at work, despite the fact that Lisp is
not an official part of my job:
- Code-generating scripts for reducing the labor of creating
and maintaining large, messy C programs and/or Verilog designs.
[Also see Kenny Tilton's & others' past articles about using
CL to generate C++ & Java source code.]
- Data-generating scripts for creating input data and expected output
for hardware simulation test suites.
- Programs to grind through console terminal logs and/or kernel log
files ("syslog") looking for "unusual" patterns, when chasing obscure
or very intermittent bugs. [I also use such a script at home to look
for penetration attempts on my servers.]
- Whipping up a quick web-based multi-question "survey" form and
backend data reduction program when a former boss needed data
"right now!" from all of Engineering (several hundred people)
about their remote-access usage patterns [during one of those
typical tugs-of-war between Engineering & I/S!].
- A user-mode interactive program for doing hardware debugging
which supports mmap'ing the hardware and then lets you do peeks
and pokes to device registers, perform DMA, etc.
This one I've done multiple times at multiple jobs: in Tcl, SCM,
MzScheme, and most recently CMUCL. For the MzScheme one I even
wrote an infix parser as a layer of syntactic sugar on top of
the usual Lisp REPL, so that the other hardware guys who used
the tool didn't get freaked out by "all those parentheses".
[Google for articles by me that mention "P'Lite Scheme".]
But for the CMUCL one I'm doing something much simpler [that came
from an earlier time], and even *thinner* layer of syntactic sugar
on top of the REPL that I call OPFR (Outer Parenthesis-Free REPL),
which is just a slightly-extended READ-LINE which READs the "words" of
a (possibly-continued) line, stuffs them into a list, and calls EVAL.
[Oh, and also implements a "0x" readmacro, for the C/Tcl/Perl crowd.]
As long as people are mostly calling pre-defined functions with
numeric or pre-defined arguments, they don't know or care that it's
really Common Lisp underneath, e.g.:
hwtool> dump32 sdram 0x80
0x00: 0xE59FF018 0xE59FF018 0x00000000 0xE59FF018
0x10: 0xE59FF018 0x00000000 0xE59FF018 0xE59FF018
0x20: 0x00000000 0x00000000 0x00000000 0x00020328
0x30: 0x00020344 0x00000000 0x00020444 0x0002040C
0x40: 0x600DDA7A 0x11FEBEEF 0x87654321 0xFFAA5500
0x50: 0x00000000 0x00000000 0xFFFFFFFF 0xFFFFFFFF
0x60: 0x00000000 0x00000000 0x00000000 0x00000000
0x70: 0x00000000 0x00000000 0x00000000 0x00000000
hwtool> dcache-off
:OK
hwtool> icache-off
:OK
hwtool> r32 (+ sdram 0x3c)
132108
hwtool> hex *
"0x2040c"
hwtool> w32 (+ sdram 0x60) 0x1234 0x5678 0x9abc 0xdef0
hwtool> dump32 sdram 0x80
0x00: 0xE59FF018 0xE59FF018 0x00000000 0xE59FF018
0x10: 0xE59FF018 0x00000000 0xE59FF018 0xE59FF018
0x20: 0x00000000 0x00000000 0x00000000 0x00020328
0x30: 0x00020344 0x00000000 0x00020444 0x0002040C
0x40: 0x600DDA7A 0x11FEBEEF 0x87654321 0xFFAA5500
0x50: 0x00000000 0x00000000 0xFFFFFFFF 0xFFFFFFFF
0x60: 0x00001234 0x00005678 0x00009ABC 0x0000DEF0 <== Note changes
0x70: 0x00000000 0x00000000 0x00000000 0x00000000
hwtool> expt 2 200
1606938044258990275541962092341162602522202993782792835301376
hwtool> loop for i from 0 below 16 collect (expt 2 i)
(1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768)
hwtool> lisp-implementation-type
"CMU Common Lisp"
hwtool> lisp-implementation-version
"19a"
hwtool>
- A little script to go grab the company's stock price off various
web sites and filter out all the HTML and just show the numeric
value of "Last trade". ;-}
The point is that we all have "non-production" or "auxiliary" work
that we do along the way when doing our "real" jobs, and there's
(usually) nothing stopping you from using Common Lisp for any of
that "other" stuff.
+---------------
| back in the 90s I started with bourne shell for scripting...
| Looking for something better I gave TCL a try... [then] decided
| to give that wildly popular language Perl a try ... [then] Python.
+---------------
My path was somewhat similar, except Perl before Tcl [and never made
it to Python], but the main reason for moving to Tcl was because the
"commandloop" command nicely supported interactive operation ["perlsh"
is not "nice", IMHO], the FFI to C code was very simple, and you could
load C-based DSOs at run-time. So the Tcl version of the "hwtool" script
could just do a dlopen() of the C code, and there was my "mmap", "peek",
"poke", etc.
But doing 'scope loops in Tcl was so *slooowwww* [I sometimes had to
turn the room lights off to see the trace], so I switched to Scheme,
and then later still, to a Common Lisp with a native code compiler.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
RW> The point is that we all have "non-production" or "auxiliary" work
RW> that we do along the way when doing our "real" jobs, and there's
RW> (usually) nothing stopping you from using Common Lisp for any of
RW> that "other" stuff.
Yes. It is a goal of mine to become proficient enough in lisp that I
can do these tasks better in lisp than I can currently do them in
python.
I despise tcl. It was an improvement over 'sh' but that is not saying
much. Oh how much happier I would have been if Don Libes had chosen
Perl/Python/Lisp/Scheme as the basis for expect rather than tcl.
Sadly, neither Perl nor Python come anywhere close to Expect for
driving tty based programs. Aside from the abominable tcl syntax
Expect does what it is suppose to do remarkably better than the
corresponding Perl and Python kludges. Sigh. Perhaps I will discover
that clisp (my chosen CL implementation) can be a decent replacement
for expect (although I won't hold my breath).
Thanks for all the great examples of using Lisp for auxilary work!
--jfc