From: necaris

2011-03-31 02:58 am (UTC)

Writing programs to write programs seems awfully Lispy to me -- or am I misunderstanding? From: pozorvlak

2011-03-31 09:10 am (UTC)

Yes, metaprogramming's a big part of Lisp culture. Lisp macros have a big advantage over textual macro-expansion, though, in that they operate on ASTs rather than textual tokens. I don't know how they handle the dead-code and tool-support issues: possibly this could be handled in a general way by advanced Lisp IDEs?



Judging by SICP, there's also a culture of writing custom interpreters and compilers for external DSLs (like the kind of thing discussed above) in the Scheme world. Again, it would be interesting to know how they solve this sort of problem. From: danl2620

2011-04-01 01:29 am (UTC)

We're using PLT Scheme in an environment with many layers of DSLs. The syntax transformers (fancy name for macros) are the heart of it all.



Dead code isn't a problem since we have subtle control over generation and evaluation so we never generate anything we don't mean to.



Tool interaction can certainly be a problem. It is extremely easy and natural to define new DSLs in each context, so at this point we have hundreds of them. There's no real standard way to interact with code that diverse. We will occasionally create simplistic new DSLs just so that external tools can generate or read our scripted code.

From: andrewducker

2011-03-31 07:23 am (UTC)

We use code generators to transform XML schemas into classes. Oh, and for UI stuff. Other than that I think it's all handcrafted. Our build stuff is all in Ant and Nant, which seems to be flexible enough by itself (at leas, so far). From: pozorvlak

2011-03-31 12:20 pm (UTC)

We do something like that; one problem that I've found is that now your getters and setters are declared (a) implicitly, (b) in another language, so ctags doesn't work. Do you find this a problem, or do you have a cunning solution?



Ant/Nant: I've heard many complaints about them, but "not flexible enough" is not one of them :-) Note, incidentally, that Makefiles have exactly this "snippets of copy-and-pasted code" problem. From: andrewducker

2011-03-31 12:27 pm (UTC)





In both cases it produces fairly standard code - our build process checks to see if any schemas have changed that day, and if so builds the associated DLL before the compile stage. This means that our continuous integration build fails if a schema has been checked in, but the code hasn't yet been brought up to date (basically treating the schema as a contract).



Can't talk about ctags, as that looks like a C thing, which we don't use :->



Ant/Nant definitely have problems - they're complex to read, it's very hard to tell if you've got it working without running it, and there's no way of debugging them short of console output. You can make them do almost anything though :-> Our code is C# and Java. We generate Java jars and C# DLLs using Liquid In both cases it produces fairly standard code - our build process checks to see if any schemas have changed that day, and if so builds the associated DLL before the compile stage. This means that our continuous integration build fails if a schema has been checked in, but the code hasn't yet been brought up to date (basically treating the schema as a contract).Can't talk about ctags, as that looks like a C thing, which we don't use :->Ant/Nant definitely have problems - they're complex to read, it's very hard to tell if you've got it working without running it, and there's no way of debugging them short of console output. You can make them do almost anything though :-> From: pozorvlak

2011-03-31 01:16 pm (UTC)

Ctags is a cross-language "jump to where this symbol is defined" tool, whose output is interpreted by vi/Emacs/etc; it was originally designed for C, but offers configuration hooks for other languages. Last time I tried to extend it I ran into a world of pain and gave up, but maybe I should try again. From: andrewducker

2011-03-31 02:04 pm (UTC)

Aaah - because we're generating code in the same language (and even if we weren't, reflection is cross-language in .Net) we don't have to worry about generating that kind of thing, it's built in. From: pozorvlak

2011-03-31 04:23 pm (UTC)

Neat! From: gareth_rees

2011-03-31 05:10 pm (UTC)





Your lessons look good (especially #6—though nothing will cure any sense that ESR is a Great Prognosticator quite as fast as



But I think you're missing the main one. You wrote:



days looking through diffs



I'm not sure if "days" is an exaggeration, but if it isn't then it's worth learning to spot when you're engaged in fruitless activity like that, and stepping back to try to make a better plan. Looking through diffs is basically hoping for a quick fix—something that will let you fix the problem without having to understand it. Which is great if it works (and often it does) but if it doesn't then you're going to have to understand the problem, and that means rolling your sleeves up and getting stuck in. Nice war story!Your lessons look good (especially #6—though nothing will cure any sense that ESR is a Great Prognosticator quite as fast as Sex Tips for Geeks ).But I think you're missing the main one. You wrote:I'm not sure if "days" is an exaggeration, but if it isn't then it's worth learning to spot when you're engaged in fruitless activity like that, and stepping back to try to make a better plan. Looking through diffs is basically hoping for a quick fix—something that will let you fix the problem without having to understand it. Which is great if it works (and often it does) but if it doesn't then you're going to have to understand the problem, and that means rolling your sleeves up and getting stuck in. From: pozorvlak

2011-04-01 11:03 am (UTC)

You're right! And in this case rolling up my sleeves and getting stuck in wouldn't have been too difficult - certainly easier than what I ended up doing. And no, "days" wasn't an exaggeration :-(