Are Extensible Programming Languages Coming?

gManZboy writes "Programming writer and instructor Greg Wilson is proposing that the next generation of programming languages will use XML to store not only such things as formatting (so you can see indentation your way, and I can see it my way, via XSLT) but even programmatic entities -- like: <invoke-expr method="myMethod"><evaluate>record</evaluate></invoke-expr>. Wacky, but perhaps wacky enough to be possible?"

Comments

Holy mother of all that is good, NO!

[Mirk]

Three and a bit years ago, as a satire on the absurd over-enthusiasm for all things XML that was then taking over the world, I invented a parody language, XMC. Guess what? The over-enthusiasm for XML has continued unabated and now has taken over the world. And so life imitates art.

Herewith, a sample XMC program:

<?xml version="1.0" encoding="ISO-8859-1"?> <program language="c" xmlns="http:miketaylor.org.uk/xms/1.0/"> <include type="sysfile">stdio.h</include> <function type="int" name="main"> <params> !-- No parameters --> </params> <statement> <expression> <fncall fnname="printf"> <arguments> <argument> <constant type="int" value="0"/> </argument> </arguments> </fncall> </expression> </statement> <statement> <return> <constant type="int" value="0"/> </return> </statement> </function> </program>

Exercises for the reader:
1. What does this do?
2. Is it easier to read than the corresponding C program?

Re:Holy mother of all that is good, NO!

[Anonymous Coward]

I think just about all the posters on this thread are mostly missing the point. The goal is not to have programmers writing XML. The goal is to provide a "programmer -level" -language-independent way to represent programs in both conventional (brittle) languages like C++, and in extensible languages like Lisp.

Why would anyone want to do this? Programmer A writes a piece of code that has a confusingly-named identifier, say xglorp. Programmer B, doing maintenance on that code, wants to do a global search and replace on the bad identifier; not a replace of the string-form of that identifier -- not something like %s/xglorp/EventExitStatus/g in vi -- but on all the occurrences of that actual identifier in the code. To do this, your editing tool needs to be able to look at the parse tree; hence you need some cooperation from your compilers + linkers + editing environments, all working together.

The idea is not to have people writing XML. You would write in your own real language, and your program would be translated into XML, and saved that way. The next programmer asks to have the program represented in his language-de-jour. If his language and your language are semantically similar, this can work. If they're not, it won't work, since you are trying to solve the UNCOL problem (the holy grail for the universal intermediate representation, which does not exist).

Re:Is this guy serious?

[Jerf]

Actually, this is a potentially good use of XML.

Bear with me.

The primary benefit of XML is that as a standardized language, standardized parsers can be made available that are reasonably easy to use.

The primary "oversell" of XML is to extend that claim to cover semantics. Human readability is great and should not be underestimated in some uses, but should not be oversold either.

So let's say you want to write a tool to validate that some Java code conforms to something or other. What's the hardest part of that task, that shouldn't be hard? Parsing the Java code. I mean, it's not like it's impossible for someone skilled enough to even consider writing such a tool in the first place, but it is a legitimate challenge; it's very easy to get 90% correct but that last 10% can be a bitch.

And let's not even talk about trying to parse Perl.

Exposing the AST in XML is not a bad idea; it's a perfect match of the two technologies. You still have semantics to deal with, but we're a ways from being able to standardize those.

Now, as LISP has shown, programming straight to the AST, while it has its advantages, is a historical loser. But that doesn't make exposing it in a standard fashion a Bad Idea. On top of it, you layer a more conventional language... and as strongly as I am defending an XML-exposed AST, I even more strongly believe it would be a stupid, fatal mistake to make that the human-exposed language that one actually programs in. I've worked with a couple of things that only come close (XBL and XUL Templates, where the primary flaw of the latter is that it should be a language and isn't) and a thing that is an XML language (XSLT) and I think it was a grave error on both counts.

Even better if multiple languages could share one standard or at least semi-standard AST; sharing semantics has proven to be a non-starter I think but there's still hope at the syntax level. (.Net shows that trying to share semantics means you end up with five languages that are just different spellings of the same thing, only without the convenient AST in XML to work with.)

This isn't a pointless abstraction, but it is something that will probably only be useful on big projects. I say "probably" because if a language with this capability ever got off the ground, there might be interesting things that could be done that we've not even thought of.

One man's view on XML

[marciot]

I personally do not understand what the entire hype about XML is, or even specifically what problem it is supposed to solve. My understanding is that there was a big push for XML because of a perceived need for open document formats. The idea being that binary formats were proprietary, closed and non-portable.

If this is the problem XML intends to solve, then I feel it is a miguided effort. Binary formats are "closed" only in so far as we do not have access to the source of the program that created them. Once that source is available, binary file formats are open, portable, and a hell of a lot more space efficient than XML. JPEG is a binary file format, yet we have open standards and the committee who designed it released open source reference implementations of the decoder and encoder. Hence, JPEG is an open format and nobody goes around trying to stuff pixels in XML files.

I really think XML is a solution to the wrong problem. The problem is closed source software, not binary files.

-- Marcio

Re:You missed a key point in the article...

[Brandybuck]

You would never edit the raw XML of your source code...

Call me an old fart, but why couldn't I edit the raw source code? My PHB can't understand why I don't use MSWord to write C++ code. He can't grok the concept of plain text. "Puh-lane tekst" I keep telling me, but he keeps complaining that he wants my local variables in a different font. Now you come along validating his insanity!

The days of 4-space vs 8-space tab debates are over.

Here's a clue: those days were over decades ago. Some people still argue over it, but they're the type of people who argue over nothing. Just ignore them and move on. If you cater to their quirks and foibles you only encourage them. Here's the answer to that debate: it doesn't matter because it's too trivial to bother with.

Suddenly, parsing all that code becomes much easier, because we have a well-established XML validation mechanism.

Thank goodness! I don't know how many more years I could have put up with stupid compilers not being able to validate my code.

Drag an if-then block into your source code. Drag a for loop block into your source code. Your editor can collapse or expand blocks.

Since when did you need XML for this? Correct me if I'm mistaken, but doesn't Kate/Kdevelop do this already? I understand that many of you use that leprous shit of an editor that comes with Visual Studio. But that's no excuse to eliminate plain text source code. Get a real editor and stop dragging the rest of us down to your level.