Tim Bowden wrote: > On Tue, 2009-09-01 at 23:11 -0400, Uri Guttman wrote:
>> SB> newbs don't understand that, without simple code examples.
>>
>> and i explained it. it is when you are asking about X (thinking that a
>> specific way to do something) when you should be asking about Y (usually
>> the larger problem which has a better or proper solution).
>>From a 'newbie' pov, I think it's worth trying to do both the 'Y' and
> 'X' components in a post. I believe it has several advantages;
>
> * Describing the underlying problem ('Y') provides potential helpers
> with hopefully a good understanding of what the real problem is so they
> can offer a better solution.
>
> * Posting code showing a (usually failed) attempt at solving the problem
> ('X') demonstrates that the OP has thought about the problem and tried
> to solve it first and isn't just rushing off to the list at the first
> hint of trouble.
All three of your above 'todo's' are great. They don't speak reality
however. (I shouldn't say that... this list has archives rich in
questions with Perl code ).
> * Demonstrates (at least to some degree) the current level of
> understanding of the OP (both of Perl & the problem), hopefully
> resulting in answers that are better targeted in terms of
> explaining /why/ a certain approach might be good or bad. Knowing 'why'
> can be just as important as knowing 'how' to use a certain solution
> type.
Although I understand why senior Perl 'people' ( don't know if I should
say Trainers, Officers, Generals, Experts, ) are here, it's hard to be a
young bashful rookie who is energetic and just wants to 'go'!.
My core instinct is to know 'why' not 'how'. If I could learn, I'd
prefer explaining the reasoning behind something, not how it happened.
> * Building a minimal exposition of the problem in code for the sake of
> posting often helps to clarify the nature of the problem. Complex code
> (for whatever value complex may be for a newbie) often tends to hide the
> nature of a problem. More than a few times I've put together such code
> for the purposes of posting and discovered the solution when I striped
> away the complexity. I've also developed quite a directory of snippets
> that have tested or demonstrated some function in a way that I
> understand. I often go back there when I'm stuck.
I'm trying to simplify my "complex" code. To me, it feels complex. I
hate it, because I'm not a programmer. I've got my svn repository for my
current project, hidden in that, I have a "tests" directory that has at
least:
% ll tests | wc -l
74
...files, and then I have a preferred code-snip directory which has a
craptacular number of 'tests', and then have a single 'howto' directory
that contains the best-of-the-best snips in individual files (many
hacked against things picked up from jwk, uri and randal) on my
workstation. I go back to these txt files, when I'm stuck. These are
files that contain very small code snips that are *very* important to
me, and I'll never forget how to reference them.
> If someone is particularly proficient in another language, expressing
> 'Y' may well be mentally easier in pseudo code applying the solution
> technique from that other language (or a 'perlish' equivalent), and end
> up looking like an 'X' type question by virtue of its form rather than
> its nature.
>
> Sometimes the OP just doesn't realise the more generic case of what
> they're trying to do, particularly if they're now to programming in
> general. If it's all new, there are no strong mental 'class' models
> they can call on to describe their problem.
If I understand what you and Uri are trying to say, 'Y' is a variable
that should be understood across all languages, zelfs in het Nederlands.
I get it. I just want to go... I'm ready,.. teachers.
Steve
--
Steve Bertrand
Senior Network Engineer
eagle.ca Internet Services
905.373.9313
IPv6 Ready!
smime.p7s
Description: S/MIME Cryptographic Signature
