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

Extensible?

[jawtheshark]

My programming languages were always extensible. Be it over procedures or functions, objects and inheritance, fuck even the good old programmable interrupts did the job! Programming languages don't limit, they enable you to do what you want.

Look, I can understand XML to convey data.... but honestly, you don't need to use XML for everything under the sun. Proven old good methods work just fine, thank you very much.

Re:Extensible?

[eln]

XML now is what OOP was 15 years ago: Useful for some things, but shoehorned into every possible application, whether it actually made any sense or not, and whether or not it made things easier or more difficult.

Re:Extensible?

[Anonymous Coward]

15 years ago? That's where OOP is now.

Re:Extensible?

[Umbral Blot]

I for one welcome new tools. Well that is if they are tools and not straight jackets. For example a new language construct (for eaxmple generic classes in Java 5) is an example of a good tool. You can use if if you need it, but you can also ignore it. Perhaps XML syntax might be useful in some areas (although I can't see how ...), but forcing the entire language to be in it seems too much like a straight jacket to me.

Re:Extensible?

[Cthefuture]

I could not agree more.

At it's core XML is nothing. It's so generic, so basic, so flexible, whatever you want to call it, that it's completely pointless. Yes, you read that right, the structure is so flexible that it's not really structure any more.

XML is just dumb in general. It's like saying: I've got this new, exciting, powerful data container called "The English language."

Yeah, OK, whatever.

Re:Extensible?

[conradp]

XML has definite value, but that value has just as definitely been overhyped.

I bet all of us have written code to save and restore configuration files or data files of some sort or another. You start with a flat file, if you're really dumb you store values implicitly by position, if you're a bit more clever perhaps you opt for using keyword/value pairs. Later you decide you want to allow newlines in the values and need to write special code for that, so you use double-quotes. Then you decide you need double-quotes in your values, and you invent an escaping mechanism. After some more development you realize that some subset of your keyword/value pairs has to be multiply-instanced, so you need some mechanism to have "objects" each with their own keyword/value pairs. And so on... Eventually someone on another project needs to read your file, and you have to explain all these idiosyncrocies to them so they can write some parsing code...

XML simplifies all that by defining a common syntax in which you can encode your information. It's easy to gradually expand your format by adding XML fields, and if you show the file to anyone else they instantly get a pretty good idea of what the information means; plus they have access to a bunch of libraries to parse it (SAX and DOM) and there are predefined ways to escape newlines, quotes, braces, and so forth.

Of course, XML is only a syntax. There are a billion other syntaxes that could probably accomplish the same things, but somehow XML became the standard; that in and of itself has value because everyone uses it and knows how to read and write it. But programs can't interoperate and read and write the same files until they agree on symantics, i.e. what tags will be where and what each field really means. I've encountered this several times, some customer says "write the data in XML format" and I have a hard time explaining to them that, yes, we can write it in XML, but that's not sufficient information to define the file format, that's really just the beginning.

Re:Extensible?

[Retric]

Ok when your storing data files you might as well use a database vs XML. But, if your storing configuration files I like to use (int;name lenght) (name as an ascii str) (int; element id) (int; data type) (int; data size) (data)

It's low over head and easy to parce so you can store a tun of data, simple or complex data, with ease. It's also easy to check the syntax so you know you did not mess up when writing or reading the data. It's also easy to store list's or nest data. Ok now if you tell me how XML is so much better than this fine but other than being a little more readable by hand I don't see what the advantage is. As to data type's;

0 = new tree
1 = string ASCII
2 = String Unicode
10 = signed int
20 = unsigned int
30 = floating point number (format 1) 31 = floating point number (format 2) ...
I basicly keep aything under 10,000 as uneversal format's and use stuff over that for odd adhock stuff which I don't have time to deconstruct.

Re:Extensible?

[conradp]

Thank you very much, I think you've just proven my point better than I ever could have!

Re:Extensible?

[Decaff]

0 = new tree
1 = string ASCII
2 = String Unicode
10 = signed int
20 = unsigned int
30 = floating point number (format 1) 31 = floating point number (format 2) ...
I basicly keep aything under 10,000 as uneversal format's and use stuff over that for odd adhock stuff which I don't have time to deconstruct.

If I had come across one of your configuration files, and did not have this key to the meaning, I would have had no idea how to interpret it.

This is exactly the argument for using XML.

Re:Extensible?

[Decaff]

XML is not Human readable on anything ther than the most simple app.

Having used XML extensively, I would disagree with this.

And do you want people to be able to mess with config files when they don't have the documentation?

But that is exactly why XML is useful:
1. A configuration file will most likely have a DTD or schema, so that if you modify it, those modifications can be validated, as can the structure of the entire XML file.
2. XML is extensible. It is perfectly acceptable to add your own tags, which give additional meaning to the file. Tags which aren't understood by a particular application will be safely ignored.
3. XML IS human readable: Which would you feel more confident editing:

<setting type="integer">123</setting>

or

10,123

(Was the indication for integer 10? I don't remember. Someone might tell me that '10' means 'integer', but there is nothing else to indicate this)

Good XML will be self-documenting, but even bad XML is better than

10,123

Re:Extensible?

[Decaff]

With your XML way you have no documentation directly in the file.

You mean like:

<-- This is a note about the following settings -->?

If you have a config file all settings should be documented in there and if you have a data file you should be able to have one documentation for an example entry at the beginning of the file.

I think you are missing the point. With a configuration file like this, you HAVE to have the documentation in there to interpret the settings. With XML you don't.

The "name=value" syntax is a lot easier to parse than XML and allows you to store the settings in memory in the way you want.

Why should you care how easy the file is to parse? Don't bother to parse it yourself - use an API like SAX - and then you can store the settings in whatever way you like.

Some other points:

The name=value syntax isn't portable or expandable. Suppose the name or value contains '='? You will need to define what delimiter should be used for the name and value. XML is a defined standard for delimiting values.

This syntax does not allow for trees. XML can do this.

How do you handle strings that require non-printable characters, like newlines? XML has a standard for this.

Suppose you have put in the documentation about what format is and what the parameters mean and then the software is dispatched to a foreign country? XML is an international standard.

Suppose someone else wants to add new settings to the configuration file. Will this prevent your software working? With their names of properties clash with yours? These matters are handled in XML.

Finally, there is nothing in the file that would allow any software to automatically detect that this is a name=value file. XML always starts with <?xml.

XML is an easy-to-use standard solution to these problems, with many well-supported high-quality libraries and tools to handle it. It can be as simple or complicated as you like. What is the objection?

Re:Extensible?

[ph1ll]

The World does not need better programming languages.

The World needs better programmers.

Is this guy serious?

[FyRE666]

...programmatic entities -- like: record. Wacky, but perhaps wacky enough to be possible?

Hopefully, no. Christ almighty, why is there this surge in interest for pointless layers of abstraction on top of the code? It seems some people are desperate to do anything to avoid actual implementation (work?), prefering to dance around the periphery of a project, adding needless fluff and speedbumps. Honestly, will the addition of XML markup in source code REALLY help to advance a project, make the code more readable or avoid bugs?

Re:Is this guy serious?

[lukewarmfusion]

No, don't you prefer this:

<invoke-expr method="myMethod"><evaluate>record</evaluate></inv oke-expr>

over this:

someObj.myMethod(record);

? I, for one, welcome the obscuring verbosity. It's a challenge. It's exciting. It's job security.

Re:Is this guy serious?

[hasdikarlsam]

You mean, like Lisp has been capable of for the last thirty years?

I think you're looking for macros. Proper, Lisp macros, not the weak text-substitution nonsense C comes with. :D

Ooh, this story is great. Next on, how to reinvent the wheel - in XML!

Re:Is this guy serious?

[Anonymous Coward]

Oddly enough, all the tools you mention are already possible and exist today, without XML.

XML has no value in and of itself. Standardized data formats may well be valuable, but there's nothing magic about angle brackets and slashes. A standardized binary format would be just as useful.

Programming languages already have a standardized syntax. Having them also conform to XML syntax adds nothing. Heck, programming languages are also even human-readable, for those that still think that's an important feature of XML.

Re:Is this guy serious?

[IO ERROR]

No. This is just needless complexity. XML is great for some things, but it is not the silver bullet for every problem in the known universe!

In this case, XML will probably make programming much more difficult and code far less readable -- to humans. The compiler might like it a little better, but the compiler is supposed to serve us, not the other way around. The tool serves us. At least in an ideal world.

In the real world we use tools to get work done. If the tools are inconvenient to use or not suitable to the problem at hand, they don't get used. For the sake of humanity, this needs to be killed now before he comes up with a prototype, and drives future generations of programmers to madness.

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.

Re:Is this guy serious?

[mpcooke3]

They're trying to make the XML-programming more powerful. what about:

<execute instruction="true">100101110111</execute>

It's readable but, remains flexible.

Matt
Bah slashdot stripping away all the xml goodness

Re:Is this guy serious?

[Curtman]

If the tools are inconvenient to use or not suitable to the problem at hand, they don't get used.

Tell that to the Internet Explorer development team.

Re:Is this guy serious?

[Coryoth]

I just skimmed the article a bit, but I believe the idea is that you write your code the way you want to but the code is translated into the xml format and stored that way. When you reopen it, it's translated back into your preferred syntax.

So what we're really talking about is something like Microsofts CLR, Java's bytecode, or Parrot code, with the ability to de-compile it back into the language of your choice? We just get the added bonus that the "compiled" code is not actually compiled, and is stored in the most padded verbose unreadable format that could reasonably be arranged? Doesn't sound like a vast improvement.

Jedidiah.

Re:Is this guy serious?

[interiot]

In the begining (1954, according to my O'Reilly poster) was Cobol. People moaned and complained.

Next came Lisp (1958). They had to literally invent garbage collection simply to be able to create the language. In 2005, garbage collection is finally starting to be found in almost every non-embedded language.

1982 brought us Postscript. It's new! Exciting new syntax. Well, okay, Lisp thought of it first.

1996 brought the world XML. Exciting new syntax! Again!

Re:Is this guy serious?

[Frank T. Lofaro Jr.]

And if it fails to help you keep your job, you have yet another XML item to add to your resume. :)

Re:Is this guy serious?

[Coryoth]

That is a good idea. And I can think of many other similiar features you might want for an editor / project development system. However I doubt XML will end up being the best solution. I would guess that the best solution would be a custom file format that was desgined for this reason.

Brilliant idea. Let's start by just using parentheses for delimiters instead of all that stuff, and just have the first word inside the parentheses define the operation, and the other (space delimited, why not?) words simply be the list of arguments to be processed. That sounds nifty. Now lets take that example from the article and convert it into this condensed format...

<cond>
<test>
<compare-expr operator="less">
<field-expr field="age">
<evaluate>record</evaluate>
</field-expr>
<evaluate>threshold</evaluate>
</compare-expr>
</test>
<body>
<invoke-expr method="release">
<evaluate>record</evaluate>
</invoke-expr>
</body>
</cond>

becomes something like

(if (< (field age (record)) (threshold))
(body
(release (record))
)
)

Hmm, that looks oddly familiar... if we just changed a few of the keywords a litte.. I wonder if someone has thought of something like this before...

Jedidiah

Re:Is this guy serious?

[mpcooke3]

I wouldn't say that. most of the companies i work with supply data in XML formats. generally they're very easy to read/debug and process and using standard libraries.

Some companies on the other hand try to give us proprietary binary data streams over tcp or incremental relational data dumps over TCP. Guess which i prefer.

Re:Is this guy serious?

[ggambett]

I'm dying to know what the other 0.9% of programmers do!!!

Re:Is this guy serious?

[tomhudson]

Well, some xml fanboy must be pissed to mod the parent as a troll ... but xml has some serious flaws in respect to data representations for code.

Try to modely objects and their instances in a multiple inheritance hierarchy in xml w/o getting REALLY redundant.

xml is for people who think that multiple inheritance (think C++) is a mistake (they prefer single inheritance a la delphi or java - both of which then had to add mechanisms to work around the flawed single-inheritance model).

Me, I'd rather go back to coding in assembler than try to fit everything into an xml world (can you imagine representing assembler mnemonics in xml? What a waste of time).

Re:Is this guy serious?

[ComputerSlicer23]

You've never ever had to deal with an external company to get data have you? I deal with thousands (literally thousands). We have defined our own CSV format. Of which in the end, we have had to accomodate about 4-6 variations of it depending on the type of CSV (gotta love CSV, there are different variations on how to encapsulate/esape comma's and quotes).

Then there are the 100 (it's probably closer to 250 formats, of which only 100 are still being used) other formats we accept in. Most of them had to be manually reverse engineered. We are exporting data out of a third party software. The people on the other end of the phone didn't write the software, they don't know how the software works. So we get to deduce all of that from them.

The 10th time you come across a variable length record file, where the sample didn't have all of the record types that exist, you'll be more then a touch peveed about it. Okay, so *K records are 432 bytes, *M records are 345 bytes. Aggg! I've never seen a *I record before. Whoopie, I get to go add one line of code recompile and deploy the software to overcome the lack of file documentation. You'll think to yourself, you know, if this was in XML, I could just skip this whole sub-tree. All the data I need, I've already found, so just clue the parser in to read to the end of the data, and I'll start on the next record.

In the end, I'm much rather throw a bit of RAM and some CPU at the problem and teach the software the semantics it needs to know to read XML DTD's to figure out how to extract data, instead of trying to reverse engineer a binary file format (gotta love people who use file formats for export but forget that Endianness exists so the same file format isn't portable across platforms). Figuring out the parsing of each file type is the part that is time consuming. Once you get the actual state machine to parse the data built, it's cake to actually extract the information I need.

There's a reason everyone documents a file format. Why not just use a general case one until you see that there is in fact a speed problem. 90% of the time, speed of parsing the damn data, and the storage overhead it incurs is minimal relative to the amount of resources wasted dealing with writting efficient parsers for each file type. The documentation and validation of the data is built in to XML (yeah, no more error detection of the system that are newline oriented, and the input system accepts carriage returns in the fields, or just corrupted on particular row of a huge CSV file). The file format is well maintained and can express all data desired (I've seen more then my fair share of file formats that if you put the delimiter in a datafile, it won't bother to escape it, I love those).

Just like I've learned to love the STL. The STL is better, faster, more memory efficient, and well organized then any code I'll probably ever write in my life. Your arguments sound very similar to the idiots I see expousing how they can out do the STL, right up until I make them benchmark their code against the most naive STL implementation you could imagine of their code.

I'm fairly sure the same is true of the XML parsers. Sure the files themselves are overly verbose. However, barring just ludicrust constraints (either enormous files, or really limited resources on the device), does it make any difference?

I'd never use XML internally to transport data around (in that case your arguments make some sense). My problem, is that there are thousands of people who might want data from me. I'd much rather use XML and tell them to use a stock XML parser then give them the EBNF to read my and some sample Lex/Yacc on how to process it. I would provide an XML export to any third party who wanted one. It'd be extremely simple, and it'd solve a ton of problems for me if I could just send and recieve data in XML. I'd have saved several man years here at my job if everyone who handed me data did it in an XML format. Sure, I'd have to have spent $5-10K extra on CPU and drive space (given that I've spent on the order of $250K-$500K it would have been no big deal).

Kirby

Re:Is this guy serious?

[Unknown Lamer]

The original Lisp system didn't have a GC. See Communcation of the ACM, Vol 3 Issue 4 Page 184 "Recursive Expressions and Their Computation Machine, Part I" (McCarthy).

The original Lisp had both S- and M-exps. It was a bit different than the Lisp we know. The important part is that it didn't have GC until later.

Re:Is this guy serious?

[tomhudson]

The *big* deal is why any serious programmer would even *want* to be able to transform his code. I've got better things to do with my time.

If I disagree with how someone else formats their c code, I can always pass it through a "pretty-print" filter, or write my own, so no big deal there.

If I want to code using c-style or c++-style syntax and then translate it into, say, java, again no big deal.

But to even think that any tool I use has to "understand" the language is wrong. The only tool that has to have an understanding of the language is the compiler for that language (and me - but I'm a "tool" too :-).

All this will lead to is (even more) sub-optimal code, as people try to "leverage" the supposed value of xml.

In other words, when coding, keep in mind the general case (for future expandability/maintenance), but always program for the specific case. This whole "store your code as xml" thing has NO benefits over the original source, which you can always shuffle around and manipulate as you see fit. If you want to store it as xml, you can always either write your own converter, or use one that someone else has written.

shhhhh

[Neil Blender]

Larry Wall might be listening.

Yea, Good Idea

[the_mad_poster]

Oh, that would be just wonderful. I was just thinking about how I could take my nicely modularized source files and bloat them into 450kb monstrosities without actually adding any value along the way.

Wait, I have an idea, why don't we all just run this script before we start a new job and then paste bits of the junk output randomly throughout the source files?

perl -e "print pack 'c*', rand(255) for(1..$ARGV[0]);" 2500

Dumbest. Idea. Ever.

Damn...

[ackthpt]

They should have put the < and > keys in the middle of the keyboard.

Short answer, no

[Anonymous Coward]

<content="N0!!!!!!!!!!!!!">
</answer>

Re:Short answer, no

[shogun]

You left the DTD off, we'll unfortunantly have to ignore your reponse.

Re:Short answer, no

[legirons]

Think you missed some punctuation...

<?xml version="1.0" encoding="ISO-8859-1"?>
<answer type="long" xmlns:h="http://www.w3.org/TR/slashdot/answer">
<content="![CDATA[N0&exclamation;&exclamation;&exc lamation;&exclamation;&exclamation;&exclamation;&e xclamation;&exclamation;&exclamation;]]" />
</answer>

Oh, yeah, *that*'ll fly...

[jonadab]

We all know how programmers like languages that require typing a lot of
verbose and lengthy expressions. Y'ever notice how *popular* COBOL is?
Did you notice how many more languages have copied Pascal's style of
delimiters BEGIN/END versus the C style {/} or the lisp style (/), and
how popular those languages are?

It's different for data, because you don't type them in by hand most of
the time; you write a program that generates them.

already have this

[CastrTroy]

Most good IDE's already support autoformatting a document to fit the indenting and bracketing to the user. I don't see how putting formatting as a core part of the language will really help the language at all.

Not to mention the fact that programming languages (not assembly) by definition, are extensible. Most programming languages provide loops, if statements, and ways to define classes, methods, and variables. Some programming languages provide standard libraries so you don't have to do everything from scratch. I don't see anything new that this will offer.

Re:Umm...

[WD_40]

Seriously. Isn't software bloated enough? Why obfuscate things further. Dumbest... idea... ever.

Silly article

[photon317]

This article argues that next-generation programming systems can accomplish this by combining three specific technologies: -> Compilers, linkers, debuggers, and other tools that are frameworks for plug-ins, rather than monolithic applications. -> Programming languages that allow programmers to extend their syntax. -> Programs that are stored as XML documents, so programmers can represent and process data and meta-data uniformly.

1 - Compilers with plug-in architectures - GCC anyone? I know, he probably means something quicker and easier than writing new front- and back- ends for the Gnu Compiler Collection, but the concept is already out there.

2 - Just about any modern language does this to some degree depending on your definition. Under even the most rigorous definition of this, the good old language LISP does it with flair. Users can extend LISP syntax with ease, and user-added extended LISP syntax is virtually indistinguishable in style and functionality from the built-in elements of the language.

3 - Since existing languages have a well-known syntax which is easily machine parseable (in fact, that's what the parser and compiler do every time you use them on your source code), existing computer languages are already in a format which allows easy conversion into other formats and representation, and the gathering of metadata. Converting semicolons, whitespace, and parentheses (or whatever your language of choice uses) to xml tags doesn't really change anything, except to make things uglier and harder to type.

Re:I don't understand

[Viking Coder]

XML is certainly more portable than binary code

That's a huge fricking lie that I wish would die.

Your TCP/IP packets don't all start and end with < and >, and they seem to be fairly portable.

Endian-ness and packing are not rocket science.

It's a LISP I tell you

[ebunga]

S-expr's and xml are interchangeable, for the most part. Congratulations, you can now be a total degenerate and program in xmlisp.

Meta Language

[LetterJ]

For those that haven't seen it, there's a guy who's done something similar with MetaL, his meta programming language in XML that generates several existing languages out of it.

http://www.meta-language.net/

XML Lisp!

[acidrain]

Wow, I never had this much trouble posting on slashdot before. Try making a joke in XML. Your screwed... First it rejects repeated tags and then silently deletes the tags it doesn't like.

<parenthesis>
<parenthesis>
a
<comma>
b
</parenthesis>
c
</parenthesis>

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!

[Piquan]

At a guess, it segfaults when printf tries to read its formatting string and gets (on most platforms) a null pointer instead.

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

ASN.1 and XML

[Anonymous Cowherd X]

Programs are written by humans and they should stay easily legible and comprehensive to humans. Going to such extremes as to use XML as the author of the article suggests would defeat that purpose, it's a common trap that people who get too deeply involved with something fall into - they want to make everything use the object of their obsession. I don't recall any ASN.1 zealots trying to push for something that extreme, but with XML there are more and more people who are pushing for XML to be where it should not.

Re:ASN.1 and XML

[Anonymous Cowherd X]

Your editor would make the code easily legible and comprehensive to humans.

Such an editor introduces an unnecessary layer of abstraction which only makes coding more complex and error-prone. The real experts will need to know how to at least read if not write the underlying XML code because there will be cases where just using your abstract higher-level editor will be insufficient to track down a bug. There is no need for this, parsers are not going to be more efficient because of it and humans will not be able to do their jobs better because of it.

Re:Possible.

[jonadab]

> I love C syntax, but it's stale and there are many things we can improve upon.

The problem with C is not the syntax; it's the semantics of the language that
are stuck in the twentieth century. Sure, there are improvements that could
be made to the syntax, but good syntax doesn't make a language good. C needs
semantic things: automatic memory management, dynamic length strings, garbage
collection, numeric types that automatically promote as needed, context-aware
functions, mixins, unicode strings that automatically keep track of their
encoding and know what a grapheme is, that sort of thing.

You missed a key point in the article...

[malakai]

From the article:

We believe that next-generation programming systems will most likely store source code as XML, rather than as flat text. Programmers will not see or edit XML tags; instead, their editors will render these models to create human-friendly views, just like Web browsers and other WYSIWYG editors. For example, a program stored on disk like this:

<doc>Only replace below threshold</doc>
<cond>
<test>
<compare-expr operator="less">
<field-expr field="age">
<evaluate>record</evaluate>
</field-expr>
<evaluate>threshold</evaluate>
</compare-expr>
</test>
<body>
<invoke-expr method="release">
<evaluate>record</evaluate>
</invoke-expr>
</body>
</cond>

would be viewed and edited like this: // Only replace below threshold
if (record.age > threshold) {
record.release();
}

Crucially, code will not be stored as uninterpreted CDATA within XML documents and programmers will not see (much less type in) XML tags. Such a representation would have all the disadvantages of JSPs, Ant, and other hybrid systems, without bringing any tangible benefits. Instead, XML will represent the program's deep structure. Only time and experimentation will tell whether this turns out to be something like an annotated syntax tree or something more abstract.

It's not that big of a deal to implement. Just get the major IDE's to play along, all will no doubt retain the ability to persist or convert to ASCII tokens when needed. The benefit comes when your in a very large enterprise project and you want to write some automated code testing or style checking, or even security audits. Being abstracted from the specific languages TOKENS lets you write a relative language neutral code auditor with ease.

I'd easily use XSL + XPATH to do some major change over using a big ass regex.

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

[Tackhead]

> We believe that next-generation programming systems will most likely store source code as XML, rather than as flat text. Programmers will not see or edit XML tags; instead, their editors will render these models to create human-friendly views, just like Web browsers and other WYSIWYG editors. For example, a program stored on disk like this:

Slashdot: IT/Security: Tuesday, January 18, 2006:
"New MyDOOM.OOP virus attacks programmers"

A new virus has been unleashed against developers. The new virus exploits an XML parsing vulnerability in /usr/local/vi and /usr/local/bin/emacs...

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

[Lusa]

I'm not certain I see any real benefits listed, for 2, 3 and 4 this currently exists without using XML. This is because of something very simple... languages have formally defined syntax. Thats so the compiler can do its job without becoming a mind reader to work out what the programmer really meant. I'm not even sure how its possible using XML as a storage mechanism (whilst still editing something that looks like normal source code) will force well defined variable names. That comes down to the discipline of the programmer in question, I could still use i, j, k and l if I wanted to.

If 4 was ever implemented, you would be welcoming in maybe the slowest programming language on the planet. Besides, drag and drop already exists (VB anyone?) not to mention most IDE's will have templates which provide what you want at a quicker rate and I wouldn't even want to think of how big the dnd pallete would need to be for all the possible language constructs out there.

If I were to pick one example of where this already exists I'd pick Eclipse, though Visual Studio has similar features. It creates in memory AST's of the source being edited so that most refactoring operations are a breeze (2). This also means it validates the code as its being typed (3). Templates allow dropping in most common language constructs and it can automagically fill in what it thinks are the most appropriate variables for method calls (4).

So far, besides the first point the rest already exists..

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

[tomhudson]

I'll believe it when I see it (and maybe not even then :-)

1 Formatting. As mentioned in the article. The days of 4-space vs 8-space tab debates are over. The days of curly-braces-on-the-same-line vs next-line debates are over. You view your source the way you want to, other developers view it the way they want; the underlying XML stays the same.

You can already do that with a simple script on any source. No nead for xml.

2 Changing stuff. As mentioned by the parent. If (for example) variable names are well-defined, then the IDE can go and rename them all at will.

Again, no big deal for a simple script (which is what a lot of code obfuscation scripts do).

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

Just because something parses ok doesn't mean it's valid code ... look at how much stuff parses ok, compiles ok, but doesn't run as expected.

4 ... Your editor can collapse or expand blocks.

... both vi and kate already do this ...

Your editor only allows you to use declared variable names in assignments.

Not a good idea for languages that auto-vivify unpredeclared variables ... or languages that allow the creation of new variables and/or new types of variables at runtime, or for anonymous variables (and anon. functions/methods) ... or for dynamically-generated runtime code.

I doubt I'll be using it any time in the next decade.

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.

Haskell is a language for writing languages.

[shapr]

This is a standard paradigm in the Haskell world. You write a new language that fits the problem domain. These are called Domain Specific Languages
For example, Simon Peyton-Jones wrote a combinator library to describe financial contracts and used it to describe the collapse of Enron. (With fascinating conclusions!)
Paul Hudak has written Dance and Haskore. Dance is a language that describes dance choreography, with a handy OpenGL viewer. Haskore is a music scoring language where code looks like:

> cMajScale = Tempo 2
> (line [c 4 en [], d 4 en [], e 4 en [], f 4 en [],
> g 4 en [], a 4 en [], b 4 en [], c 5 en []])

Languages, spoken or programming, or any other means of expression is most efficient when it fits the problem domain.

If this sort of thing interests you, Lambda The Ultimate is a good forum to learn more.

XAML

[DreamTheater]

http://longhorn.msdn.microsoft.com/lhsdk/core/over views/about%20xaml.aspx

Aren't they already here?

[Jesus 2.0]

Don't certain crappy HTML-producing languages, for example CFML, already operate this way?

For example (and yes, I've forgotten my crappy CFML syntax, so this is pseudo-crappy CFML (as opposed to crappy pseudo-CFML)),

<CF-FOR INDEX="I" START="0" END="5" STEP="1">
<CF-PRINT>%I%</CF-PRINT>
<CF-IF CONDITION="I=3">
<CF-PRINT>Aw yeah, baby, three!</CF-PRINT>
</CF-IF>
</CF-FOR>

And, to expand upon my question from my subject:

Aren't they already here? And aren't they already crappy?

Re:Syntactic Sugar

[emurphy42]

It is being proposed as an intermediate language for easy translation. From TFA:

Programmers will not see or edit XML tags; instead, their editors will render these models to create human-friendly views, just like Web browsers and other WYSIWYG editors. For example, a program stored on disk like this:

<doc>Only replace below threshold</doc>
<cond>
<test>
<compare-expr operator="less">
<field-expr field="age">
<evaluate>record</evaluate>
</field-expr>
<evaluate>threshold</evaluate>
</compare-expr>
</test>
<body>
<invoke-expr method="release">
<evaluate>record</evaluate>
</invoke-expr>
</body>
</cond>

would be viewed and edited like this:

// Only replace below threshold
if (record.age &lt; threshold) {
record.release();
}

Crucially, code will not be stored as uninterpreted CDATA within XML documents and programmers will not see (much less type in) XML tags. Such a representation would have all the disadvantages of JSPs, Ant, and other hybrid systems, without bringing any tangible benefits. Instead, XML will represent the program's deep structure.

zerg

[Lord Omlette]

Reading the article, I don't think anyone would ever actually see the XML unless they edited the file w/ their own text editor. I think the point is that the editor adds and parses the XML for its own benefit. See, our text files were written in ASCII, now Unicode. Therefore, the evolution to a higher representation is (supposedly) logical. The best way to reason about it is a /. post I saw many moons ago, something like: "You wouldn't put ASCII on your résumé, would you? So why would you put XML?"

If I'm wrong, then this might be slightly more interesting in the long run than, say, Cyclone, where you have to learn a tiny amount more of additional syntax to mark that "this pointer was meant to point to data, not code", "this pointer should not write beyond this boundary", "this function has no business mucking up its stack", etc.

Alternatively, look at Visual Studio.NET.

/**
* @author Lord Omlette
* zOMG WTF
*/

vs.

/// <comment>
/// <author>Lord Omlette</author>
/// zOMG WTF
/// </comment>

The latter is a bit more readable but more annoying to write. Better we have tools to generate this stuff for us.

And then someone will come out of the woodworks to say "Knuth had Literate Programming back in the 80s, why the fuck aren't we using that?" but that's another rant altogether.

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:One man's view on XML

[dvdeug]

My understanding is that there was a big push for XML because of a perceived need for open document formats.

The advantage of XML is that you can use an off the shelf parser for every language instead of writing a new parser for each language. Let someone else handle the parsing and you handle only what you have to.

As opposed to computer languages now, where most modern languages (LISP-family excepted) have context-dependent grammars that are incredibly hard to parse correctly and each language has to have a parser written specially for it.

Binary formats are "closed" only in so far as we do not have access to the source of the program that created them.

Yeah, I'm sure that if you got the code to Microsoft Word, you could figure out the format just like that.

Even if you can, then you add another large ball of code to your project, for reading Word files. In the end, you've got a dozen different libraries attached, each one for reading a different format of file.

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.

Look at how many file formats the average graphical viewer has to support. Each one has its own library, its own bugs, its own security holes...

JPEG is an open format and nobody goes around trying to stuff pixels in XML files.

No; they stuff pixels in PNG files and TIFF files and PNM files and GIF files and a dozen other formats that need to be parsed by completely different parsers.

Re:One man's view on XML

[elhedran]

No; they stuff pixels in PNG files and TIFF files and PNM files and GIF files and a dozen other formats that need to be parsed by completely different parsers.

You say that like its a bad thing.

png is good for icons and webpage graphics (unless your target is IE). Its compresses well, is lossless, and has good transparency

tiff is a good choice for very large, very high color images, such as producing for poster prints

pnm are an excellent format for doing batch transformations (such as sticking together, rotations, etc. Just see the pnm* tools with any Linux Distro.

gif is paletted, and compress better than png's for low color images. If you only have 20 or so colors and only a need for a mask (or perhaps would like some animation) gif is your bet. See 'screensavers' on mobile phones.

In your world, webpages would take much longer to load, poster prints seem faded and image transformation tools would take forever. Oh, and I wouldn't be able to fit a 'screensaver' on my mobile phone. All because you can't be bothered to use one of the many, existing, image transformation tools.

Repeat with me:

[Zangief]

-XML is not the panacea.

-XML was made for comunication between different programs, not for humans to write or think in.

-This was done before in LISP.

10 times each morning. If in a week you are still thinking about this, call me back.

Lisp: The Programmable Programming Language

[Piquan]

If you think that extensible programming languages aren't already here, then read On Lisp (some familiarity with Lisp is necessary).

Why do people think XML is good for this stuff?

[Tom7]

Why do people love to use XML for all sorts of inappropriate things?

XML does not make data immediately understandable. All it does is remove one parsing problem, leaving the much more important problem of understanding the meaning of the tags, data, and their combination.

XML might make sense as a compiler intermediate format, or even as a source archive format, but it has essentially nothing to offer in tems of extensible syntaxes (except for reminding us that the surface syntax of a programming language and the abstract syntax it represents can be as independent as we choose) or semantics in programming languages. (By the end of the article, this is essentially the point he comes to, with the only argument for XML being that it is popular.)

<comment><type="funny">

[ZiZ]

<do-in-order type="step">
<step order="1"><pontificate subject="programming languages"/></step>
<step order="2"><ellipsis/></step>
<step order="3"><invoke-slashdot cliche="list-of-steps">profit!</invoke-slashdot></ step>
</do-in-order>
<forget-formatting/>
<welc ome-overlords type="needlessly complicated, obfuscated, and wordy"/>
</invoke-slashdot>
</rant>
<remark type="obligatory-attempt-at-wit">But it could be worthwhile.</remark>
</type>
</comment>
<sig>

XPP

[lonedfx]

I didn't really want to post anything about it so soon, given that it's not quite ready for prime time (ie, lack of documentation among other things), but XPP might be of interest to some of you. It does some of what this guys proposes, although it's not quite a "next generation programming language", more like a pre-processor on top of C++. It allows you to use external XML templates (to describe automatically written pieces of code based on the rest of your program) and inline XML comments in the cpp source (to perform higher level macros, like, for instance, calls that morph depending on the rest of the code).

It's been used in a pretty big project from a well known company we all like to hate, though unfortunately the project itself has been cancelled. Hopefully it does mean that it's useable and could be useful to others as well. I had been waiting on a rework of the site w/documentation before drawing any more attention to it, but given this article, this is as good a time as any.

Cheers,
lone.

You didn't actually read the article, right?

[antientropic]

There are now 140 or so comments, and it is painfully clear from them that almost none of the posters have actually bothered to read the article. If they had, they wouldn't be confused on the following:

• The article does not propose that we all start writing our programs as kinds of abstract syntax trees in XML notation. The XML is just the storage format. In fact, the extensibility that the author claims this will brings would make programs less verbose, not more.
• "Lisp S-expressions already do that!" The author acknowledges this, to an extent. But as he states, those never caught on, while XML can now be processed by lots of tools, so there is a new opportunity now.
• There are also some bizarre claims about extensibility either being a feature of all programming languages, or being unnecessary. That's silly, of course. What this is about is the ability to add new abstraction mechanisms to a language, which is really what the entire evolution of programming languages has been about. Procedures, OOP, templates, macros, modules, lambdas, etc, are all ways to cut down on repetitiveness and the number of boring details you have to think about. With an extensible language you can do that sort of thing yourself (within reason), while tools such as debuggers will still work nicely (which is not the case with typical code generation approaches, e.g., Yacc output).
• "But the source will take up so much disk space!" With a 120 GB hard disk, who cares if Hello World takes 10 KB? That's a whopping 0.0000077% of your disk space.

The author also makes a persuasive case about programmer's hyper-conservatism compared to other computer users:

Why, in the early 21st century, do programmers still insist that their tools have to draw exactly one glyph on the screen for each byte in their source files? No one expects AutoCAD or Microsoft Word to do this; even grizzled old Unix fanatics don't expect to be able to open a relational database with Vi or Emacs. One of the great ironies of the early 21st century is that secretaries can easily put organizational charts or cubicle floor plans in e-mail messages, but the programmers who made that possible can't put class diagrams in their code.

Something to think about.

Subtext

[Earlybird]

What's coming isn't languages where you edit XML -- because XML has too much syntactic overhead -- but languages which aren't text based -- languages like Subtext (the screencast demo is essential).

Languages need to evolve out of the pure text medium. This has been happening as incremental hacks to classic languages through code folding editors and AST-aware, intelligent IDEs like Eclipse, literate programming and Python's doctest module. High-level development tools like Delphi were early adopters of the philosophy that code doesn't need to be visualized as text when it's better to visualize it graphically.

The next step is to store not text but structure. For example, why shouldn't I be able to comment on -- annotate -- a specific number in a mathematic formula in my code? With current text-based languages this would be a headache:

double phi = 1 - 1 / (1 + Math.exp(-(cv * /* weight */ 0.3 - range) / sigma));

Instead, I could just select the value in my editor, click on the annotate key, and enter (in nice WYSIWYG HTML or whatever) my comment there. As a result, the editor will show a tiny icon next to the number, or perhaps in the margin, indicating that there's an annotation.

And why are formulas like that represented with such a poor syntax? Why can't I easily use proper Greek letters and standard math notations such as dots for multiplication, a horizontal line for divisions/fractions, etc.? Why can't I insert images into the source file which illustrate the concept it implements?

What I'm talking about isn't just "rich source code", which Donald Knuth's literate programming concept covers to some extent. Languages will experience a revolutionary leap when they start treating language elements as flexible blocks of content as opposed to tokens in an AST. Consider internationalization; instead of looking up a string from a language-specific message table, your source code can include the string in every possible language, hidden away in a single visual representation -- it might look something like:

showDialog("File not found" [English, Swedish, (8 more languages)]);

where "English ..." is a link that opens up a nice GUI letting you change the strings in different languages. The logic to select the string to choose at runtime exists in the string "component" itself.

A common problem in dynamically-typed language is that it's hard to implement optional static typing at the language level. It adds a lot of noisy syntax, and unless you add a lot of syntax, it's hard to solve many ambiguities and special cases. With a rich source format, you can hide away the details, similar to my annotation example.

Unix geeks typically balk at non-textual files, but I blame it on a fundamental lack of imagination. You can have both! Rich source code can be represented as text -- it's just not convenient to edit it like text. Instead, you add intelligence and convenience to your tools. You don't edit your PNG files with Vi -- you use a tool like GIMP or Photoshop.

Re:Subtext

[groomed]

Unix geeks typically balk at non-textual files, but I blame it on a fundamental lack of imagination. You can have both! Rich source code can be represented as text -- it's just not convenient to edit it like text.

A format which is as flexible and comprehensive as you describe is not convenient to edit period. The problem is that every tool which wants to edit a small part of it needs to understand (or at least be aware of) all of it.

Want to calculate a line number? Have to parse and render the entire document. Want to generate a diff? Have to parse and render the entire document. Want to translate a string? Have to send the entire document to the translator and wait for it to come back. Want to post a code snippet for discussion? Have to create a new file, paste the code snippet, then upload the file, meaning all discussion gets separated from the code. Unless every browser/mail reader/whatever is changed to understand the format, but this just reiterates the point made above.

This is not to say that it wouldn't have its uses, but they'd be rather specialized, and you'd probably end up with only 1 or 2 programs which can actually fully understand the format, somewhat similar to the current situation with Flash and Squeak.

There are very good reasons why we have the functional decomposition we have today. It makes it easier to work with other people.

Re:Subtext

[ine8181]

Yeah, I think it comes back to the original idea of using XML for this very purpose.

Using XML, we will have all the goodies of having a language-specific format and also a common ground that is Unicode text, for generating Diffgram, for example.

Re:Subtext

[Earlybird]

• I believe the term you are looking for is "code generators", not languages. Inkscape and Sodipodi generate XML code, but they aren't languages - they are just tools for drawing pictures. Similarly with Delphi, except in that case the pictures are ugly pieces of Win32 API.

Not at all. Delphi stores visual UIs in a separate format. It doesn't actually generate any code -- the visual representation references methods in your code (eg., "onclick" handlers), and your code can reference and interact with the visual representation. It's MVC.

Similarly, Delphi supports non-visual components that are edited visually. For example, a database connection is created by dropping it in a form. You then link visual controls such as tables and edit fields to the data source. All of this is done visually.

Delphi also has a thing that looks like a form, but isn't rendered at runtime. In other words, a visual code editor -- components are represented as icons you can drag around, link to other components, etc. It's more limited than a full-fledged visual code editor, but still very powerful.

• As for inserting images and other documentation into your code - just use doxygen or any other documentation-generation system that compiles your commented source code and external resources into a pretty html / pdf / dvi / whatever document.

I suggest reading up on Knuth's literate programming system, and you'll see how your above comment is something of a non sequitur.

• For "proper mathematical notation", you might want to look at Mathematica

That's the whole point -- I don't! Because Mathematica won't conveniently let me do all the other stuff I want.

But all other current computer languages have a pared-down, poor text representation of math notation -- why shouldn't an IDE be able to render that as nicely-formatted, WYSIWYG, directly-editable formulas? There's no particular reason they can't, really.

The assumption that 1 octet equals 1 character is no longer true. The assumption that 1 character on disk must equal 1 character on your screen is equally untrue. Code-folding text editors demonstrate this exceedingly well.

• I blame it on the fact that I can't edit your damn png-infested source code with vim over a choppy laggy text-only ssh connection. You don't always have access to X or some other windowing system.

Yeah, let's immediately go for the most extreme use case! You're thinking deep inside the box here. Who says a "rich source" tool can't be run inside Vim or be its own ncurses-based app?

I bet you use MySQL or some other database. You're not editing the data by hex-editing the tables, are you? You're using "mysql" or "psql" as a front end. They work fine in a text-only SSH environment. It's all about having appropriate tools. Why should source code be special?

Re:Subtext

[elhedran]

Instead, I could just select the value in my editor, click on the annotate key, and enter (in nice WYSIWYG HTML or whatever) my comment there. As a result, the editor will show a tiny icon next to the number, or perhaps in the margin, indicating that there's an annotation. ...

Unix geeks typically balk at non-textual files, but I blame it on a fundamental lack of imagination.

I can type /* weight */ a lot faster than I can take my hands of the keyboard, find the mouse, move the mouse to where the text appeared on the screen, highlight said text, move the mouse to the tool button for annotate (or contextmenu, whatever), and then click to open another dialog and type 'weight' anyway.

When you type at 80+wpm anything that avoids you having to touch a mouse is good.

Re:Subtext

[Unknown Lamer]

C-<spc>, [move arrow key to end of block], C-c, C-c.

Not it's a comment in whatever language you are using. Emacs has done this for ages. No need for a new magic language with new XML based textual formats and new editors written in Java using XSLT and CORBA to format the data for view and send keystrokes to the main app over the network from the keyboard_server...

Re:Silly article (Silly Post)

[Glorfindel]

I believe the author addressed all of your points in his "silly article".

1) He did mean something different than what is available today with GCC. Rather than a new front or back end for a compiler, you could write things like optimization plugins for your language extensions.

2) He specifically mentions LISP as an example of an extensible language, but laments how it just hasn't caught on with mainstream programmers.

3) How are existing languages "easily machine parseable"? Have you tried writing a parser for a complex modern language? Without a tool to help you like lex/yacc? I didn't think so. The only reason existing languages are easy to parse is because the tools have already been created to do so. XML is also easily machine parseable by this definition since XML parsing libraries and tools are readily available.
Also, he didn't argue that programmers should be typing XML programs in with 'vi', rather that IDE tools should process XML source code and provide a customizable view that is easy for the programmer to use and understand.

I don't know if I agree with the authors prediction that XML will serve as the base for new extensible languages. It certainly adds complexity and would make hand-coded optimizations more difficult. But his "silly article" seems to be grounded in a good bit of research and thought on the matter, as opposed to your post which indicates you probably dismissed the article before reading it thoroughly (if at all).

And yes, I'm new here. :-)

You mean ..

[TheBean]

like Lisp?

Common Lisp provided this mechanism years
ago. I guess people just liked parenthesis
so much that they never changed it .. :)

"Any sufficiently complicated C or Fortran
program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common
Lisp."

- Phillip Greenspun

Re:Also... think code conversion

[Coryoth]

Language conversion. Say you find some open source Perl code that does exactly what you want, but you are a Java shop. So, just run the XML version of the code through an XSLT and voila!

Lovely theory, but I'd like to see you pull that off in practice. What if I start using some very idiomatic language paradigms in perl, which all make good sense there, but result in, at best a tangled barely intelligible mess of Java, at worst something unconvertible. What this does, in effect, is reduce every language down to a poor quality "lowest common denominator". How do you easily convert a functional language into a procedural one? How do you convert you OO Java code into C? Sure, it can be done, but itf its done in an automated way I'm not sure I would want to be the one responsible for editing and maintaining the results.

Jedidiah.

Re:Extensible? XML Allows much more

[JohnBaleshiski]

I'm not a fan of using the wrong tool for the job. At work we normally use PHP for web applications, but when I see an advantage, I will stray from the "norm" and use Perl.

XML can be a very good candidate for coding logic. We are starting to do this with several libraries we have developed for manipulating data. It is much easier to get a text document at a major company published than it is to get a DLL published. The DLL is the main engine, controlled by XML documents. We can then create a "custom version" of the library by supplying different XML documents that contain layout and logic. We can write the engine once, then customize it via XML.

Given that my user name is smug_lisp_weenie...

[smug_lisp_weenie]

...I just want to say:

Congratulations!

You are now on step 1 on a long and tedious journey to building a poorly-designed lisp dialect!

Other posters have already made this case well enough that there's not much point in me elaborating! :)

This is only a 20% difference

[iamacat]

I don't see why you gave up the benefits of C++ for such a small improvement. One day you might want to display video on the sides of your cubes. With C++, you just pass a VideoCube to renderer.spin(Cube&cube) and it will call approporiate virtual functions to get bitmaps of each of the sides. With C code, you are likely accessing internals of struct Cube directly and can not change it's implementation without re-writting a lot of code.

Besides, if you really need efficiency, you can write low-level routines in C and still compile them using a C++ compiler. Make Renderer a friend of Cube if you really want to hardcode its internals. Of course, some C++ features like non-virtual method calls have no extra overhead, and some - like inline functions and refrences instead of pointers - can potentially generate faster code.

OOP can be overdone, but a small degree is useful in any program longer than 2 pages. By contrast, I don't see how coding directly in XML would ever be helpful. If that's an internal representation used by my editor or compiler - well, whatever works for them.

Re:This is only a 20% difference

[iamacat]

Oh no. First, you need to put a pointer to a struct of function pointers shared between all instances to have the same space efficiency as C++. That structure should also have a pointer to function table of base class so that you can call functions overridden by yourself without knowing their private names. I assume that each of your structs will have a "super" field of super-struct type in the beginning. To call one of these functions, you would need to do something like:

Derived *d;
((TopBase *)d->functions->draw((DrawBase *)d)(graphicsCtx);

If draw wants to access fields defined in TopBase, DrawBase and Derived, it will need to cast its first arguments to each of these structs in turn.

You can implement interfaces by having one "virtual" function that takes a pointer to an interface object and returns a struct with functions of this object for each interface method.

After a while, you will write macros to encapsulate all these things and will become quite productive. And then one day, you will want to inherit from a struct written by another programmer, who came up with his own virtual functions, inheritance, interfaces and macros.

Maybe the solution is to write a special version of C compiler with built in support for virtual functions in structs, so that people can use a clean, concise syntax for calling them and structs written by different people interoperate naturally. Oh wait...

Re:This is only a 20% difference

[Kesh]

... and this is why I dropped out of a CS major after the first year. Dear god, just the first paragraph of that makes my head hurt...

I'd love to write some applications, but C/C++ is like building a home out of Legos. Including the plumbing, electrical and appliances.

Re:This is only a 20% difference

[QuantumG]

By contrast, I don't see how coding directly in XML would ever be helpful. If that's an internal representation used by my editor or compiler - well, whatever works for them.

Which if you'd read the fuckin' article, you'd know that's what it was about!

Redundant syntax in source code is a BAD IDEA

[MoxFulder]

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

A lot of comments have suggested that encapsulating source code in XML would make it easier to parse languages in a consistent fashion, and thereby to write better code validators, formatters, style checkers, etc.

This leads to a logical paradox: if programmers continue to write code in "plain" ascii format, how is it going to acquire the XML markup? Why, someone would have to write a parser, of course!

This XML encapsulation is a misguided effort to create a standard interface to code parsing. Guess what! A highly effective parser already exists for every single programming language. It's the compiler!

To encapsulate source code in an XML form that redundantly specifies how it is to be parsed is asking for trouble:

1. What if the XML markup ever gets out of sync with the plain text source code? Either:
2. 1. Software for editing/validating/formatting the code WILL catch the problem. If so, that software must include a parser for the ASCII source code, thus rendering the XML useless, OR...
   2. XML-ified software WILL NOT catch the problem. The code might get highlighted incorrectly in the editor or incorrectly validated by the code checker (yikes!)
3. What if compiler writers get lazy and start relying on the "pre-parsed" source code. Now the programmer might be in the lovely situation of editing plain text code that's marked up INCORRECTLY with *hidden* XML code that's affecting the compilation of the program.

My point is, don't include redundant information in the fundamental form of your source code, because it will get out of sync somehow. Remember all those wParam variables in 16-bit Windows API? The "w" was supposed to "document" that it's a 16 bit variable. Now it's declared as a 32-bit variable and everyone calls it wParam... if they still code in C. At worst, it's misleading, at best useless and annoying.

If people want a standard way to decipher language syntax, then compiler writers should write hooks in their compilers to export the parse tree in a standard format. Heck, it could even be an XML format, but this should be treated like an object file (it's derived from the source code rather than the source code itself).

Re:Silly article (Silly Post (Silly Reply))

[PylonHead]

So let me get this straight:

You're arguing that programming languages are hard to parse, because, if you don't use any of the tools developed over the last 35 years to parse programming languages, it's hard?

In a similar vein, you might find that building a set of shelves is hard if you don't use hammers, screwdrivers, and drills, but instead try to embed nails into the wood simply by slamming your head into them repeatedly.

Grammar

[Hard_Code]

Don't most programming languages already have formal grammars? Why would you need to mark them up.

Yay for <xml>.

[Anonymous Coward]

<response language="English">
<exclamation tone="sarcastic">
<word partofspeech="adjective" syllables="1">
<character encoding="ascii">W</character>
<character encoding="ascii">h</character>
<character encoding="ascii">a</character>
<character encoding="ascii">t</character>
</word>
<word partofspeech="indefinite article" syllables="1">
<character encoding="ascii">a</character>
</word>
<word partofspeech="adjective" syllables="1" emphasis="true">
<character encoding="ascii">g</character>
<character encoding="ascii">r</character>
<character encoding="ascii">e</character>
<character encoding="ascii">a</character>
<character encoding="ascii">t</character>
</word>
<word partofspeech="noun" syllables="1">
<character encoding="ascii">i</character>
<character encoding="ascii">d</character>
<character encoding="ascii">e</character>
<character encoding="ascii">a</character>
</word>
<punctuation>
<character encoding="ascii">!</character>
</punctuation>
</exclamation>
</response>

It has very clear uses

[tallbill]

If you have XML you can suck it into a DOM parser and then do node walking. Then you can write the data from the nodes into structures in whatever language you have. And for this reason it makes a great way to feed data from one program to another.

It is a very inefficient way to have the data for a program while the program is running.

I agree that XML can be whatever you want it to be, and I agree that it is very over-hyped and the OOPSLA mongers, who make their money trying to confuse people into buying into their solutions, are behind XML in a large way.

XML is still good for many things.

But it is very bad for high-performance programming like robotics or video games, or graphics or music. It is a good thing to use to store data, or at startup in a real-time process.

For web pages having the tags around all the data makes XML formated pages very easy to spider. And for that reason alone it is very useful to use in web pages. But that XML will look just like HTML.

So don't disregard XML all the way. But please do continue your health skepticism about it.
The object-tool mongers caused a lot of problems and a lot of grief for many engineering products by selling tools that were designed by amatuers and supposed to work in real-world real-time situations where they just couldn't hack it.

Were there ever any refunds made for any of these so-called tools? These professors got rich selling their seminars and a lot of very good companies got duped.

Re:Umm...

[canuck57]

Seriously. Isn't software bloated enough? Why obfuscate things further. Dumbest... idea... ever.

Couldn't agree more. Leave it to some MS XML pin head to think you need a new language to be extensible.

The fool should study polymorphism, and a object orientated language like Java or C++. But I suspect that is all is to much for the child's brain.

Going to be flame bait for this:

ALL XML IS IS FREE STYLE HTML/SGML and your smoke'in crack if you do not realize it.

And when I type code I hate typing

<><><></></></>

all the freaking time to make my job productive. Or at least I don't think it makes me virile.

It's being done already...

[nervine]

A small company called Witango Technologies (previously Tango, owned by Pervasive) already has a RAD product that does exactly this. Within a year of using the product, I've found it to be a very suitable product for medium-sized businesses with only a few developers. From importing ADO objects to creating your own Tango Class Files, it's a quick way to pump out whatever the user needs... and you know they needed it yesterday. :) Check 'em out

could somebody tell me whats wrong with LISP?

[Paolomania]

Maybe too much schooling has made me a stodgy young academic, but didn't LISP provide us with extensibility and everything else XML cuold possible offer, in a much cleaner and more elegant syntax?

This already exists, and it's called XPRESS

[KluZz]

The language can be found in the bowels of Sun Identity Manager, formerly known as Waveset Lighthouse, and it's just as wacky as you would expect from an XML-based language. It's used for implementing workflows for the user provisioning and what have you not.

I thought this was a stupid idea, until XPRESS confirmed my beliefs.

Re:Umm... how about you RTFA?

[fR0993R-on-Atari-520]

Wait, seriously. On page four, the author says:

Programmers will not see or edit XML tags; instead, their editors will render these models to create human-friendly views, just like Web browsers and other WYSIWYG editors.

All these whines about obfuscation and "I don't want to write code in XML!!!!" are clouding the debate - "Will this make development of large software projects easier and more reliable?"

I saw another poster completely discounting OOP languages (specifically C++) because it caused a 100FPS slowdown (from ~600 to ~500) in his 9 cube shaded renderer, as if that were a typical large software development project (clue to the clueless: it's not). This person was marked up as Insightful!

Give me a break, people.

Indeed.

[warrax_666]

Whenever I see people trying to pull something like this I tend to remind them of one thing (everbody seems to forget this whenever XML is brought up, I dunno why...):

Semantics matter!

It's great that you can read the syntax of a language (which is basically what this idea boils down to -- people just have to implement an XML parser instead of a $LANG-parser) without effert, but if you don't understand the semantics of what you're reading it's rather pointless, unless all you want to do trivial tree-based transforms. This applies to XML in general and it applies here. As you pointed out, the semantics of languages are different, and so your tools have to understand all the different languages anyway (or, as you say, reduce them all to some common denominator).

Re:I don't understand

[Seahawk]

How on earth is an argument like that "insightful"?

"Getting milk from the store is more convenient than having your own cow" is the biggest lie ever!

Lots of farmers gets their milk from cows without a problem.

But for the topic:
When I write a binary format that is basicly just a filedump of som c-struct, how compatible is that with c#?

Sure - I CAN read it - but it takes effort.

If I wrote the same file in xml, it would be pretty effortless to read it in php, c#, java, VB, you name it.

And with the binary file i get the added bonus that extending the file WHILE maintaining backwards compability is a bitch.

Can this be overcome by a smart developer - sure, but it would take effort.

Extending the xml-file would be pretty simple.

There are other bad things about xml - why not focus on these, instead of pulling things out your behind?

LISP history

[2901]

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.

Lisp failed in the early eighties. That is twenty years ago. Things were different back then, and it is important not to learn the wrong lessons. Here are some of the reasons LISP failed.

Virtual Memory Mysticism Four megabytes was a lot of memory back then. The junor manager could be persuaded to sign off on the purchase of a workstation with that much, but the middle manager would cut it back to two megabytes and the senior manager would cut it back to one megabyte. The fancy Lisp application would have a working set of three megabytes, so the machine would page thrash and run like cold treacle. Eventually management would be pursuaded to buy another megabyte, but it would still be too slow. The basic problem was that people treated virtual memory as magic and were reluctant to accept that there were still hard limits on the ammount of physical memory required. VLSI killed bit slice Back then, everybody and their dog was starting new mini-computer companies, using 4 AMD 2901 four bit slices to make the ALU and a 2910 to sequence the micro-code. The big Lisp vendors had their own hardware. Symbolics had Lisp machines, Xerox had D-machines. As the decade wore on, technology progressed, and VLSI CPU's such as the 68020 and 80386 slaughted the LSI CPU's. DEC's VAX was the biggest losser, but the Lisp vendors suffered greviously from mis-reading the way the hardware market was going. Naive garbage collectors Garbage collectors are hard to write. In the 80's Lisp vendors were proud that their garbage collectors were free of bugs. Unfortunately the old mark and sweep collectors tended to walk swapped out data structures, thrashing the virtual memory system. Modern generational collectors are enormously better. Computer science was young Many programmers were self taught. (I read mathematics at University.) Others had studied computer science, but were learning from academics who were new to computing themselves and thought PASCAL was a good language.

Why do you want access to the AST? The idea is that you can avoid manual maintainance of repetitous code and boiler plate code by automatically generating it. Well, it is a nice idea but it is also a sophisticated idea.

Some of the application is written in the base language. Some of the application is automatically generated. The generated code doesn't appear by magic. There have to be source files, in an application specific language. There have to be code generators, written in a meta language, that take the application specific language and expand it to the base language.

It is a huge win if the meta language is transforming AST's into AST's rather than transforming text files into text files. To obtain this benefit, the programmer must be thinking in terms of the abstract syntax, rather than the surface syntax.At this point it becomes natural to give up on surface syntax and program straight to the AST. It is also natural to insist that the base language is suitable for writing AST to AST transformers, so that a separate meta language is not required. This is what Lispniks are getting at when they say that Lisp is its own meta language.

This way of thinking about programming went right over the heads of most programmers in the 80s. I think that the most important reason why Lisp failed in the early eighties is that it was 20 years ahead of its time