If there is one thing I wish I could take from Perl and give to the current hot languages, it's the importance of not breaking shit when you release new versions of stuff. If someone's code worked yesterday with your library, it should also work today after you add a new feature.
Yet, apparently, this is not the way we do code. We expect every developer to be so devoted to a random library that they keep track of all the breaking changes and are excited about them.
Please stop that.
@joelle I'm a fan of Go for (among others) this reason. I have code written before Go 1.0 came out, and it still compiles and runs fine. It's just faster as the compiler got better, and looks a bit antiquated maybe... But it works the same as the day I wrote it.
I've anecdotally heard companies who work in industries with very long support horizons (think multiple decades) who have nice things to say about it for the same reason. Knowing there's a high probability you can still compile and service the code for a product shipped 15 years ago is a rare thing these days.
@joelle Interesting to hear. It's one of the reasons I dropped Perl after 20+ years of constantly fixing fallout and thinking things would improve long-term.
A noble goal though, definitely worth aiming for, and I'm happy for anyone who is lucky enough and can enjoy it.
@joelle Huh. Absolutely agree, but my experience with perl means I wouldn’t necessarily point at it as a good example. It probably depends on which suburbs of CPAN you tended to hang out in, but I gave up on Perl for new, big production grade apps a decade or so ago, partly for that reason.
I’ve found Go better at not breaking things recently.
@joelle I think that a challenge is that there are sometimes inherent trade-offs between improving the experience for new users or existing users. Sometimes, we want to break compatibility because we've learned and believe that a different design would be easier for new users. If we maintain compatibility, we're stuck with the results of prior decisions. If we break it, we externalize work on others.
But I think it's also reasonable to say that open source authors are not your supply chain :)
@jawnsy @joelle I think depreciation is the solution here. Introduce a new API and delicate the old. Will not be updated, but will compile for those who need whatever it did before.
It's helpful to know that I'm using the latest, best designed API available, but I still need old stuff to compile and run without changes and get the same old (possibly crappy) behaviour because some other code relied on that.
So, keep the old in place, and give us the new and shiny--we can do both!
@kdacar @joelle That's sometimes the solution, sure. But it's not always possible, and there's still a carrying cost for the deprecated approach (even if it's just some extra files in packages, though more likely there's at least some maintenance cost.)
API design and evolution is a tough thing. I think that one of the reasons early-stage projects and startups can be very fast is because they don't have many users/customers, so they can make frequent breaking changes.
@joelle Perl was used a lot by sysadmins, and many of the developers were and are sysadmins. I.e. people who know the value of continuity when it comes to maintenance cost.
Meanwhile, a lot of modern computer stuff (languages, frameworks, etc) are done by people who came out of the early 2000s web developer pool. I.e. the people who run by the credo "we are doing something nobody has done before, we don't need to look at what was done in the past"
And yes, that's the reason we have docker.
You're much younger than me.
Perl had to learn that lesson itself. I've used for my job perl applications (e.g. the NCSTRL - N??? Computer Science Technical Report Library) that broke because at some point (somewhere in 4.0xx) some redundant syntax was repurposed for different semantics (and the authors had left the operating institution long before that point). Twice. The first one was repairable by me (in the client library), the second broke the server's search engine.
Joelle
Dave Anderson
Simon Dassow
David Smith
cliffordheath
Steve Atkins
Jonathan Yu
kdacar
Attila Kinali
Darryl Green
argonaut