Slashdot Mirror
Damian Conway On Programming, Perl And More
Andrew writes: "My host pair.com has an
interview with Damian Conway
in which he talks a lot about his upcoming modules, and what skills
a Perl programmer needs. I'm personally waiting on
Parse::FastDescent." Conway talks about some interesting modules he's working on, Perl 6, and on programming in general, too.
I suppose he's talking about the post-dot-bomb world we live in, but these are probably important at any time. Funny, though: a majority of programmers I've known--while intelligent and relentless--place less emphasis on the "documentation, communication, teamwork" skills. Of course, that's where technical writers and project managers come in handy... (heh heh)
One thing I've noticed about Perl people is that they are often very open-minded about using other languages to solve a problem. Maybe it's because they are so used to losing the "let's develop in Perl" argument, maybe because they are more naturally inclined to use every tool available, or maybe it's because they want to figure out a way to parse every computer language known to humanity from within a Perl module...
I've got a bad attitude and karma to burn. Go ahead. Mod me down.
You can be artistic or even create artworks with anything.. although I once found visual basic to be a big impediment.
If you have ever heard of an elegant mathematical proof or an elegant bit of code, this is something like what "artistic" is. It also could mean efficient, clear, etc.
I think you need to differentiate between
- traditional artworks like maybe oil paintings
- artworks which use digital media in some way
- making a statement with/through art
- craftsmanship
- intellectual and visual elegance i.e. of design
Hypercard? Yes, blech. But I hope you think about elegance or craftsmanship at least if you are turning your code out to the public.
We need more elegance in open source code because it tends to 1) make work fun/creative 2) make it run efficiently 3) reduces bugs 4) strong metaphor makes paradigm more powerful/extensible.
It's true that individualistic programing styles can slow down a project, and it's true that perl allows almost infinite programming style, or lack of same. However, the two issues are orthogonal, and Perl itself is not bad for cooperation. Just ask the CPAN developers.
:)
Next, 'programming' is not the same as 'coding'. Programming has come to mean all the terms the author of the above post used: Design, Engineering, Requirements, Documentation.
The author of this post is half-right, but missing the big picture. There are folks who develop with maturity and discipline with Perl, and there are folks who write garbage in every language. The freedom to screw ourselves over is necessary for us to learn how not to screw ourselves over.
So no, Perl isn't bad for teams, self-centered programers are bad for teams. I should know, I've been that programmer.
(If I felt like invoking flame-mode, I'd suggest that perhaps the poster is coming from an academic or corporate background where individualism is bad for the hierarchy...
Here's why coding is an art: it can't (yet) be done well by a computer. That is, we don't know all the rules that go into making a good program, we haven't codified them. This is in contrast to most real engineering disciplines, where it is very easy to quantify a superior solution; the only trick is to find it.
What makes something art is how it is made, not what it is ultimately used for. As long as some part of writing good code remains locked in the coder's head it is as much a deep and mysterious art as writing a symphony or creating a painting.
"If you look 'round the table and can't tell who the sucker is, it's you." -- Quiz Show
My guess is that a design pattern
is a recognizable form of software architecture
that we see recur and thus it is cateloged.
If you use a specific language to implement a
design pattern what you have is a
'module' or a 'class'.
One uses a language to IMPLEMENT a design pattern. The pattern exists without the language.
In the same way one can make a screw driver out of tin or out of hardened steel. One uses the steel if one doesn't want the screw driver to break.
The analogy in software is using a steel OS like LINUX or UNIX verses using a toy tin OS like Windoze.
The folks who use Windoze use it because they want to addict their users (victums) to upgrades because the Tin OS stuff always breaks.
As far as PERL goes, whatever. It is cute but not the one and only show in town.
If you are going to talk about design patterns you aren't a 'coder' but an archtitect or software carpenter.
PERL is a cute language suited for WWW work. For other things it doesn't work so well.
I like PERL, but it creates a huge footprint and you have to include the world to get a very large object that runs in an interpreter.
NOT GOOD for a lot of things, pervect for others. Design patterns don't live in a specific language. One uses a language to implement and the pattern itself is something that lives in the programmer/architects mind.
The code becomes a module or an object. It is never the design pattern itself.
"Perl Specific Patterns"
I would call that a "Perl Idiom"
It is not a pattern.
Patterns are CONCEPTS not IMPLEMENTATIONS
I make my living as a perl programmer
/. are so quick to flame Perl. If you don't like it don't use it but don't flame people who do. I love Perl. As far is being hard to read or understand well I think that's people who have never tried. When I started coding Perl I was a complete newbie. I'd done a little C and a bit of Basic and I wanted to learn how to right CGI scripts. Someone showed me Perl and inside a week I was writting (badly but still writting) a message board. It took me weeks, it was horrid but it worked. I know very few people who can do that in any other language. In fact it was Perl that got me to move away from the darkside of Windows (this was before ActiveState made Perl on Windows a more manageable beast).
I do not understand why a majority of people on
Try it before you knock it. Give it a chance. If you don't like it then use the tool you like but don't keep spreading flames and lies about it. Saying its only good for 500 line programs or that its always unmaintainable or it can't be used by teams simply isn't true. And ANY language can have all of those attributes.
Perl also has a great community that I've not seen in other languages. Don't know how to do something, ask Perlmonks. Those guys are even one of the few places where newbies can come. Very rarely do I even see someone screaming RTFM at them. Most of the time you just get your question answered and answered fast. There are other places that aren't so kind.
Perl is great. Long live Perl
The Anti-Blog
Oh, c'mon. You can code badly in any language.
Given Damian's reputation, the fact that the Perl community is raising money to get him to focus on Perl, and the fact that he seems to know what he's doing, wouldn't you think that the fact he chooses to work with Perl says something potentially interesting about the language?
When someone I respect praises (or consistently uses) a tool that I don't like, I try to question my opinion and find out what they know that I don't.
"if you follow some rules. "
:) Really though, difficulty reading a language is usually due to
Well if you follow some rules it shouldn't matter what language you use
1) lack of commenting (duh!)
2) being unfamiliar with a language
3) lack of organization (formatting code blocks)
Perl programmers tend to be bad on the third point, but it's not the fault of the language. Personally I find it easier to read a program where my variables are easily marked with a $ in front, but that's probably a sign I've done Perl to long.
I work for a Major Automotive Manufacturer's ITM department, and Perl has saved our lives.
We have a large number of very large and complicated projects done in Perl, plus literally thousands of minor, single-use programs. There have been no maintainence issues to speak of.
Perl, like any other language, can be written in such a way as to only be comprehensible by the authour. But if you optimise the code for *LEGIBILITY* - ie, no use of "$_" or the "implied $_" then Perl has spectacular legibility. Much better than C, C++, or (especially) Java.
In fact, the projects that meet or beat deadlines are usually written in Perl. Those that miss deadlines, drag on for ages, and prove impossible to maintain once complete are written in Java.
That's the real beauty of Perl, from a large-project-maintainence point of view. Perl's "there's more than one way to do it" idiom means you can write code such that it is much easier to maintain than a "bondage and discipline" language that only has One True Way to code in. Java's syntax is optimised for the language designer's preferences and tastes, where Perl allows you to optimise for the needs of the project.
Y'know, the anti-Perl sentiment that runs through a sub-population of Slashdot reminds me very much of Medival England, back when French was the language of the Royal Court. French was considered the language of nobility, and English was the language of commoners. English was gauche, ugly, and messy.
But (and I'm a fluent French speaker, so I know whereof I speak here) English is a far more flexible and adaptable language than French is. You can write some really horrible, incomprehensible stuff in English, if you want to. But you can also write Shakespere. French - even the French of Voltaire and Hugo - is still pretty much French.
In the Darwinism of languages, French (once the lingua franca of the world - note the irony in the term?) has been relegated to second-fiddle status and is on the decline, where English is now the closest thing to a global language we've got, and is on the incline.
So too is Perl.
Methinks you're confusing "art" with "fine art". Webster's entry for art doesn't mention aesthetics until the 4th definition, and even there, it doesn't make aesthetics a required component: "the conscious use of skill and creative imagination especially in the production of aesthetic objects". Note that it's 'especially', not 'only'. The skill and creative imagination appear to be much more central to the definition, and those things certainly play a role in programming.
Even if you insist on including aesthetics in your definition of art, there's a good case to be made that once a basic set of functionality is achieved in a piece of software, improvements in aesthetics can be more valuable than further increases in raw functionality: Consider two pieces of software that serve a similar purpose, one with boatloads of bells and whistles, and one with a smaller, simpler set of functionality. The former is inaccessible and hard to use -- sure, it can do lots of neat stuff, but it's so hard to figure out how to do most things that most users touch only a fraction of that functionality, and spend a lot of time frustrated with it. The latter has less raw functionality, but because it's simpler and more elegant ("elegance" clearly being an aesthetic quality), it's far more useful to most users in practice.
Your bridge example is misleading: The function of a bridge is far simpler in nature than the function of any reasonably complex software, and thus it's relatively easy to consider utility and aesthetics as distinct attributes of a bridge. It's not so easy to consider them as distinct attributes of software.
I write Perl too. I write Perl professionally and I do a professional job of it -- my code is organized into object-oriented modules that could pass for Java if it wasn't for the pointies and easier string manipulation. The documentation is Javadoc-style POD and it's kept up to date. Same thing goes for my PHP code, my C code, etc... I don't write Java code professionally anymore but that's where I picked up some of my documentation and OO habits, since I learned C++ as a scientific (computational) language. Anyways, discipline will see you through if you want it to. It's always more productive to just design and write the damn code than to hold meetings over which language to do it in.
However, Perl is really a language that I find more suited to "glue" than use on a continuing basis by teams of programmers. The vast majority of Perl (and a LOT of C++ for that matter) code I have seen used by teams was phased out MUCH faster than the equivalent PHP+C, Java, or Python code. Now with Inline.pm perhaps the horrible problems of using XS or Swig for wrapping "real" code are gone, but the fact remains, without a LOT of discipline and some bitter years of experience, Perl offers more chances for a programmer to take shortcuts. Again, great for quick glue jobs, but bad for long-lived projects. For what it's worth, the C++ code that got shitcanned was big on templates, gratuitous operator overloading, and all the other Perl-like shit that I hate in C++... if there's one good thing I can say about Java it's that it isn't C++.
But I *hate* the current Java platform with a seething passion. I don't really like C, and I can't hire a bunch of Common Lisp or Python programmers off the street. Ada? Probably, but who wants to deal with DoD curmudgeons? So every approach that I can see is a compromise in some respect or another. All the "good" ways to write code have their problems. Perl's problem is that it offers lazy programmers (oops, that was redundant) many, many ways to churn out spaghetti that "works"... for a while.
As un-fond as I am of fuddy-duddy computer scientists, their focus on formal correctness, proofs, and mathematical solutions to problems is really where it's at when you are solving a problem that hasn't been attacked before. If you're just re-inventing the wheel, Perl (or any other language) is fine, but if you need to parallelize development of some fast, bug-free innards code, it isn't what you want to release in.
I use Perl on a daily basis for configuration, scripts, etc. because it's the best tool for those jobs. Right now I am the only programmer on my team. When that changes again, I'm going to have to go back to a more easily maintained solution, which looks like it'll be PHP+C for most of my tasks. (did I mention that I hate Java with a seething passion? Too much work for too little payoff) This isn't too tough since PHP and Perl have equivalent means of using extension classes, etc. and PHP is actually easier than Perl to integrate directly with C (across-the-board, not just using Inline.pm, which I admit rules). Work with a large team doing development with some custom extension code, etc. and I'll bet dollars to donuts that you, too, will one day shrug your shoulders and admit that Perl is not right for all types of work. It's also a bit baroque and the syntax can be frustrating for people who aren't from a Unix background. I started out sharing your perspective years ago because Perl is SO very wonderful when you're working all by yourself. But it isn't so great when you're with a team. Especially if you are working on code that is inter-dependent with other programmers, it's important to be using the same or similar approaches to solving problems, and this is anathema to the TMTOWTDI credo at the heart of Perl. I'm not going to hedge on this claim -- I, too, make a LOT of money writing Perl and other code, I've done so for years, I appreciate the CPAN and Perl community, and I try to give back -- but I refuse to be a simp and just crow about how great Perl is for EVERY situation, when I have seen so much evidence to the contrary.
(It is still the greatest string manipulation and glue language known to mankind, though. And many of the one-offs I wrote in Perl have made my company tens of thousands of dollars. So the fundamental truth, "Use the right tool for the job" still holds!)
Remember that what's inside of you doesn't matter because nobody can see it.
Totally agree - what planet are some of you folks on?
Like any other language, you modularise when things start to get out of hand - too many of folks here have clearly never used perl in big projects and just assume we're all writing vast clones of bash scripts - that's just plain wrong. You also clearly define a house coding style at the outset of a project, and review regularly to ensure that style is enforced - perl can be as clean as you want it to be IMHO.
At my last company we used the usual suspects of apache, mod_perl, emb_perl with an Oracle backend to drive a big UK financial web site. We made heavy use of HTML components and modules, would use CPAN for existing solutions to problems, or write our own re-usable, modular code just like anyone would do in any other language. There is NO inherent limitation in perl preventing folks from doing that.
It was also interesting that we had the usual suspects complaining about site performance and how everything would be better with IIS/ASP or JSP - in virtually every case I was involved in we profiled the code and found it was caused by sub optimal database queries or database/network performance limitations, not perl itself.
Us poor misguided fools using perl on big projects are fully aware of how much perl can really do - equally we're aware of its few but definite limitations - OO is currently not a strength - but perl 6 should overcome this, and there is an impressive number of talented programmers out there working to deliver it.
Why not rejoice in the fact that we have such a wonderful variety of excellent programming languages - or would you all really prefer to be coding in C++?