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

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

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