I was wondering what kinds of arguments against other
languages the Perl people usually use in office arguments?

Or, put another way, if D or some other language has
decent regexps, then what other issues these people
cite for not using those languages?

Any good ones?

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42162F78.9080007@nospam.org...
>
> I was wondering what kinds of arguments against other languages the Perl people usually use in office arguments?

Ruby is already a Perl-killer, IMO. I've never done a serious Perl program since discovering Ruby, and I know several people who've said the same.

> Or, put another way, if D or some other language has
> decent regexps, then what other issues these people
> cite for not using those languages?

Frankly, I don't see D ever being a competitor for Perl or Ruby, since they're serving different needs. But where there's crossover - e.g. I almost never write a regex program in C++, because the libraries are crappy, and hard to use - there _may_ be some market share gain for D.

> Any good ones?

I think Perl is a culture, even more so than C++ or Java, for whom arguments against Perl are simply irrelevant. (What other explanation could there be for such a hideous carbuncle of a language? <g>)

From: "Georg Wrede" <georg.wrede@nospam.org>

> I was wondering what kinds of arguments against other languages the Perl people usually use in office arguments?
>
> Or, put another way, if D or some other language has
> decent regexps, then what other issues these people
> cite for not using those languages?

There are endless features in Perl for writing short, text-processing apps, which is what it is meant for (Practical Extraction and Reporting Language).  There is a culture in Unix (where culture is a good word here and not a "religious rite" type word) that dates back to Unix's original use: creating output as batch jobs and parsing those results, working with config files for a network, etc.

Suppose you want to write a command that works a lot like "grep": opens a series of files, and parses them as lines.  But your lines will all be "key = value" and you want to work with that data.  In C/C++/D this would require an opendir, then an fopen per file, reading the line and using string functions (strchr, etc in C) to try and parse it.  This is all condensed into a "calculus" in Perl like so:

    example: calculate file1 file2 file3

    # that's write, this next while statement actually opens (and closes) each file in
turn
    # reading a line for each run through the loop, ending when all lines are exhausted.
    while (<>)
    {
        # that's right.  $_ holds the current line so you don't even have to declare a
variable,
        # but you could if you wanted to by typing 'while ( $line = <> )'

        strip(); # cut off newline; assumes $_ if nothing presented

        # grab everything up to the equal, then after the equal
        # put both in the array 'pair'
        @pair = $_ ~= /(.*)=(.*)/;

        $key = pair[ 0 ];
        ...
    }

Now if you didn't need all the comments, that would be insanely short code to do all that I mentioned!

However this is the kind of thing Perl was to do.  It *has* functions, but they are very simple.  Long programs will get messy quickly.  In Perl 5 they added more function syntax, modules, objects and all sorts of stuff but they realized it was hopelessly complex, I think.  So they are simplifying for Perl 6.

For a history of how this came about you should read up on 'grep', experiment with it, then 'sed', experiment, then 'awk', experiment, and finally perl.  Those other programs are much smaller, but the progression for text processing will become clear.

Matthew wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
> news:42162F78.9080007@nospam.org...
> 
>>I was wondering what kinds of arguments against other
>>languages the Perl people usually use in office arguments?
> 
> Frankly, I don't see D ever being a competitor for Perl or Ruby, since
> they're serving different needs.

Ah, tell me more! How exactly do these needs differ?

Charlie Patterson wrote:
> From: "Georg Wrede" <georg.wrede@nospam.org>
> 
>>I was wondering what kinds of arguments against other
>>languages the Perl people usually use in office arguments?
>>
>>Or, put another way, if D or some other language has
>>decent regexps, then what other issues these people
>>cite for not using those languages?
> 
> 
> There are endless features in Perl for writing short, text-processing apps, which is what
> it is meant for (Practical Extraction and Reporting Language).  There is a culture in Unix
> (where culture is a good word here and not a "religious rite" type word) that dates back
> to Unix's original use: creating output as batch jobs and parsing those results, working
> with config files for a network, etc.
> 
> Suppose you want to write a command that works a lot like "grep": opens a series of files,
> and parses them as lines.  But your lines will all be "key = value" and you want to work
> with that data.  In C/C++/D this would require an opendir, then an fopen per file, reading
> the line and using string functions (strchr, etc in C) to try and parse it.  This is all
> condensed into a "calculus" in Perl like so:
> 
>     example: calculate file1 file2 file3
> 
>     # that's write, this next while statement actually opens (and closes) each file in
> turn
>     # reading a line for each run through the loop, ending when all lines are exhausted.
>     while (<>)
>     {
>         # that's right.  $_ holds the current line so you don't even have to declare a
> variable,
>         # but you could if you wanted to by typing 'while ( $line = <> )'
> 
>         strip(); # cut off newline; assumes $_ if nothing presented
> 
>         # grab everything up to the equal, then after the equal
>         # put both in the array 'pair'
>         @pair = $_ ~= /(.*)=(.*)/;
> 
>         $key = pair[ 0 ];
>         ...
>     }
> 
> Now if you didn't need all the comments, that would be insanely short code to do all that
> I mentioned!
> 
> However this is the kind of thing Perl was to do.  It *has* functions, but they are very
> simple.  Long programs will get messy quickly.  In Perl 5 they added more function syntax,
> modules, objects and all sorts of stuff but they realized it was hopelessly complex, I
> think.  So they are simplifying for Perl 6.
> 
> For a history of how this came about you should read up on 'grep', experiment with it,
> then 'sed', experiment, then 'awk', experiment, and finally perl.  Those other programs
> are much smaller, but the progression for text processing will become clear.

Excellent! This was the kind of answer I wanted with my question.

I'll save your post, and hope to get some more examples,
from you and others!

(As is obvious by now, I'm trying to gather knowledge about
the "surroundings of D"  --  in practical matters.)

For one thing, Perl is used a lot in scripting.  One might write a quick script to DO compilation using Perl.

This is because Perl is ultra-portable.  You can write a perl or bash script, and have it set up the compilation stuff for you, because you know Perl is going to work.  What you don't know is whether D will even be installed yet on their system.

I haven't actually used Ruby myself, so I can't really say what it's niche is, but... well, I don't expect D (or any other language) to replace Perl anytime soon, and most likely the same goes for Ruby.

-[Unknown]


> 
> 
> Matthew wrote:
> 
>> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
>> news:42162F78.9080007@nospam.org...
>>
>>> I was wondering what kinds of arguments against other
>>> languages the Perl people usually use in office arguments?
>>
>>
>> Frankly, I don't see D ever being a competitor for Perl or Ruby, since
>> they're serving different needs.
> 
> 
> Ah, tell me more! How exactly do these needs differ?

In article <cv5mt0$lkg$1@digitaldaemon.com>, Matthew says...
>
>"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42162F78.9080007@nospam.org...
>>
>> I was wondering what kinds of arguments against other languages the Perl people usually use in office arguments?
>
>Ruby is already a Perl-killer, IMO. I've never done a serious Perl program since discovering Ruby, and I know several people who've said the same.
>

Ruby is not a Perl-Killer.  Ruby is a Perl Wannabe.  Ruby may have a cleaner object system but Perl still has thousands of modules from CPAN and is much more sophisticated internally. Perl has a lot of built system features that tie into UNIX and can even Adapt to different platforms.  Perl is ported to such architectures and Windows and Win32 and VMS and Unix. Perl has been ported to hundreds of different computer architectures and operating systems.  You can even run Perl on the Z/OS mainfraime.  Perl has been adapted to far more platforms than Ruby.

One thing that is really bad about Ruby is it forces you to use objects and
the tab indentation for code as in Python. Tab indention sucks.
Having a semicolon to denote the end of a line is better. Perl is also closer to
C than Ruby and has many more elements of Basic and shell scripting which
make it more natural for utility scripting. Perl allows you to use objects or
not use objects or procedural programming and Perl doesn't force the object
oriented paradigm which can be slower.

Also Perl 6 will be a rewrite that should resolve many of the object problems of Perl 5. Perl 6 will add a lot of new features including grammars and a new given switch and improved regular expressions. Perl 6 should clean up the Perl language and make it more powerful. With Perl you can mutate some of the language rules and adapt them. Perl 6 will destroy Ruby or make Python and Ruby clients of the Parrot Engine.  Perl 6 will also allow for integral data types like c which is a problem with Ruby since everything is an object.

Larry Wall has been very open to input when he redesigned Perl 6.  A lot of language designers choose what they feel a language should be but Perl 6 has had a lot of community input including RFCs in the redesign.

When it comes down to it you can always work at a company and know
that Perl is a company standard whereas in many corporate programming jobs Ruby
is not supported or encouraged and neither is Python.

Even though Ruby and Python claim to be better or cleaner than Perl they still aren't used as often in corporate settings. Where I work they use Perl and not Python or Ruby.

This is a perl code which uses semicolons which is superior to tab block
coding.
=====================
#!/usr/bin/perl -w

use strict;

my $E = 1;
my $C = 2;
my $S = 3;

===========
This is a python program for which ruby is much the same

#!/usr/bin/python

import fileinput

E = 1
C = 2
S = 3

=================
The moral of the story is that any language that doesn't use a semicolon or
something to end a line sucks.

>> Or, put another way, if D or some other language has
>> decent regexps, then what other issues these people
>> cite for not using those languages?
>
>Frankly, I don't see D ever being a competitor for Perl or Ruby, since they're serving different needs. But where there's crossover - e.g. I almost never write a regex program in C++, because the libraries are crappy, and hard to use - there _may_ be some market share gain for D.
>
>> Any good ones?
>
>I think Perl is a culture, even more so than C++ or Java, for whom arguments against Perl are simply irrelevant. (What other explanation could there be for such a hideous carbuncle of a language? <g>)

Perl is a marvel of grammar power and is not a carbuncle as much as a diamond. Just because Perl uses sigils to denote hashes and arrays doesn't mean that it is hideous.  Perl's grammar is very powerful and operator rich and a marvel or design.  Perl is like APL which also uses symbols which makes it very powerful. Perl also doesn't lock you into objects like Java or Perl or Ruby.  Better yet Perl's code structure is better than that tab block grock in Ruby and Python. All Ruby has over Perl is a newer cleaner object design with iterators but Perl 6 will more than answer this and then some.