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.
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.
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).
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.
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.