Slashdot Mirror
Extensible Programming for the 21st Century
Anonymous Cowardly Lion writes "An interesting article written by a professor at the University of Toronto argues that next-generation programming systems will combine compilers, linkers, debuggers, and that other tools will be plugin frameworks [mirror], rather than monolithic applications. Programmers will be able to extend the syntax of programming languages, and programs will be stored as XML documents so that programmers can represent and process data and meta-data uniformly. It's a very insightful and thought-provoking read. Is this going to be the next generation of extensible programming?"
This is incredibly stupid. How come XML helps in dealing with data and metadata? Metadata *is* data.
What we really want is an user-extensible type system, like the one proposed by Date and Darwen in _The Third Manifesto_ for relational database systems. Remember, types are domains plus operators.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Extensible, so that each programmer can use a whole heap of functional and syntatic elements that no other programmer has ever heard of...
XML, so stuff that doesn't need to be human-readable is human-readable, and the whole mess is a good six times larger than it needs to be...
Plugins, so that everything can be dependant upon proprietary, bulky, inefficient runtime engines...
I am all for progress, and not married to old-school solutions by any means. However, some things can sound good in theory without actually representing progress.
How humans can tell what will be in a few years if they can't tell what will be tomorrow?
I'd completely agree if the claim wasn't "that next-generation programming systems will combine compilers"... but "should combine...".
Right, the idea is nice. But where will the market go, how will big corporations guide the development, what will become the new fancy or if there will be a new development that will render XML completely obsolete and feeling ugly comparing to that "new thing" - we don't know.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Dude, I have enough trouble debugging my code without having my homemade, guaranteed to be buggy, optimizer introducing even more bugs...
/greger
A brief read of the article indicates that the author is trying to solve problems that don't exist, and as a result, is coming up with solutions that are worse than the supposed problems.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
I don't understand this fascination with XML. It's just a generic container for storing data - nothing more. OpenOffice uses it as the underlying format for storing documents, but that doesn't mean I have to deal with it when writing a document. It's transparent to the end user.
In the same way, , why should I have to deal with it when coding? It's sort of like requiring coders to be able to pop up a hex editor and cruise through the code.
Remember MVC (model-view-controller)? Being able to disassociate the different parts was considered a good thing. Swing decided it was too cumbersome, ASP.NET joins them at the hip, and now we've come all the around, with Microsoft proclaiming with XAML that everything should be dumped into one big XML box.
Bleah.
Good ideas, which are the correct choice for some problem domains (OOP is for instance often a good choice for GUI's , IMO). But they're not the best choice for everything
So this is Yet Another Buzzword. At least he didn't shorten it to XP. ;)
Sometimes XML is not the answer. That being said there are also so really great uses, but XML was not made for everything.
Having worked with both XML and Lisp, I'd say that Lisp is easier to read.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
...and by the 21st century, weren't we all supposed to have flying cars?
Personally, I'll take the flying cars...;)
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Now you can do this in C++, but look at what you need to implement to do it
It would be great, if instead, I could hook into the compiler and tell it exactly how it should handle vectors.
Umm... what makes you think that programming a compiler is going to be more straight forward than doing generic programming? That seems like a huge assumption to me.
The closest thing I've seen to what this article talks about was CLOS's MOP, which was great, but once again, a lot of people had a hard time groking it.
sigs are a waste of space
So this guy's familiar with UNIX, he's familiar with Lisp, yet he thinks the future is XML and hideous frameworks with ever-changing APIs? Not often you se e someone with a hammer AND a screwdriver using the hammer to pound screws.
Everybody's a libertarian 'till their neighbour's becomes a crack house.
I'd think most compilers will already expand it to that. I know Visual C++.NET does.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
We've seen what can happen to languages when countries get conquered. English is one of the best examples. Try to read some old English to see for yourself. With XPL (Extensible Programming Language), you cannot say anymore that I know C++, or I know C#. Someone will ask you to maintain some code, and you'll take a look at it and have no idea what is going on, until you learn the extensions. This will happen over and over again with every project you are supposed to maintain. This is BRAIN FRYING and huge possibilities for mistakes. It is just like waking up everyday and being asked to speak in another human language. Today English, tomorrow French, the day after tomorrow Bengali, can you do it?
Is it just me, or did this "visionary genius" just describe a Lisp Machine from 30 years ago? Man, if this is "progress", we're screwed.
> Programmers will be able to extend the syntax
:(
> of programming languages, and programs will be
> stored as XML documents so that programmers
> can represent and process data and meta-data
> uniformly.
Sounds like they've found a use for future eight trillion teraflop processors. Scripting on top of scripting on top of scripting.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
It's kind of funny when you think about it. Smalltalk and CLOS (and for that matter their predicessors) seem quite close to what he's describing (admittedly without the XML side of things). I guess it just follows the "those who ignore history are doomed to repeat it" mantra.
I'm not sure why he thinks it is important that the meta object protocol stuff be done in XML. I mean, why not just in the language itself? This has been shown to work with both of the above.
The problem he's not seeing of course, is that this approach essentially results in each project having it's own "language", which must be understood before one can participate in it.
sigs are a waste of space
but much of this 'vision' is implemented in Microsoft's .Net Framework and Visual Studio!
When they were building the tower of Babel, they all had the same language, after God smited them and brought down the tower, they lost that unified language
And the day came when the risk to remain closed in a bud, became more painful than the risk it took to blossom.
- Smalltalk did it before
- Smalltalk can do it easily
- Smalltalk can theoretically do it faster (ignoring the fact that every smalltalk on earch has been slower than Java 1.0 on a bad day (slightly exaggerated, I know)
Now, Java has proved that with some effort and lots of money, it's possible to make a VM thats as fast or faster than natively compiled code. Smalltalk only theorised about it.About the only language who can lay any claim whatsoever to the first two points, in pretty much any discussion, is Lisp. Smalltalk was an interesting experiment, but every single feature smalltalk touts as being great inventions has been around for ages in Lisp (with CLOS obviously).
> Editors like Emacs, Visual SlickEdit and even the
> loved/loathed MS Visual Studio have plug-in
> frameworks.
That's not the point; Eclipse makes Java code accessible to Plugins as ASW,
while Emacs & others only see it as a bunch of characters. This makes it possible to really manipulate *code* and not just text that happens to be code.
Advantages:
- immediate feedback of semantic errors (not
just syntactic ones)
- semantic highlighting (in Eclipse 3.0 M9)
- all Eclipse Plugins can access and manipulate
the AST instead of having to deal with strings
that make up the code;
...I'd say roughly 10% of you have actually read the article. He mentions specifically many of the criticisms you've mentioned. I don't think this is earth shattering, but some of the ideas are pretty good.
I for one like the idea of source code stored as XML, but not displayed or edited as XML. Imagine, viewing source code in the format you specify (eg positioning of braces). And it would be really nice to be able to treat source code as data without breaking your back writing a parser. And for those of you worried about bloat - honestly, we're talking about text files here!
It's bad enough tracking down the umpteen libraries that an open source program depends upon now. Now we have to track "Bob's special compiler" as well?
Besides, we already have compiler "plugins" for extending the syntax. They have names like bison and flex. Anyone can layer new functionality on a language through meta-translation, if there is a reason to do so. But you better have a reason!
Emacs sees lisp-like languages as more than just characters - when editing lisp in emacs, it's not "just text".
For something - retriveing stock qootes over the internet, I certainly can see its use. But when you're talking about company A's computer talking to company B's computer, maybe EDI is a better way to go, especially if company A or company B is still using dial-up lines (there are a lot of small companies out therer), considering the verbosity of XML and the efficiency of EDI.
why simple application software needs 2G of RAM and multi-GHz CPUs to get the responsiveness I got on a 100MHz 486 with Win3.11.
Engineering is the art of compromise.
What really got me is that they think merging the functionality of a compiler, linker, debugger, et al. via some sort of component framework is really anything new. Forth and Lisp were producing tightly-integrated development systems _thirty years ago_. Thank you, Mr. Moore and Mr. McCarthy.
Piling up all the closing parens makes the code *easier* to read, not harder. After you've been lisping for a few weeks, the parens just sorta disappear, and you rely on indentation to give you the overall structure of the current function, and then just add however many are left over at the end. Any good editor will let you know when you've put enough, and you can define a "fill out close parens to the top level" command in most.
Property law should use #'EQ, not #'EQUAL.
We have had these kinds of integrated, extensible systems: Smalltalk-80, Lisp, and others. And we have had the same tired, old arguments against UNIX since its original design (you can read up on them in the UNIX Hater's Handbook). Smalltalk-80 and Lisp didn't fail because there was some grand conspiracy against them, they failed because people voted with their feet.
Most real-world programmers apparently just want to put up a bunch of dialog boxes and windows, interact with the user a little, and interact with a database. They don't want to extend the programming tools or language or modify the optimizer, they want it to just do what they need it to do. And if it doesn't do what they need it to do, they just pick a different language and environment and don't go on a crusade to develop zillions of plug-ins and modifications. Programmers stick with text files not because they believe that they are the best representation, but because they actually work pretty much everywhere.
Some of the changes Wilson advocates are happening. That's not surprising, given that the features he advocates have been around for decades and many people are familiar with them. But they are happening in an incremental way and people pick and choose carefully which aspects of Lisp and Smalltalk-80 they like and which ones they don't. For example, you can get versions of GNU C that output interface definitions in XML format. IBM VisualAge maintains Java sources inside databases (not text files) and permits incremental recompilation. Many Java development environments have plug-in architectures. Many editors now permit structure-based editing operations ("refactoring") and display "styled" source code, using the raw ASCII text just as a formal (non-XML) representation of the program structure. Aspect-oriented programming adds a great deal of extensibility to languages like C++ and Java. On the other hand, general-purpose macros are out--language designers made deliberate decisions not to include them in Java, C#, and similar languages.
Altogether, it looks to me like Wilson is merely restating what is already happening and combining that with a good dose of UNIX hatred. If he would like the industry to move in a different direction, there is a simple way of doing that: he should implement what he thinks needs to be done. I think an XML-based programming language (and several have been proposed) has about as much chance at flying as a lead balloon, but, hey, surprise us.
A cynical take on this article would be that it's sour grapes by a stranded Lisp/Smalltalk guy who never got used to doing things The Unix Way, and still wants to lead the unwashed masses kicking and screaming to the promised land.
"PUT DOWN THE VIM! WE HAVE YOU SURROUNDED!"
All cynicism aside, this is a mixed back. Extensible syntax is a great idea; and yeah, Lisp already had it in the 50's. What needs to happen for broader adoption is to do it in a natural Algolish syntax, which basically means limiting functionality. Languages like Python and Ruby (with lambdas and blocks/procs) are starting to do it and I expect to see others follow.
The whole "seamless translation into XML and back into any language of your choice" is a lovely idea, but even small bugs in implementation would handicap its usefulness considerably. It'd also take a tool oodles more complicated than gcc, which he doesn't seem to like.
Finally, tight coupling of language and development environment can mean added productivity, but it also tends to mean less flexibility in practice: this is one of several reasons that Smalltalk hasn't caught on.
Google confirms: Ruby is the world's most beloved programm
The funny part is that eventhough in 99% of the cases XML is indeed transparent to the user it is still selected over binary formats (DER, TLV, whatever) because it's ASCII !
Having talked to religious XML zealots in a past, I gathered that they either were simply not aware of the alternatives or were 'afraid' of the binary formats due to the nature of their programming environments (VB & co). Duh.
3.243F6A8885A308D313
Sheesh! I can't believe nobody else saw the point of the gentleman's article. After all, it's not about improving efficiency of the programmer or the system. It's all about empowering authors to write more books about new programming languages that rely on Moore's Law to make them semi-viable (oh, and to draw in more royalties from the panoply of books about the new programming languages). It's sort of like the fad of patterns, eXtreme Programming, etc. Few places really use the principles promulgated in the all-too-many books on the subject and those that do eventually (d)evolve back into more conventional practices. Who benefits most? The authors do (not that I'm against authors making a buck).
You will still be using the same set of programming skills, no matter how the programs are represented and stored.
That's not how I read the article's proposal at all!
The code you've been asked to maintain is stored in some standard machine readable format. When you come in you then use the code-editor program to view it using -your- extensions, and the underlying primatives of the code objects are presented in the manner you're used to.
Whatever extensions and transformations the original author used to create the code would be relatively meaningless, which (for many of the reasons you descibe) is a good thing.
> Written naively the overloaded '+' operator returns a vector object. But I don't want any object returned. I want the code to be expanded in place as...
> It would be great, if instead, I could hook into the compiler and tell it exactly how it should handle vectors.
But what if your code was to run on a vector processor (or even SSE, etc)? Your telling the compiler how to handle vectors (serially, in your example) would limit your speed.
a better method would be to use declarative/ functional semantics to describe what you want, and then have a compiler that would optimize that to the architecture. many examples exist.
I believe a big problem of procedural languages is over specification of procedure (by definition...)
Synergies are basically awesome, and they're even better when you leverage them. -PA
...while the old-timers whine that we should all really be using Lisp.
That could be because Lisp provides most of the features outlined in the article, without the problems?
Microsoft is to software what Budweiser is to beer.
Even without bugs in the implementation, the XML format won't work to a general enough degree. Let's see... we already have a format which many programming languages translate to, and which can be translated back to a limited degree, and that's object code. Translating object code back to a programming language may work, sure, but it doesn't generate the same level of semantics which were there in the original.
Now translate the object code to XML. Is it any better? Probably not. It's now readable, but so is machine code, if you have the right program. And this guy is proposing to use a program which renders the XML in a familiar format anyway, which is really only one jump from using a program which renders the machine code in a familiar format.
Allowing multiple languages in the whole thing seems to naively ignore the fact that different languages have different features. What does the guy with his editor configured for Java, see when viewing a file that some C++ developer put operator overloading into?
The whole thing smacks of "if it starts with X, it must be good."
I say fuck it in the eye. We don't need source code which translates to other source code, we need source code which compiles to a module which can reliably use, and be reliably used by, modules written in any other language, and we need all these modules to be crashproof and crackproof when they run. They should save the research for the things which matter, and stop misusing XML. :-/
Karma: It's all a bunch of tree-huggin' hippy crap!
The ultimate expression of this was realized with the Symbolics LISP machine. Everything was in LISP. Everything was hackable. The MIT Space Cadet keyboard, with six shift keys (Shift, Ctrl, Meta, Super, Hyper, and Top). All 2^16 keycodes could be bound to any EMACS function.
I've used both. They sucked. Partly because they didn't work very well, but mostly because all that flexibilty and programmability had negative value. Language and UI design are hard. Evading the problem by making everything changeable does not fix the problem.
His point about XML being another way to put LISP S-expressions into textual form is well taken, though. They're both trees. The problem with LISP is that while the data structures are valuable, the programming notation really is a pain.
LISP works well as a web development environment. Viamall, which later became Yahoo Store, was written in LISP. That was one of the first web applications that really did something elaborate on the server. You could create web pages on the server from a web browser. And the overhead was lower than with XML, where you're forever re-parsing text strings into trees.
Hmm... I think this is almost what the CLR and .Net Framework allows (downloaded F#yet?), and if Sun wanted it to, the JVM could be used to do the same thing - one just has to write the compiler/interpreter spit out Java Bytecode into the JVM to run.
.Net code, so...
...but then there are Delphi, JBuilder, SharpDevelop, Eclipse, etc., IDEs HIGHLY dependent on their underlying languages, and all more or less successful (enough).
So the only thing missing then is the XML files that sort of allow this.
But, at this website C# to Delphi8 Converter, one can post C# code and it will spit out Delphi 8
tight coupling of language and development environment can mean added productivity, but it also tends to mean less flexibility in practice
From the article: "hat the programmer wants, she must"
"She" wants? Oh god gimme a break. Why can't these PC 60s hippies just get it into their head that most programmers are male and this spurious use of the female personal pronoun (in the hope of what, securing some sort of equal rights in IT?) is really bloody annoying. If someone was writing about midwives or nurses would they use "he" all the time? No. Such Mr Bearby Right-on Relic, how about you drop the politicall correct rhetoric and just concentrate on your work??
Yeah i'll get modded as a troll , whatever.
This so much reminds me of the LISP machine. How many times are they going to reinvent it?
It's such a pity that the code for the LISP machine is guarded by intellectual property protections that even the copyright holder doesn't know its way about.
Please correct me if I got my facts wrong.
compilers, linkers, debuggers, and other tools will be plugin frameworks, rather than monolithic applications
Uh? My compiler acts as a "plugin" via. make, which is called from emacs. If I want another compiler, I tell make, and voila' it's "plugged in". Welcome to the world of 'NIX Mr. Wilson.
What is worse, every tool's command-line mini-language is different from every other's
But this is their strength! Different tools solve different problems - and they use different languages to describe what they do, because they are *fundamentally* different (awk is not sed is not grep is not ls). How would you possibly write up a single language to describe what both sed and awk does, without poorly re-creating perl?
Attempts to stick to simple on-or-off options lead to monsters like gcc, which now has so many flags that programmers are using genetic algorithms to explore them
Most CS majors will know that modern CPU architectures are complex beasts, and that it is pretty hard to come up with which combination of optimization methods will yield the best performance on some particular revision of some particular CPU on some particular hardware configuration. Nothing mysterious about that. I completely fail to see what that has to do with command line options.
And instead of squeezing their intentions through the narrow filter of command-line mini-languages, programmers can specify their desires using loops, conditionals, method calls, and all the other features of familiar languages
Instead of squeezing my intentions thru the narrow filter of command-line mini-languages, I can specify my desires using what a standard shell (like bash) has to offer. Ladies and gentlemen of the jury, this is not making sense!
The result is that today's Windows developers can write programs in Visual Basic, C++, or Python that use Visual Studio to compile and run a program, Excel to analyze its performance, and Word to check the spelling of the final report.
Oh come on, please... So if I develop on windows, I can use VB, C++ and Python. How is this relevant? There are more useful languages available on the dreaded "command line systems" ('NIX), but let's just agree that there are plenty of languages available on most OS'es out there - regardless of the windowiness or commandlineness of the system.
Using VS to compile and run the application? Well, if your command line absolutely sucks, they I can imagine why you would want to launch your app from your editor - a matter of taste too maybe. But relevant? How?
Somehow I need COM in order to put numbers into Excel? Ever heard of CSV? You know, new-line terminated lines of T-E-X-T which can be processed by these little all-different tools, like, for example, Excel.
The part about Word and spell-checking of a final report... What? What's your point? If I use COM for developing software, I can spell-check in Word? If I use a command line, I cannot spell check a report that I write about it in Word?
A similar API allows the popular memory-checking tool Purify to be used in place of Visual Studio's own debugger, and so on.
Absolutely! Plusings make perfect sense certain places. Dude - GUD is written in Emacs LISP, it's a plugin for GDB. You could write an elisp file for Purify as well - in fact, Intel actually ships an elisp file for their debugger, even on Windows... Plugins make sense some places, other places they don't. Which, lo and behold, is why they are used certain places and not others.
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. Compilers and linkers are still monolithic command-line applications: files go in, files come out
Why does he not see what he's writing?!? A compiler reads a number of input files and generate an output file - this is a perfect match for a command-line too
Unix only provides text streams, that's not a good enough base for "plugin frameworks" and integration outside of the shell. You also need protocols, types, conventions, interfaces and so on = some structure (that XML can indeed provide).
This is not the golden, unifying solution or anything, but there's some ideas in there that could be useful.
I saw his thougts in the first section of the paper and took the rest as some quick examples on how it might look.
I can think of plenty of directions this could go. The first thing I got out of it is applying the same level of abstraction we try to implement in programs to the act of programming itself. This is happening in all kinds of areas of computers anyway (like abstracting file systems, GUI's, etc.) why not put programming into the mix?
It's not about using scripting instead of programming languages, it sounded more like building the same features into our programming tools as we build into the apps we write with 'em.
why all the negative reactions? If its about loosing your editor to write code, you didn't read the article. If it's about too much abtraction to program, then it seems kinda hypocritical considering all the frameworks we use for other people's tools. Or is it just irritation about having to relearn a bit and keep on coding as before? The complaints about XML are odd too. He choose a machine-parseable, human-readable widely used format as a possible way to store programs at a low level.
AB HOC POSSUM VIDERE DOMUM TUUM
A lot of people today still see OOP is a fad that will pass. On the otherhand, there has always been resistance to new programming paradigms. The early machine-code programmers resisted FORTRAN. The FORTRAN programmers resisted the Algol-like languages. People (including myself) are still not sure about the tradeoffs of OOP. If this is the next big thing, it is really no suprise that the majority of people here seem to oppose it.
Not everything is analogous to cars. Car analogies rarely work.