roxen is written in pike, so this means that pike integrates php and java, and will integrate perl...
can you see the trend?
in the end we will have
pike integrating php, java, perl, phyton,...
phyton integrating perl, php, java, pike,...
php integrating perl, java, pike, phyton,...
java integrating pike, php, pyton, perl,...
if this is followed through then the language that integrates the most other languages will succeed, or not?
come on guys, what is the point?
is every languagegroup here afraid that they can't survive against the other languages?
wait, i am doing the language-advocates injustice, it is the appdevelopers that are afraid that their app won't survive without support for every scripting language on earth.
zope is adding the perl support...
and it was the roxen-users (and the company selling roxen) that asked for php, perl and java.
but is that necessary?
your app already has a scripting language, use it!
What we're seeing here is the hardest possible way towards language interoperability. In the long run, the number of languages in use will grow, and the number of interfaces that have to be maintained this way grows quadratically with the number of languages that interoperate.
In contrast, with language interoperability approaches like CORBA or COM, there's only one interface per language to maintain, which makes life for everybody involved much easier. And the often-heard argument of performance doesn't seem to matter to users of scripting languages anyways.
Besides, Dylan will win the language war :-).
all languages can do mostly-the-same things, and can all be convinced to talk to one another with some work. deciding which you use (or "support" in corporatese) is a cultural choice, and having a cross-language bridge does not change this fact. bridging zope with perl doesn't alter the universe of perl or python people one iota. it's just a bridge. if it had been a bridge between 2 python programs you wouldn't bat an eyelash.
but they are not necessarily talking to each other.
they are one binary that understands more than one syntax of source.
i agree with andreas here, it is nothing that couldn't be solved with corba/com/rpc of some kind.
Just because an app is written in Python doesn't mean that it's not a well written useful app that people who are super familiar with Perl shouldn't be able to use. Many people areunreasonably adamant about their language of choice. But it is often justifiable. Rather than having to know several languages reasonably-well to use the apps out there, they can know one super-well and still use the apps out there.
Right now we tend to see app A written in language X, followed by people using language Y going and writing their own version of the app in their own language and calling it B rather than using app A. Then you have wars between the people writing things for A and B having to implement the same thing in different languages. It is nicer to see people use tools because they're good, not because they're based on their favorite language. [Granted, I also think a little competition is nice for product development, but not when the competition is solely "my language is better than yours"]
Script languages are "real" computer languages. The same holds true for many specialisted languages. Consider for instance extension languages and glueing languages. Myriads of languages which are useful. Some insight can be gained by looking at the mails called the The Tcl War.
Richard M. Stallman saw the problem in 1994 in the realm of extension languages. He wrote about lessons learned from emacs lisp and tcl. He proposed Guile. We all know that guile has not really taken the place Stallman envisoned yet. So it was not the complete solution. On the other hand I also do not think distributed object mechanisms like CORBA or SOAP will help.
There is the point that the first thing every scripting language appears to realize is that they need to interoperate with Perl.
No, this article isn't apocalyptic in nature. I think that all of this interoperability between programming languages is a good thing. Yes, in the short term it means that there are just more languages for programmers to learn, but I think this is a necessary phase.
When Larry Wall started writing Perl, he looked at what was already out there, pulled the good (in his subjective opinion) points from each language and combined them in a way that made sense to him. Amazingly, this thing called Perl made sense to lots of other people as well. When Guido van Rossum started writing Python he used a similar process but his criteria for "goodness" were radically different. Thus we have two programming languages that (IMHO) fill much the same niche but each having large followings of people that are largely distinct (i.e., There don't appear to be many people with a foot in the Perl camp and a foot in the Python camp)
All this means is that Computing Science is still young. We haven't had enough time to come up with formal consistent "goodness" rules as a community. Or maybe we have and they are so diverse that we don't know how to reconcile them yet. Thus we have Perl communities, Python communities, Java communities, etc. and all are realizing that they'll have to interoperate at some level. "I need my whiz-bang application to work with Company Q's neat-o application, but their application is written in perl, mine is written in python, and I don't want to learn perl to make this happen"
So, what do I think will happen? Glad you asked! :-) Many of these programming languages overlap in functionality and ability (yes, I know that they are all probably turing equivalent, but we're talking about ease of use here). So after this explosion of programming languages we'll see evolution take over. Those languages that are useful will be used and those that aren't will die (this is the collapse part). The languages that survive will define our "goodness" rules for the next generation of great ideas. It may be that we will have some clear champions of goodness that then become iconic. We may have a new classification of language families much like functional, logical, procedural but more along the lines of design philosophy rather than capability (I envision programming languages of the future to be polyparadigmatic and such distinctions as functional or procedural will be meaningless)
(thank you for pointing me to the tcl war)
allow me to cite Barry Merriman:
III.i like this argument, as it described what i partly felt when i wrote my original rant.we [ GNU Project] want to provide two languages, similar in semantics but with different syntaxes. One will be Lisp-like...As for the dual language solution, III: This does not seem like a good solution to me! Two language with the same capabilities but vastly different syntaxes??? It seems like the natural evolution of such a system will be that either one language or the other will greatly dominate in use---which defeats the purpose of having two, since one becomes the defacto standard---or most projects will be written in bits and pieces of both, which just means everyone has to know all of them, and constantly switch back and forth between different languages that do nearly the same thing
take a look at Roxen.
java support in roxen goes so far, that i can write roxen-modules in java, and make use of other roxen modules in pike from my java modules and vice versa.
this allows for (1), as i can choose in which language to write. however it will also force me to learn both languages if i ever want to debug something, since a bug could be on either side. that in itself is maybe not so bad, it's always good to learn more, but while working i'll have to constantly switch back and forth...
now look at the other side:
it's php4 support is there to allow you to serve existing php projects with a roxen server, mostly to make it easier to move your site to use roxen instead of apache.
there is no interoperability between pike and php4. i can not make use of pike functions in php or vice versa. this pretty much limits the use of php in pike to (2).
the same could probably achived by having a standalone php binary that takes requests through a roxen module, and sends the answers back.
granted there would be some drawbacks: i'd need to run and maintain a
second process, the processes would need to communicate, and this might
on the other hand, the processes could not disturb each other (since pike and php don't seem to be able to take advantage of each other, i the best case the resulting binary will run just fine, but there is no advantage for the added risk (although i don't see any risk in this case, as the guy who wrote the integration does some good work))
and, building a good rpc interface between the two apps, will make it so much easier to add interoperability with a third app, written in yet another language, and a fourth, and so on, each keeps it's seperate little universe, probably scales a lot better, and gives me a more robust package alltogether...
As Andreas says, this is pretty much solved in COM with IDispatch - You only need to maintain one thing for each scripting language. This is used in windows scripting host & ASP.
I'm hoping someone a lot cleverer than me will sort out a Bonobo::Dispatch interface for bonobo, so we can script our bonobo components in whatever language we like.. with no IDL pain. Hopefully also some kind of Bonobo based web platform will emerge sooner or later. Its not fun to have to deal with multiple component systems for no real reason.
This is something that MS is doing a lot of good stuff on - ILOVEYOU and Melissa excluded!
It is not likely that a Bonobo::Dispatch interface will be added to bonobo. By my understanding, this functionality is provided in CORBA by the interface repository and dynamic invocation interface (CORBA::Request::invoke and friends). This is what you would use to write stubless language bindings for a CORBA ORB. I believe ORBit implements DII but doesn't have a working interface repository yet.
This is an interesting discussion.
When the original announce was commented on comp.lang.ruby(1), some said it was not a good idea, because of ActiveState links with Microsoft and other similar issues. Nobody protested for the added functionality.
(1) comp.lang.ruby is a newly created USENet group about a programming laguage called Ruby, which comes from Japan with strength (calculated user base of Ruby is bigger than user base of Python) (see Ruby Language Home Page for more info.) IMO it's a very nice language which will be pretty famous in the future...
I think that's because people like variety. It's not just that people likes or dislikes this language or that language... but there are a couple of them that makes it easier for them to think about what they are programming, and they do program better as a result...
Thus allowing many languages to interact with your application will only make your application available to a wider user base... "Why should I learn Java if I already know Perl?" someone may ask, with reason, as Perl and Java a very different. The interrelation between your application, its language and another one it's only a matter of convenience... Java is the hype of the moment, and so many people wants to interact with Java... Python is written in java as well, for the JMV (it's called JPython in opposition to CPython or 'normal' one), and so Python can also by used, as it spits JMV bytecodes as well... or not? If not, it's probably because the developers were thinking about java as language specifically...
I personally find strongly (static) typed languages very rigid for fast development, like scripting may be... if I had to interact with an application (a word processor?) I'd prefer a weaked (dynamically) typed language... MS Word is written in C++ and COM, but the scripting is done in VBScript (or VBA) for a reason...
Like our favorite pointy-eared Vulcan friend would say "Infinite Diversity in Infinite Combinations", I like that...
I see intergration of a variety of programming languages in one programming space, as they being able to use each other innards (functions, objects, etc.) seamlessly. I have in mind Java and JPython (wich Excalibor referred to above). This is not necessarily bad, although I know that eMBee is pushing it a bit to show that if this gets out of control it will be silly, because a do-all language will be gigantic (ADA anyone?, just read about did not have to use it, fortunately I think). In my simple experience I use what I need, be it awk, Python, Java, C or PHP (the ones I know more or less well). Too much integration will be counterproducent.
What I am more interested is in interoperation, i.e. being able to pass info back and forth among dissimilar languages, applications or systems. Would something like XML-RPC help? I think that it will, because in principle passes information that is easily parsable, and should not suffer from problems that binary encoded data would. Of course it will use more bandwith. CORBA and COM look intersting for solving the interoperation problem too, although I am a little partial to XML, if only because CML does a very good job at representing chemical structures.
In summary: I am all for for extreme interoperation, I am very doubtuful about extreme integration.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!