fuwafuwa

Short answer: No. Gamedevs have to keep showing testing zealots the door.

Long answer: The problems with the approach are manyfold. There are a few points where testing is automatable, but they don't describe entire game projects well.

* What are you testing when you add gameplay? You are testing for a whole set of design concerns across the project, not just a technical specification or quality of service metric. You cannot do it in isolation and get the results you want at the speed you need, because you need tons of feedback to discover what a complex game is currently strong or weak at. The only reasonable way to gain the necessary feedback is to allow prototyping code to drive near-term changes, manually playtest it, and then factor out the most stable parts of the resulting soup where you can. This works against test-first because you don't really know what you're testing. You throw in a feature on a hunch - "maybe this will give the experience we're looking for" - and see how it behaves hands-on. If it works, there are still usually ramifications and elaborations that didn't surface up-front. And once it does work it's hard to break out into a sandbox because the interesting part of the behavior is in the coupling to other systems and features.

* Games deal with vast quantities of mutable state strapped onto relatively straightforward data pipelines: the parts that are most testable are engine and toolchain core elements like asset builds and rendering systems. These parts do see unit tests and integration tests, although there isn't total consensus on how much testing is needed or how it should be done. They are the most like business and application software, though, since their development can be more structured around technical goals and quality metrics.

* Many bugs are ultimately data bugs. Some designer or artist set up the wrong binding of assets or made a valid yet broken combination of parameters. Games tend to fly apart very suddenly when they operate on bad data. But the code is doing exactly what it should do for that set of inputs - and if it's a failure it's at the level of process and tooling, not the runtime code.

Typing text at speed is not really that different from playing an instrument at speed. When you pluck a string you're able to keep it in rhythm by using the resulting noise of your own playing as the cue to synchronize the next beat. When latency is high or varying, as sometimes happens with software synthesizers, even the simplest rhythm starts falling apart. Professional audio applications want very low latency, sub 20ms as a baseline, but preferably below 10ms.

In that light, it totally makes sense that typing latency matters. If you aim to type in a smooth rhythm and use the screen as feedback, any hiccup will slow you down.

Well, of course ECS does that. It's ultimately the same approach to data as a normalized relational schema. It's a bit of upfront work but the flexibility of processing and optimization is awesome.

For UI the issue is one of expressing lightweight dependencies, which may be detached and recombined easily. I am currently exploring an approach that combines "imgui" concepts with hierarchical path data, akin to the hard and symbolic links in Unix. Having the path as data allows assemblages of partial routes to be combined to express a "final" data point. The data itself may not entirely exist in a physical tree structure but instead be a combination of procedural data, stored data, and a parser.

Long "crunch" work hours with little or no enforced break, laissez-faire approaches to lunch and break room snacks, occasional encouragement to drink alcohol, lengthy car commutes to office parks, heavy preference towards in-person over remote. These are just some of the things workplaces do to lifestyle that are too small to be a topic for regulation but big enough to impact lives.

All of our fitness and nutrition advice is troubled by the cargo-culting, marketing-driven, personal-religion factors: if I go to a yoga class I spend a lot more time and money to get effects roughly similar to doing a high school gym class stretching regime each morning and evening. I paid $14 yesterday for the experience of a burger with a fancy name and an overly sweetened bun that was ultimately less satisfying than Burger King. If I buy and use supplements marketed by a bodybuilder, or try to follow their training program as printed in a magazine, I'm not going to look like the bodybuilder, and I will probably overtrain, because they weren't using the supplements at all, they were using a PED stack to train harder, eat more, and recover faster without overloading their system. Worrying about my body weight, BMI, or aesthetics is similarly Quixotic in that my body will prefer to stay in a certain range regardless of how I eat or train, and the numbers I can consistently improve tend to be "weight and reps" or "time and distance", while aesthetics and vanity numbers are much harder to aim towards.

To wit, it's more important to develop your own feedback loops for each of these things. There are serious concerns with fitness and nutrition in the U.S. but they aren't necessarily because it's impossible to get at the good stuff: it's just that eating beans and rice and oatmeal, making a habit of stretching and bodyweight exercise, and studiously logging one's training are all unfashionable, implicitly discouraged by most workplaces, and not well served by market forces.

Code already written in C/C++. I don't think there's anything stopping Rust from snowballing at this time. It's built some very strong libraries for certain problem domains, and because there's package management, it's possible to reuse it. This has already substantially reduced the friction of "systems" programming since you don't run into a challenging build process. But for the majority of folks the answer for an immediate need is still a tool or framework they already use.

The 24 hour upswing may be another bull trap masking the bearish trend that has taken hold for the last month, which has hit the entire crypto market and sent some market caps down over 50%. The BTC scaling crisis has been a known factor for even longer than that and may have precipitated a runup in other coins that directly preceded this downtrend.

Your comment indicates that you don't really understand the value of ADTs as the switch, option type and NULL pointer comments overlap: in your new code(and it would be be new code since it's rewritten in Rust) you define it to have Some(pointer) or None. Then to access the value you have to switch on and evaluate the None case at any dereference site. NULL cannot happen but you can still pass around a None type.

Regarding safely reading urandom, you don't seem to be aware that concurrency issues occur when accessing it from multiple processes. This is something that the borrow system can aid with by formalizing access to a resource like urandom and not allowing contention for it to occur at runtime.

Also, nobody appreciates aggro kid language.

ABI compatibility: Not really solved in C++ - see MSVC versus Mingw. If you're coming from the standpoint of using a Linux distro or BSD you enjoy a sanitized environment from the start.

Multi-platform support: Pray that your project's build system makes it straightforward to get all the dependencies going on every platform. Pray that your dependencies are easy to access and of the correct version. Pray that the manufacturer's fork of an ancient gcc isn't too buggy to use. C made it possible, not easy.

Tools: Both languages are too impoverished to have tooling as comprehensive as the stuff available in, for example, Java, although VS pushes very hard on this front. rustc already gives better error messages than any C++ compiler.

Code base: See the build system problem. Maintaining open source projects in C and C++ is an exercise in endurance. Single header file libraries have come into vogue as a result - and they're a hack. There is a lot of decent code in both languages not being used because it's hard to get running.

Community: Rust is in a better position here in part because it's smaller. If I encounter a C++ hacker in an online space it's just as likely to be an aggro kid as a seasoned pro.

I believe it's tied to nebulous feelings of relative freedom or control over one's environment: once adopted, it's important to make sure your chosen technology stack wins and keeps winning so that you're still praised and employed. As a consequence the rationalization part of your brain will jump ahead and find all the reasons why the language is good.

Cosmopolitanism takes a bigger effort, and it needs a more general confidence in one's abilities. It's easier to focus on building a tribe.

Stretching indirectly helps with bone health by improving joint activation and range of motion. If you're getting an increased ROM that's generally better for the bone than if it's stiff and limited.

If you're really hard up for space or money, resistance bands offer one of the best tradeoffs. The modular sets scale up to high weight and will last a while.

The issues that I think hit most people are not really with equipment, though, but time/motivation/energy. For that, it takes ordinary habit forming and logging progress.

There's implications for development whenever we have a sandbox wall, too. There are serious differences in the development experience of a binary language with no runtime model, a binary language with one, a language wrapped in a high level, fully sandboxed VM, and a language compiled to another language. Some of them allow productivity, others restrict entire application categories.

Once you have a runtime, dynamic linking suffers. Once you have a VM, you lose vast swathes of control over I/O and resources. And once you target a different language you end up with lowest-common-denominator semantics and debugging capabilities.

In some respects, the JVM-style sandboxed language runtime is an "original mistake" because it's an OS-like environment that doesn't have access to OS-like features, leading to a lot of friction at the edges and internal bloating as more and more features are requested. If we had similar access to memory, devices etc. everywhere the friction wouldn't be experienced as such, even if there were protections enforced that hurt performance in certain cases. You'd design to a protocol, and either the device and OS would support it or it wouldn't. That's how the Internet itself managed to scale.

But as it is, the stuff we have to work with in practical systems continues to assert that certain line of coder machismo: unsafe stuff will always be unsafe and You Should Know What You Are Doing, and anyone who wants safety is a Newbie Who Should Trust A Runtime.

I believe OO is good for exactly two things: abstract data containers and state machines.

In the former, access hiding cleans up the API and prevents unsafe usages of the container. In the latter, OO enforces a protocol to keep the state machine sealed off and only aware of key inputs and outputs.

And that's it. I've found nothing else. Data itself is better off when strategized to fit in a database, whether off-the-shelf or a custom-tuned, in-memory design. The state machines may need to query a part or all of the database, as well, so their ability to restrict scope only goes so far.

Indeed, it's incomplete. It doesn't discuss digital/CG audiovisuals, popular genres, fashion, or world events. Memphis is important and worth diving into but it's only one facet.

It's already arriving. Look at the Chromebooks for education. They're thicker, ruggedized. A fair number have more durable keyboards. The battery life is excellent. These are machines for doing assignments - serious work. Likewise a lot of convertibles are sporting a stylus again to pick up the digital art market. And "Mobile Workstation" has become a sizable laptop segment independent of "gaming laptop". The shift is visible, although it'll be some time before the hardware/software packages are polished enough to satisfy pros with an established workflow.