throwthrow0987 | 3 months ago | on: Netflix to Acquire Warner Bros
Is this as big as I think it is?
throwthrow0987's comments
throwthrow0987 | 3 months ago | on: Freer Monads, More Extensible Effects (2015) [pdf]
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.
throwthrow0987 | 4 months ago | on: Launch HN: JSX Tool (YC F25) – A Browser Dev-Panel IDE for React
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.
throwthrow0987 | 4 months ago | on: How the UK lost its shipbuilding industry
>comparative advantage
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?
throwthrow0987 | 4 months ago | on: Why don't you use dependent types?
Thanks, very clear explanation.
throwthrow0987 | 4 months ago | on: Why don't you use dependent types?
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?
throwthrow0987 | 4 months ago | on: Why don't you use dependent types?
>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.
For which reason sorry?
throwthrow0987 | 4 months ago | on: Ask HN: How does one build large front end apps without a framework like React?
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.
throwthrow0987 | 4 months ago | on: Ask HN: How does one build large front end apps without a framework like React?
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.
throwthrow0987 | 4 months ago | on: Free applicatives, the handle pattern, and remote systems
> is quite convenient
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.
throwthrow0987 | 4 months ago | on: Free applicatives, the handle pattern, and remote systems
They must be making a lot of money!
throwthrow0987 | 6 months ago | on: What the interns have wrought, 2025
How many of these projects are actually merged to master and live though? I noticed the phrase "worked on" a lot, as opposed to shipped.
throwthrow0987 | 8 months ago | on: Flix – A powerful effect-oriented programming language
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.
throwthrow0987 | 1 year ago | on: Stop Using and Recommending React
So why is barData being recomputed? Does anyone understand how React compiler works enough to answer this?
page 1