12thwonder

it seems like less sophisticated version of reactive paradigm to me, am I wrong?

Most of the UI/UX designers that I see at work and other places are basically graphics designers. I just wish UI designers learn more about interaction design than just pure graphics design.

I think this article is more about alternative rasterization algorithm for 2D geometry. 'vector graphics' is misleading as vertices used in graphics APIs are vectors.

> creation of a Beizer curve: ... clearly a CPU algorithm.

isn't this just a tessellation basically? GPU-based tessellation is very common, mostly for meshes but can be used for line-like figure too.

can you elaborate on what "protocol" looks like? or can you give us some example?

I like this.

It is very hard to find out if the definition already exists or not in the codebase. This can lead to multiple definitions of the same thing or the truth.

anyone has a good way to deal with this?

good article. my questions now is how can we avoid over-plannings and under-plannings?

a lot of time I feel like the diminishing return of a planning is pretty steep for many situations but it's hard to tell how much time we should spend for the planning beforehand. (this is a planning for planning and maybe this itself is over-planning lol).

I am amazed at how small the codebase is, and also pretty readable. great to see work like this, thank you!

good to know, thanks!

I personally would like to know when the GPU resources become available (freed) thus still inclined to prefer RC over GC tho.

this is a really good benefit of RC codebase.

Resource management becomes much more harmonious and easy to follow.

like Chris said in the article, it is difficult for GC languages to interop with C/C++ codebase.

in addition, if your system requires precise control over when and when not to use CPU, like resource-intensive gaming, browsers, OS, then GC may not be a good choice.

lastly, if you are using GPU via graphics API, I do not know any API that can garbage collect GPU memory but RC can naturally extend memory cleanup code to cleanup GPU memory as well quite easily.

my understanding is that the author is talking about stack usage at runtime not the size of an entire stack which can be set by the pthread API you mentioned. it's confusing because the article starts with a discussion of how default stack size differs depending on a platform.

what is your view on Clojure.spec?

Throwing away is easy but remember, you have to do the runtime check instead of compile time check, and that is not so easy in a lot of cases