| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 107:31:11 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,677 |
On Tue, Dec 10, 2024 at 09:38:57PM +0100, Serafeim (Serafi) Zanikolas wrote:
On Sat Dec 7, 2024 at 5:15 AM CET, Paul Wise wrote:that's because unsupported ports architectures have not caught up to go 1.21,
Probably adequate is the logical place for this test, but adequate doesn't build/run on ports architectures since it moved to golang,
so piuparts should probably keep its tests on those arches until
adequate moves to a more portable language or golang gets ported.
which was released ~1.5 year ago. I'd claim that that says more about the viability of those ports, than the suitability of go for Debian tooling. if you
feel strongly otherwise, I'd be happy to continue this discussion with a wider
audience at <D4CWM2UJBXDS.339WS39VNMVYO@debian.org> rather than reply here
I dont feel strongly about this, but I'd like to point out that I
disagree. IMO it was wrong to rewrite adequate (as any central QA tool
for Debian) in a language which is not available *everywhere*.
IMO it was wrong to rewrite adequate (as any central QA tool for Debian) in a language which is not available *everywhere*.
[forking to -devel]
On Wed Dec 11, 2024 at 11:15 AM CET, Holger Levsen wrote:
On Tue, Dec 10, 2024 at 09:38:57PM +0100, Serafeim (Serafi) Zanikolas wrote:
On Sat Dec 7, 2024 at 5:15 AM CET, Paul Wise wrote:that's because unsupported ports architectures have not caught up to go 1.21,
Probably adequate is the logical place for this test, but adequate doesn't build/run on ports architectures since it moved to golang,
so piuparts should probably keep its tests on those arches until adequate moves to a more portable language or golang gets ported.
which was released ~1.5 year ago. I'd claim that that says more about the viability of those ports, than the suitability of go for Debian tooling. if you
feel strongly otherwise, I'd be happy to continue this discussion with a wider
audience at <D4CWM2UJBXDS.339WS39VNMVYO@debian.org> rather than reply here
I dont feel strongly about this, but I'd like to point out that I
disagree. IMO it was wrong to rewrite adequate (as any central QA tool
for Debian) in a language which is not available *everywhere*.
I'd like to discuss this with a focus on general principles, and only discuss specifics (adequate, golang) to the extent that it helps reason about general principles.
I'd like to discuss this with a focus on general principles, and only discuss specifics (adequate, golang) to the extent that it helps
reason about general principles.
so we have a qa testing package that was written 11y ago in perl, and
has been orphaned for almost all of that time (10y!). it's not
critical but it does serve a purpose, and it's therefore nonideal that
it's been orphaned for so long.
someone takes it over and rewrites it in a language that runs in all supported arches, and likely in many ports too as long as they keep up
with a relatively recent version of the language (in this case, a
version released 1.5y ago).
on a meta level: I find it incredible that this conversation needs to
be had at all, given the increasing median age of Debian contributors,
and the limited popularity of perl among younger people
The "Perl Problem" is a wider issue we should explore in much more depth.We would first need to determine that there is an actual problem.
The "Perl Problem" is a wider issue we should explore in much more depth.
I'm personally a little surprised if it's true that younger people are unprepared to take a stab at hacking Perl. But since that's the case, we
have deeply embedded, critical stuff written in Perl everywhere. "adequate" is but the tip of the iceberg.
Industrious young people are quite capable of working with any
available tools on projects in any language, I've met plenty of
them, they do exist. I was young once too, if I hadn't been willing
to learn to use tools and languages older than I am, I'd found other
hobbies and/or gone into a different field of work.
The "Perl Problem" is a wider issue we should explore in much more
depth. I'm personally a little surprised if it's true that younger
people are unprepared to take a stab at hacking Perl. But since that's
the case, we have deeply embedded, critical stuff written in Perl
everywhere. "adequate" is but the tip of the iceberg.
On 2024-12-12 20:51, Marco d'Itri wrote:
On Dec 12, Jonathan Dowland <jmtd@debian.org> wrote:
The "Perl Problem" is a wider issue we should explore in much more depth. >> We would first need to determine that there is an actual problem.Perl is quite healthy as a language and has aged much better than many
other younger languages: e.g. there is no need to update all code every
few years because backward compatibility is preserved basically forever
at this point.
+1, advantages of Perl should not be ignored.
That may well be, but that just means that there must be a different reason why Perl has fallen by the wayside, more or less, while Python has anything but.
I'm not getting into the reasons here, that'd make for a way-too-long text, but suffice to say that Python data structures are far more *discoverable* than Perl, which translates to much easier bug fixing. The same thing applies to typing. Did you try to statically-type-check a Perl program lately?
Marc Haber:
I disagree violently with all efforts that would waste Debian people'sITYM "well-working tools".
time to rewrite existing and well-working times just for the sake of
having them in a more "modern" programming language.
That time is much better spent with improving existing tools.
The point of rewriting *is* to improve an existing tool. Or, more
accurately, pave the way towards doing that.
Yes, go ahead with that, but don't force people to do that, and don't
take the old version away until the new one is feature par and bug
free.
don't take the old version away until the new one is feature par and
bug free.
The "Perl Problem" is a wider issue we should explore in much more depth.
I'm personally a little surprised if it's true that younger people are unprepared to take a stab at hacking Perl. But since that's the case, we
have deeply embedded, critical stuff written in Perl everywhere. "adequate" is but the tip of the iceberg.
The actual perl problem is that, since perl is very strict about
backward compatibility, perl scripts written 10 or 20 years ago still
work without requiring maintainance, hence they may appear to be
abandonned.
Rewriting such software in a language that require yearly maintainance
does not simplify maintainance in the long run, quite the opposite.
[forking to -devel]
On Wed Dec 11, 2024 at 11:15 AM CET, Holger Levsen wrote:
On Tue, Dec 10, 2024 at 09:38:57PM +0100, Serafeim (Serafi) Zanikolas wrote:
On Sat Dec 7, 2024 at 5:15 AM CET, Paul Wise wrote:that's because unsupported ports architectures have not caught up to go 1.21,
Probably adequate is the logical place for this test, but adequate doesn't build/run on ports architectures since it moved to golang,
so piuparts should probably keep its tests on those arches until adequate moves to a more portable language or golang gets ported.
which was released ~1.5 year ago. I'd claim that that says more about the viability of those ports, than the suitability of go for Debian tooling.. if you
feel strongly otherwise, I'd be happy to continue this discussion with a wider
audience at <D4CWM2UJBXDS.339WS39VNMVYO@debian.org> rather than reply here
I dont feel strongly about this, but I'd like to point out that I
disagree. IMO it was wrong to rewrite adequate (as any central QA tool
for Debian) in a language which is not available *everywhere*.
I'd like to discuss this with a focus on general principles, and only discuss specifics (adequate, golang) to the extent that it helps reason about general principles.
so we have a qa testing package that was written 11y ago in perl, and has been
orphaned for almost all of that time (10y!). it's not critical but it does serve
a purpose, and it's therefore nonideal that it's been orphaned for so long. someone takes it over and rewrites it in a language that runs in all supported
arches, and likely in many ports too as long as they keep up with a relatively
recent version of the language (in this case, a version released 1.5y ago).
Le Thu, Dec 12, 2024 at 02:36:51PM +0000, Jonathan Dowland a écrit :
The "Perl Problem" is a wider issue we should explore in much more depth.
I'm personally a little surprised if it's true that younger people are
unprepared to take a stab at hacking Perl. But since that's the case, we
have deeply embedded, critical stuff written in Perl everywhere. "adequate" >> is but the tip of the iceberg.
The actual perl problem is that, since perl is very strict about
backward compatibility, perl scripts written 10 or 20 years ago still
work without requiring maintainance, hence they may appear to be
abandonned.
Rewrites after a decade usually reduce complexity and excise features
that turned out to be a bad idea.
Or introduce some subtle bugs that get ironed out only when it sees
usage.
In today's world the alternative is to remove the package - given the
rather aggressive removals we see in testing, if not unstable.
On Sun 15 Dec 2024 at 11:21pm +01, Philipp Kern wrote:
Or introduce some subtle bugs that get ironed out only when it sees
usage.
Indeed, but this work can end up being very costly. A lot of knowledge
might be built into the old code. Even if everything is well
documented
and there are comments in the right places, it's still easy to lose
something in the rewrite.
Then you have to balance the reductions in complexity and excision of features that weren't a great idea, against this risk of costly
regressions. Keeping the old program will often win.
In today's world the alternative is to remove the package - given the
rather aggressive removals we see in testing, if not unstable.
This seems like an overgeneralisation. For Perl, given their strict
stance to backwards compatibility, we can just keep it.
On Wed Dec 11, 2024 at 10:57 PM GMT, Serafeim (Serafi) Zanikolas wrote:
I'd like to discuss this with a focus on general principles, and only discuss specifics (adequate, golang) to the extent that it helps
reason about general principles.
That's going to be pretty hard, because the scenario you present is
still pretty specific.
so we have a qa testing package that was written 11y ago in perl, and
has been orphaned for almost all of that time (10y!). it's not
critical but it does serve a purpose, and it's therefore nonideal that it's been orphaned for so long.
Certainly non-ideal. "Orphaned" does not give the full picture about the state of the package, however: It could describe a package with critical bugs that aren't getting fixed, or nobody doing any QA or NMU uploads of
it ever. Neither looks true for adequate.
someone takes it over and rewrites it in a language that runs in all supported arches, and likely in many ports too as long as they keep up with a relatively recent version of the language (in this case, a
version released 1.5y ago).
"likely in many ports too" is dancing around the fact that it *doesn't*
run on at least one port, hence Holger's complaint.
on a meta level: I find it incredible that this conversation needs to
be had at all, given the increasing median age of Debian contributors,
and the limited popularity of perl among younger people
The "Perl Problem" is a wider issue we should explore in much more
depth. I'm personally a little surprised if it's true that younger
people are unprepared to take a stab at hacking Perl. But since that's
the case, we have deeply embedded, critical stuff written in Perl everywhere. "adequate" is but the tip of the iceberg.