1. Double the length from an end to the midpoint
2. Use a ruler
3. wrap it around something of known dimensions
4. Drive a mile/kilometer (use your odometer), then see how many string lengths it takes to travel that distance, and divide.
5. Guess
6. Lie
7. Ask someone else

Aren't you implying that all programmers should come from a computer science or math discipline?

Many good programmers have come from other backgrounds: Drama, History, Literature, Medicine, and so on. While some of this training includes a basic understanding of math and problem solving, I doubt very few could articulate your "pattern recognition" requirement or the calculation shortcuts that you quoted in a later reply. They may understand them intuitively or instinctively, but these folks may not be able to articulate them quite as precisely.

You're not saying that these people should give up the practice, are you? (I don't believe you are, but ask to understand your position as clearly as possible.)

In the extremely slim chance that you are thinking along those lines, would it not be more appropriate to consider these (and other folks) as inexperienced and then help them learn the skills? Don't feed them the answers, of course, but point them to pages, nodes, FAQ's, or even books that provide the skills for them to come to the same conclusions. Allow them to learn the craft as they learn the skills by solving problems.

Perl isn't (terribly) hard, programming is hard. Yes, in its purest form, the act of programming requires problem solving and pattern recognition, however, it also requires specific knowledge that can only be learned by doing. Perl requires a firm grounding in regular expressions. If you are fuzzy on regex's, then many examples and solutions are difficult to fully understand.

Also, keep in mind that many folks writing perl scripts (I'll avoid using the more general term given other recent discussions) have come from different OS's and languages. Perl is not BASIC, COBOL, Pascal, or C++. It shares certain features and contains many similarities. It can be used to accomplish the same tasks, but it's still different. There's a mind set that must be learned to "get" Perl.

While elements of this mind set can be learned in other products, certain things can only be learned through experimentation with the language itself. Going back to regular expressions, lets consider the fact that DOS/Windows really only support two very simple wildcards that have neither the scope nor richness of regular expressions. Yes, certain products support regex's, the real proving ground for learning them is Unix itself. If you do not have that experience, you're quite limited until you get them.

As a Windows programmer, I have found that writing good applications for that OS requires an understanding of the API. As a novice perl programmer, I'm seeing that the same general rule applies. I cannot be a good perl programmer without understanding the concepts, command-line utilities, and general mind set of Unix/Linux itself...including regular expressions.

There are many tidbits and factoids that you more experienced perl folks appear to take for granted. For example, printing integer scalars with leading zeros. Simple, yes? Not if your programming background does not contain C or *nix experience. printf works very nicely, but until I found this site, I did not see any examples that showed how to use it to print leading zeros...and I found this site long after the time I needed to do precisely that. (I managed to figure it out after reading and reading the Camel books, but it took me some time.)

Similarly, there's the fact that here documents are interpolated. Obvious from the standard books? No. In one of my first scripts, I was trying to put a lot of style references, ALT tags, and so on in a here document and couldn't understand why it wouldn't compile. It took me three days of frustration to wonder if they could be interpolated and learn that, yes, they actually are.

I don't believe that's obvious to someone experienced in languages where variables are treated more strictly or where interpolation has to be done manually through typecasting, concatenation, and so on.

My point is this: is it not dangerous to presume that everyone has the same background or set of knowledge that we do? If this is indeed dangerous, would it not be preferable to consider unskilled supplicants as raw potential needing gentle guidance and nudging, rather than expecting them to have the same internal knowledge base and insisting on them having a set of skill before (exaggerating) allowing them to kneel before the altar?

There is a reason many schools of thought allow adherents to learn the "secrets" in their own time. Teachers and mentors may (and do) get frustrated at answering the same question over and over. They may be disappointed in having to deal with people who are not as devoted or as serious about the craft as they are. But doesn't the payoff come when you recognize that a student "groks" it? You can see the light bulb turn on.

As a former trainer and tech support person, I found that to be true. When one person "got" it, it made up for several repetitious and "basic" questions--especially when the person that got it was asking all the basic questions.

I believe it's important to presume that questions are honest ones, instead of being suspicious about motives, skills, craft, knowledge, or understanding of basic principles. As nearly everyone's grandmother as said at some point, "The only stupid question is the one you don't ask."

And...finally...there is an important benefit to teaching, in whatever form. In trying to explain something to someone else, you refine your own understanding of it.

The best programmer I know personally, who hooked me on Perl originally (When I asked if there was a good Basic or Lisp for Irix =), is a Philosophy Major, a fine swordsman, and a maddened redheaded redneck. The other programmers I work with were working on Chemistry and Graphic Arts degrees. Two others are in non-science related fields, like History and English. All are exemplary programmers.

What is missing isn't "Maths and Science" but a foundation of critical thinking. They have learned to break up problems into patterns and sub units. My boss is the Graphic Artist and his approach to problem solving has been described as "brutal". He can rip a problem apart faster than anyone I know. He often sees the issue while we are still asking the question. While he is a real genius, I've seen plenty of computer types who weren't brilliant but had a critical capacity for breaking down problems and spotting patterns.

Programmers build up a toolkit of problem solving techniques in their head. The best ones don't keep hitting everything with the hammer, they whip out the jigsaw and Vise-grips. =)

--
$you = new YOU;
honk() if $you->love(perl)

I guess what I'm trying to say is that you have to be able to break a problem down. I guess I'm biased, already knowing HOW to do this, but I'll use your "print a number padded with 0's" comment. How would I find a way to do this?
• well, decimal numbers don't start with 0's, unless it's just the number 0
• decimal numbers CAN start with a "0." followed by 0's, so I could divide the number by some power of ten, and then remove the leading "0."
• I'm really trying to turn a number into a string with some leading 0's to make it a string of a certain length
• is there some function that will allow me to format a string to my demands?
At that point, I might not know about sprintf and printf. So I would ask: "I want to pad a number with zeroes. Is there a function I can use to format a number like that?" I might be scolded for not checking the documentation and the FAQs, but at least I was able to think through my problem.

But again, I'm biased. Maybe I was just ranting out against all the times something has been so very obvious to me and not to someone else. Perl has given me very clear vision, and I have trouble not expecting everyone else to have such clarity of mind.

$_="goto+F.print+chop;\n=yhpaj";F1:eval

Perl has given me very clear vision, and I have trouble not expecting everyone else to have such clarity of mind.

A clouded mind expects everyone elses to be clear, grasshopper.

Cheers,
KM

Take the "how to get unique elements from a list" question. How would you do this as a human? If you can't answer that question, then chances are you won't be able to get Perl to do it for you. And even if you do, you probably don't know HOW Perl did it. So sit down, and think about it in human terms -- Perl might afford you a different approach, but at least be able to do the task in real life.

Okay, if I have, say, a shopping list, and I want to see if apples is on it, I look through it for apples. Which is pretty much what the person did with their code. This turns out to be lousy efficiency BECAUSE HUMAN BRAINS AND COMPUTER PROGRAMS ARE NOT THE SAME. We don't have to look through lists of 10,000 when the inefficiency would be obvious, and if we did we'd alphabatize the list, and perform an kind-of-but-not-really-binary search. Are you suggesting _that_ should have been obvious?

You (I, in this case) would go through the list of things and put all like things in respective piles. Then I would take one thing from each pile.

Really? You think this is the way we naturally approach problems?

Perl is revolutionary because it makes a computer language act like humans, not the other way around, but it isn't perfect. We all, with experience, learn to shape problems into programming methods we know how to deal with. I think your post is unfairly critical of new programmers, and somewhat elitist.

Do they not know how to look up a function for themselves?

Quite possibly, they DON'T. So we teach them perldoc. Most of them can then look up syntax after that.

Has the person never used arrays before? Do they not know how array indexing works (that is a HIGH possibility, seeing as how tons of people use @array[$x] when they shouldn't)?

You said it yourself: they may not have used arrays before. They probably DON'T know how array indexing works (particularly perl's syntax). You're dealing with a new programmer, not an idiot. So they'll make mistakes, and they'll learn. The "seeing a pattern" that you find lacking is a learned skill. (learned at different speeds for different people, but learned)

Update:Tilly provided an execellent example of how we do "is a number even" differently than computers above.

I think a human brain works more like a hash than an array or list. Do we associate things in our brains sequentially? I sure don't. That would require a lot of time to remember something early (or late) in life. I think our brains work like hashes of hashes (of hashes...) -- and no, I'm not insane, I'm thinking in terms of Perl, and how a brain would work if it was Perl.

Hmm, I'm stopping this here and opening a new meditation. See you there in a bit. Look for something like How do our brains work?...

$_="goto+F.print+chop;\n=yhpaj";F1:eval

I'm posting in reply to this because this post is more relavent to this thread.

I think you've outlined the basic problem: You are thinking of your brain and thought processes in Perl terms. New programmers don't KNOW those terms, so they don't view their own mental processes in that framework. When we learn to think in the Perl framework, we become better programmers.

Thinking in frameworks happens in all sorts of things. Role Players are often heard to describe themselves/movies/most anything in terms of their favorite game.

I'm surprised we havent seen at least 4 of these by now... it is, after all, a basic computer science question

It's even simpler than computer science. It's something a human should know how to do! How do you figure out of a number is even? It can be divided by two evenly! Then, all the person needs to know is that mathemetics (and Perl) offer the modulus operation (Perl uses the % character, like C and C++) to return the remainder when a number is divided by another. With these two pieces of information:
• X is even if it is evenly divisible by 2
• X % Y returns the remainder when X is divided by Y
any human that can find patterns should be able to tell how to determine whether a number is even or odd.

$_="goto+F.print+chop;\n=yhpaj";F1:eval

Well if Perl were to do it like this human does, the test would be:

if ($number =~ /\D/) {
  print "$number is not an integer\n";
}
elsif ($number =~ /[02468]$/) {
  print "$number is even\n";
else {
  print "$number is odd\n";
}
[download]

Honestly, that is *exactly* how I do it! :-)

It's something a human should know how to do! How do you figure out of a number is even? It can be divided by two evenly!

japhy, you highly overestimate the knowledge of the populus. As a counter example, notice the popularity of WWF, including the number of people that swear it's real.

-- Randal L. Schwartz, Perl hacker