mitt_romney_12

But now every function that reads from stdin needs to pass around an offset of where to read from which is very unergonomical. It also isn't really pure since offset is now state that is changing whenever a function is called.

fn do_stuff(offset: int) -> (string, int) { x = read_guess(offset) y = read_name("what's your name: ", offset + len(x)) z = read_guess(offset+len(x)+len(y)) new_offset = offset+len(x)+len(y)+len(z) return ("name is: {y}, guess is: {x}", new_offset) }

What happens if you do:

x = read_guess(); y = io.read_int("what's your name: "); z = read_guess();

How would your system ensure x and z are the same?

This is an interesting approach but it has some issues with more more advanced effects. For example if you have a function that uses mutable state you would need to have the state both as an input and an output (for the original and the updated state) `update_mut: State -> String -> State` this isn't very economical as is probably worse than just `update_mut: String -> State ()`. If you commit to just having the parameters act as "markers" that don't actually relate to the implementation then you can get away with `update_mut: State -> String -> ()` but then you use one of the big benefits of effect systems which is that you can change the way effects work and have multiple different implementations.

You're approaching this from a PL design standpoint where the distinction is important, but from a user perspective it doesn't matter if it's just "syntax sugar" or if it's a super complicated to implement all that matters is whether the feature is available or not.

> the situation is, in the worst case, as good as when types are mandatory

The worst case is actually worse than when types are mandatory, since you can get an error in the wrong place. For example, if a function has the wrong type inferred then you get an error when you use it even though the actual location of the error is at the declaration site. Type inference is good but there should be some places (ex. function declarations) where annotations are required.

If you replace the ternary with an if then it's easy to understand for anyone who knows what ... means (which imo every JS developer should know)

  const count = (amount: number) => {
    if (amount > 0) {
      return [...count(amount - 1), amount]
     } else {
      return []
     };
  }

With JSX you can do

  const todo = <DoMoreStuff args={...}><DoEvenMoreStuff args={...}/></DoMoreStuff>;
  <DoStuff args={...}>{todo}</DoStuff>

> With any financial innovation, there's often a cycle: initial excitement, over-extension, contraction, and then matured understanding

I'm a little more cynical, I think the cycle is: a new financial invention comes out, greed causes people to people to pump money into it, eventually the bubble pops or regulators step in. We've seen it time and time again: the dot com bubble, the subprime mortgage bubble, SPACs, and now/soon (IMO) with PE. My question is how many times this has to happen before we stop viewing it as an isolated with specific product and start to see it as a system issue with our financial system.

Under this interpretation nothing can ever be revolutionary. There is absolutely and ideology that is dominant in society at large and trying to say that the ideology that runs 95% of world powers and one that opposes it are equally "revolutionary" is counterfactual.