8 ms·
> so you can do things like partial library upgrades when there's breaking changes. Large migrations like python 2 to 3 wouldn't take O(10yr). That wouldn't qu
by ghusbands 4y ago
> so you can do things like partial library upgrades when there's breaking changes. Large migrations like python 2 to 3 wouldn't take O(10yr).
That wouldn't quite work, though, as Python 2 and 3 have mutually-incompatible ideas of what a sequence of bytes (string/binary) is; Unison solves the problem of references to code, but apparently not what happens when identically-typed data has different meaning between versions. At least, that's not answered in the video.
- kragen 4y agoi'm not sure what you mean by saying that python 2 string is mutually incompatible with python 3 bytes they just have different names in early versions of python 3 the type was castrated but that got fixed in more recent versions
- mjburgess 4y agoThe author neglects to address the semantic reason that dependencies conflict, and focuses only on the syntactical (ie., a conflict of names). We want to enforce that where, eg., `np.array` is used, universally it's a data structure with the same properties. It isnt particularly desirable to have many versions of it floating around. It's not clear, atm, whether this is a real solution to the dependency problem. It seems like it solves it by making it easier to isolate areas of a codebase where dependencies are frozen. This is already an option, and people don't do it because they want actual semantic consistency. Maybe if it were easier it would be done more often, but a priori, it's a straw man of the dependency problem.
- dmytrish 4y agoWhile this is definitely true in general, Unison can unlock many context-specific guarantees even for data: the types are strict and expressive and it seems to have referential transparency.