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?
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
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.
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.
A good manager who knows about programming would hire him. The problem is they don't exist (or are very rare).
.com startup because you didn't know java yet.
One of the reasons for my irrational hatred of all things java is that a lot of people involved with it seem to think that java is a skill. It's not, it's knowledge. In my last company, we did a lot of programming with C and C++ and various technologies such as RPC, Corba, COM etc etc. and yet at least two people resigned because they couldn't put the magic j word on their resume. Careerwise at the time (pre dot bomb) they were right. You could have 10 years of C coding experience, a signed certificate from Donald Knuth that you were the top programmer of all time and you still couldn't get a job in a
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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.
;)
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!
You know, your entirely right. Your post echos a sentiment that is said and thought of quite often. The frustrating part is that the grandparent post reflects the majority of people's attitudes.
People can write obfuscated C yet you don't see (as many) people running around crying murder, mayhem, and the end of the world at C. It is just annoying to see people trash a language like that, for any reason.
I can write code that is completely unlike anyone else in my project in *ANY* language you can give me. It is the job of a good project manager to ensure that peer reviews are conducted in an orderly and sufficient manner. It is a good project managers job to come up with the programming standards for a project.
With standards on the style of how a language should be used and a disciplined team, your code is coherent. With an team that has less discipline you will see things are a bit more chaotic.
Notice, the language simply does not matter. Perl infact should be better in MORE projects if you can change the style and form of the code and the way you write it, simply because it suits more needs and projects that way.
All of this said, I don't use Perl as a personal choice. I never buy the argument Perl is hard to read or write just because it is Perl, I just don't use it.
yes - obvious as soon as I tried running it - lets see
perl -e '@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";
sub p{@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*
map{$P=$P[$f^ord($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;
map{$p{$_}=~/^[ P.]/&& close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];
sleep rand(2)if/\S/;print '
syntax error at -e line 4, near "&&}"
Line 4 , near "&&}"
perl -e '@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";
sub p{@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*
map{$P=$P[$f^ord($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;
map{$p{$_}=~/^[ P.]/&& close$_}%p;wait until$?;map{/^r/}%p;$_=$d[$q];
sleep rand(2)if/\S/;print '
tl hnU ei hPkaecJua/ sterrnoxr
Ok - I get it its a JAPH - and this guy has obviously cut and pasted
it from somewhere and something has munged his code - presumably the
slashdot form - hmmm -if he's posting HTML and there was to be a line
input operator pair there < > then they wouldn't display
properly in the browser. Wonder what the filehandle name could be - well
the only thing in scope inside that map { } block is the implicit $_
coming from the %p elements on the RHS of the map statement - lets try
that
perl -e '@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";
sub p{@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*
map{$P=$P[$f^ord($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;
map{$p{$_}=~/^[ P.]/&& close$_}%p;wait until$?;map{/^r/&& <$_>}%p;$_=$d[$q];
sleep rand(2)if/\S/;print '
Just another Perl / Unix hacker
Each letter appearing after a certain delay - hey , thats quite cute !
This took me lest than a minute to run debug and fix - without even
analysing the core algorithm there - just responding to the helpful
diagnostic messages emitted by the perl interpreter and fixing the
obvious syntax error ( with a little lateral guesswork ). Bear in mind
that (i)I am no perl guru , by any means and (ii) this
is a JAPH - its supposed to be a cute obfuscated bit of code
for people to have fun decoding and figuring out. So no, I don't
accept your point at all - would you judge the quality of the C
programming language based on the entries from the annual Obfuscated C
contest. No ? I'd also wager it would take you (or me) a damn sight
longer than two minutes to debug one of those beauties based
on someone elses poor transcription.
-- Oh Well