The end of an era: Saying goodbye to search.cpan.org
61–70 of 125 posts
Re: The end of an era: Saying goodbye to search.cpan.org
#62Earlier quoted context omitted.
It tells us that a solo maintainer of a large project - with no assistance from the community possible, because closed source - trying to do it in his spare time, will eventually result in a massive accretion of technical debt. It's a testament to Graham's productivity that he was able to keep maintaining it for so long in spite of those disadvantages, and says very little about perl.
Does it necessarily follow that a solo dev, working on a project in their spare time, will accrue massive technical debt? I'm honestly asking, as a solo dev that works on projects in my spare time. If it is the natural progression, how can it be avoided?
Personally, I'm prone to taking on technical debt when under time pressure or feature pressure. I think of it like my house: if I'm too busy, I get sloppy and leave messes. If I stay busy for too long, the messes stack up.
One complicating factor, though, is the age of the code base is a factor, too. Keeping up with new runtimes, new frameworks, and new ways of doing thing takes time. This is especially a problem with things built in the new hotness, because there the culture is one of rapid iteration. So if we really want side projects to last, I think we have to choose boring technology: http://mcfunley.com/choose-boring-technology
Re: The end of an era: Saying goodbye to search.cpan.org
#63Earlier quoted context omitted.
It tells us that a solo maintainer of a large project - with no assistance from the community possible, because closed source - trying to do it in his spare time, will eventually result in a massive accretion of technical debt. It's a testament to Graham's productivity that he was able to keep maintaining it for so long in spite of those disadvantages, and says very little about perl.
Does it necessarily follow that a solo dev, working on a project in their spare time, will accrue massive technical debt? I'm honestly asking, as a solo dev that works on projects in my spare time. If it is the natural progression, how can it be avoided?
Rewriting software is somewhat of an inevitability it seems like, but the more small reusable pieces you have, the easier that is. Think UNIX philosophy: small units that do a small amount of things well that you can generally depend on once they become stable.
It varies depending on your project of course. A lot of the tech debt you take on (fun new tech, getting something out fast) is half the fun.
Re: The end of an era: Saying goodbye to search.cpan.org
#64For people under 40: "Perl" refers to a script interpreter that used to be popular in the 90's.
Re: The end of an era: Saying goodbye to search.cpan.org
#65> Luckily, there is now a viable > alternative: MetaCPAN.org[...] This is somewhat of a revisionist history. MetaCPAN has been around in a form where it's been a good search.cpan.org replacement since 2012 at least, but for some reason that whatever set of people that run perl.org haven't wanted to switch serch.cpan.org over. I'm very grateful to the effort of Graham Barr in creating serch.cpan.org, and fully underst…
Re: The end of an era: Saying goodbye to search.cpan.org
#66Earlier quoted context omitted.
It tells us that a solo maintainer of a large project - with no assistance from the community possible, because closed source - trying to do it in his spare time, will eventually result in a massive accretion of technical debt. It's a testament to Graham's productivity that he was able to keep maintaining it for so long in spite of those disadvantages, and says very little about perl.
Does it necessarily follow that a solo dev, working on a project in their spare time, will accrue massive technical debt? I'm honestly asking, as a solo dev that works on projects in my spare time. If it is the natural progression, how can it be avoided?
This is exactly how my own long-term projects that actually have users have panned out. When everything is left to your own energy and charity yet it doesn't pay the bills, when there's work to be done then the project is lucky to get whatever you can spare.
And it typically needs work in spite of what's going on in your personal life. I was at the beach when my hand-coded forum went down (btw, don't build your own forum). I ended up patching it live on the server, guessed at the problem, and had to clean up my mess weeks later.
If you don't actually have users, then sure, that's something entirely different. I have plenty of projects that never left localhost with no technical debt, too. That's trivial.
Re: The end of an era: Saying goodbye to search.cpan.org
#67I guess it was probably in the same server room as wuarchive, which at its peak in the 90s was rumored to represent 10% of the traffic on the internet. Was cool to look through the glass into the server room in the engineering school, and see the lights blinking like crazy on the RAID array attached to wuarchive's server.
Re: The end of an era: Saying goodbye to search.cpan.org
#68Earlier quoted context omitted.
I am a Perl hater, but mostly from having to dig into 10 year old legacy code for apps that nobody has touched for 5 years that still run . So like on the one hand, old perl is basically unmaintainable punctuation vomit, but on the other hand, there’s a lot of 10 year old perl code out there just chugging a long, which is nothing to sneeze at.
I'm not disagreeing with you, but the first Perl project I started in 1999 in my dorm room had its latest, major release two days ago. I've never thought of maintaining your own Perl code as impossible. And I'm no wizard. I've honestly wondered if maintaining someone else's forgotten Perl code, modernizing it, and getting it so that'll it'll run for another x years isn't all that bad of a niche job.
Re: The end of an era: Saying goodbye to search.cpan.org
#69Earlier quoted context omitted.
It tells us that a solo maintainer of a large project - with no assistance from the community possible, because closed source - trying to do it in his spare time, will eventually result in a massive accretion of technical debt. It's a testament to Graham's productivity that he was able to keep maintaining it for so long in spite of those disadvantages, and says very little about perl.
Does it necessarily follow that a solo dev, working on a project in their spare time, will accrue massive technical debt? I'm honestly asking, as a solo dev that works on projects in my spare time. If it is the natural progression, how can it be avoided?
The trick is to avoid overstretching yourself in terms of what you promise - or to recruit a team. In this case, neither happened, and so the result was unfortunately inevitable.
Re: The end of an era: Saying goodbye to search.cpan.org
#70This is truly a down moment, to be sure, but it's pretty telling that the site became too hard to maintain because it's written in old Perl. I'm not a Perl hater. I like Perl! I got my start in Perl and spoke at a YAPC::NA a few years ago. It's telling, is all I'm saying. It tells us something.
Some other telling factors.
The level of activity/projects in perl compared to python.
http://twimgs.com/ddj/images/article/2014/0114/Tiobe1.gif
http://www.drdobbs.com/jvm/the-rise-and-fall-of-languages-in...
Or the fact that perl isn't even relevant enough to be part of a comparison of major script-like languages.
https://stackoverflow.blog/wp-content/uploads/2017/09/growth...
But the most telling part is the lack of perl vs python flamewars. Remember those? Even the most ardent perl fan has conceded that python won.
In the immortal words of TS Eliot, "this is the way perl ends, not with a bang, but with a whimper".