Effect systems are a trend that will go away. You can't statically guarantee that only, for example, the DB has side effects in a function. So what's the point? Haskell got it right in the first instance: IO or pure.
Most big corporates have their own inner sourced css components library. So when you get design feedback you wouldn't be directly editing the style in one self contained web application, which is what this demo is assuming.
Makes a lot of sense in textbooks. But in the real world, when politics is involved, the whole theory breaks down. What does your text book say about China holding rare earths hostage in regard of comparative advantage?
So it seems the thesis of some pretty in the know mathematicians is that the secret of dependent types is knowing when not to use them. Is that necessarily an argument against Lean or Rocq? In the sense could one simply just not use the dependent types on offer in these languages in certain circumstances, and try emulate an Isabelle proof using custom built tactics?
>It has been some time I worked seriously in a dependently-typed language, but I recall coming to the conclusion that dependent types are best used as little as possible, for exactly this reason.
React is dead easy to create a component and get going with whatever you want to create. But as your application grows it is really difficult to test. The React testing library sounds good in principle, but once you have useEffects, hooks, the DOM, and every other side effect running interwoven with your component logic, it becomes difficult test. Obscenely difficult. I think there's some tradeoff operating here. I want a front end framework that makes it a little easier to test, happy to go through some more pain to write components.
I preferred class based components. The pretend functional programming style of hooks is quite imperative when you prick a little beneath the surface, so classes were probably the right abstraction.
It's not principally about convenience though is it? It's about defining the semantics of your program through the DSL. Then you can verify the program logic, prove properties about it if you wish. It is denotative.
If you have an effect ReadsFromDB, you can't enforce statically that someone will not come along and change the ReadsFromDB effect to write to the db. That's why I think Haskell got it right in the first instance, functions are either pure or IO.