www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Perl query

reply Georg Wrede <georg.wrede nospam.org> writes:
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?
Feb 18 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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>)
Feb 18 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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?
Feb 19 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
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?

Feb 19 2005
prev sibling parent Anonymous <Anonymous_member pathlink.com> writes:
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.
Feb 19 2005
prev sibling parent reply "Charlie Patterson" <charliep1 SPAMIDDYSPAMexcite.com> writes:
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.
Feb 18 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
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.)
Feb 19 2005