merits of Lisp vs Python

[Bill Atkins]

With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful." then, no doubt, we'd take you guys more
seriously. But we don't hear that -- we hear Lispers going on and on about

And, of course, we do say that. Nobody wants people running around
writing incomprehensible macros. How does that help anyone?
Fortunately, it's not a problem in practice, because most macros map
quite straightforwardly to Lisp constructs and almost no one has the
time or the intelligence to write the mini-languages that seem to be
terrifying you so much.

how great it is that they can easily redefine every corner of the
language. Do you blame people for *believing them* and imagining that
reading Lisp code is like following some ghostly will-o-the-wisp across a
swamp, where nothing is what it seems and the landscape is forever
shifting?

"every corner of the language"? Please. Why are you so post-happy
when it's quite obvious that you don't know enough about Lisp to
attack it?

Most programmers do not write macros that are incredibly difficult to
understand. Beginners might, but beginners might also write
incomprehensible code in Java or Python. As you learn Lisp, you learn
to keep your macros tied to the underlying Lisp. You learn to make
the expansions into function or method defintions, instead of
reinventing the wheel. You leverage what Lisp offers, instead of
redefining it.

The only times you are really going to find completely alien semantics
are in textbooks (like Prolog in Lisp), in very ambitious and large
projects where the new semantics are the only reason you'd use the
code in the first place (like Franz's AllegroProlog or Marco
Baringer's CPS transformer), or in code written by beginners. Please
stop spreading FUD about this. In real life, macros make coding more
pleasant and make your code more maintainable. They are something to
embrace, not something to fear.

To provide a more solid example, Peter Seibel's book _Practical Common
Lisp_ (full text at http://www.gigamonkeys.com/book) provides a set of
classes for parsing binary files. Some user code provided in the
book:

(define-binary-class id3v2.3-tag (id3-tag)
((extended-header-size (optional :type 'u4 :if (extended-p flags)))
(extra-flags (optional :type 'u2 :if (extended-p flags)))
(padding-size (optional :type 'u4 :if (extended-p flags)))
(crc (optional :type 'u4 :if (crc-p flags extra-flags)))
(frames (id3-frames :tag-size size :frame-type 'id3v2.3-frame))))

This code very closely mirrors the standard DEFCLASS in Common Lisp,
so a maintainer knows right away what to expect. The macro expands
into DEFCLASS and DEFMETHOD forms. There's nothing mysterious going
on here; the macro is just a friendlier syntax for expressing an idea.
What I get from this are methods that read binary data into objects of
the class that I've just defined (*). That's all - methods and a
class. There is no mind-bending going on at all here. It's true of
course that I have to understand how the macro works. But without it,
I'd have to write and/or read through a lot of similar-looking code
for handling binary data. Which would you prefer?

Without a macro like this, the code required would be the definition
of boilerplate. Instead of specifying declaratively the order and
type of fields in the binary file, I would write code to read each
field from the file and then store the result in an object. I'd also
have to take into account fields that are optional. This is ugly and
boring code. Did I mention that DEFINE-BINARY-CLASS also defines
methods to save these objects back to binary files? Because it does.

So why not write this code once and then take advantage of it in the
future to get more expressive, less boring programs?



* If you don't believe me, here is the expansion of the code I cited above:

http://paste.lisp.org/display/31799

Just methods and a class.

 

[Bill Atkins]

"every corner of the language"? Please. Why are you so post-happy
when it's quite obvious that you don't know enough about Lisp to
attack it?

In addition to macros that define classes or methods, a common macro
is the WITH-* macro, which sets up some kind of context, runs the body
inside that context, and then does some cleanup.

For example, my Lisp vendor, LispWorks, provides the macro MP:WITH-LOCK :

(mp:with-lock (*the-big-lock*)
(do-something-atomic)
(something-else)
(almost-odone))

The generated first seizes a process lock called *THE-BIG-LOCK*, runs
the code in the body and then releases the lock. I never have to
worry that I've taken a lock without releasing it, because LispWorks
has encoded that behaviour into MP:WITH-LOCK (and if they handn't,
this macro is trivial to write).

Now I can tell if I'm keeping a lock around too long because all the
code that appears inside this WITH-LOCK is all the code that I'm
locking. Further, the generated code is surrounded by an
UNWIND-PROTECT, which means that if an error is raised or anything
abnormal happens in the dynamic scope of the UNWIND-PROTECT, Lisp will
run cleanup code as it flees back up the stack. So if there is an
error in my code, it does not prevent other processes from seizing
that lock, because it will be released as the error is signaled.

Here is the expansion:

CL-USER 7 > (write (macroexpand '(mp:with-lock (*the-big-lock*)
(do-something-atomic)
(something-else)
(almost-odone)))
retty t :case :downcase)
(let ((#:g17553 *the-big-lock*))
(when (mprocess-lock #:g17553)
(unwind-protect
(progn (do-something-atomic) (something-else) (almost-odone))
(mp::in-process-unlock #:g17553))))

 

[Kirk Sluder]

1). More and better mature standard libraries (Languages don't matter,
libraries do). .....
On Lisp Macros:

I think they are overrated, and in general cause more harm than good.
It's the reason I find Lisp-like programs difficult to grok, maintain
and extend. Cos every smart ass wants to needlessly write his own mini
language to the point of absolute obfuscation. Naturally, I'm supposed
to be awed by his mischievous cleverness.

I've not seen a convincing explanation as to why imported macros
from some library are so much more evil than imported functions. In
both cases one might have to dig into documentation and/or comments
to understand exactly what that imported snippit is doing.

 

[Pascal Bourguignon]

I've not seen a convincing explanation as to why imported macros
from some library are so much more evil than imported functions. In
both cases one might have to dig into documentation and/or comments
to understand exactly what that imported snippit is doing.

And the difference with a library function is?

(defpackage "LIBRARY" export "THIS-IS-A-FUNCTION"))

(library:this-is-a-function ???) ; ???

 

[Ken Tilton]

And the difference with a library function is?

Uh, that was his point.

And if you all dig back thru this thread you will find me quoting GvR on
the difference, which is (paraphrasing) "with macros you do not even
know where the function calls are". I think he is talking about a
loop-like erection of a new language.

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

I think that people who know more languages and more about programming will

be much more inclined to use Lisp than Python. Look at the contents of the
newsgroups for example, c.l.l has a thread on memoization whereas c.l.p has
a thread about wrestling oiled pigs.

Practicality beats purity.

 

[mystilleef]

Are any of these not subjective?

Objectivity is in the eye of the beholder.

Lisp is much more than a functional language.

Maybe so. But I've only ever appreciated its functional aspects. I
wouldn't choose Lisp or its derivatives for OO related tasks even if
I'm high.

Uh huh. Can you cite examples of this? Sounds like you're just
making stuff up here. Contrary to popular belief, writing a Lisp
macro that warps your mind and introduces a totally un-CL-like
semantics is extremely difficult. Most of the people who are good
enough at CL to do it (I'm certainly not one of them) are also
experienced enough to know when it's the right choice.

Any sizable Lisp applications will make extensive use of macros. Emacs
and magic ( the web framework) come to mind. My experience has shown
that nobody but the person who writes the DSL extension can maintain
their code. The benefits of extending a language in a domain specific
manner are exaggerated. My observation is that macros are important to
Lisp and it's derivative because they lack libraries to begin with.
Common problems solved using macros in Lisp and friends are solved
using specialized libraries in most other languages. And I like the
specialized libraries route. Meta-programming just doesn't tickle my
fancy. It just spells maintainance nightmare.

And Lisp environments all support getting the macroexpansion,
documentation, and source of any unfamiliar macro you might happen
upon, so really this is not as much of a problem as you might
fantasize it to be.

How's this a good thing? I don't need a Python environment to grok
Python code.

I don't agree with a lot of what you say in this paragraph, but I
you're right that libraries are crucial. That's why I wish there were
more people writing Lisp libraries instead of being scared away by
sheer fabrications like the stuff that's appearing in this thread.

People only contribute to things they understand and appreciate. More
people would be writing Lisp libraries if it was worthwhile.
Apparently, it doesn't seem to be. A few years ago, I tried to write an
editor is Scheme. The experience was appalling. I was able to write a
fully functional prototype editor in less than a week in Python.
Shockingly, at the time, I had no experience in Python. Guess which
community I was inclined to contribute to afterwards. I hear stories
similar to mine time and again, yet the Lisp community won't take heed.
They'd rather squeal about the superiority of macros and whine about
their frustrations in Python news groups.

 

[Robert Brown]

For a long time Scheme had no macros, and Scheme developers who were
exceedingly familiar with Common Lisp were nonetheless willing to get
by without them. So I have to think macros aren't all THAT important.
Scheme did eventually get macros, but somewhat different from CL's.

Macros are important enough that all the old Scheme implementations I used
offered macros in the style of Lisp's defmacro. Lisp hackers did not have
to suffer without them when writing Scheme code.

Relatively recently, the Scheme standard was augmented with hygenic macros,
a different beast. Scheme standardizes something only when there's nearly
universal support for it, so features appear in the language standard very
slowly.

bob

 

[Kirk Sluder]

Now, if you want to tell me that, despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions, then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?

Well, as a user of both lisp and python, it seems to me that python
programs can create their own domain-specific mini-languages using
mechanisms such as objects, classes and functions. It's quite
possible to mask the bare-bones python behind functions and objects
derived from imported libraries, which themselves might not be
python-native. And extreme advocates of functional programming
raise the same arguments about objects: they create obfuscated
constructs that are difficult to read and understand without
unpacking their internals. The questions could be asked, why do you
need objects if you are just using them as containers for functions?
Why not just use functions?

Python already is very explicit about supporting OOP, a paradigm
that bundles functions and data into larger constructs. So why is it
that many of these debates center around macros, which is another
paradigm that bundles functions and data into larger constructs?
Both objects and macros have IMO similar potential for abuse and
obfuscation.

But to answer your question, I use a macro when I have a problem
that can't be easily reduced to a naive function. I also use object
classes when I have a problem that can't be easily reduced to a
simple data type. When I don't need an macro or an object class, I
just use naive functions and simple data types.

 

[Wade Humeniuk]

People only contribute to things they understand and appreciate. More
people would be writing Lisp libraries if it was worthwhile.
Apparently, it doesn't seem to be. A few years ago, I tried to write an
editor is Scheme. The experience was appalling. I was able to write a
fully functional prototype editor in less than a week in Python.
Shockingly, at the time, I had no experience in Python. Guess which
community I was inclined to contribute to afterwards. I hear stories
similar to mine time and again, yet the Lisp community won't take heed.
They'd rather squeal about the superiority of macros and whine about
their frustrations in Python news groups.

Hmm.. Here is my first prototype in Lisp. It took 20 seconds
to write.

(defun display-editor ()
(capi:contain (make-instance 'capi:editor-pane)))

CL-USER 1 > (display-editor)
#<CAPI:EDITOR-PANE 2069F40C>

CL-USER 2 >


W

 

[John Thingstad]

Objectivity is in the eye of the beholder.


Maybe so. But I've only ever appreciated its functional aspects. I
wouldn't choose Lisp or its derivatives for OO related tasks even if
I'm high.

You are just being silly.
Lisp's OO environment CLOS is vastly superior to Python classes.
Both in terms of expressive power and flexibility.
You might even find out if you ever learnt how to use it.

Lisp also supports procedural programming just fine.

In the windows world the best way to access system libraries are
via .NET. Thus each language inventing it's own libraries is quickly
becoming
a thing of the past. Also you can mix and match languages according to
need.
Python is fine if you approach programming as Lego, simply gluing together
libraries.
But if you want to do some serious algorithmic's you may find that it is
just to slow.

 

[Chris Parker]

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 my general education.

Mark

They are both a lot of fun.

Python is a clean, focused language that never was designed to replace
every programming language out there or solve all of the world's
problems.

Lisp is an entire world in itself.

 

[Bill Atkins]

Objectivity is in the eye of the beholder.

Well, for example, "Lisp uses a fully-parenthesized notation for
writing programs" and "Python has significant whitespace" are both
objective facts. Agreed? There's nothing subjective about those two
facts. Do any of your points approach that level of objectivity?

Maybe so. But I've only ever appreciated its functional aspects. I
wouldn't choose Lisp or its derivatives for OO related tasks even if
I'm high.

Ah yes. Glad you went into so much detail.

Any sizable Lisp applications will make extensive use of macros. Emacs
and magic ( the web framework) come to mind. My experience has shown
that nobody but the person who writes the DSL extension can maintain
their code.

What experience is this?

The benefits of extending a language in a domain specific
manner are exaggerated.

Great, it's settled then!

(Look elsewhere in this thread for my post about Peter Seibel's
DEFINE-BINARY-CLASS macro.)

My observation is that macros are important to
Lisp and it's derivative because they lack libraries to begin with.
Common problems solved using macros in Lisp and friends are solved
using specialized libraries in most other languages. And I like the

Macros are not a substitute for libraries, nor are libraries a
substitute for macros. Having macros lets you build more powerful and
more expressive libraries.

specialized libraries route. Meta-programming just doesn't tickle my
fancy. It just spells maintainance nightmare.

So it's not just macros but metaprogramming as a whole that bothers
you? You must have an enjoyable time writing programs.

How's this a good thing? I don't need a Python environment to grok
Python code.

Nor do you need it to grok Lisp code. The environment is there to
make your life better. I was merely responding to your original claim
that it's impossible to make sense of code that uses macros.

People only contribute to things they understand and appreciate. More
people would be writing Lisp libraries if it was worthwhile.
Apparently, it doesn't seem to be. A few years ago, I tried to write an
editor is Scheme. The experience was appalling. I was able to write a
fully functional prototype editor in less than a week in Python.
Shockingly, at the time, I had no experience in Python. Guess which
community I was inclined to contribute to afterwards. I hear stories
similar to mine time and again, yet the Lisp community won't take heed.
They'd rather squeal about the superiority of macros and whine about
their frustrations in Python news groups.

Hmm. Anecdotal evidence about Scheme (a vastly and fundamentally
different language from Common Lisp). Again, you've clinched it for
me.

I do believe that the "squealing and whining about macros" was a
response to Pythonistas claiming that macros are not useful. This was
in turn in response to a foolishly (trollishly?) cross-posted
question. It is not as if we have invaded your newsgroup.

 

[mystilleef]

You are just being silly.
Lisp's OO environment CLOS is vastly superior to Python classes.
Both in terms of expressive power and flexibility.
You might even find out if you ever learnt how to use it.

Donkeys have wings.

In the windows world the best way to access system libraries are
via .NET. Thus each language inventing it's own libraries is quickly
becoming

You're only proving my point. Why do you think most windows developers
use .NET?

Python is fine if you approach programming as Lego, simply gluing together
libraries.

You mean it's fine for what 90% of programmers do?

But if you want to do some serious algorithmic's you may find that it is
just to slow.

Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
sure.

 

[Kaz Kylheku]

But Lisp's syntax is so unlike most written natural languages that that it
is a whole different story.
Bahaha!

Yes, the human brain is amazingly flexible,
and people can learn extremely complex syntax and grammars (especially if
they start young enough) so I'm not surprised that there are thousands,
maybe tens or even hundreds of thousands of Lisp developers who find the
language perfectly readable.

1> '(especially if they start young enough)
(ESPECIALLY IF THEY START YOUNG ENOUGH)
2> (sixth *)
ENOUGH

.... said!

Yeah, so /unlike/ written natural languages!

What a fucking moron.

 

[Kirk Sluder]

And the difference with a library function is?

(defpackage "LIBRARY" export "THIS-IS-A-FUNCTION"))

(library:this-is-a-function ???) ; ???

Well, my argument is that there is little difference. Functions,
objects and macros all redefine some aspect of the system's
language, and all of them can be vulnerable to obfuscation or
unnecessary abstraction. The question I have is why do critics
single out macros and not other forms of abstraction such as
objects, packages, libraries, and functions?

just as an example:
from foolib import *
bar.bar("somefile")

What does this program do? I have no idea. Its functionality is
hidden behind multiple layers of abstraction (function, object,
library.)

 

[Ken Tilton]

Objectivity is in the eye of the beholder.




Maybe so. But I've only ever appreciated its functional aspects. I
wouldn't choose Lisp or its derivatives for OO related tasks even if
I'm high.

But CLOS is the best OO there is. The OMG said so. It can do anything
any other OO can do. Why /specifically/ would you not use it? This type
of thread has no educational value unless one is specific; we already
know what the posters like and prefer, so the only added value comes
from being specific about language details. And funny put-downs.

Any sizable Lisp applications will make extensive use of macros.

Hopefully, because any sizeable app will have its sum functionality
compartmentalized into internal little sub-APIs. These five/ten data
structures and functions have been created to handle this recurring
problem faced by higher-order functions. Sometimes dealing with that API
requires boilerplate code to be written. Set things up. Make a call.
Check the return status for xyz. etc etc. That boilerplate can become a
macro, such as WITHOUT-C-DEPENDENCY:

(defmacro without-c-dependency (&body body)
`(let (*call-stack*) ,@body))

*CALL-STACK* is internal to Cells and should not be exposed. It is cool
that all I need do to defeat the entire Cells engine is bind one special
variable, but maybe someday that will get hairier. if so, no problem, I
just change the macro. Btw, without special variables, you would need:

(let ((save-stack *call-stack*)
(setf *call-stack* nil)
<your code here, possibly trapping errors>
(setf *call-stack* save-stack))

If you want to use a function instead of a macro and still hide the
boilerplate, it would have to be:

(without-c-dependency (lambda () <your-code-here>))

Not the end of the world and at least one Lisp legend thinks that makes
macros unnecessary.

Emacs
and magic ( the web framework) come to mind. My experience has shown
that nobody but the person who writes the DSL extension can maintain
their code.

You and GvR are thinking of the case where a macro is used to create a
whole new syntax, like LOOP (a mildly controversial part of standard
Lisp). I have written more macros than you can imagine and only once
even came close to it (but the language was just a list of things to do,
nothing incomprehensible). I have never seen a macro which introduced a
new language.

Of course, we all keep saying this and you all keep repeating the
opposite, so we do appreciate the excuse to repeatedly explain how
macros are really used.

The benefits of extending a language in a domain specific
manner are exaggerated.

Careful, there are laws now against cruelty to straw men.

My observation is that macros are important to
Lisp and it's derivative because they lack libraries to begin with.

Damn! Exactly which macro would have saved me creating bindings to
OpenGL? (I think you have a little category error going here.)

Common problems solved using macros in Lisp and friends are solved
using specialized libraries in most other languages.

Damn! Exactly which macro would have saved me creating bindings to
OpenGL? (I think you have a little category error going here.)

And I like the
specialized libraries route.

Damn! Exactly which macro would have saved me creating bindings to
OpenGL? (I think you have a little category error going here.)

Meta-programming just doesn't tickle my
fancy. It just spells maintainance nightmare.

The whole idea of meta-programming is reducing coding and simplifying
maintenance, so I have to wonder how much experience you have writing
macros. Could you post a few?

Macros come into play when we find a pattern in out code that is a level
more abstract than straight token replacement (ala C) will support. My
simple example above is just about avoiding typing LAMBDA, which I hate.
More interesting macros take a look at the input source to the acro
invocation and, instead of subsituting in a fixed template as does the C
preprocessor, actively assembles template bits and input bits to produce
the final result.

Of course one has to be clever enough to see higher-order patterns and
appreciate the vast productivity increase available in return for the
effort of thinking through a macro -- well, i should note that often I
do not create the macro until I see also that this bit of internal API
will be coming up often enough (or will be changing often enough as I
come to understand it) to make the effort of carving out a macro
worthwhile -- or, yes, the point of macros will be lost on you.

That's OK. I once knew a guy who cut and pasted code to create tens of
duplicates rather than create a function. He was not stupid, but clearly
there was something wrong upstairs. I think to him it was somehow
"simpler" than getting involved with these complicated function things.

Sound familiar?

How's this a good thing? I don't need a Python environment to grok
Python code.

How would that be a bad thing? Do you do a lot of programming without a
Python environment. But I love the wall of flak you are throwing up.

People only contribute to things they understand and appreciate.

More
people would be writing Lisp libraries if it was worthwhile.

We are, now that a few application programmers have landed on her
shores. Most Lispniks are just useless groupie wannabes coding Java all
day to pay the bills with no energy for programming when they get home.

Apparently, it doesn't seem to be. A few years ago, I tried to write an
editor is Scheme. The experience was appalling.

Damn. I wish this was the quarterly Lisp vs Scheme flamewar.

I was able to write a
fully functional prototype editor in less than a week in Python.
Shockingly, at the time, I had no experience in Python. Guess which
community I was inclined to contribute to afterwards. I hear stories
similar to mine time and again, yet the Lisp community won't take heed.
They'd rather squeal about the superiority of macros and whine about
their frustrations in Python news groups.

You seem to be the unhappy one. We are just here correcting FUD. We are
ecstatic with Lisp and would not want anyone to miss out on it because
of your misnformation. No one cares if you try it and decide against or
do not try it based on good information.

But for someone to miss out on Lisp because of your deliberate
misrepresentation would be a shame.

ken


--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[Eric Pederson]

am afraid you need numbers, not word games.

You seem awfully hostile, by the way. Won't that make it harder to
conduct an intelligent exchange of value to lurkers?

programming, started learning it and then gave up because they could not
handle the syntax.

Uh. Clearly no one would be dumb enough to admit it in front of the
entire usenet world, right?

- Mr. NoOne


P.S. I am still going to get back to it when I get some time, really.
LISP seems intriguing and superior, almost a magical Rubik's cube
waiting for me. I just stumbled across Python in the meantime and code
started flowing - I got distracted. I have CL (& Scheme) on all my
machines awaiting my focus.... I'll join the flock any day now.
I've just been busy. There is a cost to learning and I've not had the
spare change to date.

But New Years resolutions need to be made: I could get up a couple
hours early and spend some quality time with CL, do a daily hour jog,
and eat a really heathly breakfast. Writing myself a note on this.


P.P.S. Undoubtedly not learning a syntax either means not enough time
was put in or the student lacked proper intelligence. This will always
bias the significance of learning syntax as a factor in choice of
language to be under reported. cheers

 

[Carl Banks]

Okay, since everyone ignored the FAQ, I guess I can too... [snip]
What Python has is stupid slogans
("It fits your brain." "Only one way to do things.") and an infinite
community of flies that, for some inexplicable reason, believe these
stupid slogns.

IOW, you posted the FAQ so you could appear to have highest moral
ground, then you ignore your own advice and promptly head to the very
lowest ground with ad hominem insults.

You're right, in part: My implicitly linking Python's pros or cons with
its stupid marketing hype is, I think, an ad hominem argument.

Ahem. Calling Python programmers "flies".

But I
don't see a moral issue here; the purpose of posting the FAQ was merely
to try to stop the fight. It failed.

GMAB. If you were really interested in not fighting you would have
shut up.

Regardless, there was some content in my post which you have not
addressed:

To wit:

1. Lisp is the only industrial strength language with pure
compositionality, and that this makes it suprior to Python. We don't
have to debate this because it's being debated elsewhere in this
thread.

2. Ruby, which is closer to Lisp than Python, is beginning to eat
Python's lunch. We don't have to debate this either because George has
kindly gave support to it through posting a survey that made this point
quite nicely; Thanks, George!

BTW, for the record, I don't have anything particularly against Python
aside from its stupid marketing hype and a bit of jealousy over those
flies building libraries which I wish we had in Lisp. I've made the
choice uncountable times between PERL, Python, and Tcl when I didn't
have Lisp as an option, and I have always chosen Python in these cases,
even though I can program in any of these. (Although I'm probably going
to start using Ruby instead of Python in these cases, but I'm not
really expert in it yet.)

(Actually, in many cases I can get away with Emacs keyboard macros
where others would program in PERL or Python, although not always.)

Whatever, fanboy.



Carl Banks

 

[John Thingstad]

Donkeys have wings.

? You attitude towards CLOS is obviously insane.

You're only proving my point. Why do you think most windows developers
use .NET?

Lisp can also use .NET. .NET =/= C#

You mean it's fine for what 90% of programmers do?

Yes CRUD (Create, Read Update, Delete)..
Sure you can do that in any languge..
Not sure I would call it programming.

Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
sure.

Even then..