It'd help me (and likely others) evaluate your points in the context you intend if you could follow the Writeup Formatting Tips, especially w.r.t the use of <code></code> tags. :-) There's a quite reasonable subset of HTML there to illustrate your assertions/opinions/examples.

I'll try to parse what you've posted:

Basically, about C as Perl you _all_ have it wrong.

I don't see how you can plausibly make that assertion given the vagueness of your original post. A few monks parsed roughly the same ideas from your posting, and responded to them in a reasonable fashion.

However, if we've misunderstood what you tried to say, it's likely because you were too broad, not clear, and overly rhetorical.

I use (pointers) a lot in my Perl (by reference) unless you went to school when they misinterpreted value/reference. For another time.

Anyone who seriously uses Perl deals with references routinely. I'm pretty sure we all understand the analogue w.r.t C pointers. Perl's references, however, are typed in a manner such that errors are actually evident (irrespective of manipulation).

My original thought about 'until' as being somewhat like a properly wrapped C macro which would say do{...}while(0) is that C doesn't have 'until' and I've seen where it can and should be used. until else is a non-sequitor for the most part.

I believe the exact opinion you stated was "haha - they remind me of macros ...". Your detailed explanation notwithstanding, the statement still makes no sense. You've examined the statement-modifier form of until, noticed a slight similarity with respect to the do-while construct in C and extrapolated a relationship that's incomplete and mostly irrelevant.

until else is a non-sequitor for the most part.

In what sense? A 'non-sequitor' is a classification of logical error which deals with one point of argument/proof not following logically from its predecessor. I still don't understand what you want to say there. Were you after 'double negative'?

Other C things are;

sub func {
   my($hr_h, $ar_l, $this) = @_;
   # instead of all the shift, shift, shift
   # seems quite clear
   my @these;
   # I'll try to wantarray too.
   foreach my $i (keys(%$hr_h)) {
     if($i == $$ar_l[$i] && $hr_h->{$i} == $this)
     {
       ....
       push(@these, $ar_l->[$i]);
     }
   }
   wantarray? @these: \@these;
}

# not the best of examples but shows 2 ways to talk with
# an array pointer and uses (for good) of wantarray as the
# return value.
[download]

Perl subroutines take a flat list as argument. That's all. Entirely unlike C. Stating that a lexical declaration coupled with destructuring assignment "seems quite clear" doesn't advance your argument at all.

Since Perl's subroutine arguments come packaged in an array, programmers have the freedom to use all available built-in (or other) functions and other constructs which deal with arrays/lists. Some folks like to avoid copying. Others like destructuring assignment. Others still enjoy treating the arguments as a list. Lots of choice: no "best practices" positive correlation to C can be established without discarding lots of elegant code.

I've no idea what you intend to say about wantarray.

Your insistence on using unnecessary parentheses in order to make the code more C-like just results in Perl code that's cluttered and less idiomatic.

I can't figure out where you've advanced an argument that by writing in this style that (allegedly) mirrors C any advantage is incurred w.r.t either of

• performance
• readability

The fact that its a textarea is bad enough, but come on folks, if code is involved, let's get a bit more indentation-centric. That's not a word, I'm sure. I wouldn't write any real code without tabs and some smarts. Can I help you 'monks'? Indenting is _not_ 'press the space bar'. Nonsense.

Oh, the irony.

If you have more questions, especially you 'chromatic', send them on over to here http://www.theworld.com/~morourke/

You're unlikely to get many takers (AFAICT, you've only provided an email address). The discussion here is quite robust, if somewhat biased at times. Your website shows no danger of promoting any such quality.

-David

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.