Well, those posting bad code don’t know the difference. Those believing it to be sound advice are starting a journey toward discernment in a world absolutely heterogeneous in quality and value and they will have to take some lumps along the way or never break out of the inner circle of Dunning–Kruger. It’s not always in their interest to protect them. Attempts at process, rules, or dogma to enforce quality often have unintended consequences and like most crime/“crime” the admonishments are ignored by those they would help or correct while already understood and followed by the rest.

I can see a code post here by afoken or AnomalousMonk or Corion or, or, or… and know it to be good or, at the least, worth examining seriously and with all benefit of the doubt. New users and Anonymous Monk get a couple kilos of skepticism. I believe in best practices and would probably cite this (update: meaning your OP) post in a discussion as something worth considering. So… I’m not sure I have a point except maybe: trying to prevent crap is the fount of quite a lot of crap in the end.

Well, those posting bad code don’t know the difference.

My meditation lacks the word "intentional": It is about intentionally posting bad code. (See Re^2: Don't post bad code!)

And I think people who manipulate the symbol tables instead of showing how to use arrays or hashes do know the difference.

Those [...] never break out of the inner circle of Dunning–Kruger. It’s not always in their interest to protect them.

Good point. I've met two or three people from the innermost circle in my life, and I should have remembered how much I wished they would do a much less harmfull job (like self-moving ballast or park bank pre-warmer) at the other end of the world. Not to mention tens of people with a little bit less of D-K.

But still: Should we feed them with bad practices?

Attempts at process, rules, or dogma to enforce quality often have unintended consequences and like most crime/“crime” the admonishments are ignored by those they would help or correct while already understood and followed by the rest.

I’m not sure I have a point except maybe: trying to prevent crap is the fount of quite a lot of crap in the end.

I don't think that allowing bad code will sort out the D-K people. The crap they produce is much too often considered "good enough", some times for years and tens of years. It's part of their job security, no one except them has even the slightest clue of what happens in their code.

<Update>

Design and code review (at peer level) are an excellent way of improving quality. Unfortunately, it requires any writer to accept a lot of critic from the peers. The most important part is to understand that critic is about improving quality, not about the person.

</Update>

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Every point you touch in the above meditation is correct and sounds of your will to help people learning Perl.

But to learn is a matter of intelligence and intelligence is matter of choice (intelligere intus/inter + legere as in "be able to choice among" ).

Your will to teach a better Perl does not make this monastery a school.

The monastery is a reflection of the reality: "who want to speak about Perl? come on entrance is free" is a wide call for every type of coders and even no coders at all!

Our (mmh more on me later..) goal is to offer our solutions or opinions and underline well in red which are good and wise answers; recently a bunch of discussions pointed to the necessity to show in better way good answers and good coders.

The voting system and Level of monks helps a little in this way but somehow can be a guidance for newcomers. But is up to the newcomer to understand what he choice to ear (and to copy in his program).

Many people here around are not professional programmers; sysadmins, net people, hobbyst coders, amateurs, curious ones.. many of us have no such thing called production code

I did not say this is good or wrong; is a fact.

I entered the IT in a very tangential way, I stumbled on Perl and i liked it. I immediately appreciated PerlMonks as a cave of true gems. After years spent reading I have good list of monks which post I look with attention but sometimes I can tell good and wise answers from Anonymous ones too.

When there is a discussion about something I know, even little, If I can show another way, i take my slice of freedom and I post something; if it is wrong and downvoted and some big monks explain why my contribution was no wise.. is always a way to teach and to learn, for me and others. I can produce many examples but one for all is Find 30 days from today's date

I answered with my personal examples because in many, if not all, point you touch I'm guilty, I was and I will.

TIMTOWTDI is a Perl foundamental too and is educative even to know that some task is doable with a oneliner. I recently posted many oneliners because i had fun writing them, more fun than watching tv. I think too that oneliners are somehow irreverent in respect to the programming in itself: obviously if someone fond his critical application on my idea of ten days ago using the above oneliner is a fool as fool is who write a complete program just to know which range of days in logs need to analyze.

Smart snippets, oneliners, are not wise? If they provoke challenge and fun so they can be a big boost while learning Perl.

Golf code in beginner thread? I can assure you from my experience that is completely unharmfull: in the past I looked at such code more like to some kind of ASCII art, like Linus at russian names.

The orrible hat of a turist in front of you does not erase your souvenir of Colosseo.

best regards

L*

to learn is a matter of intelligence and intelligence is matter of choice

Good point. But as you wrote:

Our [...] goal is to offer our solutions or opinions and underline well in red which are good and wise answers; recently a bunch of discussions pointed to the necessity to show in better way good answers and good coders.

It is hard for a beginner to estimate the quality of a posting. The existing voting system does not help here, because you can't see the votes a posting has collected. You need to vote first. Initiates can't vote at all, Novices can vote only twice, so they can get a quality estimate for only two answers. And of course, you need to find and study the voting documentation (e.g. Voting/Experience System) first, while your real problem waits for a solution.

So yes, an improved voting / rating system would help beginners.

When there is a discussion about something I know, even little, If I can show another way, i take my slice of freedom and I post something; if it is wrong and downvoted and some big monks explain why my contribution was no wise.. is always a way to teach and to learn, for me and others.

My meditation is about intentionally posting bad code (sorry, missed that important word in the meditation), not about posting "accidentally" bad code.

I can produce many examples but one for all is Find 30 days from today's date

Easy: perl -E 'sleep 30*24*60*60; say scalar localtime' ;-)

Smart snippets, oneliners, are not wise? If they provoke challenge and fun so they can be a big boost while learning Perl.

Right. But it requires a beginner willing to learn. So yes, it's a good thing.

Golf code in beginner thread? I can assure you from my experience that is completely unharmfull: in the past I looked at such code more like to some kind of ASCII art, like Linus at russian names.

I doubt that. If you start with perl, even good code looks like ASCII art or line noise. Especially if perl is your first language. For me, Perl was language number 5 or 6, so I could see structures even without knowing the language. MUMPS was number 15 or 20, and even if it looked like a cat ran several times over an old typewriter, it took me just a few hours to understand the basics and a few weeks to write significantly better code than my instructor. Beginners don't have that amount of experience.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Hi Alexander,

I agree with many things in your meditation. I do want to provide some counterpoints to a few things.

But no, we should not show beginners the most dirty ways first.

I absolutely agree, if the emphasis is on "first". But I think it's a little unfair to pick on 1172628: it was posted several days after two very good replies showing the better way to accomplish the OP's goal, it does contain a disclaimer, and I'm pretty sure it'll stay near the bottom of the page. The only thing I felt missing in that node is a discussion of strict, which I have now added in a reply.

... Not even with warnings not to use the dirty ways in production code.

I disagree: If a question is first answered with the "best practice" way, then I think that posting the one-liner or "bad" way afterwards - with a prominent disclaimer - isn't a bad thing. People who are just looking for a quick answer to copy-and-paste into their script (of whom there are many) will use the first thing they find, which will usually be the first and/or most-upvoted answers, especially since the relatively recent change that replies are sorted "best first" by default. But threads are read by many more people, and those who actually want to learn Perl (hopefully including the OP) can scroll down, and they will learn something interesting.

People will always find bad code all over the 'net and use it. Just the other day I came across a blog posting showing an arguably bad snippet of Perl code, and the only indication that there was something wrong with it was if you scrolled down into the comments section (which had a tiny font). So instead, I think that showing both the right way(s) and the "wrong" way with a prominent disclaimer will help people to differentiate between the two, and to learn why something is "bad".

Note that I'm putting "bad" and "wrong" in quotes here because I'm a fan of TIMTOWTDI, while at the same time I think that guiding people to using the best practices is also a Good Thing.

There lots of threads where I see replies and think "I wouldn't have posted that", such as the many cases where people get code written for them where I happen to feel they haven't shown enough of their own efforts. But getting frustrated that I can't control what other people post is not the answer :-)

Instead I like the system that is already in place: Replying to nodes that contain "bad" code, and the voting system. Monks who truly want to contribute will quickly learn that posting replies that adhere to best practices is appreciated by more people. Your meditation is also good reminder of the "best practices of posting".

Regards,
-- Hauke D

I think it's a little unfair to pick on 1172628: it was posted several days after two very good replies showing the better way to accomplish the OP's goal, it does contain a disclaimer,

Yes, maybe. It is not the best example for a "bad code" posting, and I know that there are worse postings. But as I wrote: It is the posting that triggered my meditation. It was the straw that broke the camel's back.

There lots of threads where I see replies and think "I wouldn't have posted that", such as the many cases where people get code written for them where I happen to feel they haven't shown enough of their own efforts. But getting frustrated that I can't control what other people post is not the answer :-)

(I'm not frustrated.)

Instead I like the system that is already in place: Replying to nodes that contain "bad" code, and the voting system. Monks who truly want to contribute will quickly learn that posting replies that adhere to best practices is appreciated by more people.

Very good point. It does not require any changes to the monastery code, and everyone can contribute. Simply by posting "Don't do that. It's the path to the dark side. 'Once you start down the dark path, forever will it dominate your destiny.' -- Yoda" Yoda quote optional. ;-)

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Just for counterpoint.

The typical solution to the symbolic reference problems, is: "Use a hash"; but symbolic references use a stash, a symbol table hash.

The only real difference between symbolic references and hashes, is an extra level of indirection.

Oh, and the fact that use strict effectively disables autovivification in stashes; which is a power only relatively newly granted to hashes by autovivification

"Bad code" is only bad code if it is used badly; used correctly, it can be a very useful, and powerful asset.

Blanket bans (on anything) just encourage ignorance.

Hi

Why? Because there are lots of beginners out there, who either don't have time to or are unwilling to learn how to use perl.

They just want fast results, they don't care about maintainability or improving their skills. Imagine what happens when they get ten answers linking to FAQs, HOWTOs, documentation, or showing examples of the right way, but require a little bit of thinking; and one or two answers showing how to abuse perl into the way they are currently thinking.

Let's make it hard for the unwilling and the people in a hurry to find bad code, bad examples. Posting sane examples is good, improving a code example posted is even better.

Hi

Don't worry about it new monk :)

You can't protect people from themselves, the internet (even perlmonks) is full of bad code

Don't give it a second thought

Many of us have already changed the way we respond many times ...

we grow, we learn, we change our replies