Slashdot Mirror
You Used Perl to Write WHAT?!
Esther Schindler writes "Developers spend a lot of time telling managers, 'Let me use the tool that's appropriate for the job' (cue the '...everything looks like a nail' meme here). But rarely do we enumerate when a language is the right one for a particular job, and when it's a very, very wrong choice. James Turner, writing for CIO.com, identifies five tasks for which perl is ideally suited, and four that... well, really, shouldn't you choose something else? This is the first article in a series that will examine what each language is good at, and for which tasks it's just plain dumb. Another article is coming RSN about JavaScript, and yet another for PHP... with more promised, should these first articles do well."
I always see both sides of the 'right tool for the job' problem.
Having the right tools is great for current productivity, but it's hell on expenses and new recruits. If you use a different tool for every job, you need to maintain all those tools and a task force that's able to use all of them. Sometimes the 'right tool' is one that fits the company as well as the job.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
a few winters ago so I wrote a BASIC interpreter in Perl which wasn't hard, but then from the lessons I learned from that I then wrote the same BASIC interpreter in VMS DCL which was a really interesting week project. (VMS DCL is the Cshell of the VAX/VMS world)
Why? I dunno, but I did learn a whole lot about Perl.
I think that's the best way to learn things... make up a fake project for yourself (say, a database, or a simple flight simulator)...then implement it. Then revise it.
Karma: Excellent. 15 moderator points expire sometime.
My favorite "You did WHAT in perl?" response is: On several projects, when there were portability problems, I've created a Makefile entry that runs a "man foo" command and pipes the data to a perl script, which generates C files for that system. It's typically just header files, but sometimes also a few .c files with data structures and/or simple functions to intercede with variant library routines.
It's fun to watch people's reaction when they realize that "You wrote a perl script that reads the manual and generates the code?" I just respond something like "Uh, yeah; you got a problem with that?"
Especially fun has been the couple of discussions in which I expressed a great deal of skepticism of various "AI" claims. Then someone brings up the fact that I write perl programs that read English-language docs and generate code from them. They're obviously puzzled by the fact that I do this while looking skeptically at "AI" proposals. It's like they expect me to just shrug and write other impossible things in perl.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Skipped right down to the stuff that perl isn't supposed to do: not supposed to be used in high performance/real time stuff - check, as a replacement for shell scripts where shell scripts are shorter - check (obvious-meter off the scale though), it isn't supposed to be used in CGI. Eh. Right. Because, according to the author, we should be using ruby on rails for that. Eh. Right. Again. Why didn't he just outright say that we should be using j2ee with struts and beans and xml based style sheets ! Oh that was 2007 ! My bad.
/win/ ?!
Perl was, and is (IMHO) the first and foremost thing you grab when you write web-stuff. CPAN is nothing if not infinite, the web is a text-based thing the perl was designed for, and its speed makes ruby blush. So why ?
Why try to write off perl all the time. Is it because they can't seem to
Religion is what happens when nature strikes and groupthink goes wrong.
That is why I love python; in most cases there is only one way of doing it - which improves readability, testability, and debugging.
I was a long time perl programmer before I made the switch to python. All my headaches with perl went away, and no new headaches of similar magnitude have surfaced. So for me it has been an net improvement.
KISS, DRY, and various other good engineering/development paradigms are embodied in python's development model.
Perl made it easy to shoot yourself in the foot. Python makes it hard to shoot yourself in the foot -- but you can if you want to. That probably best sums up their differences.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Ironically, Larry Wall once said that part of the reason he wrote Perl is because he was scared of Awk's parser.
I read the internet for the articles.
Why do you say that? I write Perl and PHP scripts all the time and don't see any advantage to using Perl for webforms over PHP, at least not the ones I write. It's trivially easy to access data from a database in either scripting language and you can perform Perl-style regular expressions in PHP. The nice thing about PHP is that it's specifically designed for web applications and has simpler syntax in some situations. The downside to PHP is learning all of these functions that don't have a consistent pattern to them but, once you know them, you can accomplish a lot of tasks efficiently.
The list missed the most important part of perl. A glue language. Python and a few other languages claim they can be glue languages but that's pretty much a joke to anyone who knows both fluently. Perl is the ultimate glue language for combining diverse output so different programs from different sources, written decades apart in different languages can all work like a well oiled machine.
The other really odd experience for me was learing object oriented programming. I had been programming in objects since I was first introduced to them when the first NeXT computer came out. I used java. And C++ and such. I thought I understood objects.
Then one day I learned to program object oriented in Perl. An I learned that while I was fluent in object oriented usage, I really had a pathetic understanding of how they worked and what was actually possible with objects.
Perl objects are sort of like owning a copy of grey's anatomy or "the visible" man. You son't just see that arms connect to torso's from outside but you see all the sinews and bones and blood.
It's actually amazing how so many things we think of as different concepts in object oriented programming and data bases are actually different reflections of the same trick. And that's the trick perl use to make objects.
in perl, an object is any variable that has an attribute that can store a list of package names.
Let's see what you can do with that.
Hmmm.... well that list can be your inheritance heirarchy so each package is what you search for methods. But notice that since it's a mutable list a perl object can do something else that most object oriented languages cannot. A variable can change it's "inheritance" list after the fact. it can change it's own class.
Okay Now this is just a single variable so where to we get attributes of the object? Well, if that variable is say a hash (dictionary) then we can just use the key's as the attribute names. so if were to write self.foo in C++, you would write self->{foo} in perl.
More fun: let's say you call a method() or ask for an attribute on a variable that does not exist. Well, a perl object can just add more packages to it's inheritnace list. Or it cold write the method on the spot and add it too it's own inheritnace. "I'm my own grandpa". I've used this trick many times to create tables. I don't write any of the "get" or "set" methods. instead I just intercept the call to the method "setfoo()" which never existed cause I never wrote it, then I have perl create an attribute called foo: Self->{foo} = "something". then I have perl write a subroutine called "setfoo" and add that subroutine into a package namespace and put that in it's inhereticnace list.. ("like adding methods to a C++ package outside the declaration". (programming tip: obviously this is could lead to problems with typos, so I also provide the variabel with a list of all allowed attribute names--- but of course I can always add to that list later).
Now something more exotic. The hottest thing in Data base programming is the realization that sometimes column centric data bases are better than traditional row-centric data bases structures. In perl an object can change which it is, transparently. For example, if I'm a traditional object with a row organization then all my attributes are stored as self->{foo1}, self->{foo2}, self->{foo3}. and so on, just as you might right self.foo3 in python. But I did not have to do it that way. What if instead of making the self variable a hash (dictionary) I had made the self-variable a simple scalar, say an integer. Well at fist this seems stupid, where did all the instance variables go? Well, I just store them in the class. I make the scalar self-variable's integer just an index. The class keeps the instance variables in arrays--that is column based storage--.. SO for example if self = 4, then the attibute foo for this instance now becomes self->class->foo[4].
The beauty of this is that si
Some drink at the fountain of knowledge. Others just gargle.
That's pretty much my point. While I was at college, I worked with Java, C, C++, Fortran, VB, and SPARC Assembly. I have a vague working knowledge of VB and Java syntax. I still remember C and C++ pretty well as I use those still (and I use a lot of PHP as well, but that I picked up after I was out). If you asked me to write something in Fortran or SPARC Asm at this point in time the best I could do without a reference book next to me is a blank stare (The Fortran class I took wasn't even geared towards CS majors. It was just there for Liberal Arts people to get a required computer credit - I took it because for a 3rd year CS student it was like a free A+ to add to your GPA :)). I just haven't used it recently at all and the syntax is lost.
:P. But, regardless of the percentage, the point still stands: syntax is trivial. The important part is knowing how to think like a programmer. If you can do that the rest just falls into place.
HOWEVER, I do remember quite well what threads are, what a semaphore is, what a binary tree is, the difference between a bubble/quick/radix sort, the concept of object oriented design, etc. I wish I could say I remembered UML modeling but honestly, I hated that darned part of CS and never paid attention there anyways
"People who think they know everything are very annoying to those of us who do."-Mark Twain
Languages are for the most part trivial. And universal.
How about lazy evaluation and currying... ...time to make another language, Haskell.... Do we want... a pointer?
Please do forgive me (hee hee hee: Please ==> forgive $ me) if I haven't quite gotten your point, but I cannot square your first and last paragraphs, specifically the parts I've quoted.
Perhaps if you'd written "Imperative languages are for the most part trivial and universal? Perhaps then could easily equate C and Fortran and Perl and sed, and leave Haskell and Lisp out of the mix. Or perhaps if you'd written "OO languages are for the most part trivial and universal? Perhaps then I could equate (more or less easily, don't think it's quite NP) Objective C and Java and C++. (But see below....)
But the bold unqualified "they're all languages, get over it" sort of assertion doesn't parse.
My intro was Fortran, then F77, then Pascal, then C (OMG! Pointers! The Bomb!), and it was evolution, a little more cool, a little more flexibility all along.
Then I learned C++ at work by day and Java for fun at night, and my head hurt, 'cause I liked the imperative style and OO was weirdly different but everyone was swilling kool aid so I stuck it out...
...and every night I'd discover something in Java that was THE BOMB that would solve that day's problem and every next day I'd find that C++ didn't have that feature (does today, AFAIK, but STL was busted then, so everyone rolled their own)... ...but I moved out of real programming before I got my head around OO.
And now I'm learning Haskell, just 'cause I've learned that making my head hurt from time to time is a great way of stretching myself, of getting better at everything....
And I don't understand - at least, I haven't wrapped my head around Monads yet, though I get what they're for. And you know what? No pain.
None. I can feel the approach of enlightenment. SYB and reflect, baby, introspection and lazy evaluation and side-effect free (or reliably and provably constrained side-effect management) via implicit state passing.
Whoa.
I feel like Neo after the roof but just before the hallway - I'm starting to believe.
I've read the "SYB in C++" paper. I get what they're doing. But they admit the gap:
Scrap++ is a great exercise, but how do you get to SYB without those? You don't.
There's a guy out there that /.ers love or hate, no middle ground, so I won't reference him directly, but he's right: Different programming models change how you think of problems, and the right model opens so many doors you didn't even know existed. Doors you couldn't even have described until you knew they were there, but you were unable to find the hallway until you squinted, looked sideways at the world, and watched it shift... ...and were freed from the imperative....
"Hello World" is a cool teaching aid in Fortran and C and even perl (do it 15 different ways, without string literals or character types, preferably with a program one column wide :->)
But Haskell? No. When you learn Haskell, think big. 'Cause its programming model is so way different you have no idea. I'm at the point I almost consider Monads harmful... ...but I'll get the other side of the koan soon.
And when I have a simple repetitive task that I need to automate, I'll stick to bash, 'cause it's clean and readable, and sufficiently fast and sufficiently limited that I have to force myself to be literate, which makes it so much easier 6 months later when I need to tweak $ remember script.
I won't use Haskell for that. No way. But that replacement for scrabble/scribble I've been thinking of? That tool for edit
I'm here EdgeKeep Inc.