Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stability by Design

potetm.com

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Stability by Design

#11

Post by potetm »

alexjurkiewicz wrote: post #10

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.)

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.

Re: Stability by Design

#12

Post by RandomWorker »

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.

Re: Stability by Design

#13

Post by ashishb »

phoronixrly wrote: post #9
ashishb wrote: post #7

Earlier quoted context omitted.

> 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

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%…

> 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.

Re: Stability by Design

#14

Post by raspasov »

Animats wrote: post #3

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, o…

Sorry to hear that.

Is it fair to assume that every individual library/API can somewhat easily create a brand-new-world with every release (because it won't compile until the types are "re-aligned") yet they don't bother to check if the new release works with any other library/API?

I think the problem is partially cultural with a specific ecosystem but also fundamental. It takes a lot of type craft, care and creativity to design future-proof function/method signatures that are "open" to extension without breakage.

Re: Stability by Design

#15

Post by munificent »

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.

Re: Stability by Design

#16

Post by christophilus »

munificent wrote: post #15

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 differen…

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.

Re: Stability by Design

#17

Post by dyarosla »

ashishb wrote: post #13
phoronixrly wrote: post #9

Earlier quoted context omitted.

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%…

> 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.

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

Re: Stability by Design

#18

Post by Animats »

raspasov wrote: post #14
Animats wrote: post #3

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, o…

Sorry to hear that. Is it fair to assume that every individual library/API can somewhat easily create a brand-new-world with every release (because it won't compile until the types are "re-aligned") yet they don't bother to check if the new release works with any other library/API? I think the problem is partially cultural with a specific ecosystem but also fundamental. It takes a lot of type craft, care and creativi…

There are multiple combos. Egui can run on top of Wgpu or the simpler Eframe. Wgpu can be used with various 2D UIs on top. Winit is used by many non-3D programs. Getting all the combos right is tough.

Re: Stability by Design

#19

Post by 0xDEAFBEAD »

>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?

Re: Stability by Design

#20

Post by simultsop »

ashishb wrote: post #7
simultsop wrote: post #2

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

> 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

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.

Post reply on HN