Extensible Programming for the 21st Century

Anonymous Cowardly Lion writes "An interesting article written by a professor at the University of Toronto argues that next-generation programming systems will combine compilers, linkers, debuggers, and that other tools will be plugin frameworks [mirror], 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. It's a very insightful and thought-provoking read. Is this going to be the next generation of extensible programming?"

Comments

Go Greg!

[xcham]

The document is mirrored here to help compensate for the bandwidth deluge.

Next generation tools...

[Lord Grey]

... will obviously be "forbidden." Yes, I did RTFA.

been done

[studboy]

programs will be stored ... so that programmers can represent and process data and meta-data uniformly.

Yup. Back in the day, we called this "Lisp". It was about as readable as XML, but a hella lot more fun.

Re:been done

[ron_ivi]

Agreed, and even mentioned in TFA:

3. You don't need XML to do this.

Scheme proves by example that everything described in this article could have been done twenty years ago, and could be done today without XML.

And IMHO lisp's syntax has always had a nicer structure than XML's repetitive redundancy.

_<whatever>
__<you> want to do in <xml>xml</xml>
__</you>
_</whatever>

is nothing but a set of s-expressions that read much nicer in a lisp-like syntax:

(whatever
_(you want to do in (xml xml)
_)
)

IMveryHO the big failure of the lisp guys of old was that they were so proud of how many ')' they could put next to each other that it made their code harder to read than necessary. I bet XML would have failed too if it were commonly written

<whatever>
_<you> want to do in <xml> xml </xml></you></whatever>

(and yes, the _ are just there for /.'s formatting)

Re:been done

[Anonymous Coward]

The S-expression people put the attributes in as arguments; the element data is also just another argument, which is certainly a more uniform treatment.

Ex:

<a b="1" c="2" d="4">blahblahblah</a>

becomes something like:

(a "blahblahblah" (b 1 c 2 d 4))

or this:

(a "blahblahblah" b 1 c 2 d 4)

or this:

(a (b 1) (c 2) (d 4) "blahblahblah")

Take your pick.

The point stands that you don't need XML's syntax to get these sort of behaviors, and that's not really surprising; any sufficiently general syntax usually can accomodate any paradigm in another sufficiently general syntax. This probably has some metaphysical voodoo link with the Church-Turing thesis, formal languages, and computability, but I'm too lazy to care.

You could dispense with the element names if you didn't care about such things, although it makes it harder to reorder your arguments, of course. Then again, XML can't support this sort of ordered attribute list, now can it? Not directly, anyway. ;)

I'm not a Lisp or XML zealot, and I agree with you that if it's machine-generated, it doesn't really matter, but the Lisp people have a point that anything you claim to be able to do now with XML could have been done before with Lisp. Heck, DSSSL is based on Scheme.

* Note that I didn't quote the arguments; I'm assuming this is being fed to the read procedure, and not the evaluator.

Just what we need

[Anonymous Coward]

Extensible, so that each programmer can use a whole heap of functional and syntatic elements that no other programmer has ever heard of...

XML, so stuff that doesn't need to be human-readable is human-readable, and the whole mess is a good six times larger than it needs to be...

Plugins, so that everything can be dependant upon proprietary, bulky, inefficient runtime engines...

I am all for progress, and not married to old-school solutions by any means. However, some things can sound good in theory without actually representing progress.

Re:Can't wait

[X]

Now you can do this in C++, but look at what you need to implement to do it

It would be great, if instead, I could hook into the compiler and tell it exactly how it should handle vectors.

Umm... what makes you think that programming a compiler is going to be more straight forward than doing generic programming? That seems like a huge assumption to me.

The closest thing I've seen to what this article talks about was CLOS's MOP, which was great, but once again, a lot of people had a hard time groking it.

Let's see here..

[k98sven]

If I recall correctly,
Fourth-Generation languages was going to be the future of programming back in the early 80's?
(Machine code, Fortran/Basic-type languages and Pascal/C-type languages being the supposed first, second and third generations, IIRC)

Then in the early 90's.. OOP was going to save the world. Not that it hasn't had impact, but it certainly hasn't fundamentally changed things.

And now it's XML that's going to save the programmers, while the old-timers whine that we should all really be using Lisp.

Not that I'm a computer-language conservative myself, but it's worth pointing out that historically, there has been quite a big discrepancy between which languages the Comp-Sci researchers feel everyone should be using, and the ones which actually are used.

Hmm

[AdrianFletcher666]

So basically, we get to combine the speed of Java/.NET with the user friendliness of XML and the security of COM? May god have mercy on our souls...