digitalmars.D - Perl query
- Georg Wrede (6/6) Feb 18 2005 I was wondering what kinds of arguments against other
- Matthew (12/18) Feb 18 2005 Ruby is already a Perl-killer, IMO. I've never done a serious Perl
- Georg Wrede (2/10) Feb 19 2005 Ah, tell me more! How exactly do these needs differ?
- Unknown W. Brackets (10/26) Feb 19 2005 For one thing, Perl is used a lot in scripting. One might write a quick...
- Anonymous (58/77) Feb 19 2005 Ruby is not a Perl-Killer. Ruby is a Perl Wannabe. Ruby may have a cle...
- Charlie Patterson (36/41) Feb 18 2005 There are endless features in Perl for writing short, text-processing ap...
- Georg Wrede (6/60) Feb 19 2005 Excellent! This was the kind of answer I wanted with my question.
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
"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
Matthew wrote:"Georg Wrede" <georg.wrede nospam.org> wrote in message news:42162F78.9080007 nospam.org...Ah, tell me more! How exactly do these needs differ?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.
Feb 19 2005
"Unknown W. Brackets" <unknown simplemachines.org> 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...Ah, tell me more! How exactly do these needs differ?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.
Feb 19 2005
In article <cv5mt0$lkg$1 digitaldaemon.com>, Matthew says..."Georg Wrede" <georg.wrede nospam.org> wrote in message news:42162F78.9080007 nospam.org...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. ===================== use strict; my $E = 1; my $C = 2; my $S = 3; =========== This is a python program for which ruby is much the same 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.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.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.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 19 2005
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 file in turn exhausted. while (<>) { declare a variable, 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
Charlie Patterson wrote:From: "Georg Wrede" <georg.wrede nospam.org>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.)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 file in turn exhausted. while (<>) { declare a variable, 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 19 2005