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 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? :) >>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 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 -- http://mail.python.org/mailman/listinfo/python-list