Comparing Lisp to Python, what you consider more important:speed or macros.
in [Lisp]
|
Prev: need help implementing hooks in Common lisp
Next: Comparing Lisp to Python, what you consider more important:speed or macros.
From: His kennyness on 3 May 2010 10:24 Captain Obvious wrote: > Hk> Um, if you think macros are hard, you don't know Lisp. By definition. > > If you had some programming experience, you'd know (I'm trying to play > same game, you see? Do you find it funny?) You told it wrong. > that _sometimes_ writing > macros might take quite a lot of effort. Ah, I see where you are coming from. Yes, in the beginning such macros can be hard, but only because in our inexperience we make them hard. It is like underestimating an opponent -- we make them tougher than they are /by/ underestimating. With experience one does indeed learn to slow down and think carefully about runtime vs macroexpansion time. One also learns to divide and conquer, achieving the macro expansion with structured code, the way we write any other code, so he can develop and debug in reasonable bites. One also learns to use embedded print statements, again debugging macro code like any other code (the beauty of Lisp macros being that it /is/ like any other code, which is also why they are so easy to write). You'll know you are ready to leave the temple (and that you have been doing too much programming) when one day you write a truly interesting macro (not that trivial binding thing below) over the keyboard and it Just Works(tm) the first time. At that point I recommend bartending school. > I'm not saying that macros are _too hard_. They are just (relatively) > harder than writing an average code. I don't know, maybe it should be > that way, or maybe not. Well then don't say "macros are hard"! Where's my Strunk & White when i need it?! kt > > From my experience: > * writing code is usually easy. I can just say "I need a function that > does this and this" and then write it in a few minutes, and usually it > just works without debugging. > * writing macros which help to get rid of boilerplate code is usually > easy. It is almost a mechanical process, might just need to throw in > some "rebinding" thing. > * writing special purpose macros might be tricky, but I think manageably > tricky. > * writing macro-writing macros is goddamn hard. I need to think a lot > about each line. It never works right from the first time, it needs > trial-and-error process. > > One think is not like others, don't you think so? It can be possible > that macro-writing macros are inherently complex, but my gut feeling > says otherwise. > Essentially, it is just same process of getting rid of boilerplate code. > So I think there might be some better abstractions for this. > > IMHO general macros (where you need a full power of CL code to make an > expansion) are rarely needed. A lot of macros are just backquote > templates with little code fragments which do interesting things. Can we > make nested backquote templates more manageable? I think we can. > > And, one more thing -- there is a widely known rebinding macro: > > (defmacro rebinding (bindings &body body) > (loop > for binding in bindings > for var = (if (consp binding) (car binding) binding) > for name = (gensym) > collect `(,name ,var) into renames > collect ``(,,var ,,name) into temps > finally (return `(let ,renames > (with-unique-names ,bindings > `(let (,,@temps) > ,,@body)))))) > > How long it would take to understand what it does from the code alone? > > There is a description here: > http://groups.google.com/group/comp.lang.lisp/msg/fc60bfa60b99cdd0 > > but I think even with a description it isn't easy to understand, only > usage examples help. |