Ooooh Dette minner mistenkelig om en magefølelse jeg har: "når du lærer deg å strukturere kode skikkelig i clojure, klarer du å gjøre det i alle språk, fordi du ikke bruker støttehjul i clojure. Navnerom, navn, operasjoner og data er alt du trenger"

Føler at denotational design / skriv typer på data og typer på operasjoner mellom typer før du begynner å kode også er et plausibelt motargument. Men dette er kun noe jeg har sett i Elm-kode og Haskell-kode.

Det som jeg tror jeg savner litt er konkrete eksempler på “OMG hvis jeg ikke hadde typer her så ville alt gått til helvete”. Som regel så er reaksjonen min på det “shrug, ikke skriv koden sånn”.

Ramla over følgende kode hos oss:

export function registerForFilterChange(
  this: {
    _throttledFilterChangeCallback?: (payload?: { filter?: Filter }) => void;
  },
  callback: (filter?: Filter | Record<string, never>) => void,
  updateWhenInactive: boolean
) {
  this._throttledFilterChangeCallback = throttle(
    (payload?: { filter?: Filter }) => {
      if (shouldViewUpdate(this as ViewPlugin, updateWhenInactive)) {
        callback(payload ? payload.filter : {});
      }
    },
    THROTTLE_TIME,
    { leading: false }
  );

  [notifyFiltersChanged, setActivePerspective].forEach(action =>
    subscribeToAction<any>(action, () => this._throttledFilterChangeCallback!())
  );
}

private registerForFilterChange() {
    const throttledFilterChangeCallback = throttle(
      () => {
        this._dispatchTreeChanged();
      },
      THROTTLE_TIME,
      { leading: false }
    );

    subscribeToAction(notifyFiltersChanged, () =>
      throttledFilterChangeCallback!()
    );
    subscribeToAction(setActivePerspective, () =>
      throttledFilterChangeCallback!()
    );
  }

Dette kunne gjøres fordi ved a lese callsite så man at throttle dingsen aldri ble kalt med parametre, så alt av typer kunne bare fjernes.

"Du får ikke lov til å sykle med støttehjul før du viser at du kan sykle uten støttehjul," hehehe.

Mine barn har aldri syklet med støttehjul

Og grunnen til det er at du lærer deg fantastiske uvaner når du gjør akkurat det.

Men det er et godt poeng bak analogien: Hvis man lærer uten, trenger man dem aldri.

Løpesykkel er måten du bør lære å sykle på.

https://www.tradeinn.com/bikeinn/es/kokua-bicicleta-sin-pedales-likeabike-mountain-special/138751016/p?utm_source=google_products&utm_medium=merchant&id_producte=15761271&country=es&gclid=CjwKCAjwjOunBhB4EiwA94JWsMf_KtEWm6YMQWV0y_5xDbXuBGsAdkLB4asug6ksuFcUd_PNLocHKRoCoeMQAvD_BwE&gclsrc=aw.ds

Det med løpesykkel har jeg hørt fra flere! Det kommer vi til å kjøre også.

Hvis sterkt typede språk er som sykkel med støttehjul, er dynamisk typede språk er som sykkel uten støttehjul, hva er så løpesykkelen i denne analogien? Er det språk med såkalt "optional" eller "gradual" typing, som f.eks. TypeScript, Elixir og Mojo?

Med clojure.spec kan en kanskje også argumentere for at Clojure har "optional" eller "gradual" types.

Mojo er ganske interessant fordi det kan være sterkt typet og/eller dynamisk typet. Det har "https://docs.modular.com/mojo/programming-manual.html#strong-type-checkinghttps://docs.modular.com/mojo/programming-manual.html#strong-type-checkinghttps://docs.modular.com/mojo/programming-manual.html#strong-type-checking."

Her er råd jeg ga til en kollega: > Here is how I like to think about it: > 1. Even though I don’t care about performance, i believe that the render function of a react component should do as little as possible so that it can be as fast as possible. For this to happen, you need to do stuff outside of render and have tailor-made props for the component. > 2. Even though we don’t write tests, write the code as if it were possible to unit test it. If you have a bunch of logic inside your render function that’s harder to test. If you have a fn which takes some data and returns some data which you then pass to your react component as props, you could trivially unit test it. > 3. Even though we’re not going to replace React with something else any time soon, make sure that you write code in such a fashion that such a replacement would be as easy as possible. > IMO, if you follow these three things, a lot of good stuff happens.

Kanskje TS/React folka dine kan ha nytte av det samme.