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

Spec-ulation – Rich Hickey [video]

youtube.com

Post reply on HN
Print view View original

41–50 of 74 posts

Re: Spec-ulation – Rich Hickey [video]

#41

Post by jjnoakes »

sheepmullet wrote: post #37
jjnoakes wrote: post #33

Earlier quoted context omitted.

Because if you start relying on something new or fixed in x.2.z of your dependency you want to make sure anyone using your code isn't using x.1.y.

And doesn't automatic dependency resolution make this a non-issue for your consumer? Edit: I.e. If you declare your own dependencies then tooling should ensure anyone who uses your code uses the same dependencies. It doesn't work this way in Java world due to technical limitations, but it can in JS world

Consumers may want to use a different version.

Perhaps they want a newer one (bug fix, security fix).

Perhaps they want an older one (since another dependency was tested against an older version of the dep in question).

Semver gives you a way to decide what ranges of versions should be safe to move between in order to satisfy all of those occasionally conflicting requirements.

Re: Spec-ulation – Rich Hickey [video]

#42

Post by sheepmullet »

jjnoakes wrote: post #41
sheepmullet wrote: post #37

Earlier quoted context omitted.

And doesn't automatic dependency resolution make this a non-issue for your consumer? Edit: I.e. If you declare your own dependencies then tooling should ensure anyone who uses your code uses the same dependencies. It doesn't work this way in Java world due to technical limitations, but it can in JS world

Consumers may want to use a different version. Perhaps they want a newer one (bug fix, security fix). Perhaps they want an older one (since another dependency was tested against an older version of the dep in question). Semver gives you a way to decide what ranges of versions should be safe to move between in order to satisfy all of those occasionally conflicting requirements.

Explicitly limiting your consumers to a specific version of another library is a breaking change. You have introduced a very specific dependency and are requiring the consumer to honour it.

By semvar rules you should be updating the major version?

Re: Spec-ulation – Rich Hickey [video]

#43

Post by DEADB17 »

DEADB17 wrote: post #32
taeric wrote: post #27

Earlier quoted context omitted.

No. Because I don't have a way to keep the old and the new. That is, the point is that you didn't change my use of the old. You just changed what I actually use. It may work. It may not. This is especially egregious when I had to up versions to get some new functions, and old versions just happen to have changed.

I don't know about maven, but in NPM you can keep both. If you take away the limits of a particular implementation, I think that semantic versioning is a useful convention for the producer of an artifact to convey intent to the consumers.

Sorry @taeric, I can't reply to your post directly.

I do think that the intent of the producer is being communicated (unsafe to upgrade, safe to upgrade with new features, safe + automatic improvements).

I'm not disagreeing that "spec" adding more metadata to have better granularity and potentially reducing the amount of manual work is a good thing. But in the absence of it, "semantic versioning" is an improvement over safe and unsafe versions being indistinguishable.

Re: Spec-ulation – Rich Hickey [video]

#44

Post by taeric »

DEADB17 wrote: post #43
DEADB17 wrote: post #32

Earlier quoted context omitted.

I don't know about maven, but in NPM you can keep both. If you take away the limits of a particular implementation, I think that semantic versioning is a useful convention for the producer of an artifact to convey intent to the consumers.

Sorry @taeric, I can't reply to your post directly. I do think that the intent of the producer is being communicated (unsafe to upgrade, safe to upgrade with new features, safe + automatic improvements). I'm not disagreeing that "spec" adding more metadata to have better granularity and potentially reducing the amount of manual work is a good thing. But in the absence of it, "semantic versioning" is an improvement ov…

No worries. In the future, you can almost always get a reply button by clicking directly on a post. (Click on the "time since post" to get to the direct link.)

I think I see the point. Yes, he is using hyperbole. However, I have found it is more accurate than not. In particular, the point that many projects feel a lot more cavalier about doing breaking changes.

Re: Spec-ulation – Rich Hickey [video]

#45

Post by jjnoakes »

sheepmullet wrote: post #42
jjnoakes wrote: post #41

Earlier quoted context omitted.

Consumers may want to use a different version. Perhaps they want a newer one (bug fix, security fix). Perhaps they want an older one (since another dependency was tested against an older version of the dep in question). Semver gives you a way to decide what ranges of versions should be safe to move between in order to satisfy all of those occasionally conflicting requirements.

Explicitly limiting your consumers to a specific version of another library is a breaking change. You have introduced a very specific dependency and are requiring the consumer to honour it. By semvar rules you should be updating the major version?

What?

If my library requires X version 1.2 or higher, how is it a breaking change if I don't work with version 2.0 or 1.0 or anything except 1.2 through 1.99999?

That's the whole point of software versioning, no matter what you call it (renaming things, semver, git hashes, anything). At some point you require something of someone else, and you can only use the versions of that other library which provide what you require (or more). Semver is just a way to lock those requirements into a machine-readable number scheme.

Re: Spec-ulation – Rich Hickey [video]

#46

Post by robto »

_halgari wrote: post #8
NightMKoder wrote: post #7

Earlier quoted context omitted.

One of the things Rich talks about in this talk is semantic versioning is fundamentally broken. In fact any versioning scheme that allows removal is broken. In some sense this model encourages Rich's ideas better - since you can't version directly, you either make a new library or maintain backwards compatibility. Of course the current 'go get' model has a lot of downsides, e.g. Non deterministic builds. I still thin…

Absolutely, I think the "perfect world" would be adopting some of the ideas Rich proposes but adding (git url + sha) as the dependency management system. Of course for that to work well you'd also need to protect yourself from people deleting their git hub repos, or rewriting git history.

Which is a great use case for something like ipfs, I think.

Re: Spec-ulation – Rich Hickey [video]

#47

Post by joe-user »

j-pb wrote: post #10

> Logic systems don't have "And nothing else will ever be true!". Uuh. Closed world assumption? Everything that is not true is false. Most logic systems do have this. Prologs (not a logic system I know) cut operator even turns this statement into an operation. I feel like Rich really gets it wrong this time. His request to support all the abominations that you have ever written and keep them compatible with recent ch…

> His request to support all the abominations that you have ever written and keep them compatible with recent changes, might work if you have people pay for using your library and a company behind it. But doesn't fly if you maintain these things out of goodwill in your anyhow limited spare time.

It might actually be less effort to follow his method. You may need to create a new namespace or create a new function, but then you don't need to put out breaking change notices, handle user issues due to breaking changes, etc.

> "Man browsers are so reliable and bug free and it's great that the new standards like flexbox get widespread adoption quickly, but I just wish the website I made for my dog in 1992 was supported better." -no one ever.

It's not about better support for your 1992 website, it's about it still being accessible at all. Perhaps you've never had to deal with a file in a legacy format (ahem, Word) that had value to you, but was unrecognized in newer versions of software, but I can assure you that it's thoroughly frustrating.

> Also even though I'm a fulltime Clojure dev, I would take Elms semantic versioning that is guaranteed through static type analysis anytime over spec's "we probably grew it in a consistent way" handwaving.

An Elm function `foo :: int -> int` that used to increment and now acts as the identity function is merely statically-typed "we probably grew it in a consistent way" hand-waving, which may be worse than the alternative given the amount of trust people put into types.

Re: Spec-ulation – Rich Hickey [video]

#48

Post by pron »

j-pb wrote: post #10

> Logic systems don't have "And nothing else will ever be true!". Uuh. Closed world assumption? Everything that is not true is false. Most logic systems do have this. Prologs (not a logic system I know) cut operator even turns this statement into an operation. I feel like Rich really gets it wrong this time. His request to support all the abominations that you have ever written and keep them compatible with recent ch…

> But doesn't fly if you maintain these things out of goodwill in your anyhow limited spare time.

What percentage of the total software produced and used fits that and should discussions of general good practices address this anomaly? Obviously, if you work outside the normal industry practices, then industry best-practices don't apply to you. I don't think you should take what he says too literally to mean that every line of code you should write must obey this and there are no exceptions.

> that nobody want to touch them with a ten foot pole.

If by nobody you mean almost everyone. Those happen to be the most successful software platforms in history, and most new software outside embedded (with the big exception of Windows technologies, maybe) uses at least one of those platforms to this day.

> One of the reasons why it takes so long for browser standards to be adopted is that they have to be integrated with all the cruft that is accumulating there for almost three decades now.

So what? Look, large software gets rewritten or replaced (i.e. people will use something else) every 20 years on average. If your tools and practices are not meant to be maintained for 20 years, then one of the following must be true 1. they are not meant for large, serious software, 2. you are not aware of the realities of software production and use, or 3. you are aware, but believe that, unlike many who tried before, you will actually succeed in changing them. Given the current reality of software, backward compatibility is just more important to more people than agility.

> Combinatorial complexity is not your friend.

Every additional requirement results in increased the complexity, and backward compatibility is just one more, one that seems necessary for really successful software (especially on the server side).

> "we probably grew it in a consistent way" handwaving.

Why do you think it's handwaving? The spec is the spec, and if you conform with the spec then that's exactly what you want.

Re: Spec-ulation – Rich Hickey [video]

#49

Post by Garlef »

asymmetric wrote: post #16
adwhit wrote: post #4

Earlier quoted context omitted.

Video is a high-bandwidth way of delivering information at a low bandwidth. But try watching tech videos at 1.5 speed, it makes them much more engaging. Also works for ponderous anime.

Got any examples of ponderous anime? Lain? Akira? GITS?

Dragonball. They sometimes charge up one attack over several episodes.

Re: Spec-ulation – Rich Hickey [video]

#50

Post by j-pb »

pron wrote: post #48
j-pb wrote: post #10

> Logic systems don't have "And nothing else will ever be true!". Uuh. Closed world assumption? Everything that is not true is false. Most logic systems do have this. Prologs (not a logic system I know) cut operator even turns this statement into an operation. I feel like Rich really gets it wrong this time. His request to support all the abominations that you have ever written and keep them compatible with recent ch…

> But doesn't fly if you maintain these things out of goodwill in your anyhow limited spare time. What percentage of the total software produced and used fits that and should discussions of general good practices address this anomaly? Obviously, if you work outside the normal industry practices, then industry best-practices don't apply to you. I don't think you should take what he says too literally to mean that ever…

When stating that nobody wants to touch browsers with a ten foot pole, I meant that nobody wants to contribute to browser development unless they are paid very very well.
Post reply on HN