On 2/24/2011 9:29 AM, Uri Guttman wrote:
"TM" == Ted Mittelstaedt<t...@mittelstaedt.us> writes:
TM> On 2/24/2011 12:42 AM, Uri Guttman wrote:
TM> Uri, I am perfectly aware of what constitutes modern programming
TM> practice. And the fact of the matter is that your very wrong, because
TM> if I was going to rewrite this code the correct way would be to use
TM> one of the NNTP Perl modules (NNTP Client for example) The listgroups
TM> script could probably be replaced by something along the lines of
s/your/you're/
and i know about using the nntp module. but your last post was jusy
about crappy low level socket stuff and that bothered me more. that
isn't even a rewrite or changing the logic. it was one line to replace
about 10 hard to fix lines. drop in replacement is not a rewrite.
Ah, but that same template problem appeared in the other 2 scripts
that are part of this software package. Also I think it may have been
used in multiple places in each script. In the interests of keeping the
original question simple I omitted that. Expending the effort to fix
one script fixes all 3. Of course when I embarked on the attempt to fix
the one I didn't know the other 2 scripts would have the identical fix
but I suspected - since their failure symptoms were very similar.
TM> But I will point out that perl modules are built in a pyramid, you
TM> have ones like NNTPClient that use IO::Socket and that module
TM> uses Socket and that module uses...what? Well, it turns out it
TM> uses the same approach that's in the listgroups.pl script.
IO::Socket is in core perl. it is not a heavy dependency. the issue
isn't whether a module uses other modules but your time wasted fixing
socket stuff that doesn't need fixing. if you thing spending time there
is worth it vs a single line of code, that is your problem. see how well
it does on your resume! :)
Once more, this was not a design decision to write new code it was a
repair decision.
Re read my original post. At the time I first started looking at this
I had no idea the problem was in the socket code. It could have just as
easily been an operating system issue. Since the script worked on a
modern Ubuntu system I assumed the problem wasn't in the script.
Sure I knew the script has some hoary old code in it. But just because
code is old does not mean it's bad. Particularly when the code has been
around for a decade and worked on several different FreeBSD versions.
Consider it again. The script worked on FreeBSD 6.4 running Perl 5.8.8
It worked on the current version of Ubuntu running perl 5.10.1. And it
failed on FreeBSD 8 running perl 5.10.1 Why would it be reasonable to
assume that the script was the problem? The birds eye view would say
that it was a new bug introduced in FreeBSD 8. Particularly when the
old and new version of FreeBSD is 32 bit and the new hardware was a
pentium 4 and the old hardware a pentium 3.
TM> If your answer to a bug in the program is to hack out the
TM> section and replace it with a module, your basically saying
TM> that you don't know how the section works. So your going to
TM> drop in a black box that does the same as that section. In
TM> other words, you don't know how the black box works anymore
TM> than you know how the section your hacking out works.
bullshit. simple as that. i can hack at any level i feel like having
done it for over 3 decades. i have done massive amounts of socket work
in c and perl. i choose to be lazy and use the right module for the
job. that is a skill i promote when i job hunt.
Good for you. But I was not talking specifically about you but in
general. In your specific case since you know everything from the low
to the high level you POSSIBLY could have taken one look at the script
that was not working and had a "gut feeling" that even though the
early indicators pointed to an operating system bug, the problem still
was the script because the code in it was old. You might have then
taken a leap of faith that you were right and then cut out the socket
code and replaced it with calls to IO:Socket and then sat back in
satisfaction when everything worked. You wouldn't have even bothered
in that case trying to figure out why the socket code didn't work since
you just would have assumed it was broken.
TM> And the day that a new platform comes along and the module your
TM> using blows up on that then you will be just as screwed as I was.
TM> Worse, probably, because I didn't give up I kept plugging away at
TM> it. You won't, you will just complain loudly for the maintainer
TM> of the IO::Socket module to fix it and do nothing until he does.
huh?? you don't get it. that is basic client socket connection. that
hasn't changed in eons. if you think depending on that is a ball and
chain, you are not worth talking to.
I didn't say that was a ball and chain. What I was trying to illustrate
was that ultimately Perl depends on the implementation of the operating
system function calls and it helps to understand those calls. Perl
today is much more modularized than it used to be, that helps in many
areas but it particularly helps in this kind of problem because it is
always easier to troubleshoot a large piece of software if it is divided
up internally than if it is just one big
monolithic whole, because you can test each segment. The ball and chain
here is the operating system.
And even then, it's not really that because the OS is just machine code
to the CPU anyway. Once more, more modularization.
I think you and I are more in agreement than you think. You say that
people should operate in the upper layers of Perl and use the modules.
Yet you boast about being able to hack at any level. Well, your
boasting because you know that this is an advantage. If you really and
truly thought that your skills were equal to a perl coder who didn't
understand anything at a low level and just used the modules then you
wouldn't be boasting. But you know what I have been saying is true -
that while a programmer should use the modules, there are times that
if a module isn't working right that you have to dive into the lower
level and figure it out. You can do that while Joe Admin who thinks
that C is something he finds in his alphabet soup cannot.
TM> I'm not proposing that someone take and write a brand new project
TM> from scratch.
TM> For new perl code you want to use as many of the WIDELY USED
TM> modules that have ONGOING SUPPORT as you can. That is a given.
TM> But for older, running code that breaks on new platforms, wouldn't
TM> you rather just correct the bug in it than spend all that time
TM> rewriting it?
nope. you spent way more time fixing this than even a modest rewrite
would have taken. and i am not even talking nntp here. the reason it
blew up was BECAUSE it did the low level stuff poorly and wasn't
portable. that is what bit you. you have it backwards.
Except that I didn't know that this is what bit me until I made a
guess that this was what it was and lo and behold, I fixed it.
Hindsight is easy. Correcting the template proves that the original
code was poorly written, because if the original author really and truly
understood the pack call he would have used the correct template. The
template was wrong the day it was written back in 1998 and it only
worked through what they call "dumb luck" meaning we really don't know
why broken code works on some operating systems and it's not worth
investigating to figure it out. And if I had known at the very
beginning of trying to fix the script that the reason it was broken
in the socket code was because the code was poorly written then I
might have taken a different repair path and just planned on removing
those 10 lines and replacing them with an IO::Socket call wherever they
appeared in the scripts.
Ted
uri
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
