Slashdot Mirror
Perl 6 Synopsis 5
XaXXon writes: "perl.com has Synopsis 5 for Perl 6 up. It's a brief overview of all the changes made in Larry Wall's Apocalypse 5. Lots of stuff about the new regex syntax. I must admit, however, that I'm getting tired of reading about perl 6 -- I want to start using it." We posted Larry Wall's 5th Apocalypse in May.
... I'll finally be able to make sense of my perl code after I write it?
~geogeek
Well, go right ahead. From the Parrot VM, the Perl6 engine, page:
Use Perl6--Write some Parrot assembly, and help out!Click here or here.
"And they wandered the desert for forty years, until they found the llama, and the llama led them to the camel of Wall." Perl 6:Synopsis 5,5th Apolcalypse.
For instance there is now OO COBOL but the only people that use it are COBOL programmers who are stuck, perhaps because of their company's dictates, perhaps by choice, with COBOL. In the same way perl may be heading towards irrelevance wrt "mainstream" language. I've written commercial perl in the past, it was a pain then and it's still a pain now. The thing is that now there are alternative languages in the same space (python, ruby etc., php for web side) that do the "perl thing" better than perl.
Perl was great, it introduced many people to programming, just like COBOL did. But now it's time to move on. To move on to languages that learnt from perl, that improved on it, that don't have to drag around a syntax and culture that values neat tricks and trying to guess what the programmer really meant over providing the needed building blocks and letting you build code that does what you say, not what it thinks it heard you say. Or even, dare I say it, to move on to languages outside the perl family for some programming and choose the right tool for the job for a change.
I'd prefer to think of this as provocative rather than a flame, there is a difference you know.
For all of the hub bub and brouhahah, I think after it is released and people start to explore all the new (and old) features, folks are going to find Perl 6 an amazing tool that improves on an already amazing tool set.
With all of the flame wars regarding Perl/Python/Ruby (like triplets calling each other ugly), it's good to see Perl continuing to innovate, improve and set a brisk pace for others to follow.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
Wall has changed the language too much and now more regex changes. Like Pascal when major updates became Modula or later Oberon. Original Pascal was left to evolve on it own. Same with Turbo Pascal when Borland heavily changed it they changed the name to Delphi. Call Perl 6 the new beast that it is.
I don't pretend to know anything about Perl 6, and hopefully they are cleaning up Perl. However, I agree with your assessment of Perl 5: a thousand ways to do the same thing each using their own exclusive exotic ascii character combinations.
One has to wonder about the relative success of Java, given its horrific performance and obscene installation complexity. However, ultimately Java's success comes down to the lack of choices in the language syntax and a strong networking library.
Of course Java syntax is a simplification of C++, while Perl's roots are in shell scripts.
I wish there was a shell with the simple grace of C, the libraries and idiot proof installing packages of Perl, and the portability of bash.
Someone you trust is one of us.
#sarcasm# Yeah!!! Just what we need more RegEx fragmentation #/sarcasm#
.
Honestly, RegEx hasn't changed much since awk and when it did, Perl usually led the way. The changes though usually just added features or tweaks, my RegEx still basically looked the same though whether I used VIM, Python, ASP, C++, Perl,
Shortly after reading the changes, I was aghast. Sure some of the changes make sense but some are going completely against RegEx as we know them now (getting rid of character classes for one []) . Sure you can use the p5 modifier or do the funky syntax to use [] but the issue is its a radical change.
This is a bad thing(tm). This is going to force all us RegEx people who currently using 4 or 5 different RegEx tools to not only learn minor differences based on each app, but we will be forcec to learn a COMPLETE DIFFERENT subset of RegEx syntax incompatible with anything else.
Now wait you say, Perl has always led the way and other tools seem to use perl compatable RegEx libraries. Not so with Perl6. Have floated this question out on a couple developer lists (PHP for one) and everybody is saying, Perl 6 RegEx support isn't going to happen. They are all happy with the current state of RegEx's. This is especially go to cause hell with PHP's perl_regex functions. PHP has stated they are not going to support Perl6 RegEx. Real perl_regex compatible then huh.
Some the Perl6 changes are pretty good for RegEx, but the complete drop of support for character clases just isn't a good thing (tm).
My 2cents (who is glad at least Larry added the P5 modifier)
De Oppresso Liber
I used to write a lot of Perl scripts and libraries. But I've been cutting back and using other scripting languages instead. Perl6 looks like it would not be a pleasant transition from Perl5; I don't want to have to learn a new, idiosyncratic language every major release. If some of the features in Perl6 turn out to be useful (like the new regex syntax), they will make it as libraries into other languages.
First - the myths, untruths etc that have sprung up so far.
Perl6 is not backwards-compatible with Perl5 - uhm, yes it is. All your perl5 scripts will compile.
Why not contribute to phython or [insert other language here] well, python will compile through Parrot too, so who cares? If you like Python, write in Python. I prefer $%&? syntax to whitespace-as-syntax, but each to their own, but that is the joy of Parrot. Think .Net CLR without the so-far unfounded feeling that M$ are doing something underhand and nasty that you can't put your finger on. Before someone replies with "Why not just use the CLR instead of Parrot"? bear in mind this has been done to death already. It's in the FAQ, read first, flame later.
But why Perl? Okay, so it can be write-only. But this is only because of the flexibility, There Is More Than One Way To Do It. This includes obfuscated code, and plain unreadable alien transmissions. However - if you're writing code only you will ever see, then use the short-cuts. If you are writing code that needs to be maintained, then YOU the developer have the responsibility to ensure it is readable.
Heck, you could always use english; - but this is perl, you can also code in Latin, or, uhm, Klingon.
Perl is simply the most flexible language out there IMHO. If you're a sysadmin, you will have the Camel and the cookbook on your desk. Our entire environment is held together with Perl. Half the Internet is running on Perl. A dead language? Sheesh, Perl is dead, long live Perl.
If there is anything that does worry me about perl6, it is that it is becomiung too powerful, and too encompassing - it is important that the balance is maintained whereby it remains the Swiss Army Knife of languages, that it remains as easy for the casual Perl programmer to keep getting their job done with simple scripts as it is to create large projects.
He also goes on to note that the CLR could be a pluggable backend for Parrot to export to.
What a wussy response. So what you're saying is that those languages are all good, except when they're not.
I love Intercal because it destroys all the "they're all very nice" language relativity arguments. Here's a language that's specifically designed to be as annoying as possible. I dare you to advocate Intercal in the same way you did above.
Both the PHP language and its implementation have significant problems. Regular users of PHP already have their own list of language design annoyances ("it has to be a global??") and you can see some of the implementation problems here. You will note PHP's implementation getting beaten by Tcl, gawk, xemacs, and njs. :-(
PHP would have been better off if the implementors had used an existing language like Lua (80k of x86 code for standalone interpreter+core libraries!) and focused on the embedding features unique to the application area.
if Perl 6 is not backward compatible with perl 5
Uh, Perl 6 IS backwards-compatible with Perl 5--at least to the point that your Perl 5 scripts will compile under Perl 6.
I think its a ridiculous thing to say that Larry should have just contributed to Python or whatever instead of implementing the features in Perl itself. There are tons of things that can be done better, faster, or easier in Perl than in Python or Ruby, and ditching Perl just because someone else already came up with a particular feature is, IMHO, ludicrous.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
Java performance is excellent--very close to C and C++. What gives Java a reputation for being slow is that it takes a long time to start up.
Java is also one of the easiest systems to install: all you need to do is untar the archive somewhere, or run the installer (on Windows). Perhaps what you mean is that the Java runtime is big--but it isn't really if you compare it to other runtimes.
However, ultimately Java's success comes down to the lack of choices in the language syntax and a strong networking library
Initially, Java succeeded because it was simple and promised that people could deliver software as applets. Today, Java is widely used because it is well-supported, runs fast, has a huge library, and because it beats the alternatives for server applications.
I wish there was a shell with the simple grace of C, the libraries and idiot proof installing packages of Perl, and the portability of bash.
Seeing how given you are to snap judgements, I doubt you would recognize such a shell if it bit you in the behind.
Perl has always had ugly points, but regular expressions were always concise and well-known. And now Wall's ramblings about how he wants to change regular expressions are longer than the entire section about them in the camel book. Doesn't this strike anyone else as ridiclous? Perhaps too many special cases and too many borrowed extensions are being thrown into the language. What an ugly mess it is becoming.
I'm not a big Python fan, but now I'm wondering why I shouldn't just switch to Python now and save myself the grief of having to switch to a completely new Perl-like language later.
Comparing Java performance to C is ludicrous, even with just-in-time native compilation of java byte code. The root cause is the extensive logical error checking in the VM's and the libraries. C code with propper compiler hints (i.e. restrict, etc) generates fewer instructions with an overall reduced cycle time.
Installation and running of java as compared to perl is no contest (on unix). Java requires extensive and neverending twiddling aroung with your path.
Java runs fast relative to the other super-high-level script languages used for web server.
Don't get me wrong. I love Java. It's no C. Find me one high performance enterprize embedded appliance (router, switch, etc) with anything other than the mgmt software written in Java (if that).
Someone you trust is one of us.
Seems to be a lot of Perl bashers. Surprising.
:-).
Where I work Perl helps us with System Integration, fast scripting, production reports, database connectivity where speed of writing the application and flexibility in changing that application quickly are important, web sites for change control systems, bug reporting systems, etc. and much much more.
If speed of creating the application and flexibility of changing that application need to be blazingling fast Perl is the choice. If Perl is not going to provide the application speed you need then use C or C++. That is why Perl is written in C
If the Perl code you are reading isn't readible it probably had to be written too fast for the programmer to accout for that or else the programmer simply didn't care. Perl is the most flexible language ever and it can be the most readible if some care is taken. Especially in a smaller size applications.
If the perl 6 regex's have real benefits over the old style of regex's, then everyone else will switch over. Sure it will take a while, but then what improvements in life ever happened instantly?
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Java requires array bounds checking, some null pointer checking, and a very small number of runtime type checks, roughly the same as most other high level languages. That does not impose a lot of overhead, in particular with dynamic compilation and optimization techniques. And, in practice, Java code written for efficiency runs close to C/C++ performance.
What is true is that writing efficient Java code is cumbersome--the language does not make it easy, and most people don't know how to do it.
Java requires extensive and neverending twiddling aroung with your path.
So does Perl, and so do most other languages that load libraries at runtime. The only reason why you don't see it in Perl is because people usually put all libraries into the system directory.
I didn't claim Java was free, merely that Sun's compiler produces good code.
performs equally on memory and speed to a myriad of equal C and C++ programs
On microbenchmarks (which is what you are thinking of), Java is a little slower than C/C++ because of mandatory error checking, but not significantly. Properly written, large systems are orders of magnitude faster and smaller in Java than in C/C++ because they don't need separate processes or IPC.
If this sort of retardation wants to adopt Java, all the power to them.
It is your sort of retardation that keeps people developing open source 300M desktops in C or C++ and live in the blissfully ignorant belief that it is "efficient".
and I'm about to drop it altogether - both 5 and 6. Franky, coding Perl can be fun, but maintaining and debugging the code written by somebody else - isn't. THis is the implication of having the language with 'the same thing can be done in a 1000 different ways' and the language whose design mostly depends on Larry's whims - and remember that Larry is a linguist by education, and apparently he has somewhat limited understanding of all the issues concerning the 'production quality' language. So - I'll be taking a closer look to apparently minimalistic and restricted Python. Cheers.
Many people say Perl is too big, has too many features, is too complicated, etc. This is simply false. Perl has tons of features, but, more than any other language I have ever used, you can use as little or as much of it as you want. You can pick up a Perl book and start writing Perl code in 15 minutes.
Perl is ugly, hard to read, "write only", etc. This is complete horseshit, probably stemming from lack of experience with using Perl. Perl is very easy to write and read. Where I work, I have a co-worker who is not a programer. He learned Pascal years ago, but did not do any real coding until recently. Despite this, he can fairly easily read and modify my code. Yet, he can't read or modify my C/C++ code at all, and it's usually very readable, very clean, simple and concise.
PHP/Python is better. A lot of people like to compare Perl to PHP and Python. Neither are "better", there really is no such thing. PHP is for web developers, and Perl can do everything PHP can do in nearly the exact same ways. Take a look at CPAN, there are so many Perl modules for use with Apache and web development in general that Perl is far, far more capable of a web programming language than PHP(IMO anyway). And Python, I've seen some absolutely fantastic stuff written in Python, but I hate Python, because it gives me a frickin headache. I cannot read/write Python, the lack of braces, indentation as syntax is just horrible on my eyes. Perhaps I'm slightly dyslexic or something, but when I'm looking at a page of Python code it all starts to swim and I cannot tell where each code block begins and ends.
Now don't get me wrong, Perl isn't perfect. There are some things that bother me about Perl 5. # for comments, not bad but I really wish I could use C and C++ style comments in my Perl code. A bunch of #'s just look rather ugly. Threads, Perl 6 will have decent thread support from what I understand, I wish Perl 5 did, luckily for me everything I use Perl for I can fairly easily use multiple proceses instead, still would be nice though.
I for one am looking forward to Perl 6. There will definately be a learning curve, but at least it will run most scripts without modification, will make upgrading much easier.
Oh wait... this is /., it's easier to get modded up for bashing something... ok... Microsoft sucks! ;-)
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Because "X is written in Y", "X must be slower than Y"? Sorry, it doesn't work that way.
Properly written /. touting a particular language are speaking to justify themselves more than edify the reader...
This is the discussion.
You have to quantify what you mean by efficient. Ease of installation, learning, use, debugging, memory footprint, hard drive footprint, boot time, exception handling, integration, portability, what?
While I've done no Java work, I begin to suspect that a large chunk of the people on
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Perl for GUI apps? Save us!
If you must script a GUI use somthing that's been designed for it like TCL (another language I hate but it has its uses).
Yep. Perl: The language for us. Java: The language for the rest of them.
Java is nice if you want to pick up a programming language for the first time. It has the corners filed off and you won't poke your eye out with it. But, when you need the ultimate in flexibility it falls short. You can drop down to C (or C++) or latteral to Perl or Python. But, Java just doesn't give you the control over the environment that you need to cover the ground other languages do. For example, Perl is used for everything from OS installers to data modeling languages to graphics manipulation plugins for The Gimp. These are all areas in which Java is simply the wrong tool for the job.
Now, if I were hiring a bunch of junior programmers to crank out a database app, I'd turn to Java without glancing over my shoulder!
Just thought I'd rerun my previous comment producing post. Despite all of the ranting that generated I think I'll stick with my contention that Perl is COBOL for the 21st Century. In this respect perhaps perl 6 is going to be ADA, a wonderful language with lots of nice features that NOBODY USES. Perhaps abandon the backwards compatibility and design a new language with all of the features that modern languages should have. Surely that's less effort, and time better spent, that trying to maintain backwards compat. with perl 5. I mean, what can't you do with perl 5 now? Will perl 6 attract a single non perl user that perl 5 wouldn't have attracted? I'm sure perl 6 will be a great language, and a great monument to something, rather like
"My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!"
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.
development.lombardi.com
Apocalypse is the English transliteration of hapokalu[psi]is [3] . hApo [3] is a very common preposition meaning something like away from or off; and kalu[psi]is [3] is formed from the root, kaluptw [6] [3] , meaning cover, or veil. So, "unveiling" is acceptable. The only problem is that "unveil" is a term not used very generically in English, it has strong literal connotations. That makes it good for poetic imagery; but the original Koine Greek was probably not intended to specifically evoke that particular image.
Herodotus used hapokaluptw as uncover; Plato as disclose or reveal; and Plutarch as reveal one's whole mind, which I think is closer to what we're looking for here.
As to your two points....
The first is a bit strange. It's trivially true, as Revelations says as much in the first verse. As to Mark 13:32, it only indicates that Christ was unaware of the exact date, not the events. Indeed, Christ seems to be aware of some of the events in Mark 13:32. Also, of course, it's contestable that what Christ is describing in Mark 13 is the same thing as what is being described in Revelations. At any rate, yes, the revelation is to Christ, who then passes it along to John; and so in that sense it's quite correct to say that the revelation is to John. Your insistence that the revelations is "really" to Christ is either niggling or important. If it's important, then it's only important in your contestable interpretation of Revelations and the NT as a whole. Similarly, your second point is also quite dubious, as hev taxei [3] is in most cases in the NT unambiguously translated as "soon" rather than "fast". Here are all the incidents of hev taxei in the New Testament. It's also quite a stretch to claim that the writer of this book is keen on specifically mentioning that the events described take place quickly right there in the first sentence. It's far more sensible to interpret this as "revelation of events to come soon"; and, furthermore, the narrative that follows describes a sequence of events that are not particularly brief. In other words, pushing the "rapidly" translation is a function of an interpretation which attempts to reconcile this with the historical fact that these events did not seem to happen "soon". Which brings me to another point.As someone who studied Homeric and Attic Greek before Koine Greek [5] , I have a greater familiarity with Greek than the average layperson or non-academic who has studied the NT in Greek as a part of their bible studies. My sister, for example, is an evangelical minister and missionary; and although her understanding of Greek has improved over time, it is still enormously tainted by doctrinal teachings of Koine Greek biased towards a particular interpretation of the NT. As a result, I am very skeptical of many fundamentalist's "translations" of the NT.
Finally, I am not at all offended by your post or the fact that you're Christian - as I noted, Larry Wall is a devout Christian and your post is marginally on-topic. But please don't assume that the sets of people that are offended by Christians and atheists are mutually exhaustive. They are not. I am an atheist. I also know a great deal more about Christianity than most Christians I've met. Stereotypes are not helpful.
[1] Here is the beginning of Revelations in Greek.
[2] There used to be a second footnote. Now it's gone. It involved how to display the Greek characters I originally tried to use that I eventually discovered that /.'s preview would accept, but that the submit would not. Sigh. (Addendum: it was a different problem.)
[3] These are Latin character transliteration. We don't have a psi. Upsilon typically changes to "y" in English rather than "u" because the vowel "y" is actually closer to the presumed pronunciation. Kappa often becomes "c". Nu ["v" in my transliterations] becomes the English "n". The "w" is an omega, a long "o".)
[4] Wish I could force Unicode in this post, somehow. Ironic since one of the biggest justifications for Wall's mods to regex is that 8-bit character classes are now archaic.
[5] Koine Greek is much simpler than Homeric or Attic Greek. The New Testament was actually written in Koine Greek because it was the common language of the region. The original words, however, were probably mostly spoken in Hebrew and Aramaic. I should make it clear that I studied Greek more than ten years ago and sadly now all of my facility with it has completely evaporated. This post was constructed with frequent consultations with my Liddell & Scott. YMMV. It's also worth noting that Wall is a trained linguist as well as a studious Christian, so he means exactly what he's saying when he uses the word apocalypse.
[6] Thus, Homer's "Calypso", the nymph who hid.
The reason that perl is successful is because it's useful. Only time will tell if people think perl6 is useful. If they do, they'll use it; if not, they'll stick to perl5.
Ob regex troll: I think the new regex handling kicks major ass. The new regexes have been promoted to true first-class variables, cleaning up a lot of messy syntactical issues. In addition, everyone who says it's not backwards compatible, well you're right. That's because the current regex libraries SUCK in comparison to the features offered by perl6. That's right, they SUCK, and it would be impossible to be backwards compatible with all the new (useful) features that have been added. If you don't believe the new syntax useful, try backtracking a 100,000 character repetitive string only to discover that the 15th matched number is too large or too small. Now think <{ ... }>.
This post expresses my opinion, not that of my employer. And yes, IAAL.
I've read every Apocalypse, Exegesis and, err, "Synopsis" (why the namechange?) so far. Almost everything I've read so far has seemed like a good idea. I've personally run into quite a few of the exact issues they're attempting to solve with these changes. Regexps are just as problematic as the rest of it, and I agree with the changes. And since they're ensuring reverse compatibility with every aspect (usually via a flag), even if I didn't like a particular aspect, I wouldn't have to use it.
Frankly, I'm looking forward to it. Parrot is nice, and if it weren't for the memory management issues from string-scalar registers, I'd be seriously looking into implementing it in hardware, but its still not too impressive without the Perl6 parser. So I'm waiting patiently, but I feel it'll be well worth it.
The changes may seem like a lot, but far more will actually be staying the same. Perl's already by far the easiest language for me to implement things in (and I've given basically everything a good try), and it seems as if this batch of changes will solve the few remaining rough areas. Except the learning curve - I think BASIC (for initial concepts) and Pike (for C syntax and functional structure) still have it beaten in that area. Still, it's kinda funny how many apparent perl-haters (old perl and new perl) there are, posting to a forum thats, err, written in Perl =)
Paranoid
Bwaahahahahaa.
Java gets translated into byte code, and the byte code gets translated into machine code. The machine code is then executed. C++ isn't involved in the execution at all.
Think of it this way: the JIT compiler is like someone who gives you directions. How fast you get to your destination doesn't depend on what kind of car the guy giving you directions has, but it depends on how fast your car is and how good the directions are.
No, it isn't. I made a specific claim about execution speed.
While I've done no Java work
So, what do you base your opinions on, then? I use both Java and C++ for my work.
more than edify the reader...
Your edification is your own responsibility; you can hardly expect a free education from Slashdot. What you can get, however, is people challenging your assumptions and sharing their own experience. And my experience is that, properly used, Java can be nearly as fast as C++ for compute-intensive stuff, and it can be a lot more responsive and a lot less resource intensive than a C++ GUI environment. Think for yourself. Think about why Windows and Gnome/KDE are so huge. Try to find some fast Java apps and pick them apart. Etc.
For your sake, I hope you're trolling. Who are "you"? (A script kiddie?)
... or a truly object-oriented model.
"I" am the author of numerous Perl modules and a contributor to various Perl-related publications and a professional Perl hacker. Not that it matters.
Perl is not the language of choice for anything. The reasons are almost too numerous to count.
The reasons that every language is not ideal are almost too numerous to count. Perl just happens to have a lot more going in its favor than most.
Hope you didn't need to edit that program of yours, fella!
I have no problem editing my Perl. In fact, my co-workers have no problem (except where I use features like the C-library interface or complex process control that would be difficult for others no matter what language you were using). Modules are a huge advantage for programming in the large.
Perl does not offer strong typing
Very true. Also a benefit. I would suggest that only LISP rivals Perl for the availability of truely generic data types.
It depends on how you mean that. It does not offer a strong OO model, in the sense that Perl5's object model is fairly loose. This reflects the state of OO when Perl5 was written. C++ was young and seemed to be a poor model, but it was the one most people were paying attention to. Java did not exist. Smalltalk was nice, but no one wanted to think that way any more.
Now, Java has had its impact (I think Java's OO model is rather nice, though it has many problems that stem from its typing model) and other high-level languages like Ruby, Python, Eiffel, etc have changed the way we think about OO programming. It is now time for Perl to come in and do what it does best: deconstruct the best practices and adopt them as its own. This is one of the many things you have to look forward to in Perl6!
Hope you didn't need to write more than 100 lines... because it will turn into mush.
Counter-examples: LWP, PDL and many, many... MANY projects I have worked on alone or with others. PDL (Perl Data Language) is a prime example as it shows Perls ability to bring other components together. PDL is made up of Perl, Fortran and C. It offers one of the most complete scientific data languages available with high-performance transformations on low-level data such as binary streams, images, etc.
Also keep in mind that because of very-high-level complex datastructure handling, Perl makes it possible to write LESS code than most other languages.
The one thing that perl does reasonably well is operate on text files.
Spoken like someone who doesn't use Perl in the large. The one thing Perl does well is just about everything. Check out CPAN (the other MAJOR reason to use Perl).
But there are many other languages (awk, sed, Python, and bash scripting spring to mind)
If you think of Perl as being on the same level of usefulness as Bash, then I'm not suprised you've never made use of it. I'm sorry.
And anyway, who would consider scripting on the same level as programming anyway?
And who would consider Perl to be a language only capable of "scripting"? Scripts are traditionally run-time interpreted (Perl is compiled into a syntax tree, optimized and then exectued just like many other high-level languages). They also lack complex data types (Perl programs routinely create very complex arbitrarily deep datastructures casually; lists of hashes of lists of objects are quite common and easy to create in a couple of lines of code). Scripts are also hard to debug; Perl comes with a built-in symbolic debugger.
Learn the language; you may be suprised.
Umm, TCL was not designed for GUI scripting. John Ousterhout desinged TCL in the spring of 1988 as a generic command language, to replace the command languages for various different tools used mainly for integrated circuit design. It had nothing to do with any sort of GUI whatsoever.
Tk was spawned out of his frustration with Apple's HyperCard system and his belief that a "shared scripting language" could provide the glue to tie together components that a small group such as a university research team could build up over time. Plus, I personally suspect, his desire to reuse Tcl for more than its original design.
Pick up "Tcl and the TK Toolkit" by John K. Ousterhout published by Addison-Wesley. The info above is gleaned from page xvii, the first page of the preface...
In any case, the reason why systems written in languages like Java are often much more efficient than systems written in C/C++ is not because Java can be compiled well (which it can) but because Java is safe. In something like Gnome or KDE, every single desk accessory is its own process, using some inefficient IPC or DO mechanism for communicating with the rest of the system. In something like Java, all those can run in the same process and just pass data structures. Using C++ for such applications is penny-wise and pound-foolish; the resulting software systems are ridiculously inefficient.
C and C++ have their uses and they are great languages for some problems. But 95% of all C/C++ applications would be faster, smaller, and work better if they were written in something else.