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.
Extensible Programming for the 21st Century
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
… where code is data and data is code, plus ability to define “sublanguage” dialects.
Well, take it easy, just could not resist 🙂
Cheers,
-pekr-
Forth offers most of those concepts except the XML part for past 30 years. Every time Microsoft run out of idea, it copied some from Forth.
On the other note:
I sometime wonder why Java is so slow when Forth is so fast( both are stack virtual machine).
I think REBOL misses a buzz word feature( a.k.a new hot C++ feature: uses template to run code during compile time ).
seriously:
I think REBOL should add/change the parameter passing for better code reading. The speed lost is marginal when today CPU run at GHZ.
or scheme?
No way applications would be stored in XML format.
Just too big.
XML has one or two things to recommend it for programming. The stress of developing the language is moved from the parser to the coder.
Among the uber-flaws of the idea, speaking from having been crushed utterly by Jakarta Tomcat 4.1 configuration, are data repeating all over the place (WTF the ODR?), complete disorientation, with similar, yet different, data in the server.xconf and web.xml, and no real grasp of where the data go and how they do their magic upon arrival (hint: it’s all reflection these days), and, the ultimate truth, that, for all its vaunted legibility, you’re really going to write a graphical tool to manage it, anyway.
My example is off-topic; you’d have something less byzantine for a programming language.
What I want to see is an RDBMS-based repository system, with entities modeling languages at the EBNF level, so that you can a) move compile-time problems to design time in some cases, and b) possibly target arbitrary languages. Just have the SQL throw in { } where necessary. Stay tuned…
Howdy
and no real grasp of where the data go and how they do their magic upon arrival (hint: it’s all reflection these days)
Ahhh hiding implementation details is a good thing not a bad thing although it should be human readable, so if the element names are bad suggest new more intuitive ones
XML`s strength IMHO is when you want to share data and Chris is exactly right when he says you could build a GUI to manipulate a doc, the way you made this GUI tool is irelevant as the data stays the same between the two applications.
Also XML data is so easy to manipulate it`s not funny, hell you could build a schema and transform an old format into a new one or any future spec automatically with out much work at all.
I`ve often wondered why languages don`t have some sort of syntax tree in XML, there would have to be a reason that escapes me ATM but if you did you could convert one language into another with a simple transformation.
… what the people at Chefax R&D have been trying to do?
>and programs will be stored as XML documents,
Are they crazy or something, god help me day I have to code applications in XML. I’ve used XML quite a bit, even defined an XML standard, and no way would I like to develop applications with it, it’s just so cumbersome – and ugly. I’d rather program in FORTRAN than XML.
Lisp and Scheme did a few of these things quite a while back. You can extend the syntax of the language using macros, you can store code as data and vice versa. Extremely flexible languages they are.
As someone once pointed out (I might be paraphrasing here): any sufficiently complicated C (or Fortran) program contains an ad hoc informally-specified bug-ridden, slow implementation of half of Common Lisp.
I stopped reading when he said programs will be stored as XML. No thanks. I’ve looked into VoiceXML and it really sucks to have XML as a programming language. It’s fine for storing data, but it’s very cumbersome to use it for control flow. Besides, we all know the language of the future is Arc, right?
In case you’re wondering about Arc, it’s a language being designed by Paul Graham and there is information about here:
http://paulgraham.com/arc.html
Are they crazy or something, god help me day I have to code applications in XML. I’ve used XML quite a bit, […rant…]
RTFA:
[i]Programmers will not see or edit XML tags; instead, their editors will render these models to create human-friendly views, just as web browsers render HTML. [i]
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.
Looks like this industry is running out of ideas…
>Are they crazy or something, god help me day I have to code >applications in XML. I’ve used XML quite a bit, […rant…]
>RTFA:
>Programmers will not see or edit XML tags; instead, their >editors will render these models to create human-friendly >views, just as web browsers render HTML.
It wasn’t a rant, it’s from direct experience, I’ve been working with XML since early 2000 and I’ve come to see it’s advantages and disadvantages. I don’t think you quite realize where this is going. Some people seriously believe that we will in fact use XML as the basis for a new set of programming languages and we will write directly in XML. Just check out the variety of XML based languages that are now being devised. I don’t believe all of them will have a nice shiny user interface with some upper level language in which to communicate the programming logic, unless you’re suggesting that we will go fully visual and program by point and click?
Think about it, your shiny interface is one ‘language’, point and click or text based, whatever your taste, which gets translated down to XML, which in turn get translated down probably to some safe intermediate code, which in turn gets translated down to the machine. How many layers do we need between the programmer and the hardware? I think it’s just CS Mastu**ion, XML has it’s uses but I hope it won’t be for application programming (unfortunately I think it will).
I think some people have got the idea that with XML, everything looks like a nail. Sometimes we need to use a bit of common sense and not buy in to every thing we (i.e you) read.
” How many layers do we need between the programmer and the hardware? ”
However many it takes to turn us into engineers.
In programming language design, parsing text to build the syntaxic tree is not a problem anymore.
Every Unix derived OS has “lex” and “yacc”, for example.
IMHO, what is interesting in that article is not XML by itself. The way the data and the code are actually stored is not a that important issue ( although, XML syntax is verbose ). The underlying principle is that programming tools will :
– Transform / Analyse code to various human readable formats. Not only plain text.
For example, Smalltalk engines usually have “decompilers” allowing to seamlessly analyse and modify methods.
– Produce and modify automatically code. There is a difference between embedding an “alien sytax” language into XML and adding programmatic XML tags.
The goal is definitively metaprogrammation. Lisp have allowed it for ages but the XML buzz will make it mainstream. XML languages can transform code written in XML languages, much more efficiently than, say, a Java code modifying java code.
Programmation is a task that will -also- be done by computers.
( One good aspect of XML is that its syntax is so bad that special editors are absolutely necessary, whereas the Lisp syntax is equally appropriate for these abstractions but is manageable with an ordinary text editor. )
That would be Greenspun’s 10th rule of programming:
“Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.” – Philip Greenspun
This is the *future*? Lisp has done all three of these things for decades!
Frameworks: Take the compiler optimizer example he used — that’s ‘compiler-macro’ in some CLs.
Code as data: Sexprs! And much nicer to use than XML to boot!
Extendible syntax: Heck, even the built-in syntax is often defined as macros.
This is the future of mainstream languages? What’ll be the future after that? Maybe integration with the compiler into the runtime (tremendously useful, Lisp has had it for decades). Flexible type systems? Metaclasses? Can I hope to see Java/C# overtake Lisp sometime during the next several decades?
Has anybody heard anything lately about Arc? It seems to have disappeared off the radar.
A recent Graham + Arc interview would be interesting.
lisp, forth, scheme and I am sure some that I have not heard of are extensible.
But the idea of storing the program as XML is the most telling. Far simpler indeed to store the code as written and provide a preprocessor to translate it to XML at compile time for the XML compiler. Then coders may use vi or emacs or codewright as pleases them.
Its 2004 and we are still seeing lots of code developed as it was ten years ago (C).
Presume that you will see slow progress in the future. In ten years I expect to see more runtime-supported languages (perl,python,C#,java) but not much else happening.
By time I get out of the industry (2030-2040) I expect people will simply use verbal descriptions of the problem and solution and let the system sort it out. “Take all of these images and remove that dumb looking tatoo from my brother”. DONE.
There’s a lot of truth to this. Changes will sneak up on us incrementally, and not all at once.
Despite the fact that Perl et al were basically interpreters, Java snuck in the Virtual Machine into the mainstream, and brought some very sophisticated compilers to the market. Smalltalk had some of this as well, but no where near with the success of what Java has had.
Now, we have Microsofts CLR, which is Different from Javas JVM but was certainly inspired by it.
With Moore’s law steaming full speed ahead, I can easily see a lot of new MS code being written on top of the CLR, literally as much as practical for them to do.
Dynamic languages in general are having quite the rebirth today (as can be seen by the popularity of things lile Ruby, Python, etc.), there’s even a resurgence in the Lisp community. Bit of a shame that the Forth community can’t make inroads in the new found wave. But it would need to be a pretty high level Forth, I think, much higher than what is typically considered Forth today.
So, who know what we’ll see in 10-15 years. I don’t think it will be XML based, because I think users will revolt, the interoperability of XML isn’t that necessary in this context, and XML is flat expensive to process.
But that doesn’t mean other interesting idea won’t come out.
Ahem…
“With Moore’s law steaming full speed ahead, I can easily see a lot of new MS code being written on top of the CLR, literally as much as practical for them to do. ”
and
“So, who know what we’ll see in 10-15 years. I don’t think it will be XML based, because I think users will revolt, the interoperability of XML isn’t that necessary in this context, and XML is flat expensive to process. ”
Not in the face of Moore’s law it’s not.
The article is focused on the short term (a few years).
What is going to happen in the long term (a few decades)
is that the basic semantics of language operations is
going to change. Object-oriented programming as done
today is still good old destructive assignment on memory
cells. This is also true of a Lisp program with macros.
This is not going to be true forever. In the future,
apparently simple instructions may cause complex
protocols to execute, such as fault tolerance, security,
and distribution protocols. We are already getting a little
of this with some of the more interesting languages
existing today: languages like E (capability security and
latency tolerance), Oz (dataflow concurrency and constraint
programming), and even with older languages such as
Prolog (unification as a basic operation). It’s not because
these are not in the mainstream that their ideas will not
become so.
My thanks to everyone for their comments. As always, most people seem to agree that programming tools are going to become deeply-extensible plugin frameworks, and that languages themselves are going to become syntactically extensible, but balk at the thought of using XML to store programs.
My argument isn’t that XML is an ideal representation for code; it’s that it is an inevitable one. XML is already becoming ubiquitous, mixed systems (Ant, Tomcat configurations, JSPs, JavaDoc, XDoclet, etc.) are already happening, and tools like .NET’s CodeDom already let developers create and manipulate source using XML-ish ideas. As the article says, I do not believe programmers will type in XML tags, any more than they type in the bytes that make up a GIF or spreadsheet’s on-disk representation. Instead, the switch to XML will enable (and require) programming editors that owe more to AutoCAD than to Notepad.
Thanks again for your comments.