«

> 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

http://www.geocities.com/opalpaweb/

Patrick May <> wrote in
news::

>
> 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

"Michael Redlich" <> wrote in message
news: oups.com...
>
> 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

> 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

http://www.geocities.com/opalpaweb/

Matt Garrish wrote:
>
> 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...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/)

>>>>> "MR" == Michael Redlich <> writes:

MR> Matt Garrish wrote:

>> 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.

MR> Matt:

MR> PERL - Practical Extraction and Report Language

MR> This is direct from
MR> http://www.cs.cmu.edu/afs/cs.cmu.edu...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

--
Uri Guttman ------ -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

"Michael Redlich" <> wrote in message
news: oups.com...
>
> Matt Garrish wrote:
>>
>> 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.
>>
>
> PERL - Practical Extraction and Report Language
>

Perl is not an acronym.

http://perldoc.perl.org/perlfaq1.html#What's-the-difference-between-%22perl%22-and-%22Perl%22%3f

> This is direct from
> http://www.cs.cmu.edu/afs/cs.cmu.edu...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

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

http://www.geocities.com/opalpaweb/

> 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

http://www.geocities.com/opalpaweb/

<> wrote in message
news: ups.com...
> 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