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?"
The document is mirrored here to help compensate for the bandwidth deluge.
When life gives you lemons, you CLONE those lemons, and make SUPER-LEMONS. -- Dr. Cinnamon Scudworth, Ph.D
Forbidden You don't have permission to access /~gvwilson/xmlprog.html on this server.
... will obviously be "forbidden." Yes, I did RTFA.
No.
I think someone forgot to get their permission to link to their site from Slashdot.
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
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
programs will be stored ... so that programmers can represent and process data and meta-data uniformly.
Yup. Back in the day, we called this "Lisp". It was about as readable as XML, but a hella lot more fun.
XML for everything? Sure! All you need is a super-duper Athlon64 5.0ghz to process all the overhead and we can have a very descriptive, very rich programming language with little regard for efficiency.
I don't mean to be a troll, but you have to sacrifice speed and size to allow for this type of flexibility. We're already seeing this with Microsoft's upcoming GUI wrapper Avalon.
no.
looks like they are blocking the slashdot referer. I wonder why they would want to do that.
A good example is code like this in C++
.
Vector a,b,c;
. .
c = a+2*b;
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
c[0] = a[0]+2*b[0]
c[1] = a[1]+2*b[1]
c[2] = a[2]+2*b[2]
Now you can do this in C++, but look at what you need to implement to do it. The code is a hideous nightmare of template metaprogramming. Of course you can do it in a language like C, but then you lose the ability to express yourself cleanly through code like 'c=a+2*b'.
It would be great, if instead, I could hook into the compiler and tell it exactly how it should handle vectors.
Of course you'd clearly need to document your code well as people reading your code would also be forced to understand the plugins.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
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.
no
XML? Bah. Next generation languages will be written in "WIMNNWIS" (What I mean not necessarily what I say) and will run on processors liberally sprinkled with pixie dust.
taken! (by Davidleeroth) Thanks Bingo Foo!
And suddenly he's propheysing the future?
Editors like Emacs, Visual SlickEdit and even the loved/loathed MS Visual Studio have plug-in frameworks.
As for XML being the "glue" for holding things together... No. It'll be a data neutral "modulator" you emit your data from your program by name in a particular format. Transmitting and receipt by the other programs will be handled by a remodulator. In between it might be XML, it might be binary, it might be whatever you feel like using that day.
(and no I haven't read the artile (FORBIDDEN)
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
Instead of treating each new idea as a special case, they allow programmers to say what they want to, when they want to, as they want to.
Is this not the Ultimate goal of programming? The Holy Grail of programming perhaps?
I have a theory that the truth is never told during the nine-to-five hours. -- Hunter S. Thompson
Dude, I have enough trouble debugging my code without having my homemade, guaranteed to be buggy, optimizer introducing even more bugs...
/greger
So here I am, coding away merrily, when I run into a *STICKY* problem.
I'm running applications as user X, and need to access data as user Y. I have all the routines and everything written (in PHP) to access the data, but I need to do this as user Y, while accessing the data as user X.
There's just no easy way to do this. You have to use some kind of glue (such as XML), along with parsers, socket connections, pipes, shared memory, and all that jazz just to be able to access data remotely.
Ouch.
What I'd like to see is the concept of a "remote object". Imagine standard OOP, except that a particular object doesn't have to exist in the same memory/process space as the parent.
For example, instantiate an object on a remote server, or as another user on the same server, or at least in a different memory space as the same user & server.
The biggest problem with XML is that it's heavy, very heavy, and requires specialized scripting in order to work.
If you have an class already written that does what you need, you should be able to simply instantiate that object in the context you need it to run in, and then begin using it, COM style.
Obviously, some calls (such as GLOBAL) would be affected or even disabled with such functionality - but can you imagine the benefits?
Ah well. That world doesn't exist, yet.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
Until we have a major change in teh hardware elements programming lanuages will become more of the same with some refinements not to the languages but to the object models and header files that are associated with them.
The MyTh - I am a figment of the Imagination - [Im Probably even not here]
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. ;)
The result will be systems that are simultaneously more sophisticated and easier to understand.
Is this really...Truly possible?
I have a theory that the truth is never told during the nine-to-five hours. -- Hunter S. Thompson
Sometimes XML is not the answer. That being said there are also so really great uses, but XML was not made for everything.
... the tower of Babel fell !
:)
aka, lack of a unified language
We learn from history that we learn nothing from history - Tom Veneziano
This is not the next generation of programming systems but rather the present one for pretty much everyone except for those using Microsoft tools.
Again, nothing new.
There is no way in hell that would ever happen. Ever.
No.
Now, I will read the entire article, but somehow, I am not holding my breath...
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
I second that.
Need some of those too...
When life gives you lemons, you CLONE those lemons, and make SUPER-LEMONS. -- Dr. Cinnamon Scudworth, Ph.D
...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!
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.
Now the developers of tomorrow have a heads up on the next big, stupid programming idiom to make their lives miserable.
that next-generation programming systems will combine compilers, linkers, debuggers, and that other tools will be plugin frameworks, rather than monolithic applications.
yup, it already happened. more than 10 years ago. it's called Rule of modularity and Rule of Composition. In case you don't know. It's the Basics of the Unix Philosophy
#
#\ @ ? Colonize Mars
#
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?
People see this as bloat, but it's always been an issue. As computers get faster, we can remove ourselves from the nitty gritty of computer programming and back to computer science. Sixty years ago computer scientists probabably would have thought the same thing about the most efficient methods we make applications today. "IDE? What the hell is that for? Use punch cards!" My point is that as cpu and memory increase in speed and size, we take advantage of that in ways other than making the final result run faster. In twenty years, this idea will probably seem something like "wait, they used to type the source code?" I think this is just evolution of computer science.
If I recall correctly,
Fourth-Generation languages was going to be the future of programming back in the early 80's?
(Machine code, Fortran/Basic-type languages and Pascal/C-type languages being the supposed first, second and third generations, IIRC)
Then in the early 90's.. OOP was going to save the world. Not that it hasn't had impact, but it certainly hasn't fundamentally changed things.
And now it's XML that's going to save the programmers, while the old-timers whine that we should all really be using Lisp.
Not that I'm a computer-language conservative myself, but it's worth pointing out that historically, there has been quite a big discrepancy between which languages the Comp-Sci researchers feel everyone should be using, and the ones which actually are used.
that next-generation programming systems will combine compilers, linkers, debuggers,
...THINK Pascal (for the Mac) was doing this almost 20 years ago: the editor served as the front end to the compiler --- so the syntax highlighting in the THINK Pascal editor was driven by the lexer (really was the lexer): you knew about syntax errors immediately. The debugger was fully integrated into the environment. It was really sweet, and probably one of the best programming environments ever written.
and that other tools will be plugin frameworks
Like Unix pipes and Eclipse?
Tomorrow arrived yesterday and appears today.
eXtensible Programming sounds too much like eXtreme Programming.
Maybe they can call it Extensible Fox?
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.
The arguments being posted here are exactly the same that would've been posted about arguments against XML replacing EDI.
An EDI message looks like garbage:
ILD=1+0+0+1222+3+0+0+S+17500'STL=1+1+S+ASSOR. NP11+?'EXT?''
and people said "XML will never replace it because no-one's meant to read this stuff and the resulting files will be huge."
XML is replacing EDI already. The EDI networks didn't see it coming, mostly because they tried to use XML as an excuse to hike their kilocharacter transfer charges. Doh.
Now you can see XML already replacing RPC with web services. You might knock it but it's being used right now every time you get a stock market quote. The SOAP wrapper allows remote methods using XML already. a C# client accessing a Perl Server app over the web. Nothing new there, so why are folks here denying it exists?
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
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!
So basically, we get to combine the speed of Java/.NET with the user friendliness of XML and the security of COM? May god have mercy on our souls...
Adrian
Basically, you're saying that next genration programming languages will all be Java with RMI and Jini.
.Net. This is nothing new, it's been around for years. I suggest you look into it ( especially if you're using *ugh* PHP for anything; been there done that too, trust me, ditch it while you still have time to go with another framework ).
Decent remoting is already built into many development frameworks, including Java and
As Slashdoters we should be the ones who know about and utilize the tools of the trade freecache being one of them,
thanks to the good work by the Internet Archive there is no reason to link directly to a source (and thus bring it to its knees) ever again.
come on guys get with the friggen program
XML is not the solution to everything. Next english is replaces with an XML based language.
SeeSpotrun
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Java supports all this in a very rich manner today, with a lot of security related things around this (so for instance you could have an SSL protected RMI connection, and authenticate as a different user on the remote end to run the calls as some other user).
.Net not all the same support is baked in - one interesting aspect is that if you want to do SSL at all, you have to have IIS installed on the computer running the .Net code.
With
"There is more worth loving than we have strength to love." - Brian Jay Stanley
- 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).
That means we have no one on staff who has a chance to learn this new technology. So, I guess we're stuck outsourcing our technical needs forever...
Pick one. There is a PHP interface to SOAP.
o ap/
Personally I like ZOPE, but the python 'php' package is not even in alpha.
here is the link for PHP SOAP:
http://phpsoaptoolkit.sourceforge.net/phps
...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!
Programmers will be able to extend the syntax of programming languages
Seems to me that Lisp has had this ability for 40, almost 50 years now.
Everything old is new again
Any language with a top level loop (type, debug, execute code interactively) already has the integration thing down. Languages like LISP and scheme and ocaml already have macro systems.
And by macro systems I don't mean the C like things, I mean the ability to treat code as data and process it like any other data. Wonderful, but rather an old idea.
Gawd, here we go again. I think someone needs to make a new version of Greenspun's Tenth Rule of Programming (all complex system eventually approach an imperfect LISP runtime), something like "all programming languages and environments eventually look like sloppy LISP".
combine compilers, linkers, debuggers
Yup, LISP usually involves an integrated environment for editing, debugging, execution, compiling. But since it's all LISP, it can all be extended, swapped, or componentized at will.
Programmers will be able to extend the syntax of programming languages
Wow, what a *concept*. Not only is this easy in LISP, it's easy in a lot of dynamic languages. In Ruby for instance, you can use blocks to factor out common code sequences, example:
Before:
After:
You LISP hackers are laughing of course, this level of refactoring and more is common with macros. Those of you who don't practice "extreme refactoring" probably don't see the difference.
programs will be stored as XML documents
Uhm, if you treat XML tags as "named parentheses" you have S-expressions (LISP again). XML and S-expressions map onto each other completely. But S-expressions are a lot simpler to program with, so you might as well use them. Sure, they aren't as hip as XML or optimal for document storage, but they are better suited to programming.
programmers can represent and process data and meta-data uniformly
LISP treats everything as list, if you want.
I'm no "smug lisp weenie". I have never used LISP for production code. I use usually use Ruby and Perl. But it's a trade-off, Ruby has better libraries and a single implementation. Lisp has more raw power but isn't as practical.
The point I'm trying to make is that what the author describes ALREADY EXISTS. But I guess it's "cooler" to invent something new than to just perfect something that already exists.
Could somebody please come up with a LISP that has modern stuff like threads, CGI, and process control and is optimized for Unix-like systems, and please get a uniform version pre-installed on Linux and Mac systems so all the LISP folks could finally get some cred?
From the article:
Editor MACroS? My favorite editor is vi, you insensitive clod!
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
perl6
I know Bengali, French AND English!
as in shared virtual memory. Big problem is locking and the memory coherency that implies.
It is usually to refer to a neuter member of the human race as masculine (man,he etc..) and a neuter object as feminine (her,she etc...)
sine the author was intent in using the feminine for the programmer I would assume that the programmer was non-human, a machine.
thank God the internet isn't a human right.
This is the 3,967th language proposal I've seen recently. (Okay, almost that.)
I suggest that C++ and Java be finished before working on any more languages. All my life I have been working with unfinished programming tools.
Having a well-defined syntax is a good thing. Plus, if the syntax is extensible, you can't write a general parser for the language, which makes it harder to write compilers and other sorts of source-processing tools.
Didn't see that one coming.
Hmmm... Parent has a point...
In my opinion the author tries to do too much. By doing so it is almost difficult to form an opinion on or start a discussion about the article.
As for using XML as source code, I hope the author is kidding. If you use PHP or JSP code in (x)html, you should always keep most functionality outside the page (in separate objects) unless it is directly related to the representation of the page. Otherwise the source will become unreadable very quickly.
Obviously XML can be used to transport the parse tree from one tool to the other. Various proposals have been made to do this already. Using a well defined, easy to handle (and verify) data tranport can really help here. This is really usefull, but has little to do with the representation of a language itself.
I think the a big change will be the use of source code alltogether. A parse tree is actually all that is really needed. This will be edited with a (graphical) editor and accompanying GUI tools (eg Agile code development and GUI design tools). This parse tree will be coded to intermediate language and then translated - at some point - to machine language. These last two steps are already happening obviously.
Now for the graphical representation; leave out those silly restrictions of where to put braces, line delimiters etc. The program shall be shown according to the defaults of the company (overruled by the defaults of the department and then the developer). There is nothing against using graphical editors for literals (a 2x2 table that can be edited as a table e.g.) or comments etc. Evenly spaced ascii has had its 50 years of glory, and I whish it goodbye.
To have all these features the language should be easy to parse however. Putting in macro definitions is stupid, as is putting in operator overloading. They make the language complex to use for both humans and parsers. Templates as used in Eclipse are much more well behaved. Code asists can take case for a lot as well. Emacs etc. have features for those as well, but they have no knowledge about what the code means, making it way more difficult to do things right.
I have the feeling I am still missing some important points, but this terminal like screen is running out of whitespace. I would strongly suggest for everybody to look at Eclipse.org to see what modularization/plugins can do to an IDE. It's free, very easy to install (unix & windows) and will give you an insight in what tomorrow (today) will hold. Even if you don't use Java.
One of the footnotes had the best idea I've seen yet- diagrams in source code. Perhaps this could be accomplished by allowing HTML hot links in comments? Or better yet, IMG tags?
.NET languages would be HUGE.
Still, the body of the article, the idea of creating new syntax on the fly, is very powerfull. I'm used to it in Scheme, to have it in VB or other
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
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 maybe a few people have missed is that there will be some incredibly interesting "hardware" out there in the future.
Some people have already demonstrated things like using DNA computers to solve travelling salesman problems, Quantum Computing and Grid Computers.
Perhaps what this article is suggesting is one way for developers of entirely new "hardware" to easily supply operators and types (syntax) to any programming language.
It would be interesting to be able to write program a that talked directly to the nervous system using fairly standard <your language of choice> syntax, that when compiled produced a real piece of nano "machinery".
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.
but much of this 'vision' is also implemented elsewhere, and was implemented elsewhere long before there -was- a Microsoft .Net Framework, and Visual Studio!
Nice try, though.
It's kind of like that.
I also want to do the XML data bases / meta data storage for the source.
Cool this really validates a lot of my views.
You must be new here...
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
XML may very well be a nice way to lay out data so that it can easily be gobbled up by other systems, if there is such a need, but as for using it as the holy grail of file formats for every thing? I don't think so!
.NET wasn't bad and bloated enough, now they're forcing this XAML crap down everyone's throats? At best, I see XML as a decent replacement for .ini or .csv files - zip! That's it!
Microsoft's plans for XAML really make me feel sick! As if
Let's not create a mountain out of a mole hill by turning everything into XML!
Ever tried storing an ampersand in an XML file???? Do you want to have to type escape sequences as part of your everyday life from now on? I know I DON'T!!!!
How about developing Maintainable programming?
That's exactly one of the author's points! You shouldn't (and in his vision won't) have to deal with the XML directly, -unless- you are one of the people actually writing new plugins rather than just using them.
His suggestion is primarily that we start using editors that transparently present the 'code file' in our choice of format rather than forcing us to edit it byte-by-byte. It's like the syntax-highlighting you probably use now, only effecting more than just colors.
Using XML for the underlying syntax is mostly irrelevant to his proposal, but he suggests it merely because it is currently popular, well suppoerted, and well suited to it's primary job of presenting data in an easily MACHINE READABLE format.
His proposal is, in fact, exactly the opposite of requiring coders to pop open a hex editor, and he likens our current ASCII-only coding methods to doing exactly that at one point.
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.
Programmers cannot invoke parsers, analyzers, or code generators selectively, or insert custom modules to change how programs are processed
He should try looking at Python. From the Python docs:
- imp -- Access the import internals
- codeop -- Compile Python code
As for extensibility, if a Python class T has the internal function for add defined then you can take two objects t1 and t2 of class T and write t1 + t2 and the compiler will generate the code for it.This module provides an interface to the mechanisms used to implement the import statement.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
And also here.
Well... You are technically correct. I am only wondering whether talking about "syntax" in the context of Lisp isn't a little exaggeration. The true power of Lisp seems to be the apparent lack of syntax as we usually understand it and writing parsed trees by hand, to make writing bad code impossible.
I agree. What people forget is that you can not win against entropy. By redefining problem in a different way you are not necessarily solving it.
Very true. Let us not forget the Conservation of Cruft Principle.
I don't think we've met.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Does that mean we'll all be using Perl6?
[It does appear to be one of the few languages being developed with a strong DWIM focus...]
- Low level developers. People programming in C; the ones writing Linux and KDE.
- Quasi-low level developers. People programming in Java; the one writing much of the business software right now.
- High level developers. People programming in scripting languages, like Ruby, Python, PHP, JSP, Javascript.
The second group is the most visible, because business loves them. The first group is the second most visible, because -- while it isn't as "hot" a technology in Monster -- most of the software we use is written at this level. I suspect that the third group is the one that will goose the business community in the future, and will probably eclipse the second group. I'd guess that this is a submarine technology; you don't see many job postings for Ruby programmers, but a heck of a lot of software is being written in it. Even more is being written in PHP, JSP, and Python.I imagine something like Python or Ruby, or some other high-level language that's easy to write software with, coupled with a decent compiler will be the real winner in the near future. Get some type inferrence for one of these languages, and the ability to compile it (as with Parrot), and group two will mostly go away. Java claims to be a more productive language than C because of higher level features; modern scripting languages are even better at increasing productivity, and their only real limitation is their speed, or lack of it. Just as Java eventually overcame the speed issue, so, too, do I expect some future version of a scripting language.
But, maybe Java will hang in there. If you look at Java 1.5, you see a lot of increased syntactic sugar that has usually been only available in languages like Ruby -- I've heard that this was motivated by similar constructions in C#. Perhaps Java or C# will evolve enough syntactic sugar that hacking out code will be as easy as doing so in Ruby. IMO, it'll take a more radical language change than that provided by 1.5; my biggest complaint about Java these days is that it gets in your way; a large chunk of the code you write for any application is infrastructure, and you write it over, and over, and over (anybody else sick of ActionListeners yet?). I'd like to see the typing system changed to type inferrence... but it is possible.
I doubt, however, that software development is going to evolve into choosing black boxes from a set of tools and plugging them into each other, mostly because to do cover all possible jobs, the framework would have to have access to a huge amount of fine-grained tools, and by that point, you might as well just write the code yourself. Look at the size of the Java APIs. How many packages are there? How many classes? How many methods? This is making our lives, as programmers, easier... how?
* compilers, linkers, debuggers, and other tools will be plugin frameworks, rather than monolithic applications;
For example, see the .Net Microsoft.CSharp Namespace, the System.Codedom namespace to represent code as objects, etc. in the framework class library.
* programmers will be able to extend the syntax of programming languages; and
don't know about extension of languages yet, but the next one is interesting ....
* programs will be stored as XML documents, so that programmers can represent and process data and meta-data uniformly.
take a look at Microsoft's XAML technology -- describing code by using XML. That's the general direction.
I'm sure other technology frameworks have similar things, but I'm not as familiar with those technologies.
S-expression is a natural way to represent programs in languages like Lisp and Scheme due to the very nature of their syntaxen or the lack thereof. Writing Lisp code is basically writing S-expressions in the first place. XML is a bastardized S-expression with some additional redundancy, so unsurprisingly enough Lisp programs could be stored as XML without any problems, even with also without any reason. Good luck storing a Perl 6 program as XML, though, in any useful way. Keep in mind that for it to be useful it would have to expose the original source code every time I want to edit it or otherwise it is completely useless, and now it has to have some additional advantages over simply storing the source code in a text file.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Yes, there is a God.
I18N == Intergalacticization
Metrowerks Codewarrior is an IDE (and I believe has a commandline tool for processing the project file ala Make) that uses plugin based preprocessors, compilers, prelinkers, linkers, postlinkers, and other tools, which the master project controls execution of (and through a nice GUI, allows easy association of file extensions with their tools and build information). It's been doing this since at least '97.
Hunt your preferred prey at Aliens vs Predator MUD. Join the war at avpmud.com port 4000
Smalltalk is already everything this guy thinks needs to be invented. It's extensible, flexible - and at least in VisualWorks, the sources are, in fact, stored in XML.
Talk Small and Carry a Big Class Library
Why not just use Lisp?
...richie - It is a good day to code.
Where Wilson goes wrong is in assuming that this kind of environment will be built based on plug-ins. The interrelationships needed between the components to get the required level of functionality are too great. What many people have already noted is that the current Unix environment is in fact based on plug-in development. Editors, debuggers and compilers are modularized as programs, with clean lines of communication between them in the forms of files and streams (which Unix again abstracts to one concept). The limitation of this system lies in the fact that the modules all use their own separate address spaces, and hence each one has to have a private representation of the program. This can't be mitigated by having the separate tools communicate to a central database (this is the most that Wilson's proposal of using XML as the underlying format can accomplish), because then the method of communication would be the limiting factor. Of course, you can use the neutral code-data representation to make the communications between the modules and the database be in terms of sending closures (from reading the paper, I don't think Wilson even considers this), but then you've just designed a single distributed address space, and in the process removed all the encapsulation and modularity advantages of the communication links (not to mention introducing a whole slew of concurrency issues)!
One such integrated system has been built in the past, called Interlisp. Barstow, Shrobe, and Sandewall's book (mentioned above) has a few papers that describe the system, but briefly a few lessons can be distilled from it. First of all, the system itself was an integrated development environment for a dialect of Lisp, where everything was done in one in-core address space: source code (including comments) was represented by data structures in memory, upon which the structure editor (residing in the same address space) operated directly. Code could either be interpreted from the data structure or compiled by the (yes, in-core) compiler. There were several extended packages (besides a Lisp macro-like facility), notably the structure editor and "Conversational LISP," a pseudo-natural language command-prompt parsing system. Although source code (and data) could be serialized to files (there was a sophisticated change-tracking facility that took care of this), the usual way of working was by saving the core image to disk and loading it next session, so the whole environment was persistent. There were hooks for everything from the parser to the compiler to error handling down to the most basic frame-handling code of the stack-based VM, and in order to implement the facilities mentioned above (and some other ones I left out, like the ever-present DWIM automatic error-correction facility) the code took full advantage of them. This caused some trouble when it came to portability of the components and the Interlisp itself (the heavy interdependence caused many problems in bootstrapping the system). Some of these incidents are documented in Barstow et al.'s book, but the Interlisp bootstrapping difficulty has been mentioned in all of the Interlisp porting papers I've read. Unfortunately, I don't think a system with those capabilities can be built with the rescrictions of modularization, since all of the things it did are applicable to programming in any language, and to do them required precisely the
In the great CONS chain of life, you can either be the CAR or be in the CDR.
(see lisp)
Putting a language in XML only saves you from (maybe) writing a lexer or maybe a parser. After that there is so much variation in semantics between languages (and valid operations on the code) that the supposed "uniformity" disappears. Also, there are an huge number of ways to represent any given language's parse tree in XML. Do you even represent the parse tree or do you do it at a token level? Are numbers and strings their own element types? In other words, simply using XML doesn't buy you much in terms of uniformity.
Isn't lisp an a self extensible language?
Considering it has been around the 50's this idea is not new if I remember correctly.
Steve
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.
This was actually done a lot, as most academics thought that the ALGOL syntax was clearly superior to the C syntax.
:)
For example Steve Bourne wrote the Bourne shell (from which BASH ultimately derives) in such a C macro dialect, and it remained in common use for decades afterward. Seems silly today.
This is related in Peter Van der Linden's Expert C Programming, Deep C Secrets along with lots of other cool programming legends. So if the above fact is false, blame him not me
STOS was a BASIC programming language for the Atari ST, where you could add extension to the language or program your own in assembly language. AMOS was the same thing, but for the Amiga.
STOS and AMOS were interpreted programming languages, but they could be compiled into normal executables.
Even I had this idea a long time ago, where organizations would make their own library of code for their own systems.
STOS and AMOS do not work with syntax, only commands.
Well of course that's what templates are. Yes, their syntax is horrendous but that's what comes of trying to wedge the concept into the existing crannies of C syntax (or when, as Stroustrup remarked to me once, "the ecological niche was already polluted").
If you hanker for a language in which metasyntactic extension is natural, you need Lisp macros (or here and here for a more complex example), Scheme "hygenic" macros or the CLOS MOP.
But if you really want to consider "hooking into the compiler" as you say then you should look at the reflective programming work, the ground work for which was laid down almost 25 years ago by Brian Cantwell Smith and was even implemented, by me and others, back then. Although a lot of work continued in this area that vein pretty much got mined: unless you can think up a completely new control structure there's not a huge amount more you can do with such a system than you could with a normal metasyntactic extension mechanism.
HTH
-d
I've been working on a pet project very similar to this for a couple of years now off and on.
Currently, I'm constructing the editor as a javascript/xul/xbl based application under mozilla (not yet publicly released) and tossing the documents over jabber to a code repository which connects as another client. Other pieces in the suite, such as the compiler, talk over jabber to the repository, helping to ensure modularity.
Why mozilla? It gives me a cross platform editing environment and I can take advantage of the built in xhtml/mathml rendering. (Although, I admit I'm largely hamstrung by the faulty mathml rendering on Mac OS X at the moment)
Why jabber? It serves as a glorified RPC mechanism for exchanging XML document fragments for me. Its primary advantage compared to SOAP, XML RPC, etc, is that I can allow the repository or execution environment to send out updates to the clients, rather than rely on client based polling. After all, in this day and age of everything lying being NAT, you usually can't open sockets to clients directly. It also has the advantage that it makes evolving the platform into a collaboration environment a simple logical progression, rather than something grafted on as an afterthought.
My main interest is in what advantages you derive from allowing a rich text markup language and extensible grammar, and the ability to tag information and retain markup across versions.
A smarter editor allows you to move towards allowing dynamically defined operators, which can have their precedence defined in terms of a partial ordering with respect to one or more existing operator, that way you can red flag during the editing process when something is ambiguous. Superscripts, subscripts, radicals, Riemann sums are allowed by defining small extensions to the grammar in the language and loading them into the editor.
The potential for language tagging comments or method labels for internationalization is nifty, but more than a bit of a Pandora's box.
An XML namespace for version control means the repository can store one document much like a cvs system. By having the editor submit a series of change requests to the repository rather than edit the document directly, integrity is ensured.
Since you have a fairly stable set of tags you can now embed more information for statistical collection, loop counting from debugging compiles. Links to hand- or auto-generated proofs of algorithmic correctness, big-O information, etc.
So, yes, there is a value to storing the data in XML and making the editor smarter.
However, one primary is that any such project has a rather high bar to clear to become even marginally useful.
There are also a number of interesting problems regarding how to handle certain types of code refactoring and traditional text editing operations in this sort of environment.
Sanity is a sandbox. I prefer the swings.
With the new xmlrpcjit you can compile your xml apps in a distributed fashion so it is almost as fast as running vb apps. I can't wait.
I agree -- XML is one of the most hyped buzzwords of the 21st century. When used for storing larger amounts of type complex data, the structure of an XML container often grows to enormous amounts. And with Microsoft proclaiming XAML and every single byte of source code embedded in XML documents, we can only imagine (and fear!) the sizes of the CVS development repositories of the future.
I work as a developer on a combined Java/C# code generator application for exchanging data between several data models, XML formats, databases etc. The application primarily uses a GUI for defining the data mappings, which triggers the need for a generic XML container for storing the code. When the mapping is defined, you press the -button - and the application generates the code in the language of choice. This really shows the strength of the XML world, also in the vast territories of application development - generic data are translated into the development environment and platform of your choice.
In this way, XML is a nice choice. But don't hype it too much.
Most of the problems with windows is from 16 year old programmers who never think what their code will do in the real world.
So don't throw this at little kiddies who can't even program the way we do now, wait till they grow up and learn how to *really* program.
Don't drink and drive (but teenagers do it anyway)
Don't program anything important till you're at least 21
Science Fiction isn't really about the future. it's about the time it comes out of and what is on people's minds. there used to be lots of science fiction about radiation and hypnosis turning people into superhumans. now we have xml, which is really a lot more interesting.
There's always someone trying to push one of these. Right:
XML - It's markup. That's it. STOP IT WITH THE ROUND PEGS AND SQUARE HOLES!
'Unix command line' -> 'Windows COM' - Yeah, I can see how people are abandoning:
while read name; do convert ${name} -resize 100x100 ${name}_thumb; done
into COM because COM it so much EASIER and so POWERFUL. Please. No.
One more then, macros to convert one to another. New idea this. Not at all like:
#define loop(i,m) for (i = 0; i m; i++)
then?
There's nothing new or revolutionary here. Nor is there much coherence or common sense in the first part. Languages will evolve the same way they always have, and no amount of shouting 'but.. but.. XML! and.. and.. MODULAR' is going to change it.
End of rant. Flame retardent underpants on (you never know around here...)
Cite:Want to see for yourself?
http://www.nongnu.org/stumpwm
-- a blessed +42 regexp of confusion (weapon in hand) You hit. The format string crumbles and turns to dust
Sounds like "source code in database" a.k.a. SCID. I have a feeling smart IDEs like Eclipse are doing part of that already.
If the goal is to express programs more briefly, presumably at a "higher level", then I don't believe an extensible language alone can solve the problem. After all, we already have languages which are extensible to varying degrees. In my experience, code that maximizes the use of language extensibility tends to be the most cryptic to read, at least until you thoroughly understand all the extensions used. Witness C++ code that makes heavy use of overloading and templates.
A large part of the problem (IMHO) is the slowness of developers in standardizing common data types and programming idioms. I'm not a linguist, but there must be some interesting parallels here with the development of human language. However, there is one important difference: programmers are usually more concerned about getting a computer to understand their programs than getting other programmers to understand them. Thus, there isn't the same motivation that Tak and Nog would have had to agree on the linguistic expressions and social conventions that would allow them to hunt the woolly mammoth and divide up the women.
In fact, experienced programmers do tend to standardize their own use of language extensions, libraries, and program development tools, as this does enable them to program more efficiently. Many software companies do the same, which is probably how they manage to accomplish anything at all. But most software companies place very little priority on creating industry standards (unless, of course, they think they can own them).
on Lambda the Ultimate.
I am fairly dissappointed after reading the article, there is nothing new that wasn't said before. He is fairly niave about the subjects he discusses. Shame really.
I don't buy the idea. CLI and strings of chars are useful because are simple. XML IS NOT simple. Look at how many programs in our compuyters process text data, pretending to have a similar amount of programs for alternate XML processing is just a vaste of time.
KISS
What's in a sig?
What's in a sig?
Fortran as usual! (why not?)
Thank You for the best belly laugh I've had all week.
I18N == Intergalacticization
I would say that at the very highest level (specifically the first paragraph or so), this article has got the right idea. Then it takes a bad idea and runs around like a headless chicken with it.
They talk about the fact that computer programs are represented by 'collections of arbitrary ASCII tokens' as if it is impossible to discern the meaning of the program. Er, that's what parsers are for. They parse 'collections of arbitrary ASCII tokens' into data structures. Incredibly, those data structures look a lot like their XML structure. Except, if one wishes and is clever, you can do fun things with those arbitrary data structures that are hard to do in XML (e.g. turn them into graphs vs. XML's trees). You manipulate the data structure, serialize it into text and save it. And you're done. Simple. Their problem is a non-problem.
There is also a serious lack of understanding of the term 'semantics' in this document. They are *not* representing the programs semantics in XML, they are merely storing its abstract syntax as opposed to its concrete syntax. Giving things a bunch of XML tags does not infer semantics - those semantics are defined and implemented elsewhere.
In my opinion, there are several factors that have held back so-called 'extensible programming'. Here's a couple that spring to mind. Firstly is the sheer awfulness of most parser generators. They're fiddly to use, and accept laughably limited forms of grammars. This dates back to when parsing was a very processor intensive job - these days, however, Earley parses and the like can cope with any grammar you chuck at them in comparable time to e.g. yacc. Secondly, most languages don't have macro languages, and those that do (like C) tend to do it at the token level, which lacks power and is prone to disaster unless the programmer is incredibly careful. Those that operate at the syntax level (basically LISP) work with languages whose syntax is so restricted that it's difficult to generalize to modern languages. However, I feel that Template Haskell provides a solid indication as to how modern languages can incorporate macro powerful and practical systems. And, before anyone dismisses this reccomendation, I'm *not* a functional programming fan - I just think that TH approaches the problem in a way that can be applied to other languages.
How will they handle this mess?
How could we integrate/view/merge the differences between versions and allow concurrent versionning?
I'd definitly like that one. Imagine for example programming 3D Stuff and you had a plugin which allows you to display vectors and polygons in 3D. Currently i often paint 'em on paper while debugging.
And i could imagine some more plugins would be useful for me, for example pushing the variables i'm currently watching to a log file.
I remember adding modules onto the Tcl interpreter back in 1994. This is hardly cutting edge stuff. Ok , it didn't change the actual syntax of the language , it just added new commands but its the same sort of thing in terms of functionality since you could have those new commands do anything you wanted. I do wish people would stop pretending to be futuroloists when they're apparently not even aware of the recent past.
Oh, yeah? They found it would be useful to be able to extend the syntax of a programming language, by representing it in some structured tree form, like XML? How truly innovative. Reminds me as if I had seen this done right some, er, more than fourty years ago. And I suppose it's called "LISP" and "Macros".
Boy, I wonder wehen they will come around to inventing such ingenious new and ultra-flexible systems that not only allow you to design your own syntax, but also influence control flow in most abstract and flexible ways.
Morons... throughout the world.
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.
Someone should break it to the guy that modern programming systems already consist of compilers, linkers and debuggers, and that modern apps are already more like plugin frameworks than monolithic programs.
:-) Microsoft have been doing this stuff for almost a decade now, and every other major app from Photoshop to Maya to CuBase is just a plugin architecture.
I mean, Jeez, was this article written in 1980?
He predicted COM and Visual Studio! Go University of Toronto!
Read: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8 &threadm=7a8ba0c2.0404260409.390fd7eb%40posting.go ogle.com&rnum=1&prev=/groups%3Fsourceid%3Dmozclien t%26ie%3Dutf-8%26oe%3Dutf-8%26q%3Dnamed%2Bargument %2Bfreer%2Bsyntax
Someone's two ideas on "IDE-Based Named Argument Viewing/Editing and Freer Syntax for International Users":
http://babelcode.crazylife.org/?skip=11
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.
Um. the preprocessor has allowed that for years...
#define BEGIN {
#define END }
Thought this was a very bad thing because it made a program unmaintainable....
IMO, this is nothing new. Microsoft's Longhorn presentation, at the PDC in LA last fall, made it pretty clear that Longhorn will be shipped with the compiler and an extensive class framework "installed".
C# is part of the operating system and the file system. The operating system will generate "partial classes" for new file "types" and other functionality on demand.
Since the compiler will be part of the OS, I could write an application that could generate code and run it, leveraging existing classes already on the system.
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
I think what we're really looking for is simple meta programming (introspection and transparency). F.e. have a look at the Java-project Compost, which is supported by Prof. Goos (famous compiler engineer).
I don't know, wether C# has introspection (I think so). Unfortunately there is no easy way to introduce metaprogramming to C++ with its preprocessor and the hardcoded virtual method tables.
LISP.
Reading the fscking article now; oh, he did say that already.
Good stuff.
Having access to the parse tree is only valuable to a point, and in Lisp you have to use MOP to do more. Most of the limits in software complexity and maintainablity are in the relationship that span the branches of the tree, and are not made explicit in in tree itself. You don't want to do code generation such 'this interface has a "visit" method for each leaf subclass of class in this package' using XSLT or any other tree based model; either you have a relational model, or you have to write masses of tree navigation code. In terms of parsing and storage, if the common syntactic model was expressed as ASN.1, then both the Java syntax and the XML syntax could be encodings of the same abstract model, and you could use whatever tool you liked, and store the code in whatever form you like.
author tries to slam both vi and emacs at the same time. +1 gutsy. however, to do so he resorts to placing words in the mouth of grizzled vi and emacs users. -1 unnecessary. so overall, it's a wash wrt grizzled programmers.
thus, the question from this critical reader is: what is left? unfortunately, the bulk of the paper gushes on about the easiest workaround in computer science -- syntactic indirection -- and neglects to delve into the more interesting "plugin" idea (which incidentally, emacs has covered since the beginning and newer versions of vi are starting to grok as well).
so, "obfuscation is understanding" is the message? i don't think so. i think the message is that trailing-edge programmers should taste the power they envision leading-edge programmers have, by buying into the siren songs of middle of the pack programmers (who happen to play "vendor" and other intermediary roles) and their mediocre mish mash of soothing "technologies". frankly, that reeks.
it reeks mostly because he says "what deserves to succeed shouldn't". this is essentially a conflicted statement, probably a defenseive measure the author uses to befuddle himself enough to spew on so, w/o internal damage. that alone is not a problem, but the dude is a doctor and poor slobs like me expect doctors to use more sophisticated self-deceit.
but any deceit is akin to syntactic indirection, and thus like the waves tossing about the surface of the ocean. the orcas and monster octopi deep below, slinging parentheses w/ aplomb, don't mind the frivolity so maybe i won't, either.
It's a common thing to hear, but I don't see it as a reality. I notice most of use are focused on the "xml" -- I say now, end ever after, you will never get me writing a program in XML.
I wrote a fuzzy-logic boolean type once, where I could writethe statement would be 'true' even if a was 'not completely true' and c was 'definitely false', if only b was 'very true'. Fuzzy logic with familiar syntax. All transformed into efficient simple machine code by the wonders of the compiler internals.
Yet, even something as simple as this is not well understood by most programmers out there. I sincerely doubt that more of this transformation madness is going to solve any significant problems - what we should be worrying about, is to educate people to begin using what is already available.
Then, in a few decades when we have experience with the technologies from the last decade, let's talk about extending on that or re-doing things.
From the article:
If success is measured by longevity, the Unix command line is the most successful programming system in history.
You can tell the author has spent his entire adult life in academia. If sucess is measured by longevity, COBOL & Fortran are the most sucessful programming systems in history.
need a free COBOL editor for Windows?
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
What a terrible paper. This is garbage written by someone that feels a need to publish something to get another year of research funding. The paper is poorly organized, unsupported, and fails to draw any definite conclusions. Code is basically irrelevant. I spend 70-80 percent of my time in A&D. That's where I create the program structure and the flow of functionality. Object lifetime, error handling, mesaging, persistance. All of these are designed into the system. The code is just a means putting it on 'paper' and requires little more that a common language to do it in. A proper design can be coded in any decent OO language and come out just fine. The developers of the future will be designers. Any monkey can code a loop. A real developer can tell you if it's the right way to do what you need.
What most people don't realize is that most of the developments in programming languages knowingly or unknowingly follow this trend. For example, object oriented programming (a la C++, Java etc etc) is closely related to how our brain sees the world as a hierarchy of objects. Type inference (as in ML) is closely related to how our brain derives useful information from incomplete data.
Computer languages are moving away from small languages to bigger more expressive languages. The evolution of Perl I think reflects this trend. XML etc are just syntactic sugar. They don't reflect any fundamental steps. The difficult parts have yet to be done.
In many ways we are at the beginning of the evolution of computer languages. I think the next 10-20 years are going to be very exciting.
While agreeing with Paul Graham that programming languages represent notation, I don't quite agree that they must evolve as slowly as changes in notation. I think there is a real difference between how notation is used to represent meaning in programming languages and how they are used in human languages. Different domains demand different notations of differing precision
In conclusion, computer or programming languages will evolve to be closer to human languages. There will be specializations of the language for different domains. This is akin to using mathematical notation to describe mathematics rather than write each rlationship out in wordy English (or other language).
dane smells
maybe 1000 times before. Those "integrated programming environments". UCSD/Pascal, Oberon, some LISP-stuff/machines, smalltalk (iirc) was also more an environment for "doing stuff".
Pascal eventually revolved around the P-Code, a VM much like the JVM is now.
What is so revolutionary? The word "XML"?
he can shove XML up his b@tt in 20-30 years.
I'm not in the mood for insightful and thought-provoking, but from the description it sounds kind of like Mozilla's programming framework. Except for the compiler/linker part.
t["a"]="blahblahblah";
t["a.d"]=4; :)
t["a.b"]=1;
t["a.c"]=2;
Last I checked, academics that wanted to change the world didn't write manifestos, they wrote reference implementations. Do you think we'd have garbage collected, object-oriented GUI-capable programming systems today if some twit up in his ivory tower said "Everyone should go build these"?
I doubt it. The only way these ideas get into the mainstream & accepted is with implementations that have the 'hard problems' solved & prove that the idea works. Looking over this guy's website, it doesn't look like he's willing to put his money where his mouth is.
my sig's at the bottom of the page.
wow, a troll designation for responding to the question in an honest, consise manner.
I demand a recount!
(and I still say the answer is NO)
I think what is interesting about this isn't the immediate benefits (being able to format the code to your liking is more of a convenience), but what could be done with it down the road. With the code as XML, generating class diagrams and flow charts suddenly becomes easier. Round-trip engineering using UML diagrams isn't as messy. Cross-referencing for API documentation could be generated automatically. I like pounding out code as much as the next programmer, but for large projects, it would be nice if we didn't need a special word for refactoring - we just moved fields and classes around.
In some ways it can give you more control over your code. Mark all of your debug statements as debug or logging, and then tell your editor to hide them. Bug in the networking code? Have your editor show a flow chart of that code. Sure, a lot of that stuff is possible now, but tools have to bend over backward to get it to work, and they muck up your source code.
I probably sound like marketing hype, but to me it's interesting to think of the possiblities.
At least that is my experience.
I'm a little surprised you can mention Python and Ruby and omit Perl.
The big weaknesses I see in Perl are
* The need for an (optional!!!) "use types" kind of strongly typed mode
* Non-kluged (eval is a kluge) exception handling.
* The need for a standard GUI toolkit in the distro (I know Perl/tk exists, but it's not shipped normally, I believe)
Otherwise, it's generally easier to write a modest size job in Perl, rather than in Java, AND, it runs faster. I do a lot more batch-ish stuff that user-coddling GUIs (<Grin/>), so the run-time speed matters, and the fact that Perl is also EASIER to write helps.
I hope Perl 6 comes out sooner, rather than later...
Yow! I'm supposed to have a plan?
He and who else?
I actually agree with almost 100% of what the article proposes, and the above poster clarifies. I've been sketching ideas about this for about 5 years, a project I nicknamed 'Babel'.
Let me address some common misconceptions I see here:
Lisp/Scheme/yourfavoriteprojectorlanguage already does this. Yes, but this is a proposal to take a number of features that have been done in various places and make a better whole of them. Also, my interpretation is that the proposal doesn't necessarily involve substantial runtime support beyond what current languages like C++ require, making it quite a bit different from LISP.
Also, I don't want to read/write Lisp. I don't want to read/write XML. I want to read/write something that looks like languages I'm already comfortable with, like C++. This proposal would store the data as XML (not that XML is the crux of the matter, it's just a convenient form -- you could do the same thing and store it in binary form, or more ASCII-like) and on-the-fly translate it into a form the programmer wants. Something like the CSS mentioned by the above poster could be used to control or assist this. No more bracket/indent style holy wars. Each person's editor/browser can display it in the form they prefer, and yet all the merges and diffs work out fine because the actual code format is agnostic to all this window-dressing.
Because the 'meat' is stored in a structured format, with standardized tools and procedures for parsing it, making batch tools to work with it will be much easier. How about writing a tool to find all variable names and de-Hungarian them? Try that with flat text. Or, even tougher, HUNGARIAN them! (Not that you'd want to, but...) How about locating all references in the project to any floating-point variables named something like Fred? All methods that take a Barney object as an argument? Any method that has the word Purple in it that calls a method in the Dino library and uses a Yabba object. I bet you could find laborious or exotic ways to do this now, but if code starts being stored in a structured way, and you have the opportunity to hook into the language data inside the lexer/parser, you can do quite a bit.
Smart editors like this could, as pointed out elsewhere, do syntactic and semantic checking on the fly. Move a block of code around and immediately see that you missed moving the scope of a variable, or that in this scope, WhiffyObject doesn't have a Fubar method. Sort these things out at edit time, not parse/compile time.
Even better, a really smart development system could be doing the lexing/compiling behind your back, as you edit, because it's doing a lot of that work anyway to do syntax highlighting and checking.
Yes, there are downsides to all of these things, but the upsides are very attractive. Allow me to cite from my own notes about this sort of thing:
Babel
Current ASCII flat-text parsed languages are an outgrowth of a time when editing was cheap but compiling was expensive. They rely on intelligence and resources of programmer in favour of intelligence and resources of computer.
Intelligence and resources of computers are increasing, of programmers are not. Effective balance begun to swing -- computers can relieve tedious tasks from programmers allowing programmers extra resources/intelligence to execute more sophisticated and complex designs, or better quality of existing designs.
Languages are fundamentally very similar at heart, each with own bells & whistles, and each with own peculiar syntax. Many are very similar to some degree -- withness moderate success of fortran-to-c, pascal-to-c converters. GNU compiler suite uses different front-ends on a common middle and back end to implement ADA, Fortran, C/C++, etc. In the beginning (and many would argue, today) C compilers were just C-to-asm translators. Many original C++ compilers were (few still are) C++-to-C compilers. Java source code can be compiled into JVM code or native code (Metrowerks, etc). C/C++ can be compiled in
-- There is no truth. There is only Perception. To Percieve is to Exist.
Please do this to save the computing world!
If somebody does a grand design with XML everywhere replacing text files, kick him hard in the nuts.
Start with the guy who wrote Gconf.
I actaully had this prof last year in a second year course (CSC207). I probably learned more about programming practices than in any other course however all my interactions with Greg were extremly scary and I found him quite intimidating. He's a pro for sure though.
This is an interesting idea. I always thought that the shebang line was not enough.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Interestingly enough, "</perl>" is valid Perl. You would have to find another delimiter. Good luck.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
None of this to say Python's usage is bad. I love Python. I love that there is no possibility of getting mislead by incorrectly-indented code, as happens sometimes in C.
The syntax is no more complex than C and totally acceptable for any programmer -- but that's still a lot more complex than Lisp, the language with almost no syntax. Naively moving indent syntax into Lisp would give you the worst bits of Lisp (prefix algebra) and Python (non-trivial syntax).
It is curious but the article just describes MetaL.
MetaL is actually a meta-language with a XML based syntax on which you the commands and constructs can be redefined by the means of compiler plug-in modules.
Anyway, MetaL was not meant to replace the current languages but rather to implement domain specific languages that can get compiled into code of current programming languages like PHP, Perl, Java, etc., as you may see in the MetaL sample page.
This is not normal programming this is meta-programming because it is a language to generate programs in other languages.
One domain specific application that is being developed as an application of MetaL is Metastorage.
Metastorage is a DAO (Data Access Object) classes generator tool that generates classes of objects meant to be stored in persistent containers like databases, XML files, flat files, data in LDAP servers, etc..
Metastorage takes the definition of persistent classes including properties, validation rules, relationships between classes and also functions that implement different aspects that you want the persistent classes to feature like retrieving objects from storage, changing object properties, validating object properties, store objects, manipulate relationships, etc..
Since Metastorage enables Aspect Oriented Programming because it lets the developer choose which functions that implement the aspects of the persistent classes he wants to be generated. This leads to very compact classes that do not contain code that is not always needed (bloatware).
Anyway Metastorage is just one type of tool based on MetaL by the means of a special module meant to implement persistence layers. Many other types of modules could be made available when there is need for other domain specific needs.
Wait, this is exactly how I program right now. I guess the future must be here, already.
I combine compilers, linkers, debuggers on the command line. All my tools are plugin frameworks, rather than monolithic applications. I connect them to each other using pipes and batch commands. For extensibility I use the C pre-processor macros and Perl.
So what he is saying is that in the future all programming will be done in Vi and Bash.
I would like to predict that programmers of the future will replace their laser mice with a new and highly-advanced interface device, with lots of buttons, called the keyboard.
----
asimjalis.blogspot.com
From the paper:
Doesn't Cygnus' work prove this to be not true? Brad Kuhn, executive director of the FSF, recently came to the University of Illinois at Urbana-Champaign and gave a talk about free software. Kuhn mentioned one or two other consulting firms like Cygnus which did GCC work. He said that one of them was booked for a long time in advance (a year, if I recall correctly -- I don't have a transcript of his talk to refer to) because they were in such heavy demand. So it seems to me that GCC is quite extensible and ready for improvement by dedicated hackers. Difficulty of doing the work is one thing, but at least GCC can be legally shared and modified (unlike proprietary compilers).
It also seems unfair to not recognize that GCC was conceieved and originally written by and for free software hackers (first among them RMS, if I recall correctly) for the free software movement years before the open source movement started. I'm guessing that Dr. Wilson wouldn't like his work being credited for a movement that doesn't stand for the same values years after his work was started. RMS sure doesn't like that and today's GCC does build on his work. The open source movement has done a lot to bring people to software freedom, and I'm really grateful for all that hard work, but we're not going to be able to properly interpret history if we don't understand what "open source" and "free software" stand for and then give credit where credit is due.
Digital Citizen
'Nuf said.