Slashdot Mirror

← Back to Stories (view on slashdot.org)

Are Extensible Programming Languages Coming?

Posted by michael on from the tabs!-spaces!-tabs!-spaces! dept.

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

17 of 838 comments (clear)

  1. Re:Is this guy serious? by hasdikarlsam · · Score: 5, Informative

    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!

  2. Meta Language by LetterJ · · Score: 2, Informative

    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/

    --

    The Glass is Too Big: My Take on Things
  3. You missed a key point in the article... by malakai · · Score: 3, Informative
    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.
    --
    -Malakai
    A Dragon Lives in my Garage
    1. Re:You missed a key point in the article... by tomhudson · · Score: 3, Informative
      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.

  4. Haskell is a language for writing languages. by shapr · · Score: 5, Informative
    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.
    --

    Shae Erisson - ScannedInAvian.com
  5. Already out there by Anonymous Coward · · Score: 1, Informative

    Not much of a surprise, it is very useful in certain situations. For example, take a look at ABLE (Agent Building and Learning Environment) from IBM alphaworks (i'm too lazy to find the link, just go to alphaworks.ibm.com and search for able). It is a logic programming language, but I used it's XML language capability to dynamically use XSLT on input and run the smart "agent," given some very complicated paramters and logic.

    Kevin

  6. XAML by DreamTheater · · Score: 2, Informative

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

  7. Re:Syntactic Sugar by emurphy42 · · Score: 2, Informative
    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.
  8. read the article... by Anonymous Coward · · Score: 1, Informative

    He clearly talks about LISP as doing this years ago with s-expressions. And he clearly talks about using XML as an interchange format -- NOT as something you'd ever type. XML in this case is just an update of S-expressions to easily incorporate extensions people have already built (e.g. handling Unicode) and interoperate with other stuff that's out there today, but with the assumption made clear throughout that you're never going to type or look at plain XML. You pick your syntax that the editor will transform the XML into and vice versa.

    What wasn't mentioned is that this (in some way) was what McCarthy originally envisaged for LISP --- S-expressions would be the underlying representation, but humans would never need to see them or type them. There would be a syntax transformation layer on top. He just never got around to defining a LISP syntax above s-expressions, and the rest is history.

  9. XPP by Anonymous Coward · · Score: 1, Informative

    XPP

    xml language used as a c++ preprocessor. used to generate classes for use with other classes, based on base classes... well, you get the point.. read the site

    its a programing language that uses XML as its format

  10. Re:Silly article (Silly Post) by Glorfindel · · Score: 2, Informative

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

  11. You mean .. by TheBean · · Score: 2, Informative

    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

  12. Re:Subtext by groomed · · Score: 5, Informative

    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.

  13. Re:Subtext by Earlybird · · Score: 2, Informative
    • 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?

  14. Re:Is this guy serious? by Unknown+Lamer · · Score: 2, Informative

    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.

    --

    HAL 7000, fewer features than the HAL 9000, but just as homicidal!
  15. It's being done already... by nervine · · Score: 2, Informative

    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

  16. Re:This is only a 20% difference by QuantumG · · Score: 2, Informative
    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!

    --
    How we know is more important than what we know.