|
in reply to Perl and Java
The disclaimer is that I wrote Java at a Fortune 500 company colloquially known by two initials before I discovered Perl and struck out to find riches on my own.
I've worked with both. I have done much more with Perl than with Java.
A competent programmer will be able to code in either.
A competent Java programmer will be able to write cross platform code, if your idea of platform compatibility ranges from both Win32 to Solaris. Bill Joy himself help you if you want to write an applet. (This seems to be less popular with Sun's marketing department these days.)
The nice thing about Perl, when it comes to a portability standpoint, is that the people who write it make sure it work on other platforms. Even better, for those platforms on which it's too odious for us mere mortals to attempt to program, there are crazy people like Ilya and even companies like ActiveState and Indigo that make sure the main distribution compiles on exotic platforms like VMS and Windows.
With Java, if you're not Solaris or Win32, you're second class. (No offense towards either Blackdown or kaffe, who are doing fine work in a difficult situation.) Sun's not interested in portability that helps anyone but Sun.
Perl, of course, suffers no such market-dominating constraints.
Update: mothra is quite correct that Perl does favor Unixy systems... but at least there's an officially blessed binary available for just about any platform on which Perl runs, which is not the case with Java. (I danced around that point slightly.) |
Re: Re: Perl and Java
by mothra (Hermit) on Apr 02, 2001 at 18:41 UTC
|
With Java, if you're not Solaris or Win32, you're second class.
Yes, and with Perl, if you're not in Unix or Linux, you're second class! I don't even like Java (far.too.wordy.for.me), but let's not pretend that Perl doesn't heavily favour certain platforms as well.
Certainly Perl's favoritism isn't such that it won't even compile on Win32 systems, but there's no question that most production Perl scripts are running on Unix and Linux servers, that most documentation has a heavy Unix flavor to it (ie. refer to manpage foo for more info...), and that most CPAN modules only make the promise of having worked on some flavor of Unix.
By the way (and this is no longer specifically related to what chromatic was saying), but we can we waste slightly MORE time comparing language XYZ to Perl?
| [reply] |
|
|
Being someone who codes almost exclusively for Win32 systems these days, I'd have to disagree. The quality of the Win32 modules does not reek of a second class effort.As for scripts that have already been written, I might point out that perl wasn't always an easy issue with Win32 systems. If a script was written in the past, it was written for Unix. Recently, I've just started paying attention to the last time the script was edited. Relatively new scripts run on Win32 in many cases. I think with time these old scripts can be ported (a good way to spend time if this really bothers you that much) and that the perl community will learn better methods for writing multi-platform code.
| [reply] |
|
|
Yes, and with Perl, if you're not in Unix or Linux, you're second class! I don't even like Java (far.too.wordy.for.me), but let's not pretend that Perl doesn't heavily favour certain platforms as well.
I think you have that backwards. Unix-type users tend to favor languages like Perl for more heavy-duty programming than to Windows users because of their background (mainly because of sh). They're used to writing short little shell scripts as well as longer more complex C programs, and Perl is heavily endowed with both. Thus, you see more Perl usage on Unix systems. The language itself isn't really specific to, either, though. The Win32 support is actually on par or better than the Unix support (note the number of well-written, Windows-only modules on CPAN). It's just not as heavily used because the background of my Windows programmers is not scripted/interpreted languages. It's .exe files and the C++ source that underlies them. Java is the natural extension of that.
| [reply] |
|
|
There's no magic as to why Perl isn't used on Windows in any way remotely comparable to VB or VC++. a.) VB and VC++ have big marketing campaigns, b.) there's a somewhat reasonable perception that VB and VC++ are much more suitable to developing large "native-looking" GUI's than Perl (of course, VB for RAD, VC++ for the "more serious stuff"), c.) it's easier to find people (especially Microsoft) to whom you can pay money for technical support.
There are some tasks to which Perl isn't suitable, and one of them is definitely writing large GUI's, and even if Tk were satisfactory for this, it's too ugly to sell to the average consumer, who wants a more eye-candyish interface that the somewhat amateurish look of Tk. This might sound a little harsh, but then again, all you have to do is take a look at how many off-the-shelf programs you can buy that are developed for Windows, using Perl/Tk. There must be a very, very small handful, but I sure as heck don't know of any. Of course, there's also the Win32::GUI module, which I've experimented with, and won't consider for writing large GUI programs anytime soon!
And, from my perspective, Perl just doesn't feel like Windows. Unix users have seen other scripting lang's with $'s and @'s in them...this is a foreign concept to DOS/Windows programmers (forgetting about @echo off :). Regexp's, of course one of Perl's larger selling points, while useful sometimes, are almost never needed in GUI programming. Perhaps they might make validating data slightly easier (sometimes), but a lot of GUI programs do the same thing (in varying levels of complexity): Read data in, have the user modify it, spit it back out to the database. Often times (like in Powerbuilder's datawindow control), the data validation is simply a property of the control (ie. specifying a certain "edit mask"): no coding necessary.
Now, of course, it's very easy to dismiss this as "nonsense", and that Perl is "well-suited" to GUI programming. Please, feel free to point out programs that are done this way, and making money (or even being used by a lot of people). It's easy to discuss the "theory" that Perl is good for making GUI's, but my experience is that in practice, Perl will not be used for this purpose (often) anytime soon.
| [reply] |
|
|
