Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^3: Wassercrats::Improved Volume 0, Number 0

by Wassercrats
on Aug 26, 2004 at 19:54 UTC ( #386150=note: print w/replies, xml ) Need Help??


in reply to Re^2: Wassercrats::Improved Volume 0, Number 0
in thread Perl::Improved Volume 0, Number 0

Your "safer reset script" is based on a programming style which is inheirently flawed and dangerous

I almost never downvoted anyone (when I was able to), but I downvoted diotalevi when he said I would sincerely ask you to not upload this to CPAN. While there is no enforced minimum standard of quality for code there or here, this goes particularly low and really should not be shared with a wider audience. People have said worse things that I didn't downvote, but I respect diotalevi and was particularly surprised for the unsupported comment. One of my responses in that thread was:

I don't see how my use of globals is unsafe. If my use of eval could end up doing something dangerous because I'm improperly parsing the code before evaling it, please explain. I reviewed my code after you warned me about that, but I couldn't find a problem.

"or die" is a good idea, if that's what you meant by checking for failure, but that's a 30 second job that should be taken care of, rather than something to make me forget about the script. I'll be adding other error reporting as well.

Parsing Perl isn't bad. Even if it's not as robust as another method, it's not bad. If the script would fail too often, that's bad, but you didn't explain how.

You weren't specific about what's flawed and dangerous, but I think the above answers your comment.

tkil spent a long time reviewing VarStructor 1.0 for his analysis, and I don't recall him mentioning anything security related. He did mention that "it violates good coding guidelines left and right" but I don't care because "good coding guidelines" are not rules when you're not in school and are your own boss, and following any set of guidelines doesn't indicate whether a script works. Remember, I'm the one maintaining it. Don't cramp my style. I understand my scripts and I've determined that other programming methods don't suit me at this time.

  • Comment on Re^3: Wassercrats::Improved Volume 0, Number 0

Replies are listed 'Best First'.
Re^4: Wassercrats::Improved Volume 0, Number 0
by diotalevi (Canon) on Aug 26, 2004 at 20:06 UTC

    Hey now. It wasn't entirely unsupported. We'd had chatterbox conversations about it where I mentioned stuff. Then the May holiday came up, I found myself busy and tkil looked like he/she was being thorough.

    The one thing I really want to add at this late date is that as a consensus, we don't view things like strict as something theoretcally nice for school or such. I use it because it is a really practical, day-to-day, help me write solid-code, fast, thing to do. I understand why VarStructor exists - to assume that a program's state exists in a bunch of shared variables in a common namespace and then clear or examine them. The thing is, with lexical scoping (my) we've (meaning the productive part of the perl community) moved onto better things and as a matter of course either have no globals or as little as possible. That's the big thing. The part where you use eval just makes it possible for someone to break your code. The part with source code parsing makes your code fragile. Its like going out and putting a bunch of well know and identified weaknesses into your program. It just sits poorly. Do you understand that viewpoint?

      You said: "The part where you use eval just makes it possible for someone to break your code. The part with source code parsing makes your code fragile. Its like going out and putting a bunch of well know and identified weaknesses into your program. It just sits poorly. Do you understand that viewpoint?"

      I understand the error in that viewpoint. It's simply not true.

Re^4: Wassercrats::Improved Volume 0, Number 0
by elusion (Curate) on Aug 26, 2004 at 22:08 UTC
    I don't see how my use of globals is unsafe. If my use of eval could end up doing something dangerous because I'm improperly parsing the code before evaling it, please explain. I reviewed my code after you warned me about that, but I couldn't find a problem.
    It's not necessarily that globals are unsafe. But they are bad. The reason they're bad is they create state. This is something that you'll appreciate even more if you ever program in a functional language.

    When debugging, it is far easier to deal with code that doesn't use globals. Because the minute globals enter the equation, you can no longer be sure what's changing what. What looked like good input has been changed somewhere, leaving you dazed and confused.

    And it may not hit you that bad. But the moment someone tries to take over your code and maintain it, they will get lost. By using lexicals, you can keep track of what's getting changed where. Every time you put in a set of values, you will get the same set of values back out.

    There are exceptions to this rule too. Database handles are often a good example. They don't have state (mostly). Using a database handle in one subroutine won't cause another subroutine to have different output.

    I'm pretty sure I've said this to you before, but: you should stop arguing and start asking. Chances are, there are reasons that things are the way they are. Sometimes they're bad reasons, like "because that's the way they've always been". And in that case, you can often feel free to change them. But many times there are good reasons. And you should try to figure out what they are before you say things are dumb.

Re^4: Wassercrats::Improved Volume 0, Number 0
by hardburn (Abbot) on Aug 26, 2004 at 20:40 UTC

    I don't see how my use of globals is unsafe.

    Are you writing to them? If so, your use of globals is unsafe. At the risk of making an appeal to the majority, this fact is rather well-accepted among programmers that don't wear diapers anymore. The only accepted use of globals is for constant data. You can Google for "global variables dangerous" to get plenty of arguments as to why.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      The other only accepted use of globals are for such things that are global like database connections or things that cross-cut into potentially every or many contexts.

        Hrm, I usualy pass my DBI handles around without globals. I could see making the handle a "global" part of a class, like Class::DBI does.

        I guess making a complex object a global (or just widely-scoped) isn't as bad as a simple string or number. You at least have finer-grained control of what is going on that way. I'd still prefer to pass it around, though.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

        Thats what Singletons and Factory classes are for, they are global without actually being global. Of if you are of the more functional persuasion you can use an Identity function. But there is always some way to avoid using globals.

        -stvn
Re^4: Wassercrats::Improved Volume 0, Number 0
by chaoticset (Chaplain) on Sep 11, 2004 at 02:02 UTC
    I don't care because "good coding guidelines" are not rules when you're not in school and are your own boss, and following any set of guidelines doesn't indicate whether a script works. Remember, I'm the one maintaining it. Don't cramp my style. I understand my scripts and I've determined that other programming methods don't suit me at this time.
    Were this about walls, it would read like so: "I don't have to build a wall this way just because walls built this way stand up. I'm not in some wall-making school where they teach you how to build walls! I'm building it any way I please."

    This is fine, if your wall stands up, and if someone will pay you to build it. It is also fine if your wall stands up and nobody stops you from building it.

    It is not necessarily fine if you wish to produce a wall that will hold up someone else's ceiling, because they will pick a wall they hope will hold up, and your wall will look unfamiliar to them. If you're hoping someone else will place a wall next to yours, it helps to give them some form of assurance that they will work together to hold up a ceiling.

    If you're going to build walls the way you please, and not the way walls are built...they'd best be very, very good walls. Build what you feel you must, certainly. That should be denied of no one.

    But if these are walls built for your pleasure, why do you show them to others who dislike them?



    -----------------------
    You are what you think.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://386150]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2018-04-26 08:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?