I think what's really at stake is that code and data are a sort of inventory: they are not what you are selling, but they get turned into what you are selling. Inventory always has a carrying cost, and generally people underestimate that because they are only looking at the direct cost of storage, not how the presence of the inventory itself gets in the way, makes getting to other things harder, makes bottlenecks harder to see.

And that's where you see that debt is a wrong metaphor, because debt has the particular property that you can pay all of it off and that would be a good thing. By contrast inventory is a good thing in the right place: It means that if one thing stops working, the system can still continue for a while. Really operating with zero inventory everywhere is possible, and it's not done because it would drive you out of business. Similarly, deleting all of your code is not accessible in the way that getting rid of all of your debts is.

Designing an API to have a separate messaging later from its business layer from its data management layer from its data fetching layer is a technical debt; the fact that any change in the system now needs to be distributed across 10 different places in the code base is your interest payment. I would argue that you would like to derive all of these from some shared source of truth to remove those interest payments, and when you do, I no longer think that it's a bad thing for you to have a homebrew HTTP framework that has those separations in its internal functions.

It looks like you try to keep it so that the runtime type object itself has the correct TypeScript type? That is, I would expect that under the hood you either have `types.number = 0`, `types.string = ''`, and so on and then you just use `typeof runtimeTypeObject` to derive this, or something more sinister like `types.number = ('number' as any) as number`. Either way that's fairly clever and I like it. I probably won't do it that way in `tasso` because one of my abstract points of power is that `tasso` should be able to validate that a given type object is a valid `tasso` schema, so there should be a metaschema. But it is really nice to have this thing saying just `typeof runtimeTypeObject` and not `ValueOfSingleType` to derive, from the schema's type, the instances' type.

I may steal one thing for `tasso` from this library, and that is the way your `constant()` works without specifying type metadata; I was under the impression that even with the `` TypeScript would still say "well `const x = constant('abc')` doesn't say anything else about `'abc'` so I am going to infer that it is a `string` and then string does extend string so `x` has type `string`," much like it does when you just write `const x = 'abc'`. I didn't realize that you can "hint" that you want the more generic type for the thing. In tasso this manifests when you are writing self-recursive schemas, like

    // the following line is a sort of hack
    const refs = tasso.refs<'cell' | 'list'>();
    // but then we can write stuff like this
    const schema = {
      cell: tasso.number,
      list: tasso.maybe(tasso.object({
        head: refs.cell,
        rest: refs.list
      }))
    };

[1]: https://github.com/crdrost/tasso

I have read the source; indeed reading the source of redux-thunk was necessary for me to conclude it was pointless. I like everyone else thought that it was doing something more than `go = fn => fn()` does.

The code that I wrote you is logic which needs access to `dispatch` and `getState` when it runs, but it is not bound to specific references of `dispatch` and `getState`. It does not use your hack of importing a store from a global location, so it does not have problems with (A) or (B).

You cannot avoid grabbing that reference to props.dispatch either way. The crux of the argument that redux-thunk is just syntactic sugar, is that dispatch is already in scope whenever it is used and can be passed as an argument or a closure.

I agree somewhat with refactoring async logic into its own component when one wants to reuse it and make it portable. The question is just, should you pass `dispatch` and/or `getState` as an argument to that function? Or should you curry that dependency to a subfunction and pass that function as an argument to `dispatch`?

I opine that the latter is objectively worse than the former. You have `dispatch`: hand it directly to the function, let people know that this function is not an actual action but an asynchronous process. We are talking about a syntactic sugar, in other words, that doesn't make anything sweeter.

I'm actually refreshed to be reminded that the Redux store is a closure, I had forgotten since I first read the Redux code several months ago. So then it's even easier; one never has to bind anything.

I will try to ping you on Discord later tonight; there is a specific reason that I am preferring asynchronous messaging systems at the moment.

For some references you could find e.g. http://wiki.c2.com/?ModelViewControllerHistory

> The dependency (addDependent:, removeDependent:, etc.) and change broadcast mechanisms (self changed and variations) made their first appearance in support of MVC (and in fact were rarely used outside of MVC). View classes were expected to register themselves as dependents of their models and respond to change messages, either by entirely redisplaying the model or perhaps by doing a more intelligent selective redisplay.

or (PDF Warning) http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf :

> Because only the model can track all changes to its state, the model must have some communication link to the view. To fill this need, a global mechanism in Object is provided to keep track of dependencies such as those between a model and its view. This mechanism uses an IdentityDictionary called DependentFields (a class variable of Object) which simply records all existing dependencies. The keys in this dictionary are all the objects that have registered dependencies; the value associated with each key is a list of the objects which depend upon the key. In addition to this general mechanism, the class Model provides a more efficient mechanism for managing dependents. When you create new classes that are intended to function as active models in an MVC triad, you should make them subclasses of Model. Models in this hierarchy retain their dependents in an instance variable (dependents) which holds either nil, a single dependent object, or an instance of DependentsCollection. Views rely on these dependence mechanisms to notify them of changes in the model. When a new view is given its model, it registers itself as a dependent of that model. When the view is released, it removes itself as a dependent.

Like, I'm not getting this out of nowhere; at one point I inspected the code in the Model object and that's how it works...

Multiplexing two models together to my mind just constructs a new model whose values are tuples of the existing models and which subscribes to both of those models in order to notify its own subscribers whenever either side of those tuples change. If you do this, you can have a bunch of local stores and still say "this component's value changes whenever either of those values change." The key is that "normal" models accept a set(value) message to set their value to something, and you might play around with "dict" models which accept insert(key, value), deleteAt(key) messages, but a multiplex model would not be easily able to abstract over all the different possible messages to send upstream and so the easiest approach is just to make multiplexes nonresponsive -- you can't "dispatch" to them, in Redux terms.

redux-thunk is nice in that it helps keep people from making the mistake of sending otherwise-no-op actions to the store which then, inside a reducer as side-effects, do a bunch of async I/O to compute events that eventually make it back to the store. I would broadly agree with that.

My basic beef with redux-thunk is that it's unnecessary and complicates what would otherwise be a type signature that has no reference to I/O, which I regard as a good thing. Developers ought to know that, to quote one of the Austin Powers movies, "you had the mojo all along." It's a sort of talisman that you are using for purely psychological reasons to reassure developers and to coax them to doing updates outside of the reducers, but it's OK because "it's in `dispatch()` so it must be a Redux thing so we'll make it work." But such a talisman is unnecessary.

Like, here's what you've got (in the readme):

    function makeASandwichWithSecretSauce(forPerson) {
      return function (dispatch) {
        return fetchSecretSauce().then(
          sauce => dispatch(makeASandwich(forPerson, sauce)),
          error => dispatch(apologize('The Sandwich Shop', forPerson, error))
        );
      };
    }
    store.dispatch(
      makeASandwichWithSecretSauce('Me')
    );

    function makeASandwichWithSecretSauce(forPerson, dispatch) {
      return fetchSecretSauce().then(
        sauce => dispatch(makeASandwich(forPerson, sauce)),
        error => dispatch(apologize('The Sandwich Shop', forPerson, error))
      );
    }
    makeASandwichWithSecretSauce('Me', msg => store.dispatch(msg));

    store.dispatch = Store.prototype.dispatch.bind(store);
    store.getState = Store.prototype.getState.bind(store);

This is not to say that data modeling is not important, or that your model won’t have a similar shape as your data model; it will. But that is not the original point.

In MVC as it was originally understood, a model is a list of subscribers. You can add yourself to that list, you can remove yourself from that list, and whenever a “value” changes, if you are on that list, you get a notification that the value has changed. You have a couple of different designs of these, depending on whether you want to send a current-state message as a notification on subscription, or just give everybody read access to the current state. The latter commits you to initializing your models in ways that indicate the absence or staleness of data (someone loads your app, you need to send out a network request to get a new thing) but also allows you to use variable scope to augment how much multiplexing and state tracking you need.

Models vary from data models in having view-relevant data. So for example you switch from the type

    const urlList = new Model([])

    type Fetching = { state: "init" }
      | { state: "loaded", data: x },
      | { state: "fetching", staleData: x },
      | { state: "fetch error", staleData: null | x }
    const urlList = new Model>({
      state: "init"
    })

If this begins to feel a lot like React and Redux, that is because there is a shared lineage there. React originally made its splash as “the V in MVC” but its setState/state system, while it doesn't contain a subscriber list, effectively does something equivalent by insisting on destroying anything that has the old values and then superficially identifying things which appeared to remain the same from moment to moment, with the basic model then being a “subscription tree.”

Redux of course takes this from being a tree to being something more generic by making the store global... I think that models should not be app-global the way that Redux likes (it does not want to solve the problem of multiplexing models, which is understandable but it turns out to be a much simpler problem than you'd think) and that the pattern of reducers is more verbose than one generally needs, but I love the time travel browser features that Redux gives me. Somehow Redux has encouraged abominations like redux-thunk which complect separate concerns into the same dispatch function unnecessarily. But the fundamental workings involve that same basic structure: a subscriber list.

Here's the problem setup: So we want to share a secret byte (178) among Alice, Bob, and Carol, so that we need all 3 of them to contribute to it. Three points defines a parabola so we choose two more random bytes: [38, 68], our polynomial is y = 178 + 38x + 68x². We then give Alice the point (1, 284), Bob the point (2, 526), and Carol the point (3, 904).

Now supposing that we have compromised both Bob and Carol's points we know that we have the two equations,

   9a + 3b + c = 904
   4a + 2b + c = 526

   6a - c = 230

   c = 6a - 230.

Here's how modular arithmetic solves this: It turns out that modulo a prime, all fractions are also whole numbers. That is, if I am working modulo the prime 13, I will find that I can divide 7/5 to find 4. Remember what division means, it inverts multiplication: I can find that 5 × 4 = 20 and then that 20 = 13 + 7, so they are at the same place "on the clock". In fact it suffices to just find 1/5 and multiply by 7, so you can find that 1/5 is 8 in the mod-13 ring, 8 × 5 = 40 = 39 + 1. You can also find that 1/6 is 11, so 6 × 11 = 66 = 65 + 1.

The proof that this must be the case is that if you take

    [1, 2, ..., p-1].map(x => (x * n) % p)

That's kind of a brute force argument so you may want to also mention that there are two efficient ways to find these, one is called the "Extended Euclidean algorithm" (do a GCD computation to find that the GCD=1, but you can take the dividends that you discarded and cleverly assemble them to recover the constants from Bezout's identity, which in this case gives you the modular inverse) and the other is called "Fermat's little theorem" (since a^(p-1) % p == 1 for prime p, raise something to the p-2 power. Using exponentiation by squaring you only need ~log p multiplications that each take no more than ~log p time.

MPL, for folks who aren't aware, is a successor to the CDDL seen in Solaris etc. and is a per-file copyleft, thus having a nicer legal structure while getting the same rough benefits of GPL or at least LGPL. The idea is “any modifications to this file must also be open-sourced under MPL, but you can package this file with proprietary other files that are not MPL and integrate them into a larger proprietary thing as long as your modifications to this file alone are open-sourced.” The goal is to protect weakly from Microsoft-esque “embrace, extend, extinguish” as GPL does but enable commercial integration the way BSD does.

In practice nobody seems to be all that pissed at Mozilla because of their license; the MPLv2 added GPL compatibility so the GPLers are mostly able to use MPL software and it gives a nod towards the stronger copyleft they like; commercial applications which just use the software as a library don't mind.

P vs NP is the same: if solutions to a problem are easy to check, is there always some better way to analyze the mechanics of the checker to make those solutions easy to find, so that we aren't stuck with brute-forcing it? Whether the answer goes one way or the other, the point is that solving the problem would have to provide some insight to the effect of "here is a periodic table of elements for all of the 'easy' algorithms -- and here are the properties of all the 'molecules' made by combining those building blocks." And only once someone advances our understanding with those cutting insights can we say "yes we can always reach into the verification mechanism to understand it well enough to build a better-than-brute-force algorithm" or "no, here is such a thing that algorithms cannot do, it's not just that I am not smart enough to find a way for them to do this -- they are fundamentally incapable of doing it faster."

What I mean is, people don't find an experiment about nanostructures that doesn't work and start going "hey I think I have disproved quantum mechanics!". Even when the OPERA faster-than-light neutrino debacle was going on, physicists were largely saying "We are pretty sure that there is some mistake in either the model or the experiment such that these neutrinos are not moving faster than the speed of light." In fact the objection goes a little further than that: according to Newtonian mechanics, geocentrism is perfectly admissible. There is absolutely nothing wrong with constructing a geocentric frame of reference and doing Fourier expansions of the motions of planetary bodies. No experiment has disproven it because it's just a mathematical choice of accelerated reference frame to analyze the motion of the planets. According to unmodified Popper, each of the first two should have led to a rejection of the scientific principles which led to them, while the latter would mean that geocentrism and heliocentrism are pseudoscience and there was never any scientific switch between them -- all of that sounds wrong.

So Kuhn introduced the idea that there is a separation of science into two parts, "theory" and "model". A scientific theory like quantum mechanics or heliocentrism is a platform for building models and deciding what questions are worth asking and how one goes about asking them. They are a "platform for computation" in a sense, and most of them are "Turing complete," there is nothing that they can't model somehow. So classical mechanics turns out to be able to do something with quantum mechanics if we use something like Bohm's pilot wave theory. And Couder and Fort's droplets on a vibrating oil bath show an experimental realization of particles which nevertheless diffract in a classically explicable way, underscoring this point. Kuhn said that theories need to be abandoned during some sort of "scientific revolution" but was very hazy on how exactly that happened. But he was a huge fan of Popper and wanted to say that Popper was fundamentally right about the way that we model systems, discarding models immediately when they do not fit experiment and coming up with better models.

Kuhn picked up a lot of flak because one of the things Popper's works were trying to do was to discredit things like psychiatry and astrology as being "pseudoscience" rather than real science because they could explain everything and thus never stuck their neck out -- thus Kuhn's work seemed to need some extra structure about the manner that we actually conduct such a revolution, otherwise astrology might not be a pseudoscience but an "eventual science" or so: if theories are just some sort of aesthetic agreement on behalf of the existing scientists then what stops us all from deciding that we rather like reading our weekly horoscopes?

This challenge was to my mind best resolved by the "research programmes" idea of Imre Lakatos. He philosophizes that theory choice -- fundamental progress in science -- is best seen as motivated by lazy grad students. Like, laziness is a virtue on this account: grad students have to make a contribution to the published literature that excites their peers and makes a name for themselves, and they do not have much time to do it.

So, why do people use the Copenhagen interpretation for everything if very few people philosophically accept its ontology? Because it is mathematically equivalent to all of the other interpretations but is astonishingly easy to use, just "yeah the wavefunction collapsed so now this is reality, I don't strictly have to care about that collapse happening across spacetime instantaneously because that's not observable anyways, so here are my experimental results." Lazy grad students will choose that ten times out of ten over coming up with the correct pilot-wave mechanics and simulating it. Why did heliocentrism win if Newtonian mechanics says that geocentrism is 100% experimentally valid? Because the heliocentric models are easier to build and reason about with straight mechanics, and lazy grad students will take Newton's law of gravity any day over those epicycles.

You can in some respects view this as Occam's razor but Occam's razor is painfully ill-specified. A better view of it is that it's a survival-of-the-fittest, a theory of scientific evolution. So, theories are "genes" which make it easier or harder to publish interesting discoveries that are modeled with those theories in scientific journals. Based on others reading those papers and extending those results in various ways, theories "reproduce" and the ones that reproduce most effectively are the ones that best adapt to their (ever-changing) environment.

The `string` type here comes from a mapping that the router is using. That is, the router ultimately type-evaluates a `ValueOfType<{type: 'guid'}>` to `string`. But because it's a runtime object, the router can also, at runtime, validate that URL param, "did they actually give me a UUID?" -- and sanitize it, e.g. "convert all UUIDs to lowercase."

(In fact the benefit of having this TypeScript type at runtime is even bigger than that. With Express.js, the router can rewrite the route param so that the route doesn't even match if you don't provide a UUID, which matters because there is often a lot of accidental ambiguity in HTTP APIs -- but here you can embed the UUID regex into Express paths. The router can then also do some other trickery like confirm at initial load time that all params in URLs match params in this `params` dict, and it can convert all of its routes to OpenAPI/Swagger docs so that you can define another route which just gives you your OpenAPI JSON. Literally in what I have written the above would be a type error because the `Router` class would complain that `params` has the wrong type because the `objectguid` descriptor needs a key called `doc` which is a string for parameter documentation for OpenAPI.)

This is great work, and I think you're burying one lede, which is that it looks like you've embedded a declarative permissions model in this thing, and I built one of those and the time saved can be huge when authorization is handled at the model level rather than everywhere in the business logic.

I can definitely confirm for others reading this that it indeed has been something like 10 years in the making; I was working with a prototype of it 8-9 years ago and found those data models so nice that I actually reimplemented the core idea in a repository on GitHub, though it didn't really go anywhere except for my own web site. I have also been able to reimplement it in TypeScript more recently, so that there is a non-Turing-complete subset of algebraic data types (though maybe I'll be able to add a fixpoint operator, who knows) as runtime objects with highly specific TypeScript types that are inferred from the functions you use to construct them. So then a parametric TypeScript construct,

    ValueOfType 

    myHTTPRouter.get('/objects/by-id/:objectguid', {
      params: {
        objectguid: {
          type: 'guid'
        }
      },
      async handler(params) {
        // inside of here, params has type {objectguid: string},
        // and VSCode knows this, because params is ValueOfType where
        // the schema is specified in the `params` key above.
        return response.json({success: true})
      }
    })

The problem is that that still comes out to ~250 printed pages, so one book, so that's an investment of 2 months to create no obvious business value, and I think if I could take that I would actually be part of that 1%. But the point of my post was just to give an example of "we can make smaller architectural decisions all the time to clean out crap and make our lives easier," and nobody is going to look the ~2 hours you spend cleaning as wasted time since it causes them to get a more-correct product sooner.

Another example: I remember at IntegriShield we had an API written in PHP, and one of my favorite little things I had written was a data model. ORMs are not hard to find in PHP but because the data model we were using was JSON we could express inside of that data model a declarative security model for the data and it would get written into the SQL queries: you say "Give me all of the groups!" and it rewrites that to, "I will give you all of the groups that you can see." The logic for the group-editor does not need to explicitly handle the checks for "can this person really edit that group?" because the data model will check it for them, "UPDATE groups SET values WHERE id = (the group you are editing) AND (user can edit the group)."

Adding the first security type was maybe half a day's work threading stuff through the SQL generator? Adding subsequent new checks took more time but was incremental so each of them might have delayed their projects 1-2 hours. But the net result must have saved a tremendous amount of programming. I have always had that latitude to create structure, if I want it.

That said, I have been pretty lucky with the places I've been privileged to work, so maybe I'm already part of the 1% and this is not representative.