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.

Re:Next generation tools...

[Impy the Impiuos Imp]

> 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.

Sounds like they've found a use for future eight trillion teraflop processors. Scripting on top of scripting on top of scripting. :(

Re:Next generation tools...

[E_elven]

Just for clarification: you don't actually code in XML. This is what it means:

<function>
<name>foo</name>
&nbs p; <abstract>Blah blah</abstract>
<args>
<arg>
<name>bar</name>
&nbs p; <type>int</type>
&nbs p; <purpose>Blah blah</purpose>
...

When you fire up your IDE, you'll see:

// abstract:
// Blah blah
// parm:
// bar -Blah blah
int foo(int bar)
{
...
}

Joke was funny, though.

Data and metadata by XML

[leandrod]

This is incredibly stupid. How come XML helps in dealing with data and metadata? Metadata *is* data.

What we really want is an user-extensible type system, like the one proposed by Date and Darwen in _The Third Manifesto_ for relational database systems. Remember, types are domains plus operators.

Re:Data and metadata by XML

[xcham]

This is incredibly stupid. How come XML helps in dealing with data and metadata? Metadata *is* data.

Just an observation. This comment was literally posted 2 minutes after the story went live on /. - thus there's absolutely no way in hell you've read the paper and already you're trashing it. How mature.

Re:Data and metadata by XML

[MisterFancypants]

This is incredibly stupid. How come XML helps in dealing with data and metadata? Metadata *is* data.

It goes up to 11, see. That's one higher.

Re:Data and metadata by XML

[sfjoe]

This is incredibly stupid. How come XML helps in dealing with data and metadata? Metadata *is* data.

Metadata is, of course, data. Sometimes, a finer-grained taxonomy method is helpful. After all, sausages and uranium are both matter, but calling them matter doesn't help me with my dinner selection.
Mmmmmm - sausage.

Re:Data and metadata by XML

[xcham]

No amount of explanation will fix that stupid idea.

According to you, and that's not the point. You don't go to a class and tell the professor he's full of shit when you haven't read the required reading for the course. You don't dispute something without a clear idea of what's being said.

It's not the fact that you disagree (heck, I disagree with some of it), but that you disagree without knowing what you're disagreeing with, exactly. As far as I'm concerned, you're just another /. forum monkey with nothing better than to do than post ill-informed knee-jerk reactions.

Re:Data and metadata by XML

[leandrod]

> Sometimes, a finer-grained taxonomy method is helpful

But when it comes to data it just confuses, because taxonomies imply a hierarchy, and hierarchies are hard to agree upon on the first place, are quite arbitrary, and tend to change quite fast and radically.

The relational model already provides a better alternative to taxinomies: attributes. And then, metadata becomes just data.

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

[Carnildo]

Having worked with both XML and Lisp, I'd say that Lisp is easier to read.

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

[Digital Avatar]

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

What really got me is that they think merging the functionality of a compiler, linker, debugger, et al. via some sort of component framework is really anything new. Forth and Lisp were producing tightly-integrated development systems _thirty years ago_. Thank you, Mr. Moore and Mr. McCarthy.

Re:been done

[Wolfkin]

Piling up all the closing parens makes the code *easier* to read, not harder. After you've been lisping for a few weeks, the parens just sorta disappear, and you rely on indentation to give you the overall structure of the current function, and then just add however many are left over at the end. Any good editor will let you know when you've put enough, and you can define a "fill out close parens to the top level" command in most.

Re:been done

[Tarantolato]

A cynical take on this article would be that it's sour grapes by a stranded Lisp/Smalltalk guy who never got used to doing things The Unix Way, and still wants to lead the unwashed masses kicking and screaming to the promised land.

"PUT DOWN THE VIM! WE HAVE YOU SURROUNDED!"

All cynicism aside, this is a mixed back. Extensible syntax is a great idea; and yeah, Lisp already had it in the 50's. What needs to happen for broader adoption is to do it in a natural Algolish syntax, which basically means limiting functionality. Languages like Python and Ruby (with lambdas and blocks/procs) are starting to do it and I expect to see others follow.

The whole "seamless translation into XML and back into any language of your choice" is a lovely idea, but even small bugs in implementation would handicap its usefulness considerably. It'd also take a tool oodles more complicated than gcc, which he doesn't seem to like.

Finally, tight coupling of language and development environment can mean added productivity, but it also tends to mean less flexibility in practice: this is one of several reasons that Smalltalk hasn't caught on.

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.

Re:been done

[makapuf]

So why not take the python approach and use the indentation as the structure ?

compare

(whatever _(you
want to
do
in (xml xml)
_)
)
(indentation doesn't follow strcture)

with

whatever :
you :
want to do in : xml

Re:been done

[boots@work]

This has been proposed and implemented several times as an alternative syntax. I think Arc is meant to have this, but it's hardly the first. I don't think it's ever really caught on.

Why?

- Sometimes it's nice to put code into things that don't reliable preserve whitespace, such as, say, comment fields on web sites.

- Parens are well-established in lisp. If you change it you give an additional barrier to people coming from other lisp dialects, without particularly helping people coming from elsewhere.

- Whitespace by itself is not enough. Do you want to write (+ 3 (* 4 5)) across 3-5 lines? Python ends up with fairly complex rules about backslashes, open parens, etc.

- One advantage of lisp is that it's easy to write out from a program. This is really not true of Python.

- If you accept that we need paren syntax, then you can wonder whether indentation should be supported as an alternative. But having two different syntaxes for one language, though an interesting idea, is likely to cause a lot of practical confusion.

So I think all you really want is an editor that ensures the indentation is always valid, and that can highlight parens and do other things. emacs goes a long way, but it could be better -- for example by making outer parens larger, as in TeX-printed or handwritten mathematics.

In my humble opinion what Lisp needs to take from Python is not semantic indentation, but rather a single standard dialect with good OS bindings. The last thing we need is yet another slightly incompatible dialect that can't bind to existing code. Sheesh; I love lisp but lisp implementers really exasperate me.

Can't wait

[exp(pi*sqrt(163))]

A good example is code like this in C++

Vector a,b,c;
. . .
c = a+2*b;

Written naively the overloaded '+' operator returns a vector object. But I don't want any object returned. I want the code to be expanded in place as

c[0] = a[0]+2*b[0]
c[1] = a[1]+2*b[1]
c[2] = a[2]+2*b[2]

Now you can do this in C++, but look at what you need to implement to do it. The code is a hideous nightmare of template metaprogramming. Of course you can do it in a language like C, but then you lose the ability to express yourself cleanly through code like 'c=a+2*b'.

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

Of course you'd clearly need to document your code well as people reading your code would also be forced to understand the plugins.

Re:Can't wait

[TwistedSquare]

Actually I believe this particular example might well be optimised out by the compiler to the code you mention. But your point is probably valid for trickier problems.

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.

Re:Can't wait

[PhrostyMcByte]

I'd think most compilers will already expand it to that. I know Visual C++.NET does.

Re:Can't wait

[exp(pi*sqrt(163))]

what makes you think that programming a compiler is going to be more straight forward

I don't know how to make it easier myself. I think it's a hard problem and I hope people smarter than me are working on it. But I have a hunch it can be made a lot easier than template metaprogramming, say. My reasoning is simply this - template metaprogramming wasn't designed to do the sorts of things that are being done with it, it's almost an accident that you can write stuff like Blitz++ or boost::mpl. I've a feeling that something designed to do this has got to be easier to use.

Re:Can't wait

[exp(pi*sqrt(163))]

Actually, this example often isn't optimized away which is why the Blitz++ library exists. In fact, the author of the library, Todd Veldhuizen, has written at least one paper spelling out what compiler developers need to do in order to ensure stuff like this is optimized away. I've done lots of experiments myself. As soon as you put something like my example line inside a template that is instantiated from another template etc. I've found compilers start missing what you think ought to be easy optimizations. It's very frustrating, I just want to tell the compiler myself how to do its job because it's often just a mindless application of a bunch of rewrite rules.

Re:Can't wait

[fdicostanzo]

> Written naively the overloaded '+' operator returns a vector object. But I don't want any object returned. I want the code to be expanded in place as...

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

But what if your code was to run on a vector processor (or even SSE, etc)? Your telling the compiler how to handle vectors (serially, in your example) would limit your speed.

a better method would be to use declarative/ functional semantics to describe what you want, and then have a compiler that would optimize that to the architecture. many examples exist.

I believe a big problem of procedural languages is over specification of procedure (by definition...)

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.

Wrong.

[Bingo Foo]

XML? Bah. Next generation languages will be written in "WIMNNWIS" (What I mean not necessarily what I say) and will run on processors liberally sprinkled with pixie dust.

Ah.. So the professor likes Eclipse

[the_skywise]

And suddenly he's propheysing the future?

Editors like Emacs, Visual SlickEdit and even the loved/loathed MS Visual Studio have plug-in frameworks.

As for XML being the "glue" for holding things together... No. It'll be a data neutral "modulator" you emit your data from your program by name in a particular format. Transmitting and receipt by the other programs will be handled by a remodulator. In between it might be XML, it might be binary, it might be whatever you feel like using that day.
(and no I haven't read the artile (FORBIDDEN)

I always remember Master and Margaritta.

[SharpFang]

How humans can tell what will be in a few years if they can't tell what will be tomorrow?
I'd completely agree if the claim wasn't "that next-generation programming systems will combine compilers"... but "should combine...".
Right, the idea is nice. But where will the market go, how will big corporations guide the development, what will become the new fancy or if there will be a new development that will render XML completely obsolete and feeling ugly comparing to that "new thing" - we don't know.

Rather Grand Conclusion ?

[beatleadam]

Instead of treating each new idea as a special case, they allow programmers to say what they want to, when they want to, as they want to.

Is this not the Ultimate goal of programming? The Holy Grail of programming perhaps?

Plugins?!

[Greger47]

Developers can add new or improved optimizations to SUIF by writing a filter and adding it to the compiler's configuration.

Dude, I have enough trouble debugging my code without having my homemade, guaranteed to be buggy, optimizer introducing even more bugs...

/greger

Next generation for ME

[mcrbids]

So here I am, coding away merrily, when I run into a *STICKY* problem.

I'm running applications as user X, and need to access data as user Y. I have all the routines and everything written (in PHP) to access the data, but I need to do this as user Y, while accessing the data as user X.

There's just no easy way to do this. You have to use some kind of glue (such as XML), along with parsers, socket connections, pipes, shared memory, and all that jazz just to be able to access data remotely.

Ouch.

What I'd like to see is the concept of a "remote object". Imagine standard OOP, except that a particular object doesn't have to exist in the same memory/process space as the parent.

For example, instantiate an object on a remote server, or as another user on the same server, or at least in a different memory space as the same user & server.

The biggest problem with XML is that it's heavy, very heavy, and requires specialized scripting in order to work.

If you have an class already written that does what you need, you should be able to simply instantiate that object in the context you need it to run in, and then begin using it, COM style.

Obviously, some calls (such as GLOBAL) would be affected or even disabled with such functionality - but can you imagine the benefits?

Ah well. That world doesn't exist, yet.

Re:Next generation for ME

[Greger47]

So whats wrong with CORBA? Here's one among several implementations for PHP: http://sourceforge.net/projects/universe-phpext/

/greger

Re:Next generation for ME

[warriorpostman]

.NET provides "remoting" and Java provides RMI. These are essentially Remote Objects. CORBA provides this cross-platform. If I understand exactly what you're asking for, it already exists. Clients can instantiate objects remotely, and maintain virtually local control of these remote objects, using the aforementioned technologies.

However, if you're using PHP, the whole concept of remote object has to be patched together (just like in ASP) simply because there is no true "state" in web applications.

Solution looking for a problem?

[Carnildo]

A brief read of the article indicates that the author is trying to solve problems that don't exist, and as a result, is coming up with solutions that are worse than the supposed problems.

Sounds like Forth

[Anonymous Coward]

Except for that XML stuff.

I don't understand this fascination with XML. It's just a generic container for storing data - nothing more. OpenOffice uses it as the underlying format for storing documents, but that doesn't mean I have to deal with it when writing a document. It's transparent to the end user.

In the same way, , why should I have to deal with it when coding? It's sort of like requiring coders to be able to pop up a hex editor and cruise through the code.

Remember MVC (model-view-controller)? Being able to disassociate the different parts was considered a good thing. Swing decided it was too cumbersome, ASP.NET joins them at the hip, and now we've come all the around, with Microsoft proclaiming with XAML that everything should be dumped into one big XML box.

Bleah.

Hot air?

[Henrik S. Hansen]

Ok. Perhaps there are some interesting things to pick out from this. But it is a giant leap to claim that the next big thing will be extensible programming. I think we can all remember XML, OOP, and all the rest.

Good ideas, which are the correct choice for some problem domains (OOP is for instance often a good choice for GUI's , IMO). But they're not the best choice for everything

So this is Yet Another Buzzword. At least he didn't shorten it to XP. ;)

Why XML?

[ProfessionalCookie]

XML is great and all but there are a few killer disadvantages. It can be really really slow. It can mean generating huge files. A well documented open format is better than a "human readable" XML template. How many XML files have you looked at that have this kind of thing :

<DATA>2ED4F64676766DC7B87A76A65B1722303FFF</DATA&g t;

Sometimes XML is not the answer. That being said there are also so really great uses, but XML was not made for everything.

Re:Why XML?

[Impy the Impiuos Imp]

The love of XML and Java stun me. It's the younger, LISP-ignorant generations who are infatuated with this crap.

I blame the education system, with all mealy mouthed teachers who wince if Little Johnny cries about too much homework causing him to lose 10 minutes from his seven hours of Halo every evening.

Teacher of the Future: Come on, Johnny! You can do it! You can program it!

Johnny: It's too hard!

TotF: Johnny! Johnny! (starts cabbage patching)

Johnny: Computer, create a program to figure the fifth digit of PI and tell me it.

Computer: 9

TotF: I knew you could do it, Johnny!

Johnny: Yey!

Note to 'tards: Computer makes assumptions for Little Johnny. Shut the hell up!

Re:Why XML?

[dcam]

You know what the next killer algorithms will be for? Processing XML.

XML is good in a few limited circumstances. It works with small amounts of data, and is great for communication. And yet XML is being touted as the cure for cancer and being applied in every possible. MS has bought it big time with Longhorn from what I can see.

The way we are going, we are going to end with a lot of data stored and transmitted in XML and a lot of applications committed to XML. And you know what is wrong with that? XML doesn't scale well.

The XML thing is quite depressing. You take something that is good and useful and apply it everywhere, whether it is appropriate or not. Gah.

Summary Of The Summary

[Pan T. Hose]

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, rather than monolithic applications.

This is not the next generation of programming systems but rather the present one for pretty much everyone except for those using Microsoft tools.

Programmers will be able to extend the syntax of programming languages,

Again, nothing new.

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

There is no way in hell that would ever happen. Ever.

It's a very insightful and thought-provoking read. Is this going to be the next generation of extensible programming?

No.

Now, I will read the entire article, but somehow, I am not holding my breath...

Yeah huh...

[grasshoppa]

...and by the 21st century, weren't we all supposed to have flying cars?

Personally, I'll take the flying cars...;)

Re:Yeah huh...

[Tumbleweed]

Yep, and around the same time, we'll all be typing on Dvorak keyboards in Esperanto talking about the new flat tax. :)

The laughs keep coming

[fuzzy12345]

So this guy's familiar with UNIX, he's familiar with Lisp, yet he thinks the future is XML and hideous frameworks with ever-changing APIs? Not often you se e someone with a hammer AND a screwdriver using the hammer to pound screws.

yup

[Janek Kozicki]

that next-generation programming systems will combine compilers, linkers, debuggers, and that other tools will be plugin frameworks, rather than monolithic applications.

yup, it already happened. more than 10 years ago. it's called Rule of modularity and Rule of Composition. In case you don't know. It's the Basics of the Unix Philosophy

Extensible Programming == BAD!

[Space_Soldier]

We've seen what can happen to languages when countries get conquered. English is one of the best examples. Try to read some old English to see for yourself. With XPL (Extensible Programming Language), you cannot say anymore that I know C++, or I know C#. Someone will ask you to maintain some code, and you'll take a look at it and have no idea what is going on, until you learn the extensions. This will happen over and over again with every project you are supposed to maintain. This is BRAIN FRYING and huge possibilities for mistakes. It is just like waking up everyday and being asked to speak in another human language. Today English, tomorrow French, the day after tomorrow Bengali, can you do it?

Re:Extensible Programming == BAD!

[poincare]

I very much agree. I think the reason that Java has risen to its status today is because it constrains the programmer to be explicit with what methods are being called upon what data, and thus easier for someone other than the orginal writter to understand what's going on. In Java A=B will do the same thing every time (as far as the programmer is concerned), but in C++, A=B may mean any number of things depending on operator overloading. I think XML has the same advantage over S-expressions that a strongly typed programming language (E.G. Java) has over an untyped language: transparency. Image if HTML was based on S-expressions:

(html (head (title "bla")) (body (bgcolor blue)(b (a (href "http://osdn.com/osdnsearch.pl") (style "text-decoration: none") (fontsize "-2") (face "verdana") Search)))(i Here))))

Sure if you have an editor that will show you matching (), then the above s-expression makes sense, but otherwise it would be a nightmare trying to figure out why Here was not in bold. HTML and XML are much easier for humans to read (and thus debug) because it's clear where in the tree you are editing, just as it's easier to program in Jave because you are forced to be explicit about what data types you are manipulating and what calls you are making.

Re:Extensible Programming == BAD!

[StrawberryFrog]

Someone will ask you to maintain some code, and you'll take a look at it and have no idea what is going on, until you learn the extensions. This will happen over and over again with every project you are supposed to maintain.

Eh, that's no different from the usual: starting a new job and being asked to maintain and extend a regular 100 000 line program: you'll take a look at it and have no idea what is going on, until you learn the objects and functions.

In both cases, standard libraries and readable, maintainable, consitent design and coding can make your learning curve more pleasant. But how often does that happen in business?

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.

Re:Let's see here..

[ezzzD55J]

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.

True, but that doesn't mean the researchers are wrong..!

Re:Let's see here..

[Tony]

...while the old-timers whine that we should all really be using Lisp.

That could be because Lisp provides most of the features outlined in the article, without the problems?

Re:Let's see here..

[ViolentGreen]

A lot of people today still see OOP is a fad that will pass. On the otherhand, there has always been resistance to new programming paradigms. The early machine-code programmers resisted FORTRAN. The FORTRAN programmers resisted the Algol-like languages. People (including myself) are still not sure about the tradeoffs of OOP. If this is the next big thing, it is really no suprise that the majority of people here seem to oppose it.

The more things change...

[treerex]

that next-generation programming systems will combine compilers, linkers, debuggers,

...THINK Pascal (for the Mac) was doing this almost 20 years ago: the editor served as the front end to the compiler --- so the syntax highlighting in the THINK Pascal editor was driven by the lexer (really was the lexer): you knew about syntax errors immediately. The debugger was fully integrated into the environment. It was really sweet, and probably one of the best programming environments ever written.

and that other tools will be plugin frameworks

Like Unix pipes and Eclipse?

Tomorrow arrived yesterday and appears today.

They'll have to change the name ...

[magefile]

eXtensible Programming sounds too much like eXtreme Programming.

Maybe they can call it Extensible Fox?

Back To the Future!

[But Who's Counting]

Is it just me, or did this "visionary genius" just describe a Lisp Machine from 30 years ago? Man, if this is "progress", we're screwed.

Back to the future.

[X]

It's kind of funny when you think about it. Smalltalk and CLOS (and for that matter their predicessors) seem quite close to what he's describing (admittedly without the XML side of things). I guess it just follows the "those who ignore history are doomed to repeat it" mantra.

I'm not sure why he thinks it is important that the meta object protocol stuff be done in XML. I mean, why not just in the language itself? This has been shown to work with both of the above.

The problem he's not seeing of course, is that this approach essentially results in each project having it's own "language", which must be understood before one can participate in it.

No one here wants to hear this...

[EatenByAGrue]

but much of this 'vision' is implemented in Microsoft's .Net Framework and Visual Studio!

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...

Re:That's exactly the reason why ...

[PuffCammy]

When they were building the tower of Babel, they all had the same language, after God smited them and brought down the tower, they lost that unified language

Based on the comment so far...

[Squidbait]

...I'd say roughly 10% of you have actually read the article. He mentions specifically many of the criticisms you've mentioned. I don't think this is earth shattering, but some of the ideas are pretty good.

I for one like the idea of source code stored as XML, but not displayed or edited as XML. Imagine, viewing source code in the format you specify (eg positioning of braces). And it would be really nice to be able to treat source code as data without breaking your back writing a parser. And for those of you worried about bloat - honestly, we're talking about text files here!

Re:Based on the comment so far...

[hoggoth]

Agreed.

The original development of XML came from the desire to separate HTML content and formatting into two distinct parts. Soon you will use XHTML and CSS to have machine parsable, web-spiderable content and any formatting you like.

The same goal of separating content and formatting applies to programs. Use XML internally. Your choice of editor can use braces, brackets, tab-indenting, BEGIN/END, or whatever you like best to format the code.

The internal XML format will be easily manipulated by the program itself.

And yes, all this has been possible with LISP for a very long time, before many of you were born. But hey, if the buzzword of the day let's us push this powerfull overdue idea into the mainstream, I'm all for it.

Re:Hit refresh to access the article

[RobertLTux]

somebody saw the /. coming and doesn't want to have their MSIIS server in a whimpering heap in the corner?

Sounds good in theory

[rhysweatherley]

Being able to extend ones compiler with different plugins sounds good in theory. Until you need to send your code to someone in Florida who doesn't have exactly the same setup as you do.

It's bad enough tracking down the umpteen libraries that an open source program depends upon now. Now we have to track "Bob's special compiler" as well?

Besides, we already have compiler "plugins" for extending the syntax. They have names like bison and flex. Anyone can layer new functionality on a language through meta-translation, if there is a reason to do so. But you better have a reason!

Re:Wait a minute. This has happened before

[corngrower]

What benefits does XML have over EDI when transmitting business data? I know of none. The only reason this substitution is happening is that XML happens to be the big buzzword among PHB's.

For something - retriveing stock qootes over the internet, I certainly can see its use. But when you're talking about company A's computer talking to company B's computer, maybe EDI is a better way to go, especially if company A or company B is still using dial-up lines (there are a lot of small companies out therer), considering the verbosity of XML and the efficiency of EDI.

Now I understand....

[EmbeddedJanitor]

why simple application software needs 2G of RAM and multi-GHz CPUs to get the responsiveness I got on a 100MHz 486 with Win3.11.

Interesting operators

[jfdawes]

What maybe a few people have missed is that there will be some incredibly interesting "hardware" out there in the future.

Some people have already demonstrated things like using DNA computers to solve travelling salesman problems, Quantum Computing and Grid Computers.

Perhaps what this article is suggesting is one way for developers of entirely new "hardware" to easily supply operators and types (syntax) to any programming language.

It would be interesting to be able to write program a that talked directly to the nervous system using fairly standard <your language of choice> syntax, that when compiled produced a real piece of nano "machinery".

zombie UNIX haters back from the dead

[hak1du]

We have had these kinds of integrated, extensible systems: Smalltalk-80, Lisp, and others. And we have had the same tired, old arguments against UNIX since its original design (you can read up on them in the UNIX Hater's Handbook). Smalltalk-80 and Lisp didn't fail because there was some grand conspiracy against them, they failed because people voted with their feet.

Most real-world programmers apparently just want to put up a bunch of dialog boxes and windows, interact with the user a little, and interact with a database. They don't want to extend the programming tools or language or modify the optimizer, they want it to just do what they need it to do. And if it doesn't do what they need it to do, they just pick a different language and environment and don't go on a crusade to develop zillions of plug-ins and modifications. Programmers stick with text files not because they believe that they are the best representation, but because they actually work pretty much everywhere.

Some of the changes Wilson advocates are happening. That's not surprising, given that the features he advocates have been around for decades and many people are familiar with them. But they are happening in an incremental way and people pick and choose carefully which aspects of Lisp and Smalltalk-80 they like and which ones they don't. For example, you can get versions of GNU C that output interface definitions in XML format. IBM VisualAge maintains Java sources inside databases (not text files) and permits incremental recompilation. Many Java development environments have plug-in architectures. Many editors now permit structure-based editing operations ("refactoring") and display "styled" source code, using the raw ASCII text just as a formal (non-XML) representation of the program structure. Aspect-oriented programming adds a great deal of extensibility to languages like C++ and Java. On the other hand, general-purpose macros are out--language designers made deliberate decisions not to include them in Java, C#, and similar languages.

Altogether, it looks to me like Wilson is merely restating what is already happening and combining that with a good dose of UNIX hatred. If he would like the industry to move in a different direction, there is a simple way of doing that: he should implement what he thinks needs to be done. I think an XML-based programming language (and several have been proposed) has about as much chance at flying as a lead balloon, but, hey, surprise us.

Extensible Schmextensible

[blair1q]

How about developing Maintainable programming?

dealing with XML

[Yobgod Ababua]

That's exactly one of the author's points! You shouldn't (and in his vision won't) have to deal with the XML directly, -unless- you are one of the people actually writing new plugins rather than just using them.

His suggestion is primarily that we start using editors that transparently present the 'code file' in our choice of format rather than forcing us to edit it byte-by-byte. It's like the syntax-highlighting you probably use now, only effecting more than just colors.

Using XML for the underlying syntax is mostly irrelevant to his proposal, but he suggests it merely because it is currently popular, well suppoerted, and well suited to it's primary job of presenting data in an easily MACHINE READABLE format.

His proposal is, in fact, exactly the opposite of requiring coders to pop open a hex editor, and he likens our current ASCII-only coding methods to doing exactly that at one point.

XML is heavily misused

[apankrat]

The funny part is that eventhough in 99% of the cases XML is indeed transparent to the user it is still selected over binary formats (DER, TLV, whatever) because it's ASCII !

Having talked to religious XML zealots in a past, I gathered that they either were simply not aware of the alternatives or were 'afraid' of the binary formats due to the nature of their programming environments (VB & co). Duh.

Overlooking the obvious

[BigLinuxGuy]

Sheesh! I can't believe nobody else saw the point of the gentleman's article. After all, it's not about improving efficiency of the programmer or the system. It's all about empowering authors to write more books about new programming languages that rely on Moore's Law to make them semi-viable (oh, and to draw in more royalties from the panoply of books about the new programming languages). It's sort of like the fad of patterns, eXtreme Programming, etc. Few places really use the principles promulgated in the all-too-many books on the subject and those that do eventually (d)evolve back into more conventional practices. Who benefits most? The authors do (not that I'm against authors making a buck).

That changes nothing

[mldqj]

You will still be using the same set of programming skills, no matter how the programs are represented and stored.

Bad?

[Yobgod Ababua]

That's not how I read the article's proposal at all!

The code you've been asked to maintain is stored in some standard machine readable format. When you come in you then use the code-editor program to view it using -your- extensions, and the underlying primatives of the code objects are presented in the manner you're used to.

Whatever extensions and transformations the original author used to create the code would be relatively meaningless, which (for many of the reasons you descibe) is a good thing.

I doubt it.

[srussell]

That would be a departure from what I see happening in softare development today. There seem to be three dominant camps:

• Low level developers. People programming in C; the ones writing Linux and KDE.
• Quasi-low level developers. People programming in Java; the one writing much of the business software right now.
• High level developers. People programming in scripting languages, like Ruby, Python, PHP, JSP, Javascript.

The second group is the most visible, because business loves them. The first group is the second most visible, because -- while it isn't as "hot" a technology in Monster -- most of the software we use is written at this level. I suspect that the third group is the one that will goose the business community in the future, and will probably eclipse the second group. I'd guess that this is a submarine technology; you don't see many job postings for Ruby programmers, but a heck of a lot of software is being written in it. Even more is being written in PHP, JSP, and Python.

I imagine something like Python or Ruby, or some other high-level language that's easy to write software with, coupled with a decent compiler will be the real winner in the near future. Get some type inferrence for one of these languages, and the ability to compile it (as with Parrot), and group two will mostly go away. Java claims to be a more productive language than C because of higher level features; modern scripting languages are even better at increasing productivity, and their only real limitation is their speed, or lack of it. Just as Java eventually overcame the speed issue, so, too, do I expect some future version of a scripting language.

But, maybe Java will hang in there. If you look at Java 1.5, you see a lot of increased syntactic sugar that has usually been only available in languages like Ruby -- I've heard that this was motivated by similar constructions in C#. Perhaps Java or C# will evolve enough syntactic sugar that hacking out code will be as easy as doing so in Ruby. IMO, it'll take a more radical language change than that provided by 1.5; my biggest complaint about Java these days is that it gets in your way; a large chunk of the code you write for any application is infrastructure, and you write it over, and over, and over (anybody else sick of ActionListeners yet?). I'd like to see the typing system changed to type inferrence... but it is possible.

I doubt, however, that software development is going to evolve into choosing black boxes from a set of tools and plugging them into each other, mostly because to do cover all possible jobs, the framework would have to have access to a huge amount of fine-grained tools, and by that point, you might as well just write the code yourself. Look at the size of the Java APIs. How many packages are there? How many classes? How many methods? This is making our lives, as programmers, easier... how?

revolutionary or late?

[jdkane]

I think Microsoft is already addressing the professor's points in the .NET platform ... or at least starting to head in that general direction already:

* compilers, linkers, debuggers, and other tools will be plugin frameworks, rather than monolithic applications;

For example, see the .Net Microsoft.CSharp Namespace, the System.Codedom namespace to represent code as objects, etc. in the framework class library.

* programmers will be able to extend the syntax of programming languages; and

don't know about extension of languages yet, but the next one is interesting ....

* programs will be stored as XML documents, so that programmers can represent and process data and meta-data uniformly.

take a look at Microsoft's XAML technology -- describing code by using XML. That's the general direction.

I'm sure other technology frameworks have similar things, but I'm not as familiar with those technologies.

Metrowerks Codewarrior

[MaineCoon]

Metrowerks Codewarrior is an IDE (and I believe has a commandline tool for processing the project file ala Make) that uses plugin based preprocessors, compilers, prelinkers, linkers, postlinkers, and other tools, which the master project controls execution of (and through a nice GUI, allows easy association of file extensions with their tools and build information). It's been doing this since at least '97.

Inventing Lisp again

[richieb]

Paul Graham said that all languages hope to become Lisp. This sounds like just another attempt.

Why not just use Lisp?

This is far from a new idea.

[voodoo1man]

Terry Winograd wrote a paper, called Breaking the complexity barrier (again), in 1973 (it is reprinted as the first paper in Barstow, Shrobe, and Sandewall's excellent compilation, Interactive Programming Environments, 1984). In it he described the integrated programming environment of the future, speculated on the role AI would play in it, described the importance of extendable syntax and the need for data-code representation, and noted that all this would need to be deeply and intimately interconnected, all the while taking a technology agnostic view.

Where Wilson goes wrong is in assuming that this kind of environment will be built based on plug-ins. The interrelationships needed between the components to get the required level of functionality are too great. What many people have already noted is that the current Unix environment is in fact based on plug-in development. Editors, debuggers and compilers are modularized as programs, with clean lines of communication between them in the forms of files and streams (which Unix again abstracts to one concept). The limitation of this system lies in the fact that the modules all use their own separate address spaces, and hence each one has to have a private representation of the program. This can't be mitigated by having the separate tools communicate to a central database (this is the most that Wilson's proposal of using XML as the underlying format can accomplish), because then the method of communication would be the limiting factor. Of course, you can use the neutral code-data representation to make the communications between the modules and the database be in terms of sending closures (from reading the paper, I don't think Wilson even considers this), but then you've just designed a single distributed address space, and in the process removed all the encapsulation and modularity advantages of the communication links (not to mention introducing a whole slew of concurrency issues)!

One such integrated system has been built in the past, called Interlisp. Barstow, Shrobe, and Sandewall's book (mentioned above) has a few papers that describe the system, but briefly a few lessons can be distilled from it. First of all, the system itself was an integrated development environment for a dialect of Lisp, where everything was done in one in-core address space: source code (including comments) was represented by data structures in memory, upon which the structure editor (residing in the same address space) operated directly. Code could either be interpreted from the data structure or compiled by the (yes, in-core) compiler. There were several extended packages (besides a Lisp macro-like facility), notably the structure editor and "Conversational LISP," a pseudo-natural language command-prompt parsing system. Although source code (and data) could be serialized to files (there was a sophisticated change-tracking facility that took care of this), the usual way of working was by saving the core image to disk and loading it next session, so the whole environment was persistent. There were hooks for everything from the parser to the compiler to error handling down to the most basic frame-handling code of the stack-based VM, and in order to implement the facilities mentioned above (and some other ones I left out, like the ever-present DWIM automatic error-correction facility) the code took full advantage of them. This caused some trouble when it came to portability of the components and the Interlisp itself (the heavy interdependence caused many problems in bootstrapping the system). Some of these incidents are documented in Barstow et al.'s book, but the Interlisp bootstrapping difficulty has been mentioned in all of the Interlisp porting papers I've read. Unfortunately, I don't think a system with those capabilities can be built with the rescrictions of modularization, since all of the things it did are applicable to programming in any language, and to do them required precisely the

The horror... the horror...

[Trejkaz]

Even without bugs in the implementation, the XML format won't work to a general enough degree. Let's see... we already have a format which many programming languages translate to, and which can be translated back to a limited degree, and that's object code. Translating object code back to a programming language may work, sure, but it doesn't generate the same level of semantics which were there in the original.

Now translate the object code to XML. Is it any better? Probably not. It's now readable, but so is machine code, if you have the right program. And this guy is proposing to use a program which renders the XML in a familiar format anyway, which is really only one jump from using a program which renders the machine code in a familiar format.

Allowing multiple languages in the whole thing seems to naively ignore the fact that different languages have different features. What does the guy with his editor configured for Java, see when viewing a file that some C++ developer put operator overloading into?

The whole thing smacks of "if it starts with X, it must be good."

I say fuck it in the eye. We don't need source code which translates to other source code, we need source code which compiles to a module which can reliably use, and be reliably used by, modules written in any other language, and we need all these modules to be crashproof and crackproof when they run. They should save the research for the things which matter, and stop misusing XML. :-/

Re:The horror... the horror...

[hyc]

"half human-readable" is just a bit too wishy-washy for me. HTML is human readable, and it does its job pretty well (aside from true horizontal positioning control, instead of faking it with Lists and Tables) but that's because the 'T' stands for TEXT and it's intended primarily for human readable text.

For anything that is meant to be machine-processed, like a low level data format, human-readability is a non-issue. For anything that is meant as general purpose, large capacity data storage, human-readability is a liability because the volume of metadata eclipses the volume of data.

As a slightly better example, ASN.1 is sometimes tedious and even overly verbose, but it is far more compact than XML, is at least as expressive, and is trivial to parse with a simple state machine.

What annoys me about "XML" is that a "Markup Language" is supposed to describe data *for presentation*, that's what Markup is all about. Using it as a general purpose database format is truly a misuse of the SGML technology.

This is so Interlisp

[Animats]

Most of what he's talking about was in Interlisp, the first Really Big Integrated Programming Environment. Integrated debugging. EMACS. Program storage as "workspaces". Extensibility. Intelligent assistants ("DWIM", or "Do What I Mean", a set of heuristics for correcting Warren Titelbaum's most common typing errors.)

The ultimate expression of this was realized with the Symbolics LISP machine. Everything was in LISP. Everything was hackable. The MIT Space Cadet keyboard, with six shift keys (Shift, Ctrl, Meta, Super, Hyper, and Top). All 2^16 keycodes could be bound to any EMACS function.

I've used both. They sucked. Partly because they didn't work very well, but mostly because all that flexibilty and programmability had negative value. Language and UI design are hard. Evading the problem by making everything changeable does not fix the problem.

His point about XML being another way to put LISP S-expressions into textual form is well taken, though. They're both trees. The problem with LISP is that while the data structures are valuable, the programming notation really is a pain.

LISP works well as a web development environment. Viamall, which later became Yahoo Store, was written in LISP. That was one of the first web applications that really did something elaborate on the server. You could create web pages on the server from a web browser. And the overhead was lower than with XML, where you're forever re-parsing text strings into trees.

Compiler extension (was:Can't wait)

[real gumby]

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

Well of course that's what templates are. Yes, their syntax is horrendous but that's what comes of trying to wedge the concept into the existing crannies of C syntax (or when, as Stroustrup remarked to me once, "the ecological niche was already polluted").

If you hanker for a language in which metasyntactic extension is natural, you need Lisp macros (or here and here for a more complex example), Scheme "hygenic" macros or the CLOS MOP.

But if you really want to consider "hooking into the compiler" as you say then you should look at the reflective programming work, the ground work for which was laid down almost 25 years ago by Brian Cantwell Smith and was even implemented, by me and others, back then. Although a lot of work continued in this area that vein pretty much got mined: unless you can think up a completely new control structure there's not a huge amount more you can do with such a system than you could with a normal metasyntactic extension mechanism.

HTH
-d

XML metadata.

[Edward Kmett]

I've been working on a pet project very similar to this for a couple of years now off and on.

Currently, I'm constructing the editor as a javascript/xul/xbl based application under mozilla (not yet publicly released) and tossing the documents over jabber to a code repository which connects as another client. Other pieces in the suite, such as the compiler, talk over jabber to the repository, helping to ensure modularity.

Why mozilla? It gives me a cross platform editing environment and I can take advantage of the built in xhtml/mathml rendering. (Although, I admit I'm largely hamstrung by the faulty mathml rendering on Mac OS X at the moment)

Why jabber? It serves as a glorified RPC mechanism for exchanging XML document fragments for me. Its primary advantage compared to SOAP, XML RPC, etc, is that I can allow the repository or execution environment to send out updates to the clients, rather than rely on client based polling. After all, in this day and age of everything lying being NAT, you usually can't open sockets to clients directly. It also has the advantage that it makes evolving the platform into a collaboration environment a simple logical progression, rather than something grafted on as an afterthought.

My main interest is in what advantages you derive from allowing a rich text markup language and extensible grammar, and the ability to tag information and retain markup across versions.

A smarter editor allows you to move towards allowing dynamically defined operators, which can have their precedence defined in terms of a partial ordering with respect to one or more existing operator, that way you can red flag during the editing process when something is ambiguous. Superscripts, subscripts, radicals, Riemann sums are allowed by defining small extensions to the grammar in the language and loading them into the editor.

The potential for language tagging comments or method labels for internationalization is nifty, but more than a bit of a Pandora's box.

An XML namespace for version control means the repository can store one document much like a cvs system. By having the editor submit a series of change requests to the repository rather than edit the document directly, integrity is ensured.

Since you have a fairly stable set of tags you can now embed more information for statistical collection, loop counting from debugging compiles. Links to hand- or auto-generated proofs of algorithmic correctness, big-O information, etc.

So, yes, there is a value to storing the data in XML and making the editor smarter.

However, one primary is that any such project has a rather high bar to clear to become even marginally useful.

There are also a number of interesting problems regarding how to handle certain types of code refactoring and traditional text editing operations in this sort of environment.

Re:been done, README in StumpWM

[kampi]

Funny thing that I read a very similar story last year: it was the README of the window manager stumpwm, which was written in Common Lisp.

Cite:

The current trends shown by Big Software is to use XML for all data formats. It won't be long before we have XML interpreters, XML data being interpreted as functions:

<math>
<operator>plus</operator>
< operand>4</operand>
<operand>5</operand>
</math>

I predict within 2 years Big Software will announce the Next Big
Thing: XML++. An Object Oriented language with all the advantages of
the superior XML data format coupled with modern advancements in
Server side Web based technologies. XML Code and XML Data will be
almost interchangeable, except for some tweaky markup which will be
justified by the need for more aggressive innovative content creation
services.

But why wait? We have it all already.

Want to see for yourself?
http://www.nongnu.org/stumpwm

Is the problem in the tools or ourselves?

[trenobus]

If the goal is to express programs more briefly, presumably at a "higher level", then I don't believe an extensible language alone can solve the problem. After all, we already have languages which are extensible to varying degrees. In my experience, code that maximizes the use of language extensibility tends to be the most cryptic to read, at least until you thoroughly understand all the extensions used. Witness C++ code that makes heavy use of overloading and templates.

A large part of the problem (IMHO) is the slowness of developers in standardizing common data types and programming idioms. I'm not a linguist, but there must be some interesting parallels here with the development of human language. However, there is one important difference: programmers are usually more concerned about getting a computer to understand their programs than getting other programmers to understand them. Thus, there isn't the same motivation that Tak and Nog would have had to agree on the linguistic expressions and social conventions that would allow them to hunt the woolly mammoth and divide up the women.

In fact, experienced programmers do tend to standardize their own use of language extensions, libraries, and program development tools, as this does enable them to program more efficiently. Many software companies do the same, which is probably how they manage to accomplish anything at all. But most software companies place very little priority on creating industry standards (unless, of course, they think they can own them).

Related Discussion...

[Meijer]

on Lambda the Ultimate.

LISP machine, anyone?

[RAMMS EIN]

This so much reminds me of the LISP machine. How many times are they going to reinvent it?

It's such a pity that the code for the LISP machine is guarded by intellectual property protections that even the copyright holder doesn't know its way about.

This will be in Longhorn

[objwiz]

IMO, this is nothing new. Microsoft's Longhorn presentation, at the PDC in LA last fall, made it pretty clear that Longhorn will be shipped with the compiler and an extensive class framework "installed".

C# is part of the operating system and the file system. The operating system will generate "partial classes" for new file "types" and other functionality on demand.

Since the compiler will be part of the OS, I could write an application that could generate code and run it, leveraging existing classes already on the system.

Rebuttal

[Oestergaard]

compilers, linkers, debuggers, and other tools will be plugin frameworks, rather than monolithic applications

Uh? My compiler acts as a "plugin" via. make, which is called from emacs. If I want another compiler, I tell make, and voila' it's "plugged in". Welcome to the world of 'NIX Mr. Wilson.

What is worse, every tool's command-line mini-language is different from every other's

But this is their strength! Different tools solve different problems - and they use different languages to describe what they do, because they are *fundamentally* different (awk is not sed is not grep is not ls). How would you possibly write up a single language to describe what both sed and awk does, without poorly re-creating perl?

Attempts to stick to simple on-or-off options lead to monsters like gcc, which now has so many flags that programmers are using genetic algorithms to explore them

Most CS majors will know that modern CPU architectures are complex beasts, and that it is pretty hard to come up with which combination of optimization methods will yield the best performance on some particular revision of some particular CPU on some particular hardware configuration. Nothing mysterious about that. I completely fail to see what that has to do with command line options.

And instead of squeezing their intentions through the narrow filter of command-line mini-languages, programmers can specify their desires using loops, conditionals, method calls, and all the other features of familiar languages

Instead of squeezing my intentions thru the narrow filter of command-line mini-languages, I can specify my desires using what a standard shell (like bash) has to offer. Ladies and gentlemen of the jury, this is not making sense!

The result is that today's Windows developers can write programs in Visual Basic, C++, or Python that use Visual Studio to compile and run a program, Excel to analyze its performance, and Word to check the spelling of the final report.

Oh come on, please... So if I develop on windows, I can use VB, C++ and Python. How is this relevant? There are more useful languages available on the dreaded "command line systems" ('NIX), but let's just agree that there are plenty of languages available on most OS'es out there - regardless of the windowiness or commandlineness of the system.

Using VS to compile and run the application? Well, if your command line absolutely sucks, they I can imagine why you would want to launch your app from your editor - a matter of taste too maybe. But relevant? How?

Somehow I need COM in order to put numbers into Excel? Ever heard of CSV? You know, new-line terminated lines of T-E-X-T which can be processed by these little all-different tools, like, for example, Excel.

The part about Word and spell-checking of a final report... What? What's your point? If I use COM for developing software, I can spell-check in Word? If I use a command line, I cannot spell check a report that I write about it in Word?

A similar API allows the popular memory-checking tool Purify to be used in place of Visual Studio's own debugger, and so on.

Absolutely! Plusings make perfect sense certain places. Dude - GUD is written in Emacs LISP, it's a plugin for GDB. You could write an elisp file for Purify as well - in fact, Intel actually ships an elisp file for their debugger, even on Windows... Plugins make sense some places, other places they don't. Which, lo and behold, is why they are used certain places and not others.

One of the great ironies of the early 21st Century is that the programmers who build component systems for others are strangely reluctant to componentize their own tools. Compilers and linkers are still monolithic command-line applications: files go in, files come out

Why does he not see what he's writing?!? A compiler reads a number of input files and generate an output file - this is a perfect match for a command-line too

Not the golden solution...

[fikx]

This is not the golden, unifying solution or anything, but there's some ideas in there that could be useful.
I saw his thougts in the first section of the paper and took the rest as some quick examples on how it might look.
I can think of plenty of directions this could go. The first thing I got out of it is applying the same level of abstraction we try to implement in programs to the act of programming itself. This is happening in all kinds of areas of computers anyway (like abstracting file systems, GUI's, etc.) why not put programming into the mix?
It's not about using scripting instead of programming languages, it sounded more like building the same features into our programming tools as we build into the apps we write with 'em.

why all the negative reactions? If its about loosing your editor to write code, you didn't read the article. If it's about too much abtraction to program, then it seems kinda hypocritical considering all the frameworks we use for other people's tools. Or is it just irritation about having to relearn a bit and keep on coding as before? The complaints about XML are odd too. He choose a machine-parseable, human-readable widely used format as a possible way to store programs at a low level.

Prog Languages will become like human languages

[smishra]

I think the natural progression of programming languages is to become more like human languages. We are a long way from it but coming closer everyday.

What most people don't realize is that most of the developments in programming languages knowingly or unknowingly follow this trend. For example, object oriented programming (a la C++, Java etc etc) is closely related to how our brain sees the world as a hierarchy of objects. Type inference (as in ML) is closely related to how our brain derives useful information from incomplete data.

Computer languages are moving away from small languages to bigger more expressive languages. The evolution of Perl I think reflects this trend. XML etc are just syntactic sugar. They don't reflect any fundamental steps. The difficult parts have yet to be done.

In many ways we are at the beginning of the evolution of computer languages. I think the next 10-20 years are going to be very exciting.

While agreeing with Paul Graham that programming languages represent notation, I don't quite agree that they must evolve as slowly as changes in notation. I think there is a real difference between how notation is used to represent meaning in programming languages and how they are used in human languages. Different domains demand different notations of differing precision

In conclusion, computer or programming languages will evolve to be closer to human languages. There will be specializations of the language for different domains. This is akin to using mathematical notation to describe mathematics rather than write each rlationship out in wordy English (or other language).

Re:Glaring error at beginning of article

[voodoo1man]

If sucess is measured by longevity, COBOL & Fortran are the most sucessful programming systems in history.

The problem here is in the definition of system. FORTRAN and COBOL are programming languages - the systems for programming in them have changed drastically over the years, from punched cards to teletypes to full-screen glass teletypes. The Unix command line, on the other hand, has pretty much stayed the same since it was introduced. You can only type in the current prompt, editing the prompt is awkward, and previous input and output scrolls up off the screen. The three biggest changes have been job control (so you can edit your command line with vi), pipes, and editing-friendly shells (tcsh has nice key-bindings borrowed from Emacs for moving point, deleting, etc.). I think they were introduced in that chronological order, although I could be mistaken.