kbr

NNs have complex non-convex loss functions that don't admit a closed-form solution. Even for small models, it can be shown that it's an NP-complete problem. In fact, even for linear regression (least squares), which has a closed-form solution, it can be computationally cheaper to run gradient descent since finding the closed form solution requires you to calculate and invert a large matrix (X^T X).

> Sustained effort compounded over time is unreasonably powerful.

Thank you, this hits close to home and is great advice, I appreciate it.

As a high schooler interested in things that are probably out of my league, I love reading this kind of stuff. The author mentions their unconventional style at the beginning: hyperlinks, color, italics, exclamations, parentheses, side notes, etc. They address your thoughts and craft their explanations around them instead of being terse and optimizing for length.

The author's blog [1] has more of this style and has really helped me get deeper into category theory. Without it, I wouldn't have even begun to try and understand things like the Yoneda lemma (which still remains a mystery to me).

Does anyone know any other papers or resources with this style? Maybe something like "explorable explanations" [2]?

[1] https://www.math3ma.com/

[2] https://explorabl.es/

I think dependent types are stronger than refinement types because they can encode types that don't necessarily have to be decidable. Refinement types are used for creating subsets of a type, while dependent types can be used for creating arbitrary types based on values. As a result, dependent types are more powerful, but they might be too much if all you need are some constraints on an existing type.

I think you might be describing refinement type systems [1]?

[1] https://en.wikipedia.org/wiki/Refinement_type

`|` is bitwise-or in many C-style languages.

AFAIK React itself is performant enough, the bottleneck is client code within components. I suppose the change is mostly for full enterprise web apps at the Facebook level that likely have thousands of components running at the same time. Concurrent mode lets React split up work and give some time back to browsers (for e.g. mouse movements or rendering) to prevent large freezes on rerenders, essentially allowing prioritization of certain interactions for latency. On top of that, I think it also helps to remove some of the bottleneck that comes from I/O.

I wrote an article with the same name! [1] The problem solving based approach seems to be the most relatable and easy for people to get an idea of what monads are. Nice work.

[1] https://blog.kabir.sh/inventing-monads

Yup, I think they definitely found the sweet spot for making revenue from games — offering players sweet returns if they keep playing (you buy the battle pass for 1000 vbucks, but you can earn back 1500 just from playing casually) while still keeping it relatively competitive and not "pay to win". They did host a $30 million world cup event after all :)

They pioneered the "battle pass" model for cosmetic items, and their constant release of skins, dances, etc can create a lot of recurring revenue I imagine.

Hey, I wrote a post with the same title [1]! I feel like everyone writes a blog post once monads finally click, and this one is great — I like how you introduced them through solving real-world problems. :)

[1] https://blog.kabir.sh/inventing-monads

Their semantics might be consistent, but they sort of leak into the parent. Height and width are local to what the component renders, and they don't depend on the parent (as long as they aren't relative sizes). But things like margin and align-self change how the parent renders all of its children.

In other words, the view rendered by the component is a function of properties like height and width. But when you throw in margin or align-self, the component now depends on its siblings.

The OO perspective is interesting — I agree that it effectively makes these things hard to express. I now think that it's more of a problem relating to encapsulation and isolation. OO would isolate it through a child component interface while FP would have a function that can't affect siblings.

How does it become any more object-oriented?

I saw it more as "purely functional", where components are the functions and styling outside of the component is a side-effect. Avoiding side-effects like margin or align-self makes components more like pure functions than objects IMO.

Looking at their GitHub [1], it's been actively developed and open source since 2013.

[1] https://github.com/unisonweb/unison

My bad then, that's fair. JS has been deviating from C-style syntax and it really shows in this article haha

Sorry about that haha, the style of programming in this guide is very different from C++, and it relies heavily on currying and lambda functions using next-generation JavaScript syntax. Nonetheless, I think it can offer a new perspective because JS is more comfortable than Haskell for most developers.

Thanks haha, I had exposure to computers from a very early age, and I try to make functions/systems representing things I'm curious about. It's helped me grasp ideas and come up with new ones, and I should probably write about them more :P

Hey! I attempted to make the code snippets use practical concepts, but they aren't very practical for use in actual JavaScript code — the reason being that JavaScript is not a functional language and doesn't have syntactic sugar for monads.

However, I chose JavaScript because I believe it's more familiar and widespread, and it can be easier to explain a foreign concept when it's done in a language that more people feel comfortable with.

Thank you! I'll mention "You Could Have Invented Monads" along with a couple of other great resources that helped me at the end of the post.

I believe that the aesthetics and layout are inspired by Edward Tufte [1].

[1] https://edwardtufte.github.io/tufte-css/

That’s a ToDo app example