Logfile visualization tools - request for comment
Eric S. Raymond
esr at thyrsus.com
Tue Jul 19 04:14:00 UTC 2016
Dan Drown <dan-ntp at drown.org>:
> I don't see a compelling reason to switch to python. I guess I don't see
> the pain points.
They're not a problem you have, really.
*I* feel a very strong need to hold the number of scripting languages
used in NTPsec down to a minimum, because a pattern I've observed more
than once in multilanguage projects is this: code in the most
frequently-used language gets a lot of love, code in the second
most-frequently used gets enough (maybe) and it's bitrot all the way
down for code in the third through nth languages.
You can actually see this pattern the Classic code if you look at the
relative state of the C, Perl, S, and awk stuff. I think it's a
sort of adverse-selection effect of how contributors match themselves
Our language #2 is Python for a couple of reasons. (1) Requiring
Python for scripting doesn't worsen our dependencies, because the
build system needs it anyway. (2) Python scores quite high on
readability six months later, actually higher than any other language
I know of. (3) The drive-scripting-to-Python policy worked *very* well
There we tolerate a limited amount of sh scripting and I will here, too,
but Perl is right out; translating or scrapping the Perl/S/awk stuff
is definitely on the to-do list.
The only reason I can offer you to switch is that the Python adaptation *will*
ship with NTPsec. I think it would be more efficient for both you and us
that you join us in maintaining that, rather than having two implementations
and duplicated effort. Also, I'm quite good at documentation and wlling
to bribe you with applications of that skill. :-)
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel