8 ms·

Stability by Design

132 points by potetm 1y ago

simultsop 1y ago
TLDR. The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes.
- ashishb 1y ago
  > The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes. No. In statically typed languages, failures are usually caught in CI. In dynamically typed languages, they end up in production - https://github.com/pypa/setuptools/issues/4519 https://github.com/pypa/setuptools/issues/4519
  - phoronixrly 1y ago
    Maybe that's a bad example, as your build can fail because of a breaking change in a dependency regardless of whether you use a statically typed language. Also your statement is only partially correct. Breaking changes in dependencies end up in production only if you don't have tests. And I know this is news to many people using static types but in many Ruby shops for example there are test coverages in excess of 90% and at the very least I never approve a PR without happy path tests.
    - ashishb 1y ago
      > Breaking changes in dependencies end up in production only if you don't have tests. That's true. However, you have now replaced the work of a compiler with testing.
      - dyarosla 1y ago
        Compilers dont test, or rather, they test a very specific and narrow set of things relative to what youd want to test to maintain a working program
      - jiehong 1y ago
        Refactoring from a function returning a string to another returning a string, and all compiles, yet without tests nothing works in production because it’s not the same string. On top of that, sometimes mocking in tests also hide the string breaking change you don’t yet know about. On top of my head, I saw this happen with a base64 string padded vs unpadded, or emojis making their way through when they did not before, etc. So yeah, the compiler tells you which pieces of your jigsaw apparently fit together, but tests show you if you get the right picture on the jigsaw at the end (or on some regions).
        yakshaving_jgt 1y ago
        Isn't it a shame that we're only allowed to have one or the other.
    - lmm 1y ago
      A test suite often ends up acting as an ad-hoc, informally specified, buggy, slow implementation of half a static type system yes.
      - phoronixrly 1y ago
        I mean sure, if your test suite does fuzzing, then I guess so. Most test suites focus on higher level stuff like behaviours and entire features these days. This is instead of testing in isolation the technicalities like the signatures of functions and what happens if you pass a null here or there.
        lmm 1y ago
        The same applies to type systems these days - you don't just express basics like nullable or not, you build high level business concerns into your types.
    - lelanthran 1y ago
      > Breaking changes in dependencies end up in production only if you don't have tests. Which are opt-in in dynamically typed languages. You get the same functionality in statically typed languages and it's not opt-in, AND the developer doesn't have to do the work of type-checking (the compiler does it).
      - phoronixrly 1y ago
        I will keep in mind for future projects that you don't need tests in compiled languages because the compiler does it for you. Will also keep in mind that tests are optional. This is def. a healthy mindset.
        lelanthran 1y ago
        > I will keep in mind for future projects that you don't need tests in compiled languages because the compiler does it for you. who said that? > Will also keep in mind that tests are optional. This is def. a healthy mindset. Once again, I have to ask - where did you get that from?
      - simultsop 1y ago
        In a utopic scenario, yes, you fix type-checking and you can live happily ever after. In an interoperable environment, when additional programming languages/teams are in play, which is very frequent nowadays. You have the problem of centralizing types/entities/schemas, reused types, partial types, and union types, and you can keep the story on. At some point, instead of typing being an invisible tool, it becomes the tool. Then you superset the tool to other languages, because they are in an immutable state. Another language will emerge with dynamic typing in decades then people will take the same spiral and spend more time to reason wages.
  - simultsop 1y ago
    Leaking bugs, I believe, do not relate to static typing or dynamic typing; it mostly involves deployment. Your types might match, but you would still leak bugs in dependencies :/ From a CI/CD perspective, you should make sure that on updates, things won't break. As others suggest, a maintainable project would have test suites. Except if you aim to have a program that you will never update again. Write the code once, compile it, and archive it. When you decide to keep that program available to potential clients, be prepared to back up dependencies, the OS it runs on, and everything that makes it operable. If there is a breaking change in the ecosystem of that program, it will break it.
Animats 1y ago
I'm currently struggling with instability in the Rust 3D graphics stack. All this stuff has been around for about five years now, and was mostly working five years ago. The APIs should have settled down long ago. Despite this, there are frequent "refactorings" which cause breaking changes to APIs. (I'm tempted to term this "refuckering".) Some of this API churn is just renaming types or enum values for consistency, or adding new parameters to functions. Some changes are major, such as turning an event loop inside out. Code using the API must be fixed to compensate. Because of all the breaking changes, the related crates (Wgpu, the interface to Vulkan, etc., Winit, the interface to the operating system's window manager, and Egui, which handles 2D dialog boxes and menus) must advance in lockstep. There's not much coordination between the various development groups on this. Wgpu and Winit both think they're in charge. and others should adapt to them. Egui tries to cope. Users of the stack suffer in silence. When there's a bug, there's no going back to an older version. The refuckering prevents that. Changes due to API breaks are embedded in code that uses these APIs. I'm currently chasing what ought to be a simple bug in egui, and I've been stuck for over a month. The unit tests won't run for some target platforms that used to work, and bug reports are ignored while new features are being added. (Users keep demanding more features in Egui, and Egui is growing towards web browser layout complexity.) Most users are giving up. In the last year, three 3D rendering libraries and two major 3D game projects have been abandoned. There's are about two first-rate 3D games in Rust, Tiny Glade and Hydrofoil Generation, and both avoid this graphics stack. The "Stability by Design" article is helpful in that it makes it clear what's gone wrong in Rust 3D land.
- potetm 1y ago
  That sounds like a complete tirefire tbh. The exact thing that I'm hoping to convince people to stop doing. I'm glad the article was helpful though!
  - Animats 1y ago
    All the players think they're doing the right thing. Each group is doing a reasonably good job based on their own criteria. But their collective actions create a mess.
- 1y ago
juancn 1y ago
The premise feel weird to me, I read the graphs much more as evidence of how scared the devs are to make changes rather than how "stable" the libraries are. You add the code, and rather than change it if needed, you just leave it there and add more code. You could argue too that Scala is much safer so changes to the code are not scary and it's easier to be stable even under code changes.
- olivierduval 1y ago
  Actually, you can't neither read that or the opposite from the graphs: it doesn't if the new code is for new functionalities or if it's to replace (without deleting) some old code. But you're right: that would be a particularily useful information
alexjurkiewicz 1y ago
I think code retention charts will look similar for any major library in any language. Projects accrete code. You could instead consider: * How many major version releases / rewrites happen in this language? (This might be a sign of ecosystem instability.) * How much new code is replacing old code? (This might imply the language needs more bugfixes.)
- potetm 1y ago
  Not sure what you mean. The Scala example looks nothing like the Clojure examples. The retention charts show you how much new code is replacing old code, and you can see the releases/rewrites as the code gets replaced.
  - deleted 1y ago
    [deleted]
  - chatmasta 1y ago
    The charts are very cool. But they’d be more informative if they tracked _interface_ changes. Maybe Scala is more flexible and the code changes are limited to optimizing the underlying implementation while keeping stable interfaces. It’s impossible to tell from the charts.
- KronisLV 1y ago
  > code retention charts I really liked those charts, I wonder how you can generate them, whether there's a tool out there that you can just feed a Git repo into or something.
  - potetm 1y ago
    pip install git-of-theseus git clone repo cd repo git-of-theseus-analyze . git-of-theseus-stack-plot cohorts.json
    - KronisLV 1y ago
      Thank you! This was super useful!
RandomWorker 1y ago
As a recent Clojure convert of 3 years or so, I love reading how amazing Clojure is. As a solo Dec there is simply no alternative. It’s so nice to return to a project 2 or 3 years ago and everything is still running and humming along smoothly as it did when I started the project. I previously worked in PHP, Perl-cgi, Java, and Python- webtools mostly based on MySQL and other SQL database flavours. I worked in a Clojure only shop for a while and they taught me the ways after that you don’t go back. Everything can quickly click into place, it’s daunting to start the learning curve is very unsteep, takes long to get anywhere, but as a curiosity it was fun, then I started to hate how everything else was done now I’m sold my soul to the Clojure devil.
- potetm 1y ago
  love it!
munificent 1y ago
It's true that if you always add new functions to your library instead of changing existing ones then users can upgrade without breaking. There is real value in that. But woe unto the user who first starts using your library after a decade of that "evolution" and they are faced with a dozen functions that all have similar but increasingly long names and do very similar things with subtle but likely important differences. (I guess a culture of "the longest function name is probably the newest and the one you want" will emerge eventually.) Personally, I like when a library's API represents the best way the author knows to tackle a given problem today without also containing an accumulated pile of how they thought the problem should have been tackled years ago before they knew better. If I want the old solutions, that's what versioning is for. I'll use the old version.
- christophilus 1y ago
  Agreed. Create a new library if there’s truly a better way. That does seem to be what happens in Clojure from what I’ve seen.
- eviks 1y ago
  > If I want the old solutions, that's what versioning is for. I'll use the old version. And you'll miss all the stuff you do not want the old solution for. And all the old bugs > faced with a dozen functions that all have similar but increasingly long names and do very similar things with subtle but likely important differences. Unless all the old versions are marked add old/deprecated and can be hidden from your view. Then you only care about the old stuff if you used it before and don't want to change
- mwcampbell 1y ago
  It's no wonder that newcomers to Win32 find it intimidating.
  - munificent 1y ago
    And C++ for that matter.
0xDEAFBEAD 1y ago
>For example, over its lifetime the Clojure community has shifted from accepting argument lists and named parameters in their functions to accepting a single hashmap. This is because the single hashmap is easier to grow over time. This seems a little nuts, to be honest. It feels like you're just pushing failures from easy-to-diagnose issues with the function signature, to hard-to-diagnose issues with the function body. Basically the function body now has to support any combination of hash parameters that the function has ever taken over its entire history -- Is this information documented? Do you have test coverage for every possible parameter combo?
- jiehong 1y ago
  I think it was meant from old style functions to new style, but not changing a given function’s signature this way.
- MarkMarine 1y ago
  no, you pull out the things you need from the map in the function body and move forward. I recommend either reading up on how this works in Clojure or just trying it, it's pretty simple. https://clojure.org/guides/destructuring#_associative_destructuring https://clojure.org/guides/destructuring#_associative_destru... Some extra reading if you're curious: https://softwareengineering.stackexchange.com/questions/272302/use-map-instead-of-class-to-represent-data-rich-hickey https://softwareengineering.stackexchange.com/questions/2723...
- upghost 1y ago
  It is nuts, especially in ClojureScript. "Am I missing a key, is the value in the hashmap nil, or was there an upstream error or error in this function that is presenting as nil?"
- potetm 1y ago
  I'm sympathetic to this idea, but in practice it's very manageable. Function signatures destructure exactly the data that they need, so it's easy to tell what's required and what's optional. Of course, normal rules apply like, "Don't pollute your program with a proliferation of booleans."
asalahli 1y ago
> I selected the following libraries off the top of my head with three criteria: all have more than 500 stars and are in active use. This sentence bothered me way more that it should've, for some reason.
- potetm 1y ago
  Ah! You caught me in an editing discontinuity.
boxed 1y ago
> I told Martin as much, and he agreed without hesitation that we needed to find a solution that didn't break current users' code. This is not a normal interaction amongst software engineers—a breed infamous for their long, drawn out debates on the most minute of details. However, this is absolutely expected in the Clojure community. Well that's just slander as far as I'm concerned. Of course we other non-clojure programmers believe in backwards compatibility. What a crazy thing to suggest that we don't.
- potetm 1y ago
  Maybe I didn't do a good enough job demonstrating how common it is for backwards compatibility to be broken. You're right that many devs value stability—not just clojure devs. But there are also many communities where breaking stuff is normal. This is addressing the latter, obviously.
lelanthran 1y ago
> I told Martin as much, and he agreed without hesitation that we needed to find a solution that didn't break current users' code. This is not a normal interaction amongst software engineers I find this to be extremely "it depends": this is a normal interaction amongst software engineers, if you have mature engineers. It's only not normal in those ecosystems (Everyone knows which ones those are) which appear to have not had adults in the rooms during the design phase. If you've only been developing for the last decade or so, you may think it's normal that stuff breaks all the time when software is upgraded. If you've been developing since the 90s you'd know that "upgrades brings breakage" is a new phenomenon, and the field (prior to 2014 or thereabouts) is filled with engineering compromises made purely to avoid breakage. It's why, if I have an application from 10 years ago in React, I won't even try to build it again, but if I have an application from 1995 in C, it'll build just fine, dependencies included[1] (with pages of warnings, of course). [1] C dependency graphs are small and shallow, because of the high friction in adding third-party libraries.
- wereHamster 1y ago
  To be fair, React itself has been exceptionally stable compared to the rest of the JavaScript / Node.js ecosystem. It's the other packages that are causing build failures, not React. Yes, React did deprecate and eventually remove some features, and those were real breaking changes. But it was at a far lower pace than every other package out there.
- potetm 1y ago
  fair
JackSlateur 1y ago
One great way to have stability is to rebase old code against new code Say, you have the first function, with a specific signature and it does its stuff Then later, you improve the stuff and the signature changes with a breaking change Do not do that Instead, create a new function (with a new signature) and push in it the whole code And rewrite the old function to use your new function This way, you keep one "production code": the new function. And you keep one interface-to-legacy code: the old function (which is nothing but a compatible gateway to the new function, and can be easily forgotten) Old users have no breaking, new users have features, you keep a single code and are only burdened with a small compatible layer
benrutter 1y ago
Caveat that I only have a tiny amount of experience with Clojure and none at all with Scala, so this isn't coming from a place of language knowledge in those fields. I'm not convinced though that the Clojure graph represents something I'd view positively. Notably, the Scala codebase gets smaller at one point, which looks fantastic to me. Nobody want the world changing under there feet every five seconds, but if code just accumulates without refactors, the end product often becomes not only unusable, but also difficult to replace. Personally, I'd much prefer more frequent refactors in a changing codebase (vs code addition) but with a strict adherance to semvar, that way, I can stick on v3 or whatever if I'm worried about v4 breaking things for me, but the project itself doesn't need to worry about stagnating, or being stuck with design decisions that aren't relevant anymore. I'm always happy when I see a library like pyarrow that has high version numbers, because I take it as a sign that they're most likely actually following semvar, as opposed to libraries that stay on v0 for 10+ years.
andai 1y ago
When I asked ChatGPT for help with Zig during a game jam, it gave me a bunch of code that was no longer valid. It used to be, but the compiler changed. I understand it's an extreme example — Zig is both niche and pre-1.0 — but it was the first thing that came to mind as a counterexample to, an API that never changes. It's not just an LLM thing, when I looked up tutorials and docs, most of them were also using code that didn't work anymore. And the library I needed only worked with a specific version, so I had to upgrade.. but not too far! Boring, "painful" languages, by contrast, were quite productive for game jams. Except the time when adding a member to a class broke the Emscripten build on the last day, and it took me the entire day to track it down (because why on earth would it be that!)
globnomulous 1y ago
This is really surprising. One of the first things I learned when I started shipping APIs and software packages is that the behavior you expose and the interface you provide for it have to be written in stone. The alternative is to break code and other packages that depend on it. Your package's changes are always somebody else's bugs. Compile-time errors and static analysis provide helpful guarantees and reduce suffering, but that doesn't change the fact that when you introduce changes you're still throwing Legos on the floor of someone's bedroom while they sleep. Major-version revisions by definition allow for breaking changes, but a breaking change needs strong justification: either you know nobody or few users are using what you've changed, or there's broad consensus that there's a bug (but one that didn't need to be fixed with a minor-version update, so it's probably a design problem, not a code bug), or the people using it broadly agree on the need for or benefit of the change.
kazinator 1y ago
One Happy Fellow somehow never encountered silently breaking dependencies in static languages.
kazinator 1y ago
Those strata graphs don't prove anything about stability, because a small number of lines of code (that don't make any difference to the graph) can wreck stability. Whereas a complete rewrite of something quite large can be utterly backwards compatible (bug for bug, even) and not break anyone. Too much horizontal striping in this kind of graph can be bad news: the project isn't improving its old code. That could be because the code is perfect and doesn't need anything, or it could be that the maintainers are not confident enough to touch it.

132 points by potetm 1y ago

TLDR. The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes.

ashishb 1y ago
> The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes. No. In statically typed languages, failures are usually caught in CI. In dynamically typed languages, they end up in production - https://github.com/pypa/setuptools/issues/4519 https://github.com/pypa/setuptools/issues/4519
- phoronixrly 1y ago
  Maybe that's a bad example, as your build can fail because of a breaking change in a dependency regardless of whether you use a statically typed language. Also your statement is only partially correct. Breaking changes in dependencies end up in production only if you don't have tests. And I know this is news to many people using static types but in many Ruby shops for example there are test coverages in excess of 90% and at the very least I never approve a PR without happy path tests.
  - ashishb 1y ago
    > Breaking changes in dependencies end up in production only if you don't have tests. That's true. However, you have now replaced the work of a compiler with testing.
    - dyarosla 1y ago
      Compilers dont test, or rather, they test a very specific and narrow set of things relative to what youd want to test to maintain a working program
    - jiehong 1y ago
      Refactoring from a function returning a string to another returning a string, and all compiles, yet without tests nothing works in production because it’s not the same string. On top of that, sometimes mocking in tests also hide the string breaking change you don’t yet know about. On top of my head, I saw this happen with a base64 string padded vs unpadded, or emojis making their way through when they did not before, etc. So yeah, the compiler tells you which pieces of your jigsaw apparently fit together, but tests show you if you get the right picture on the jigsaw at the end (or on some regions).
      - yakshaving_jgt 1y ago
        Isn't it a shame that we're only allowed to have one or the other.
  - lmm 1y ago
    A test suite often ends up acting as an ad-hoc, informally specified, buggy, slow implementation of half a static type system yes.
    - phoronixrly 1y ago
      I mean sure, if your test suite does fuzzing, then I guess so. Most test suites focus on higher level stuff like behaviours and entire features these days. This is instead of testing in isolation the technicalities like the signatures of functions and what happens if you pass a null here or there.
      - lmm 1y ago
        The same applies to type systems these days - you don't just express basics like nullable or not, you build high level business concerns into your types.
  - lelanthran 1y ago
    > Breaking changes in dependencies end up in production only if you don't have tests. Which are opt-in in dynamically typed languages. You get the same functionality in statically typed languages and it's not opt-in, AND the developer doesn't have to do the work of type-checking (the compiler does it).
    - phoronixrly 1y ago
      I will keep in mind for future projects that you don't need tests in compiled languages because the compiler does it for you. Will also keep in mind that tests are optional. This is def. a healthy mindset.
      - lelanthran 1y ago
        > I will keep in mind for future projects that you don't need tests in compiled languages because the compiler does it for you. who said that? > Will also keep in mind that tests are optional. This is def. a healthy mindset. Once again, I have to ask - where did you get that from?
    - simultsop 1y ago
      In a utopic scenario, yes, you fix type-checking and you can live happily ever after. In an interoperable environment, when additional programming languages/teams are in play, which is very frequent nowadays. You have the problem of centralizing types/entities/schemas, reused types, partial types, and union types, and you can keep the story on. At some point, instead of typing being an invisible tool, it becomes the tool. Then you superset the tool to other languages, because they are in an immutable state. Another language will emerge with dynamic typing in decades then people will take the same spiral and spend more time to reason wages.
- simultsop 1y ago
  Leaking bugs, I believe, do not relate to static typing or dynamic typing; it mostly involves deployment. Your types might match, but you would still leak bugs in dependencies :/ From a CI/CD perspective, you should make sure that on updates, things won't break. As others suggest, a maintainable project would have test suites. Except if you aim to have a program that you will never update again. Write the code once, compile it, and archive it. When you decide to keep that program available to potential clients, be prepared to back up dependencies, the OS it runs on, and everything that makes it operable. If there is a breaking change in the ecosystem of that program, it will break it.

Animats 1y ago

I'm currently struggling with instability in the Rust 3D graphics stack. All this stuff has been around for about five years now, and was mostly working five years ago. The APIs should have settled down long ago. Despite this, there are frequent "refactorings" which cause breaking changes to APIs. (I'm tempted to term this "refuckering".) Some of this API churn is just renaming types or enum values for consistency, or adding new parameters to functions. Some changes are major, such as turning an event loop inside out. Code using the API must be fixed to compensate. Because of all the breaking changes, the related crates (Wgpu, the interface to Vulkan, etc., Winit, the interface to the operating system's window manager, and Egui, which handles 2D dialog boxes and menus) must advance in lockstep. There's not much coordination between the various development groups on this. Wgpu and Winit both think they're in charge. and others should adapt to them. Egui tries to cope. Users of the stack suffer in silence. When there's a bug, there's no going back to an older version. The refuckering prevents that. Changes due to API breaks are embedded in code that uses these APIs. I'm currently chasing what ought to be a simple bug in egui, and I've been stuck for over a month. The unit tests won't run for some target platforms that used to work, and bug reports are ignored while new features are being added. (Users keep demanding more features in Egui, and Egui is growing towards web browser layout complexity.) Most users are giving up. In the last year, three 3D rendering libraries and two major 3D game projects have been abandoned. There's are about two first-rate 3D games in Rust, Tiny Glade and Hydrofoil Generation, and both avoid this graphics stack. The "Stability by Design" article is helpful in that it makes it clear what's gone wrong in Rust 3D land.

potetm 1y ago
That sounds like a complete tirefire tbh. The exact thing that I'm hoping to convince people to stop doing. I'm glad the article was helpful though!
- Animats 1y ago
  All the players think they're doing the right thing. Each group is doing a reasonably good job based on their own criteria. But their collective actions create a mess.
1y ago

juancn 1y ago

The premise feel weird to me, I read the graphs much more as evidence of how scared the devs are to make changes rather than how "stable" the libraries are. You add the code, and rather than change it if needed, you just leave it there and add more code. You could argue too that Scala is much safer so changes to the code are not scary and it's easier to be stable even under code changes.

olivierduval 1y ago
Actually, you can't neither read that or the opposite from the graphs: it doesn't if the new code is for new functionalities or if it's to replace (without deleting) some old code. But you're right: that would be a particularily useful information

alexjurkiewicz 1y ago

I think code retention charts will look similar for any major library in any language. Projects accrete code. You could instead consider: * How many major version releases / rewrites happen in this language? (This might be a sign of ecosystem instability.) * How much new code is replacing old code? (This might imply the language needs more bugfixes.)

potetm 1y ago
Not sure what you mean. The Scala example looks nothing like the Clojure examples. The retention charts show you how much new code is replacing old code, and you can see the releases/rewrites as the code gets replaced.
- deleted 1y ago
  [deleted]
- chatmasta 1y ago
  The charts are very cool. But they’d be more informative if they tracked _interface_ changes. Maybe Scala is more flexible and the code changes are limited to optimizing the underlying implementation while keeping stable interfaces. It’s impossible to tell from the charts.
KronisLV 1y ago
> code retention charts I really liked those charts, I wonder how you can generate them, whether there's a tool out there that you can just feed a Git repo into or something.
- potetm 1y ago
  pip install git-of-theseus git clone repo cd repo git-of-theseus-analyze . git-of-theseus-stack-plot cohorts.json
  - KronisLV 1y ago
    Thank you! This was super useful!

RandomWorker 1y ago

As a recent Clojure convert of 3 years or so, I love reading how amazing Clojure is. As a solo Dec there is simply no alternative. It’s so nice to return to a project 2 or 3 years ago and everything is still running and humming along smoothly as it did when I started the project. I previously worked in PHP, Perl-cgi, Java, and Python- webtools mostly based on MySQL and other SQL database flavours. I worked in a Clojure only shop for a while and they taught me the ways after that you don’t go back. Everything can quickly click into place, it’s daunting to start the learning curve is very unsteep, takes long to get anywhere, but as a curiosity it was fun, then I started to hate how everything else was done now I’m sold my soul to the Clojure devil.

potetm 1y ago
love it!

munificent 1y ago

It's true that if you always add new functions to your library instead of changing existing ones then users can upgrade without breaking. There is real value in that. But woe unto the user who first starts using your library after a decade of that "evolution" and they are faced with a dozen functions that all have similar but increasingly long names and do very similar things with subtle but likely important differences. (I guess a culture of "the longest function name is probably the newest and the one you want" will emerge eventually.) Personally, I like when a library's API represents the best way the author knows to tackle a given problem today without also containing an accumulated pile of how they thought the problem should have been tackled years ago before they knew better. If I want the old solutions, that's what versioning is for. I'll use the old version.

christophilus 1y ago
Agreed. Create a new library if there’s truly a better way. That does seem to be what happens in Clojure from what I’ve seen.
eviks 1y ago
> If I want the old solutions, that's what versioning is for. I'll use the old version. And you'll miss all the stuff you do not want the old solution for. And all the old bugs > faced with a dozen functions that all have similar but increasingly long names and do very similar things with subtle but likely important differences. Unless all the old versions are marked add old/deprecated and can be hidden from your view. Then you only care about the old stuff if you used it before and don't want to change
mwcampbell 1y ago
It's no wonder that newcomers to Win32 find it intimidating.
- munificent 1y ago
  And C++ for that matter.

0xDEAFBEAD 1y ago

>For example, over its lifetime the Clojure community has shifted from accepting argument lists and named parameters in their functions to accepting a single hashmap. This is because the single hashmap is easier to grow over time. This seems a little nuts, to be honest. It feels like you're just pushing failures from easy-to-diagnose issues with the function signature, to hard-to-diagnose issues with the function body. Basically the function body now has to support any combination of hash parameters that the function has ever taken over its entire history -- Is this information documented? Do you have test coverage for every possible parameter combo?

jiehong 1y ago
I think it was meant from old style functions to new style, but not changing a given function’s signature this way.
MarkMarine 1y ago
no, you pull out the things you need from the map in the function body and move forward. I recommend either reading up on how this works in Clojure or just trying it, it's pretty simple. https://clojure.org/guides/destructuring#_associative_destructuring https://clojure.org/guides/destructuring#_associative_destru... Some extra reading if you're curious: https://softwareengineering.stackexchange.com/questions/272302/use-map-instead-of-class-to-represent-data-rich-hickey https://softwareengineering.stackexchange.com/questions/2723...
upghost 1y ago
It is nuts, especially in ClojureScript. "Am I missing a key, is the value in the hashmap nil, or was there an upstream error or error in this function that is presenting as nil?"
potetm 1y ago
I'm sympathetic to this idea, but in practice it's very manageable. Function signatures destructure exactly the data that they need, so it's easy to tell what's required and what's optional. Of course, normal rules apply like, "Don't pollute your program with a proliferation of booleans."

asalahli 1y ago

> I selected the following libraries off the top of my head with three criteria: all have more than 500 stars and are in active use. This sentence bothered me way more that it should've, for some reason.

potetm 1y ago
Ah! You caught me in an editing discontinuity.

boxed 1y ago

> I told Martin as much, and he agreed without hesitation that we needed to find a solution that didn't break current users' code. This is not a normal interaction amongst software engineers—a breed infamous for their long, drawn out debates on the most minute of details. However, this is absolutely expected in the Clojure community. Well that's just slander as far as I'm concerned. Of course we other non-clojure programmers believe in backwards compatibility. What a crazy thing to suggest that we don't.

potetm 1y ago
Maybe I didn't do a good enough job demonstrating how common it is for backwards compatibility to be broken. You're right that many devs value stability—not just clojure devs. But there are also many communities where breaking stuff is normal. This is addressing the latter, obviously.

lelanthran 1y ago

> I told Martin as much, and he agreed without hesitation that we needed to find a solution that didn't break current users' code. This is not a normal interaction amongst software engineers I find this to be extremely "it depends": this is a normal interaction amongst software engineers, if you have mature engineers. It's only not normal in those ecosystems (Everyone knows which ones those are) which appear to have not had adults in the rooms during the design phase. If you've only been developing for the last decade or so, you may think it's normal that stuff breaks all the time when software is upgraded. If you've been developing since the 90s you'd know that "upgrades brings breakage" is a new phenomenon, and the field (prior to 2014 or thereabouts) is filled with engineering compromises made purely to avoid breakage. It's why, if I have an application from 10 years ago in React, I won't even try to build it again, but if I have an application from 1995 in C, it'll build just fine, dependencies included[1] (with pages of warnings, of course). [1] C dependency graphs are small and shallow, because of the high friction in adding third-party libraries.

wereHamster 1y ago
To be fair, React itself has been exceptionally stable compared to the rest of the JavaScript / Node.js ecosystem. It's the other packages that are causing build failures, not React. Yes, React did deprecate and eventually remove some features, and those were real breaking changes. But it was at a far lower pace than every other package out there.
potetm 1y ago
fair

JackSlateur 1y ago

One great way to have stability is to rebase old code against new code Say, you have the first function, with a specific signature and it does its stuff Then later, you improve the stuff and the signature changes with a breaking change Do not do that Instead, create a new function (with a new signature) and push in it the whole code And rewrite the old function to use your new function This way, you keep one "production code": the new function. And you keep one interface-to-legacy code: the old function (which is nothing but a compatible gateway to the new function, and can be easily forgotten) Old users have no breaking, new users have features, you keep a single code and are only burdened with a small compatible layer

benrutter 1y ago

Caveat that I only have a tiny amount of experience with Clojure and none at all with Scala, so this isn't coming from a place of language knowledge in those fields. I'm not convinced though that the Clojure graph represents something I'd view positively. Notably, the Scala codebase gets smaller at one point, which looks fantastic to me. Nobody want the world changing under there feet every five seconds, but if code just accumulates without refactors, the end product often becomes not only unusable, but also difficult to replace. Personally, I'd much prefer more frequent refactors in a changing codebase (vs code addition) but with a strict adherance to semvar, that way, I can stick on v3 or whatever if I'm worried about v4 breaking things for me, but the project itself doesn't need to worry about stagnating, or being stuck with design decisions that aren't relevant anymore. I'm always happy when I see a library like pyarrow that has high version numbers, because I take it as a sign that they're most likely actually following semvar, as opposed to libraries that stay on v0 for 10+ years.

andai 1y ago

When I asked ChatGPT for help with Zig during a game jam, it gave me a bunch of code that was no longer valid. It used to be, but the compiler changed. I understand it's an extreme example — Zig is both niche and pre-1.0 — but it was the first thing that came to mind as a counterexample to, an API that never changes. It's not just an LLM thing, when I looked up tutorials and docs, most of them were also using code that didn't work anymore. And the library I needed only worked with a specific version, so I had to upgrade.. but not too far! Boring, "painful" languages, by contrast, were quite productive for game jams. Except the time when adding a member to a class broke the Emscripten build on the last day, and it took me the entire day to track it down (because why on earth would it be that!)

globnomulous 1y ago

This is really surprising. One of the first things I learned when I started shipping APIs and software packages is that the behavior you expose and the interface you provide for it have to be written in stone. The alternative is to break code and other packages that depend on it. Your package's changes are always somebody else's bugs. Compile-time errors and static analysis provide helpful guarantees and reduce suffering, but that doesn't change the fact that when you introduce changes you're still throwing Legos on the floor of someone's bedroom while they sleep. Major-version revisions by definition allow for breaking changes, but a breaking change needs strong justification: either you know nobody or few users are using what you've changed, or there's broad consensus that there's a bug (but one that didn't need to be fixed with a minor-version update, so it's probably a design problem, not a code bug), or the people using it broadly agree on the need for or benefit of the change.

kazinator 1y ago

One Happy Fellow somehow never encountered silently breaking dependencies in static languages.

kazinator 1y ago

Those strata graphs don't prove anything about stability, because a small number of lines of code (that don't make any difference to the graph) can wreck stability. Whereas a complete rewrite of something quite large can be utterly backwards compatible (bug for bug, even) and not break anyone. Too much horizontal striping in this kind of graph can be bad news: the project isn't improving its old code. That could be because the code is perfect and doesn't need anything, or it could be that the maintainers are not confident enough to touch it.