On Sat, 12 Jan 2008 21:46:36 +0000, Cor wrote: >> Still, it would be in his interests to consider the effect of the way >> he uses language.
> Do you really mean that ?
> Just because the messenger used "Hey-'yo 'ya-bunch" instead of My Dearly > Beloved Congregation ... ?
> Would you really believe the 'foo-thinghy instead of the 'bar-thinghy > because the paper 'foo-thinghy was written on did not match your colour > taste ?
> Maybe , the lingo is just used to kick some life in stuffed shirts ...
> Cor
It didn't affect me. I spent several hours reading through his web site. But "university studies show" that most people are greatly impacted by appearance and impressions.
You seen this in the computer field all the time where people are sucked in by good looking demos that have no substance to them whatsoever ie no actual capability.
Have a look at some advertising to see the rubbish that convinces most people. None of us are immune - we are all human.
On Sat, 12 Jan 2008 13:48:28 -0800, Don Geddis wrote:
> Looked at it from another view, Lisp has embodied many advanced programming > language concepts that other languages ignored for decades, and only recently > began appreciating the value and adding. Garbage collection, macros, symbols, > etc. Surely, if your argument ("popularity in other languages") were valid, > it would apply to all those concepts also (at least until the recent past).
It's interesting that other languages have been importing many features, but macros seems to be an exception. My impression is that macros are less used now than 10 or 20 years ago.
There seems to be a phobia about macros. People keep reinventing them but are very wary of calling them macros.
If you have a look at the java world, there is a large amount of code generation going on. There is also an amazing amount of patching of object files (.class files) as well.
C++ has templates, which have reportedly now reached the stage of being Turing-complete. But macros are still frowned upon.
There are two explanations I have seen:
1. If you use macros, you are almost defining a new language. You have to look at the macro definition to see what the code does.
This argument seems equally applicable to the use of any facility beyond in-line code (eg using other classes). And most languages with macros have the ability to expand the macro for viewing.
In any case, as Paul Graham never tires of pointing out, maybe you do want to create a new language, a domain specific language. This may be a really good idea.
What puzzles me is that people accept patching class files but will not accept macros. How do you look at the source of a patched class file?
2. In the early days, people went too far with macros and the code became unmaintainable.
This seems to be just an argument for discipline in programming projects.
Is there any other explanation? Here is Sun's explanation for no macros in Java.
On Sun, 13 Jan 2008 00:53:28 +0000, tim Josling wrote: > What puzzles me is that people accept patching class files but will not > accept macros. How do you look at the source of a patched class file?
> 2. In the early days, people went too far with macros and the code > became unmaintainable.
> This seems to be just an argument for discipline in programming > projects.
> Is there any other explanation?
I think that the big "problem" wth macros is that because they leave no trace of themselves in the ultimately-generated executable code, they make it difficult and confusing to debug with the usual suite of source- level "IDE" debuggers (you generally can't "step into" a macro the way you can a function). I have observed that there are a *lot* of otherwise good programmers who won't even consider stepping outside that paradigm, and who therefore hate all macros, a-priori.
Some entity, AKA tim Josling <tejgcc_nos...@westnet.com.au>, wrote this mindboggling stuff: (selectively-snipped-or-not-p)
> It didn't affect me. I spent several hours reading through his web site. > But "university studies show" that most people are greatly impacted by > appearance and impressions.
I understand that, but it really bugs me that 'packaging seems more important that the contents, hence my reaction.
Cor
-- SPAM DELENDA EST http://www.clsnet.nl/mail.php (defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux"))) Alle schraifvauden zijn opsettelick, teneynde ieder lafaart de cans te gevuh over spelingk te mekkuh instede de inhaut
On Sat, 12 Jan 2008 21:46:36 +0000, Cor <c...@clsnet.nl> wrote:
>Some entity, AKA tim Josling <tejgcc_nos...@westnet.com.au>, >wrote this mindboggling stuff: >(selectively-snipped-or-not-p)
>> Still, it would be in his interests to consider the effect of the way he >> uses language.
>Do you really mean that ?
>Just because the messenger used "Hey-'yo 'ya-bunch" instead of My Dearly >Beloved Congregation ... ?
>Would you really believe the 'foo-thinghy instead of the 'bar-thinghy >because the paper 'foo-thinghy was written on did not match your colour taste ?
>Maybe , the lingo is just used to kick some life in stuffed shirts ...
>Cor
The problem is that Xah frequently opens a discussion with the moral equivalent of "hey you fuckers, you should listen to me because I'm smarter than you". He only rarely responds to discussions of his posts and when he does, his responses to criticism are frequently abusive. His style and tone naturally predispose people not to listen to him.
Xah's opinions are rarely unclear, and he obviously puts quite a bit of thought into his missives - but many people simply are unwilling to parse his morass of foul language to understand what it is that he thinks.
Anyone in advertising will tell you that the form of the message is at least as important as the message itself. The message doesn't matter if no one hears it. If Xah cleaned up his language (quite) a bit and took the chip off his shoulder, I think he would get much more respect as a critical thinker.
tim Josling <tejgcc_nos...@westnet.com.au> writes: > It's interesting that other languages have been importing many features, > but macros seems to be an exception. My impression is that macros are less > used now than 10 or 20 years ago.
Yes. I think that's for a number of reasons, but basically because the trend has been toward static analysis and macros themselves are hard to debug without a decent theory of parsing, presenting language structures, etc. Without that, they are little more than a sed script, and that detracts from the other less unruly (more ruly?) parts of whatever language you are talking about.
> There seems to be a phobia about macros. People keep reinventing them but > are very wary of calling them macros.
Well, they keep trying to solve the problem in isolation, without addressing the other parts of the language (manifest representation, parsing, printing) issues that make it tough to use them. If you want to solve only the macro problem in isolation, it is a hard problem, and they're doing the best they can--much better, frankly, than I'd have predicted, even if not as well as we might wish. I'm pretty impressed with how much C# managed to clean up templates, to where they almost feel like they're part of the same language and not some alien language, unrelated to the base language (as happens in C++).
> If you have a look at the java world, there is a large amount of code > generation going on. There is also an amazing amount of patching of object > files (.class files) as well.
> C++ has templates, which have reportedly now reached the stage of being > Turing-complete. But macros are still frowned upon.
Probably because of debuggability, which in turn is because the language you're writing your template code in really doesn't feel like the language you've come to master without templates... so it doesn't leverage a lot of what you know already. It's just a new exercise.
> There are two explanations I have seen:
> 1. If you use macros, you are almost defining a new language. You have to > look at the macro definition to see what the code does. [...]
You are only defining a new language if you don't make your original language available as a manifest data structre that is easy to conjure, traverse, parse, and print. What modern language, and here I'll generously include not only C++ but even C, is incapable of those four basic operations? The thing that is missing isn't the ability to manage such structures, it's the ability to know and manipulate and interact with and extend the actual structures C++ does.
What's people like about Lisp, I think, is that it allows you to take ordinary knowledge--the kind of knowledge you have already if you've solved that idiotic FLATTEN-LIST problem that teachers of Lisp always assign--and use that to write a macro. C++ templates are unintelligible to someone who does not have reasonably advanced knowledge of types and methods. That's a huge difference. You could get a lot of programming done in Lisp without ever mastering defclass, defstruct, deftype, and typep; to include the use of macros. Not so in C++ for the equivalent operators.
> 2. In the early days, people went too far with macros and the code became > unmaintainable.
> This seems to be just an argument for discipline in programming projects.
I think it tells you that the tools for creating macros were error-prone because they were text-based, and they got a bad name because of token merging bugs and stupid stuff like that. That makes it politically hard to get people to reconsider them. They have the kind of overzealous bad reputation that Lisp has in some circles--where people are eschewing a whole class of concepts because once, somewhere that they probably don't remember, they saw (or heard about or think they heard about) one such concept being abused.
> Is there any other explanation? Here is Sun's explanation for no macros in > Java.
Fascinating. But personally, I think the central claim in that post appears to be unsupported. That is, they seem to assert that macros would make programs unreadable for everyone else. But they offer no foundation for this claim. That says a lot.
Probably people are not beating down their doors asking for macros. People rarely ask for things they are not used to using, and are usually delighted to get anything that improves their prior state, with very little regard to whether others somewhere else have something better. They have to first understand and appreciate that "something else" to want it, and no one is busy marketing macros to this community in a form that makes it sound like something they _would_ want.
For a long time, people used to talk about what an innovation Microsoft Windows was, mostly because they came from DOS, not the Macintosh, and certainly not from a Lisp Machine, an Alto, a Dorado, an Apollo ... Unix (and later Linux) was likewise greeted as an extraordinary step up by people who had never seen Multics. Progress often moves backward to move forward because timing, marketing, and other factors are as important as being right about where you're going...
- - - - -
By the way, shifting topic for a moment somewhat:
The first course I took at MIT where Lisp was taught was 6.030, I believe, and I think I took it in the spring of 1977, almost exactly 30 years ago. The Lisp part was taught by Joe Weizenbaum (of ELIZA fame). I recall a story he told us once about the importance of always balancing our parens. He took on a mischievous tone at one point and said something vaguely to the effect of (this was now almost exactly 30 years ago, in Spring 1977, and this is from memory, so I might not have the exact words still, but hopefully this is close in nature): ``Sometimes, when I want to have a little fun with someone, I'll sneak into their office and write a stray open parenthesis somewhere on their blackboard. [And he made a little chalk mark to show us.] And then all day, I imagine they'll wander around feeling like something is just a little off. Then, later, I'll sneak back in and close that parenthesis. [He made another chalk mark.] And then the world will be back in balance, and they may never know why.'' And he smiled the kind of delighted smile of someone who understood the power of parentheses to make or break one's day. The remark, or its essential nature at least, really stuck with me. And I often think on it and smile.
I noticed you missed a closing parenthesis in the subject line. And so I was feeling like something was just a little off.
Andrew Reilly <andrew-newsp...@areilly.bpc-users.org> writes: > I think that the big "problem" wth macros is that because they leave no > trace of themselves in the ultimately-generated executable code, they > make it difficult and confusing to debug with the usual suite of source- > level "IDE" debuggers (you generally can't "step into" a macro the way > you can a function). I have observed that there are a *lot* of otherwise > good programmers who won't even consider stepping outside that paradigm, > and who therefore hate all macros, a-priori.
I don't think this problem is intractable. There are various different approaches that can be used, some involving more and less cooperation from macro writers, some involving different data structures and tools for navigating them than Lisp uses.
Just as an example, there was a stepper written for Lisp by ... hmmm ... I'm going to say Dan Halbert, then a student MIT Lab for Computer Science, I wish I could remember for sure--anyone know? And I can't remember the name of the stepper, but I can't do that either. Anyway, in this stepper I'm remembering some extra operations that macro expanders could expand into in order to help with interactive stepping through macrofied code. Vaguely, I recall it being something like:
[With only slight bits of extra effort, you could even make these forms take an "argument" which was the parent cons of the point in the source code that contains the source text, or some other such thing. Or it could be heuristically inferred.]
This doesn't exhaust the set of things that macro writers are up against, and each has to be confronted as its own problem. Keeping track of token-to-line correspondences is another. I've seen various solutions to that, too. None are trivial but each does a fair job of getting close enough for serious work.
But they don't get solved by saying "oh, this looks hard" and giving up. One thing the Lisp community has excelled at is first committing to doing something, just because it needs to be done, and then making it work well. If you do it the other way around, only moving forward when you know how to do it, you don't get nearly as many submissions about how to improve things. And you hold back program writing in the interim rather than having people write as they like on the promise or hope that it will work better by magic later. Some of those promises don't come true. But more often than not, they do.
> I think that the big "problem" wth macros is that because they leave no > trace of themselves in the ultimately-generated executable code,
I am a newbie But I'll take a shot, what the heck :)
If some CL compiles to C and then generates code and (for argument's sake) can not correlate the ultimate machine instruction with the CL source, is that a problem with functions Even if it directly generated machine code, is it automatically given that such an implementation can correlate source and the machine code Don't the lexical variables go away unless explicit care is take to preserve stuff for debugging Isn't same true for tail call merging (or whatever)
I guess logically you should be able to step into macro expansion and then also step into macro execution, showing appropriate code at the appropriate time, depending on whether you are debugging expansion or debugging execution (nice theory :) )
I am a newbie But I'll take a shot, what the heck :)
If some CL compiles to C and then generates code and (for argument's sake) can not correlate the ultimate machine instruction with the CL source, is that a problem with functions Even if it directly generated machine code, is it automatically given that such an implementation can correlate source and the machine code Don't the lexical variables go away unless explicit care is take to preserve stuff for debugging Isn't same true for tail call merging (or whatever)
I guess logically you should be able to step into macro expansion and then also step into macro execution, showing appropriate code at the appropriate time, depending on whether you are debugging expansion or debugging execution (nice theory :) )
Inspired by this post, and as a service to the Internet community I am making available, free of charge, a large collection of periods:
