yuhe00
yuhe00 on Hacker News
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.
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.
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.
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.
Yes! Would definitely recommend the investment if you spend a lot of time typing on the computer ;)
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.
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 ;)
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!
> 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.
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.
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...
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.
You do have the C API in the form of source code. You just can't distribute your changes as a plug-in.
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.
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...
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.
> 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.
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.
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.
When I was young, I avoided restaurants because of exactly this! Always preferred cafes/fast-food places where you pay first. It just didn't make logical sense to me. I've grown out of it now obviously... :P
Realtime raytracing hooks into an existing multipass pipeline like this by replacing select traditional techniques. The easiest to replace are shadowmaps and AO. You can also make use of radiance (diffuse GI) and reflections with one or two bounces. Traditional techniques are currently faster and give better results for just about everything else. Also, you can only afford maybe 1-2 raytrace samples per pixel at the moment, even with RTX, so they make heavy use of AI denoising techniques.
https://www.inconspicuous.noMostly just a CV and overview of projects I've done. I do consulting on realtime-rendering, game dev and interactive installations. Somewhere between tech and design.
It's made for mobile, which is the correct move in this day and age. But yes, should not be difficult to add keyboard controls too.
As a fan of both visual programming and Haskell, I definitely think this is the future of programming, and I can see it going two ways - A general purpose tool like
https://nodered.org with a huge library of plugins or included in a host program as a VM/embedded DSL. Or perhaps both ;) What are the developers plans/thoughts on this?
Oh, I was genuinely unaware that the replication crisis was such a big problem in psychology - It makes a lot of sense though, and it was a fascinating read :) And yes, I do agree that there's a problem with incentivization in all the sciences.
I don't know a lot about psychology. The only things I've read are pop-psych articles like this about "traits", "D-factors" and "personality types", which you got to admit do sound a bit much like pseudo-science, or at least not telling the full story. It's useful, for sure, but I'd like to know more about the formal methods employed in modern psychology today. I imagine statistics, surveys and telemetry perhaps being key, but like all methods based in data - You have to be very careful; testing methodology and interpretation biases can heavily influence the results.
I think psychology could bring valuable insight into the future of AI as well. It's a shame that most psychologists involved in tech are in HR/communications or at best tasked with keeping people addicted to whatever social platform they are building.
Most of the work in programming is in describing (in very strict and pendantic terms) how different systems interact with each other and how the data flows from one end to another. The actual work of moving the data and doing all the calculations is handled by machines. In that sense, the work done in programming is designing and integrating systems, not the execution of it. In your analogy, installing a shelf would be more like installing Photoshop (which we can presumably agree is actually simpler than installing a shelf). Most people do not design their own shelf, select the most appropriate fasteners, source raw materials and send it to manufacturing to be mass-produced. A shelf is also a relatively simple piece of furniture. What about a desk-drawer or a closet? Sure, you can buy the raw materials and power tools at any hardware store, but is it trivial for anyone to actually design and build usable (and desirable) furniture from pieces of plywood?
Oh, I think you're spot-on. I've definitely spent more time consciously practicing typing and I used to have some bad habits when typing QWERTY (e.g. using the wrong shift for certain characters or typing 'Y' with my left hand). In fact, what initially prompted my interest in custom ortho keyboards was trying to rectify some of my bad habits in QWERTY and finding it really painful on my wrists to touch-type the "proper" way using a standard staggered keyboard.
I think the biggest benefit for me has been exactly that - taking a whole new look at a skill I thought I had figured out - Or going beyond what I thought was my limit by approaching it in a new way. I think the numbers and WPM don't really matter, but it's a nice way for me to personally quantify my improvement and progress over time. That said, I think it would've been impossible to for me to do all this without discarding the familiar (QWERTY) and starting from scratch. In that sense, the layout matters.