solomonb

Is that really true? I'm asking not debating, as I may have selection bias in how I observe Lean Manufacturing through the lens of small to mid size companies with active public relations via the internet.

> I think the key that makes process improvement work in manufacturing is that the production line is continuous, and the measuring of outcomes is independent. Car quality, customer satisfaction, units produced, mistakes, etc.

I think this makes a lot of sense. The products in software development are a lot more nebulous.

The point was that later typewriters had a features like memory, automatic indentation and erasing that were not available in 1950s era typewriters..

If you follow the two paths around the square you will find that everything typechecks correctly and both paths get you to the same result. This shows how the two paths are equal in some sense.

To keep this simple just imagine the objects are types and the arrows are functions between those types.

You start out in the upper left corner and walk through the two paths checking the types as you go along. If the diagram typechecks correctly then it is said to commute and the two paths are in some sense equivalent. The specific sense depends on a bunch of details elided here.

    mySubroutine = do
      foo <- mkFoo
      bar <- mkbar foo
      mkBaz bar
    
    mySubroutineV2 =
      mkFoo >>= \foo ->
        mkBar foo >>= \bar ->
          mkBaz bar

Short circuiting on `Either` is a specific case of this. You can define your own EitherBind in any language.

    eitherBind :: Either e a -> (a -> Either e b) -> Either e b
    eitherBind (Left e) _ = Left e
    eitherBind (Right a) f = f a

You don't need monads for this. You just need the ability to encode your error in some term like `Either e a` and ability to eliminate those terms. In Rust for example that is the `Result` type and you use pattern matching to eliminate those terms.

https://en.wikipedia.org/wiki/Optic_(disambiguation)

> In computer science, optics are a general class of bidirectional transformations

Its still my most starred repo. :shrug:

  data Maybe a = Nothing | Just a

  foldMaybe :: (Unit -> r) -> (a -> r) -> Maybe a -> r

Now I don't know what to think..

> What the market values is the ability to produce things that are rare and are valuable.

> what the market dismisses are activities that are easy to replicate and produce a small amount of value. Well social media use is the epitome of an easy to replicate activity that does not produce a lot of value [...] by definition the market is not going to give those activieis a lot of value [...]."

Yet in the years since this TEDx talk we have seen the rise of influencer and streamer celebrities who have gained an immense amount of wealth and power.

> In the years since I wrote this, I have gotten much more bullish about pure functional programming, even in C/C++ where reasonable: (link) > >The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing.

He explicitly says that functional programming solves the same issue as inlining but more directly and completely.

I have with another deprecated effect library. Its a bummer to have something so core to the architecture that is deprecated but then to not have the time or buy-in to do anything about it.

Just to be clear I think Bluefin is really cool and I'm a fan of your work overall.

I'm speaking from the industry/production perspective here. When polysemy and freer-effects were released there was a similar belief that they were here to stay.

transformers and MTL have stood the test of time, are heavily documented, and are pervasive throughout Hackage. Understanding them and how to build programs with them is essential for anyone trying to break into 'production haskell' as a career move.

You have a function that can return a Null response and you are claiming you can rewrite it to be one that does not return a Null.

This means that in the cases where your function previously produced a `Null`, you have to produce a `Y`. You claimed you can do this if you write the function to receive `X|Null`. In other words you are claiming you can write `(X -> Y|Null) -> X|Null -> Y`. I challenge you to write this function.

> "Implementing" is a special case of rewriting, so how can you say you can implement something but not rewrite it?

I didn't say that. You claimed you can write `(X -> Y|Null) -> X|Null -> Y`. I am saying that is impossible but you could write `(X|Null -> Y) -> X -> Y|Null`. Do you see the difference?