|
Re: Preferred output for development tool
by flyingmoose (Priest) on May 06, 2004 at 20:23 UTC |
I still don't see the need to emulate reset (or your buggy code, or why one program does two completely different things), but I understand this has been a looooooooong battle for you. I suggest you read up on some code-refactoring techniques. Some of it is rather obvious, but it may help you try to understand what we are saying and why your antiquated ways need to change. Also read up on error handling, design driven development, and so on. And debugging! If you want to watch values, use a debugger or instrument debugging hooks.
To be constructive, I'll give some feedback. I like to chain GNU tools together, and parse things (running items through sort and grep and such), so I'd do something like the following to keep parsing simple. Shiny output is of little use to machines.
iteration variable value
1 abcdef foo
1 bbcdef bar
2 sheep zebra
or is there hope for my module?
I see little hope. Especially in that you still have a few subroutines and don't even have a module yet. | [reply] |
|
After probably more then a dozen replies to VarStructor and VarStructor 1.0 NOBODY BUT MYSELF found a single bug, except when someone spent 6 hours analyzing the code, and even then, the bugs he found would have been noticed in use only in rare occasions. And it's not as though nobody tried to find bugs. I got plenty of bogus complaints about the code.
I don't need to get any better at debugging or testing, and my programming ways don't need to change. Anyway, all that is irrelevant to my question.
Chain GNU tools together and parse things? The change to my script to produce the output you showed wouldn't take much time or code. Sounds like you want me to spend extra time to do it the way you would from scratch. That doesn't sound appealing.
| [reply] |
|
After probably more then a dozen replies to VarStructor and VarStructor 1.0 NOBODY BUT MYSELF found a single bug, except when someone spent 6 hours analyzing the code,
Are you implying that since it took 6 hours of analysis to find a bug that your code must be good? I take it to mean that if it took 6 hours to understand 2 pages of code, your code needs to be rethought.
and even then, the bugs he found would have been noticed in use only in rare occasions.
But still a bug. If you're planning on releasing this to CPAN, why not make it as robust as possible?
I know you would dismiss an in-depth discussion about how you can't parse Perl with regular expressions as just "academic" and therefore stupid. If you're really interested, find a book on formal language theory and models of computation. The point is that not being able to parse Perl with regular expressions is a fact. You whine and whine about how lexicals and use strict are so restrictive, but now anyone who uses this code you release will be restricted to the coding style that are recognized by your basic regexes.
And it's not as though nobody tried to find bugs. I got plenty of bogus complaints about the code.
The complaints were valid, they just weren't bug reports. Someone telling you that your code is crap is not necessarily "bogus." In this particular case, it's spot-on.
I don't need to get any better at debugging or testing, and my programming ways don't need to change. Anyway, all that is irrelevant to my question.
You're right, it is. And I think we all know that it's hopeless to try to convince you of pretty much anything about your code.
Chain GNU tools together and parse things? The change to my script to produce the output you showed wouldn't take much time or code. Sounds like you want me to spend extra time to do it the way you would from scratch. That doesn't sound appealing.
If you already know how to do it the best way, why post in SOPW?
| [reply] |
|
|
|
|
Howdy!
I don't need to get any better at debugging or testing, and my programming ways don't need to change. Anyway, all that is irrelevant to my question.
<VOICE "Bill Cosby">Right!
Hubris is one of the virtues of a programmer. This isn't
hubris. This is "stick my head in the sand". This is "stick
my fingers in my ears and say 'I can't hear you'". Hubris
does not mean you claim personal perfection. You make that
claim, and, like most such claims, it is just flat wrong.
You need to step back and chill out, dude.
If this were Usenet, people would be commenting on the
tightness of the death spiral. Pull up! Pull up!
No, wait. Roll out, *then* pull up! You keep pullin up, but
all it does is make the spiral tighter. Pretty soon, the
wings come off.
You seem to have gotting yourself heavily invested in this
tool thingy. You come asking for wisdom, but you do worse
than ignore it. You are like the guy trapped by floods who
spurned two boats and a helicopter come to rescue him
saying "God will save me". When he then gets a chance to
ask God why he didn't, God says "I sent two boats and
a helicopter. Whadda ya want?"
I'm getting tired of downvoting your nodes -- the ones that
really deserve it. It's not fun. When more than half, and
perhaps two-thirds of all the nodes you have written have
a negative reputation, one has to wonder. The big foam clue
bats are getting ratty from the amount of use they have
gotten on your account.
| [reply] |
|
|
|
Re: Preferred output for development tool
by waswas-fng (Curate) on May 06, 2004 at 20:26 UTC |
The text boxes would all be the same size so everything will line up. I could do this with CGI, but I don't know how acceptable that would be for the average programmer.
I thought that it had already been covered that an "Average" programmer would be better suited using localized variables in the first place instead of your rehash of reset.
| [reply] |
|
corollary -- he's the only one who is going to use this tool, so it doesn't matter what he does with the output.
| [reply] |
|
I thought that it had already been covered that an "Average" programmer would be better suited using localized variables in the first place instead of your rehash of reset.
I agree with that. It has nothing to do with the question, and it shows that you don't know what my script does.
| [reply] |
|
I think it shows that you are the only person who does know what your script does.
| [reply] |
|
|
|
|
|
Re: Preferred output for development tool
by perrin (Chancellor) on May 06, 2004 at 20:41 UTC |
| [reply] |
Re: Preferred output for development tool
by Anonymous Monk on May 06, 2004 at 21:47 UTC |
Seriously, the best approach to this is to remove your script from PerlMonks, ensure it exists in only one location (say, a 1.44 inch floppy) and then put it out of its misery in a humane fashion (maybe toss it into a river?). To quote a phrase from an ex-housemate of mine - and not wishing to offend any esteemable monks - "you can't polish a turd". | [reply] |
|
So, if I spend the short amount of time to make it print out the table of variable history, that wouldn't be of use to programmers? Is Tie::HashHistory of any use? How about Xref? You have the opportunity to be one of the first people to be specific and make a valid point about the functionality of VarStructor. Don't pass it up if you're able to.
| [reply] |
