In the context of LATEX, some Pythonista asked what the big
successes of Lisp were. I think there were at least three *big*
successes.
a. orbitz.com web site uses Lisp for algorithms, etc.
b. Yahoo store was originally written in Lisp.
c. Emacs
The issues with these will probably come up, so I might as well
mention them myself (which will also make this a more balanced
post)
a. AFAIK Orbitz frequently has to be shut down for maintenance
(read "full garbage collection" - I'm just guessing: with
generational garbage collection, you still have to do full
garbage collection once in a while, and on a system like that
it can take a while)
b. AFAIK, Yahoo Store was eventually rewritten in a non-Lisp.
Why? I'd tell you, but then I'd have to kill you :)
c. Emacs has a reputation for being slow and bloated. But then
it's not written in Common Lisp.
Are ViaWeb and Orbitz bigger successes than LATEX? Do they
have more users? It depends. Does viewing a PDF file made
with LATEX make you a user of LATEX? Does visiting Yahoo
store make you a user of ViaWeb?
For the sake of being balanced: there were also some *big*
failures, such as Lisp Machines. They failed because
they could not compete with UNIX (SUN, SGI) in a time when
performance, multi-userism and uptime were of prime importance.
(Older LispM's just leaked memory until they were shut down,
newer versions overcame that problem but others remained)
Another big failure that is often _attributed_ to Lisp is AI,
of course. But I don't think one should blame a language
for AI not happening. Marvin Mins ky, for example,
blames Robotics and Neural Networks for that.
Jul 18 '05
303  17396 
Terry Reedy wrote: Lisp-aware editors do not solve the problem of reading Lisp code
embedded in text, as with OnLisp formatted .ps or .pdf.
I agree. A big wadge of Lisp is not readable like NL text. And having
seen Graham's MOSTN posted here, wow, that is really verbose lisp. With
any Lisp, the indentation increment is just a few characters. I think
one can extend that in many editors, but then the structured nature of
functional code has one sailing off the right margin before too long.
As for reading code, I do not do that in books much, and when I do they
are pretty short examples. When they get bigger, right, I slow down and
destructure mentally. For example, in MOSTN I saw the earliest few lines
were just handling the edge case of a null input list. I moved a couple
of levels into the tree and forgot that outer check (which was
unnecessary!).
I was recommending Chapter's 1 & 8 for well-written thoughts on the
macro issue.
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Terry Reedy wrote:
...
Lisp-aware editors do not solve the problem of reading Lisp code
embedded in text, as with OnLisp formatted .ps or .pdf.
well, to the extent that they indent consistently, they do. one trains ones
eye to ignore the parentheses. perhaps one may have misinterpretated the
resistance to tyrannical indentation. one very effective way to read lisp
attends to the indentation and ignores the parentheses. the compiler does not
do this, but the eye does. different eyes are trained differently, but the
principle remains.
for instance, if we take m.kowalczyk's example. a competent lisp programmer
could just as readily interpret the text below, as interpret the text with
parentheses. the parenthese are redundant information which aids
disambiguation - eg where numerous forms are on a single line, and corrects
errors, but fairly early on one no longer "reads" them.
defun mostn fn lst
if null lst
values nil nil
let result list car lst
max funcall fn car lst
dolist obj cdr lst
let score funcall fn obj
cond > score max
setq max score
result list obj
= score max
push obj result
values nreverse result max
practice. one suggestion would be to find an old mac and download a copy of
mcl. if you can get along with a mac, it really is the easiest of the lisps to
break in with.
....
On Sun, 19 Oct 2003 12:12:37 -0400, "Terry Reedy" <tj*****@udel.edu> wrote: Last night I accepted the repeated suggestion to download and read
(some of) OnLisp. Problem: I *don't* know the arglist structure of
every form Graham uses, and since Graham assumes such knowledge, I
had to count parens to reverse engineer function prototypes and
determine what is an argument to what. A Python beginner would more
easily do this with Python code.
Well, "On Lisp" is not a book for beginners. It's a book about the
power of CL macros and was written for people who alread know Common
Lisp.
What is ILISP.
<http://www.cliki.net/ILISP>
<http://sourceforge.net/projects/ilisp/>
Is there a usable online CL reference that would let me lookup, for
instance, DO and get the prototype and short description?
Yes, definitely. Common Lisp has an ANSI standard and the ANSI
standard is available online.[1]
<http://www.lispworks.com/reference/HyperSpec/Front/index.htm>
Be warned that this is a language standard, though. It's not a
textbook written for people who want to learn the language.
Tools like ILISP will allow you do put your cursor on a symbol and
open the corresponding page of the HyperSpec with one keystroke. Or
try something like <http://weitz.de/clhs.html>.
Lisp-aware editors do not solve the problem of reading Lisp code
embedded in text, as with OnLisp formatted .ps or .pdf.
Yes, but experience does.
Edi.
[1] Well, technically this is not the ANSI standard (you have to pay
money to ANSI to get it - it's a printed document) but for all
practical purposes it is.
Luke Gorrie wrote: C'mon guys, live a little,
(defun mostn (fn list)
(let ((max (apply #'max (mapcar fn list))))
(values (remove max list :test-not #'= :key fn) max)))
Yes, live a little, get messy. Why is there this insistence that
everything be neat and tidy? (in your dreams) In reality it never is,
that's the beauty of it.
(defun mostn (fn lst)
(let ((mostn-elems nil) (max nil))
(tagbody
find-mostn
(unless (null lst)
(let ((score (funcall fn (car lst))))
(cond
((or (null max) (> score max))
(setf max score mostn-elems (list (car lst))))
((= score max)
(push (car lst) mostn-elems)))
(setf lst (cdr lst))
(go find-mostn))))
(values (nreverse mostn-elems) max)))
Wade
Wade Humeniuk <wh******@nospamtelus.net> writes: (defun mostn (fn lst)
(let ((mostn-elems nil) (max nil))
(tagbody
find-mostn
(unless (null lst)
(let ((score (funcall fn (car lst))))
(cond
((or (null max) (> score max))
(setf max score mostn-elems (list (car lst))))
((= score max)
(push (car lst) mostn-elems)))
(setf lst (cdr lst))
(go find-mostn))))
(values (nreverse mostn-elems) max)))
This is untested but looks simpler than the lisp example:
def mostn (fn, lst):
max = None
for a in lst:
score = fn(lst)
if max is None or score > max:
max = score
ret = [a]
elif score == max:
ret.append(a)
return ret
Paul Rubin wrote:
This is untested but looks simpler than the lisp example:
def mostn (fn, lst):
max = None
for a in lst:
score = fn(lst)
if max is None or score > max:
max = score
ret = [a]
elif score == max:
ret.append(a)
return ret
That's the spirit, now
(defun mostn (fn lst &aux (mostn-elems nil) (max nil))
(tagbody
find-mostn
(unless (null lst)
((lambda (score)
(cond
((or (null max) (> score max))
(setf max score mostn-elems (list (car lst))))
((= score max)
(push (car lst) mostn-elems))))
(funcall fn (car lst)))
(setf lst (cdr lst))
(go find-mostn)))
(values (nreverse mostn-elems) max))
or
(defun mostn (fn lst &aux (mostn-elems nil) (max nil))
(map nil
(lambda (score elem)
(cond
((or (null max) (> score max))
(setf max score mostn-elems (list elem)))
((= score max)
(push elem mostn-elems))))
(mapcar fn lst)
lst)
(values (nreverse mostn-elems) max))
Wade
On 19 Oct 2003 18:40:20 +0200, I wrote: <http://www.cliki.net/ILISP>
<http://sourceforge.net/projects/ilisp/>
I should have mentioned that Bill Clementson gave a talk about using
Emacs as a Lisp IDE at ILC 2003 (alas, I wasn't there, but I saw a
draft of his paper) last week. It will be partly available from
<http://cl-cookbook.sf.net/emacs-ide.html>
in a couple of days.
Edi.
Terry Reedy wrote: Last night I accepted the repeated suggestion to download and read
(some of) OnLisp. Problem: I *don't* know the arglist structure of
every form Graham uses, and since Graham assumes such knowledge, I had
to count parens to reverse engineer function prototypes and determine
what is an argument to what. A Python beginner would more easily do
this with Python code.
Other people have already pointed you to some resources. I have also
liked the book "Common Lisp, The Language - 2nd edition" (CLtL2) by Guy
Steele a lot. It is a snapshot of the then ongoing ANSI standardization
from 1989. The HyperSpec is based on the final ANSI standard, as
published in 1995.
There are some minor differences between CLtL2 and the ANSI standard,
but they are neglectable, especially for a beginner. CLtL2 is generally
more accessible IMHO - better overall structure and more examples. It
feels a little bit like an advanced tutorial. When in doubt, refer to
the HyperSpec.
CLtL2 can be downloaded for free at
http://www-2.cs.cmu.edu/afs/cs.cmu.e...ltl/cltl2.html
I will admit that after a few chapters, the parens did begin to fade a
bit. They are a surface issue. I think some others are more
important.
Yes, exactly.
Lisp-aware editors do not solve the problem of reading Lisp code
embedded in text, as with OnLisp formatted .ps or .pdf.
That's right. A good exercise is to type in the code that you find in
the books by yourself. This should make you get a better feel for how to
read Lisp code.
Pascal
"Edi Weitz" <ed*@agharta.de> wrote in message
news:87************@bird.agharta.de... Is there a usable online CL reference that would let me lookup,
for instance, DO and get the prototype and short description?
Yes, definitely. Common Lisp has an ANSI standard and the ANSI
standard is available online.[1]
<http://www.lispworks.com/reference/HyperSpec/Front/index.htm>
Be warned that this is a language standard, though. It's not a
textbook written for people who want to learn the language.
Very helpful. I've read the first W&H Lisp on MacLisp, but CL has
lots of new name and syntax symbols, like &rest, :whatever, etc that I
can now look up as needed.
Thanks, Terry J. Reedy
On 18 Oct 2003 21:44:53 +0300, Ville Vainio
<vi********************@spamtut.fi> wrote: Lisp offers a bit more power than Python (macros), but after a while
with Python, one notices that none of the power that is missing is
actually even needed. Python has just the right
features. Period. There are one or two warts (dangling variable after
list comprehensions comes to mind), but the language as a whole feels
natural. Lisp feels natural if you are writing a compiler or want to
be as orthogonal as possible, Python feels natural for most (all
except drivers/applications with extreme performance requirements) of
the real world applications.
Depends. For a lot of things I agree with you, writing Python code is
very natural and straightforward. (I've decided my aesthetic dislike
of Python is such that I'd never be happy writing anything other than
throwaway scripts in it, but that's a different matter; aesthetics is
in the eye of the beholder.)
However, this really applies only when you're doing things the
language designer anticipated. The great thing I find about Lisp is
that when I'm doing something the language was _not_ designed to
handle, it's not an "oh shit" problem, it's a "well, I suppose I can
do this with a few macros" problem.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address. http://www.esatclear.ie/~rwallace
Paul Rubin wrote:
... This is untested but looks simpler than the lisp example:
def mostn (fn, lst):
max = None
for a in lst:
score = fn(lst)
Perhaps "score = fn(a)" ?
if max is None or score > max:
max = score
ret = [a]
elif score == max:
ret.append(a)
return ret
it it all right to raise an exception if lst is empty?
I'm not sure of the lisp example's behavior in that case,
but I suspect it returns an empty list and None. In
that case, we may need to initialize ret to [] too.
Stylistically (but it's just me) I don't much like that
"first-time switch" use -- null in lisp, None in Python.
An alternative might be to treat the empty lst as
an exceptional case:
def mostfn(fn, lst):
try: a = lst[0]
except IndexError: return [], None
ret, max = [], fn(a)
for a in lst:
score = fn(a)
if score > max:
max = score
ret = [a]
elif score == max:
ret.append(a)
return ret, max
a _bit_ more complicated than Paul's code, and calls
fn twice on lst[0], but it caters to my dislike for
"first-time switches"...;-). One could remove the
double-call problem by changing the start to:
def mostfn(fn, lst):
it = iter(lst)
try: a = it,next()
except StopIteration: return [], None
ret, max = [a], fn(a)
for a in it:
...
If taking O(N) auxiliary memory was acceptable, of
course, there would be an alternate possibility:
def mostfn(fn, lst):
if not lst: return [], None
aux = [ (fn(a), a) for a in lst ]
Max = max([ f for f, a in aux ])
return [ a for f, a in aux if f==Max ], Max
Typical problem with all high-level languages --
they often make most attractive an approach that
may not be quite as spare of bytes and cycles as
some lower-level one!-) [A simple test with
fn=lambda x:x%333 and lst=range(9999) shows the
lower-level approach is over 3 times faster,
both with and without psyco.proxy on both].
Alex
Hi Marcin 'Qrczak' Kowalczyk, What about reading (in books, on WWW)? I guess you would say
"indentation"...
Indentation in Lisp is not clear enough. Let's look at an example from
http://www-users.cs.umn.edu/~gini/ai...m/onlisp.lisp:
(defun mostn (fn lst)
(if (null lst)
(values nil nil)
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))
Note that only one pair of adjacent lines is indented by the same amount.
Other alignments are in the middle of lines.
I have ignored the followup-to because your comment is ignorant. If you
want to make ignorant comments please only make them in comp.lang.lisp so
corrections don't also have to be posted to comp.lang.python.
Here is what a Common Lisp users see from the indentation:
1. IF takes a "test" form, a "then" form and in this case an "else"
form. By the indentation I can instantly see that the "test" form is
(null lst), the "then" form is (values nil nil) and the "else" form is:
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))
2. LET is binding values to RESULT and MAX. By the indentation I can
instantly see that this binding is in effect for the remainder of the form:
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))
3. By the indentation I can also instantly see that the DOLIST is
only operating over:
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
4. I can instantly see that SCORE is bound only within this form:
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
5. And finally I can instantly see that there are two test conditions, the
first being (> score max) and the second (= score max). Again by the
indentation I can see the return results grouped with the test conditions.
In pulling apart these forms there are still dangling parentheses
remaining on the page. That's the point. You can read the semantics
through knowledge of the special forms and the indentation alone. I didn't
attempt to manually delete the parentheses without the assistance
of an appropriate editor because I would probably screw something up. But
it did not stop me from being able to read the code.
Regards,
Adam wa**************@eircom.net (Russell Wallace) writes: However, this really applies only when you're doing things the
language designer anticipated. The great thing I find about Lisp is
When I'm really doing something the language designer didn't
anticipate (and the required features don't already exist), I'm
probably doing something wrong and need to revise my design
anyway. You can do a whole lot in Python, esp. as you can code parts
in C if you really need that.
that when I'm doing something the language was _not_ designed to
handle, it's not an "oh shit" problem, it's a "well, I suppose I can
do this with a few macros" problem.
One can always go to c.l.py and ask, only to see that the problem is
easily solved in plain old Python. I think the benefits of Python far
outweigh the theoretical scenario that I actually needed some feature
that isn't there, and could be done in Lisp. Most often the missing
features involve not having a library to, say, access some database,
and I doubt Lisp has more than Python to offer in that area.
Meanwhile, people are voting with their feet: a lot (thousands? don't
know the exact figure) of people are taught Lisp (well, Scheme, but
anyway) at colleges/whatever every year, and they abandon it in a
blink of an eye after the course (obviously this might be because the
courses emphasize functional programming). Many even think that C++,
of all things, is easier!
--
Ville Vainio http://www.students.tut.fi/~vainio24
On 20 Oct 2003 09:01:33 +0300, Ville Vainio <vi********************@spamtut.fi> wrote: Meanwhile, people are voting with their feet: a lot (thousands?
don't know the exact figure) of people are taught Lisp (well,
Scheme, but anyway) at colleges/whatever every year, and they
abandon it in a blink of an eye after the course (obviously this
might be because the courses emphasize functional programming). Many
even think that C++, of all things, is easier!
Yeah, sure. And 95% of all computer users use Windows so it must be
the best OS. You know the "50 million flies" saying?
Edi.
"If a million people say a foolish thing, it is still a foolish
thing."
(Anatol France)
Edi Weitz <ed*@agharta.de> writes: Yeah, sure. And 95% of all computer users use Windows so it must be
the best OS. [..]
...and presumably the masses of Windows users are also thinking that
whatever theoretical (read "something I've never heard of") benefits
other systems may offer, it will surely be offset by the next
point-and-click application from Microsoft.
--
Frode Vatvedt Fjeld
Paul Rubin <http://ph****@NOSPAM.invalid> writes: No language feels more natural than Lisp. There's a real sense that
while Python was invented by a brilliant programmer, Lisp is built
into of the structure of the Universe.
yes! The following quote from the ILC-03 (please help me: I can't
remember who said it!) says it all: "John Mc Carthy didn't invent lisp,
he _discovered_ it".
--
(espen)
Edi Weitz <ed*@agharta.de> writes: Yeah, sure. And 95% of all computer users use Windows so it must be
the best OS. You know the "50 million flies" saying?
Yep, but when exposed to a clearly superior language, one might assume
that at least a part of the students would get the clue and keep on
using it after the course. You can only go so far with "all college
students are morons". People diss Python if they haven't tried it, but
convert soon after giving it a spin; people diss Lisp even after
trying it. Perhaps they are morons, flies, whatever. Python also
welcomes them with open arms. When all is said and done, being 31337
is not that important.
However, Lisp (Emacs Lisp) *is* one of the three languages I actually
can find use for. The other two are C++ (day job) and Python.
--
Ville Vainio http://www.students.tut.fi/~vainio24
On 20 Oct 2003 12:29:39 +0300, Ville Vainio <vi********************@spamtut.fi> wrote: Edi Weitz <ed*@agharta.de> writes:
Yeah, sure. And 95% of all computer users use Windows so it must
be the best OS. You know the "50 million flies" saying?
Yep, but when exposed to a clearly superior language, one might
assume that at least a part of the students would get the clue and
keep on using it after the course.
As the OP wrote, most of these students are taught Scheme, not Common
Lisp. (And, as we have seen quite often on c.l.l., probably by
teachers who force them to use weird recursive constructs and tell
stories about Lisp - "it is slow, it is interpreted, ..." - that have
been obsolete for decades.)
Also, where do you see evidence that /all/ students dismiss Lisp
immediately? We have a constant (albeit small) influx of newbies on
c.l.l.
As a counter-example consider the courses Robert Strandh teaches in
France (Bordeaux?) - they seem to be very successful. He's teaching
Common Lisp and some of his students "got the clue." They even
implemented a perfectly usable window manager in Common Lisp during
the course.[1]
Edi.
[1] <http://common-lisp.net/project/eclipse/>
The website is mostly empty but you can download the software and
also subscribe to the mailing list.
Ville Vainio wrote: wa**************@eircom.net (Russell Wallace) writes:
However, this really applies only when you're doing things the
language designer anticipated. The great thing I find about Lisp is
When I'm really doing something the language designer didn't
anticipate (and the required features don't already exist), I'm
probably doing something wrong and need to revise my design
anyway.
So why is it that Python is continuously evolving as a language? Do you
think this is going to stop at some stage?
Wouldn't it be better if everyone could contribute to the evolution of a
language, and then let the community decide what the best approaches are?
See for example, the SRFI approach of the Scheme community.
that when I'm doing something the language was _not_ designed to
handle, it's not an "oh shit" problem, it's a "well, I suppose I can
do this with a few macros" problem.
One can always go to c.l.py and ask, only to see that the problem is
easily solved in plain old Python. I think the benefits of Python far
outweigh the theoretical scenario that I actually needed some feature
that isn't there, and could be done in Lisp.
The approach for Lisp is to write a domain-specific language for the
problem at hand, and then to write the program in that domain-specific
language. (These are not actually two distinct steps, but these parts
are usually achieved in an evolutionary way.)
If you want to keep your Lisp program in a specific programming style
(OOP, functional, imperative, etc.) you can do that either. Lisp gives
you a choice here.
With Python, you have to stick to the constructs the languages give you.
When you want to add domain-specific abstractions on the language level,
you have to step outside of the language, and for example use program
generators. Python doesn't give you a choice here.
This is only to say that in general, we usually don't use macros just to
"fix" the language, but we want macros because it enables a programming
style that is not available in most other programming languages.
Most often the missing
features involve not having a library to, say, access some database,
and I doubt Lisp has more than Python to offer in that area.
That's correct.
Meanwhile, people are voting with their feet: a lot (thousands? don't
know the exact figure) of people are taught Lisp (well, Scheme, but
anyway) at colleges/whatever every year, and they abandon it in a
blink of an eye after the course (obviously this might be because the
courses emphasize functional programming). Many even think that C++,
of all things, is easier!
They can't vote with their feet wrt to particular features of the
programming languages they use, can they?
And as a sidenote, if you are seriously considering to learn and maybe
use Lisp in practice, you should take a look at _both_ major dialects,
i.e. Common Lisp and Scheme. They are very different in several
respects, and if you think that one of them sucks, this doesn't
necessarily mean that you will also despise the other one.
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Ville Vainio wrote: Edi Weitz <ed*@agharta.de> writes:
Yeah, sure. And 95% of all computer users use Windows so it must be
the best OS. You know the "50 million flies" saying?
Yep, but when exposed to a clearly superior language, one might assume
that at least a part of the students would get the clue and keep on
using it after the course.
In fact this happens. There are people out there who get it and stick to
Lisp. It's true that the majority doesn't do it (yet?), but that's
because Lisp doesn't give you instant rewards. I guess it takes
considerably longer to learn Lisp so that you can use it effectively, in
the sense that you can go beyond the stage that you can maximally get at
in other languages. (Also think about the possible net effects of
instructors who try to teach Lisp without having gotten it themselves.
Especially in the functional programming camp, there are people who see
Lisp as just a prelude to languages like ML and Haskell. This misses
some important points.)
All in all, these things are hard to measure. I have first learned about
Lisp about 10-15 years ago, and then completely forgot about it. It was
only about one and a half years ago that I have rediscovered it. In the
meantime, I have learned a lot about restrictions that most languages
impose on me as a programmer. Now I can really appreciate the expressive
power of Lisp and the degree to which unnecessary restrictions don't
bother me anymore in Lisp. This wouldn't have been possible 15 years
ago. Now do you really think the fact that I have "dissed" Lisp at first
tells us something really important about the language other than that I
was just too inexperienced to be able to appreciate it?
And in the meantime the world is continuously moving in the direction of
more dynamic and less restricted languages. Otherwise other languages
before Python would have been enough already. I think there is a pattern
involved here, and I am pretty sure that it will ultimately lead to
something that is as powerful as Lisp is today.
This is not just a fanatical rant of a religious follower, although it
may sound like that. However, you can objectively point out the
ingredients that make Lisp the mother of all languages in a certain
sense. See http://www.paulgraham.com/rootsoflisp.html
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Ville Vainio wrote: wa**************@eircom.net (Russell Wallace) writes:
However, this really applies only when you're doing things the
language designer anticipated. The great thing I find about Lisp is
When I'm really doing something the language designer didn't
anticipate (and the required features don't already exist), I'm
probably doing something wrong and need to revise my design
anyway. You can do a whole lot in Python, esp. as you can code parts
in C if you really need that.
Yes to the latter, no to the former. Say that you want to do, e.g.,
aspect-oriented programming: that's something Guido definitely did
not anticipate, so Python "out of the box" doesn't support it --
that doesn't mean you're "doing something wrong and need to revise
your design" if your purpose is to experiment with AOP. Sure, you
can download several packages offering AOP for Python (google for
python aop
for a few thousand links), but each of them will do so within the
normal confines of ordinary Python syntax. If you want to experiment
with divergent syntax, too, as well as revolutionary semantics, then
those packages can't do it for you, except by implementing a new and
different language, separate from Python though integrated with it.
If your purpose in life is to write good, working applications with
high productivity, then I agree it's most likely suboptimal to play
around with paradigms that are novel, experimental and not (yet?)
well-integrated -- but if your purpose is experimenting with the very
bases of computing itself, such experimentation can't be called "wrong"!
Although it IS quite feasible to integrate most such experiments with
Python, there _are_ other languages that may be even more suitable for
that: Ruby if you don't care all that much about syntax sugar (you can
redefine just about any methods of Object etc to get the semantics you
want to play with -- but it may not have quite the syntax you'd most
like, e.g. you may find yourself having to use f.call(x) rather than
just f(x) because Ruby distinguishes callables from non-callables) --
Lisp (or Dylan, basically an infix-syntax dialect thereof;-) if you DO
care a lot about molding the syntax sugar to your experimental wishes.
that when I'm doing something the language was _not_ designed to
handle, it's not an "oh shit" problem, it's a "well, I suppose I can
do this with a few macros" problem.
One can always go to c.l.py and ask, only to see that the problem is
easily solved in plain old Python. I think the benefits of Python far
outweigh the theoretical scenario that I actually needed some feature
that isn't there, and could be done in Lisp. Most often the missing
You're taking it for granted that one's actual purpose is just to write
good working applications. That need not be the case: another might
have the purpose of experimenting with novel paradigms, instead.
features involve not having a library to, say, access some database,
and I doubt Lisp has more than Python to offer in that area.
From the point of view of deploying working applications, yes, you're
surely right. But it's not the ONLY valid point of view in the world.
Meanwhile, people are voting with their feet: a lot (thousands? don't
know the exact figure) of people are taught Lisp (well, Scheme, but
anyway) at colleges/whatever every year, and they abandon it in a
blink of an eye after the course (obviously this might be because the
courses emphasize functional programming). Many even think that C++,
of all things, is easier!
Sure, there's a "network effect" (in the sense of economics, nothing
to do with computer networks, necessarily;-) that goes to the advantage
of popular languages (C, Java, C++, perl) over less-popular ones (Python,
Ruby, lisps of all sorts). E.g., it's easier to find add-ons, books,
people to cooperate with, etc, etc. But it's only one of many factors
to consider in language choice, particularly when you're comparing
languages particularly hard to master, such as C++ or perl, with ones
that are particularly EASY to master, such as Scheme, Python, Ruby --
teaching one of the latter to people new to it then zipping along with it
may still be faster, for a large enough project, than finding people who
THINK they master, e.g., C++, and slogging through the project while
repeatedly having to engage in bouts of "emergency fire-fighting" and
unplanned tutoring each time some aspects they DON'T master comes up:-).
Alex
On 20 Oct 2003 09:01:33 +0300, Ville Vainio
<vi********************@spamtut.fi> wrote: When I'm really doing something the language designer didn't
anticipate (and the required features don't already exist), I'm
probably doing something wrong and need to revise my design
anyway.
If you find that, then that would be a good reason for you to use
Python; there is of course no rule that says the same programming
language has to be best for everyone (or even for every program
written by a given person).
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address. http://www.esatclear.ie/~rwallace
Pascal Costanza <co******@web.de> writes: So why is it that Python is continuously evolving as a language? Do
you think this is going to stop at some stage?
Python is not only the language, it's also the implementation (or
implementations). I don't know whether the evolution is ever going to
stop, you've got to ask Guido :-). Obviously I wouldn't mind if the
language reached Perfection within, say, 10 years, after which it
could be standardized and only the libraries and the implementation
would evolve.
Wouldn't it be better if everyone could contribute to the evolution of
a language, and then let the community decide what the best approaches
are?
Possibly. But personally, I trust the guys in charge. Lisp might the
very essence of programming, built into the DNA of computer science,
but Python is the channeling of that quintessential truth into a form
that is *easily* writeable and esp. readable by mere mortals. It might
lose some of the power, but improved productivity in 90% of the
situations complements this nicely.
With Python, you have to stick to the constructs the languages give
you. When you want to add domain-specific abstractions on the language
Yes, and it gives me all I need. You can do a whole lot with
dynamically typed OO and powerful data types.
Meanwhile, people are voting with their feet: a lot (thousands? don't
And as a sidenote, if you are seriously considering to learn and maybe
use Lisp in practice, you should take a look at _both_ major dialects,
i.e. Common Lisp and Scheme. They are very different in several
I only use Emacs Lisp. I have Python for the problem domains that CL
and Scheme would cover. I guess I might start hacking CL if/when
XEmacs switched their Lisp implementation, which I believe is in the
roadmaps...
--
Ville Vainio http://www.students.tut.fi/~vainio24
Ville Vainio wrote: Pascal Costanza <co******@web.de> writes:
So why is it that Python is continuously evolving as a language? Do
you think this is going to stop at some stage?
Python is not only the language, it's also the implementation (or
implementations). I don't know whether the evolution is ever going to
stop, you've got to ask Guido :-). Obviously I wouldn't mind if the
language reached Perfection within, say, 10 years, after which it
could be standardized and only the libraries and the implementation
would evolve.
....and if it never reached perfection? If perfection were not reachable,
not for Python, not for any language? Wouldn't it be better if everyone could contribute to the evolution of
a language, and then let the community decide what the best approaches
are?
Possibly. But personally, I trust the guys in charge. Lisp might the
very essence of programming, built into the DNA of computer science,
but Python is the channeling of that quintessential truth into a form
that is *easily* writeable and esp. readable by mere mortals.
No, it's not. Python doesn't have the "programs = data" feature. With Python, you have to stick to the constructs the languages give
you. When you want to add domain-specific abstractions on the language
Yes, and it gives me all I need. You can do a whole lot with
dynamically typed OO and powerful data types.
What makes you so sure that it gives you all you need? Is this merely a
belief, or can you back that claim by objective facts?
Pascal
--
Pascal Costanza University of Bonn
mailto:co******@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <co******@web.de> writes: ...and if it never reached perfection? If perfection were not
reachable, not for Python, not for any language?
I guess some pythonistas are like communists, they happily accept the
dictatorship of the proletariat as an intermediate solution...
Common Lips programmers, on the other hand, are like laid-back
anarchists with a Loneley Planet guide book: "Getting there is half
the fun" :-)
--
(espen)
Pascal Costanza <co******@web.de> writes: ...and if it never reached perfection? If perfection were not
reachable, not for Python, not for any language?
Then we'll just let it evolve, working around the shortcomings as we
go.
Yes, and it gives me all I need. You can do a whole lot with
dynamically typed OO and powerful data types.
What makes you so sure that it gives you all you need? Is this merely
a belief, or can you back that claim by objective facts?
It gives me all *I* need, it is very possible that it doesn't give
anyone else what they need. Perhaps I just don't need much. As far as
facts go, I don't even have objective facts to back my own existence,
so I'm not going to pursue that route.
Let's put it this way: Lisp is obviously the best language in
existence. All rivers flow from Lisp, and flow back to
Lisp. Preferences of human beings are inconsequential, it's not Lisp's
fault that some people are somewhat lacking in cognitive capability. I
just don't expect it to be hugely popular in the near future, at least
outside academia.
I'll go shut up now - don't really feel like reheating the old c.l.l
vs c.l.py flamewars (we've had enough of those - somehow these two
groups just don't mix). I have no axe to grind with Lisp; in fact I'm
planning to improve my skills in it. And some of you Lispers might do
well to check out Python - Lisp is Love, and thus very forgiving even
if you stray from the One True Way a little bit. Who knows, you might
have some fun :-).
--
Ville Vainio http://www.students.tut.fi/~vainio24
Pascal Costanza wrote:
... So why is it that Python is continuously evolving as a language? Do you
Basically because Guido LIKES language design, I think;-).
think this is going to stop at some stage?
Not as long as Guido's at the helm:-).
Wouldn't it be better if everyone could contribute to the evolution of a
language, and then let the community decide what the best approaches are?
Everybody CAN contribute to Python! Indeed, I've never seen a community
more attuned to open source. But as for "who decides" -- you DO know that
a camel is a horse designed by a committee, right? I far prefer to have
one highly respected designer with final decision-making power. Guido's
not impervious to "the community", of course, but, in the end, it's HIS
final decision to make -- NOT some amorphous committee's.
Note that this delegation of final power IS "the community's decision".
Exactly because Python is aggressively open-source, there's NOTHING
stopping you, me, or anybody else, from taking a CVS snapshot and
forking off our own "python-like language" (presumably keeping binary
FFI compatibility to take advantage of the mainstream's abundance
of libraries and extensions). But people _don't_ -- thus concretely
recognizing the advantages of sticking to "Python as Guido indented
it" over designing their own language[s]. Even things that may look
like forks to the uninitated, such as Stackless, are anything but --
Christian Tismer took huge pains in Stackless development to turn it
back into a small patch anybody can apply to Python's official sources,
just to avoid diverging from the mainstream.
I think you couldn't CALL your altered language "Python", but there
are plenty of other reptiles and/or British comedy groups that you
can no doubt freely choose from.
The approach for Lisp is to write a domain-specific language for the
problem at hand, and then to write the program in that domain-specific
Right. People who fancy themselves as language designers will surely
be happier that way. People who prefer to use languages used by better
language designers than themselves, such as me, will be happier with
Python.
If you want to keep your Lisp program in a specific programming style
(OOP, functional, imperative, etc.) you can do that either. Lisp gives
you a choice here.
With Python, you have to stick to the constructs the languages give you.
Which include roughly the same paradigms as the above, BTW.
When you want to add domain-specific abstractions on the language level,
Specifically: when you want to ALTER SYNTAX...
you have to step outside of the language, and for example use program
generators. Python doesn't give you a choice here.
....you can't "just alter Python's own syntax with your own changes":
you have plenty of choices (implement your chosen semantics within
Python's syntax, use any of N available parsers to parse your favourite
syntax -- user EITHER "program generators" OR interpreters at any
level on the parsed forms -- etc, etc). You just don't have the one
choice of *altering Python's own syntax wholly within Python itself*.
Describing a situation of having 99 available strategies rather than
100 as "doesn't give you a choice" can be charitably described as
"ridiculous", it seems to me.
They can't vote with their feet wrt to particular features of the
programming languages they use, can they?
What are you saying? Anybody can vote with their editor to alter
whatever set of features they hate. Well, in practice, at the
moment, only if they know enough C, or Java, or maybe C#, or
O'CAML -- they ARE welcome to download the pypy sources and fork
off those, of course, but if they did that right now their dialect's
performance would be, ahem, somewhat slightly sub-optimal (as in,
HUNDREDS of times too slow -- we're far from turning to various
optimizations that we plan to remedy that!).
But _in practice, people don't_, except for play and experiments
of various kinds. You can find a bazillion extremely varied
extensions to Python of all imaginable kinds, *BUT* they're ALL
*add-ons*, NEVER alteration of syntax or fundamental semantics
(Stackless had to work hard to ensure unchanged semantics JUST
adding [used to be continuations, now instead] microthreads --
no semantic alteration; psyco builds machine code on the fly
WITHOUT any syntax nor semantic alteration; etc, etc). The way
Pythonistas are voting with their feet and their editors seems
to be overwhelmingly in favour of Guido, see...
Alex
Alex Martelli <al***@aleax.it> writes: Describing a situation of having 99 available strategies rather than
100 as "doesn't give you a choice" can be charitably described as
"ridiculous", it seems to me.
But it's not 100 against 99, it's 2 against 1. The two are functional
and syntactic abstraction.
And: All programming can be seen as an exercise in building a
language, where the programming language per se is merely a starting
point and provider of mechanisms for extending that starting point. So
whenever you define a function (or macro) you extend the language,
usually in the direction of some particular application area.
The "but I'm not a programming language designer" argument against
macros is very common and very bogus. Every programmer is.
--
Frode Vatvedt Fjeld
Alex Martelli wrote: Wouldn't it be better if everyone could contribute to the evolution of a
language, and then let the community decide what the best approaches are?
Everybody CAN contribute to Python! Indeed, I've never seen a community
more attuned to open source. But as for "who decides" -- you DO know that
a camel is a horse designed by a committee, right? I far prefer to have
one highly respected designer with final decision-making power. Guido's
not impervious to "the community", of course, but, in the end, it's HIS
final decision to make -- NOT some amorphous committee's.
Who cares about committees? I don't.
Yes, there exist committee-driven standards for Scheme and Common Lisp.
But they are not by far as limiting as those for other languages.
In the case of Python, couldn't you rightfully regard it as driven by a
one-man commitee? ;-)
With Python, you have to stick to the constructs the languages give you.
Which include roughly the same paradigms as the above, BTW.
Yes, roughly.
When you want to add domain-specific abstractions on the language level,
Specifically: when you want to ALTER SYNTAX...
If it were only about making small alterations to the syntax, I wouldn't
lead this discussion. I mean what I say, I am talking about adding
full-fledged language constructs.
you have to step outside of the language, and for example use program
generators. Python doesn't give you a choice here.
...you can't "just alter Python's own syntax with your own changes":
you have plenty of choices (implement your chosen semantics within
Python's syntax, use any of N available parsers to parse your favourite
syntax -- user EITHER "program generators" OR interpreters at any
level on the parsed forms -- etc, etc). You just don't have the one
choice of *altering Python's own syntax wholly within Python itself*.
Exactly. Lisp-style Macros make these things a breeze. The other
alternatives you suggest are considerably more complicated. As I have
said before, Lisp makes the simple things a little bit harder (-> syntax
for beginners), so that the hard things become considerably simpler (->
adding sophisticated abstractions in order to considerably reduce the
amount of code for complex tasks).
Describing a situation of having 99 available strategies rather than
100 as "doesn't give you a choice" can be charitably described as
"ridiculous", it seems to me.
I know about these choices, I have tried them all. I have written
compilers, interpreters, with and without parser generators, and have
co-designed and used transformation frameworks. These things are
considerably harder to build, and you need to spend a considerable
amount of time on the technology itself which distracts you from solving
the problem at hand. With Lisp-style macros, these things are much
simpler to handle once you have gotten it.
But _in practice, people don't_, except for play and experiments
of various kinds. You can find a bazillion extremely varied
extensions to Python of all imaginable kinds, *BUT* they're ALL
*add-ons*, NEVER alteration of syntax or fundamental semantics
You still have a wrong idea of how macros work. Macros are of course
also only add-ons. You don't alter unrelated syntax or unrelated
portions of source code, and you don't change fundamental semantics.
Instead of spreading misconceptions you should really start to get to
know the things better that you criticize.
Pascal
Pascal Costanza <co******@web.de> writes: All in all, these things are hard to measure. I have first learned
about Lisp about 10-15 years ago, and then completely forgot about
it. It was only about one and a half years ago that I have
rediscovered it. In the meantime, I have learned a lot about
restrictions that most languages impose on me as a programmer. Now I
can really appreciate the expressive power of Lisp and the degree to
which unnecessary restrictions don't bother me anymore in Lisp. This
wouldn't have been possible 15 years ago. Now do you really think the
fact that I have "dissed" Lisp at first tells us something really
important about the language other than that I was just too
inexperienced to be able to appreciate it?
I still need to drag myself over the learning curve. I am forever
being distracted by other things and not devoting time to Lisp or any
other programming right now.
However.
My personal desire is to use Lisp as a competitive advantage for my
own software development. Self employment with a livable income is
what I want and I think that Lisp can get me there.
I have no beef with Python. I don't like the use of white space to
define block structures, but that is just my hangup. I think it is a
Good Thing that Perl has something to compete against. There is also
Ruby of course. Heck, it's not hard to point out all the different
scripting languages out there. I think scripting languages will rule
in the web based application world, Java notwithstanding.
I've served time doing web based applications. They have their
place, but they are not something I find very interesting. I prefer
the old school application that each computer has a copy of to run.
Compiled languages server better for that purpose I think. Sure,
embedding a scripting language like Python in a traditional
application will make it tons better (unless the application is a
Dali Clock). However, the base language is rather irrelevant in that
case. At least it is to the user.
On an unrelated note, I'm not entirely comfortable with all this
cross posting. It generates the sort of debate you see in the
*.advocacy groups. I'm not saying the debate is a bad thing. It
just clutters up the news groups that are intended to provide support
for their respective languages. If the group doesn't already exist,
perhaps a formal proposal for comp.lang.advocacy is in order. I know
some languages have specific advocacy groups already.
comp.lang.java.advocacy could be moved to comp.lang.advocacy.java to
go with the new group as well as the others that are out there so
that everything is in one pile.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
Pascal Costanza <co******@web.de> wrote previously:
|Wouldn't it be better if everyone could contribute to the evolution of a
|language, and then let the community decide what the best approaches are?
I can think of almost nothing worse than this!
Well, "design-by-committee" results like XSLT are even worse. But the
"benevolent dictator" model is VASTLY better than the "let 1000 flowers
bloom" approach.
Incidentally, I have never seen--and expect never to see--some new
mysterious domain where Python is too limited because the designers did
not forsee the problem area. Nor similarly with other very high level
languages. It NEVER happens that you just cannot solve a problem
because of the lack of some novel syntax to do so... that's what
libraries are for.
Yours, Lulu...
--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.
Ville Vainio <vi********************@spamtut.fi> writes: I only use Emacs Lisp. I have Python for the problem domains that CL
and Scheme would cover. I guess I might start hacking CL if/when
XEmacs switched their Lisp implementation, which I believe is in the
roadmaps...
If even XEmacs is ported over to Common Lisp in my lifetime I will be
surprised. If it happens to GNU Emacs, surprise will not be enough
and I will have to resort to astonishment.
I'm not thinking of the core code. I'm thinking of all those *.el
files floating around the universe.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
Alex Martelli <al***@aleax.it> writes: The approach for Lisp is to write a domain-specific language for the
problem at hand, and then to write the program in that domain-specific
Right. People who fancy themselves as language designers will surely
be happier that way. People who prefer to use languages used by better
language designers than themselves, such as me, will be happier with
Python.
Any programmer writing a program is by necessity also a language
designer. The act of writing a program consists of designing a
language. Did you read Steele's "Growing a Language", which someone
posted a pointer to earlier in the thread? It is essentially about
Java, but is very enlightening on the "programming as language design"
issue.
There is nothing magical or special about syntactic abstraction. It is
just an abstraction mechanism like the rest of them.
Björn
Pascal Costanza wrote:
... In the case of Python, couldn't you rightfully regard it as driven by a
one-man commitee? ;-)
Ah, what a wonderfully meaningful view that is.
Specifically: when you want to ALTER SYNTAX...
If it were only about making small alterations to the syntax, I wouldn't
I didn't say SMALL. Small or large, it's about alteration to the
syntax. Other lispers have posted (on several of this unending
multitude of threads, many but not all of which I've killfiled)
stating outright that there is no semantic you can only implement
with macros: that macros are ONLY to "make things pretty" for
given semantics. If you disagree with them, I suggest pistols at
ten paces, but it's up to you lispers of course -- as long as
you guys with your huge collective experience of macros stop saying
a million completely contradictory things about them and chastising
me because (due, you all keep claiming, to my lack of experience)
I don't agree with all of them, I'll be glad to debate this again.
Till then, this is yet another thread that get killfiled.
lead this discussion. I mean what I say, I am talking about adding
full-fledged language constructs.
Right: exactly what I _DON'T_ want to happen to my favourite language.
you have to step outside of the language, and for example use program
generators. Python doesn't give you a choice here.
...you can't "just alter Python's own syntax with your own changes":
you have plenty of choices (implement your chosen semantics within
Python's syntax, use any of N available parsers to parse your favourite
syntax -- user EITHER "program generators" OR interpreters at any
level on the parsed forms -- etc, etc). You just don't have the one
choice of *altering Python's own syntax wholly within Python itself*.
Exactly. Lisp-style Macros make these things a breeze. The other
alternatives you suggest are considerably more complicated. As I have
What's "considerably more complicated" in, say,
my_frobazzer = frobaz_compiler('''
oh my pretty, my beauteous,
my own all my own special unique frambunctious *LANGUAGE*!!!
''')
and later on call my_frobazzed(bim. bum, bam) at need? The complexity
of the frobaz_compiler factory callable depends exclusively on the
complexity of the language you want it to parse and compile, and you
of course have total choice ("Python doesn't give you a choice" MY
LEFT FOOT) on how to apportion the work between the factory and the
__call__ method of the resulting my_frobazzer.
You just have to respect Python's syntax and fundamental semantics
(e.g., strict order when your Python code calls a Python callable --
you can ALWAYS, TOTALLY count on this, NO surprises possible EVER),
and you still have a BAZILLION of choices, even AFTER making the
decision, which SHOULD be momentous rather than "a breeze" (!!!),
to CHOOSE to structure your whole application around your own unique
language or sub-language.
If Python makes it just as appealing to structure applications in
other ways, reserving "language design" for those occasions which
really call for it, so much the better. As I've repeatedly posted,
I've SUFFERED the consequences of computer scientists "breezily"
designing embedded Lisp subdialects for "domain-specific languages"
for domains they DIDN'T know 1/10th as well as the poor non-CS'ers
forced to suffer under that mishmash (hardware design the domain,
hardware design engineers the poor non-CS'ers) -- while at other
competing firms language design was treated with the respect it
deserves, producing not-embedded-in-anything, not-necessarily-
distorted-extended-subsets-of-anything hardware design languages
that let people actually DESIGN HARDWARE when that was their job.
said before, Lisp makes the simple things a little bit harder (-> syntax
for beginners), so that the hard things become considerably simpler (->
adding sophisticated abstractions in order to considerably reduce the
amount of code for complex tasks).
The vast majority of applications has absolutely no need to tinker
with the language's syntax and fundamental semantics. When you need
a language with different syntax, this is best treated as a serious
task and devoted all the respect it deserves, NOT treated as "a
breeze". PARTICULARLY for domain-specific languages, the language's
designers NEED access to domain-specific competence, which typically
they won't have enough of for any domain that doesn't happen to be
what they've spent many years of their life actually DOING (just
STUDYING doesn't cut it); the people WITH the domain-specific
competence will in turn not typically be experienced programmers --
they've spent their lives getting experience in the specific domain
instead. Making things harder for "beginners" (which may well be
the domain-specific experts) is then the wrong choice: those
non-programmers fully deserve, if a domain-specific language is
indeed warranted by the task's complexity, a language that does NOT
just happens to embed bits and pieces of another, harder-for-
beginners language, just because it was "a breeze" to design it thus.
I'm talking about substantial applications meant to get into heavy
production use. For experimentation, play, research in computing
itself, whatever, go ahead, not my own interest. For application
programming, IF a domain-specific language is needed, I want it to
be designed FOR THE USERS' NEEDS AND CONVENIENCE (==productivity!),
NOT because it's easy to hack together with macros. And that IF is
a big one; more often than not, no weird new syntax and semantics
are warranted. If it's too easy to tweak syntax and semantics, they
will be tweaked whether that's warranted or not; such frequent and
lightly undertaken SYNTAX CHANGES are NOT what I want in the language
I will use, in collaboration with many others, to build applications.
Some resistance to change is useful. Without attrition, walking
would be VERY hard. Without a constitution that's FAR harder to
change than ordinary laws, and "balance of powers" so that the
legislature, the executive and the courts hamper each other, a
democracy might be dangerously unstable (the "Federalist Papers"
make that case particularly well). Without an unchanging core,
such as syntax and fundamental semantics, a language may be less
useful for application development by middling-large groups (the
language might be wonderful for play and free-spirited experiments
AND at the same time less wonderful for such usage).
Describing a situation of having 99 available strategies rather than
100 as "doesn't give you a choice" can be charitably described as
"ridiculous", it seems to me.
I know about these choices, I have tried them all. I have written
So, you KNOW "doesn't give you a choice" is ridiculous.
compilers, interpreters, with and without parser generators, and have
co-designed and used transformation frameworks. These things are
considerably harder to build, and you need to spend a considerable
amount of time on the technology itself which distracts you from solving
You are (by far) exaggerating the effort. Check out such tools as
spark or SimpleParse and you'll see that parsing a custom language,
e.g. into an AST, is reasonably trivial. Once you have your AST,
you're basically in the same position as you start out with
S-exprs, so compiling and/or interpreting them is the same work.
What you don't do this way is MERGING LANGUAGE AND META-LANGUAGE --
sprinkling bits and pieces of your own custom language in the middle
of your implementation language and vice versa -- not "casually": if
and when you decide to embed languages into each other you must
deliberately take all decisions about arranging that.
As a consequence, the language you design is NOT influenced by the
language[s] you choose to use for the implementation thereof -- no
special push to make the supposedly application-domain-specific
language conform to uses and conventions typical of the implementation
language, no fragments of the implementation language suddenly perking
up in the middle of the application-domain-specific language.
So, for example, the BLM Language being developed at AB Strakt
(www.strakt.com) is INDEPENDENT from Python (though the designers
have of course been influenced by the parts of Python's syntax
they most liked, e.g., significant indentation); in the first
implementation, the embedded language for expressions and actions
is also Python, but the syntax already provides for embedding
multiple procedural/imperative languages even inside a single
BLM module. The interface between the declarative parts and the
embedded imperative ones is defined in terms of functions and
objects, so that, if and when the application-domain-specific
experts demand it (and pay for it:-) other languages may just as
well be adapter (sufficiently non-dynamic ones will necessarily
end up with lots of boilerplate code such as
attrib := blm.services->get_attribute(current_name);
and the like, but then, users of non-dynamic languages do appear
to like such boilerplate:-).
Sure, it could perfectly have been done in lisp (or any other
sufficiently high-level language just as well), but one would
have had to resist the temptation to orient the language being
designed towards "ease of implementation with lisp macros and
ease of integration with snippets of lisp", making it a
totally separate language -- and I've seen, and suffered on
my own skin, what typical CS'ers do about resisting such
temptation, particularly when convinced (as most, though not
all, of you guys seem to be) that lisp is obviously the best
language for ANY task, so why EVER could one POSSIBLY want a
totally different one for [insert any application domain]...?!
[Well, I've seen what they did about it 20+ years ago -- no
doubt human nature HAS changed drastically since, I'm sure].
the problem at hand. With Lisp-style macros, these things are much
simpler to handle once you have gotten it.
But will the simple way be the RIGHT one? Or will you end up
designing application-domain-specific languages needlessly, in
applications that would be much better structured in other ways,
AND when an application-domain-specific language IS called for,
end up "along the continuum" designing it ``by inertia'' as just
some "extended subset" of lisp, instead...?
But _in practice, people don't_, except for play and experiments
of various kinds. You can find a bazillion extremely varied
extensions to Python of all imaginable kinds, *BUT* they're ALL
*add-ons*, NEVER alteration of syntax or fundamental semantics
You still have a wrong idea of how macros work. Macros are of course
also only add-ons. You don't alter unrelated syntax or unrelated
portions of source code, and you don't change fundamental semantics.
I have HAD to use (several mutually incompatible varieties of)
"application-domain-specific languages" built by lispers with
their beloved macros (in the early '80s, so it wasn't common
lisp yet, but rather a congeries of different lisp dialects,
including scheme). I know how macros work: they get hacked by
computer scientists that don't really grok the application domain,
then the resulting "extended subset of lisp" du jour is foisted
on people who DO know the application domain, CLAIMING falsely
to be appropriate for the specific application domain -- why,
they're (some kind of) lisp, OF COURSE they're automatically ideal
for ANY application right? And I'm not sure what the "unrelated"
syntax or portions of sources were, if any -- we had to describe
system-level, interface-level, circuit-level &c views of a chip
being developed in one or more of those (expl.del) "application
awful languages" and NO of _course_ you can't use COND here
because [gibbledygook] -- that's in AAL 1 as designed in Lab 1,
while in AAL 2 designed in Lab 2 OBVIOUSLY you must use COND here,
I thought you were HIRED because you had used lisp (I had, scheme
actually, but that was the favoured lisp of lab _3_ so mentioning
it in labs 1 or 2 made you an instant leper obviously).
No doubt "the solution" you proposed would have been to learn a
few of those GD macro systems and write the N-plus-1-th divergent
incompatible subdialect. Yeah right. I found a better one --
jump ship to IBM Research, get a raise, get to use a GOOD (for
the times, mind you -- still over 20 years ago) hardware design
language, have the fun of my life designing HW for a while until
I had to go back to SW -- and reconciling myself to the latter when
I found out it didn't HAVE to mean endlessly designing languages
for domains you didn't truly grasp with congeries of pieces of an
existing language and half-baked concoctions of your own -- you
COULD actually design good systems and algorithms, just like you
could with hardware, using SOLID, UNCHANGING (inside a project's
timeframe:-), _almost_-decently-designed-for-the-general-domain
languages [PLURAL!!!! *YES*!!!]. Admittedly, "almost". I tried
my hand at designing specialized languages (one of those sins
that just about everybody practices in youth, I guess) and found
out that, even when I grasped the application domain perfectly
well, that still didn't make my languages usable by other experts
of the domain (maybe because I kept falling onto prefix s-exproid
syntax in those years -- and just about everybody else hated it).
Instead of spreading misconceptions you should really start to get to
know the things better that you criticize.
Been there, done that, *NEVER, NEVER AGAIN*. Don't keep repeating
this claim, analogous to one that somebody who's lived and suffered
under a dictatorship shouldn't be spreading misconceptions but try
being a dictator to "know the things better that you criticize". I
don't want to foist my half-baked macro-based lisp dialects on
others any more than I'm going to suffer others foisting their own
on me, thankyouverymuch. If and when I should find myself working
on a solo project for which the need to tweak syntax within an
s-expr world appears, I may try some kind of lisp (hopefully, by
then, Graham's new baby -- if he's as good as the reverence every
lisper devotes him seems to indicate, then his claim that he can
make a lisp that's better than both scheme and CL while having the
strenths of both -- and then some -- should be credible).
But, until then -- bye. And now, to killfile this thread too....
Alex
On Mon, 20 Oct 2003 21:25:55 +0200, Pascal Costanza <co******@web.de> wrote: Alex Martelli wrote:
[...] ...you can't "just alter Python's own syntax with your own changes":
you have plenty of choices (implement your chosen semantics within
Python's syntax, use any of N available parsers to parse your favourite
syntax -- user EITHER "program generators" OR interpreters at any
level on the parsed forms -- etc, etc). You just don't have the one
choice of *altering Python's own syntax wholly within Python itself*.
Exactly. Lisp-style Macros make these things a breeze. The other
alternatives you suggest are considerably more complicated. As I have
said before, Lisp makes the simple things a little bit harder (-> syntax
for beginners), so that the hard things become considerably simpler (->
adding sophisticated abstractions in order to considerably reduce the
amount of code for complex tasks).
Describing a situation of having 99 available strategies rather than
100 as "doesn't give you a choice" can be charitably described as
"ridiculous", it seems to me.
I know about these choices, I have tried them all. I have written
compilers, interpreters, with and without parser generators, and have
co-designed and used transformation frameworks. These things are
considerably harder to build, and you need to spend a considerable
amount of time on the technology itself which distracts you from solving
the problem at hand. With Lisp-style macros, these things are much
simpler to handle once you have gotten it.
But _in practice, people don't_, except for play and experiments
of various kinds. You can find a bazillion extremely varied
extensions to Python of all imaginable kinds, *BUT* they're ALL
*add-ons*, NEVER alteration of syntax or fundamental semantics
You still have a wrong idea of how macros work. Macros are of course
also only add-ons. You don't alter unrelated syntax or unrelated
portions of source code, and you don't change fundamental semantics.
Instead of spreading misconceptions you should really start to get to
know the things better that you criticize.
Maybe we can put this thing to bed by a Python foreign-language-module-encapsulating class,
and a functionally equivalent lisp a macro for lispers, so we could write something like (sketch)
module_from_lisp = FLModule('lisp','lisp_file_path_or_remote_spec',
'interface spec string', 'make info string')
where the last args would have sensible defaults, but all would be expected to be passed
to a translation process selected by the language name (the first arg) unless a cached module
could be accessed without calling for any translation.
For C or C++ this could generate a DLL extension module and import that, assuming the
relevant tools are available. Otherwise an informative exception could be raised.
For other languages, a DLL that serves as an access proxy for whatever. Letting the source
be specified by a remote spec like an URL with some authentication requirement might open
some interesting uses (language name 'python' would be allowed ;-) (maybe even 'python1.5.2' ;-)
I know there are already pieces for integrating/accessing C, but the idea here is to
unify the concept into one standard general form expressed by a standard class which could
always have a presence in builtins.
Just an alpha idea at this point ;-)
Hm, think I'll switch the title, in case people aren't reading the old subject thread ;-)
Regards,
Bengt Richter
"Lulu of the Lotus-Eaters" <me***@gnosis.cx> wrote in message
news:ma*************************************@pytho n.org... Pascal Costanza <co******@web.de> wrote previously:
|Wouldn't it be better if everyone could contribute to the evolution of a
|language, and then let the community decide what the best approaches are?
I can think of almost nothing worse than this!
Well, "design-by-committee" results like XSLT are even worse. But the
"benevolent dictator" model is VASTLY better than the "let 1000 flowers
bloom" approach.
Incidentally, I have never seen--and expect never to see--some new
mysterious domain where Python is too limited because the designers did
not forsee the problem area. Nor similarly with other very high level
languages. It NEVER happens that you just cannot solve a problem
because of the lack of some novel syntax to do so... that's what
libraries are for.
Yours, Lulu...
Can't one make the same argument for Visual Basic. Use libraries as the
method to "build up the language" to a domain. Keep the language as simple
as possible and just use libraries - yeah, that's the ticket.
-R. Scott McIntire
--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.
David Steuber <da***********@verizon.net> writes: If even XEmacs is ported over to Common Lisp in my lifetime I will be
surprised. If it happens to GNU Emacs, surprise will not be enough
and I will have to resort to astonishment.
I'm not thinking of the core code. I'm thinking of all those *.el
files floating around the universe.
Plans have been to convert Emacs to use a Scheme dialect with hacks to
support old .el files.
Alex Martelli <al***@aleax.it> writes: Pascal Costanza wrote:
snip
What's "considerably more complicated" in, say,
my_frobazzer = frobaz_compiler('''
oh my pretty, my beauteous,
my own all my own special unique frambunctious *LANGUAGE*!!!
''')
and later on call my_frobazzed(bim. bum, bam) at need? The complexity
of the frobaz_compiler factory callable depends exclusively on the
complexity of the language you want it to parse and compile, and you
of course have total choice ("Python doesn't give you a choice" MY
LEFT FOOT) on how to apportion the work between the factory and the
__call__ method of the resulting my_frobazzer.
Just imagine if your embedded language also used white space to denote
program structure.. cut and paste would get a little more tricky...
|"Lulu of the Lotus-Eaters" <me***@gnosis.cx> wrote in message
|> It NEVER happens that you just cannot solve a problem
|> because of the lack of some novel syntax to do so... that's what
|> libraries are for.
"Scott McIntire" <mc******************@comcast.net> wrote previously:
|Can't one make the same argument for Visual Basic. Use libraries as the
|method to "build up the language" to a domain.
Sure, in a sense. But the problem(s) with VB are not that it cannot be
extended to some novel domain syntax because it lacks macros.
VB is a bad language, but it is JUST AS BAD in its "core" areas as it is
when extended to new problems. There is a very strong disanalogy with
Python here. Python does a good job of expressing all the basic
*programming* constructs that go into ANY programming domain: loops,
branches, collections, objects and inheritence, HOFs, declared
constraints, etc. I have no expectation of EVER seeing some new problem
area that isn't built out of these same application parts.
Once in a great while, something really new comes along in programming
constructs themselves. OOP was such a thing, HOFs were, multimethods
are at a smaller level, constraint declarations (i.e. logic programming)
were; maybe coroutines are. Python does all of these things well--see
some of my articles for explanations of some of them where the basic
syntax needs some straightforward (pure-Python) extension modules.
The ONLY example I can think of where a basic construct is difficult to
shoehorn into Python might be AOP. I remain agnostic about the staying
power of this one, but it might prove important. There are some modules
out there, and metaclasses let you do it (in a less than elegant way).
On the other hand, Lisp--macros and all--is not any better suited to AOP
than is Python. I know you can work up something that nominally
qualifies as AOP using obscenely brittle macros... but it's not
something I would want to do.
Yours, David...
--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.
In article <OiZkb.838841$uu5.148203@sccrnsc04>,
"Scott McIntire" <mc******************@comcast.net> wrote: "Lulu of the Lotus-Eaters" <me***@gnosis.cx> wrote in message
news:ma*************************************@pytho n.org...
.... Incidentally, I have never seen--and expect never to see--some new
mysterious domain where Python is too limited because the designers did
not forsee the problem area. Nor similarly with other very high level
languages. It NEVER happens that you just cannot solve a problem
because of the lack of some novel syntax to do so... that's what
libraries are for.
Can't one make the same argument for Visual Basic. Use libraries as the
method to "build up the language" to a domain. Keep the language as simple
as possible and just use libraries - yeah, that's the ticket.
Well - yes! I mean, I honestly don't know a thing about Visual
Basic, but I find no irony in this. Relatively humble language
is widely used thanks to rich library support - QED.
Now I'm sure Python programmers will mostly say that its core
language features are superior to Basic's and a move to that
language would be a big step backwards, and of course the same
will eventually apply to Python when a radically better language
arrives. But that's thanks to basic language design, not
incremental tinkering. As the man said, incremental tinkering
doesn't open the door to new application areas, it's just something
to keep the language designer busy so he doesn't get bored and
design a new language that competes with the old one.
Donn Cave, do**@u.washington.edu
Paul Rubin wrote:
David Steuber <da***********@verizon.net> writes: If even XEmacs is ported over to Common Lisp in my lifetime I will be
surprised. If it happens to GNU Emacs, surprise will not be enough
and I will have to resort to astonishment.
I'm not thinking of the core code. I'm thinking of all those *.el
files floating around the universe.
Plans have been to convert Emacs to use a Scheme dialect with hacks to
support old .el files.
I have seen a translator written in scheme to convert el files
to scheme automatcially. I don't know how good it is or whether
it's ready to go, but it was basically source-to-source
compilation using a chained series of thunks as the output.
And of course, there's an emacs-alike editor called 'edwin' that is
coded directly in scheme. I don't know whether it runs any .el
files, but I think that it doesn't.
Bear
Edi Weitz <ed*@agharta.de> wrote in message news:<87************@bird.agharta.de>...
[yada yada...] "If a million people say a foolish thing, it is still a foolish
thing."
(Anatol France)
Did you know that Anatole France had one of the smallest brains on
record? See for instance: http://www.sciencenetlinks.com/sci_update.cfm?DocID=166
search for 'anatole'
Slightly OT I guess, but these threads get boring fast.
ps on the topic -- any language that *requires* bloatware like Emacs
in order to use is already out of the running. I wrote my first large
Python program in Wordpad. da*******@yahoo.com (dan) writes: Edi Weitz <ed*@agharta.de> wrote in message news:<87************@bird.agharta.de>...
[yada yada...] "If a million people say a foolish thing, it is still a foolish
thing."
(Anatol France)
Did you know that Anatole France had one of the smallest brains on
record? See for instance:
http://www.sciencenetlinks.com/sci_update.cfm?DocID=166
search for 'anatole'
Slightly OT I guess, but these threads get boring fast.
ps on the topic -- any language that *requires* bloatware like Emacs
in order to use is already out of the running. I wrote my first large
Python program in Wordpad.
Jesus. Are you bragging about using a non-editor on a non-OS?
Calling Emacs "bloatware" when you're using Windows seems more
than a little bit silly.
--
Raymond Wiker Mail: Ra***********@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker <Ra***********@fast.no> writes: da*******@yahoo.com (dan) writes:
Did you know that Anatole France had one of the smallest brains on
record?
Oh *hell* no. Phrenetics?!?! That pretty much disqualifies anyone
within two degrees of you from being taken seriously.
Jesus. Are you bragging about using a non-editor on a non-OS?
This fool was talking about nonsense that's been discredited for 80
years, and 20 years in the popular press (cf. The Mismeasure of Man).
I wouldn't be surprised if it was bragging that 2 + 2 = -17.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <fb**************************@posting.google.com >, da*******@yahoo.com (dan) wrote: ps on the topic -- any language that *requires* bloatware like Emacs
in order to use is already out of the running. I wrote my first large
Python program in Wordpad.
~bruce$ ls -l `which emacs`
-rwxr-xr-x 1 root wheel 4596224 Sep 24 04:29 /usr/bin/emacs
~bruce$ ls -l /Applications/Microsoft\ Office\ X/Microsoft\ Word
-rwxr-xr-x 1 bruce admin 10568066 Sep 26 2002
/Applications/Microsoft Office X/Microsoft Word
Uhh, dude ... emacs is less than half the size of Word...
Sorry, don't have Wordpad on this Mac.
And don't bother to quote me the size of Wordpad on W2k or XP ... most
of it is built into the operating system, just as IE and WMP and the
rest of them are.
-- Bruce tf*@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes: Raymond Wiker <Ra***********@fast.no> writes:
da*******@yahoo.com (dan) writes:
> Did you know that Anatole France had one of the smallest brains on
> record?
Oh *hell* no. Phrenetics?!?! That pretty much disqualifies anyone
within two degrees of you from being taken seriously.
Jesus. Are you bragging about using a non-editor on a non-OS?
This fool was talking about nonsense that's been discredited for 80
years, and 20 years in the popular press (cf. The Mismeasure of Man).
I wouldn't be surprised if it was bragging that 2 + 2 = -17.
Maybe we should all chip in and book him a session at a good
retrophrenologist's?[1]
Footnotes:
[1] See http://shorty.wz.cz/download/pratche...rms.htm#_ftn15[2]
[2] Better yet, but the book.
--
Raymond Wiker Mail: Ra***********@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Bruce Hoult <br***@hoult.org> writes: Sorry, don't have Wordpad on this Mac.
It's pretty small, a little smaller than vi, actually:
ev@liten:~$ ls -l /mnt/vfat/Program\ Files/Accessories/WORDPAD.EXE
-rwxrwxr-x 1 ev ev 204800 Apr 23 1999 /mnt/vfat/Program Files/
Most needles are also small. That doesn't make them suitable as
chopsticks.
--
(espen)
David Mertz wrote: Python does a good job of expressing all the basic
*programming* constructs that go into ANY programming domain: loops,
branches, collections, objects and inheritence, HOFs, declared
constraints, etc. I have no expectation of EVER seeing some new problem
area that isn't built out of these same application parts.
How do you justify your expectation? What's the rationale?
Pascal
In article <fb**************************@posting.google.com >, da*******@yahoo.com (dan) wrote: ps on the topic -- any language that *requires* bloatware like Emacs
in order to use is already out of the running. I wrote my first large
Python program in Wordpad.
Good point! I always thought that Python's popularity stems from
that special property of the language. It relieves the vendors
from writing special editors for the language and shift the burden
to the user. Particularly attractive for embedding it as a
scripting language for an application.
However I don't agree that CL requires bloatware as big as
Emacs. You need only a small portion of Emacs for lisp editing.
Still it is going to be much more work than writing a WordPad
though.
dan writes: ps on the topic -- any language that *requires* bloatware like Emacs
in order to use is already out of the running. I wrote my first large
Python program in Wordpad.
No big deal: all text editors are ex-complete.
Paolo
--
Paolo Amoroso <am*****@mclink.it> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: RobertMaas |
last post by:
After many years of using LISP, I'm taking a class in Java and finding
the two roughly comparable in some ways and very different in other
ways. Each has a decent size library of useful utilities...
|
by: mike420 |
last post by:
I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro...
|
by: nobody |
last post by:
This article is posted at the request of C.W. Yang who
asked me to detail my opinion of Lisp, and for the benefit
of people like him, who may find themselves intrigued by
this language.
The...
|
by: nobody |
last post by:
Howdy, Mike!
mikecoxlinux@yahoo.com (Mike Cox) wrote in message news:<3d6111f1.0402271647.c20aea3@posting.google.com>...
> I'm a C++ programmer, and have to use lisp because I want to use
>...
|
by: Mark Tarver |
last post by:
How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?
Note I'm not a Python person and I have no axes to grind here. This is
just a question for...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
