12thwonder

I made a similar editor a while ago https://apps.apple.com/us/app/aerial/id1483897826?mt=12

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

sort of. I don't write tests at early stages, do you?

I don't see types as serious tests and I don't think they are robust. let's say that some integer must be between 10 and 100, do you use type checks for this?

good point. Yes, during prototype phase, rigid typing actually helps quite a bit. I still do that myself, simply because I don't have to "run" the program to see if I'm on the right path when I'm just sketching things out.

I guess what I wanted to say is that, in the long run, compile-time checks may become runtime checks, especially something like enum values where at the beginning, enums are fine choice but soon you will find yourself where you have to store that to a DB etc.

Problem is, moving from compile-time check to runtime check isn't that straightforward in a lot of cases.

yeah, but my point is that checking system that you had created will be thrown away at some point in my experience. so why bother writing types? that is my attitude at least at very early stage of a project.

later in a project where you know for sure something can be known at compile time, of course I love to check them at compile time.

back in the days, I had this infatuations with the idea of having everything checked at compile time by using type system. and I see many people following this kind of path with type system of Haskell, rust, and maybe typescript. granted, it feels good, at first.

I don't do that any more. simply because I'm very lazy and also in a lot of cases, those types that I wrote will be replaced by more dynamic representation (e.g. strings) at some point.

why not

    struct Foo{
        bool some_flag : 1;
        bool other_flag : 1;
        ....
    }

?

I feel like you are talking about types in programming languages but Object–relational impedance mismatch is still a thing and I'm not sure if you want a solution (for the mismatch) at DB level.

I wonder what kind of application I need to try

application that deals with highly dynamic data. lots of variants (OR type) in tree/graph. (photoshop's layers come to mind.)

I think what you are saying makes sense for a lot of projects. but point I was trying to make is that there are projects that have to deal with highly dynamic and complex data structures. I used file system as an example but any trees/graphs are pretty hard to express as a simple type.

do you think having a DATE type will increase performance for example as opposed to use INT/LONG type?

if stronger type systems will ensure performance, Haskell will beat C in benchmarks but that's not the case in most situations.

but do you want, for example, a file system where you have to define what kind of files you can store?

This folder can only contain JPEG and PNG files, this folder can contain only A or B ....etc.

useful in some cases but I don't think this is not what you want as a default.

off-topic but the author's negative sentiments toward c++ is interesting to me as it is quite opposite with me.

I use c++ mainly but when I have to use javascript at work, i really hate it for whatever reason. wonder if other c++ programmers feel the similar way.

Right, Browsers too are written in c++ for the most part

I personally don't see that capitalism itself is the culprit of the issues mentioned but I don't like monopoly powered by free software.

as long as competition is in place, I am kinda ok with big companies exploiting(?) free software.

I do agree with most of your points, porting may not be possible. However, I was just wondering if the future of C/C++ can be much safer than it is right now. for example, GCC's GUARDED_BY macro is a big help in thread safety for c/c++. not sure how much further we can go but just a thought.

for new projects, sure. but when it comes to existing c/c++ projects, I'm not a big fan of rewriting everything.