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.
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.
11*43+456^2
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.
Education is the silver bullet.
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>
-- http://thegirlorthecar.com funny dating game for guys
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.
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. vs. 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.
[o]_O
-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.
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:
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:
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.
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.
Craft Beer Programming T-shirts
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.
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.
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.