oessessnex

@oessessnex@programming.dev

• ⁨Comment⁩ on ⁨Post a prompt, have an art from this insane russian⁩ ⁨⁨4⁩ ⁨months⁩ ago⁩:

  Haha, this made my day :)

• ⁨Comment⁩ on ⁨Post a prompt, have an art from this insane russian⁩ ⁨⁨4⁩ ⁨months⁩ ago⁩:

  A whale swallowing the world.

• ⁨Comment⁩ on ⁨Tough Trolly Choices⁩ ⁨⁨4⁩ ⁨months⁩ ago⁩:

  I would just pick the root of each underlaying balanced binary tree, easy.

• ⁨Comment⁩ on ⁨Boil 'em, mash 'em, stick 'em in a stew⁩ ⁨⁨6⁩ ⁨months⁩ ago⁩:

  You don’t even need soil, you can just put them on the ground and cover them with hay, and they grow just fine.

• ⁨Comment⁩ on ⁨Opinions on how to deal with duplicate code.⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  The implementations mostly don’t matter. The only thing that you need to get right are the interfaces.

• ⁨Comment⁩ on ⁨Golang be like⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Nope. Monads enable you to redefine how statements work.

  Let’s say you have a program and use an Error data type which can either be Ok {Value: T} or Error:

  int a = new Ok {Value = 1};
  int b = foo();
  return new Ok {Value = (a + b)};
  

  Each statement has the following form:

  var a = expr;
  rest
  

  You first evaluate the “expr” part and bind/store the result in variable a, and evaluate the “rest” of the program.

  You could represent the same thing using an anonymous function you evaluate right away:

  (a => rest)(expr);
  

  In a normal statement you just pass the result of “expr” to the function directly. The monad allows you to redefine that part.

  You instead write:

  bind((a => rest), expr)
  

  Here “bind” redefines how the result of expr is passed to the anonymous function.

  If you implement bind as:

  B bind(Func f, A result_expr) { return f(result_expr); }

  Then you get normal statements.

  If you implement bind as:

  Error<b> bind(Func > f, Error result_expr) {
     switch (result_expr) {
         case Ok { Value: var a}:
             return f(a);
         case Error:
             return Error;
     }
  }
  

  You get statements with error handling.

  So in an above example if the result of foo() is Error, the result of the statement is Error and the rest of the program is not evaluated. Otherwise, if the result of foo() is Ok {Value = 3}, you pass 3 to the rest of the program and you get a final result Ok {Value = 4}.

  So the whole idea is that you hide the if Error part by redefining how the statements are interpreted.</b>