* Spec-ulation Keynote
** 101
   - spec is a tool to USE not rules to follow (it's optional to use
     features of spec)
   - spec is about committing to a specification (not changing
     drastically in the future). New modifications should not break
     things downstream.

** Deps
   Build tools often resolve dependency conflicts by just picking one
   version (which can easily break your dependency chain and your
   program). The program code doesn't contain the artifacts and
   artifacts don't contain each other (both just use dependency lists).

   Some dependencies are artifact deps that our program code never
   actually uses. There are also potentially many namespaces in an
   artifact that don't get used. Namespaces also aren't tracked in
   the artifact's dependency metadata.

   Some kind of tree shaking could prune out:
   - namespaces from deps that aren't used
   - deps of namespaces that aren't used

** SemVer
   Meant for a "sane" release and upgrade solution without having to
   roll out new versions of dependent packages.

   Violations to this model can happen when we need to upgrade our
   project code to reflect upgraded dependency code. Other problems can
   come when we're at the function level calling a :required function of
   an artifact. That artifact's functions don't refer to the artifact
   (and it's version), only the namespace is referenced!

** Why Use Deps?
   - we need 3rd party libs
   - maven handles dep conflicts
   - packages our program for other downstream consumers

   it only records the context though... :/

** Changes
   required changes:
   - fn -> args
   - ns -> var names
   - artifact -> ns names

   provided changes:
   - fn -> result of the call
   - ns -> vars
   - artifact -> namespaces

   good software changes by:
   - accretion (providing more features)
   - relaxation (need fewer inputs passed)
   - fixation (bug fixes)

   breaking changes happen by:
   - require more
   - provide less
   - unrelated stuff under same name

   Saying "change" is an inadequate description of the updates to our
   program. The update was either: growth or breakage.

    At the function level, spec can help us determine if our update was
    a breakage or normal growth (maybe even programmatically). Don't be
    a dummy and version your specs.

** Recognizing Collections
   Collections only change by adding or removing items. The adding is
   growth and removing is breakage.

   Our namespaces are collections of vars/fns. Artifacts are collections
   of namespaces/packages.

   Don't confuse the fn, ns, and artifact levels.

** SemVer Revisited
   "Sematic Versioning" == who cares (except when your system breaks)

   Major updates have a higher probability of screwing you because all 3
   levels can change and names of things at all 3 levels can randomly
   change too (fuck...). Making a major update is for any backwards
   incompatible changes but then you're introducing backwards
   incompatible change which break downstream consumers, so that's
   dumb.

   DON'T EVER CHANGE THE NAME OF YOUR STUFF!!!

   levels of badness when updating:
   adding < removing < mutating

   We could detect the changes by using spec to compare the old version
   of the library with the new version. Are there incompatibilities? New
   fns? New namespaces?

** Fixing Versioning
   We could keep function or namespace names versioned for when changes
   happen so that new things have versioned names. That's growth and
   therefore still compatible.

   If you want to get rid of a fn, pick a new namespace but keep the old
   one.

   When providing fewer namespaces we should use a new
   artifactId. Breakage can happen and since the artifact name has no
   relation to namespaces. How do consumers know about a breaking change
   if the artifact name is identical?

   Avoid breakage by turning it into accretion. The old and new can
   co-exist (e.g. Nix pkg manager).

** Maven... Broken? Nu-uh
   Maven central grows through accretion because people just add
   artifacts over time. It doesn't randomly delete or mutate artifacts
   (like our programs do).

** SemVer Round 3
   Sematic Versioning is broken and promotes software breakage! The
   minor versions are also pretty useless.

   Maybe it'd be better to have a timestamp in the artifactId so we can
   tell when something has major changes.

** Git?
   Everything is immutable, source code is what matters (not version),
   it does content-based addressing (SHA hashing). The SHA hashing makes
   it not human readable though :/

** Solutions
   This is a social problem. We need to name properly so downstream
   projects can use our code freely. If we don't know who will consume
   our projects then we don't know who will be broken by our breaking
   changes.

   Open specs are the key to growth. Specs are about what we can do, not
   what we can't do. Expect that your functions will get lots of
   unnecessary junk, just pull out the keys or whatever that you'll
   use.

   Even alpha versioned software should grow without breakage but it's
   less bad since breaking changes are expected.

** Impacts
   Breaking changes can cause changes to our runtime execution and
   testing can be broken by deps.

** Web Services
   We use versioning on our web APIs too (usually major
   versioning). Using accretion here too could prevent a ton of issues!

** Why's all this bad?
   - our deps have mutability problems because they update in place!
   - programs become fragile (a dep could break things at any point)
   - we get scared of adding deps (more surface area for breakage)

** What could it be like?
   - artifact names are meaningful forever
   - orthogonal deps testing by a machine
   - we can explore fine-grained deps
   - update our deps with impunity
   - compose with impunity

** Challenges?
   - we can't see some things (like outputs of functions)
   - spec compatibility should be aware of the context (e.g. :require vs
     :use)
   - repo, artifact, namespaces not first class
   - tooling is hard to change from status quo

** Opportunities
   - spec
   - flexible dep awareness (how brittle is the dep)
   - Explicit code -> artifact support
   - fine-grained deprecation method
   - testing based on fine-grained deps, great for generative testing
     (so we can test only our latest changes)

** Recap
   - grow your software
   - give birth to variation (don't break, accrete)
   - think of downstream consumers
   - move forward without burning bridges (breakage)
   - create a lib/service ecosystem of which we can all be proud