Slashdot Mirror
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?"
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.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
...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?
Code, Hardware, stuff like that.
They should have put the < and > keys in the middle of the keyboard.
A feeling of having made the same mistake before: Deja Foobar
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.
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: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.
Shae Erisson - ScannedInAvian.com
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
<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>
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.