an atypical entry

[zanfur]

I've found that I have a hard time thinking in Microsoft. I can think in C, C++, Smalltalk, Java, Bourne, BASIC, Perl, LISP, and any kind of scripting you could care to name. But, hand me C#, VB, J, or any of the other language Microsoft has designed in the last ten years, and I just can't hack it. Well, I can, but it just seems ... the long way

Comments

[zanfur]

Oh, please say more. You seem to know what you're talking about, and to know things that I don't.

Also, if you found this entry interesting, you'll probably find this one interesting, too.

I think it would be very, very hard to autogenerate maintainable C code. I think the solution to that problem involves designing a new language with that goal in mind. My first, knee-jerk response thought is that such a language would have to be very spartan, and very close to "human" thought architecture (roughly, "do this thing" as opposed to any sort of "manipulate these bits"). But, I haven't really spent much time thinking about it, because I figure the largest part of good design is the designing process itself, and not the tools used.

Hmm...second thought for a good visual designer would be to not autogenerate any structure code at all, but have adding "hooks" to named visual elements or events be part of the language itself. This way, with a separate named "form" object/file specifying initial layout, you could add any function to the

[zanfur]

Sorry it took me a while to respond, but my life these past couple days has been consumed with preparing for a presentation

[lumiere]

One trouble with Lisp and similar languages with complex compile-time code-generation systems is that macros and other code-generators are not first-class citizens of the programming environment. For example:

macros generate code, and multiple macros generate lots of code, and those code-generators interact in interesting, and sometimes incorrect, ways, and the details of code generation are extremely difficult to track down and change, especially if you are not the author of the code generators in question;

programming understanding tools such as profilers & debuggers gather information on the basis of the generated code, but rarely are able to correctly map that back into the source format which the programmer understands, and in the absence of that reverse mapping the programmer must learn how what the code generation process does in order to do the back-mapping by hand;

code-generation is generally hard to delay until runtime, yet sometimes you will need that delay so you can collect the proper inputs to the code generator.

There are

[zanfur]

Well, although I agree that macros in general are not first class citizens of the programming environment, LISP is an exception: LISP's macro system is actually turing-complete, making it a full-blown programming language unto itself. Actually, the macro system isn't a separate language -- it's just more LISP -- but you can use all of LISP to generate the code. Except for the macro you're currently defining, of course. This is an obvious extension of LISP, because its code syntax and list syntax are identical, and the code therefore easy to programmatically generate, but there are other systems (such as Slate, a smalltalk derivative) that manage to have a turing-complete macro system as well. You still run into problems of badly written code, but it's a lot easier to avoid (and easier to catch) than in most languages.

Badly written programs will have badly written bugs, of course. Because LISP macros are literally programs unto themselves, badly written macros will have badly written bugs. But, there are ways (actually, it's

[lumiere]

I've programmed in Chez Scheme and am familiar with hygenic macros and other nice properties of LISP-style macros.

Making macros Turing-complete, even making them expressed in the host programming language, does not make them first-class citizens of the programming language. It does make them far more powerful and far easier to write.

Here's another example of the second bullet point: static analysis. Your generic static analysis tool will operate on the fully-expanded syntax; how do results get mapped back onto the source syntax? There are workable approaches, but it's not a simple problem.

[zanfur]

I agree that macros pose some issues. You got me on the "debuggers can't back-map well" one, at least. Thankfully, because the forward mapping is so easy, it's never been a problem. That's in addition to the easy Tu Quoque defense I could make, but really, it just hasn't been a problem. It's a problem in C -- it's pretty hard to figure out what the expansion will be, once you start layering macros -- but I think that's mainly because C doesn't have a good "macro-expand this code and show me the result" function, and LISP does. (ALthough evan just wrote a C REPL, though, which may change that. I wanna be like him when I grow up.)

I just really prefer writing code that says exactly what it does. I can't do that with C. I can write something pretty close to english in LISP, and get what I want done. That's made possible by the openness and simplicity of the LISP macro system.

I like your comment that addressing these problems is in the arena of the development environment. LISP images are the development environment. The