mystilleef wrote:
Bill Atkins wrote:
>>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.
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. :)
>
>>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.
Hopefully, because any sizeable app will have its sum functionality
compartmentaliz ed 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 incomprehensibl e). 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? :)
>>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.
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. :)
>
>>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.
<cough>
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
misrepresentati on 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
