A[X] B[] C[] D[]
Often, even though a definitive answer in not provided, I find some-one elses ideas extremely helpful.

I may be so tied up in trying to solve an issue I have, that I don't always consider that there may be a different, if not better, approach.

Think outside the box type stuff.. isn't always so easy to do when you are faced with a deadline or head banging problem... I would vote that you post your suggestions/ideas and let the community or poster decide if they want to use your comments.

I also often find that just talking to some-one else, whether they understand my problem or not, is helpful as it stimulates thought processes differently, that otherwise may not have been invoked.

If you are someone that cares about XP (I don't think you are, FWIW :) ), you might refrain from this though - I have gotten the occasional (or even systematic) downvote for posting nebulous pointers instead of definitive answers.

As an aside, reading the title to this discussion, I thought is was going to be about copyright. I'm happy it is not :).

CU
Robartes-

Definitely A.

One thing I remember from my early days of engineering schooling is that I must look at *all* of the possibilities -- even if some of the ideas are not fully developed or even slightly non-sensical.

Often new and better solutions are derived by sleeping on these crazy ideas -- sometimes the ideas contain hidden merits that may cause you/others to see the problem in a different light. That is why discussion is so effective.

What's important is the end result. Did a fellow monk ultimately get the answer the were looking for?

BTW, I highly value your opinion, because you always seem to be spot on.

Perl monks after all is about Perl, not about knowing every environment on the planet.

--
integral, resident of freenode's #perl

C.

    E[X] Wait until the question has been around at least a couple of hours and then post your idea if nothing better has yet been posted.

I have started typing responses only to get about half-way through them and thought, "Wow, this is a cool idea, but I have no idea if it will work." Generally I don't post that sort of message (now) because:

• it usually doesn't work
• it's only a cool idea to me
• there's too many @#$!ing nodes already

My policy for right now is to respond with untested ideas only in very familiar ground, which is Win32 for me.

--
May the Source be with you.

Like others already said, you should always look at all the available possibilities before solving something. If you think your idea solves the problem from a different angle, you should present it; after all we're all here to expand (and share) our knowledge!

-- JaWi

"A chicken is an egg's way of producing more eggs."

Abigail

Well, I wanted to make option [E], but tye has already done that, so I'll add a new option.

[F] - All of the Above ('D' only under strict circumstances).

A - Depends on how much you can muster with your knowledge. If you can provide an english description of how to go about it, but cannot put together the code that matches that description, absolutely. There are times that the idea just isn't founded enough (ie: Something like Couldn't we use references here?. Yes, but *how* and *where*?)

B - Absolutely. IMHO, you don't have to be an expert on a subject in order to participate in the discussion associated with it. On the other hand, you shouldn't walk in completely ignorant on the subject and try to offer ideas that just won't even relate (this sort of response might be considered to fall under catagory 'A'). Do at least enough research that will allow you to offer your thoughts without looking like you don't know what you're talking about.

C - This is probably the best way to go about things, but it's an unrealistic method. If every answer was required to come with a complete, working solution to get the job done, there would not be as much discussion on things. I imagine it would be a "here's how to do it, end of discussion" type of thing. Yet again, the other side of the story: others would comment on these answers, offering ways to improve upon the code and its implementation. Who knows? Maybe we'd have more intelligent discussion here. But I think it's too much to ask/demand that a person research a subject to the point that they could teach it. Unless the topic interests you, you shouldn't have to spend an hour putting one reply together. :)

D - Absolutely Not! - No, no, no! Don't do this one, because what if your idea was right? What if you thought of a way to reduce a chunk of code by half, while at the same time improving the efficiency and clarity of the code? The only time you should consider not posting your thoughts is if you truly believe that your comments will not provide a positive contribution to the discussion. Post your thoughts. If you're right, you'll be praised. If you're wrong, some will offer reasoning as to why it doesn't function correctly, others will downvote you thinking that your answer was worthless. Take it as it comes. For every downvote you receive, I think you'll get 2 ir more upvotes.

      C:\>shutdown -s
      >> Could not shut down computer:
      >> Microsoft is logged in remotely.
    

A[X] B[ ] C[ ] D[ ]
[download]

1. TIMTOWTDI (of course!)
2. I'm slightly biased toward option B in a sense that the suggestion should be clearly on-topic

The latter is what drives you to learn and improve oneself. So please, suggest away freely as long as it's remotely related to the OP (I guess that stands for Original Post)!

--
Cheers, Joe

Michael

A[/] B[ ] C[ ] D[ ]

I would say A, unless the problem was already well on its way to being solved by others, when I'd lean towards B or C.

D is probably best reserved for when the problem actually has (or appears to have) been solved to the satisfaction of the person who asked about it.

Not only do fresh ideas send people along paths they probably wouldn't have considered themselves, they can also help solve similar problems for those searching for similar topics months or even years later.

Of course, this is just my opinion, but you were asking for our opinions, right? :o)

__________
"Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work." -- (Author Unknown)

Definatly A , on the grounds that even your 'germ' of an idea could take root in more places than your 'soiled' mind! :)

Besides, don't scribes-> have votes and bishops-> moderation facilities to sort out what is valued or otherwise. meanwhile ...

A[X] B[ ] C[ ] D[ ]

I'll have to go with A. Often times I am about to pull my hair out, LITERALLY(you should see my balding head;o))

Then I'll ask for help.

Often I get some very off the wall comments(different forums not just PerlMonks), so I'll try them, often they don't work, most of the time they do, but I'll tell you this, and my wife would confirm this, I will read every post on the matter, in the thread upon which I'm focusing on(usually mine). Then I'll go to sleep frustrated, and I will dream the solution. I swear, It happens all the time. I wake up, remembering what I did in my dream, and it works!

I probably could not do that, if I don't get to read those other "angles" on the matter.

One time I was stuck for at least 8 days, I swear, I almost just through my dang computer away, then one time I read an answer from Dave Cross in ANOTHER thread on a different subject that had nothing to do with my problem, and it while I was dreaming I solved it, but that time I could not remember when I woke up what I did.

So I scanned over and over the code AGAIN. Then I remembered what Dave did, so I looked at my code again and again. And I changed one field in one subroutine, and another field in a different subroutine, and it worked.

I would never had thought of that if I had not read what Dave said.

sometimes answers come from NOTHING AT ALL. Don't ever stop sharing your knowledge, it is TRULY POWER.

Even if it does not belong, if a person reads it who has never known that before, they became stronger minded and a better person, because of it(provided it's upbuiding not negative).

That is my 4 cents on the subject:o) Take Care,
Richard.

Sorry If I rambled on and on... It's about 1:30 am but I've been up for almost 22 hours straight. I'm seeing stars ;o)

For me, definitely A. Your mileaage may vary.

Explanation: Having written code for almost 20 years, I don't find writing the code to be the difficult part -- at least 90+% of the time. Mostly I'm looking for new ways to approach problems. Sometimes I am stuck on a very specific problem, but those generally are not the kind you can offer an idea for (e.g., how do I get this @!#$% linker line for DBD::mysql to work on Solaris 2.7).

That being said, I think there are probably more people who are lacking the coding experience that need concrete examples and solutions. So no one answer is correct ... depends on the audience.

The response is unanimously A at this point.

Just a tongue-tied, twisted, earth-bound misfit. -- Pink Floyd

A[X] B[X] C[ ] D[ ]

I would say a combination of A and B. While it's great to brainstorm to solve a problem, you also need to be able to "sell" your idea should someone should think that you are on the right path to a solution. Feel free to post your ideas, but also be able to back them up (even if it's just with a toy problem) with some proof. That way, you not only will be helping others, but you will also gain experience through your testing.

I often look at my code and think "How can I break this?" I try. That way, when I release something, I know it will indeed solve the problem it addresses. Not only does this produce good, stable code, but it also expands your knowledge of the implementation.

Just my thoughts.

--
haxordan

If the world is to end in a whisper, I hope that it's not someone whispering,"I wonder what this button does?" -DTB

Implementations are nice, research is helpful, but neither or those is any good without the idea.

 One thing I've found in the past is that I've been sufficiently intruiged by a question to go off and research an answer myself.

 Typically I'll spend a while reading the perl documentation, playing with some test code - then discover just before posting an answer that somebody else answered it nicely.

 This is enough to make me not answer, mostly, but I don't regard it as a bad thing because it's forced me to learn something.