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

Glad you liked it. If you read some of the original Moon articles (“Introducing Moon”) you’ll find that I was frustrated with other libraries and strived to create a smaller and faster alternative.

Now I have worked on designing a new structure for web applications that I’m planning on writing further about. The view API of components in Moon closely models my vision for the future of the web. Moon’s philosophy is to have a consistent API in order to create views to display data.

For now, it is non-keyed. As I mentioned in some other comments I just wanted to get a beta out as I've been rewriting Moon for about a year and it's finally gotten to a semi-usable state.

A keyed implementation, single-file components (multi-file components exist with Moon CLI but I've started to like single-file components), custom DOM events, component inserts, and an official router are on my todo list. Hopefully you'll get to use the library this time :)

Your views are compiled down to JavaScript beforehand. Your example would be compiled to something like:

  m2.textContent = instance.text;

Use Moon.compile(template) to get a better idea of outputs.

It’s currently in beta and although that’s no excuse for the lack of warnings I just wanted to get a beta out as I started v1 almost a year ago.

It's been rewritten completely and hit 1.0 beta a week ago :)

To prevent large bundles, Moon uses a lightweight runtime that is about the same size as the equivalent compiled virtual DOM render function (using React.createElement for example).

It's definitely based on preference, but I designed MVL to be as simple and consistent as possible. For example, there are two ways to create a for loop (one on the ul and one on the li).

  <For={item in items}>
    <!-- multiple elements -->
  </For>

  <p For={item in items}><!-- single element --></p>

This syntax works for every component ("For" is just another component).

Thanks! It used to be a smaller version of Vue aiming to be a small subset of it. For the v1 beta (what the current documentation is for) I decided to change up the API to be something more simple that can still scale well for larger projects.

Linear types are different from immutable types. You can change the value of a linear type as long as you used the previous value somewhere else (for example i = i + 1). Languages like Rust leverage affine types (another substructural type system similar to linear type systems) in order to guarantee memory safety.