Java sucks, Perl Rules.

[opalpa]

You're making my point for me: Java is more verbose.

You were disagreeing with a statement I made, then I replied with a
clarification as you appeared not to comprehend the statement. That is
when you started off with "This is not the case." it sure seems you
were disagreeing with a point I stated. I was making a practical
point: the amount of typing for Java is not a burden.

If you spent the same amount of time adjusting your editing style
for Perl, for example, is there any reason why you wouldn't see a
similar reduction in the amount of typing required to deliver similar
functionality?

Similar reduction? Percentage wise? Yes, here are two reasons: a) the
concepts are about the same b) java has better examples available
freely on the internet to incorporate.

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[zero]

You're making my point for me: Java is more verbose. The fact
that you've come up with techniques to avoid some of the negative
consequences of that verbosity indicates just how bad the situation
is.

Perhaps I'm being pedantic, but I think it's very important to make the
distinction between the Java programming language, and the Java API.
The Java programming language, like most any other language, has a very
limited number of keywords and language constructs. The API on the
other hand has a lot of packages, libraries, classes and methods. I
completely agree that some of the names used in the API are too long.
This may enhance readability, but it can hamper it at the same time by
making lines too long to fit on screen.

Anyway, to compare the verbosity of two languages you have to either
compare the language constructs and keywords of each, or compare API
libraries that have the same purpose. As an example, it is possible to
compare the traditional C/C++ for loop with Java's enhanced for-each
loop, and say that in that particular case, Java is shorter. On the
other hand one cannot say that creating a window/frame in Java is
shorter or longer than in C++, simply because there is no standard C++
library for creating windows. You could compare creating frames in the
Java API with creating windows in the Win32 API, in which case Java is a
lot shorter. But note that you would not be comparing languages, but
APIs.

In this type of discussion it is always presumed that Java is the
combination of the language and the API. This is completely inaccurate.
Theoretically it is very possible to create a completely different API
that is completely conform to the Java language specification. And even
in practice there are different (although related) Java APIs - the J2SE
API, JME, JavaMail, etc.

I have never studied Perl, so I don't know how verbose it is. What I do
know is that comparing programming languages is, in most cases,
nonsensical - and all the more so if the distinction between the
language and the libraries is not made.

As a final note, it shouldn't matter how verbose a language or an API is
(within reason of course). Programming is not typing, no more than
playing chess is the physical action of moving a piece.

Zero

 

[Matt Garrish]

Perl is simply an excellent tool for extracting information
from files using regular expressions. We all know what can be
developed using Java.

Wow, that has to be one of the stupidest assessments of Perl I've ever read.
I would suggest you go back to discussing Java, because it appears you know
little else.

Matt

 

[opalpa]

Wow, that has to be one of the stupidest assessments of Perl I've ever read.
I would suggest you go back to discussing Java, because it appears you know
little else.

Michale's is not the whole picture of perl, missing much of the
variety, but stupidest you've ever read? That's harsh; especially
since you don't add anything positive. Anyway, I'm bailing on this
thread. Good day to all.

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Michael Redlich]

Wow, that has to be one of the stupidest assessments of Perl I've ever read.
I would suggest you go back to discussing Java, because it appears you know
little else.

Matt:

PERL - Practical Extraction and Report Language

This is direct from
http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/rgs/pl-intro.html:

"Perl is an interpreted language optimized for scanning arbitrary text
files, extracting information from those text files, and printing
reports based on that information. It's also a good language for many
system management tasks. The language is intended to be practical (easy
to use, efficient, complete) rather than beautiful (tiny, elegant,
minimal). It combines (in the author's opinion, anyway) some of the
best features of C, sed, awk, and sh, so people familiar with those
languages should have little difficulty with it. (Language historians
will also note some vestiges of csh, Pascal, and even BASIC-PLUS.)
Expression syntax corresponds quite closely to C expression syntax.
Unlike most Unix utilities, perl does not arbitrarily limit the size of
your data -- if you've got the memory, perl can slurp in your whole
file as a single string. Recursion is of unlimited depth. And the hash
tables used by associative arrays grow as necessary to prevent degraded
performance. Perl uses sophisticated pattern matching techniques to
scan large amounts of data very quickly. Although optimized for
scanning text, perl can also deal with binary data, and can make dbm
files look like associative arrays (where dbm is available). Setuid
perl scripts are safer than C programs through a dataflow tracing
mechanism which prevents many stupid security holes. If you have a
problem that would ordinarily use sed or awk or sh, but it exceeds
their capabilities or must run a little faster, and you don't want to
write the silly thing in C, then perl may be for you. There are also
translators to turn your sed and awk scripts into perl scripts. OK,
enough hype."

OK, so shoot me for giving an abstract overview of Perl. But I believe
that I highlighted the main point about the language, don't you think?.

So, I would suggest that you should consider thinking *twice* before
criticizing...

Mike.

--- ACGNJ Java Users Group (http://www.javasig.org/)

 

[Uri Guttman]

MR> Matt:

MR> PERL - Practical Extraction and Report Language

MR> This is direct from
MR> http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/rgs/pl-intro.html:

MR> OK, so shoot me for giving an abstract overview of Perl. But I believe
MR> that I highlighted the main point about the language, don't you think?.

no, you didn't. but what do you know about perl? finding poor
descriptions on the web isn't knowing perl. BZZZT! try again.

MR> So, I would suggest that you should consider thinking *twice* before
MR> criticizing...

pot, meet kettle.

have a good time in java where you belong. you are obviously not mature
enough for perl.

my lang can outcode your lang! NYAH! NYAH! NYAH!!!

this thread has to die already.

uri

 

[Matt Garrish]

PERL - Practical Extraction and Report Language

Perl is not an acronym.

http://perldoc.perl.org/perlfaq1.html#What's-the-difference-between-"perl"-and-"Perl"?

This is direct from
http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/rgs/pl-intro.html:

Ahh, a quick Google for Perl 4 info. That's convincing.

OK, so shoot me for giving an abstract overview of Perl. But I believe
that I highlighted the main point about the language, don't you think?.

So, I would suggest that you should consider thinking *twice* before
criticizing...

The main point of the language? Text extraction and processing with regular
expressions is such a tiny component of the language it's laughable that you
continue to think you're somehow in the right. There is no text extraction
by regular expressions for all the sys admin work you can do with Perl, none
for all the database work, XML (unless your robic0, for those who follow
clpm), dynamic web generation, bioinformatics, and on and on. As I said, if
all you know is Java please stick to it and save us your uninformed and
over-arching statements about other languages.

Matt

 

[opalpa]

Personally having used regular expressions for text extraction in a sys
admin context and database work and dynamic web page generation, I
assure other folks reading this thread Matt is incorrect in his
assertions.

In a sys admin context one example is when I extracted timezone
information from a text file where it was stored.

In a dynamic web page generation context I extracted connections
history and sent out html.

In a database context I used perl to re-engineer schemas on some very
large databases using regular expressions all over.

I haven't touched XML with perl and I haven't touched bioinformatics
with perl, but so far, Matt, you are 0 for 3.

Is your vituperative attitude popular among perl fans?

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[opalpa]

no, you didn't. but what do you know about perl?

Micheal, having evidenced some information, as compared to 0 from you,
currently appears to know infinitly more than you.

Cheers.

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Matt Garrish]

Personally having used regular expressions for text extraction in a sys
admin context and database work and dynamic web page generation, I
assure other folks reading this thread Matt is incorrect in his
assertions.

I suspect I've used Perl a lot more and a lot longer than you. You aren't
convincing anyone with the ridiculous examples you provided that Perl is all
about regular expression parsing. Anyone who actually knows Perl knows who
the fool is here. I don't need to keep my own count.

Matt

 

[Uri Guttman]

ocofo> Micheal, having evidenced some information, as compared to 0 from you,
ocofo> currently appears to know infinitly more than you.

evidence?! i don't need no steekin' evidence!!

perl is used for so much more than text processing. it just happens to
be the best text processing lang out there. you are like those kiddies
who think perl is only used for cgi since it was the most popular cgi
lang for years. that is typical of limited understanding of perl.

take a look at cpan sometime. tell me what percentage of those modules
are only for text processing. seems to be stuff in every conceivable
technical field. i call that solid evidence. but i don't know if i can
find the proper glasses for you so you can see it. so stop with the FUD
about perl being a text oriented lang. it is such bullshit.

uri

 

[opalpa]

I suspect I've used Perl a lot more and a lot longer than you.

Maybe. Ten years here, on and off.

You aren't convincing anyone with the ridiculous examples you
provided

Ridiculous? Hardly. I'm pleased with what will be recorded for
posterity.

that Perl is all about regular expression parsing.

In previous post I stated there is variaty to perl. Processing text,
using regular expressions, is common.


Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[opalpa]

I've been to CPAN many times. I like the variaty -- used MQ Series
stuff from CPAN, used various time/date libraries from CPAN, FTP libs,
etc. Yes, big variaty, I've stated this multiple times in this thread.

tell me what percentage of those modules are only for text processing.

A lot less than the percentage of those modules that are used in
programs which in part process text, using regular expressions.

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Randal L. Schwartz]

opalpa@gmail> A lot less than the percentage of those modules that are used in
opalpa@gmail> programs which in part process text, using regular expressions.

Can't believe I'm getting sucked in to this, but...

That's like saying Java is about *multiplication*.

"Look how many Java programs perform multiplication! Nearly all of them!"

And your point?

 

[Matt Garrish]

In previous post I stated there is variaty to perl. Processing text,
using regular expressions, is common.

Then why are you jumping in here to defend the claim that that is all Perl
is? Your examples are ridiculous because they're so limited to you. Did you
stop and consider that few admin tasks that can be done in Perl ever need
regex processing? That few database applications need regex processing? That
few web pages or web tools that can be written in Perl ever need regex
processing? As Uri tried to explain to you, it's a lot of FUD.

Out of curiosity, though, because I can write regexes in Java, and often
process text when I write Java programs, does that make Java simply a text
processing language? Who cares what anyone else does with the language; my
experience supersedes all. Beginning to see why defending a fool makes you
look like a fool?

There is no such English word as variaty, by the way.

Matt

 

[Matt Garrish]

opalpa@gmail> A lot less than the percentage of those modules that are
used in
opalpa@gmail> programs which in part process text, using regular
expressions.

Can't believe I'm getting sucked in to this, but...

I know. I shouldn't have gotten sucked in by the idiocy of the original
comment, but such gross over-simplifications are an anathema to me... : )

Matt

 

[opalpa]

page x, preface, "Programming Perl, 2nd edition", (dated stuff, yes,
part of the point coming):

"The hitherto well-kept secret is now out: Perl is no longer just for
text processing."

You thought Perl was for more than text processing in 1996. The "no
longer" implies there was a time before then when you thought it was
"just for text processing".

Let's compare what percentage of Java programs use regular expressions
and what percentage of Perl programs use regular expressions. By the
java code I've got available I see less than 1% of Java sources using
regular expressions. I'm having a hard time thinking of a grep to
identify which perl code uses regular expressions. Let's approach this
a little more intuitively:

Say you wrote a program to categorize newsgroup posts and had yourself
features for each newsgroup post. If for a particular message a
"regular expression" feature was present that would be more strongly
correlated with a perl newsgroup than a java newsgroup. Same for a
"text processing" feature.

The point is multipart:a) although you have long accepted Perl to be
more than text processing and regular expressions that opinion spreads
slowely, b) the label "stupidest assessments of Perl I've ever read"
was perhaps the poster dating himself and not knowing that you held a
similar opinion prior to 1996.

For those who don't know: Mr. Schwartz was one of the authors of
"Programming Perl 2nd edition". Useful book.

All the best.

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[opalpa]

Matt Garrish first wrote: "There is no text extraction by regular
expressions for all the sys admin work you can do with Perl.."

Matt Garrish later wrote: "few admin tasks that can be done in Perl
ever need regex processing?"

You're more accurate now.

There is no such English word as variaty, by the way.

I admint I'm not prickly about spelling. Glancing over posts today
I've spelled that word inconsistantly. I'm a perfectionist about code
not about newsgroup spelling.

Take care.

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Uri Guttman]

s/Opalinski/fool/ ;

there is a great use of regexes in perl. let's see how fast you can code
that in java!

your conflation of tools used and the purposes of programs is
boggling. would using a regex in bioperl to process gene data mean that
that work is just plain text processing? or parsing XML? or writing
internet protocols? you don't get the difference between a popular and
powerful feature of a language and the goals of a particular
program. given such a lack of discriminating logic, as i said before
please stick to java. it needs more coders like you.

just let it go. you will never understand perl or anything beyond your
little java applet world. and don't come back with some balderdash about
my not knowing other langs and such as i could swat you like a fly in
too many langs.

and back to the mature part of this useless thread. you ain't a perl
hacker and we are glad! NYAH!! NYAHH! NYAHH!!

<one day those nyahs will finally be understood by you. i won't hold my
breath. now go away before even the java groups start thinking of you as
a fool.>

uri

 

[opalpa]

lol.

bye.

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/