Python - hard to re-aquire

[Eric S. Raymond]

Hal Murray <halmurray at sonic.net>:
> 
> > I'm pretty sure this is a problem with the ntpq code, not with Python -
> > Python in general has a reputation for being *easy* to read six months later,
> > which I think is deserved.  It's one of the first things I noticed when I
> > started coding in Python back in 1998 or so. 
> 
> The hard to-go-back-to comment came from friends that I trust as much as I 
> trust you. (I worked closely with them for ~10 years.)

The story of the blind men and the elephant comes to mind.

> I don't maintain a lot of python code.  I have a handful of python hacks.  The 
> small ones are easy to maintain.  I find ntpq hard to work with.  As you 
> suggest, that could be because it is crappy code.

I'm not sure that it's crappy code; some things have to be as complicated as they
are.  What it certainly is is *difficult* code.

>                                                   It could also be because my 
> head depends on type checking and python is full of automatic conversions that 
> conflict with strong type checking.

I think you will be happier working in Go than in Python.  It's strongly tryped,
and the compiler's error messages are so helpful that they come as rather a shock
after years of GCC.

> >> There is a bug in our ntpq, or was not-that-long-ago and I'm pretty sure it 
> 
> > I'm aware.  Some time back I spent a day hunting for that bug.  I couldn't
> > find it.  That's a nasty thicket of code in there. 
> 
> The bug is in the interface between the code that collects packets and checks 
> the sequence numbers to make sure it got all the packets in the clump and the 
> code up a few layers that decides how big the clump should be.  Tangled in 
> there is that the collect-it code should return a partial clump but doesn't.
> 
> I'll track it down if you want to look again.  It may be in the issue already.

If you find the issue could use more detail, please add it.  Then I'm
willing to take anoither swing at fixing the problem.  It has been niggling
at me ever since.

> Another thing to consider...
> 
> You are planning to convert everything to Go without changing the structure, 
> then go back and clean things up.
> 
> Why didn't ntpq get cleaned up after it was moved to Python?

It did. The code ended up as pretty good Python, not just C awkwardly
recoded as Python.  A way to tell that is, for example, that it makes
proper use of first-class maps rather than replicating the many ugly
and unfortunate ways that C programmers try to approximate them.

Often that kind of cleanup exposes and destroys bugs, but it's
certainly not guaranteed to fix *every* pre-existing bug.  I agree
with your analysis - I think there is some dataflow error, that
it was in the C code as well, and it got faithfully replicated by
the faithful translation.

Of course, the same risk of bug-for-bug compatibility exists in doing
a stupid literal translation of ntpd.  But in both cases that risk has
to be compared to a different one, that trying to translate and refactor
or rewrite at the same time will lead to a complexity explosion.

I have seen such explosions before.  They tend to ruin porting efforts
and leave a large blast crater.  I have learned a healthy fear of
trying to do too much during a port.

> [Go being easy to read.]
> > BTW, I will not strongly assert that this is an advantage over Rust, because
> > I never grokked Rust well enough to make a really fair comparison.  But Rust
> > requires a lot of ceremony in the form of lifetime declarations that neither
> > Python nor Go does; a priori this probably does put it at a readability
> > disadvantage.
> 
> This should be an interesting experiment.  The same info that is a 
> complication also tells you what is going on.

Maybe.  Or it could *obscure* what's going on in a surfeit of syntax.  I've
used and read languages that have that tendency.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>