More thoughts around Code Generation and Extensible Programming Systems
Got forwarded an interesting link from Dr. Gregory Wilson at the University of Toronto. He's an editor at Dr. Dobbs as well, and has an article up called Extensible Programming for the 21st Century that touches on many of the topics I've been concerned with lately.
He makes some interesting assertions, starting with:
This article argues that next-generation programming systems will accomplish this by combining three specific technologies:
- compilers, linkers, debuggers, and other tools will be plugin frameworks, rather than monolithic applications;
- programmers will be able to extend the syntax of programming languages; and
- programs will be stored as XML documents, so that programmers can represent and process data and meta-data uniformly.
Ok, #1 no problem, we arguable have this with the CLR's model, while #2 is a little different. I assume he means actual keyword syntax, as opposed to the way we "changed" programming languages in C with preprocessors and inline functions. Of course, LISP and Schema use macros to the point where one can't tell where the language starts or ends. Additionally, custom language constructs like the "using" statement in C# that "expands" into a try/finally use of the IDisposable pattern extend the language within a specific context - so I'll buy #2 also. I used to think that Number 3 is more of a stretch, but then you've got XAML sneaking up on us as well (not to mention our own foray into XML and CodeGen).
I supposed the question I am left with after reading his article is - hasn't all this already happened?
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
RichB
Scott, the 'using' keyword is not a good example of #2. I want to create my own keywords, and that cannot be done in C#. I think that's an important one, and it's in the same path as the 'intentional programming' guys.
About storing the source file in an XML I'd say that it should be in a database, where all the names are stored in a normalized structure. So, if I change the name of one class, I'm really changing the 'description' of the class, but all the references to it in the source code are made by id (when the source is edited you see the name). That way some operations like renaming a class are trivial (all the references are automatically renamed), deleting a class does a referential integrity check so you cannot delete it if you are using it, doing a cross reference that shows where a class is references is just performing a SQL statement, etc.
Some time ago I read somewhere that if we find a guy that all his accounting work in a text file we'll think he's crazy. We programmers are doing all of our work in text files.
Storing programs as XML or in a database makes sense to me. I used to wonder why I could use rich text and graphics (Word at the time) to write a spec or design note for a piece of code, but then had to resort to flat text for the code itself. What I always wanted to do was to take the Word doc, start adding the code while reading the design.
What is particularly pitiful is that you can't even have simple drawings or hyperlinks in the comments. I've often drawn a quick picture of my datastructures to help me think through some code. Most often I do it when debugging, but sometimes when writing it too. Those kinds of artifacts ought to be saved.
I guess I should note that maybe I should have modelled the code in the first place.
KC
KC
As an example, consider what people in dynamic languages (not just ST and LISP, but even python or ruby) do: they often use a method where other languages uses syntax (say, C#'s lock is trivial to implement with blocks, or that "private" is a method call in ruby).
I'm not really sure that static languages could easily deal with this (if X# allows it that would be *really* interesting to know)
Comments are closed.