If you or anyone else reading this haven’t finished Stephen’s Sausage Roll to the very end, including reading all the story book paragraphs along the way (which increase in poignancy and frequency as the game winds to a close) then I strongly encourage you to do so. No spoilers!
I love pure puzzles and completed SSR. The story consists of sign plaques that narrate the history of the fictional world, and how your player character fulfills their place in the world through the main goal of cooking sausages. A bit unique and interesting, though not particularly complex, and you can guess the twist before it reveals. In other words, a puzzle game with a short story interspersed, perhaps 99% puzzles and 1% reading. The music consists of relaxing algorithmic ambience. The artistic ambition aims for surrealism and minimalism. I like it a lot, but I recommend against it for you.
I’m good with zero-story puzzle games. I’ve spent many hours in Simon Tathem’s Puzzles [1] on my iPhone, just for the 100% pure logic goodness that they are.
Do yourself a favor, if you haven't yet: go in the instructions for the games you like and find out the original game's name (for example' "Light Up" is actually called Akari), go online and find hand-crafted puzzles for that game. I love that Simon Tatham's Puzzles exists, but nothing beats hand-crafted puzzles made by good designers. There's a sense of purpose in the order you discover the solution and some "eureka!" moments that randomly generated puzzles will never give you!
The same way linux isn't. It's easy to start, all the base modifications/configurations are fairly simple, and if you find yourself deep into custom ways of using it, it's open source and fairly well documented with a large community.
I think that a "minimal viable baseline" type implementation should not break the ODR.
In Rust these types of proposals are common, in C++ less so. The incredibly tedious release process encourages everyone to put in just as much complexity as they can safely get away with.
This is begging the question. Yes, but why did they do that over dedicated syntax?
(My personal theory is that early go had a somewhat misguided idea of simplicity, and preferred overloading existing concepts with special cases over introducing new keywords. Capitalization for visibility is another example of that.)
I'm no longer sure what you're saying. You asked why they didn't go with dedicated syntax, I listed two advantageous aspects of the chosen syntax. We know it's an overloaded comment: that's literally one of the advantages.
Well, I've been unable to follow you as well, then. Obviously if they'd used a different type of syntax (e.g. using # for annotations), those would also be compatible with the language spec, and other implementations would still be just as capable of ignoring all unknown annotations.
(Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)
This is such a silly response when "You've gotten better at using them and know how to work around their flaws now." is right there and seems a lot more plausible.
That's how I learned a pretty important lesson about software engineering that still informs how I work to this day.
"A layer of abstraction on top of a stateful legacy system often doesn't result in a simpler system, it just introduces exciting new failure possibilities. This especially applies when the owners of the legacy system have no responsibility over the abstraction layer."
It's still true. Your metabolic system is probably not simpler after taking terzepatide. Although, just because it's not simpler doesn't mean it can't be better. I'm very glad for the C++ abstraction layer over assembly, even if the stack is more complicated than if it were just assembly
Manjaro sells itself as "Arch, but more approachable". In reality, you'll often end up with "Arch, but with additional weird package management upgrade issues that are a byproduct of Manjaro's own repositories interacting with the arch on your system."
Instead of just having to track the arch repos, you suddenly have those and Manjaro's own stuff (and own package manager tool etc.), which is another point of failure. Every new bit of technology is another part that can fail.
I think a lot of the really old school people don't care, but a lot of the younger people (especially those disillusioned with C++ and not fully enamored with Rust) are in fact quite happy for C to evolve and improve in conservative, simple ways (such as this one).
Imo it's better to approach Demon's Souls as an exploration puzzle game with RPG stuff and combat, not as an action RPG (such as Dark Souls 3).
reply