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?"

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?

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

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 buyin

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 XM

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, wh

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=

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

[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!

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

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

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.

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 ex

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.

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

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.

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?

[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?

[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?

[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 bac

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

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?

[ShadeARG]

Actually, perhaps it might. Follow me here. Imagine being able to comment a chunk of code, but leave it invisible until the coder decides to review the comment layer. It sure beats polluting the codes readability, regardless of what other IDEs do to fold them. Imagine the possibilities with being able to lock certain areas of the code that you might have intimate knowledge of in a workgroup setting. Do you really want Fred touching that code? Would he even know better? If you were able to add explicit notes

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?

[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 suitab

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?

[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 o

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 woul

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]

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

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?

[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?

[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?

[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 feat

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.

That's just silly...

[Vaevictis666]

And really, it can be done right now with pretty much anything.

Just run the code through the tokenizing phase of the compiler, and output it as XML. Teach the editors to work backwards that one step for display, and run forwards when saving, and you're done.

Programmable Programming languages?

[sleepingsquirrel]

Programmable programming languages? I'm sure it'll make the lisp-macro master Paul Graham [paulgraham.com] smile.

Damn...

[ackthpt]

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

Syntactic Sugar

[Viking Coder]

There should be precisely the amount of syntactic sugar to consisely express a programming construct.

Any more than that, and you're just typing because the editor is too stupid to do it for you - and you're making it harder to scan. ("Read" or "Grok")

"begin" and "end" look pretty silly compared to { and }, and <bizarre-programming-construct-that-means-the-sam e -thing-as-an-open-paren> is retarded. Maybe as an intermediate language for easy translation, but not for my fingers to be typing or eyes

Short answer, no

[Anonymous Coward]

<answer type=long>
<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>

On the Microsoft front...

[sH4RD]

Microsoft is implementing an XML based language into Longhorn. I forgot what it is called though, but I can assure you it exists. I find it kinda funky myself, but maybe it works.

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.

Great

[Epistax]

I've always wanted my "Hello World" source to take 10k.

Buzzword compliance to the table!

[CharAznable]

Yes, because it will be easier to sell a project to your boss:

"Hey, it has XML!!"

This will trigger memories from a IT management journal that your PHB read but didn't understand and will become enthused at the prospect of your product being even more buzzword compliant.

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

I was at the OLE devcon in 1993 in Seattle ...

[JMZorko]

... and someone posed a very cool question that I had not thought of:

"So, we're going to be making all of these neat components that people can use, right?"

"Right."

"And this will allow them to call our components from about any language that has a COM bridge, right?"

"Right."

"Um ... why do they get to have it so good?"

(long pause)

Regards,

John

Hahaha... lisp all over again...

[Vaevictis666]

Heading 3 from the article: Programs as Data. Yep, lisp was doing that decades ago :P

COBOL coming back?

[SharpFang]

XML has one serious disadvantage: It's awfully verbose. You may argue what is more readable,

i++;

or

myIndex.math.increment();

but it's hard to argue about

<math operation="increment"><variable type="integer">i</variable></math>

Sorry. I don't see future for that.
Yes, writing your own syntax rules with XML, okay. But as an editable compiler abstraction layer. Not as a part of the program itself

XML information content is too low

[Shimmer]

XML has even less entropy (number of keystrokes required per statement) than COBOL. It's the anti-Perl. Good luck to anyone who chooses to write a program in XML. (Those of you with experience in XSLT already know what I mean.)

What the hell for?

[Fulcrum of Evil]

Seriously, what does this offer over current stuff? If I want to extend my application, I'll embed a script host. Extending the language just aadds the potential for the same code doing different things and giving rise to a whole new raft of bugs.

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.

XML in Java and .NET

[Eyah....TIMMY]

As far as web app development is concerned, XML is more and more present in the two domains, either natively or via open source projects.

On the Java side, the struts framework [apache.org] provides logic to the front end so developers can use an XML style language to go through lists, create variables, set objects, etc. You can also make all your build scripts using ANT [apache.org], which allows for function calls, variable assignments, and other simple tasks.

On the .NET side, ASP.NET pages are in the form of controls, which

Please give me LESS typing, not more

[Brento]

As somebody who loves the speed and elegance of hand coding, the thought of having to hand-code XML is horrifying.

When designing programming languages, try to relieve your users from carpal tunnel, not contribute to it.

Uh?

[Unknown Lamer]

Lisp.

Heard of it before?

LISP

[jonastullus]

for all those yammering about the many brackets in lisp: how exactly is polluting your code with xml-tags better??

LISP/scheme is an incredibly extensible language and after having spent the last days learning the basics of haskell, i really wonder how on earth an inferior language like "C++" could ever become this popular!

for low-level stuff, C is a great language but when it comes to prototyping complex algorithms or simply trying out some whacky ideas, imperative languages like C++ keep your mind so ver

*sigh*

[jmb-d]

Ever heard of FORTH [forth.org]?

Geez, it's only been around since 1970...

And LISP has been around since the 1950s...

Great

[Trejkaz]

So we'd have...

... xmlns:Foo="urn:code:com/blah/Foo" ...

Instead of...

...
import com.blah.Foo;
...

Big improvement.

No!

[Daimaou]

The first example in the Slashdot blurb would be the functionality of an editor or IDE, not a language. I can actually see this as being handy; especially if you are working with a bunch of other curly-brace-positioning zealots. The second example just looks stupid though.

I use XML for some things and it is very useful in some cases, however, I find it more a pain than it's worth in most situations.

XML has its uses and has its place, but I don't think this is it.

You mean...

[wan-fu]

...they want to take Lisp and replace all the parenthesis with < and > symbols?

The article itself clearly states: "Yes, this could all have been done 20 years ago using s-expressions."

C'mon, LISP has already done this stuff and then some. This "new" idea deserved a publication on ACM AND front page Slashdot? If everyone flocks to this because of s#(#<#, etc. it will be a sad day in programming language history.

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

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.

Haskell is a language for writing languages.

[shapr]

This is a standard paradigm in the Haskell [haskell.org] world. You write a new language that fits the problem domain. These are called Domain Specific Languages [yale.edu]
For example, Simon Peyton-Jones wrote a combinator library to describe financial contracts [microsoft.com] and used it to describe the collapse of Enron. (With fascinating conclusions!)
Paul Hudak has written Dance [yale.edu] and Haskore [haskell.org]. 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 [lambda-the-ultimate.org] is a good forum to learn more.

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 [att.com], 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 hav

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

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 [paulgraham.com] (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]

<rant><invoke-slashdot cliche="overdone-parody">
<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 [bluemars.org] 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.

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 [subtextual.org] (the screencast demo [subtextual.org] 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 [eclipse.org], 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 [artima.com] 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

[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 v

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! :)

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>

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?

Re:Umm...

[WD_40]

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

XML Lisp!

[acidrain]

Trying to get this past the lameness filter...

a

b

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>

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 typi

Re:I don't understand

[Homology]

XML is certainly more portable than binary code, as will be any plain text, but I just can't reckon why everything needs to be XML based these days.

XML is not suited to everything under sun, though some people mistakenly thinks so. It's just one of those famed Silver Bullets.

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.

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