Re: A difficult Metaphor for Macros (especially for Java people)
On Sep 9, 5:06 pm, alux alu...@googlemail.com wrote: But, @Luc pushing the advantage of Lisp macros to the forefront is not obvious if the audience cannot compare with another (good/simple) implementation they understand well. Thats why I want to use a nifty metaphor ;-) Even your dumbest Java developer knows that javac (or ant, or maven, or Eclipse, or *something*) converts their source to JVM byte code. Finding a familiar example is not hard. Compilers might not be a perfect example perhaps because maybe people think of compilers as big, complicated, high magic. But, clearly, they don't have to be. Any rewriting system should be a suitable analogy. As I said before, the macro concept should be as plain as the nose on your face. As other people have said, the cool part is that lisp macros are written in lisp and integrate with the compiler/interpreter in a cool way. That can only be internalized (grokked) by writing your own macros and reading good examples. How do you force someone to do that? You make it part of some other goal they are trying to achieve. Right? Why did you study semi- conductor physics? Because you had to before they'd let you do transistors, before they'd let you do logic gates, before they'd let you do microprocessors, before they'd let you do assembly, before they'd let you do C, before they'd let you do algorithms, before they'd let you do AI. Which is all you ever *really* wanted to do in the first place! Adam -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Adam Burry abu...@gmail.com wrote .. On Sep 9, 5:06 pm, alux alu...@googlemail.com wrote: But, @Luc pushing the advantage of Lisp macros to the forefront is not obvious if the audience cannot compare with another (good/simple) implementation they understand well. Thats why I want to use a nifty metaphor ;-) Even your dumbest Java developer knows that javac (or ant, or maven, or Eclipse, or *something*) converts their source to JVM byte code. Finding a familiar example is not hard. ??? converting to byte code (machine instructions) has nothing to do with macro processing... Macros can stand by themselves without being embedded in a compiler (m4, ...) Or perhaps I miss understood your statement ? Luc P. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On Sep 10, 1:10 pm, lprefonta...@softaddicts.ca wrote: Adam Burry abu...@gmail.com wrote .. On Sep 9, 5:06 pm, alux alu...@googlemail.com wrote: But, @Luc pushing the advantage of Lisp macros to the forefront is not obvious if the audience cannot compare with another (good/simple) implementation they understand well. Thats why I want to use a nifty metaphor ;-) Even your dumbest Java developer knows that javac (or ant, or maven, or Eclipse, or *something*) converts their source to JVM byte code. Finding a familiar example is not hard. ??? converting to byte code (machine instructions) has nothing to do with macro processing... Macros can stand by themselves without being embedded in a compiler (m4, ...) Or perhaps I miss understood your statement ? It has everything to do with macro processing. Macros convert one expression into another. For example, depending on how your lisp is set up: (cond (case1 action1) (case2 action2) (case3 action3)) can map to: (if case1 action1 (if case2 action2 (if case3 action3 'nil))) What do you think the compiler does? Recall, the OP said: How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? Well, Java is data to javac. Adam -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava patrickli_2...@hotmail.com wrote: I found the easiest way to introduce macros is just to introduce them as small syntactic sugaring. For example, getting rid of the explicit (fn [] ...) for macros like (with-open file ...). Interesting. I don't see any real difference between macros and C preprocessor stuff and C++ templates at a conceptual level. I think Clojure macros are much cleaner, but essentially they are similar. So in the Java world, generics (templates) are not yet widely used outside the libraries and maybe that's why Java devs find macros hard to comprehend? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hello, 2010/9/9 Sean Corfield seancorfi...@gmail.com: On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava patrickli_2...@hotmail.com wrote: I found the easiest way to introduce macros is just to introduce them as small syntactic sugaring. For example, getting rid of the explicit (fn [] ...) for macros like (with-open file ...). Interesting. I don't see any real difference between macros and C preprocessor stuff and C++ templates at a conceptual level. I think Clojure macros are much cleaner, but essentially they are similar. So in the Java world, generics (templates) are not yet widely used outside the libraries and maybe that's why Java devs find macros hard to comprehend? I think that even at the conceptual level, the differences are big: a. C/C++ is a pre-processor. It does a first pass on the code. Only at the end is the C/C++ compiler invoked. In Lisps, there is still this first pass/second pass thing, but it's at a waay finer granularity level: the top level form. At the end of the evaluation of each top level form, a new macro may have been defined and can be called immediately by the next top level form. So not only is the set of macros not closed in Lisp (and in C/C++, to some extent, it's also not closed, even if rather limited), but it can be expanded during the compilation of the program. b. The second major difference is that you stay in the same language for writing macros or non macros code in Lisp, whereas you have a preprocessor language with very limited possibilities in C/C++. Same language in the syntactic and semantic level. Macro/non-macro code executions are intermingled. But maybe I'm overemphasizing things. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On Sep 8, 5:41 pm, lprefonta...@softaddicts.ca wrote: Writing tons of XML lines to control behavior of frameworks was also a turn off. We use Spring to create low-level Java beans but the XML describing these beans did not change much over time. That is acceptable. I think Lisp is very well suited to being introduced as a replacement for XML. Some XML-based frameworks and tools (notably Spring and Maven) make sure - or are starting to make sure - that XML is not actually required to configure them; you can more or less easily write your own configuration reader that understands your language and plug it in. I actually wrote my own Lisp configuration DSL for Spring and I find that the possibility of having functions, macros, conditionals in your application context is just great ;) Just my €.02 Alessio -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT laurent.pe...@gmail.com wrote:
Hello,
2010/9/9 Sean Corfield seancorfi...@gmail.com:
On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava patrickli_2...@hotmail.com wrote:
I found the easiest way to introduce macros is just to introduce them
as small syntactic sugaring. For example, getting rid of the explicit
(fn [] ...) for macros like (with-open file ...).
Interesting. I don't see any real difference between macros and C
preprocessor stuff and C++ templates at a conceptual level. I think
Clojure macros are much cleaner, but essentially they are similar. So
in the Java world, generics (templates) are not yet widely used
outside the libraries and maybe that's why Java devs find macros hard
to comprehend?
I think that even at the conceptual level, the differences are big:
a. C/C++ is a pre-processor. It does a first pass on the code.
Only at the end is the C/C++ compiler invoked. In Lisps, there is
still this first pass/second pass thing, but it's at a waay finer
granularity level: the top level form. At the end of the evaluation of
each top level form, a new macro may have been defined and can be
called immediately by the next top level form. So not only is the
set of macros not closed in Lisp (and in C/C++, to some extent, it's
also not closed, even if rather limited), but it can be expanded
during the compilation of the program.
Of course the real difference is that in Lisp macros you are working
directly on the AST, where in C/C++ macros you're working at the
source level. My understanding of the C/C++ preprocessor is that it
more or less does a string substitution, which *may* lead to a syntax
errors (you often see #define X(y) do { y } while (0); to get around
different limitations), or undesired results, not to mention
unintended variable capture, etc, etc, etc.
The fact that Lisp macros actually operate on the AST means that Lisp
macros can make *changes* to the AST (insert things, remove things,
rearrange things), and *not* just substitute FOO for BAR. This is a
hell of a lot more powerful.
--
http://www.apgwoz.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
2010/9/9 Andrew Gwozdziewycz apg...@gmail.com:
On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT laurent.pe...@gmail.com wrote:
Hello,
2010/9/9 Sean Corfield seancorfi...@gmail.com:
On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava patrickli_2...@hotmail.com
wrote:
I found the easiest way to introduce macros is just to introduce them
as small syntactic sugaring. For example, getting rid of the explicit
(fn [] ...) for macros like (with-open file ...).
Interesting. I don't see any real difference between macros and C
preprocessor stuff and C++ templates at a conceptual level. I think
Clojure macros are much cleaner, but essentially they are similar. So
in the Java world, generics (templates) are not yet widely used
outside the libraries and maybe that's why Java devs find macros hard
to comprehend?
I think that even at the conceptual level, the differences are big:
a. C/C++ is a pre-processor. It does a first pass on the code.
Only at the end is the C/C++ compiler invoked. In Lisps, there is
still this first pass/second pass thing, but it's at a waay finer
granularity level: the top level form. At the end of the evaluation of
each top level form, a new macro may have been defined and can be
called immediately by the next top level form. So not only is the
set of macros not closed in Lisp (and in C/C++, to some extent, it's
also not closed, even if rather limited), but it can be expanded
during the compilation of the program.
Of course the real difference is that in Lisp macros you are working
directly on the AST, where in C/C++ macros you're working at the
source level. My understanding of the C/C++ preprocessor is that it
more or less does a string substitution, which *may* lead to a syntax
errors (you often see #define X(y) do { y } while (0); to get around
different limitations), or undesired results, not to mention
unintended variable capture, etc, etc, etc.
The fact that Lisp macros actually operate on the AST means that Lisp
macros can make *changes* to the AST (insert things, remove things,
rearrange things), and *not* just substitute FOO for BAR. This is a
hell of a lot more powerful.
Yeah
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On 9 Wrz, 14:25, Andrew Gwozdziewycz apg...@gmail.com wrote:
The fact that Lisp macros actually operate on the AST means that Lisp
macros can make *changes* to the AST (insert things, remove things,
rearrange things), and *not* just substitute FOO for BAR. This is a
hell of a lot more powerful.
--http://www.apgwoz.com
To be fair to C and C++ they allow changing AST:
#define UNLESS(x,y) {if (!(x)) {y;} };
This macro changes (UNLESS x y) to (if (not x) y) - this is different
AST trees.
The only difference I see is that in C you have to work with
characters, when in lisp you work with lists, and that in C you can
only use preprocessor directives at compile time (you can't output
diffrent code in macro depending on the structure of its arguments),
when in lisp you can use lisp at compile time to change what code will
be created by macro.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On Thu, 9 Sep 2010 07:04:00 -0700 (PDT) ajuc aju...@gmail.com wrote: [In C] you can't output different code in macro depending on the structure of its arguments That, of course, is a *crucial* difference. Think about the same restriction outside the macro environment: what would programming be like in a language where a function couldn't output different values depending on its arguments? mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On Thu, Sep 9, 2010 at 10:04 AM, ajuc aju...@gmail.com wrote:
On 9 Wrz, 14:25, Andrew Gwozdziewycz apg...@gmail.com wrote:
The fact that Lisp macros actually operate on the AST means that Lisp
macros can make *changes* to the AST (insert things, remove things,
rearrange things), and *not* just substitute FOO for BAR. This is a
hell of a lot more powerful.
--http://www.apgwoz.com
To be fair to C and C++ they allow changing AST:
#define UNLESS(x,y) {if (!(x)) {y;} };
This macro changes (UNLESS x y) to (if (not x) y) - this is different
AST trees.
The only difference I see is that in C you have to work with
characters, when in lisp you work with lists, and that in C you can
only use preprocessor directives at compile time (you can't output
diffrent code in macro depending on the structure of its arguments),
when in lisp you can use lisp at compile time to change what code will
be created by macro.
Well, C preprocessor macros don't really *change* the AST, it
*affects* the source *before* it's passed to the compiler (the
compiler creates the AST). You've also stumbled on the most important
difference between the two types--those differences make Lisp style
macros far more powerful.
--
http://www.apgwoz.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Interesting discussion!
I think about taking some of the topics into separate threads. Will
see, I'm a bit under project pressure. Wont tell you the language ;(
But, @Luc
pushing the advantage of Lisp
macros to the forefront is not obvious if the audience cannot compare
with another (good/simple) implementation they understand well.
Thats why I want to use a nifty metaphor ;-)
@all
After reading all your answers and discussion, I ponder whether the
words of
@ Laurent PETIT
second major difference is that you stay in the same language
for writing macros or non macros code in Lisp
are really true.
It is, of course, the same for my Java collegues, because its written
wit parentheses ;-)
But writing lambda forms - and this is what the usual functional
programming can be reduced to - and writing macros is very different.
Or is it not?
(At least to me it is.)
(Macros ar tree transformations. I have a hunch that maybe lambda can
be seen as a special form of such tree transformations (but I'm a
newbee here). If this is true, a new foundation of lisp may be
interesting. Not in lambda calculus, but in tree transformation
grammars. But that doesnt belong to this thread. Nevertheless,
comments are welcome :)
Thank you all, and kind regards, alux
On 9 Sep., 20:40, lprefonta...@softaddicts.ca wrote:
The major thing that made me used macros as much as possible when available
in any language was writing assembly code. Not 100 lines projects, 20,000 and
above, mainly made of macro calls.
That's when you realize that you need to use macros to generate instructions
for three reasons:
a) keeping the code size of the system within reasonable limits
b) having the instant ability to change things under the hood by altering
your macros instead of erring in the code trying to find the spots where
you must add these new instructions you just find out you urgently need to
make it work.
c) to improve the code readability and maintainability by enforcing common
patterns in the code.
I was blessed to work on DEC environments where the macro processors were
very strong and much more sophisticated than the C preprocessor. Not as
good as Lisp but still very flexible and able to handle complex logic.
For some reason, many common languages of the 70s/80s were missing this
important feature, at least it was not in their respective standards (Cobol,
Fortran, Pascal, ...). I think only Pl1 had some.
One friend of mine in the 80s was working on a HP3000 in Cobol I think
and that implementation had a macro processor but that was an exception
at the time.
My first impression is that they are not enough main macro implementations
widely used these days aside from the C preprocessor which is pretty basic.
The macro feature by itself is probably an strange/alien concept for many
people today.
Learning Lisp by itself is a big chunk so pushing the advantage of Lisp
macros to the forefront is not obvious if the audience cannot compare
with another (good/simple) implementation they understand well.
Luc P.
Laurent PETIT laurent.pe...@gmail.com wrote ..
2010/9/9 Andrew Gwozdziewycz apg...@gmail.com:
On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT laurent.pe...@gmail.com
wrote:
Hello,
2010/9/9 Sean Corfield seancorfi...@gmail.com:
On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava patrickli_2...@hotmail.com
wrote:
I found the easiest way to introduce macros is just to introduce them
as small syntactic sugaring. For example, getting rid of the explicit
(fn [] ...) for macros like (with-open file ...).
Interesting. I don't see any real difference between macros and C
preprocessor stuff and C++ templates at a conceptual level. I think
Clojure macros are much cleaner, but essentially they are similar. So
in the Java world, generics (templates) are not yet widely used
outside the libraries and maybe that's why Java devs find macros hard
to comprehend?
I think that even at the conceptual level, the differences are big:
a. C/C++ is a pre-processor. It does a first pass on the code.
Only at the end is the C/C++ compiler invoked. In Lisps, there is
still this first pass/second pass thing, but it's at a waay finer
granularity level: the top level form. At the end of the evaluation of
each top level form, a new macro may have been defined and can be
called immediately by the next top level form. So not only is the
set of macros not closed in Lisp (and in C/C++, to some extent, it's
also not closed, even if rather limited), but it can be expanded
during the compilation of the program.
Of course the real difference is that in Lisp macros you are working
directly on the AST, where in C/C++ macros you're working at the
source level. My understanding of the C/C++ preprocessor is that it
more or less does a string substitution, which *may* lead to a syntax
errors (you often see #define X(y) do { y } while (0); to get
Re: A difficult Metaphor for Macros (especially for Java people)
alux alu...@googlemail.com wrote .. Interesting discussion! I think about taking some of the topics into separate threads. Will see, I'm a bit under project pressure. Wont tell you the language ;( But, @Luc pushing the advantage of Lisp macros to the forefront is not obvious if the audience cannot compare with another (good/simple) implementation they understand well. Thats why I want to use a nifty metaphor ;-) @all Get them to write a few thousand lines of assembler, they will quickly adopt macros believe me : After reading all your answers and discussion, I ponder whether the words of @ Laurent PETIT second major difference is that you stay in the same language for writing macros or non macros code in Lisp are really true. It is, of course, the same for my Java collegues, because its written wit parentheses ;-) But writing lambda forms - and this is what the usual functional programming can be reduced to - and writing macros is very different. Or is it not? (At least to me it is.) (Macros ar tree transformations. I have a hunch that maybe lambda can be seen as a special form of such tree transformations (but I'm a newbee here). If this is true, a new foundation of lisp may be interesting. Not in lambda calculus, but in tree transformation grammars. But that doesnt belong to this thread. Nevertheless, comments are welcome :) Thank you all, and kind regards, alux On 9 Sep., 20:40, lprefonta...@softaddicts.ca wrote: The major thing that made me used macros as much as possible when available in any language was writing assembly code. Not 100 lines projects, 20,000 and above, mainly made of macro calls. That's when you realize that you need to use macros to generate instructions for three reasons: a) keeping the code size of the system within reasonable limits b) having the instant ability to change things under the hood by altering your macros instead of erring in the code trying to find the spots where you must add these new instructions you just find out you urgently need to make it work. c) to improve the code readability and maintainability by enforcing common patterns in the code. I was blessed to work on DEC environments where the macro processors were very strong and much more sophisticated than the C preprocessor. Not as good as Lisp but still very flexible and able to handle complex logic. For some reason, many common languages of the 70s/80s were missing this important feature, at least it was not in their respective standards (Cobol, Fortran, Pascal, ...). I think only Pl1 had some. One friend of mine in the 80s was working on a HP3000 in Cobol I think and that implementation had a macro processor but that was an exception at the time. My first impression is that they are not enough main macro implementations widely used these days aside from the C preprocessor which is pretty basic. The macro feature by itself is probably an strange/alien concept for many people today. Learning Lisp by itself is a big chunk so pushing the advantage of Lisp macros to the forefront is not obvious if the audience cannot compare with another (good/simple) implementation they understand well. Luc P. Laurent PETIT laurent.pe...@gmail.com wrote .. 2010/9/9 Andrew Gwozdziewycz apg...@gmail.com: On Thu, Sep 9, 2010 at 3:48 AM, Laurent PETIT laurent.pe...@gmail.com wrote: Hello, 2010/9/9 Sean Corfield seancorfi...@gmail.com: On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava patrickli_2...@hotmail.com wrote: I found the easiest way to introduce macros is just to introduce them as small syntactic sugaring. For example, getting rid of the explicit (fn [] ...) for macros like (with-open file ...). Interesting. I don't see any real difference between macros and C preprocessor stuff and C++ templates at a conceptual level. I think Clojure macros are much cleaner, but essentially they are similar. So in the Java world, generics (templates) are not yet widely used outside the libraries and maybe that's why Java devs find macros hard to comprehend? I think that even at the conceptual level, the differences are big: a. C/C++ is a pre-processor. It does a first pass on the code. Only at the end is the C/C++ compiler invoked. In Lisps, there is still this first pass/second pass thing, but it's at a waay finer granularity level: the top level form. At the end of the evaluation of each top level form, a new macro may have been defined and can be called immediately by the next top level form. So not only is the set of macros not closed in Lisp (and in C/C++, to some extent, it's also not closed, even if rather limited), but it can be expanded during the compilation of the program. Of course the real difference is that in Lisp macros you are working directly on the AST,
A difficult Metaphor for Macros (especially for Java people)
Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking quite different are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the only group where people understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) Now the question: Do you see any problems with this metaphor, is it misleading somewhere? Thank you, alux -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Actually, this metaphor has been used before. Check http://www.defmacro.org/ramblings/lisp.html for an other version of your story ;). 2010/9/8 alux alu...@googlemail.com: Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking quite different are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the only group where people understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) Now the question: Do you see any problems with this metaphor, is it misleading somewhere? Thank you, alux -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over Esperanto? Perguntas sobre o Esperanto? - http://demandoj.tk -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hello Joop, thanks for the link. So it seems not to be completely misled ;-) Greetings, alux On 8 Sep., 11:59, Joop Kiefte iko...@gmail.com wrote: Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlfor an other version of your story ;). 2010/9/8 alux alu...@googlemail.com: Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking quite different are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the only group where people understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) Now the question: Do you see any problems with this metaphor, is it misleading somewhere? Thank you, alux -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over Esperanto? Perguntas sobre o Esperanto? -http://demandoj.tk -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
I found the easiest way to introduce macros is just to introduce them as small syntactic sugaring. For example, getting rid of the explicit (fn [] ...) for macros like (with-open file ...). Once people get accustomed to this, they naturally extend it to more and more complicated usages. -Patrick On Sep 8, 6:12 am, alux alu...@googlemail.com wrote: Hello Joop, thanks for the link. So it seems not to be completely misled ;-) Greetings, alux On 8 Sep., 11:59, Joop Kiefte iko...@gmail.com wrote: Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlforan other version of your story ;). 2010/9/8 alux alu...@googlemail.com: Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking quite different are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the only group where people understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) Now the question: Do you see any problems with this metaphor, is it misleading somewhere? Thank you, alux -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over Esperanto? Perguntas sobre o Esperanto? -http://demandoj.tk -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hi Patrick, yes, I think thats the right way to teach this stuff. My problem arises earlier - I still have to motivate my collegues, to get them interested, and, maybe, teach them later ;-) Regards, alux On 8 Sep., 16:28, CuppoJava patrickli_2...@hotmail.com wrote: I found the easiest way to introduce macros is just to introduce them as small syntactic sugaring. For example, getting rid of the explicit (fn [] ...) for macros like (with-open file ...). Once people get accustomed to this, they naturally extend it to more and more complicated usages. -Patrick On Sep 8, 6:12 am, alux alu...@googlemail.com wrote: Hello Joop, thanks for the link. So it seems not to be completely misled ;-) Greetings, alux On 8 Sep., 11:59, Joop Kiefte iko...@gmail.com wrote: Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlforanother version of your story ;). 2010/9/8 alux alu...@googlemail.com: Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking quite different are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the only group where people understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) Now the question: Do you see any problems with this metaphor, is it misleading somewhere? Thank you, alux -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over Esperanto? Perguntas sobre o Esperanto? -http://demandoj.tk -- You received this message because you are subscribed to the
Re: A difficult Metaphor for Macros (especially for Java people)
Ah I see. Yes, motivation is hard. I don't have any good tips for that. I remember when I was trying to learn Lisp. Even though I desperately *wanted* to like Lisp, it still took a few tries before I started to appreciate it. Good luck! -Patrick On Sep 8, 11:07 am, alux alu...@googlemail.com wrote: Hi Patrick, yes, I think thats the right way to teach this stuff. My problem arises earlier - I still have to motivate my collegues, to get them interested, and, maybe, teach them later ;-) Regards, alux On 8 Sep., 16:28, CuppoJava patrickli_2...@hotmail.com wrote: I found the easiest way to introduce macros is just to introduce them as small syntactic sugaring. For example, getting rid of the explicit (fn [] ...) for macros like (with-open file ...). Once people get accustomed to this, they naturally extend it to more and more complicated usages. -Patrick On Sep 8, 6:12 am, alux alu...@googlemail.com wrote: Hello Joop, thanks for the link. So it seems not to be completely misled ;-) Greetings, alux On 8 Sep., 11:59, Joop Kiefte iko...@gmail.com wrote: Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlforanotherversion of your story ;). 2010/9/8 alux alu...@googlemail.com: Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking quite different are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the only group where people understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) Now the question: Do you see any problems with this metaphor, is it misleading somewhere? Thank you, alux -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to
Re: A difficult Metaphor for Macros (especially for Java people)
Hi, On 8 Sep., 17:07, alux alu...@googlemail.com wrote: yes, I think thats the right way to teach this stuff. My problem arises earlier - I still have to motivate my collegues, to get them interested, and, maybe, teach them later ;-) Then I wouldn't stress macros at all. Just mention them later on - Oh! And btw: this is a macro thingy. Clojure's concurrency features, the functional style, the abstractions, the consistency, rapid REPL development cycle - all this is what makes Clojure Clojure. Macros are also part of that, but a small and - IMHO - an overrated one. They have their place - and I don't want to miss them - but they are not one of the main selling point for me. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hello Meikel, I agree with all the points you suggest to mention, and I do so. Nevertheless I will get (and got, so this is not hypothetic) the question: But why do they use this intolerable strange syntax? Why cant this be in a usual (C-like) syntax? And here (thats my state of understanding) is the only reason: We directly write the abstract syntax tree, because this is the way we can introduce new syntax ourself. Thats why I think to need this metaphor. Thank you, and kind regards, alux On 8 Sep., 17:19, Meikel Brandmeyer m...@kotka.de wrote: Hi, On 8 Sep., 17:07, alux alu...@googlemail.com wrote: yes, I think thats the right way to teach this stuff. My problem arises earlier - I still have to motivate my collegues, to get them interested, and, maybe, teach them later ;-) Then I wouldn't stress macros at all. Just mention them later on - Oh! And btw: this is a macro thingy. Clojure's concurrency features, the functional style, the abstractions, the consistency, rapid REPL development cycle - all this is what makes Clojure Clojure. Macros are also part of that, but a small and - IMHO - an overrated one. They have their place - and I don't want to miss them - but they are not one of the main selling point for me. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hi, My main motivation to get away from Java as much as possible was the code size. I was tired of having to write tons of code lines for what I considered mundane things. Using wizards was not satisfactory to me. The generated code size is significant and still it has to be maintained either by hand or by running again a wizard. Using IDEs like Eclipse solved some of the issues with a huge code size and framework integration with the code if you had the hardware performance on your desktop to run these efficiently. That was not the case until very recently when multi core became affordable on the desktop. The slowness of single core desktop used for development purposes was an absolute Java repellent until 2/3 years ago. Writing tons of XML lines to control behavior of frameworks was also a turn off. We use Spring to create low-level Java beans but the XML describing these beans did not change much over time. That is acceptable. Is there something in the above list that could pull some of your reluctant colleagues on the dark side :)) ? If yes then you may want to take an existing chunk of Java code of reasonable size that they work with in everyday life and move that to Clojure or to a Clojure/Java combo... Luc P. alux alu...@googlemail.com wrote .. Hi Patrick, yes, I think thats the right way to teach this stuff. My problem arises earlier - I still have to motivate my collegues, to get them interested, and, maybe, teach them later ;-) Regards, alux On 8 Sep., 16:28, CuppoJava patrickli_2...@hotmail.com wrote: I found the easiest way to introduce macros is just to introduce them as small syntactic sugaring. For example, getting rid of the explicit (fn [] ...) for macros like (with-open file ...). Once people get accustomed to this, they naturally extend it to more and more complicated usages. -Patrick On Sep 8, 6:12 am, alux alu...@googlemail.com wrote: Hello Joop, thanks for the link. So it seems not to be completely misled ;-) Greetings, alux On 8 Sep., 11:59, Joop Kiefte iko...@gmail.com wrote: Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlforanother version of your story ;). 2010/9/8 alux alu...@googlemail.com: Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking
Re: A difficult Metaphor for Macros (especially for Java people)
This was actually the article that finally got me to overcome the inertia and start exploring lisp, as a long-time native Java speaker. I gave up again in a few weeks, but the possibilities excited me, and when I found Clojure I was delighted with the number of things that were better than lisp, as well as the things better than Java. After just two weeks of working with lisp, when I went to write my next Java app, I was flabbergasted to discover that there is no (map). You might want to show them how simple it becomes to process sequences with map/reduce/etc - that was a huge revelation for me. On Sep 8, 2:59 am, Joop Kiefte iko...@gmail.com wrote: Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlfor an other version of your story ;). 2010/9/8 alux alu...@googlemail.com: Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking quite different are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the only group where people understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) Now the question: Do you see any problems with this metaphor, is it misleading somewhere? Thank you, alux -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over Esperanto? Perguntas sobre o Esperanto? -http://demandoj.tk -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more
Re: A difficult Metaphor for Macros (especially for Java people)
Hello Luc, what you say is of course completely true. Nevertheless it seems true for Scala too. And now I come with a new language again. The curious people in my team (well, or its the one with enough spare time :) already had some look into Scala, and I think I need additional arguments make them to look into Clojure too. But here I'm on a slippery slope. I'm still unable to judge the power of lisp macros compared to the power of Scalas possibilities to write your own control structures. Regards, alux On 8 Sep., 19:29, Alan a...@malloys.org wrote: This was actually the article that finally got me to overcome the inertia and start exploring lisp, as a long-time native Java speaker. I gave up again in a few weeks, but the possibilities excited me, and when I found Clojure I was delighted with the number of things that were better than lisp, as well as the things better than Java. After just two weeks of working with lisp, when I went to write my next Java app, I was flabbergasted to discover that there is no (map). You might want to show them how simple it becomes to process sequences with map/reduce/etc - that was a huge revelation for me. On Sep 8, 2:59 am, Joop Kiefte iko...@gmail.com wrote: Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlforan other version of your story ;). 2010/9/8 alux alu...@googlemail.com: Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking quite different are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the only group where people understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) Now the question: Do you see any problems with this metaphor, is it misleading somewhere? Thank you, alux -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com
Re: A difficult Metaphor for Macros (especially for Java people)
alux alu...@googlemail.com wrote .. Hello Luc, what you say is of course completely true. Nevertheless it seems true for Scala too. And now I come with a new language again. The curious people in my team (well, or its the one with enough spare time :) already had some look into Scala, and I think I need additional arguments make them to look into Clojure too. But here I'm on a slippery slope. I'm still unable to judge the power of lisp macros compared to the power of Scalas possibilities to write your own control structures. I cannot help you much here. I looked at Scala nearly two years ago while searching for a JVM alternative to Java. I already knew Lisp and wanted a generic macro facility but I was not convinced by Scala even before looking at its extensibility features... sorry. Too OOish for me, I was starting to have skin rashes about the OO approach by then after 7 years of exposure to Java and the Russian puppet syndrome :))) Luc Regards, alux On 8 Sep., 19:29, Alan a...@malloys.org wrote: This was actually the article that finally got me to overcome the inertia and start exploring lisp, as a long-time native Java speaker. I gave up again in a few weeks, but the possibilities excited me, and when I found Clojure I was delighted with the number of things that were better than lisp, as well as the things better than Java. After just two weeks of working with lisp, when I went to write my next Java app, I was flabbergasted to discover that there is no (map). You might want to show them how simple it becomes to process sequences with map/reduce/etc - that was a huge revelation for me. On Sep 8, 2:59 am, Joop Kiefte iko...@gmail.com wrote: Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlforan other version of your story ;). 2010/9/8 alux alu...@googlemail.com: Hello, I still try to read my way through Paul Grahams On Lisp, and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this Code is Data, and Macros let you grow your own language towards the problem stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like You can have the language which suits your program, even if it ends up looking quite different from Lisp. Longer Answer: What puzzles me most about this quoted formulation is the words different from Lisp, as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things looking quite different are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the
Re: A difficult Metaphor for Macros (especially for Java people)
On Wed, 08 Sep 2010 15:13:57 -0400 (EDT) lprefonta...@softaddicts.ca wrote: I cannot help you much here. I looked at Scala nearly two years ago while searching for a JVM alternative to Java. I already knew Lisp and wanted a generic macro facility but I was not convinced by Scala even before looking at its extensibility features... sorry. Too OOish for me, I was starting to have skin rashes about the OO approach by then after 7 years of exposure to Java and the Russian puppet syndrome :))) Hey, I *like* OO programming! I love being able to create whole new classes of functionality by just inheriting from the correct set of classes, with out actually writing a line of code that's more than the class declaration. Not quite as spiffy as real macros, but close. Of course, that I like OO programming and desired to continue doing so is why I never wrote Java or C++ for real. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Rich does a fine job of explaining macros here: http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Rich-Hickey-and-Brian-Beckman-Inside-Clojure See minutes 23 to 25. The macro concept is not complicated, it should not be hard to explain to someone. The benefits of code writing code should be obvious and familiar to everyone. The complexity comes from the particulars of how you write good macros in your lisp. And mastery of that is primarily a function of writing your own and reading good examples. Adam -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On Wed, Sep 8, 2010 at 08:17, CuppoJava patrickli_2...@hotmail.com wrote: Ah I see. Yes, motivation is hard. I don't have any good tips for that. I'm still a noob at the evangelising part of Lisp! However, when it comes to clojure, I tell Java people it's a better way of writing Java than Java; it gives you all the things experienced Java programmers wish Java had: + try the cast, compiler, just trust me on this one + must I really declare that to be thrown? When I don't please just treat it like a RuntimeException! + no write, save, compile loop - REPL's are amazing + concise object literals for the common data structures, list, maps, etc. are amongst a few of my favoured lines. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hello all, @Luc I'm not a OO adversary, but no evangelist too ;-) @Mike I think the difference between Scala and Clojure is not OO vs not OO, but rather static vs dynamic typing. Clojure is OO too, but as you see with Luc, you can ignore it ;-) @Adam Cool! A RH-video I want aware of! Thank you! (I read he did a talk just about macros this year, but I dont know whether there is a video or slides of it on the web.) @Michael Yep, again some stuff for the comparison list. Thank you. An interesting discusssion! Thank you all! Regards, alux On 8 Sep., 20:17, Michael Ossareh ossa...@gmail.com wrote: On Wed, Sep 8, 2010 at 08:17, CuppoJava patrickli_2...@hotmail.com wrote: Ah I see. Yes, motivation is hard. I don't have any good tips for that. I'm still a noob at the evangelising part of Lisp! However, when it comes to clojure, I tell Java people it's a better way of writing Java than Java; it gives you all the things experienced Java programmers wish Java had: + try the cast, compiler, just trust me on this one + must I really declare that to be thrown? When I don't please just treat it like a RuntimeException! + no write, save, compile loop - REPL's are amazing + concise object literals for the common data structures, list, maps, etc. are amongst a few of my favoured lines. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
