1. 37

  2. 11

    It had 105 million downloads in 2022.

    “Sorta popular”, right. Only 290,000 downloads per day. Lesson one: humility.

    A lot of programmers use Stack Overflow today. (I wish there were a popular nonprofit alternative I could recommended.)

    On the one hand, oof, but on the other hand, I very much like lobste.rs not being “popular”.

    1. 9

      Only 290,000 downloads per day.

      Keep in mind that package-index download counts are tricky numbers, because there are a lot of mirrors of the big popular indexes, and a lot of badly-configured CI tools which download the whole dependency tree from scratch on every run. And in the JS world the way installation works means that a single npm install might actually download multiple copies of any given package in certain circumstances (example: packages foo and bar both depend on package baz, but on different versions of it; npm install will download two copies of baz in that case).

      It’s still a popular package. But always take download counts with a similarly-sized grain of salt.

    2. 5

      I totally agree about avoiding large breaking changes. We had a huge breaking change from CHICKEN 4 to 5, where we completely restructured the module exports, which required people to change essentially all of their code. It was a change that was really needed - before, we had nondescript names like extras and utils and data-structures, where you would not really be able to reason about where things would be (you just had to know). Now we have many smaller modules, like (chicken string) for string procedures and (chicken bitwise) for bitwise operations. And to make things worse, we added large integer support which, while great in itself, introduced various subtle changes in what values certain procedures would return, so you had to deal with those two changes at the same time. There were other changes, as well. I still think the end result is much better, but was quite a painful change and it wouldn’t surprise me if we lost users over it. I know we lost some users over the CHICKEN 3 to 4 change, and that was a much smaller change (we changed the way extensions were packaged, and we introduced modules, which were optional, but strongly recommended for extension libraries - we enforced that though, which may not have been the best thing to do).

      We decided to make all these big changes (from 4 to 5) under the motto “well, this is going to be a major breaking release anyway”, but in retrospect that’s a bad way to go. It’s much better to contain the changes to one particular thing, and indeed plan your way over the next months or years to make the other changes. And try to make them in a way that backwards compatibility is possible, or at least offer a solution to migrating from old to new.

      This was before Python 3 (or at least, before it became so hated), so we didn’t yet have a negative example to guide us (I guess common sense failed us as much as the Python folks).

      1. 2

        I think the really bad thing is if the breaking changes aren’t documented. Either all or just in a very convoluted way. I honestly don’t care if I need to change code, but 90% the project assumes I’m using it day to day and am a complete pro and not “Someone else wrote this app 2 years ago and now I need to change a single line but you don’t have any useful examples”.

        1. 2

          We decided to make all these big changes (from 4 to 5) under the motto “well, this is going to be a major breaking release anyway”, but in retrospect that’s a bad way to go.

          The big lesson I take from the Python 3 debacle (and more recently, the Vue 3 debacle) is that you can break backward compatibility, but you can’t break forward compatibility. Eventually the six package was created to make Python 2 forward compatible, and along with some changes to Python 3, that unjammed the ecosystem, but in retrospect, it would have been better to plan for forward compatibility from the beginning.

        2. 2

          Helmet is nice, than you for it. ❤️

          I would be willing to bet that size optimisations save more than that, if they affect end-users too?

          1. 1

            I wish there were a popular nonprofit alternative I could recommended.

            Why is that? SO has made the lives of so many programmers better, myself included. Surely it’s a good thing that the founders are able to profit by it?

            1. 4

              It’s important enough that it shouldn’t be in the hands of a couple people. If it’s a company, it can be bought; if it can be bought, it can be destroyed. Look at freenode.

              1. 5

                At least the data/content is licensed and made available in such a way to disincentivise any stewards of the site, current or future, from doing too terrible a job of it.

                1. 3
                  1. 2

                    If something is important it absolutely should be in the hands of people who can profit from it, because otherwise it will be going away.

                    1. 6

                      You’re commenting on a free site about a post someone wrote for free about maintaining software for free for nearly a decade and (my understanding of) your takeaway is that only extraction capitalism can possibly create sustained value.

                      Meanwhile musk is burning for-profit twitter to the ground and I can’t take my kids to Toys R Us anymore because hedge firms exist.

                      I think we need more nuance and understanding.

                      1. 1

                        This site exists free of charge and advertising solely through obscurity. Pretending otherwise is disingenuous to say the least.

                        1. 5

                          Every town in the Western world has churches which are non-profit entities. Whether you think they’re good or bad, they definitely exist and aren’t explicitly profit seeking. There are lots of ways to make a sustainable endeavor. The for profit corporation is one, but there are others.

                          1. 1

                            I think you missed my forest for my tree.

                        2. 2

                          Wikipedia? A seemingly close cousin to Stackoverflow.

                          1. 1

                            I’m aware that it exists, and also that it would be the major exception anybody could mention. Stack overflow is not going to run on the “nag everybody who’s details we have for donations until the heat death of the universe” model.

                            1. 2

                              Is your argument that Stackoverflow won’t or that it’s impossible and nobody should try? Because the OP said alternative, arguing against the latter, and the existence of Wikipedia stands to me as a beacon of what’s possible, inviting us to imagine and build better.

                    2. 1

                      When I have grander visions, I try to roll them out over many versions and many months.

                      I don’t use helmet.js so I’m confused as to what that statement means. If a grand vision cannot be implemented without breaking anyone’s code, then the total amount of breakage over time is going to be the same. Are we talking about the choice between a large breaking change with a huge announcement and a migration guide versus creeping incompatibility that keeps breaking programs of many people in small ways?

                      I absolutely despise the creeping incompatibility approach that some projects, sadly, choose. If the only way to bring a vision to life requires breaking people’s programs, then there should be a legacy maintenance release line to give people time to migrate, people need to be properly made aware of the change, and there should be a guide to adapting to new versions.

                      If a grand vision doesn’t actually require breaking changes, then what’s the issue? For compatibility purposes, it doesn’t matter if it’s rolled out gradually or at once.

                      1. 1

                        That depends - for people upgrading at a very slow pace, it makes no difference, or even makes things harder as they have to gather the changes from all the intermediate versions. For people upgrading perhaps not every single release, but let’s say every 2 to 4 months, those will be faced with less changes to their code every time they upgrade, allowing them to ease their way into the new way of doing things. So for them it would make things easier.

                        For folks who religiously update every time a new release comes out, it’s a bit of a toss-up. On one hand, it could be annoying to have to make adjustments every single time, but it also (hopefully) means the adjustments are rather small.