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

41–50 of 67 posts

Re: Stability by Design

#41

Post by lelanthran »

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.

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

Re: Stability by Design

#42

Post by benrutter »

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.

Re: Stability by Design

#43

Post by yakshaving_jgt »

jiehong wrote: post #25
ashishb wrote: post #13

Earlier quoted context omitted.

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

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

Isn't it a shame that we're only allowed to have one or the other.

Re: Stability by Design

#44

Post by andai »

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

Re: Stability by Design

#45

Post by KronisLV »

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

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

Re: Stability by Design

#46

Post by upghost »

0xDEAFBEAD wrote: post #19

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

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

Re: Stability by Design

#47

Post by potetm »

0xDEAFBEAD wrote: post #19

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

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

Re: Stability by Design

#48

Post by potetm »

lelanthran wrote: post #38

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

fair

Re: Stability by Design

#49

Post by potetm »

RandomWorker wrote: post #12

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

love it!

Re: Stability by Design

#50

Post by potetm »

boxed wrote: post #33

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

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.
Post reply on HN