yuhe00 · HackerTrans

Unreal's Niagara has a visual editor. While it is packaged as an VFX/particle editor, it is in many ways an ECS. Each particle can have custom data structure and modules/systems that drive them. Under the hood the graphs are translated to SIMD-optimized VM bytecode when run on CPU. It can even support translation to HLSL/GPU-acceleration if all modules support it. Not sure if Unity has something similar.

yuhe00

4 anni fadiscuss

Actually Denmark was considering completely banning selling cigarettes to anyone born after 2010, but seems like this is unlikely to happen due to EU rules: https://www.thelocal.dk/20220407/eu-rules-dampen-danish-gove...

yuhe00

4 anni fadiscuss

With the availability of game engines, gameplay programming is actually very high-level. Most of the logic is handling some input or some collision or updating some position or timer every frame. The more complex parts of a game (collisions, physics simulation, rendering, asset management, networking, etc.) is handled by the game engine itself, so the games programmer usually only need to interface with the high-level API of these systems.

Also, games programming is HIGHLY agile. Most of the logic you implement will be thrown away. It's all about rapid prototyping and finding what is "fun". Of course, once you've found something fun you might want to build it into a solid and scalable system, but even in such a system you might want to keep the flexibility for designers to extend and add new elements as they see fit (using visual scripting!). The ability for non-programmers to be able to make gameplay changes is also an important factor.

yuhe00

5 anni fadiscuss

This is a creative coding library, similar to OpenFrameworks, Processing, etc. The description is confusing. Seems to be an in-house tool some creative agency decided to open-source.

yuhe00

7 anni fadiscuss

I don't think it's that complicated, it's just a matter of having different values. The Chinese culture values prosperity, solidarity, and security over freedom. and those are things the current government has provided in spades over the last few decades. Freedom of speech is not that important as long as you and your family can live your life in peace and prosperity. For most Chinese, it makes no sense to go against the government.

yuhe00

7 anni fadiscuss

Yes! Would definitely recommend the investment if you spend a lot of time typing on the computer ;)

yuhe00

7 anni fadiscuss

Everyone is different. Nowadays, if I post something, it is either: a) I have something to share, a bit of knowledge/opinion/story. If this is the case, I already know I am correct, and as such do not really care about the response and it's very easy to walk away, or b) If I pose a question, in which case I will be open to any response because I'm genuinely curious. I think I used to care more about what other people thought when I was younger and more insecure. Sure I can still be proven wrong, but I usually do not care enough to respond. I just learn and move on.

yuhe00

7 anni fadiscuss

I had one of the first revisions of the Ergodox EZ. There were some problems with the build quality, and a few of the legs arrived loose/broken. Customer service was great though, and I received replacement parts very quickly, but after a while the same parts came loose again. Likely a problem with the design or low quality component, which I hope the newer revisions have fixed. Otherwise a great keyboard, although it takes a while to get used to (around 3 months for me). I ended up building my own Ergodox using the open-source design - Now I have about 5-6 of them that I built myself, all with different keycap/switch configurations... Only negative is that I can no longer type on a regular keyboard ;)

yuhe00

7 anni fadiscuss

It takes a while to get used to. I switched to Ergodox and Colemak at the same time, and it took me around 3 months to get up to my normal speed again. Unless you type a lot on other people's keyboards (IT-support or similar), I'd say it's definitely worth it!

yuhe00

7 anni fadiscuss

> Your approach of delaying the abstraction choice sounds very interesting (somewhat akin to Extreme Programming?), I will try to keep that in mind for the future. In thinking about this I'm mostly afraid of code sort of remaining at this "makeshift"/provisional level and never actually settling into something more organized (due to lack of incentive/time to improve it). I think that can be kept under control, but do you have any suggestions on that front?

Actually, I find that more often than not, code written in this manner is actually easier to maintain, because there are no layers and concepts to untangle - just the raw functionality and data transformations. You don't need to put yourself in the mindset of the person who wrote the code, who might not have had the right concepts in their head at the time. Instead, you just parse the code like a computer - This makes it easier to figure out what the code actually does rather than being distracted by the intent of the author.

The main purpose of abstraction is to intentionally hide implementation details so other people can use your code without requiring a full understanding of all the details. However, when maintaining code, obfuscation is the exact opposite of what you want - You want to fully understand what the code is actually doing. Internally, I forgo most abstractions. For public interfaces, I expose highly specific functions and datatypes rather than "generic" interfaces, and only the bare minimum. Variants should favor duplication over generalization when uncertain. It's up to the consumer of those APIs (which is often myself!) to choose whether or not to implement abstractions on top of those. In my experience, it's either super-obvious when it's needed or unnecessary if unsure - So you can usually push back abstraction up to that point.

yuhe00

7 anni fadiscuss

I don't think OOP itself is bad. Bad abstractions are bad, no matter the language, and that is the main problem. Abstractions and domain models are created based on our understanding of a given problem as well as what is possible within a certain programming language/paradigm. Most of the time, we initially do not have a good understanding of the domain we are working in, and because we are conditioned to keep code "organized", we tend to fall back to established "patterns" (which OOP has an abundance of...), but these almost always end up being the wrong abstraction. By the time we figure this out though, it's already too late to change it.

A functional language such as Haskell tend to make us think a little bit more about what abstractions we use, because they are such an integral part of the language you can hardly do anything without them. We can "converse" with the compiler to come to a better understanding of how our code should be structured. You usually end up with a better domain model. However, this can also be very limiting. Lack of control of execution and no control of memory layout is a problem in my domain (video games). It's also slower to develop for because you can't take "shortcuts", which can be helpful to get something up and running without having to understand the problem domain.

I still use OOP daily (C++), but I never start out with abstractions when writing new code. I tend to create C-style structs and pure functions. Eventually, I will have a better understanding of how this new module should be organized, and will make an API that is RAII-compliant and whatnot. I think you can easily write clean code in OOP as long as the abstraction makes sense.

yuhe00

7 anni fadiscuss

Tech roles comes in many forms. For example, I have worked a fair bit with graphics programming and VFX, where extensive knowledge of photography would be very useful.

I can imagine tech jobs where most of the hobbies you've listed could be considered relevant. Dance? Biometric sensor tech. Guns? Video games. And so on...

yuhe00

7 anni fadiscuss

This article is funny because it starts off with an assumption that is the opposite of my initial perspective. Then again, it was also quite a revelation to me when I learned that a lot of people are not like myself and cannot stand being alone for long periods of time and actually spend a lot of time thinking about their relationships with other people.

yuhe00

7 anni fadiscuss

You do have the C API in the form of source code. You just can't distribute your changes as a plug-in.

yuhe00

7 anni fadiscuss

This is fair. I don't think anyone can claim they have never been disrespectful towards anyone in their life. People are sometimes unbearable and sometimes you are too. Learning to deal with your own and others crazy bullshit is a part of life and how you grow as a person.

yuhe00

7 anni fadiscuss

I'm also an introvert. I get exhausted when spending a lot of time with other people. One thing I've noticed though is that when I do spend time with people, I prefer getting to know new people rather than hanging out with people I already know. I guess this is some subtype within introverts, because the "stereotype" is that introverts have a few close friends - Instead I have lots of shallow relationships and I am terrible at keeping close friends because I never spend time with them...

yuhe00

7 anni fadiscuss

I agree. It's true that it is easier than ever to have instant access to just about anyone in the world, but because it's so easy, we become less interested in actually investing in people and forming lasting bonds. Why bother when we can get what we need without? What used to be genuine connections formed by necessity and shared experiences have now become quick and easy transactions. Social media and the gig economy have made interpersonal relations into fast food, and the world feels smaller and less fullfilling because of it.

yuhe00

7 anni fadiscuss

> A bug is never just a mistake. It represents something bigger. An error of thinking that makes you who you are.

I like this quote from Mr. Robot. Most of the time a bug is not an error in logic, but a misunderstanding in how some component of the system works or an unexpected outcome of the emergent behavior of basic rules. Always check your assumptions.

yuhe00

7 anni fadiscuss

Maybe I've just been unfortunate/fortunate, but in 6 years as a software developer on all kinds of projects, I've never once worked on a project where even two people share the major contributions to a single repo. Either I run away with one part of the project or someone else does while I work on some other part. Usually split between frontend/backend/devops (webstuff) or app/libraries/tooling. We obviously plan and discuss how the different parts of the projects work together, and we do make contributions to the other repos, but these are usually minor.

I don't necessarily see it as a bad thing. It just feels the most natural, reduces friction and the need to communicate minute details. Ownership is also important. The downside of this is that some part of the project might fall apart if someone leaves, because no one else can take over.

yuhe00

7 anni fadiscuss

But the learned behaviour will be short => likely a shoplifter. Short people who don't shoplift will have to deal with being suspected of shoplifting at a higher rate than the rest of society. You could say that's just a fact of life, a minor thing, but it's still a privilege to not be in that group. If you then belong to multiple of these groups (dark skin, poor neighborhood), you become a primary target without ever having any intention of doing anything illegal. It's not immoral per se, but it does not set the stage for a fair society.

comments