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.
Is that Damian dislikes C++ for the same reason he seems to support Perl 6. Both seem to have gone into comittee and emerged ugly, baroque monstrosities.
At least this interview didn't try to sell me a book.
Although slashdot loves to post Damian Conway stories, those who still haven't had their fill can follow his online diary at yetanother.org.
"The single most important skill is programming itself." Based on the way I think, I could become a good programmer. People have told me all my life that I'd make a good programmer. But if I don't have a drive to program, all of it is in vain.
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
The story
Free Java games for your phone: Tontie, Sokoban
Current projects:
Good God, vi?!
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.
By which of course he means good, gooder or goodest. Damn intellectuals.
Free Java games for your phone: Tontie, Sokoban
i found his choice of programming languages very interesting myself. he really seems to be a big fan of elegance. personally i've always found the idea of thinking of code as art to be rather offensive. i mean: i code and i appreciate art. i think to suggest that there is a crossover demeans both. not to mention that he praises the hypercard scripting language and i have something of a vendetta against it having spent several months once trying to update a massive piece of edu-software written entirely in uncommented hypercard script. blech.
lysergically yours
And if you divide a sibling variable by a knife variable, perl will have none of that mess, you'll have to garbage collect the mess yourself.
Free Java games for your phone: Tontie, Sokoban
Damian mentioned design patterns as one of the skills necessary to become a better programmer. As very little has been written about implementing design patterns in Perl, I've started a project to produce Perl implementations (and explanations) of the Gang of Four's patterns. Later, I hope that Perl-specific patterns may emerge, but for the moment I'm just trying to create interest in this important area for OO-Perl programmers.
Damian mentions "TMTOWTDI" several times but forgot to explode($acronym). What he's saying is that There's More Than One Way To Do It.
I read the article with an ever increasing sense of disbelief. Perl is definately a lanaguage for the individual rather than for groups or projects. One person on their own okay, but in a project....
Perl lets me to program in a style that suits me, rather than enforcing a style that some language designer thought would be best for me.
Now that is a quick way to bugger a project, everyone with their "own" style.
Perl is multi-paradigm: I can write code that's procedural, or object-oriented, or functional, or declarative; whatever solves my problem best. I can even mix styles when the optimal solution calls for that.
Leaving asside discussions on whether Perl is "mutli-paradigm" or indeed any language can be. This is another case of great for me, sucks on a project. You would never want to take this approach on a large project, it increases maintainance costs and learning costs for new people.
And then of course the piece de la Resistance... the most important skill is...
programming itself
Let me get this straight, its CODING ? Not Design, not Engineering, requirements, risk analysis or whatever but banging the code out.
I know this will probably get moded as "Flamebait" or whatever, but the reality is this is exactly the sort of language and approach that holds back software development and keeps us in the Dark Ages. Languages like Ada demonstrated clear advantages and had lower development and maintainance costs than C, so all new languages have their syntax based on.... C. Scripting languages have a history of producing huge amounts of unreadable and unmaintainable code.
Why can't we just grow up and realise that this is an Engineering discipline that deserves the same respect and approach as structural, mechanical or whatever engineering. If someone said "well I like using bamboo to build bridges, I'm going to build a 6 lane highway with it" we'd laugh. This guy is talking about the same sorts of things and promoting a language that has none of the advantages of bamboo for bridge building.
At least with people and languages like this, I'll never be unemployed, as there will always be buggered systems to fix or replace.
Newton stood on the shoulders of giants, we fail even to build on the work of pygmies.
An Eye for an Eye will make the whole world blind - Gandhi
> One thing I've noticed about Perl people is that > they are often very open-minded about using other > languages to solve a problem. I think its a result of hackishness: a common trait amongst perl programmers is to want to solve a problem in the fastest, simplest way possible and most are mature enough to admit their favourite language isn't always the right tool for the job.
Why has this been modded as a troll? What he's saying makes absolute sense.
The fact of the matter is that anyone who is involved in professional web site development will know that Perl is becoming less and less important as a scripting language, I believe precisely because of its design and philosophy.
Unfortuately, "Perl gurus" like to write programs which are as short and "clever" as possible. That type of programming is not compatible with large, professional software development projects.
Of course this opinion will probably be modded as a troll as well by those very same "perl gurus".
After all, I'm not hiring them to replace my domain expertise; I'm hiring them to get a job done -- a programming job. So I'm going to hire someone I can explain my problems to quickly (that's where the "minimal understanding" comes in handy), and then unleash them to develop a solution that's correct, efficient, robust, maintainable, under-budget, and on-time.
That's a great piece of insight that a lot of managers/employers/HR people need to keep in their hip pocket. It seems too many can be dazzled by the knowledge, but miss the lack of ability to perform their intended task quickly and efficiently!
If you don't like this . . . MOD someone else up.
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.
Here
/. effect...
a web hosting company... hmmm, maybe it will handle the
No coding is a craft or maybe engineering, not an art. An artist's objective is to produce something that has an aesthetic quality. An engineer's or craftsman's objective is to produce something that performs a function. "Aesthetically pleasing" is secondary. e.g. the function of a bridge is to get people or things across a river without them getting their feet wet
Craftsmen are artists, a lot of the time. Certainly you wouldn't say things like for example a table to always consider function over form. You might prefer a table that has been designed to be useful over it's appearance, but others might not.
Similarly, you might write code with esthetics a secondary concern, but others may not, witch would make their code art.
Certainly, not all code is art. And certainly some is.
autopr0n is like, down and stuff.
"Parse::Perl. Just as the name says, its goal will be to provide a pure Perl parser that parses Perl itself."
This could actually be useful for things like self-modifying code and the sort.
Of course, writing anything in Perl in the first place is a bad idea, but beyond that, self parsing could actually be useful.
now, if the had had a self-interpreter...
autopr0n is like, down and stuff.
Good grief - why not simply write a Perl syntax parser for Common Lisp?
...)
This project would also require
1) a mechanism to redefine class representations and instances on the fly - similar to
(defmethod update-instance-for-redefined class
2) a mechanism to "save core" under Perl (does this one exist yet?)
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...
You forgot to s/OpenBSD/Perl/g in the middle of your pathetic troll attempt.
Anyway: MS is losing market share in the embedded space. Is wince dead? No, unfortunately. So the whole argument is pants.
Just as the -- what is it? Program Extraction & Report Language (P.E.R.L.?) -- language grew from one-time Seattleite Larry Wall's kludgey geek code into the major glue that holds the entire World Wide Web together, so also the Mentifex Call to AI has stormed the far reaches of the 'Net and now needs Perl programmers everywhere to take up the once-in-a-species-lifetime Herculean task of creating Open Source Artificial Intelligence.
But Perl's just a scripting language... you may say dubiously and faith-lackingly. Fear ye not, for from the tiny acorn of Perl shall grow the mighty oak of Technological Singularity.
The original 26nov1994 Amiga Mind.Rexx AI used an IBM scripting language (REXX), whose ardent promoters are still licking their wounds from having lost the Web battle to Perl.
Although the AI Mind moved into old-fashioned Forth for robots, it quickly moved back into the scripting language of JavaScript, so Perl will hold its own against Visual Basic Mind.vb and against the object-oriented Mind.Java AI.
Perl programmers, do not be a dim bulb about whom people will say:
- "He is not the brightest crayon in the box."
- "His brain-waves do not reach the shore."
- "Er hat nicht alle Tassen im Schrank."
- "If you gave him half a brain, he'd have half a brain."
- "He's not playing with a full deck."
- "He suffers from weapons-grade stupidity -- it's dangerous to go near him."
Think different! Use your Perl skills to join in the last great intellectual Gotterdammerung of the human species.
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.
None of these are good reasons to use Perl. None! These are all reasons that Perl is a maintenance nightmare, and not at all suitable for programs in excess of five hundred lines, or programs that will ever have to be modified.
Even good Perl is some of the worst code I've ever seen.
Just say no.
Utterly rediculous.
You give one velocity. Actually a moving object under acceleration will have a changing velocity. Thus do we need to then worry about:
1. sampling rate for this variable
2. precision of the variable
In programming there is always a different way toedo things. The folks who say "have to" produce kludges like Windoze or Digital UNIX where everything is a non-deterministic messaging stack.
It works for small and trivial things but quickly becomes a mess.
In the case of doing PERL to track velocities I feel that this is an exercise in futility. Here is why:
There is no general case of utilizing velocities for solving a problem. The problem is always specific for whatever is needing to be solved. Imagine a situation where you are tracking all of the airplane traffic around a city. Do you think that a silly rule like "a distance and a time need to have a velocity variable" makes any sense at all?
I can imagine N planes each with varied degrees of sampling position and time.
In any case in order to determin velocity from position and time we need at least two samples of position and time. And then the velocity we get is not real anyway, but an approximation.
And so we see your little therom is incorrect. There will always be FEWER velocity measurements than position and time samples.
Thus do we then nessecitate an further variable that tells us the acuracy of the velocity prediction?
So . . .
those hard rules that you make need to be just put away.
As someone who has done velocity measurements from time and position data I submit that your heart is in the right place thinking about this as a pattern. It is just that you shouldn't be thinking in terms of PERL, but in concept space.
One thing further: for real-time velocity and position measuring of real-world systems with N components, PERL just ain't going to cut it, dude.
Yes, PERL is good for somethings, but don't waste your time writing PERL modules that provide a bad solution for a non-exisitant problem.
;)
When doing advanced perl programming I figure being autistic (Rain man) would help figuring out the syntax.
"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
who cares about damian conway, check out Heidi Wall
Here's why coding is an art: it can't (yet) be done well by a computer.
Why would that be a criterion for art? A computer cannot invent delicious receipes; a computer cannot discover interesting physics or mathematics; a computer cannot summon sophisticated legal arguments; if you put your mind to it, you will quickly realize how little can be done well by a computer and how many of those things it cannot do are not art.
... virtually anything can be art. You guys should see the elegant, clever, yet ever so functional layout of my Windows 98 desktop.
No, virtually every geek is overcome with the artifacts and evidence of their mere existence and calls them art out of their profound ignorance. I realize "art" is a convenient word, but it doesnt actually mean "everything".
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.
You don't have to be limited to what your compiler vendor supplies, or the extra libraries you (or your company) can afford. CPAN provides an enormous repository of useful (and usually well-written and well-tested) tools that no other language approaches.
But of course, you need to use perl.
Netlib may be the closest thing I know of for numerical analysis. While CPAN doesn't have the depth of numerical analysis the netlib does, it has much more breadth. I can usually find something that makes a new project much more quickly than I can code it up myself. CPAN is one of the big reasons I use perl
Keep you credit card in your wallet, leave the purchase requisitions in the file folder; keep your money and your sanity. Just check out CPAN!
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.
> Writing a book is a full-time job. Unfortunately, I already have a full-time job
> writing new Perl modules. And a second full-time job maintaining all my existing modules.
> And a third full-time job helping with the design and explanation of Perl 6. And a fourth
> full-time job traveling around the world speaking at conferences and Perl Mongers
> meetings.
> So taking on a fifth full-time job seemed a little...ambitious.
Isn't a full-time job one that you spend 40+ hours per week on? Since there are 168 hours in a week, even having FOUR full-time jobs would leave a mere eight hours PER WEEK for sleeping, eating, commuting, etc. And 40 hours is the bare minimum around here. I code Perl 50 hours plus per week for actual uses in the credit card industry, not making kooky new modules.
Give me a break, buddy. You aren't the only one who has to work for a living, and your job seems pretty cush... Quit it with the martyr syndrome, and write the damn book.
JM2C...
Jethro73
Quidquid latine dictum sit, altum viditur.
I used to do a huge amount of C++ programming too, and enjoyed it. But that was back before the committees got hold of it and turned it into a baroque monstrosity.
And there I was thinking Perl was pure baroque with all that weird syntax. The clarity of C on the other hand is Enlightenment. Which makes Pascal Renaissance.
So what would Leonardo da Vinci programmed in?
Oh, dear, there does the little karma I had
check out Playing both against neither (pdf format) which gets into the fallacy of the "exclusive or" mentality which seems to be apparent in many of the messages post here (so far).
The world is much too interesting, even the parts, like programming languages, which we've created, to be so easily pigeoned into such small compartments.
Well, this is a very old and relatively stupid debate (I think the first time I participated in it was when I was 13 or so on FidoNet, luckily i've learned since then.)
But it comes to mind that that most venerable CS author Knuth called his highly regarded series of books (or bibles depending on who you talk to)
"The Art of Computer Programming"
So maybe those that argue there is no Art in computer programming should take it up with him?
demerphq -> http://www.perlmonks.org
People who shove their backwards-ass supersition down other peoples' throats deserve a good beating. Christians especially.
Printing an array of hashes in Perl (lifted from O'Reilly book):
.. $#LoH ) {
.. $#$foo ) {
# print the whole thing one at a time
for $i ( 0
for $role ( keys %{ $LoH[$i] } ) {
print "$i: $role is $LoH[$i]{$role}\n";
}
}
in Python:
for i in range(len(list)):
for key in list[i].keys():
print i, ": " + key + " is " + list[i][key]
Consider line 2 of both examples. Perl's contains 11 non-alphanumeric typographical symbols. Python's contains 6. On a purely visual level alone, I can't imagine anyone preferring to maintain the former over the latter. Furthermore, Perl requires the explicit "% { }" foo so that it knows it's dealing with a hash, an issue Python doesn't face. (Orthogonality... now _there's_ a concept!)
Now take the above Perl example and imagine if you're using a _reference_ to an array of hashes, as in:
foo = \@LoH;
for $i ( 0
for $role ( keys %{ $$foo[$i] } ) {
print "$i: $role is $$foo[$i]{$role} \n";
}
}
Sweet Jesus, my eyes are hurting! I started using Python 6 months ago and for general purpose scripting, I swear I'll never go back to Perl if I'm not forced to.
Don't get me wrong - currently I am learning Perl by coding a somewhat complex (at least for a "first" project) CGI bookmark management system. I have yet to stray into the OO syntax of Perl yet, sticking with a functional approach for now. I am having fun, and enjoy coding in it. With that said, though...
I understand the sentiment of some when they equate Perl with "line noise" - we have all seen the lovely "one-line" Perl scripts which seem to "be all that and a bag of chips" - scripts that seem to do the impossible, sometimes.
I am sure we have all seen instances of this same type of coding within larger Perl systems, as well. I know I have looked inside some modules I have download, some code I have picked up in places, and nearly gagged at some of the stuff I have seen...!
Sure, it worked great - but unless you are a master regex wizard (regex is something I am still trying to grasp the complexities of - whoever came up with the system should be beat - I mean, if you want to do something complex, that is what coding is for - not everything should be done on the command line!) you can't understand it. Regex, unfortunately, seems like a "must-to-know" to do certain things in Perl, it seems. I don't want to really come across as knocking regex too much - I attribute that more to my lack of understanding. I am sure one day I will come to "love it".
I think what upsets me the most is that many of these "wizards" assume that because they wrote the regex code for a certain function, that others can easily read it. However, it is apparent by the number of people who refer to Perl as "line noise" that others find those expressions hard to read!
I think it would be better if those expressions were broken out/down into seperate lines, with comments explaining what each section is doing (why is commenting so hard for most programmers to do? You want fun? Wade through the Descent I code - this from a pro game house - hahahaha! - non-commented C code at its finest - but I digress). If they must, because of performance reasons (I don't honestly know for sure), provide the single line version as well, and put the multi-line version in comments or something.
Nothing makes me loath Perl more than trying to figure out the bits (that should be "huge bits") of regex almost invariably scattered throughout...
Reason is the Path to God - Anon
A majority of programmers I've known are the same; not many of the good ones, though. Almost no serious programs can be written properly by a single developer these days. I'd rather have a team of 5 competent but unexceptional programmers who understand the value of communication, than a team of 5 ueberhackers who can't or won't communicate with one another. The former will typically get the job done much better.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Or, to put it another way: the category of the process is not of neccessity related to the category of the product.
You appear to be suffering from homonymic category confusion
An art, as in artist, is to do specifically with aesthetically purposed construction.
An art, as in artifice or artisan, is to do with any skillful process requiring good judgement and expertise. Hence:
The process of generating science is an art.
The product, i.e. science, however aesthetically pleasing it may be to the scientist, is neither art nor its subcategory Art.
[Science, and code, may be aesthetically pleasing, but for the most part this is not their primary purpose - obfuscation competitions et cetera notwithstanding.]
As for the legal profession's antics, I guess a well written, superbly delivered oration could even be classified as a work of art. But to construct a good legal case is still more of an art than a science.
So, what of engineering and, more to the point, software engineering? Well, to me it is simple. One sense of art applies (artifice) and the other (aesthetic purpose) does not.
Sloppy coding and coding practices are neither.
Okay, I've stopped gibbering (for now). So flame me
[FWIW: I code and I daub]
__
Arse
A finite state machine is essentially a set of rules that operates on a string. Given the current state and the input one travels to a new current state. The theory of finite state machines is integral to the development of computer science and has a very strong mathematical foundation. A computer language that can be represented by a finite state machine is called a regular language.
This is where regular expressions come in. They are essentially user constructed finite state machines. The input is the text, and the state is the curent symbol (or symbol set). If you match the current symbol, you move to the next. If you don't you go back to the beginning. If you reach the end of the symbol set, you have a match.
Regular expressions weren't made up to confound you, they were the implementation of a sound mathematical method that is very useful for text processing. However, regular expressions by themselves are not enough to form a Turing Machine, or even an approximation of a Turing Maching (which is what the computer sitting on your desk is).
Moving to more practical matters; regular expressions are not easy to read. You're working on raw characters, and you have to have lots of escaped to handle everything. They become easier with practice, and are very useful. The biggest problem with them is that every application (Perl, vi, emacs, grep, etc) use their own syntax for them, which means you have to shift gears every time you try to use them in a different application. But that is a problem with the implementation, and not the tool itself.
The middle mind speaks!
Well, if you don't like the O'Reilly Example, there are several other ways to do this. Maybe you think the following is more clear?
Try
##>>> Build an Array of Hashes...
our @array_list = (
{ aaa => 111, bbb => 222, ccc => 333},
{ aaa => 111, bbb => 222, ccc => 333},
{ aaa => 111, bbb => 222, ccc => 333},
{ aaa => 111, bbb => 222, ccc => 333},
);
##>>> Loop d' loop...
foreach my $array_item (@array_list)
{
print "New Row! \n";
while( my ($key, $value) = each %$array_item )
{
print " Key: $key, Value: $value \n";
}
}
if the variable @array was a scalar ref this would be basically the same:
our $array_list = [
{ aaa => 111, bbb => 222, ccc => 333},
{ aaa => 111, bbb => 222, ccc => 333},
{ aaa => 111, bbb => 222, ccc => 333},
{ aaa => 111, bbb => 222, ccc => 333},
];
foreach my $array_item (@$array_list)
{
print "New Row! \n";
while( my ($key, $value) = each %$array_item )
{
print " Key: $key, Value: $value \n";
}
}
Both give the following:
New Row!
Key: ccc, Value: 333
Key: bbb, Value: 222
Key: aaa, Value: 111
New Row!
Key: ccc, Value: 333
Key: bbb, Value: 222
Key: aaa, Value: 111
New Row!
Key: ccc, Value: 333
Key: bbb, Value: 222
Key: aaa, Value: 111
New Row!
Key: ccc, Value: 333
Key: bbb, Value: 222
Key: aaa, Value: 111
I can think of several other ways to handle this, although I seldom need to write out code to parse though complex structures, since I can use data::dumper.
Of course, adding some documenation is always good for clarity.
Not that I have a problem with the python way. Looks cool to me. But I don't understand how it's really more self documenting than perl.
Peace.
Peace, or Not?
P.D.
-----------
I'd post as my self but I can't be bothered logging in
Most of the GOF patterns are specific to a class of languages, in fact they go further and embody implementation assumptions such as local vs. distributed, transient vs. persistent etc.
Take a look at how the estimable Peter Norvig achieves the aims of many of the patterns in LISP: Design Patterns in Dynamic Programming. Are these LISP implementations of the DP examples?
All in all, I don't really care about lines of code and efficiency (of execution). CPU time is absurdly cheap. Human time is extremely expensive. So I care about time to develop and maintain -- if that means a slightly longer, less clever, and easier-to-read approach to solving a problem, that's likely the one I'll choose.
"Biped! Good cranial development. Evidently considerable human ancestry."
My guess is that many programmers haven't had enough painful experience maintaining crappily-written code. Maybe the first thing that should be taught in CS 101 is not how to write "hello, world", but how to take a poorly documented and convoluted program written by somebody else and fix the bugs. (No flames about how CS is about computer science not programming; you know what I mean here.)
For me personally, the incentive to write more self-documenting code was having to maintain stuff I'd written and deployed in commercial environments for a period of years. I don't care how well you knew the code when you wrote it, when your customer unearths some obscure bug in five years' time you're not going to remember a damn thing. And that is a miserable experience. It taught me to take the time up front to save myself the agony down the line.
"Biped! Good cranial development. Evidently considerable human ancestry."
actually this post isn't about what u think at all. i just thought it amusing to note that an announcement about a major update to PHP gets a measly 20 comments, whilst a more general and waffly piece about Perl (interesting as it is tho') gets nearly ten times as many.
do i take it from this that /. readers are Perl hackers rather than PHP scripters? thought so.
nalfy.
-- Despair is an operating system that ANY human being can run, sort of a psychological JAVA --