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?"
No.
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.
Larry Wall might be listening.
What's wrong with an OO paradigm for extensibility? 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. Will this allow multiple languages to use the same libraries transparently?
I Want To Believe
Sounds like a great idea to me.
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?Dumbest. Idea. Ever.
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
Possible? sure. Practical? No.
Unless you're trying to build a VB-like system, XML would not be practical at all.
I tried designing an XML-based programming language long ago and failed miserably. It just doesn't work out well. I do think that languages are ready for a revolution, though. I love C syntax, but it's stale and there are many things we can improve upon.
Disconnect and self-destruct, one bullet at a time.
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.
Slashdot = ((Technology + Politics) / Trolls) % Grammar Nazis
That code example is enough to put anyone off even considering it.
This is a joke. I am joking. Joke joke joke.
Programmable programming languages? I'm sure it'll make the lisp-macro master Paul Graham smile.
They should have put the < and > keys in the middle of the keyboard.
A feeling of having made the same mistake before: Deja Foobar
There should be precisely the amount of syntactic sugar to consisely express a programming construct.
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 to be reading.
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
Education is the silver bullet.
<content="N0!!!!!!!!!!!!!">
</answer>
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.
WASTE - The Secure P2P
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.
Cut that out, or I will ship you to Norilsk in a box.
There's a certain beauty and robustness to simple text files, but on the other hand XML stored code would enforce earlier code analysis, which could lead to cleaner code. I for one would also love to get rid of the mixture of whitespace conventions in "grown" code. Let's give it a try.
You define your program visually and internally it's stored as XML.
Really easier to maintain.
"Doing what i can, with what i have." ~ Burt Gummer
Must everything be OO and XML ???
I am disgusted
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
For years scientists having been working on a language less readable than perl.
albeit in a somewhat limited form. It's called XSLT, and it's a HORROR to program in. Un-fucking-readable. XML is an INTERCHANGE format, people.
Guess the guy wanted something opposite to Brainfuck, eh?
Sig ?
The linux kernel should be rewritten in XML.
I don't need no instructions to know how to rock!!!!
I've always wanted my "Hello World" source to take 10k.
I think it's lame, but if you're interested then check out the Water programming language at waterlanguage.org
From TFA
v oke-expr>
<invoke-expr method="myMethod"><evaluate>record</evaluate></in
Hey, that's almost as good as
(invoke (method . "mymethod") (evaluate "record"))
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.
The perfect sig is a lot like silence, only louder
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 so verbose, it puts Pascal to shame. I guarantee you, if that language ever came out, a bunch of C guys would have a complete macro language for that in a day... =)
"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
Falling You - beautiful
If the grader can't understand what you're doing, which appears to be valid, how can they mark you wrong?! They can't. A person for every language and a language for every person. Muwahahaha. Egalitarianism is about to arrive, first one to name their son Harrison Bergeron wins, sort of, but not really. Have a back up.
Heading 3 from the article: Programs as Data. Yep, lisp was doing that decades ago :P
Dear god no! If I was forced to code in a language like that I would beat down everyone around me with my keyboard. Seriously, XML is not a new paradigm. It is a way to describe data. A bit bloated IMO but good for what it's designed to do. Why are people trying to shoehorn it in everywhere else? I've heard of plans to put XML into DNS! ArghhhHH!!!
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
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Just someone wanting to try out their shiny new XML hammer on all those nails. (The custom reformatting would be nice. After a while those 64x16 Forth pages got old--not that they were manditory.))
One line blog. I hear that they're called Twitters now.
People need to go back to using lower-level assembler code and other such near-machine-code basic (but not BASIC basic) languages and master those before they try to create a whole bevy of new languages that are so far removed from the binary that it takes the computer 5 minutes just to render "Hello World" in a pretty-looking XML formatted stlye. C, in particular, has been abandoned by many teaching institutions, including my own (we learned JKarel using Java). This is a dangerous trend that teachers bad programming habits and needs to be stopped before it becomes widespread.
Um, doesn't LISP achieve the same thing in a far better manner?
This signature intentionally has just seven words.
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.)
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
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.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
S-expr's and xml are interchangeable, for the most part. Congratulations, you can now be a total degenerate and program in xmlisp.
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.
.NET side, ASP.NET pages are in the form of controls, which similarly to the struts framework allow server side logic to be defined through an XML language.
You can use NANT also to make builds. Similar to ANT, it allows for many simple programming language tasks including listeners.
On the Java side, the struts framework 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, which allows for function calls, variable assignments, and other simple tasks.
On the
I have yet to see exception handling and OO but I'm sure it's not far away.
It is not enough to have a good mind. The main thing is to use it well. - Rene Descartes (1637)
Representing code in a structured data form so that languages can have user-extensible syntax and can easily host programs that manipulate other programs as data? Sure, it's not like we haven't had that for nearly FIFTY years now!
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.
What's your damage, Heather?
XML is lame in the first place and this is the lamest use of it I've ever seen.
Back to the loch with ye, Nessie!
Lisp.
Heard of it before?
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
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 very busy with memory allocation, pointer arithmetic and weird segmentation faults that the chance of finally implementing some intricate algorithm in such a language is really slim (and will definitely produce a HUGE headache).
i am not saying that LISP/scheme/OCAML/haskell (to name just a few [very different] functional and multi-paradigm languages) are so much better for all tasks, but if people were simply introduced to one of these languages early on, this might have a very beneficial effect on their programming style in any other language.
and as for extensibility, LISP is seriously unbeatable with its powerful macros and the duality of code and data!
well, you do your thing with patched-on xml tags in your code and i'm just gonna stick to the languages that were actually thought through!
jethr0
Ever heard of FORTH?
Geez, it's only been around since 1970...
And LISP has been around since the 1950s...
In walking, just walk. In sitting, just sit. Above all, don't wobble.
-- Yun-Men
The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well. -- Phil Wadler, POPL 2003
So we'd have...
Instead of...
Big improvement.
Karma: It's all a bunch of tree-huggin' hippy crap!
Don't know how closely related this is, but a professor I used to have is into this kinda stuff. srcML basically builds a parse tree of your code and preserves all sorts of information about it. The idea is to be able to configure your IDE to display the code in whatever format you'd prefer and increase program comprehension among other things.
Trying to get this past the lameness filter...
a
b
-- http://thegirlorthecar.com funny dating game for guys
of course it's possible, and some would say it already exists with languages like Lisp. But it wouldn't look anything like the code example provided. Why would anyone want to program in XML. IMHO, XML syntax is not appropriate for a programming language, it's appropriate for data representation. It's like having a whole language made completely of nouns and adjectives. It's incomplete if you're trying to do anything beyond writing a grocery list. Great languages require nouns and verbs and descriptors. XML-type languages aren't adequate for something like this.
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.
I've done lots of programming in XSLT, which is an XML-based programming language.
...
It's annoying as heck.
As you use it more and more, you find that there are lots of situations that you can deal with in a "normal" language that have no equivalent expressibility in XML. The problem comes in the strict matching of open/close tags. The easiest way to explain it is in terms of the English language, but code flow is similar. A simple liguistic example is as follows.
Consider the sentence: The dog walked. This might end up as the following XML: <sentence>The dog walked</sentence>
But now suppose you have the sentence: He said, "Hello." You CANNOT do: <sentence>He said, <quote>Hello</sentence></quote> Instead, you have to do: <sentence>He said, <quote>Hello</quote></sentence> And then your period ends up on the wrong side of the quote.
The same thing happens with logic flow statements, and you end up having to copy and paste code or create all kinds of extra functions. For example, suppose you are writing a simple "program" that puts either "<b>...</b>" or "<i>...</i>" around some text depending on whether it is to be bold or italic.
You can't do this:
<if bold==true><b></if>
<if italic==true><i></if>
Complex code here for inserting text
<if bold==true></b></if>
<if italic==true></i></if>
Instead, you have to do
<if bold==true><b>Complex code here for inserting text</b></if>
<if italic==true><i>Complex code here for inserting text</i></if>
It's a big pain because you end up having to break your code into lots of small, unnatural functions that are called a bunch of times from the same small section of code, but nowhere else.
XML has its place, but as a programming language, it's pretty cumbersome.
Doesn't mean you should. Jesus christ, this is silly.
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.
No, it's just the way they're sat.....
</C_Code>
It might work.
Personally, it's the dumbest thing I've heard. Doable sure but who would want to code in it when there are many other languages out there that are nicer to code in (Not just C).
Lead balloon I think.
Paul Graham's outstanding book On Lisp is what you want to read if this interests you at all. Indeed, pretty much anything he has written about Lisp is relevant. Lisp's macro system allows you to do this: you can define your own language constructs.
The book is out of print but can be downloaded from Paul's site,
http://paulgraham.com/onlisp.html.
XML is not God's Gift. XML has had delusions of grandeur pushed upon it. A nice simple representation has morphed into a horrible monster. Ugh.
Every problem looks like it needs a factor of ten bloat.
As with all XML applications I find myself asking "what problem does this solve?" and find the answer is "one in the creator's head".
I've never understood what the point of XML is. Beyond the purpose of documenting any file format, that is, because that seems to be all it does. And it does it very very badly.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
There are already XML based programming languages
ANT for example, and it is indeed extensible
http://ant.apache.org
Possible, yes. In fact actual.
Hello World!
</write>
<format statement="10">20A</format>
??
Goodness I am rusty!
One of the great ironies of the early 21st century is that the programmers who build component systems for others are strangely reluctant to componentize their own tools.
That's not one of the great ironies of the early 21st century. It's minor and uninteresting. Let's wait until the end of the 21st century before we employ this sort of hyperbole.
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
I don't get it.
this already exist with server side systems; cause i built them using reflection in 1999. One major problem...its too slow and you have to type into too much just to get something done and xml is like lisp with all the tag crap. jsp works better; its a happy medium between total programming and xml-script-programming. xml alone does nothing except stir the imagination to build another un-needed format.
Will know does this already.
Quality over Quantity.http://www.virusgaming.com/
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
Am I the only one who is wincing: "ewwww ...." ?
http://www.o-xml.org/
Oh yeah...
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:
Exercises for the reader:
1. What does this do?
2. Is it easier to read than the corresponding C program?
--
What short sigs we have -
One hundred and twenty chars!
Too short for haiku.
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.
Sounds like Lisp to me, only more inefficient.
By having the code in a structured format, it would be far easier to do things like static analysis, metrics, or reverse engineering of code, without resorting to hand to LEXX/YACC combat. simply understanding the sequence of nodes and we would be good to go to write some nice tools.
An extensible language whose syntax can be manipulated programmatically? Why has nobody thought of this before?!
All's true that is mistrusted
Anyone seen CFML lately?
Don't waste time... procrastinate now!
The language I'm develolping is currently looking like a "scripting" language built on java with many lisp type concepts. The nice thing about Argot is that I can add new concepts into the language dictionary whenever I want.
In the future I hope to develop a browser that allows mixing data and code seamlessly. The Argot dictionary concept allows this to happen easily. The fact Argot is binary also makes it compact.
Even further into the future it would be nice to see virtual machines with dynamic byte code. I've got ideas of using Argot for this too, but that can wait. :)
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
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
It's funnier when I remember to include the link to the second-oldest HLL still in use, which thought of this a long time ago.
All's true that is mistrusted
Yes, we've all seen Cold Fusion. The tags are only useful for the most limited control statements.
Anything serious has to be done inside the <cfscript> tag - in a painfully limited javascript-type language, without any of the silly tags in the way.
This couldn't be more off base if he predicted the resurrection of the "GOTO" statement.
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
This sort of crap is taken almost seriously, and people complain about (mymethod record).
See what I've been reading.
http://longhorn.msdn.microsoft.com/lhsdk/core/over views/about%20xaml.aspx
Don't certain crappy HTML-producing languages, for example CFML, already operate this way?
For example (and yes, I've forgotten my crappy CFML syntax, so this is pseudo-crappy CFML (as opposed to crappy pseudo-CFML)),
<CF-FOR INDEX="I" START="0" END="5" STEP="1">
<CF-PRINT>%I%</CF-PRINT>
<CF-IF CONDITION="I=3">
<CF-PRINT>Aw yeah, baby, three!</CF-PRINT>
</CF-IF>
</CF-FOR>
And, to expand upon my question from my subject:
Aren't they already here? And aren't they already crappy?
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.
Please, if you think you'd actually be typing the code yourself, you're nuts! The point is to get as much of the grunt work done via automated means as possible. From that perspective, automation of source code is much easier with the source as XML than as a typical c-style syntax. The upside is we then get to do the interesting work.
This guys is reinventing languages like LISP but with a even worst syntax!
The formatting stuff is is an example of XML being so hyped that it is starting to become a solution in need of a problem.
As for languages that allow you to metaprogram the language in order to extend it, FORTH has been doing this for four decades, and LISP has been doing it for at least four decades, too.
And they both do it in a way that is a lot more intuitive and readable than any XML implementation I can imagine.
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
That whole idea reminds me of Cobol programming, where 2/3rds of the code that you wrote was mindless respecification of thing, or characters that specified how things were going to be formatted instead of how they would be used.
XML is such an odeous buzzword these days. Everyone's jumping on the bandwagon because it's easy to comprehend. They don't seem to care that the entire language is horribly inefficient for what it does in terms of characters needed and processing time to transfer and interpret it.
I think, though, that programmers will draw the line at using it as a stupid bloody programming language. All really good programmers know that their ability to produce is, in a lot of ways, a factor of their typing speed. Adding extra lines to code for the sole purpose of conforming to an inefficient standard will only appeal to people who have more interest in bureaucracy than productivity.
Wake up - the future is arriving faster than you think.
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
... and it eventually drove me crazy...
Could this be used on the user-side of things to allow the user to customize the layout of the program to suit their tastes or maybe add functionality for advanced users? .Net's CLR - for example the tag <invoke-expr> would simply be an opcode or a 'machine' language instruction?
Or is it just another virtual CPU like Java or
Shh.
I can see a compressed XML representation making sense as your intermediate data representation (akin to modern-day bytecode representations) simply because you could easily compile pretty well anything to it (creating sub-dialects of it by adding entity support in XSD and the usual notion of XML namespaces for over-riding selective behaviour in the dialect).
The XML compiler could encode a great deal of semantic value (ie: loops, etc) on a higher-level than native binary languages or even conventional bytecode languages do. Thus, a VM could JIT the representation into something brilliant for the host machine (for example: vector optimization would even be easy where it is nearly impossible in most VMs for bytecode languages). Really, I can see where they are going with this since XML is a perfectly expressive level of indirection which could give the compiler and VM a lot of room to do powerful things in a fast and extensible way.
Using it as the actual programming language that the developer uses is not feasible since it is overly complicated for most of the what the developer wants to think about and kind of slow to actually write logic in.
I wonder if previous generations had people making fun of the idea of using ASCII or the 8-bit byte for everything the way that there are modern day people thinking that using XML for everything is absurd. This may be the point where it is questionable but XML is powerful so it is worth thinking about.
.... oh yeah of course it's LISP.
I'll try to avoid being modded down as redundant by adding that programming language designers should start tackling the difficult issues rather than ever discussing how to abstract the programming of van Neuman machine and being anal about re-use, B.S. "elegance" and useless concepts such as OO or whatnot-Oriented-programming. Do you keep changing the grammar of your native spoken language just because it's not optimal for expressing certain things ? Do you speak in 10 different languages according to which is best for what you have to say.
While many posters here rightly argue that early work on LISP, Scheme and ML essentially invented everything that had to be invented on programming sequential machines, my opinion is that people should settle on a simple, extremely mature, accessible standard such as C.
It's not that language design work is useless. It actually is my job. However, there are really useful problems out there in programming certain parterns of concurrency and synchronicity/asynchronycity, for example programming hardware behavior, systolic arrays, reconfigurable logic, multi-core processors, stream processors, grids, etc.
use Blunt::Instrument;
-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.
gah, it is to laugh.
realize: xml is the bell-bottoms of programming language design. it may get you in w/ some easy-come-easy-go folks in a grassy-hilled cultural festival but you will always (attempt to) hide the fact from your kids.
languages w/ parens, on the other hand, are the height of style. see for yourself: look carefully at those who deride them.
If you think that extensible programming languages aren't already here, then read On Lisp (some familiarity with Lisp is necessary).
I am responding to the slashdot post, not the article. If you wanted to each programmer to see the code their own way instead, you WOULD NOT store the formatting as part of the underlying representation. Instead you would store the formatting as part of the display transform, so that each user would see the source code differently.
The stuff we use now stores the formatting as part of the file and that is part of the problem (although it could be worked around).
It saddens me to see that kind of gross semantic error made in the slashdot post, I'm hoping the actual article does not perpetuate this fallacy.
There seem to be a lot of comments here along the lines of 'Eeek, XML looks ugly, why on earth would I want a language that looks like that'. Now if you bother to read the article... the idea is to *store* the code as XML, not display it as XML. It would look the same to you, but your editor would store it differently - in XML as opposed to plain text. One of the points being it would be easier to manipulate the display of the source code without changing its meaning.
I quote: '...programmers will not see (much less type in) XML tags'.
Now one can certainly discuss whether this is a good idea or not, but it might be worth commenting on the actual idea rather than a straw man, yes?
OK... I refute this articles rather silly ideas in this blog entry: http://jroller.com/page/murphee/20050113#xml_futur e_of_source_files
murphee
That's about all there is too it.
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.)
he uses Nuke so he must be crazy....
With XML based source code, my SLOC will rise a billion times!!
Woot time to bring that to management! Look at how fast my output is growing!
f(x) and (f x) are two forms of functor and argument, the former more commonly used than the latter. These could also be written as:
This isn't to belittle XML, but to recognize what it is and is not. A named parenthesis format is really important and that's why XML gets so much attention. But it isn't a complicated idea -- so recognized that the rest of the noise about XML is just that.
Seastead this.
Or am I missing something?
follow me on Twitter: http://twitter.com/moeffju
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
<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><
</do-in-order>
<forget-formatting/>
<wel
</invoke-slashdot>
</rant>
<remark type="obligatory-attempt-at-wit">But it could be worthwhile.</remark>
</type>
</comment>
<sig>
This flies in the face of science.
Umm... then learn Lisp, rather than re-inventing a half-assed bloated version of it.
All's true that is mistrusted
Some people, when confronted with a problem, think "I know, I'll use XML!"
Now they have two problems.
When this happen, that's when the hacker-counter has wrapped.
This would just be LISP with a fancier, ugglier and less readable syntax. Data and code are the same, and data structure and code structure are the same, and the same tools can process both.
The semantic content of XML and S-expressions is the same, only syntax and verbosity/redundancy of said syntax differs...
Actually, when I was working for MandrakeSoft, I heard one of the hackers there had actually done exactly this - implemented an XML->S-expression rewriter and hacked Scheme in XML...
0
0
1
--The knowledge that you are an idiot, is what distinguishes you from one.
Also, I think the XML thing, which everybody here seems to be harping on, is totally irrelevant. How you represent each developer's custom language settings isn't the issue; the fact that the language can be changed on the fly is.
Have you read my blog lately?
Advantages: ???
Disadvantages: As a structuring language, XML sucks ass.
Signature.
We live in a legacy world. It's about time we work that realization into the technology we choose to use. Most programming languages (and their many versions) are quite similar, but it takes skilled workers and time to rewrite the code. If we could set up XML standards for it, then we could convert code to and from these standards. Not only do we make the rewrite easier, but we preserve most, if not all, the effort put in by the original programmer.
find me at haszak.org
i seem to remember a M$ patent about xml encapsulating programs/set of programs.
too lazy too look, any one else remember, have the details?
If they keep that markup as the API between the code-entry GUI and the compiler/interpreter/VM/whatever, then we'll be able to slap whatever code GUI we want. So we can choose between CLI (procedural), flowchart, "by example", genetic algorithm, etc HCIs for specifying programs. Or we'll get stuck with that unuasble crap that will reduce all coding to scripting, and the HTML "programmers" ("failed graphic artists") will finally have won, and programming will collapse like Babylon.
--
make install -not war
The way we write the language may not be differant to that off todays languages, the XML markup would be hidden from what the programmer types. It could be used to extend the language, it's not about editing XML raw it's about using it as a data format.
His idea sucks. Natural Language programming should be the future, and even that sucks. People should just revert back to the various Assembly languages and be done with it. Granted it takes longer, but with the Internet as a communication link between developers, hundreds of people could take different pieces. Assembly is faster, stronger, better. Leave the higher level crap for scripting and such.
For all the time spent making super-abastract code, and huge architectures that allow marketing types to pull out the 'extensible' and 'scalable' words, it's sad that the fate of many programming projects that have been designed to be flexible up until the year 2082 is that they get trashed when the development company goes south because it has no money left, because everything was wasted on designing an uber-framework that really just turns out to be an uber-waste-of-time.
At least most of these languages had the decency to look like something palatable. (It'll be a cold day in hell before any hacker I know voluntarily spends all day looking at XML. XML is for machines, not for humans.)
Disclaimer: I work for a company, but I don't speak for them.
If somebody made an extended byte code so that I could canonicalize all my java code and be able to extract the same meaningful source (complete with manageable variable names and comments), I'd be all over it. if somebody wants to do that using XML, fine, as long as you don't otherwise kill me with speed/space tradeoff.
Just let me keep working with the editors I like in the syntax I know. Don't expect me to manually code it, just liek I don't manually code byte code now.
www.HearMySoulSpeak.com
Code generators will make most expensive programmers obsolete...
It's all about freeing mankind from boring repetitive work and making it so people can get back to the real business of living, learning, loving, etc.
All the jobs that don't require real creative GENIUS will be done by machines...including programming machines...
"Heading 3 from the article: Programs as Data. Yep, lisp was doing that decades ago :P"
:)
And Forth was Data as code.
It sounds like we all are pining for the "Good , old, days".
When men were men, and our development environments respected that. None of these 'sissified' "Can I wipe your chin?" we presently have.
Before a new paradigm can gain mindshare, it needs to address the fundamental problem of crafting software - reduction of complexity. Hardware doubles in capacity, what, every 18 months? What is the doubling time of software writing productivity? No where near 18 months. Not even close.
Unless someone clearly demonstrates how extensible programming languages allow me to solve problems at a higher level (more abstract expression, therefore fewer lines of code), I'm not gonna buy into it.
I think too many people here are looking at this as I write in xml and now it gets translated into my preferred language. WRONG. On page 5 of the article, the document clearly states that the code will be stored in an extensible format but edited just as normal. In other words, as a programmer this change will be transparent to you. Who cares? I do. Storing code in an extensible format provides an extremely powerful platform for scripting, which is key in any development environment. Perhaps just as importantly, I can port from one language to another in a matter of moments. Combining two differing languages becomes very easy. Quite a bit of software development these days is being done for and on middleware. It should come as no surprise that we extend this extrapolation to compilations and languages.
Gee, an extensible programming language, perhaps we could call it XMLisp.
Another Solution looking for a Problem.
I guess this sort of thing mercifully keeps the academicians off the streets and out of the bingo parlors.
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 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.
XML is not S-Expressions.
Clearly:
1. Modern programmers ahve far to much time on their hands. Computer languages exist so we can solve problems. Where the problem most projects deserpately DON'T need is how to make a dynamic programming environment.
2. Such frippery could never have been implemented any other way. It is only via the magic of an xml tag that extensible code could ever be declared.
I have seen code like this: XTML.
Although the primary idea is that you write all of your call logic with a commercial GUI, the underlying "code" is Turing-complete XML. I find viewing the XML a painful and dizzying experience, but the XTML-specific GUI actually presents a decent view of the logic.
- <function name="printf"><argument value="I don't think this is such a good idea.\n"/></function><semicolon/>
</function>While I'm uncertain of the applicability of this as a technical form of expression, an XML syntax would seem to be a welcome way to approach legal forms of expression.
Software patents are fluid and vague in their expression by design. Unlike copyright protection of the actual code, the patent is protecting the idea and you want to cast as wide and vague a net as possible. It seems to me that an XML expression of the idea (though independent of a particular language) would force an explicit interpretation of what was meant that would be interpretable by a judge (or someone not as fluent in technical syntax).
I dislike the idea of software patents altogether, but if they are going to exist it seems like an XML expression of the idea should be a requirement for any sort of patent submission.
Given how crappy and undocumented much of the C, C++, C#, and script code floating around is today, I can only imagine what horrors the hackers will commit with this kind of extensible mess at 3AM while on a Red Bull buzz.
Thank you, but no. I value professional quality code--efficient and well documented enough that a reasonably proficient coder can pick it up cold and figure out how to make a non-trivial change or addition with a minimal education process.
There are now 140 or so comments, and it is painfully clear from them that almost none of the posters have actually bothered to read the article. If they had, they wouldn't be confused on the following:
The author also makes a persuasive case about programmer's hyper-conservatism compared to other computer users:
Something to think about.OH wait.. No it's called coldfusion.. Yeah that thing that everybody hates because "it's like html!", things like this can never catch on because they are just too easy, no job security for the developers.
Who would want to download source code that looks like this? I bet the open source community would hate it, especially Gentoo Linux users. Please think of the Penguins...
Brain kills internet cells.
Nothing like introducing arbitrary notation into a system to make it clearer, eh?
There is much pleasure to be gained in useless knowledge.
They ARE NOT, this is xemel masturbation. When languages are aiming for simplicity, flexibility and script like charecteristics this guy is suggesting making things unwieldy and verbose. boy does this ever suck..
Do you complain this much about "C"'s semicolons? With a good editor (Emacs was made for LISP). And practice the parenthesis disappear.
For example, at my company our new manager is insisting we change our existing coding standards to match his personal preferences. (I know, this is wrong for all sorts of reasons, I won't go into that here). The article's suggestion of using XML to store the underlying code, and XSLT to display the code would have solved a lot of arguments.
I have been considering developing an Eclipse plugin which would achieve a similar result. The idea being roughly:
Making bold predictions means you don't have to do any work.
How we know is more important than what we know.
Maybe less leaky abstractions in our languages.
Like anything else, it's just a fad. Eventually everyone goes back to C.
10 print "this sux"
20print GOTO 10
It's a basic fact that programmers make x number of errors per line of code. Anything that reduces the number or lenth or lines I write increases my productivity and decreases my error rate. Fuck XML, it doesn't do either of these things.
All those moments will be lost in time, like tears in rain.
To quote one of my coworkers:
"XML is like violence. If it doesn't solve your problem, you're not using enough of it."
To truly understand recursion, you must first truly understand recursion.
Microsoft briefly experimented with somthing called Windows Scripting Components (WSC). It allowed you to create a COM object interface in XML.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
"XML now is what OOP was 15 years ago"
Funny enough. Our computers likewise haven't evolved that much. OOP and Functional programming (let alone prototyping) worked best on "non-conventional" computers. "C" (and family) is basically wed to the von-neuman way of looking at things. Any attempt to hide that fact, simply is to make it look more and more like the "unconventional" languages without ditching the baggage.
Why bother storing the code as XML. In order for your text editor to present things in a bareable fashion, the text editor has to contain a module that parses whatever language you are using and converts that into XML. So assuming that code exists, if you want to write some tool that prefers xml, just use that code to do a java2xml or whatever2xml conversion first. That way people can use their existing tools for existing work.
This is all entirely possible already, there's no reason at all for people to start doing things differently.
http://rareformnewmedia.com/
Ever come across C code like this?
Not fun. Macros are usually a problem, not a solution. (Sometimes XML seems that way. XML enthusiasts are making every mistake made by S-expression enthusiasts in the LISP era.)There's been some discussion of a system for adding attributes in C++. C++ has "auto", "static", "explicit", "volatile", "extern", and "const". Microsoft's version adds another dozen or so more. These are all keywords, and every time a new one goes in, it breaks things. Plus the interaction of attributes and overloading is very ad-hoc. But so far, nobody has made a proposal that looks workable. And that's a minor bit of extensibility in an area where people agree there's a problem.
Another issue is how to manage non-text assets in software. This is a medium-sized problem for most programmers. It dominates game development, where you have everything from level maps to motion capture data to manage. There are specialized tools for game developers, like Alienbrain, to store, track, and maintain version control on all those assets.
Exactly! The big part that I think everyone's missing is that the languages themselves don't have to change, but potentially their storage does. Or, instead of changes to the storage, perhaps the IDE or a 3rd party tool just knows how to convert it to common XML code. Remember, code is just data after all. It has structure too.
So where's the advantage in this? I think it lies in 2 places:
1.) Having code be self documenting become so much easier. Think JavaDoc, only for any language.
2.) 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!
#1 is probably more likely to happen sooner than #2 given that code conversion will be held back by different languages having different styles and ways of accomplishing tasks, but code conversion would really be the major benefit of this.
We all know how revolutionary that cr4p is...
Again!
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
Just take your Java code, and with the right XSLT you have C# or VB or COBOL or whatever.
Then with something language agnostic runtime thingummy you can run any of them.
We seem to be approaching a Zen-ish thing where all computer languages are the same, and their names are meaningless/irrelevant.
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.
How far does one let the non-programmer go in customizing their environment? Til they break all the paradigms that it's based upon? A training, and maintenance nightmare? Anyway look up Glade, or XUL.
Isn't this sort of what IBM's VisualAge tried to do?
It never really caught on because it basically locked you into the one tool suite and was generally a pain to deal with. The argument was "programming in a text editor is like doing an accountant doing spreadsheets in a text editor".
We'd like be able to easily write tools to parse and modify code so we can quickly do refactoring, etc. Makes sense.
So obviously major programming languages should publish their parsers as libraries to make things like this easy to write...
Oh, no, wait a sec, I have a much better idea: let's make programmers write code in a way that's trivial to parse. Yeah, then writing the tools will be easy! Brilliant! The fact that it makes writing any code a lot harder is something we can solve by writing fancier editors!
And while I'm at it, I'm sick of the way there are all these cars on the road while I'm trying to get somewhere. I think there should be a new rule that everyone has to give way to me. Hell, everybody else should be made to ride bicycles.
*Takes gun, shoots self in head*
And I'm being Ha-Ha-Only-Serious on this one.
I don't like trolls and mod against me if you like, but I'd prefer if you'd reply.
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.
My point is, why reinvent the wheel, when half of a wheel is aleready invented in XEXPR?
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
... the first time I saw it, back in 1984 when I first met the macro facility on a Symbolics LISP machine.
I'm not kidding. If this offers anything we haven't had for the last 25+ years in LISP, I don't see it.
What a bloody stupid idea.
"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."
Simple. It takes time, and discipline. Something the computing world has historically been short on. We can produce good code. e.g. spacecraft, aviation, etc. But we're not willing to pay the price in economic, and personal effort. Just look at how much noise is generated by these "(",")".
Now a good IDE certainly helps.
Don't know about anyone else, but I've been using that for a while.
1 /Jun/01 09.html
Many content management systems use xml, and have such a syntax, including logic. Interwoven Teamsite is one of them.
Some tags:
http://cms.filsa.net/archives/cms-list/200
Particularly useful (though sometimes a pain) was iw_iterate. Which I guess was prettymuch a foreach
Along the lines of "LISP with ugly parens" is the Water project at MIT.
I've had my own adventure along these lines (Unigrok really *is* XML) but you sort of run into problems embedding a real language into XML because of function return values.
As in how would your "syntax" indicate returning values from a function or user-defined tag. Try to be too general and pretty soon you've got XSL on your hands (and still haven't solved the problem).
...let's teach programmers to write BUG FREE code first.
Of course, I'd settle for remote code execution code free.
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
From page 5 of the article:http://www.acmqueue.com/modules.php?name=C ontent&pa=showpage&pid=247&page=5
Maybe it is, but in both cases it obfuscates/confuses what you want to say; it's worse than perl. Maybe that's what this guy wants - programs that look like line noise, written in "Ingrish" and stored in xml so they're harder to debug.OTOH, there's nothing stopping anyone from writing their own code generator/translator, which is all this really is. Also, for prior examples, the Clipper compiler was extremely modifiable (and that was 2 decades ago). Heck, you can even use make, cat, and a couple of perl scripts to translate plain english into code if you're REALLY desparate to find something to do with your time. (Anyone remember the dBASE code generators? Ugh!)
It does not mean that programmers will be typing in straight XML, it means that they'll be using smart IDEs of one sort or another to interact with their code, and probably that XML to (language) and (language) to XML filters will be built.
This greatly facilitates a number of things that are currently difficult - here are a random few (not all I can think of and in no particular order) :
And more.
To some extent this stuff is available today in one place or another. Using an XML based markup for the language would make such things much easier to implement and much more under the control of programmers.
I'm not a fan of using the wrong tool for the job. At work we normally use PHP for web applications, but when I see an advantage, I will stray from the "norm" and use Perl.
XML can be a very good candidate for coding logic. We are starting to do this with several libraries we have developed for manipulating data. It is much easier to get a text document at a major company published than it is to get a DLL published. The DLL is the main engine, controlled by XML documents. We can then create a "custom version" of the library by supplying different XML documents that contain layout and logic. We can write the engine once, then customize it via XML.
A few years ago my group actually did build a programming language, essentially a PHP replacement, with XML syntax; you can see the results at http://www.risource.org/PIA/ and http://cpia.sourceforge.net/ .
The astute observer will no doubt notice that neither of those projects has been updated recently.
...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!
Base all first-year CS courses on this language. The metric for passing the course is simple: advance all the students who quit this class to the next year CS courses, and drop all the students who stick it out the whole semester because they are obviously tools.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
Here's an example C function that sums a vector of integeers:
// the return value.
int vsum(int *v, int v_len)
{
int rv = 0;
int i;
for (i = 0; i < v_len; i++)
rv += v[i];
return v;
}
The above sample is horribly unreadable and suffers from eXtendibility deficiency.
Watch how the same program written in eXtendible becomes far more clear, precise, and managable.
I tried to format this with more space, but the slashdot posercomment compression filter kept rejecting it.
<function name=vsum>
<param type=integer refernece=pointer>
<param_name>vsum</param_name>
</param>
<param type=integer reference=value>
<param_name>v_len</param_name>
</param>
<body>
<localvar type=integer reference=value>
<local_name>rv</local_name>
<comment>The return value</comment>
<inital_value>0</initial_value>
</localvar>
<localvar type=integer reference=value>
<local_name>i</local_name>
</localvar>
<iterate type=for>
<initialize>
<setvar name="i" value=0/>
</initialize>
<cond>
<expr>
<left type=var name="i"/>
<right type=var name="v_len"/>
<operator type=less-than/>
</expr>
</cond>
<pre_cond>
<setvar name="i">
<expr>
<left type=var name="i"/>
<operator type=auto-incr/>
</expr>
</setvar>
</pre_cond>
<loop>
<setvar name="rv">
<expr>
<left type=var name="rv"/>
<right>
<expr>
<left type=var name="v"/>
<right type=var name="i"/>
<operator type=array-index/>
</expr>
</right>
<operator type=add/>
</expr>
</setvar>
</loop>
</iterate>
<return type=var name="rv"/>
</body>
</function>
scientists anounced the world will be coming to an end right after the anouncment of the XML for programming language endevour. Seriously, we use XML at work and the overhead of XML has made us all sit back and think, mabye everything shouldn't be in XML.
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.
One section is titled "In Defense of Monopolies" and the author goes on to say that Microsoft being able to dictate a programming language onto people is a good thing, because it fits his agenda!
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
Who needs all that crap in the code for stuff like formatting? There's too much already - mostly whitespace, but also all the other structural delimiters like braces ('{'), parentheses/commas of lists, type identifiers like "sub" or "int void()", even repetitions of variable names. Of course all that stuff should appear in the presentation of the code, when reading it onscreen. But I want a tokenized or otherwise structured form of the code stored in records in a relational DB, factored down to the minimal representations of the code graph. A copy of the edited source textfile can be stored as a blob, including a "compiled OK" flag. I want to view the program by serializing it with formatting and real object names (rather than their indices in the "objectNames" table, changing from, say K&R indentation/newlines to my own idiosyncratic version. I want to ask the code questions about itself, like "how many local variables are called 'index'", or "change all function calls and definition prototypes that return 'time_t' and take 'int8 yy' arguments to instead take 'int32 yyyy' arguments', and complex related combinations. I want every block opener to include a comment (eg. "{ // \n"). I want to refactor code by asking a tool to use some version of "SELECT DISTINCT_BLOCKS(blocks)", or even smarter SIMILAR_BLOCKS(blocks). Get a package with no docs? How about "SELECT DISPLAY(scope, range, code) FROM program WHERE kind=comment", and save the result in README.raw? Wrap that in an HTML generator that marks up the scope/range/code IDs into query URLs to display the commented code, and you've got JavaDoc - as an afterthought to coding, without caring while you code.
Source code is some of the most highly structured data we make. We should be able to use our data tools to handle it better. I want distributed clusters for uptime, distributed compilation, codesharing and version control. I want replication, dumps and stats. We're already using the hierarchical database, the filesystem, that we've been stuck with for 30 years - it's time to move on. We can keep, eg, C's "file" scoping as a virtual construct, but we can share that single file with several projects, and even have several versions used under switchable circumstances. Who will recode gcc's filesystem calls to SQL?
--
make install -not war
You have a valid point, but think of scenarios where you have to do analysis of the code. You would be needed to convert into native format before any analysis is possible.
Well, I have been secretly working on Profile Programming. With Profile Programming I propose that the next generation of programming languages will use INI files.
I'd love to use a derivative of C++ whose source was maintained structurally, and which had tools (editors, etc.) that supported it, provided I didn't need to learn a new syntax to code in. It would certainly allow for much easier to understand and code compile-time processing, which is currently performed with template meta-programming and which is generally a royal pain to get right, portable and not too buggy. Hygienic macros for C++? Cool!
ASP.NET uses XML markup for the front-end GUI stuff. For example, if you want to add a TextBox Web control to a page, you add:
Hello, World!
Which basically is translated the first time the page is visited into a class with a TextBox class instantiated and added in the proper place in the control hierarchy.
I really like this approach of XML syntax for defining the UI of a page; it makes especially good sense for Web pages, since developers are already familiar with the XML-like syntax of HTML markup, and this allows them to just add Web controls in a similar fashion embedded within their markup. Microsoft likes this approach enough that Avalon is spelling out UI-specific bits using XML in the same manner. This strategy makes sense if you look at it in the long run, since it allows for:
(1) A unification of ASP.NET and Avalon syntax. Once you have this, there is no difference to creating the UI for a Web page vs. a Windows application.
(2) It allows for a platform-neutral manner to specify markup, thereby allowing a hosted application to be run on a variety of platforms/devices. Basically, I can have a server that has the UI markup, you ping my server, I send you the markup, and you render it appropriately on your device.
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
If ever there was proof that anything is possible...
http://search.cpan.org/perldoc?PPI
Back in my early 20s, compilers and development systems were my primary interest in computers. (My reasoning was that we as programmers spend all day interacting with a development system, but don't seem to spend much time thinking about the development system, and I wanted to change that.) My source code format was going to be structured text, much like XML is nowadays. (Back then, I only had SGML as a reference.) I generated a huge stack of notes and thoughts on the system, but got to the point where I realized I'd need a team to have a reasonable chance of implementing it. And so it remains paper.
The reason I chose an XML-like source code format is that I wanted to allow the source code to be browsed by whatever visual metaphor the programmer felt comfortable with. The vast majority of average programming constructs can be expressed in any language, and allowing language-specific displays of XML-stored information seemed like a good way to allow programmers to use the system without a huge learning curve. It also allowed code written in other languages to be imported & turned into native XML-ish code instantly. That's important for leveraging legacy code.
Of course, the system supported far more constructs than the average language. It seems that most programming languages have some sort of religion they want to whip on you, and the language has a combination of features that tend to reinforce those religious beliefs. In contrast, my language featured every programming construct, and the ability to add new ones -- extending the compiler was intended to be as common as writing a subclass. The logic here was, we're real programmers implementing real projects in the real world, and we need the tools to get our job done, not some religious language-designing ninny forcing us into their dystopia.
To combat the obvious problem of bad programmers writing code that no one will be able to understand, I designed the language as two layers: the lower one is called Clay, and the higher one is called Scaffold. The idea is, Clay allowed programmers to do anything their heart desired, whether ill-advised or dangerous or whatever. It was something like a compiler-development toolkit exposed as a language. Scaffold, written in Clay, was an attempt to create a real software-engineering language on top of the free-for-all that Clay offered. Scaffold combined the low-level programming abilities of C++, the design-by-contract of Eiffel, the orthogonal pattern construct of Beta, and the high-level browsing of something like Rational Rose. The GUI would handle programmers writing code in metaphors they were comfortable with, and all of it would be stored in XML. The junior programmers would spend most of their time in a variant of Scaffold, and the senior programmers would write Clay constructs to make the development system more closely match the project, and thus make programming it less tedious and error-prone.
Oh well, it looks like once again, ideas I came up with years ago have been independently discovered, and due to my inadequate promotion skills, someone else will get the credit. I tried describing something like this back in 1995 or so, but got only glazed looks in response. (Want to hear about a neat video game I designed on paper back in 1992? The one I called "Turf"? Where you start out as a thug on the street, get jobs from gangs, and work your way up to more difficult jobs that pay better, and meanwhile you get to wreak havoc in an urban landscape? Sounds like Grand Theft Auto, you say? Damn right it does. I described it back in 1992 and got only glazed looks in response. Being visionary doesn't mean squat unless you can promote.)
- - - - - - - - - -
Think The Fountainhead is just a book? Check this out.
"Once we've identified and embraced our sickness, we'll have strength...and that's when we get dangerous." - John Waters
The idea that a program would generate the XML for me, based on what few, horrible, GUI tools it decided to expose, is scarey on so many levels. VS.NET is the biggest abomination yet to come out of Redmond. We don't need this type of bloatyness rammed down our throats even more!
"I knew I'd hate COBOL the moment I saw they'd used perform instead of do." --Larry Wall
'Nuff said.
Laws do not persuade just because they threaten. --Seneca
Teaches me to hit preview first... Anywho, it should be:
...>
<asp:TextBox runat="server" id="myTestBox"
Hello, World!
</asp:TextBox>
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
Has it occured to you that if writing language extensions were easier, you would do so more often?
We are already creating words (named functions), creating rules to use them (languages...) would allow you to create task-specific languages very easily.
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 would have to write a parser, of course!
This XML encapsulation is a misguided effort to create a standard interface to code parsing. Guess what! A highly effective parser already exists for every single programming language. It's the compiler!
To encapsulate source code in an XML form that redundantly specifies how it is to be parsed is asking for trouble:
- What if the XML markup ever gets out of sync with the plain text source code? Either:
- Software for editing/validating/formatting the code WILL catch the problem. If so, that software must include a parser for the ASCII source code, thus rendering the XML useless, OR...
- XML-ified software WILL NOT catch the problem. The code might get highlighted incorrectly in the editor or incorrectly validated by the code checker (yikes!)
- What if compiler writers get lazy and start relying on the "pre-parsed" source code. Now the programmer might be in the lovely situation of editing plain text code that's marked up INCORRECTLY with *hidden* XML code that's affecting the compilation of the program.
My point is, don't include redundant information in the fundamental form of your source code, because it will get out of sync somehow. Remember all those wParam variables in 16-bit Windows API? The "w" was supposed to "document" that it's a 16 bit variable. Now it's declared as a 32-bit variable and everyone calls it wParam... if they still code in C. At worst, it's misleading, at best useless and annoying.If people want a standard way to decipher language syntax, then compiler writers should write hooks in their compilers to export the parse tree in a standard format. Heck, it could even be an XML format, but this should be treated like an object file (it's derived from the source code rather than the source code itself).
My bicyles
Workflow engines have done this for years. Xforms can be extensible in this fashion as well. Basically, any engine that interprets some type of XML tag that describes a condition and runs a proceedure call based on that condition with a list of parameters does what this guy is talking about.
FreeSpeech.org
As a programmer, I currently can't even handle HTML generators, and prefer to code (most of) my web pages by hand.
I wonder what becomes of Big Ball of Mud spaghetti code when translated into XML. How much worse can it become?
Another key issue may remain efficiency: compile and link times have remained issues for large projects, as program complexity keeps up with performance increases.
I'd bet on pure text source code for serious programming in the next 10+ years. Which doesn't mean that the Visual Basics and Mathematicas of tomorrow won't choose and XML-based storage format.
"Base all first-year CS courses on this language. The metric for passing the course is simple: advance all the students who quit this class to the next year CS courses, and drop all the students who stick it out the whole semester because they are obviously tools."
And yet when the AMA tries something like that. You all complain about "the man" keeping you down, and "greedy bastards" (amoung other things).
I look forward to the first virus hidden in the meta-information of a program's source code.
Nothing new really.
There's one called Forth that came out years and years ago. Very nice little language, even complete with incremental compiling. Unfortunately it never made it to mainstream.
But we already have an extensible language.
quidquid latine dictum sit altum videtur.
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.
# (/.);;
- : float -> float -> float =
I think this is stupid .
Obviously not a coder.
XML is for data not a programming language. Please.
Don't most programming languages already have formal grammars? Why would you need to mark them up.
It's 10 PM. Do you know if you're un-American?
um, i kinda like the way we're doing things now. so thanks - but no thanks. :)
I can see using XML constructs to imbed documentation inside of source code so you can later extract it to whatever format you want.
I can see using XML as a transport encoding mechanism for moving data from one location to another - and for translating that data from one data management system (say a relational database) to another incompatible system (say to an object database).
I can see using XML as the native format for all my writings (so that, again, I can translate to any other format I like now, or 200 years from now).
I can see using XML as a configuration language for applications - so I can create a standard shared language between all of my apps.
But for other tasks such as generating code or providing a macro layer to an application, I would just use the language I am already using to accomplish the same thing - and probably do it more elegantly/expressively for people trying to get something done fast - which is really what code generation/automation is about (and I must say that code generation should never replace well designed libraries of routines).
As for using it to port code to other languages --> this is bad, for several reasons, not the least of which is the optimized structure in one language can be a total dog in another; to effectively do this you will need to build some sort of super optimization library to restructure the output code for every possible language variation.
This is interesting from a laboratory perspective. As far as I am concerned it bombs from a practical perspective. Most of the XML I write is via a wysiwyg editor for all my first drafts - then I tweak as needed - simply because it is tedious to use. I can't imagine using it as my primary programming language.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
after invoking the correct dtd (and finding one of the three people on the planet who can write a complex dtd without fcsking it up b.a.r. or making it pig slow to parse)
< /value></initialize /arguments>i able><compari son>lessthan</comparison>e valuate>> <integer>i ncrement</integer></operator</loop_check_top>x ecute>
then we can write things like
<loop_check_top><initialize arguments><assign><argument><variable> i </variable></argument><value><integer>0</integer>
<evaluate><argument><variable>i</var
<integer>3</integer></
<modify><variable>i</variable><operator
<e
Which is terrifically easier to read than
for(i=0;i<3;i++){
and because execute can be rendered in different ways so that the { goes on the next line. That's some powerful stuff.
And because with our really smart DTD's we can emulate this exotic loop structure in languages that only support checking loops at the end by creating some automatic variables!
Give me a break.
<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>
I think you can make it even better.
For each '
for each > have the following:
>
Write a program to replace every tag in the manner that I suggest, and then run the xml through that as many times as you feel is humourous enough.
I like XML, it is a cute way to store data but it is a very band-width intensive way to store data.
How about this way to store data:
for the binary byte 0xff:
1
1
1
1
1
1
1
1
And then, because it means the same thing, it doesn't matter what order you put the bit fields in, because the data is all there, isn't it? And if you can't see that you must be blind.
XML is good for somethings, but not for all.
And it works very well at seeming to be hard to understand (which it isn't) and so it seems like magic.
I still like just using a structure definition with well-defined types of a known number of bytes and known byte order.
Do any of the OOPSLA monger really believe that we are still fooled by their non-sense?
Yegg, more bloat. Stupid idea to let people code in XML.
Shows that the poster didn't bother to RTFA. Of course you're not supposed to code directly in XML. XML is not very human readable. It is, however, easy for a machine to parse. The programs are stored in XML, programming stays more or less the same.
What does this do that I can't allready do in C?
The point of the article is that programmers should stop thinking of their code as a stream of characters but treat it like a tree. For example, when I want to change all the name of a function, tools like grep and sed don't suffice because they can't tell if a string belongs to a function call, comment or literal. A refactoring tool needs to know the structure of the program. Of course there are allready tools that are capable of this (Eclipse?), but they are in fact a partial compiler. Why not get rid of this duplication? If a language gives you easy access to the abstract syntax tree everyone can write his own refactoring tools in a minute.
Another way to look at it is this. If you'd have to design a data format to store an abstract syntax tree that is flexible and can last a few decades, would you come up with the following?Yet, this is how most abstract syntax trees are stored. You and I would probably define a format that represents the tree structure of the program more directly. This could be easily realized in XML.
The best known example of an extended language is C++ which originated as a "C with classes". Stroustrup added a feature to an existing language instead of writing one from scratch because this would have meant existing code had to be ported and the new language would suffered from the same problems as any immature language. The disadvantage of this approach is that of legacy mistakes like the declaration syntax in C. This particular problem would be non-existing in a language that was designed to be extended.
Bah, lisp can do this since 1950. When will people see the light?
IMHO never. A similar article from the same author was on slashdot earlier, in which he acknowleges that lisp can allready do this but also that lisp is waiting for a breakthrough for four decades. XML may not be the most elegant solution but it has the momentum.
The above mentioned article adresses some other objection people might have: e.g. that desiging a language is a difficult process because of the effects language constructs have on each other, and that therefore we shouldn't give this power to every high school student.
Beating the Averages by Paul Graham is a good start. What made Lisp different and On Lisp are also by Graham. Lastly, one from Franz Inc on domain specific languages on top of Lisp. Really, if you've never used Lisp and you want to create your own language, you're missing the boat.
Sounds like it would really work, like plus with a twist. Curve and engrave your own squares. The difference between machines and langauges are in the ends. The machine only reads code which it signifies patterned. Those of us building langauges pattern our own, postulating a purpose. Sounds really amazing that langauges are other than useless. I'd like to meet those guys. ThankYou. ThankYou. Refreshments and information are in the lobby when you leave.
Waiting for the challenge to bring job security. :-)
C isn't extensible. C is still C. You can't chenge the structure of C. You can pull some tricks with macros, but it is still C.
Forth allows to to hack the **compiler** on the fly (ie during the compile). This makes it pretty damn powerful, but is also dangerous in the wrong hands.
Engineering is the art of compromise.
a few years ago, without (IIRC) the extensible language part. I don't remember who. Sorry to worsen your pain but, ideas themselves are cheap; implemented ideas are what make the world go 'round.
The good news is that, everyones' thinking of this means that hopefully it's an idea whose time has come. I sure hope so.
Someday we'll all be negroes
just like Web browsers and other WYSIWYG editors
*giggle*
*snicker*
*sob*
Have you used any WYSIWYG editor that didn't mangle markup or render it poorly?
Tweet, tweet.
I hate programming some times.
This is useless. Waste of news space too at that.
Seriously, LISP is like XML except with less typing, and it's a programming language too. It's also exensible. People won't use it because it's too "strange", and typical implementations are either mere toys, expensive, or have issues with using libraries.
It's called Ant.
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.
I can see the point of this... it look to me to be a bit like C Macros. A way to invent your own keywords and the like.
But, personally I find a major Hell can be to be given some C code that is chock full of Macros and then attempting to make sense of it. Having to go look in all sorts of places to figure out what neat trick the previous programmer was playing.
I'm very glad macros were downgraded in C++ and disappeared all together in Java.
Creating your own neat language extensions in XML might be fun and help you out in the short term, but pity the poor fool who has to make sense of it later.
And face it, XML is an excessively verbose, pain-in-the-arse to read. Especially when things get complex and nested.
But as a language translator, or a YACC front end, it's as good a plan as any.
The reason that one creates layers in code is to allow for hooking into the code later with patches and modifications that maintain the idiom of the other layers.
That is why there is a 7 layer stack for communications. 7 layers! but why, that is too complex! However, when looking at it from a position of understanding you see the elegance of it. The abstraction allows for an elegant idiom with the various layers!
And if a layer is not used it is proxied. That way if real code is needed later the hooks are already in place to do this. If you don't need a layer of the stack it calls a proxy which calls the layer below. A complier will optimize away these calls. So the actual code doesn't do anything at this layer unless the calls to it are implemented.
abstraction is thus a very useful tool. A module or an object can be an idea that is a useful tool for the programmer. This is why one doesn't write to the bytes in hardware, but to a device driver. This is why one doesn't write directly to the harddrive but to a layer that takes requests from all processes to do the writing.
And so I conclude that abstraction is often much simpler in the long run. I think that what you may object to is obfuscation.
I've been using JSON (JavaScript Object Notation www.json.org) for a couple of years now for all my JavaScript application programming frameworks and it's paid off extremely well. I can easily express complex data structures in an extremely compact format that is easier to read than XML and is about 40% smaller. I use it for program configurations to hashmap type data structure definitions.
The beauty of JSON is that it is natively interpreted by both JavaScript and Python making it very fast to parse.
Sure JSON does not allow for complex meta definitions, but in most programming designs like XML but more often then not, XML is the equivalent of cracking open a walnut with a sledgehammer.
With proper coding you can use this meta definition model with any language.
json={
coolness: "high",
ease: "high",
nativeSupport:[
{type: "language", name: "JavaScript"}, {type: "lang", name: "Python"},
],
nonNativeSupport: "You name it"
}
JsD
Let's hope they wouldn't leave this code style in published source. One example given in some comment elsewhere was a 4-line snippet of C that turned into a 16-line behemoth of XML-compliant C. That's a 400% increase. So instead of a 40MB kernel tbz2 that unpacks to a 300MB source tree we'd have 160MB archives that turn into 1.2GB trees? (Yes, I know it doesn't exactly work that way and that those numbers are probably more than a little exaggerated. But you get the idea of the ridiculous amount of extraneous text that'd be included in these new source files.) New proposal: Let developers use this XML thing so they can easily go make changes. Then they can export code in a less verbose format (i.e. sans XML) for faster download and less space taken up.
Sorry, my karma just ran over your dogma.
XML is not a programming language, and should not be treated as such, the syntax is simply blasphemous.
XML is good if you want the data to be read and/or modified by a human, or if you want to exchange data between 2 different programs that would otherwise have no common language. This is what XML should stay as. I've seen applications that use XML to store proprietary data that no human would ever need to read! This is a completely wrong use of it, as it just wastes the programmers time, and the processors time parsing the XML. People need to learn how to use things for what they are meant for, and not force stuff to work for applications they weren't designed for.
...Had this been an actual emergency, we would have fled in terror, and you would not have been informed.
Is someone seriously suggesting that the atrocity that is ColdFusion syntax might be a good thing!?!? Its slow, its ugly, and it's far too verbose. When I look at code, I look more at the shape in which it's written than the actual code itself, and can skim over it much more quickly than anything XML based. No no no no no....
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
I click on the demo to "see it", and all I see is a puzzle piece and "Download Plugin". Thinking that led to this page is *exactly* the whole damn problem with the thinking behind the language and why people stick to ASCII. We already have a standard format (ASCII)... why do we need XML (a !subset! of ASCII)? Proper greek letters? What you want special keyboards to go with that? Like APL. That was another brilliant idea. Wait another *dead* idea.
The worst problem with all this junk is mentioned in the article. Debugging the freaking crap. Imagine what happens when you don't have the correct plugin to view the code the way the author looked at it. And the author moved on, and is nowhere to be found. Have fun with that....
I am sorry, but the problem you are proposing has already been solved - by the compiler - and you don't want to reinvent the wheel, or duplicate code.
You think I am kidding? Open any modern Java IDE (e.g. Eclipse). You see the whole structure of your program in a huge tree, where you can seamlessly browse through files, jar files, classes, methods, etc. How do you think this works under the hood? I'll tell you: It's nicely navigating along the compiled bytecode. Already parsed, and guaranteed to conform to a well-documented standard. No point in replacing the bytecode with XML.
Under capitalism man exploits man. Under communism it's the other way around.
...when looking at standard C/C++/C# code, I noticed how much the curly braches {} create a kind of structure similar to XML, and wondered about making an XML version of C++. Everyone here seems to think that's insane, but that's because they're thinking about making EVERY element an XML element, which isn't neccessary. You only need define blocks this way. For example:
<class name="Parser">
<memberVariables>
<private>
int id;
char* socialSecurity;
char* fullName;
</private>
</memberVariables>
<methods>
<method name="ParseDocument" params="char* doc, int block">
int len = strlen(doc);
<while cond="len != block">
len -= block;
</while>
</method>
</methods>
</class>
It almost looks cleaner, though definately more typing. Why would this be useful? It tends to make the meaning of staements more clear. It forces you to say what block you are ending (instead of a generic }). It can be easier to parse. Standard off-the-shelf XML viewing technologies (XSLT, CSS, etc) can easily render the code in a useful way, and can even understand it without really understanding the language.
Maybe not seem useful, but could very well be. One unusual use I can think of would be the possibility of defining things like concurrency hints using extra, optional parameters.
Congratulations, he just reinvented ColdFusion.
Table-ized A.I.
Here is a ColdFusion code sample.
Note it is not "pure" XML, or at least offers shortcuts that are not pure XML.
Sounds like a complete mess to me. Can you imagine maintaining a project where every developer was writing in a different language? Can you imagine the completely idiotic constructs that would appear in the code of every junior developer with a God complex (read: all of them)?
Computer languages, like real languages, exist so that we have a common way to communicate with other people. Allowing people to change the underlying language would be like allowing to introduce new grammar rules and words into English and expecting everybody to communicate essentially in different languages.
Why doesn't Slashdot ever get slashdotted?
Really. I think Visual Studio
VS.NET will need more memory, everything will run slower, projects will have problems when the new XML stuff has a bug.
A full build of Windows will take a week.
And, for all that, they'll get the benefit of... Well, if they ever happen to need to convert to a different language, they might be able to.
(Really, it's a bit like towing a giant boat behind your car all the time, because you just might have a chance to use it. Except you live in southern Libya. In the desert.)
Meanwhile, Mac developers, unburdened by this stuff, will tear ahead.
Yes, I think this is the wave of the future. Microsoft should jump on it.
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
You might want to check out o-xml and srcML among others. The work that Martin is doing on MLML is pretty good. It doesn't mean you have to write XML as the source code format but you can incorporate unit tests, UML and documentation all in the one format.
[Please type your sig here.]
You might want to check out these archives from the o-xml mailing list. The last could of weeks have had some good discussion on the issues /reasons for XML based langauges/transforms.
[Please type your sig here.]
Your code is sloppy, uncommented, and probably won't run. You should join the slash team.
It seems to me that the article conflates several different kinds of extensibility under one heading and that the different kinds have different virtues and vices. One kind of extensibility is the abstraction and information encapsulation that OOP provides. That seems to be a win. Another kind of extensibility is the ability to "go meta" provided by reflection. This is provided by languages like LISP and by strongly object-oriented languages in which everything is a first-class object. It too seems to be a good idea.
A third kind of extensibility is the ability to modify syntax. As I recall there was somewhat of a vogue for this in the late 1980s though I can't remember the names of the languages or any other details. My memory is that it proved to be a bad idea. It removes the framework that we rely on, especially for people reading other people's code, or for people reading their own code after time has passed. Languages with powerful macro preprocessors allow the ability to modify syntax. Here again, my experience, and I think that of many others, is that this makes life much more difficult. In sum, I'm not sure that extensibility in the general terms discussed in the article is such a good idea.
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?
XML has the right approach to a particular problem -- a common way to organize data into a hierarchy. But there needs to be a faster way of doing it -- I'd vote for binary-XML. Or some re-engineering of traditional XML.
You see, XML by itself is not any more readable than C by itself, so there's no good reason to state the name of the element twice (at beginning and end). Attributes are pointless, basically just another way to do sub-elements. And it was developed too slowly -- I dare you to find a browser that has support for XML includes, for instance.
I read about some other alternatives -- YAML, some Javascript-based thing (designed to be parsed by almost any compiler with very little preprocessing), and others.
But frankly, I'd rather design a standard programming language (not C) and use mmap.
Don't thank God, thank a doctor!
Insert picture of programmer popping the key tops off a keyboard and clipping them back on in different places.
Insert picture of Model M.
The .dfm file is binary, but it has a textual representation which is in Pascal syntax -- I guess they have a Pascal parser (while not Lisp, I hear that Pascal is pretty easy to parse) that they use to that purpose.
If I were in charge, I would be a little less coy about the .dfm file and its textual representation. I may also consider a standardized Pascal syntax for describing graphs and data -- there is this thing called VHDL that has an IEEE standard and is used for hardware design, but it seems perfectly suited for a Pascal-syntax answer to XML. And for you C-syntax proponents, there is this thing called Verilog.
The programmable programming language par excellence is Lisp. My main programming language is Lush, a Lisp dialect. I use it for everything: numerical stuff, games, scripts,....
Yes, I found that just because it is possible to automate conversion, it doesn't mean you/'ll get editable or maintainable results. I'd also about how many inefficiencies would be introduced when attempting to emulate features that are not native to a language (like the Perl work-around for case statements).
I used the a2p tool to convert some awk stuff to Perl so that we could run it on Windows. Whilst it worked, the resulting Perl was not particularly easy to read, even for Perl.
Xix.
"Everything is adjustable, provided you have the right tools"
I actually created a tool about 4 years ago for a project named WorldInsure that would translate XML into java and then compile it into bytecode for these reasons:
the new XML language was a small subset of a Turin complete language (Java in this case) that would impose schema validation rules onto the produced XML structure. The problem at hand was the following: a bunch of people sitting there, creating mapping algorythms that map a set of insurance rules from any one company into a generic set.
Apparently, after looking at it for some time, I realised that the problem was a programming problem limited to only a few simple functions with a small possibility of extensions. So about 95% of work of mapping data sets was done by 2 or 3 guys who only knew the mapping rules but not programming who still were able to produce most of the necessary mappings with this tool (that validated their manual work, no less,) and the rest 5% were added on top as custom java.
This worked well, but it was not a Turin complete language, just a domain specific language type.
You can't handle the truth.
And there is YAML. It's already quite popular.
even XML cannot save him.
This is really about the ages-old war between the suits and the geeks. This war is actually a class war between the rich and the middle class, but in the current discussion the relevant part of the war is the tension between geeks and suits, which I'll touch upon.
.Net (which became so Java-like it was suitable for Real Programmers again). Brief dalliances with 4GLs didn't work out. The suits want to know, "what is the next step? What is the next Great Thing we can stab in the backs of the programmers who bedevil us?" And they've got a lot of money to spend, so they've got plenty of programmers working like busy little bees to produce the tools they crave.
Let me start with the geeks, to put things in perspective.
Geeks are generally middle class children of blue-collar and low-to-mid-level white collar workers. They've had to work for everything, and they studied in college, so they're pretty sharp. They're also hungry -- MUCH more hungry than the pampered ivy-league kids of the suits.
Middle class kids study practical things like computer science, engineering, electronics, the sciences, technical trades... They earn a good salary because they can do the work the suits cannot, something the suits absolutely hate them for. And they're capable of working with traditional software engineering tools without handholding because THEY STUDIED.
On the other side, you've got the suits.
The suits think it's a terrible shame that there's an entire class of people they have to pay a living wage to. Although they can't see the irony in this, they actually consider middle class people "greedy". Their main goal is to STOP paying a "living wage" and get out of obeying worker protection laws.
In the past, they've had successes against the middle class. They killed off the domestic steel industry, putting thousands of people out on the street, and then they repeated the exercise using the same techniques to kill most of the automotive manufacturing industry and every other manufacturing industry they could.
Up until the turn of the century, however, they couldn't kill off the white collar and tech workers because they needed them to maintain their systems. There were no huge trans-Pacific cables and satellite systems back then, so outsourcing to other countries wasn't practical. And there was no practical way of bringing foreign staff here.
So, first, under the guise of Y2K preparedness, they brought over thousands of H1-B workers, flooding the market with cheap programmers. Then, they built up the network capacity between the U.S, Asia (particularly India), and Eastern Europe. Satellite communications were improved. Gradually, there were no more barriers to their plans to move all the REST of the middle class's work overseas.
Of course this is happening right now. But think about the next step.
See, moving all the work overseas to destroy the American middle classes (or at least cut them down to a size rich people are more comfortable with) CREATES a middle class over THERE. Well, sooner or later, they're going to want a decent salary too!
So, the next obvious step is to make programming easier, and easier, until it's almost so easy you can train monkeys (or A.I.) to do it. Or a secretary. Or whichever third-world people are still willing to work for slave wages. As each third-world country improves to the point of independence, the rich will move to another one because that is the way of things. To facilitate this, programming must be simplified.
The first step in this path was Visual Basic. Each version of Visual Basic has gotten easier, at least until
And, all of this XML silliness is designed with that exact goal in mind: to dumb down computer science to the point where IT becomes cheap for the suits.
It's all about money, same as it ever was.
Why all my fellow programmers don't just go ballistic and lynch the programmers who are writing this stuff is beyond me.
Farewell! It's been a fine buncha years!
the whole point of programming language structure is to cleverly *restrict* what is possible so that you can say: "well, even though this is 30,000 lines of code...i know that nobody can possibly modify this variable...and it's guaranteed that A happens before B... if C and D are happening at the same time, there are no problems. Some languages have thread monitors, others have the compiler enforce coverage of all cases, others provide encapsulation guarantees, and all provide various levels of type safety.
If you want a parse tree oriented syntax, then why not use a LISP variant? At least it's compact and consistent. With XML, every opening *and* closing tag just has to consume 12 characters, with namespaces bloating everything beyond reason and comprehensibility. I guess ColdFusion is a pretty good example of what happens when you try to make XML into a programming language. Your whole design ends up being dominated by workarounds, and you have a "language within a language" mess of tags.
And don't get me started on the use of signed and encrypted XML...not writable or readable in a text editor, and might as well be binary. If you create a standard that will only work on the fastest connections, or with many useless layers of abstraction, then you will automatically cause "standards" to FORK...because the standard won't scale DOWN.
The most common cause of pointless complexity in apps in recent years seems to come from everybody jumping on the "combine lots of indirection with typelessness" bandwagon. It's real fun trying to debug a large application when components are only related by many layers of loosely coupled string references that can't be tracked or detected easily by the debugger. (misspelled a class name in that huge web.xml anybody? compiler didn't catch that?) There's a reason why there's no lightweight tools that you can simply invoke on the root of a J2EE app to verify it's structure as well as Javac can do with java files.
Please, Please help make the XML nightmare stop. The more of our customer's time we waste fiddling around with our under-engineered monstrosities, the more our customers will rebel and go find cheaper programmers to do the job.
LISP and s-expressions reveal XML as the ugly duckling, wanna-be language it is. They are so much more beautiful, so much more regular, so much more powerful that it's amazing that the XML world has gotten as far as it has without someone pointing out that the emperor is wearing no clothes.
;-)
Sufficiently large quantities of XML are indistinguishable from line noise to me. So what have they achieved? A language neither readable by humans, nor machines.
What has XML added to the world of computer science that didn't already exist in a simple zen-like scheme interpreter. I'm serious when I say simple. Check out SIOD (Scheme In One Defun).
At least with the scheme interpreter you get a complete programming language. You can program Zork in Scheme. I know because I have.
In scheme or any other minimal lisp, config files simply become script input to the interpreter. Python comes close to this ideal and borrows heavily from LISP in many ways. You could almost call Python, LISP without the parens.
Honestly, some of the editors that they have on Slashdot are hopelessly ignorant. Don't even talk about language extensibility until you've at least played with FORTH or LISP. In FORTH you have access to the core of the interpreter and compiler in real-time.
Of course for bad programmers that's certainly a double-edged sword. Bad programmers can barely handle the full range of flexibility offered by C without slicing themselves to pieces.
Wake up Slashdot. The cluephone is ringing.
From what I can understand in the article, XML is just used to represent an abstract syntax tree with metadata (e.g., "<doc>" tags). The author even admits that we could have done the same thing with LISP expressions....
If the author's suggested systems were to come about (and they certainly sound nice), why on Earth would they use XML?
The compiler, debugger, and editor (plus profiler and other helper apps) would all have to be written for the new data storage format. Without one, the entire system will not work. It stands to reason that this work will be done by one group or company. So they can define whatever data format they want. Why XML? "XSLT transforms" is a lousy answer: transforms would be trivial to implement in a scriptable manner no matter what storage format is used to represent the AST.
And while providing debugging methods in a library is a fantastic idea, it really has nothing to do with XML at all. It would just be a hack on the ELF (or whatever) binary format which the compiler would be able to deal with.
The fact is, nothing in this article really gives a reason to use XML. Maybe it would be a nice interface between the editor and the compiler front-end, but beyond that there's really no reason at all....
Actually, I'll back up another step: if you've got an editor which stores class diagrams in its comments, that's one mother of an editor. It stands to reason it's an IDE which invokes the compiler for you automatically. Writing an object or two in the editor's code that translate its internal representation into C (or whatever) would be trivial compared to the rest of the IDE. So why bother even changing the compiler?
This article basically boils down to, "All IDEs suck. There ought to be a good one." Even using the GNU tools as they are today, a killer IDE could be written to implement all the features suggested. And XML wouldn't be needed at all.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
The language can be found in the bowels of Sun Identity Manager, formerly known as Waveset Lighthouse, and it's just as wacky as you would expect from an XML-based language. It's used for implementing workflows for the user provisioning and what have you not.
I thought this was a stupid idea, until XPRESS confirmed my beliefs.
For a very interesting, concise and powerful language, Rebol is hard to beat. ..... :-)
The whole package (including a GUI) in less than 500Kb.
Rebol, although free, isn't open-source, but there are two projects that attempt to imitate it. They are -
R-sharp ( http://sf.net/projects/r-sharp )
and Freebell
( http://sf.net/projects/freebell )
Although both projects seem to be dead, they both have code (Freebell's is in CVS, R-sharp can be downloaded straight off ).
I've used R-sharp and it's not bad at all
Have you tried writing or reading any code in any XML variant, for-example XSL?
:)
:)
It's all fine and dandy if you simply wanna move some subtrees around and select a few trees, but implement, lets say, a procedure to decide primality, and it will shortly dawn on you that the "domain-specific" languages for programming (C,C#,ML,python,ruby,...) are a lot nicer to work with than XML, which is basically just a way to write down trees of data, and a wierd one at that
While XML may be nice to parse, and certainly nicer that having a gazillion differently formatted data-transports, it certainly is very verbose, and a lot harder to read for humans that ad-hoc formatted text (yes, i write all my posts in "Plain Old Text", wonder why
Please, stop using XML for things where better, more readable solutions exist. If you MUST: write a program to transform your data (program) into XML, for later processing as XML
SLOGEN [ http://ungdomshus.nu : Sebastian cover music]
but all too often it is. Look at C#: its notion of "partial classes" exists for no reason other than to support Microsoft's code generating form painter.
Dependence on tools signals a weakness in the language. The solution is not to increase the accessibility of the language to the tools; this is addressing the symptoms rather than the cause. The proper solution is to identify weakness in the language that the tools are trying to fix and then invent language constructs to address those problems.
Oh, and make the constructs as general as possible to avoid undue pollution of the language. Compare the author's example, Java's ultra-specific @Remote, to Objective-C's notion of forwarding, which allows for transparent remoting without any code generation (and has plenty of other uses too!)
There is no need to use XML to be extensible. I'm working on research project that allows to do for languages that use normal syntax. For early released prototype see http://sourceforge.net/project/showfiles.php?group _id=11569&package_id=109063.
Dowload both files and run scripts in xj.ast\docs for demos of parser. Also there is some documentation that explains an idea.
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?
If those tools were so magical, why did the GCC team have to throw them out and write the code by hand to get a correct working C++ parser? Of the languages in common use, LISP is about the only one that can actually be parsed by BISON (= has an LALR(1) grammar).
I'd hate to try to write a quine in an XML programming language!
Wait, seriously. On page four, the author says:
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.
All these whines about obfuscation and "I don't want to write code in XML!!!!" are clouding the debate - "Will this make development of large software projects easier and more reliable?"
I saw another poster completely discounting OOP languages (specifically C++) because it caused a 100FPS slowdown (from ~600 to ~500) in his 9 cube shaded renderer, as if that were a typical large software development project (clue to the clueless: it's not). This person was marked up as Insightful!
Give me a break, people.
There are 11 types of people in the world: those who understand unary, and those who don't.
The process is called "programming." Duh. What you suggest is like mountain-climbing by adding rope. Miles and miles of rope. In a big pile. Up you go. Whee.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
I liked it when you mention that KWord uses XML inside a gz file. I hadn't known that and it may invalidate my claim that XML files are less efficient in storage than binary files. All the redundancy in XML should compress very well, and you may even be able to approach a maximum with arithmetic coding.
The only counter-argument I could make is that you are using CPU cycles to find the redundancy, rather than writing out a space-efficient file in one swoop. But that's not a good argument since CPU cycles are very cheap now a days! I guess the trade-off is between CPU cycles and the man hours required to implement and debug a space efficient format from scratch. Of course, the former is always best. Computers are meant to do grunt work.
So I see it now. If you just look at XML itself, it's not very efficient or particularly useful. But the idea is that the result of XML + gz *is* a very efficient binary file. I've never thought of it that way.
-- Marcio
that an XML parser is the only parser left? and that only XML can be structured?
what nonsense. the if statement is just as structured as the XML 'version', and parsers do exist and have existed for 40 years for representations other than XML you know. and still can be written very easily using one of the many 'compiler compilers' such as antlr, yacc and the like.
most IDE's, obviously have a very efficient parsers built in that enable them to reformat the code, interpret inline documentation (such as javadoc) etc. XML would not offer any new possibilities, it would not make it easier or faster.
But the grammars of these languages are virtually required by the complexity of expression they offer the user. The only way you're going to achieve a simple XML-based programming language that can be parsed by "just" a simple recursing XML parser (and I might remind you that XML parsing in itself isn't all that trivial, which is why we have support libraries just for that), is by designing a really horribly inexpressive language. If you bring back in the expressivity that coders want, you'll be adding superstructure to the XML which is beyond simple XML structure and beyond LALR as well.
Bottom line - switching an existing code language or something like it to an XML-based format is a matter of pointless, ugly, bloating search and replace. It doesn't accomplish anything in the machine sense or in the human sense, just wastes cycles.
11*43+456^2
Been there, done that. It's called smalltalk.
Yes, I know "X" stands for extensible and that many binary formats are not actually extensible. However, binary files can be extensible as well. TIFF for instance does a very good job of allowing extra blocks of data to be inserted into the stream without throwing off older decoders.
Anyhow, dvdeug made some very good points and I have conceded that XML can be an storage efficient format. That was the major drive of my original post, so I am no longer arguing against XML. See my reply here:
http://slashdot.org/comments.pl?sid=136513&cid=114 05771
So, I actually learned something from Slashdot today.
-- Marcio
Those extensible languages are called Lisp (and its family) :).
'A lie if repeated often enough, becomes the truth.' - Goebbels
I guess I would have liked to see something along those lines rather than XML. Perhaps an extensible binary format with a really good open source API for it.
"Wacky, but perhaps wacky enough to be possible?"
Should read:
"Retarded, and probably retarded enough to be unnecessary."
Lisp (+ scheme) and Tcl are also extremely flexible languages, where you can write new control structures in the language itself, or modify the meaning of existing functions/commands. Tcl isn't as flexible as Lisp (macros), but it's pretty good for a language that has made it to the mainstream. And it has a beautiful, fun, and well written C API that lets you do neat things at that level. It's got a scheduler, a filesystem, all kinds of neat stuff... it's nearly an OS;-)
http://www.welton.it/davidw/
So in other words the (programming) masses are scared of math, and logic?
"XML is dumbed down enough to appeal to the masses."
I should point out that the masses in question that'll end up using XML are programmers. Not Joe and Jane Friday in front of the Tivo.
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...):
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-based transforms. This applies to XML in general and it applies here. As you pointed out, the semantics of languages are different, and so your tools have to understand all the different languages anyway (or, as you say, reduce them all to some common denominator).
HAND.
I really can't understand this. How anyone with ANY kind of serious insight into the workings of computer science would come up with this is beyond me. It just proves the naivety and narrow mindedness of the author.
Extensible programming languages, then. Apparently it's no longer enough to be able to extend basic types, override functionality and reuse code. Now you have to be able to create completely new language functionality! Um, why?
By adding to the DTD/XMLSchema you are not 'extending the language'. Perl modules extend the language. C libraries extend the language. The do it by building new features from the building blocks provided.
Rather, you'd make the language proprietary. Forget the problems of the difference between g++/VC++/TurboC++ etc. Now you're into the realms of a different language per project. It's not enough just to read the (standardised) code and the way it works. Oh no, now you just have to learn all the language extensions as well. Welcome to the world where gnome-x++ is similar, but unlike, kde-x++ thanks to some muppet messing with the language constructs. Welcome to the world where you have to incorporate each projects language extensions to be able to build it.
I won't go into further reasons why using XML programming languages is a bad idea. I'll just leave you with this Dan Quayle quote:
"Verbosity leads to unclear, inarticulate things"
That about sums it up, I think.
Good post.
nt means no text.
Not meant to offend, just a joke (however, /. people could better check articles...).
This kind of calls can be done, since some years, with Web Services protocols (i.e., XML-RPC, SOAP, etc).
Look at W3C .
the D compiler support html embedded in code .. ..
;)
http://www.digitalmars.com/d/html.html
so this it isn't so strange to heard..
HTML is a sort of XML..
but this can help in write a editor with syntax highlighting..
and maybe to put down documentation in html
like JavaDoc
sorry for the english
GCS/T/O -d+ -p c++++(++) l+++ u++ e+ m+@ s+/+ n+(--) h* f++(+++) !g w(+) t r+(++) y?
Lisp Machine keyboards have dedicated parenthesis keys, and you don't need to hold down shift to type s-expressions, so you can hold a Hefty bag full of nitrous oxide with your other hand while you program in Lisp.
Indeed, programming languages could benefit from being extensible. Many concepts would be easier to program if domain-specific languages would be used. Check out this discussion for extending the open source Gold Parser program to support user-defined ASTs, intermediate languages and instruction sets.
Of course this poses the great danger of everyone using his/her own language to express the problem at hand, therefore making it very difficult to transmit ideas from one person to another in written or spoken way.
But the problem is not about the language we use to express our ideas. With little training, the average person can very well learn the syntactic details of a programming language like Java. The problem is our programs are filled with bugs, and they never work 100% correct, no matter what we do. And the problem lies into the fact that our tools are stupid. They can't find the bugs for us. Check out this stupid little C program:
It's obvious from the first look that this program will most probably crash.
The big question is:
Why we, humans, can find bugs, while the computer can not?
The (obvious to me) answer is:
We humans can find bugs that the compiler can not, because we know many more things than the compiler about the program that we can use as logical proof.
In the above example, I know that I should not call
before ! but the compiler does not know it, so it happily accepts the program as valid.In conclusion, programming languages should be extended with program state information. The program itself must make sure that certain pieces of code can be executed only under specific states; programming languages should provide the syntax for that. Then the compilers could extract logical information about the programs and refuse to accept the program if there is a logical error. Libraries should be accompanied with the state information. I call this type of programming state-based programming. Here is the example program annotated with state information:
Seriously:
It adds another layer of things that can fuck up. Even compilers do have some bugs. Why add another layer of things that can go wrong? Add "Check the WYSIWYG editor output" to your bug-hunting checklists.
It is incompatible with existing systems of merging/tracking changes. Try to do a diff/merge on XML files. Yuck. Ok, so we'll develop another WYSIWYG tool to present the differences/conflicts in a colourful graphical way.
The whole concept just takes the "Keep It Simple, Stupid" rule and sodomizes it. Ok, rules are not absolute, but what's the gain here? Ah, ok, we can sell the WYSIWYG editor to the masses. To quote the parent post: Give me a break, people.
I thought I remember reading that the VS .Net is now run by XML and is the reason why it doesn't really matter what programming language you use since it will get compiled to the same ADO.NET code.
So is it really news that XML will be the future?
http://winfx.msdn.microsoft.com/?//winfx.msdn.micr osoft.com/winfx/core/overviews/about%20xaml.aspx/
Large database systems can and have been written in forth.
q =a uthor%3Aerather%40forth.com+database&qt_s=Search+G roups
http://groups-beta.google.com/groups?hl=en&lr=&
Forth, being an extensible language by design is also one of the few truly verifiable languages from a point of view of trust.
Consider "Reflections on Trusting Ttust".
Because the forth core can bemade very tiney (even as little as 3 forth words - ok this makes an inefficent forth) the rest of the forth can be in ascii source form and compiled on-the-fly at bootup.
This makes it easy-ish to verify that the tiny binary core is safe and un-tampered with and the main ascii source easy to examine and diff for changes.
Try certifying that your C/C++ code based on generations of binary output from C compilers is safe.
Sam
blog.sam.liddicott.com
is like fashion. New exciting method/tool, and suddently we can fix all the problems we did not have with it. When you have only a hammer, everything looks like a nail.
In imaginary XML syntax for C++ such ambiguites will go for good.
If you are a java developer you will need to learn about generic programming and the java implementation of it. Unless you stick to java 1.4 forever. Maybe it's not everywhere just yet, but wait a bit and you'll see that generics are used everywhere, and you can try to avoid it but at some point you must learn at least how to work with generic classes. Even if you don't write them yourself.
It's the same with C++ templates... I thought they were implemented in such a horrible ugly way that i refused to use them, but all kinds of libraries started to use templates. Ugly ugly ugly, but no way to ignore them. This was one of the reasons for me to switch to java! And now generic programming has come to 'enhance' java programming too....
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.
Personally, I just flip the relevant switches on the front of my machine a few times. I guess it takes all sorts...
For the love of God, please learn to spell "ridiculous"!!!
I really hate that about the internet:
.cpp or .java, but why would you want to?
XML: data storage format for file formats that contain data
Program code: logic and conditions
Yes SVG can have logic, and yes XSLT is a logic language (with XPATH and stuff) written in XML.
But the problem is, XML is designed to be human READABLE (and independant in many ways because of its text structure) NOT intended (or designed!!) to be HUMAN WRITABLE.
Just because you can write SVG in xml, doesn't mean you should. Just because you could replace syntax optimised over 20 years for the depiction of logic, structure and behaviour, with the same essential thing but in XML, doesn't mean you SHOULD!!
You could make a middle ground XML structure that could XSS into
Java 1.4 has a lovely XML codec framework, places any class in memory into an xml state. Lovely thing for massing around with presentation frameworks.
XML, Blogging and a host of other buzzwords are so mistreated and misunderstood, there should be a society setup to protect them from maliscious developers who want to write stuff on thier blogs, because they are cool.
[ot]
Second of all, WTF is up with get fuzzy cartoon, why is that wuss dan carabarnaby... (get a real name, one that is easy to spell!) hidding his email address from his contact page?
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
Honestly, 99% of the time XML is used as a buzzword, nothing more. And in a lot of cases, like this one, it just means "we had no actually useful ideas, so we're gonna give you some fashionable snake oil instead. And we hope that your PHB is stupid enough to buy it based on buzzwords alone."
.class files (for Java).
/., take the two following representations:
Since we're talking programming languages, what's the big huge gigantic benefit of having the indentation and code handled through XSLT?
Any modern IDE does lexical and syntactic parsing on the fly. It doesn't need XML and XSLT for that.
E.g., I have Eclipse open right now. I can edit the indentation rules however I want to have them, and reformat. It didn't need some idiotic XML syntax for that. It doesn't need some stupid XML tags telling it "instruction starts here" and "instruction ends here": the language syntax already tells it that.
I can hear the over-used argument "but XML is a standard!" Well, C is an ISO standard too. "But XML has standard parsers!" YACC and LEX are even more standard nowadays.
Same for "extending" it. I don't need some idiotic XML file telling it the parameters to my methods, any modern IDE takes them directly from the headers (for C) or
I can just type "MyClass mc = new MyClass(); mc." and then hit CTRL+SPACE in Eclipse, and it will show me all the methods and public members I can use from an instance of that class. And the parameters and docs for those methods. Again, it didn't need some XML file for that: the standard language parser was enough.
And it seems to me like it's missing the whole point even of XML. The whole idea of XML (and SGML before it) was to have a humanly readable text format for data that was otherwise saved in proprietary binary files noone could read.
Well, program code was always text and humanly readable. So I'm at a loss as to what would XML bring.
To use the example in the text on
1. record
2. myMethod(record)
Seems to me like number 2, the traditional way is actually more humanly readable.
A polar bear is a cartesian bear after a coordinate transform.
I meant between these two:
v oke-expr>
1. <invoke-expr method="myMethod"><evaluate>record</evaluate></in
and the plain old
2. myMethod(record)
A polar bear is a cartesian bear after a coordinate transform.
C++ is horrendously hard to machine parse. GCC has just got a new parser to deal with the many problems the old one had. And C++ with errors in is even harder to parse.
A reasonable design goal for new languages should be to make it as easy as possible for the user to find errors and as hard as possible for those errors to appear in the first place.
The situation with C++ is not so bad; however, Java is designed to be so provincial, monolithic, and xenophobic that calling out to C code where performance matters usually makes the performance worse instead of better. Once anything is written in Java, it tends to suck in the rest of the program like a black hole.
duties that XML extensible stuff would come in handy - AIML processing for example, but on the other hand I'm nervous of the way XML is coming to dominate a lot of people's thinking especially when it seems to involve doing the same things differently.
Lightning Pool : Free online game
Suttree, a weblog about casual games development
Hi... Using XML in the IDE to display the code in a friendly way to each individual programmer is a great idea, but what happens when two seperate programmers try and debug the same code???
1. Programmer selects to compile the code
2. The IDE saves the file in a format that the compiler can read (presumably plain/flat text).
3. file is compiled and ready to run
4. program is run and it crashes with: "NullPointer Exception occured at line 120."
Now...
- James views his code with the '{' on the same line as the 'if' and Timmy views his code with the '{' on a sperate line.
- Both programmers are able to see the SAME code, however without knowing how the plain/flat test version of the file was compiled, how the hell are they expected to find the TRUE error line?
- Remember, when the file is saved the XML information will be removed so it can be compiled.
So, it looks like we will end up with a future of "meaningless" error messages again!?!?
Code generators will make most expensive programmers obsolete...
Funny, they said that about Fortran too!
He suggests a definition of a programming language (not a programming language?) in xml.
.emacs"
That is even dumber. Code would compile differently depending on how you specify the language.
That is so dumb, the whole point of a language is STANDARDS, XML is a standard, but that doesn't mean every XML document is a standard.
Making my own Java like compiler spec to give me my fav shortcut is akin to saying:
"yes, my program compiles, if you have my
public static void ignoreArticle(){
return sanity;
}
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
YES, LAMENESS FILTER, XML IS LAME, BUT HEY, THAT'S NO REASON NOT TO LET ME POST IT!
Ok, maybe that helps
(Probably linguists would tell me that my structure is completely off :-))
:-)) Flüssigkeiten sollen ja recht inkompressibel sein, vielleicht kann ja die Aufzählung von solchen hilfreich sein :-)
Oh, and the lameness filter told me:
Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.
Yes, the lameness filter got it exactly right: XML has just too much redundancy!
Indeed, I now got the same message a second time. Therefore I'll just add more junk in order to get this XML stuff through the filter. To avoid repetitions, the person that's me will use different words as much as possible (I am obviously not always able to not use the same term again, of course).
Ok, let's see if now the lameness filter is satisfied.
No, still not. So let me add some more stuff: fhjks hjfkdlgh dfhjklash fjklsd
10 20 42 0 8 1 6 7 5 1278
!"$%&/()=
I'll give you your red.un.dan.cy, you lame la.a.m.e.n.e.s.s fil.ter!
$ $$ $$$ $$$$
Ok, satisfied now?
Ah, still not. Then let's try some more text. To reduce redundancy, I'll now add some German.
Nun denn, dann wollen wir mal sehen, ob der Filter sich auf diese Weise beruhigen läßt. (Und für alle Korinthenkacker: Ja, das ist noch alte Rechtschreibung
Also: Wasser, Quecksilber, Ammoniak, Öl, Essig, Schwefelsäure
The Tao of math: The numbers you can count are not the real numbers.
I remember, over the course of time, my friends and I (all longterm crack contract programmers) looked over XML to check out the hype. EVERY one of us independently came away going 'What's the big deal?' It's useful for a) trading data between disparate systems or b) storing complex data in a text readable format (but at that point I usually stick it in a database anyway)
It's like the whole XML database idea. Excuse me? WHY would I want to have my database in text TO BEGIN WITH? So I can REALLY slow down my access? So some MORON opens it in an XML editor and tries to edit it? The reality (as usual) is that 80% of the people that cram in XML to their development never needed it. XML is so much freaking hype. It has VERY specific uses and it's not the global answer to ANYTHING.
Don't even get me STARTED on how people then proceed to incorretly format it (God, you guys should see the XML I get back from a certain credit card processor - I had to write a custom node scanner for it cause some idiot designed the nodes wrong) BTW, credit card processing is one place with XML makes a LOT of sense.
Another language paradigm....
OK guys, throw away all that ugly old (insert favorite language here) and (lets code it again in | lets make all our old code talk to ) (insert newest buzzword here). Now what do we make here again??
I think that using XML for programming would be a very good idea, but some redundancy might have to be removed to make writing easier. For example, since things like HTML 123 are no longer valid in XML, it is pointless to write which tag you close, since there is only one unambiguous tag you can close at any given point. So instead of 1 2 we might use 1 2 , or better yet, just >>. Now, that's a nice idea, but those angle brackets look strange, they are too wide and look like X's, so maybe let's just use the ordinary parentheses: (a (b (c 1) (d 2))). Now, that's more like it. Yes, I definitely like this new scheme much better. XML in programming is a great innovative idea, only its syntax needs some polishing.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
I think they should call it coldfusion
but look at the XML decorations in C# (for things like serialization), and look at Aspect Programming and you see ideas that are not "extensible" really, in so far as creating whole new functionality at the language level... but they do allow for a high degree of seperation of individual concerns of the code and the program itself.
This was posted back in May last year.
actually, this sounds a lot like the general practice of programming in pseudocode, and having (I guess) a translator turn it into the language of your choice...(why?)
I suppose the one major initial benefit would be to finally expose to most people that all languages essentially do the same thing. only the specific syntax is the difference. although in the interests of job security would we all want everyone to know that?
although a side effect might be to have languages start to look more like applescript...
personally, I think it would be kind of neat to have an editor that could, due to the formatting of the underlying code,) be much more clever about highlighting code blocks. and being able to view a representation of the program flow by backing out somewhat and seeing the whole program laid out graphically in front of you... wait, forget I said that, (does anyone know the number to the patent office?)
-- it's ridiculous how many people misspell ridiculous... (damn, damn, damn...)
Having said that, I *do* like the idea that no single piece of code in a high-level language (including c, as opposed to assembler) should be more than 1-2 pages long.
As for the "kludgy scripting" to group your files together, that's what #include, cat, and "make" are for :-) (BTW, I actually did this on one project where I used a flow-charting program to outline my code, then embed pseudo-code", then translate it into source code, just to see if it would work, but that was 10 years ago :-).
Lisp failed in the early eighties. That is twenty years ago. Things were different back then, and it is important not to learn the wrong lessons. Here are some of the reasons LISP failed.
Virtual Memory Mysticism Four megabytes was a lot of memory back then. The junor manager could be persuaded to sign off on the purchase of a workstation with that much, but the middle manager would cut it back to two megabytes and the senior manager would cut it back to one megabyte. The fancy Lisp application would have a working set of three megabytes, so the machine would page thrash and run like cold treacle. Eventually management would be pursuaded to buy another megabyte, but it would still be too slow. The basic problem was that people treated virtual memory as magic and were reluctant to accept that there were still hard limits on the ammount of physical memory required. VLSI killed bit slice Back then, everybody and their dog was starting new mini-computer companies, using 4 AMD 2901 four bit slices to make the ALU and a 2910 to sequence the micro-code. The big Lisp vendors had their own hardware. Symbolics had Lisp machines, Xerox had D-machines. As the decade wore on, technology progressed, and VLSI CPU's such as the 68020 and 80386 slaughted the LSI CPU's. DEC's VAX was the biggest losser, but the Lisp vendors suffered greviously from mis-reading the way the hardware market was going. Naive garbage collectors Garbage collectors are hard to write. In the 80's Lisp vendors were proud that their garbage collectors were free of bugs. Unfortunately the old mark and sweep collectors tended to walk swapped out data structures, thrashing the virtual memory system. Modern generational collectors are enormously better. Computer science was young Many programmers were self taught. (I read mathematics at University.) Others had studied computer science, but were learning from academics who were new to computing themselves and thought PASCAL was a good language.Why do you want access to the AST? The idea is that you can avoid manual maintainance of repetitous code and boiler plate code by automatically generating it. Well, it is a nice idea but it is also a sophisticated idea.
Some of the application is written in the base language. Some of the application is automatically generated. The generated code doesn't appear by magic. There have to be source files, in an application specific language. There have to be code generators, written in a meta language, that take the application specific language and expand it to the base language.
It is a huge win if the meta language is transforming AST's into AST's rather than transforming text files into text files. To obtain this benefit, the programmer must be thinking in terms of the abstract syntax, rather than the surface syntax.At this point it becomes natural to give up on surface syntax and program straight to the AST. It is also natural to insist that the base language is suitable for writing AST to AST transformers, so that a separate meta language is not required. This is what Lispniks are getting at when they say that Lisp is its own meta language.
This way of thinking about programming went right over the heads of most programmers in the 80s. I think that the most important reason why Lisp failed in the early eighties is that it was 20 years ahead of its time
Clearly, that invalidates your entire post.
Hey, I'm just your average shit and piss factory.
And now we are reinventing Forth and Lisp in XML!
Sure, it's 30/40 years later, and sure, it sucks lemons like nothing I have ever seen, but, hey, it's XML!
(8-DCS)
I began such a language (called Fog) a few months ago with a few goals in mind:
1. Easilly manipulatable by non-programming-aware applications (XML-based accomplishes this to an extent)
2. Extensible enough to handle future enhancements (based on the MOO programming language)
3. Designed for visual effects (the XML+MOO combo was to be embedded in its own stream in video files and interpreted on the fly to add special effects)
I haven't worked much on the project (IIRC, only a few statements are supported) since it is so large and only 3 or 4 people have shown interest in it, but if others are interested, we could possibly get something working in a few months...
Luke-Jr
Where did you study CS? ;-)
At my university (Germany) nobody forces you to build software out of Lego i.e. C/C++
Actually, you learn the theoretical background, more or less useful things, and if you code, it's done mostly in Java (not because it's so great, but because it's high-level). In fact, many people here graduate without writing a single line of C code. They never handled pointers in their whole studies. I myself code mostly in C++ (love-hate relationship), but that's only in my spare time.
shouldnt that be ?
Ever written a differential equation solver? In a symbolic language like Mathematica or MathCAD you have to provide the 'meat' of the routine yourself. When it doesn't work the way you expected, you only have one token that represents at (its simplest) set a multi-nested loops. Not easy to debug. Its soooo easy to create infinite loops with this stuff unless you restrict input to almost useless levels of output :(
- This and all my posts are public domain. I am a Physicist. I am not your Physicist. This is not Physically advice
But the grammars of these languages are virtually required by the complexity of expression they offer the user.
That's funny; Common Lisp has a virtually trivial grammar and an incrediably complex language. There is really no excuse for the C grammar, and the C++ grammar can't put all its blame on the C grammar. The only reason why they are hard to parse is because the creators didn't think about parsing it.
and I might remind you that XML parsing in itself isn't all that trivial, which is why we have support libraries just for that
It doesn't matter how simple XML parsing is, since we have support libraries for that. Note that most programs that deal with C code outside of compiling use adhoc measures; they never completely parse the code.
is by designing a really horribly inexpressive language.
Really. Can you show me any evidence that an LALR(1) language can't be every bit as expressive as C++? Common Lisp isn't generally considered horribly inexpressive, either.
That invalidates yours.
Signature.
Or you could combine the advantages of both LISP on top of Forth
Ok, so there are billions of markup languages around. However, I don't see anyone one of them implemented across most imbedded language libraries. The hype of XML has helped XML to infest itself into everything, and now I can parse any XML document using my favourite language with very little work.
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
XML is a data directory search path capacity. It allows you to write queries to "find" your data in an organised way, where the app determines the organisation. Try that in c++ across object hierarchies for example, and you`ll find yourself backpointing or giving up encapsulations in any stupid little object in order to be able to access stuff.
We`ve done 2 console games with the full data backend in XML. This has 2 big benefits: We can write the data for any platform, and we can make importers and exporters in any 3rd party or self written application that we use to build or tweak the games.
We`ve often heard our artists and programmers say (not least of all myself): "thank god this is readable, finding that data bug would have meant many debug and compile sessions otherwise to find it."
I know it`s `in` to diss on XML, but it is actually usefull, so take the pointless 'XML is dumb and structureless' rants somewhere else please.
With great power comes great electricity bills.
How incredibly naive... It's supposed to be an intermediary for different languages? If we pretend (in magical happy ideals land) that languages all have equivalent constructs (which they DON'T), it's still a horrible idea. This means people need to write new parsers for all these languages to convert to/from XML in some undoubtedly grotesquely complex XML based language. Yes, new parsers, because existing ones are made to translate to machine or some other non-equivalent code. It's far from a simple modification.
On to the equivalent constructs thing. What you are proposing is silly for this reason alone. In order to make code work, you need to take the incompatible construct and translate it into so much more complex combination of simple code chunks. Then, when you translate back to the original language again, it will show up as the complex code, not the original incompatible construct. The reason for this is the same reason that decompilers can't properly generate the original code. That's what this is--a combination of an "XML code generator" and a decompiler. Decompilers have failed miserably.
This is not to mention the fact that intermediate languages like Java byte code and MSIL have been worked on for a long time, and they still haven't got it right. XML is not going to magically fix JACK SHIT.
Lastly, people have been trying to come up with good refactoring software for decades and it's still sub-par. That's because, as I said, these people at BEST, have some exist open source compiler to start from, but even then it's a huge pain. Have you seen how grotesquely ugly gcc is? The most you can take from it are it's grammar files, everything else is incomprehensible junk unless you've spent quite a while studying gcc.
You'll note I referenced LISP in my original post, I'm not unfamiliar with it. LISP does lack some high level expressiveness, but just like any turing complete language, you can of course invent such expressiveness in your code at the cost of some more characters typed.
I think we have failed to agree on what "expressiveness" means. I meant expressive in the sense that more information can be conveyed with a minimal code size. By my definition as I was using it, assembler is the least expressive practical language, and some hypothetical 4GL would be the most expressive. C is considerably better than assembler, and C++ and Java fall somewhere in the middle of C and that theoretical peak.
So by that I'm saying that while you can express anything in LISP that you could express in any other language, LISP is not as "expressive" by virtue of the fact that not as many idioms are embedded into the language design.
And it wouldn't be that hard to write a C-parsing library like our XML-parsing libraries. Nobody has done it because there isn't a great need. When people write tools that need to parse C, they tend to just roll their own. Might not be a bad project for someone to start up a reusable C-parsing library.
11*43+456^2
LISP does lack some high level expressiveness, but just like any turing complete language, you can of course invent such expressiveness in your code at the cost of some more characters typed.
Why do you say it lacks some high level expressiveness? LISP macros can do things that C macros can't even start to do.
LISP is not as "expressive" by virtue of the fact that not as many idioms are embedded into the language design.
Common Lisp can format outputted numbers in Roman letters. However gratitious that feature may be, it leads me to wonder you mean by this statement. It's object-orientated (CLOS), it's functional which is something very, very hard to do in C, it's iterative, Common Lisp will practically walk the dog and feed the cat.
And it wouldn't be that hard to write a C-parsing library like our XML-parsing libraries.
Have you ever looked at the problem? Yes, it is a hard problem. You'd need two C parsing libraries, one for CPP and one for C itself. At which point, you'd actually need to understand C, because it's a context-sensitive grammar at points.
When people write tools that need to parse C, they tend to just roll their own.
Again, G++ rolled their own C++ parser. They had to spend several months rewriting it. Almost nobody has a full C parser; they have an ad-hoc thing that mostly does what they need.
Spitefulcrow, it sure looks like I was wrong about Iran. Sy Hersh has a remarkable track record.
It is cowardly, and a betrayal of whatever it means to be a Jew, to act as a white man
-James Baldwin