Questioning the software for perfection!!

"Well, in general, the thing I don't like about other computer languages is that they're not Perl. :-) " Larry Wall, creator of Perl

2009-02-18T20:30:00.001-08:00

I was surfing for the information on Larry Wall, who made an immensely humble and transparent scripting/Programming language, I came across this article in slashdot.

Hope you enjoy reading it.

Interview of Larry Wall, the man who made the life easier for developers, DBAs, network Administrators and Testers.

1) Perl as a "scripting" or a "programming" language
by Marx_Mrvelous

I've been using perl for a very long time, but primarily as a scripting language. I indeed mostly use it for extraction and reporting. With the recent developments in perl, however, there seems to be the trend that perl is able to do much, much more (while retaining compatibility to be "just" a scripting language).

What do you think about how people are using Perl today? Are you satisfied that most people use it for simple tasks like log parsing? Would you like to see more advanced applications being built with Perl verses a compiled language?

I am perfectly happy for Perl to continue parsing logfiles. Perl has always been, and always will be (I hope), a humble language. When I am 80 years old, even if everyone in the whole world puts me on a pedestal and thinks I'm the renaissanciest man that ever lived, I still intend to take out the trash when my wife asks me to. Just because I'm learning Japanese doesn't mean I have to stop speaking English.

But just as people grow (and are stretched), Perl continues to grow (and be stretched). Perl has acquired new skills over the years, and people have been using Perl to do all sorts of things that are arguably at the limits of its capabiliites. The solution to that is not to stop people from doing that, but to increase Perl's dynamic range.

The thing is, people are already building more advanced applications with Perl. But there are some aspects of that process that aren't as easy as they could be. They're hard. In times past we were proud of the fact that the hard things were even possible with Perl5. We often chant the slogan: "Easy things should be easy, and hard things should be possible."

But as with any slogan, there are some qustionable assumptions hidden behind the sentiment. We assume that it's obvious which things should be easy or hard, and that the things that are currently easy are the things that ought to be easy. We assume that making the hard things easy will necessarily cause the easy things to become hard. But sometimes it's not obvious what should be easy or hard. Sometimes the wrong things are easy. And sometimes there are ways to make the hard things easier without making the easy things harder.

Some of the complexity in a Perl5 program is necessary to the solution, and some of it isn't. We can't eliminate the necessary complexity, but we can hope to get rid of some of the needless complexity. That will make everything easier. Well, most everything...

I'm really under no illusions that we can make everything easier at once. There's no such thing as a perfect language. Merely making a more expressive language means it's in some sense more difficult to learn to express yourself responsibly. That's the price of power. Manhattan will always be more difficult to understand than a set of beads.

But in any event, let me assure you that Perl6 will not be as difficult to learn as Japanese. :-)

2) Perl Beginners
by KoopaTroopa

I'm a CS student who's recently become very interested in Perl along with other languages. However, I don't really have too much everyday (or even occasional) need to actually USE much Perl. I am big into learning as much as I can about it for its own sake.

Now, for the question: Given this approach to learning Perl (just for a general working knowledge, maybe light usage,) is it really worth spending a lot of my time learning Perl now, or should I wait for the big Perl6 revision?

I don't think you would be damaged by learning Perl5, though I'm sure there are those who would disagree--or at least choose to be disagreeable.

It really depends on your curiosity level, I think. Some people would learn both Perl5 and Perl6 merely to see how a language design evolves over time. Those folks are pretty hardcore. Count yourself lucky if you're not one of them. But despite appearances, Perl5 isn't a totally horrible language, and we're hoping to save all the good bits of it in Perl6. People moving from Perl5 to Perl6 shouldn't find it too difficult to unlearn the naughty bits, especially since it's the naughty bits that tend to be frustrating. And if you're ever in a situation where you need to use Perl6 for real, it's likely you'll have to deal with legacy Perl5 code anyway. So as usual the answer is: "It depends..."

Gildor was silent for a moment. 'I do not like this news,' he said at last. 'That Gandalf should be late, does not bode well. But it is said: Do not meddle in the affairs of wizards, for they are subtle and quick to anger. The choice is yours: to go or wait.'

'And it is also said,' answered Frodo: 'Go not to the Elves for counsel, for they will say both no and yes.'

'Is it indeed?' laughed Gildor. 'Elves seldom give unguarded advice, for advice is a dangerous gift, even from the wise to the wise, and all courses may run ill. But what would you? You have not told me all concerning yourself; and how then shall I choose better than you? But if you demand advice, I will for friendship's sake give it. I think you should now go at once, without delay; and if Gandalf does not come before you set out, then I also advise this: do not go alone. Take such friends as are trusty and willing. Now you should be grateful, for I do not give this counsel gladly.'

3) Structured programming and perl
by slashnot007

The reason I like perl is it is not a structured programming language. In my work I find it is 50% a get the job done parsing language and 25% sequencer of programs and deamons and 25% major ojbect oriented programming effort often a cgi.

Thus I worry that perl has Python-envy. I've tried to use python several times but always go back to perl. The reason is my daily need for a parser dominates my choice of language and maintains my fluency, since I dont want to have to be fluent in both, perl becomes my language of choice for advanced tasks too, even though python might be better for strcutrued programming.

So my question is, is perl6 making make perl a structued language like python? Would it be a good idea if perl did not develop any further for fear of becoming too complicated and thus disorganized? (witness the evolution of java from clean slate to giant mess with intricate redundant libraries half of which are deprecated).

Er, what do you mean by "structured"? 25 years ago all of these languages would have been considered "structured", in the sense that a block generally has only one entrance point. (There were also people who thought that a block should only have one exit. Thankfully these folks did not prevail, since functions representing decision trees often have one entry but multiple exit points.)

But you obviously mean "structured" in a different sense, or perhaps several different senses. Syntax is structure, and different languages have different syntax, but I don't think that's what you mean.

I'll assume you mean "structured" the way a grade school teacher means it, as in "structured play time", as opposed to "free play time". Python's slogan is "There's only one obvious way to do it." That's fine from the computer's viewpoint, but kinda su*ks from the human viewpoint. "You can play any game you like, as long as it was organized by the teacher."

Java was, in that sense, much less structured than Python, I think. That's part of the reason for Java's success, but it came at a price. One of the problems with Java is that they swept a bit too much of the innate complexity of life under the carpet of the libraries. And so now they've had to replace the carpets several times.

So, yes, Java started with a "clean slate", but it was a rather undersized slate, methinks. But as for "structured play time" in Java, the structure has been imposed more by cultural norms than by the language itself.

As for Perl, it has never been "structured" in that sense, though it has always been structured in the sense that you can create as much structure as you like. The whole point is that the structure is optional, not imposed externally. If you're playing with your schoolmates at recess, you can always choose to organize a football game, but the teacher isn't making you do that.

Playing football is like programming in the large. You have to agree on a lot of rules to do it with other people. Perl5 doesn't make it terribly easy to agree on a set of rules, and we hope to make that easier in Perl6. You have to have discipline to do programming in the large, but you'll choose the discipline by turning up the big discipline knob yourself, not by having someone else turn it up for you. Perl6 will give you the big knob.

I am philosophically opposed to turning up the knob for you, because I don't know how fast you want it turned up. (Perl6 will turn it up for you a little by default--if you write a module or class, it'll automatically default to a stricter mode than it uses for your main program.) But the reason I don't like doing it for you is that you know how fast you want to learn, and I don't. As Gildor says, you haven't told me enough about yourself for me to give you advice. If I don't know how hard you can paddle, I can't tell you how big of a wave to try to catch. We all have to start with the small waves.

We find the same problem in teaching reading to kids. Some people shout "Whole language!" while others shout "Phonics!" Well, guess what, they're both oversimplifying. You have to learn some phonics, and then you learn some larger bits based on that, and some larger bits based on that, and eventually you find that you're intuiting whole language. The whole language folks fall into what I call the "Expert Fallacy". You look at how experts do something, and assume that's how everyone should do it. There are some people who are natural readers. They naturally figure out the bits and pieces themselves. But if you try and teach everyone that way, half your kids never figure out the phonics.

Programming is the same way. Language designers tend to look at how experts program and then think that everyone ought to learn to program that way from the start. That's a bit like expecting a new surfer to do well on 40 foot waves. Some will make it, but most will wipe out.

Perl is designed to help people learn the bits of programming they need right now without forcing them to learn the techniques they aren't ready for. But when they are ready for them, Perl tries to be there too. We just don't tell the beginners that the speedometer on their golf cart wraps around several times.

4) What will you *not* put into Perl 6?
by TreyHarris

What would you say has been the number one requested feature that you will not put into Perl6, and why not?

That depends on what you call a feature, and what you call a request. If you look at all the RFCs at dev.perl.org, you'll find that most of the feature requests are bogus on some level or other because they tend to suggest bandaid solutions. Nevertheless, I think it's best to treat them all as a "cry for help". With computer languages, about 75% of the bandaids have a bullet hole underneath.

So, for instance, I officially rejected the RFC asking for multiline comments, while actually accepting the underlying premise that it was too difficult to do block comments. But the better solution is not to introduce more syntax, but to fix the POD syntax to do what people want.

But this is Perl, after all, so there has to be more than one solution. The other solution is to make the Perl grammar malleable enough that the user can install their own multiline comment mechanism anyway via a pragma, so there! That's fine by me, as long as the syntactic warpage is lexically scoped. "All is fair if you predeclare."

Another often-requested feature that's not going into Perl6 is implicit lexical declarations. That's one of those features that seems like a good idea when you're looking at small snippets of code, but it breaks down when the scopes get larger than you can see in a glance. Scoping by indentation has the same problem, but nobody has seriously requested that for Perl6, for some strange reason...

Now you might think that getting rid of the $, @, and % sigils would be the number one requested feature, but typically that is suggested only by people who don't know Perl and probably wouldn't use Perl even if we did get rid of them. The folks who know Perl tend to like the sigils.

5) perl vs other languages
by larry bagina

Whenever perl pops up in slashdot, there are plenty of language zealots claiming perl is obsolete and you should really be using php or ruby or python instead.

What are your thoughts on these other scripting languages? What do you like about them, what do you dislike?

Well, in general, the thing I don't like about other computer languages is that they're not Perl. :-)

Seriously, Perl matches the way I think pretty well, because what I mostly want in a computer language is a wide dynamic range. I want a language in which you can say both dirty, low-level stuff and fancy, high-level stuff. I want a language where both baby-talk and fluency are acceptable. Other computer languages tend to try to level those distinctions.

As for specifics, I must say that the example of Ruby is the main reason I decided against implicit lexical scoping for Perl6. We'll be sticking with explicit my declarations. But I have to like the majority of Ruby simply because that's the part that was borrowed straight out of Perl. :-)

I also liked Ruby's unary splat operator, so I borrowed it for Perl6.

The main problem I see with Ruby is that the Principle of Least Surprise can lead you astray, as it did with implicit lexical scoping. The question is, whose surprise are you pessimizing? Experts are surprised by different things than beginners. People who are trying to grow small programs into large programs are surprised by different things than people who design their programs large to begin with.

For instance, I think it's a violation of the Beginner's Principle of Least Surprise to make everything an object. To a beginner, a number is just a number. A string is a string. They may well be objects as far as the computer is concerned, and it's even fine for experts to treat them as objects. But premature OO is a speed bump in the novice's onramp.

I confess, I have a soft spot in my heart for inside-out languages like PHP. The first real compiler I ever wrote was for a sort of text-processing macro language in which the commands were embedded in the data. This is part of a more general class of programming languages in which a peculiar form of processing is assumed by default, such as the pattern/action syntax of awk that assumes an invisible outer loop.

Perl can do that, but it's not the default. I think languages like awk and PHP hobble themselves in the long run by attaching themselves to a particular ecological niche, particularly when a generalist like Perl can effectively occupy the same niche. So I've never felt tempted to even try PHP. I'd only be speaking second-hand if I said that PHP has some serious namespace and extension mechanism issues. So I won't say that. :-)

Python is cool to look at small bits of, but I think the "outline" syntax breaks down with larger chunks of code. I'm with Aristotle on the structure of discourse--a story should have a beginning, and middle, and an end. So should blocks.

There's something to be said for forcing everyone to code in the same style, but that's not the Perl Way. At least, it's not the default Perl Way. But all is fair if you predeclare. It's perfectly fine for you to import a pragmatic module that enforces a certain style policy. It's even fine if your company forces you to import that pragma. Of course, if you want real programming discipline, I'd suggest you use Damian's Klingon module...

6) Perl and .NET
by prostoalex

What is your opinion of .NET in general and Perl's role in it? Given that .NET supports Perl as one of the languages would you recommend actually using it for any projects? Do you see good future for this tandem?

As far as I'm concerned, .NET is just another architecture that we need to port Perl to run on natively. The current approach to .NET interoperability is a bit of a hack, I think. That is partly Perl's fault for not having a sufficiently powerful type declaration system, but it's also a problem that .NET doesn't really support dynamically typed languages very well. I foresee that we'll have something like a Parrot interface that functions as a (hopefully thin) layer of glue over other VMs such as .NET or Java machines. The less impedence mismatch there is, the thinner the layer can be.

I recommend that you use Perl where it makes sense to use Perl, and avoid using it where it doesn't make sense. I am not the judge of whether it makes sense to use Perl on .NET, simply because I'm way too ignorant and stupid to be making those kinds of decisions for you. Sorry.

As for the future, I really don't know. Long, long ago (when our galaxy was far away) I shoehorned Perl and Java into the same process, and it never aroused much excitement. Certainly the Java folks tend to turn up their noses at non-100% Java solutions, but it got a pretty chilly reception from the other end as well. By and large, Perl programmers don't seem to have much appreciation for Java. I think the language architects who aren't living in reality tend to like multi-language solutions a lot more than ordinary folks do.

Which is, of course, why we're doing exactly the same thing with Parrot. Go figure. :-)

6.5) From a project managers prospective
by mustangdavis

What are your thoughts on the comments made by people that Perl is not designed for projects that require more than one programmer? Many people have stated over and over again that Perl code can not be managed by more than one person ... what are your thoughts on that statement? How would you manage a large Perl project? Do you think Perl should be used for large projects? (or should it be used strictly as a "quick and dirty" programming language?) BTW: I love your work (someone had to say it)

I do not manage any large projects, appearances to the contrary notwithstanding. I haven't an executive bone in my body. All my managerial skills are delegated. Ask anyone I've delegated to...

However, those who claim that Perl code cannot be managed by more than one person are obviously smoking something worse than crack. They're simply ignoring the many examples of people who have done just that. But you wouldn't expect to hire random people off the street to come in and collaborate on writing a novel. You can do it by hiring a few good novelists who already know how to figure out how to work together, or at least how to fight with each other productively. In the absence of that level of expertise, you can also do it by setting up policies under which random people can work, rather like the rules for writing about the world of Liavek, in which, for instance, every story has to mention a camel.

That being said, there are things we can do to make Perl6 better at helping managers and architects set up such policies for programming in the large. Having a standardized opaque object type will help there as well. Nobody is going to claim that Perl6's OO is "bolted on". Well, except maybe for certain Slashdotters who don't know the difference between rational discussion and cheerleading...

7) Role of Religion?
by Anonymous Cowdog

I remember reading at some point that you are a Christian, and there have been suggestions that some of your early missionary impulses (a desire to do good, help others) are perhaps part of the zeal you have put into Perl over the years.

Preferring a scientific view, I am not religious, and have no desire to be. Perhaps there is a God, but if there is, I think he/she has no opposable thumbs; in other words, has no power to change anything; reality is just playing out according to the laws of physics (whatever those are).

Please tell us how in the world a scientific or at least technical mind can believe in God, and what role religion has played in your work on Perl.

Well, hmm, that's a topic for an entire essay, or a book, or a life. But I'll try to keep it short.

When you say "how in the world", I take it to mean that you find it more or less inconceivable that someone with a scientific mind (or at least technical mind, hah!) could chooose to believe in God. I'd like to at least get you to the point where you find it conceivable. I expect a good deal of the problem is that you are busy disbelieving a different God than the one I am busy believing in. In theological discussions more than any other kind, it's easy to talk at right angles and never even realize it.

So let me try to clarify what I mean, and reduce it to as few information bits as possible. A lot of people have a vested interest in making this a lot tougher to swallow than it needs to be, but it's supposed to be simple enough that a child can understand it. It doesn't take great energetic gobs of faith on your part--after all, Jesus said you only have to have faith the size of a mustard seed. So just how big is that, in information theory terms? I think it's just two bits big. Please allow me to qoute a couple "bits" from Hebrews, slightly paraphrased:

You can't please God the way Enoch did without some faith, because those who come to God must (minimally) believe that:
A) God exists, and
B) God is good to people who really look for him.

That's it. The "good news" is so simple that a child can understand it, and so deep that a philosopher can't.

Now, it appears that you're willing to admit the possibility of bit A being a 1, so you're almost halfway there. Or maybe you're a quarter way there on average, if it's a qubit that's still flopping around like Shoedinger's Cat. You're the observer there, not me--unless of course you're dead. :-)

A lot of folks get hung up at point B for various reasons, some logical and some moral, but mostly because of Shroedinger again. People are almost afraid to observe the B qubit because they don't want the wave function to collapse either to a 0 or a 1, since both choices are deemed unpalatable. A lot of people who claim to be agnostics don't take the position so much because they don't know, but because they don't want to know, sometimes desperately so.

Because if it turns out to be a 0, then we really are the slaves of our selfish genes, and there's no basis for morality other than various forms of tribalism.

And because if it turns out to be a 1, then you have swallow a whole bunch of flim-flam that goes with it. Or do you?

Let me admit to you that I came at this from the opposite direction. I grew up in a religious culture, and I had to learn to "unswallow" an awful lot of stuff in order to strip my faith down to these two bits.

I tried to strip it down further, but I couldn't, because God told me: "That's far enough. I already flipped your faith bits to 1, because I'm a better Observer than you are. You are Shroedinger's cat in reverse--you were dead spiritually, but I've already examined the qubits for you, and I think they're both 1. Who are you to disagree with me?"

So, who am I to disagree with God? :-) If he really is the Author of the universe, he's allowed to observe the qubits, and he's probably even allowed to cheat occasionally and force a few bit flips to make it a better story. That's how Authors work. Whether or not they have thumbs...

Once you see the universe from that point of view, many arguments fade into unimportance, such as Hawking's argument that the universe fuzzed into existence at the beginning, and therefore there was no creator. But it's also true that the Lord of the Rings fuzzed into existence, and that doesn't mean it doesn't have a creator. It just means that the creator doesn't create on the same schedule as the creature's.

If God is creating the universe sideways like an Author, then the proper place to look for the effects of that is not at the fuzzy edges, but at the heart of the story. And I am personally convinced that Jesus stands at the heart of the story. The evidence is there if you care to look, and if you don't get distracted by the claims of various people who have various agendas to lead you in every possible direction, and if you don't fall into the trap of looking for a formula rather than looking for God as a person. All human institutions are fallible, and will create a formula for you to determine whether you belong to the tribe or not. Very often these formulas are called doctrines and traditions and such, and there is some value in them, as there is some value in any human culture. But they all kind of miss the point.

"Systematic theology" is an oxymoron. God is not a system. Christians are fond of asking: "What would Jesus do in this situation?" Unfortunately, they very rarely come up with the correct answer, which is: "Something unexpected!" If the Creator really did write himself into his own story, that's what we ought to expect to see. Creative solutions.

And this creativity is intended to be transitive. We are expected to be creative. And we're expected to help others be creative.

And that leads us back (finally) to the last part of your question, how all this relates to Perl.

Perl is obviously my attempt to help other people be creative. In my little way, I'm sneakily helping people understand a bit more about the sort of people God likes.

Going further, we have the notion that a narrative should be defined by its heart and not by its borders. That ties in with my linguistic notions that things ought to be defined by prototype rather than by formula. It ties in to my refusal to define who is or is not a "good" Perl programmer, or who exactly is or isn't a member of the "Perl community". These things are all defined by their centers, not by their peripheries.

The philosophy of TMTOWTDI ("There's more than one way to do it.") is a direct result of observing that the Author of the universe is humble, and chooses to exercise control in subtle rather than in heavy-handed ways. The universe doesn't come with enforced style guidelines. Creative people will develop style on their own. Those are the sort of people that will make heaven a nice place.

And finally, there is the underlying conviction that, if you define both science and religion from their true centers, they cannot be in confict. So despite all the "religiosity" of Perl culture, we also believe in the benefits of computer science. I didn't put lexicals and closures into Perl5 just because I thought people would start jumping up and down and shouting "Hallelujah!" (Which happens, but that's not why I did it.)

And now let's all sing hymn #42...

8) Thanks Larry
by wdr1

Like many others, I love Perl. I use it both professionally and personally. You've not only helped make my career, but also given me a very pleasent past-time. I was wondering what I can do to say thank-you? Can we give you money? Dontate something to someone, etc.?

When the new Programming Perl came out, I didn't really need anymoe (viva perldoc!), but wanted to make sure I was putting a few bucks in the pockets of those who made Perl great. What else can I do to say thanks?

Hmm, what timing! You must be from one of those churches where they pass the offering plate right after the sermon... :-)

Even just saying thanks is much appreciated. But if you want to help out more, there are lots of places to donate time or money. Unfortunately, it takes time to figure out how to donate time, since you have to hang out with various interest groups until you get, er, interested in one of them. But it's part of Perl culture to value contributions to Perl culture, so don't hold back just because your contribution is not somehow technical. That's not how we work.

Donating money is easy (except, of course, for the money part). Tax-deductible contributions can be made to the Perl Foundation. Much of my support for this year has come through the Perl Foundation--my full-time work on the Apocalypses would have been impossible without it. If you can persuade the companies you work for to make donations or to match your donations, that's also a worthwhile investment of time (and in some cases, agony). Please allow me to express my sincere gratitude here for everyone who has contributed already. This program is made possible by viewers like you.

9) perl 6 niche
by maraist

perl 1-5 have been great UNIX configuration/management languages. This includes small-scale webserver platforms. It's very difficult to find any other language that is as versitile in this respect where it reigns in it's niche. It is the perfect combination of speed, power, simplicity and huffman encoding (especially given the co-UNIX-tools look-and-feel).

Perl6 on the other hand, changes this formula around; favoring a more general solution that potentially reduces performance (due to abstractions), and deviates substantially from the UNIX-family-syntax - Namely: c-ish-syntax ( colon, question mark, select, exception-handling, etc), awk/sedish reg-ex's, raw c-libray-wrappers, etc. It was these very similarities that made learning and accepting perl so trivial since learning CIS and UNIX administration was sufficient to master perl in 2 days.

My question is: does perl6 have a niche in mind? Or is it spreading itself too thinly; competing more and more against Java/python/C# and thus losing it's identifiable niche?

Excellent question. I love the evolutionary biologists' way of talking about organisms as if they're evolving on purpose: "I think I'll develop feathers now and become a bird...", though in Perl's case, of course, there is some amount of purpose in my head (some would say "not enough"), not to mention the heads of other Perl developers (some would say "too much" (or is it the other way around?)), but it's still great fun to talk about Perl as if it were its own beastie, or as if it were a character in a novel that runs away with the plot despite the intentions of the author, kinda like this sentence has.

Anyway, from the start, Perl has never really been satisfied with staying in any one particular ecological niche. That's not terribly healthy approach in evolutionary terms, especially when your niche goes away. Perl's been pretty lucky so far to land in stable niches, but if some of its current niches dry up someday, that's really only to be expected, and indeed almost hoped for. It's probably the fault of closing ecological niches that we aren't all still swinging from trees, after all. (Of course, some of us still are, but that portion of us isn't heavily represented on Slashdot. Er...appearances to the contrary notwithstanding.)

Perl started out as just a text processing language--a better awk and sed--but it very rapidly spread to the ecological niche of system administration. On Unix, at least, a lot of system administration is text processing. With version3, however, Perl very intentionally escaped the text-processing-only niche by adding the capability to process binary data. Perl4 UNintentionally spread from the sysadmin niche into the CGI/Web niche. Perl5 accellerated that trend by intentionally occupying the extensible-glue-language niche, which had the unforeseen (by me) but predictable result of enabling Web sites to hook all their backend databases to the various textual Internet protocols.

But if you're worried about Perl trying to inhabit the "good for everything" niche, that's actually been Perl's intention since Perl5 came out. After all, you can't add OO to any language without making it perfect. ;-)

Seriously, I think that, for many of the people who use Perl today, the ecological niche they're thinking of is already labeled "everything", even if it isn't quite. For those folks, trying to make Perl better for the "everything" niche is not really an issue--they're already panting for it. These are the people who will actually carry Perl over to the next ecological niche it spills into, and the ones after that. I just made Perl a glue language, and other people applied it to bootstrapping the Web. Making Perl the best tool for growing programs from small to large is actually one of the underlying design goals of Perl6. But other people will use that to inhabit, or even create, other ecological niches. I hope to be surprised again as I was with the Web. I could, of course, be completely wrong.

10) How to get people to take Perl seriously
by kin_korn_karn

I'm a perl programmer who uses it daily. The push is on from the C?O types to get rid of Perl, even though a bunch of us here know it and are very proficient and fast with it. The new standard is Java with web services and all that other BS. This sickens me, because a) I'm biased towards Perl and b) I know Java is simply a fad language and the overhead/infrastructure only serves to give do-nothing architect types jobs.

The high-level technical people in my company don't take Perl seriously. They see it as some kind of super-Awk or an artifact of the early days of the web. Smart people know better, but we're not in charge.

What do you think it would take to get people to take Perl seriously as a programming language [again]? Is widespread use of Perl a goal of yours, or do you not care?

Well, if Java really is a "fad" language, we don't have to do anything to beat it, now do we? :-)

Leaving that aside, my goal is (and has always been) for Perl to be as useful as possible. It naturally follows that if people are avoiding Perl for artificial reasons, Perl is not being as useful as possible. So there's a place for advocacy. It is an unfortunate fact that, human nature being what it is, an ounce of cheerleading often beats a pound of rational discussion.

However, my job is not to lead cheers, but to make sure that Perl is designed to be maximally useful. It has never been a direct goal of mine to be "taken seriously". For good or ill, I am composed of far more levity than gravity. And I'm afraid some of that rubs off on Perl, too. But if Perl is everything it ought to be, it will naturally attract serious attention over the long term. If ecological niches are natural, and if nature abhors a vacuum, it follows that ecological niches abhor vacuums too. I expect to hear some great suc*ing sounds over the next ten or twenty years.

Source: http://interviews.slashdot.org/article.pl?no_d2=1&sid=02/09/06/1343222

Pe(a)rl!

2009-02-18T20:12:00.001-08:00

Automation always fascinates a tester. Even it has sowed a seed in the naive(in automation) mind of this blogger. I was thinking where to start with. I worked on perl once and my love for this language never faded off. It is the most beautiful scripting/programming language I ever came across.

It is so adaptable and flexible in usage that DBAs, web developers and testers equally use it with ease.One more thing I like about perl is the usage is regex which makes it very efficient in performance.

One of the major myth about perl is that it is a procedural language…I must shout and repeat "PERL SUPPORTS OBJECT ORIENTED PROGRAMMING!"

People also say it is not a comercial product, so we can't count on it much…People have stopped respecting the things which are available free. Open your eyes and Google it. Most of the beautiful things around us are free. Larry Wall has been very kind on us for not commercialising perl.

In this object oriented world of JAVA, where there is no use of reference and pointers (which is a superficial claim, now and there I see "null pointer exception"! ), people find the usage of reference in perl hard to use.

Perl has two slogans:

There's more than one way to do it
Easy things should be easy and hard things should be possible

I am going to take a dip in the world of Perl again…no matter what… catch you soon!

PS: The details author mentioned here is a combination of his personal experience on perl and current research on internet to start the 'perl'ing again!

The Black Hat!

2008-03-18T10:24:00.000-07:00

I have been reading this book named '6 thinking hats' by Edward de Bono since last 2 days. Book says every individual can think under 6 hats or 6 categories. And this kind of thinking results in efficient usage of time and helps in a better decision making. Blue hat is the moderator hat. It will guide the thought flow process. White hat deals with facts and figures. It has no emotions attached. Wearing a green hat signifies the thinking is diverted for fresh ideas. Yellow hat signifies the thoughts which concentrates on positive aspects associated with a decision. When an individual wears the Red hat he/ she thinks with a higher emotional quotient. When someone is said to wear a Black hat on a topic that implies the individual will be cautious and will emphasize on the negative aspects.
I found this black hat very interesting and to my surprise Edward de Bono thanked only the Black Hat in his acknowledgement. My interest in the black hat is due to the kind of thinking a user switches to, when he wears this hat.User takes a stance of critic, thoughts are now concentrated on the negative aspects. The user becomes a devil's advocate.
My interest in the black hat is also due to the fact that, this is the hat which a software tester is proud and anxious to wear. While reviewing the requirement documents, while writing the test cases and so on. Because it is in our blood… to be cautious, not just being cautious but extra cautious.
This is the attitude which a tester should have order to nurture and deliver a better application or product.
But the black hat needs to be removed at once when we are talking to developer regarding a defect. We wear a white hat; show him the impact or severity of the defect. Talk in figures and facts. While we are discussing a CR or a suggestion which needs to be implemented; we wear a yellow hat.
At this point I questioned myself: Why can't a developer put a black hat while testing and then a yellow or green hat while coding? The answer is: No one will criticize oneself when:
1. one 'believes' that he is right and what he is doing is 'acceptable' (acceptable as per the requirement and design document).
2. one cannot see the broader view and overall affect when he is dealing with a smaller portion. ('Module-based' development)
Don't forget to wear the black hat next time you test!!

Testcases

2008-03-07T18:33:00.000-08:00

3 years back, when I started my career in testing, testcases and testcase writing were something I hated the most. Now I feel it is the most basic and unavoidable entity in the testing field. Testcase writing substantiates the testing thought flow and, reviewing them solidifies those collections of thoughts or logic which were gained from the design docs and requirement docs. Testcase creation should be started from the requirement phase and will go till the coding phase. Each for one phase

Testcases should have a proper format which, of course depends upon the standards of your organization. A good testcase document should contain following information.
Module Name: For any software made or in-making should have modules or functionality.
Type of testing: Unit, System, Regression etc
1. Testcase ID: Every testcase should be identified by a unique ID. The implicit details which should be reflected through the ID are functionality, Module and sub module.
E.g. testing a “parameterized report for the delayed payment”. Here report is functionality, Module is delayed payment. We will be testing the parameters one by one.
2. Testcase Name: Name of the test case should summarize the activities of the tester.
3. Steps to reproduce: Now, this is the most important part in the testcase, the part which should be so simply and elegantly written to be understood by a layman.
4. Expected result: What is expected from the application?
5. Actual Result: What application gives to the user?
6. Pass/Fail: Is the testcase passed or failed?
7. Defect ID: If the testcase fails, log it. Enter the defect Id in the testcase document. ( This makes me happy…I am explaining it J)
8. Test Run ID: Which is the run of these testcases? First run? Second Run? Third Run? You need to know and record it.
9. Test Run date: Date at which the test run.
10. Tester’s Details: Name, ID.

What defines a good testcase document?
The testcase document which helps the tester to hunt down the maximum number of bugs can be defined as a good testcases document. It should contain both positive and negative cases. Yes, Positive testcases too, a tester is neither supposed to trust the developer nor what he “thinks”.

Sustained excellence is possible....

2007-10-04T01:40:00.000-07:00

Following is an article which I got in mail .. I liked it so I am sharing it with all....

Excellence is self-explanatory. Where there is excellence, explanations are not required. Where explanations are required, rarely do you find excellence.

What's okay is okay and what's not okay is not okay. However, we have a tendency to explain, justify, reason and rationalise what's not okay as okay. Hold it. Once you develop this tendency of using your mind to make what's not okay look okay, you press your own self-destruction button. The mind that gets trained into justifying lack of excellence learns to settle for compromises - it learns to live with compromises.

If you have scored 88 out of 100, the fact remains that you have fallen short by 12. How much ever you explain, you've still fallen short by 12. Communication cannot make up for the 12. You are attempting to explain as though 88 is actually 100, though you yourself know that 88 is only 88.

The saying goes - a lie told a thousand times becomes the truth. To others, it may appear to be the truth. You can do your best to make it look like the truth, but you will always know that it is a lie. Even when I am not comfortable with myself, I can tell the world - "I am on Top of the World." But I know the truth of the matter. For how long can you make a cat look like a lion? You can neither hide the fact from yourself, nor hide yourself from the fact. What is short is short. Explanations can never make up for the shortfall.

If your target was 40 lakhs and you did only 36 lakhs, then you've fallen short of your target. If the delivery was to be made by Monday but it happened only on Friday, then you have failed in your commitment. If your appointment was for 11.00 and you turned up only at 11.15, then you are late. Much after you have explained everything in every possible way, the fact remains that you didn't achieve your target, that you failed in your commitment and that you didn't respect punctuality.

Of course, it is soothing to justify non-performance. It acts as a psychological pain balm. It relieves you from the burden of hurt. However, self-consolation for lack of excellence will hurt you very badly in life. Time and again, it will make you fall short of the mark and you will eventually fall short of what you are capable of. Wake up. What's not okay is not okay. 6.01 is not 6.00; Monday alone is Monday.

'Zero defect' is possible. Precision is possible. Sustained excellence is possible. It all starts with the attitude of refusing to settle for anything but the best. It's a funny thing about life that if you refuse to settle for anything but the best, it often gives it to you. Lack of excellence should hurt. That which hurts, instructs. That which instructs, creates. Get created. Create excellence.

Communication with developer

2007-09-14T22:20:00.000-07:00

Better communication is an ability which the tester should possess to understand the product better and hence achieve a smoother release. Simple formula is to 'Ask a lot of questions'. How tight the situation be. One has to clear all doubts about the functionality before proceeding with the testing.
If we lack to understand the functionality or what the product is supposed to do, in an appropriate manner, it will result in catastrophe.
I would like to narrate an incident which happened during the initial stage of my career..
I tested the functionality with so much enthusiasm that, within 5 mins I got 5 bugs in the application.. :-). I stopped the testing for a while and I thought,something is fishy here.. either the developer is a dumbass or I am extra genius. Bugs which I caught were not the one which needed a genius, those we simple..too simple.

At the initial stage of my career I did not have the courage to judge the developer. I stopped my work there. I took a notebook and pencil, and went directly to the developer. He explained me the whole functionality. There it turned out that most of the bugs( as per my judgment) were features :-).

Did you see..what brings communication to a process...to the methodology of testing.

Should code be made visible to the tester ?

2007-08-21T02:48:00.001-07:00

This question arose to me when I was suffering very badly, thinking of the influence of a particular task to the application. I felt every time that these test cases are not sufficient..I have to create more test cases.After testing those, again the same kind of feeling ..(the term 'deja vu' is suitable :-) )

I feel, "Yes, why not!". Now to explain why I strongly support we need to consider all the ill-affect of not giving access of the code to the tester.

Tester's life revolves around the test cases. Let it be any testing type..functionality, regression, re-testing so on..

If we want to cover all the details of a particular test we will have infinite number of testcases.

Even if you are very much experienced in that application you are prone to waste some amount of extra time for testing a particular change, because you are unaware where the code is changed, what are the sections getting affected by this change, and hence clueless about what to test which results in the 'Deja vu' experience I explained above.

Now lets say, the code is accessible to the tester and the tester can view the code change, if it is in a particular function you can search the entire codebase for that function call and check out where all it is getting called and depending upon the tester can plan how to proceed the testing. The severity of the task or the change is directly proportional to the number of times that particular function is getting called.

As the code is visible to tester a better, effective, cleaner and precise the test cases become, which leads to saving of lot of time and frustration of the tester.

Now there is a confusion here..is this a whitebox testing type ??

That depends on the perspective of the tester. If he is interested in the internal business logic and more concentrated on the naming or say the coding conventions or the loops and conditions involved in the code he is doing white box testing.

If the tester is satisfied by the boundary of the change associated with the task or the scope of the code change and creates his testcases keeping them into consideration. Then what the tester does is a blackbox testing.

Depth of Testing

2007-08-15T09:21:00.000-07:00

Testing is more about heuristics than its about the computer science.A testing professional has to keep his eyes and ears open.
Complete testing is not something which you can gauge with some tools and you can tell "Yeah, I will complete it in a week". Hah...no way..what you can do is, you can judge the test cases and tell, what test cases can be ignored or 'not be carried out or documented'.But for that you need experience, shrewdness and better understanding of the software application you are testing.

When we consider the software application, you cannot tell what exactly is going on, what it does, whom is it for. Now don't tell me you can get the details from the requirement analysis, I would say no! you cannot get the exactness of the application. You need to derive from the requirement document consulting with the clients and the developers. You, as a tester need to churn out the details by tuning the minds of the stakeholders, those who are associated with the application.

Certifications

2007-08-11T06:46:00.001-07:00

As I am a certified tester(CSTE), people have a hell lot of queries regarding the certifications...at my work place, my friend circle and so and so ..So i thought of creating an FAQ for all the aspiring CSTE candidates..

CSTE FAQs

Q. What is CSTE?

A. CSTE is Certified Software Tester. This is a globally approved certification administered by Quality Assurance Institute, USA (QAI) and is mainly intended for the Software Quality Professionals.

Q. What is the eligibility Criteria for CSTE Certification?

A. To qualify for candidacy, each applicant must meet one of three prerequisites:

1. A bachelor’s degree from an accredited college-level institution,

2. An associate’s degree and two years of experience in the information services field, or

3. Six years of experience in the information services field.

The application requires the applicant to provide details supporting the option selected.

No formal proof of education or employment is required at the time of application; however, you may later receive a request for verification of education, or verification of employment, or both, depending upon a compliance sample selected according to program criteria. If selected for verification, such verification must be supplied to the program prior to sitting for any necessary examinations.

Q. What is the Syllabus for this certification?

A. Syllabus for CSTE changes as per the industry demand and is not consistent. This syllabus is updated in CSTE CBOK (Common Body Of Knowledge).

Q. What is the exam format?

A. The four and a half-hour exam is made up of four parts; two parts multiple-choice and two parts essay and short answer. You will have forty-five minutes to complete each of the multiple-choice sections and one hour and fifteen minutes to complete each of the essay and short answer sections. There is a ten-minute break between each part.

Q. What is the passing Criteria for CSTE?

A. Scoring 75% individually in all the four papers.

Q. Is CSTE study material available easily?

A. All applicants will receive a CD of the Guide to the Common Body of Knowledge. Bibliographic references are included in the applicable Body of Knowledge description for information purposes. Candidates are expected to know and pursue other and more recent resources.

Q. Does one have to attend any preliminary courses before giving this certification exam?

A. The examination presumes that you have had a broad exposure to quality practices and have reviewed and read the current literature available on quality management in their particular area. The Quality Assurance Institute, as administrator of Software Certifications, does not infer that attending specific courses or programs will significantly enhance the your chances of passing the examination.

If you have extensive experience in the quality practices described in the knowledge domains of the Body of Knowledge (CBOK), the examination should not be difficult.

Q. Would CSTE be valuable if I am a manager?

A. Yes, CSTE CBOK contains domains, which are building blocks that contribute towards good project management since they address fundamental issues of sound quality assurance and testing practices, and other significant skills needed for Project Managers.

Q. I am proficient enough in my work, then why is the need of Certification?

A. Acquiring the designation of Certified Software Tester (CSTE) indicates a professional level of competence in the principles and practices of quality control in the IT profession. There is a set of code of ethics, which QAI expects the CSTE professional to follow.

Q. What are the benefits of becoming a CSTE?

A. Following are the benefits of being certified.

For the Individual

CSTE certification is proof that you've mastered a basic skill set recognized worldwide in the Testing arena.
CSTE certification helps to achieve more rapid career advancement.
Results in greater acceptance in the role of an advisor to upper management.
Assists individuals in improving and enhancing their organization's software testing programs.
Motivates personnel having software-testing responsibilities to maintain their professional competency.

For the Organization

CSTE is expected to be a 'change agent', someone who can change the culture and work habits of individuals to make quality in software testing happen.
Aids organizations in selecting and promoting qualified individuals
Demonstrates an individual's willingness to improve professionally.
Defines the tasks (skill domains) associated with software testing duties in order to evaluate skill mastery.
Acknowledges attainment of an acceptable standard of professional competency

Q. What is the fee for Certification?

A. The initial fee for the CSTE and CSQA is $350.00 (USD); this includes the application processing fee, administration fee, your initial sitting fee and a CD of the Guide to the Common Body of Knowledge. If you sit for the exam the first time and do not receive passing marks, there is an additional fee of $100.00 (USD) for each retake (limit two).

The above-mentioned fees can differ. It is requested to check the following link for any updates in fee structure. http://www.softwarecertifications.org/qai_apply.htm - 003

Q. What is the validity period of CSTE Certification?

A. Validity of the Certification is 3 years.

Q. What I have to do for extending the validity of CSTE Certification?

A. You can extend your CSTE status through Recertification, either by gaining Continuing Professional Education (CPE) credits of 120 points in 3 years or by taking a Recertification Examination.

Q. I want to know more about CSTE Certification?

A. You can visit http://www.softwarecertifications.org/ .

Automation Testing.

2007-08-03T20:55:00.000-07:00

Automation Testing is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions. Commonly, test automation involves automating a manual process already in place that uses a formalized testing process.

Over the past few years, tools that help programmers quickly create applications with graphical user interfaces have dramatically improved programmer productivity. This has increased the pressure on testers, who are often perceived as bottlenecks to the delivery of software products. Testers are being asked to test more and more code in less and less time. Test automation is one way to do this, as manual testing is time consuming. As and when different versions of software are released, the new features will have to be tested manually time and again. But, now there are tools available that help the testers in the automation of the GUI which reduce the test time as well as the cost, other test automation tools support execution of performance tests.

Many test automation tools provide record and playback features that allow users to record interactively user actions and replay it back any number of times, comparing actual results to those expected. However, reliance on these features poses major reliability and maintainability problems. Most successful automators use a software engineering approach, and as such most serious test automation is undertaken by people with development experience.

A growing trend in software development is to use testing frameworks such as the xUnit frameworks (for example, JUnit and NUnit) which allow the code to conduct unit tests to determine whether various sections of the code are acting as expected in various circumstances. Test cases describe tests that need to be run on the program to verify that the program runs as expected. All three aspects of testing can be automated.

Another important aspect of test automation is the idea of partial test automation, or automating parts but not all of the software testing process. If, for example, an oracle cannot reasonably be created, or if fully automated tests would be too difficult to maintain, then a software tools engineer can instead create testing tools to help human testers perform their jobs more efficiently. Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection (consider parsing or polling agents equipped with oracles), defect logging, etc., without necessarily automating tests in an end-to-end fashion.

Disadvantages of Automation:

Test automation is expensive and it is an addition, not a replacement, to manual testing. It can be made cost-effective in the longer term though, especially in regression testing. One way to generate test cases automatically is model-based testing where a model of the system is used for test case generation, but research continues into a variety of methodologies for doing so.

Soak Testing.

2007-06-23T21:01:00.000-07:00

So many types of testing!!...and whats now.. Soak testing?? Some one asked me this question during an Interview..I was like "Which testing???" :-)

Soak Testing is a type of testing where we run the application or system at high level of load for prolonged period of time. This type of testing is needed to verify the memory leaks* in the application. Load testing and stress testing may not find such issues because the time duration for stress and load testing is very less.

*Memory leaks: It is the accumulation of the memory resource by the application and not releasing it after its use. This may result in breaking down of the application.

Regression Testing

2007-05-30T07:23:00.000-07:00

There is always a risk associated with the change introduced to an application, to reduce this risk, regression testing(RT) should be carried out during every stages of testing, after a functional change.

Today I came across a quote regarding RT...it was funny but there is a great truth in it..
"Regression testing is to keep a check that your software is not moving a step backward" ......
How true...
To sum it up, "technically",
Regression Testing is a quality control technique by which tester ensures that changes done in the application or software complies with the requirements and the introduced change doesn't inadvertently affect the other parts of the application.

software testing!! what is that ???

2007-05-26T12:14:00.000-07:00

hmm... name sounds nice .."Software Testing"...what is it exactly??

Lets define it.

Software Testing is a disciplined field which deals with the validating of the software in a controlled environment for normal and abnormal conditions.

My first blog!

2007-05-26T08:14:00.001-07:00

I was curious about this "blogging thing" till I started my own blogs...

Today I started this blog which will deal with software testing, which I am professionally into. I want to share my views with the world.