Peter Newman 8 January 2005
"Unified Programming Language" is an attempt to create a programming language that combines the best features of all scripting and compiled languages - with none of their defects.
It arose from an idea suggested by DKF (I think,) on Tcl/2, that it might be easier to improve Tcl if we started with a clean slate - and designed a new version thereof (called Tcl/2) - where backwards compatibility with traditional Tcl isn't a requirement. So we can take the bits we want, leave those we don't, and innovate to our hearts content.
Seems to me the best way to go. So this page and its sub-pages are just an attempt to make that new Tcl/2 happen.
Obviously however, it's too big a job for one person. So it'll die unless heaps of others - and that means YOU - pitch in.
I won't go on about what's right and wrong with existing Tcl. It's discussed exhaustively on this Wiki.
First thing we gotta do is get some concrete overall design down on paper. Here are the main features of the new language. Feel free to add more...
Gustav Ivanovic Huh? This reminds me about something called M$ dot net framework.
SLB Yes. The Java Virtual Machine also has compilers for other languages, for example see [L1 ]. Also note that parrot has a Tcl implementation, though it appears there's still a lot of work to do on it [L2 ]. Does the world really need another multi-language virtual machine?
DKF: Just noting that I didn't suggest that. (I don't know who did though.)
To me, the idea of a unified programming language reminds me very much of the phrase "Jack of all trades, but master of none." You gain in one area by making trade-offs in another.
Peter Newman: Yeah the name "Unified Programming Language" really sucks. It's totally misleading.
UPL isn't really a programming language (because it has no pre-defined commmands/functions, data structures, operators or conditionals, etc). It's a system that allows the script-level programmer to have total control over the programming language they use. In Tcl terms, we're just extending the package concept into the core. In UPL, every data type; 'lists', 'arrays', 'scalars' (variables with a single value), etc - and command or group of commands (you know them all), is a single stand-alone entity that the script level programmer can add to or remove from the language at will.
That same modularity goes for the parser, and byte-code executioner, etc. Every component of the language is a separate stand-alone module that can be analysed and understood and coded and re-coded and bug-fixed and extended and enhanced, etc) on it's own. The only thing is that they all swap information between each other. So we have to define who does what - and how they talk to each other. But I'd like the whole thing to be as flexible as possible.
The modularity means that one can then completely redefine the language, simply by adding the new data types and commands/functions etc. that you want. Even the parser for example can be replaced. So if you wanted a Tcl that didn't use {} and/or , etc - but had a more C-like syntax (strings in double quotes, and commas between items), you can do it.
As a result, you can add data types and commands and even syntax rules from other languages.
The modularity also allows UPL to support multiple parsers. So you can code one part of your program in Tcl - and maybe another in Forth, and/or Perl, and/or C, and/or Haskell, and/or Scheme. Whatever you want (or more precisely, whatever someone's implemented a parser, etc., for).
We get the modularity by insisting that every component of the language be designed from the outset as a separate stand-alone entity. And then implementing it as a separately loadable dll/so.
Which is completely unlike Tcl and Perl for example - both of which are implemented as a single monolithic core. With Tcl and Perl, if you want to change anything - no matter how big or small - you've got to understand the entire thing - to ensure that by changing or fixing one thing - you're not de-railing another. Then you've got to recompile the whole thing. It's hopelessly time-consuming and un-productive. And IMHO, the root cause of why changes to and improvement to stuff in the core seems so agonisingly difficult and slow.
So with UPL it's the modularity that's the important thing. Hopefully, that will create a language that, unlike Tcl and Perl, doesn't have a monolithic and inflexible core that makes enhancement and improvement increasingly difficult as it grows.
That gives us the abilty to add useful features from other languages. And to freely innovate and improves any aspect of the existing language. It also allows the script-level programmer to freely select and/or create exactly the programming language toolkit they want to work with.
It also makes development and distribution of even the low-level stuff that's currently in the core much easier. The developer simply creates or recomplies the dll/so concerned - and the user loads it.
DKF: I got the picture, but I suspect that what you're proposing isn't going to work as well as you hope. In particular, it doesn't seem to me that it will be easy to share the scripts created using UPL with anyone else; there's no way to determine if they have the same set of modules loaded.
XX: I am usually content to let the experts hash out the technical details, but feel compelled in this instance to comment on a couple of points...
I did some experiments myself with modularizing an earlier version of the TCL core that had been ported to DOS. I have found, as others, that not only are there difficulties, but the payoff is not as great as anticipated. Perhaps a CVS branch "TCL-embedded" might be an interesting undertaking, and an attractive one for marketing to a certain audience. But facing facts: hard drive space and memory footprints simply aren't the issues they used to be in the majority of the deployments out there. Even having a "Site TCL" and individual deployments suited for particular purposes wouldn't even begin to make a dent in the resources of most systems.
Further, this particular idea, while having some nice features on paper...I don't know. First, as DKF suggests, the actual shape that the implementation will take raises some questions. Next, after reading the descriptions herein, I am left without a clear picture of what the actual benefits are supposed to be...what is the problem that this solution is actually attempting to solve. I look at the reaction of the Perl community to the proposed Parrot engine...the .Net backlash. These might not be technically the same but they are similar in that they all add a new meta-layer of sorts to the mix. Why should TCL follow these bad examples with its core. Let us target their engines (as is being done) and compete with them there.
I'm hardly a reactionary thinker, and actually do like some of the suggestions that are included in the UPL pages. And perhaps UPL has its place, but not as a replacement for the TCL core, in my opinion. Personally, UPL, Parrot, .Net etc... all make me a bit queasy. For those that have read "Mostly Harmless" the 5th book in the Hitchhikers Guide to the Galaxy Trilogy, I am reminded of the creepy new edition of the guide that takes the power out of the hands of the user. I'm sure I'm jumping at shadows, and I try not to let this queasiness cloud my opinions too much. But "managed" is to me a euphemism for "mangled" and "bastardized" I'll manage my own code, thanks.
I do look forward to watching this all hash out, though. There are intelligent opinions on both sides of the discussion, and the subject of the future of TCL keenly interests me.
anand - 2011-03-21 01:59:03
I think we have already got a Unified Programming Language which is XML
http://www.w3.org/TR/xpath-functions/
Anybody can write one's own programming language in XML and describe it neatly and completely using XML Schema.
The input is a file in XML, rules to create input are in XML schema, the processing instructions are in XML (XSLT file), rules to interpret custom programming language are in another XML schema, the output is XML (XHTML) and the interface is a web browser with full HTML5 text/image/audio/video rendering capability
Someone once had a problem. So they decided to solve it using XML. Now they had two problems.
So the saying goes. But seriously, people who think that XML is a reasonable programming solution is out of they're F*in mind. Its an ugly, convoluted mess of a description language that is outdone in every way by JSON (in simplicity and descriptiveness). Its *not* a programming langauge and was never meant to be one.
So I'd love to see a *real* unified programming language - one that is simple, elegant, concise, easy to learn, and portable to any platform. I'm trying to do it myself, because I don't think its too big a problem for one person - in fact, I think the more people involved in a language semantics design, the worse off it is. Look at ADA, java, ... ahem xml. Here's lima: http://btetrud.com/Lima/Lima%20Documentation.html
~Fresheneesz