There Is Nothing Perl Cannot Do
There Is Nothing Perl Cannot Do
http://www.bastichlabz.org/bastich/Strips/
Likewise, there is nothing BrainfuckLanguage cannot do. NOTHING! It's all because of that little thing called TuringCompleteness.
Nothing? So that means we'll soon see: "Quake 4: Deathmatch!!" (proudly scripted in Perl)
Yes, probably! See http://search.cpan.org/~tels/Games-Irrlicht-0.04 -- PhilippeCausse
Maybe not, but we do have FrozenBubble? (http://en.wikipedia.org/wiki/Frozen_Bubble).
PerlLanguage is one of those languages that you tend to either really love or really hate. If it fits the way you think, you will become a rabid fan, but if not, consider it a tool for lovers of cryptic puzzles and one-liner contests. Other languages that fit this category may include LispLanguage variants, SmallTalk, and EiffelLanguage. Such languages will probably never become mainstream, but will always have super-loyal followers.
Some discussion on readability moved to WhyHatePerl.
In other words, Perl is TuringComplete. Whoopty-doo.
The Turing-completeness rejoinder to the power of languages is, of course, completely fallacious. You can compare Turing-complete languages based on their relative power. For instance, Smalltalk is strictly more powerful than CeeLanguage and JavaScript is strictly more powerful than Smalltalk and Perl is strictly more powerful than JavaScript.
Actually, the real problem is the statement, "There is nothing Perl cannot do." The real statement should be, "There is nothing Perl should not do." That is also false. (By the way, I'm still waiting for someone to answer, "Is there something JavaLanguage should do?") -- SunirShah
I'll take a stab at IsThereSomethingJavaShouldDo. -- MarkAddleman
An advocate would say "everything is easy in Perl." A critic might say "everything is hard in Perl." One would ask of both, how much experience do you have in other environments? in Perl?
I will say that the "smart match" operator, the given/when, and the easy ability to format variables into strings are worth saving--then dump anything else that isn't already widely used in other languages.
Actually, an advocate would say "Perl makes easy things easy and hard things possible." Though LarryWall said it first, of course.
And since we so often want to do the same simple things over and over again (fetching a webpage, sorting a list, grepping a logfile) Perl helps us get out job done more easily.
Perl is the Quasimodo of programming languages - he is as ugly as hell, but you want him on your side. You can't help but love him, warts and all.
Today, in my office, two developers with, I estimate, more than 30 years experience between them, having used procedural, functional and OO languages in a range of industrial and research settings throughout that time, were, in the space of a three-hour session, unable to understand how to capture the output of a system command and subsequently pass it into a subroutine. They were new to Perl, and were working from an O'Reilly book. Anyway you slice it, that makes Perl a hard language. -- KeithBraithwaite
Here are a few ways to dice it that don't necessarily make Perl a hard language: (i) Your book wasn't good, or (ii) programmers who get stuck in a book and don't use Google to help them resolve their questions are probably imbeciles posing as smart workers.
I'd say that demonstrates more about your colleagues RtFm skills. It's a FAQ for crying out loud! Perl is a language where neophytes really must read a structured introduction; its approach to many common tasks is distinctive.
[-- how can use "structured <anything>" and "perl" in the same sentence?! I use perl because its good at processing text. I also hate its ugly syntax and insane inconsistencies NickKeighley]
D:\Dev>perldoc -q capture command outputOutput snipped for brevity, but had they bothered to use the tools that come with Perl they would have quickly found the answer.
[Wow! ThankYou for "-q". My Perl RTFM skills kind of stink.]
this works every time:
http://www.google.com/search?q=how+to+capture+command+output+in+PerlAaaa! Eeeek! Had they been working from a reference card rather than a book they might have found backticks faster -- or if they had ever captured the output of a system command in a shell they would have found backticks familiar -- backticks! BackTicks!
After some discussion here we have determined that the programmers in question had figured out that `command` evaluates to the string which is the captured output of command. They had also figured out that a subroutine with this argument could be called with or without parenthesis. The mystery that stumped them was that the arguments to the call aren't bound to formal parameters as is the practice in most other languages. Instead they are assembled into an array which is bound to the name "_". From here forward PerlLanguage programming practice varies ...
All of these are highly idiomatic with perl. If you know them, then you (probably) think perl's versatility elegant. If not, you are (probably) left searching the manual for examples of a formal parameter list.
such as
sub takesthreevalues($$$){
my ($firstarg, $secondarg, $thirdarg) = @_;
...
That is how to do pass-by-value.
Actually that's only partially correct. takesthreevalues() is prototyped (a badly overloaded term) to take three and only three values regardless of the context that it is called in. Such a prototype is severely frowned upon by most competent perl programmers. That should be written:
sub a_sub_that_takes_uses_up_to_three_vars {
my ($firstarg, $secondarg, $thirdarg) = @_;
...
}
The crucial difference between these two is the following:
my @array=(1,2,3,takesthreeargs 4,5,6,7,8,9);is the same as
my @array=(1,2,3,a_sub_that_takes_uses_up_to_three_vars(4,5,6),7,8,9);Except the latter requires the parens or it will "slurp" all of the args following the sub call. Prototypes mostly exist so that power users (and if you use $$$ willy-nilly IMO you ain't one) to redefine the lexing rules at compile time. As i said most perl programmers almost never use prototypes.
Perl is definitely a severely idiomatic language, which has its benefits and drawbacks. This might not be a fair example, though: Any decent intro Perl book would make it very easy to find this feature. When you say "an O'Reilly book," do you mean ProgrammingPerl? If so, that might explain the difficulty.
We mainly use LearningPerl , with PerlInaNutshell? as a reference. What we lack is a place to easily find bundles of examples like the one Ward kindly provided above. A pointer to such would be most helpful, if there is one. Examples of all three idioms are doubtless in Learning Perl, but not collected together under the heading The three ways to pass strings to subroutines. It's all well and good to celebrate there being more than one way to do it (that is, a small, arbitrary number of ways to), and it's fine for LarryWall to claim that Perl is PostModern, but the upshot can be that the developer new to Perl is adrift on a conceptual sea without a cognitive compass. -- KeithBraithwaite
That sums up my experience: adrift on a conceptual sea without a cognitive compass. I tried on several occasions to learn Perl, but could not quite wrap my head around it. Eventually I read that Perl had been developed as a replacement for shell, sed, grep and awk. Suddenly it all fell into place! Glenelg Smith
LearningPerl does not make a good reference book. After working through all of it, you will have an understanding of the basics, but it's hard to find a particular concept, especially if you're not sure what it is yet :) I second the recommendation for ThePerlCookbook. Looking up system() in the index gets you to the 'Running Another Program' recipe, next to 'Gathering Output from a Program', though it does not explicitly explain the difference between calling 'some_function(`command`)' and 'some_function(scalar(`command`))' which is perhaps part of the trouble you were having. Though that might be under 'Accessing Subroutine Arguments'
I'd recommend ThePerlCookbook by TomChristiansen and NathanTorkington?. It's full with code snippets on a surprisingly wide range of Perl questions... Real good! -- DavidDeLis
ThePerlCookbook is a worthwhile investment in any case, but for quick answers to these sorts of questions I keep the Perl Core Language Little Black Book by Steven Holzner (Coriolis; ISBN 1576204265 ) within arms reach. -- PrestonRickwood
In Perl6, it probably will be. Perl programmers never found it necessary - the 3rd approach (above) is the closest. Even function prototypes were a late addition (and they are rarely used).
Also, note the highly effective idiom of calling subroutines with a list of named arguments as in mySubroutine( baz => 'a', foo => 'b' ). This idiom is used prominently in CGI.pm amongst other places. Such a list is easily converted to a hash table with code such as the following ...
sub mySubroutine {
# my %param = @_;
# here's how to use unordered named parameters with default values
my %param = (bar => 37, baz => 24, action => 'hike!', @_);
print "Foo: $param{foo} Bar: $param{bar} Baz: $param{baz}";
}
Note that Perl's "prototypes" aren't really prototypes at all, and are generally to be avoided. See TomChristiansen 's "Prototypes Considered Harmful" (http://www.perl.com/language/misc/fmproto.html) -- PaulCrowley
Or Robert Fischer's DevilsAdvocate "A Defense of Prototypes" (http://enfranchisedmind.com/blog/2005/10/19/a-defense-of-prototypes/).
ErikNaggum said it best:
There's no doubt he's biased and opinionated, but he's also incredibly intelligent, competent, and has mastered both languages. Who would you like to ask for an unbiased opinion, someone not competent to give one?
Indeed. If you want someone to praise your pet language, don't ask someone who can think and then call him biased. <-- whose side is this person on? Both.
People with 30 years experience often expect perl to work the way they think it should work.
IMHO you have managed to refactor this into both contextlessness and meaninglessness.
People with significant Unix, CeeLanguage and shell script experience tend to find that Perl does work the way they think it should work. (Those who have lots of mainframe experience, but are weak in Unix and its tools tend to have a hard time.)
foreach(keys %params){
$params{$_} =~ s/\+/ /g;
$params{$_} =~ s/%(..)/chr hex $1/ge;
};
# okay that took more than five seconds
As a counter to some of the above gloom, I've worked on a mid-sized, Enterprise application written primarily in Perl (about 80KLOC worth, plus some Java and a lot of DHTML). We had competent Perl programmers on the team. The code was well structured and easy to read (once one had become competent in Perl). Perl gave us a lot of leverage, both from powerful regular expressions for munging text, and from the availability of powerful add-ons, like DBI/DBD for database access. Because Perl is interpreted, bug fix turnaround was rapid. We ran circles around people trying to do similar things in Java.
We did eventually suffer from lack of stable threading, but that was well along in the product's life cycle, when we were starting to push hard on performance. We also ran into a far amount of "Perl, yuck! Java cool!" bias, including some from customers.
I wouldn't try to build GUI stuff with Perl, but as a server side development language, in competent hands, it rocks. -- DaveSmith
There are hooks to many different GUI toolkits, e.g., wxPerl, Qt, Perl/Tk, Gtk, Prima. Someone used to VisualBasic or the like might find it cumbersome to program at this low level, but there are some screen designers (I don't think you can call them IDE's though) like wxGlade, GUILoft, ZooZ, and Prima. The IDE's tend to be commercial, e.g. VisualPerl?, or the Qt IDE (though the GUI Tool kit itself has a free version). Heck, just see the Perl GUI Programming FAQ at http://www.perlmonks.org/?node=108708.
Give a try to Perl/Tk - It's worth having a look at. -- PhilippeCausse.
I read here and there: a Perl script in 3900 lines, 4500 lines. Does this mean that Perl is not as modular as C? It is a huge script and not a bunch of small modules? -- ra
Perl can be modular (in fact, more modular than C). Perl has packages, which can hide parts of one file from other parts of the same file, but C does not have (or need) this feature.
Regarding modularity, in the "chunks of code" sense, Perl has a huge number of modules implementing an extremely wide range of functionality distributed as free software on TheCpan (See my comments on that page.) In the "hiding things" sense, good OO Perl will encapsulate carefully to encourage people to do things the right way (see ObjectOrientedPerl for more on this). Of course, though, the language will never force you to do this, because that wouldn't fit with TimTowTdi. The Perl you encounter will be only as good as the person that wrote it. -- EarleMartin
Discussion of interpreted languages moved to InterpretedLanguage.
Can you write a bootloader in Perl?
Define bootloader.
Should you write a bootloader in Perl?
No.
{Cowards!}
In this case the essential part of the definition is a bootloader has to run without memory mapping and load certain blobs into certain addresses. Turing completeness doesn't cover everything. A Java applet is still Turing complete but is not fully complete because no virus can be written (assuming no exploit against the sandbox). In fact the Java applet is only Turing complete because it can emulate a complete computing platform, and that platform can have a virus just fine.
Is there really nothing that Perl cannot do? I find that very hard to believe.
For one thing, I doubt that Perl can trisect an arbitrary angle, using the computational equivalents of a straightedge and compass.
And I would be surprised if, given a computational straightedge and compass, Perl can square a circle, or double the volume of a cube.
And certainly, if Perl were to integrate the function exp(-x^2) in terms of elementary functions (ie, polynomials, trigonometric functions, exp(x) and ln(x)), I would certainly raise an eyebrow. And it would be highly amusing if Perl were to come up with integers n, x, y, and z, with n greater than 2, such that x^n + y^n = z^n.
Having said this, I do know of one thing that Perl can't do: Perl can't parse its own syntax, without running a Perl program. Indeed, it has been proven that the halting problem can be encoded into Perl's syntax itself, and it's been proven that no Turing-complete language can solve the halting problem (ie, no program can determine if a given algorithm will be able to complete, without getting into an infinite loop)...which, incidentally, is something else that Perl can't do.
Now, to be fair, these are all things that no computer language can do, because they have been mathematically proven to be impossible; I find it amusing that there are people claiming that there is nothing that Perl cannot do, considering these things!
--Alpheus
EditText of this page
(last edited December 19, 2014)
or FindPage with title or text search