I love my Steam Deck aside from the quality control issues I ran into, one of which required an RMA. It's really hard to justify $1000 for it when the Switch 2 is $450 (soon $500).
I do think there's a bright future for PC handhelds, especially when (not if) ARM processors can be utilized. I'm less sure about that if prices keep rising since that quickly becomes the difference between niche hobbyist device and mainstream gaming portable.
> It's really hard to justify $1000 for it when the Switch 2 is $450
For someone without an existing library, sure, but if you have a massive existing Nintendo/Switch1 or Steam library, that's going to drive your decision making far more than the price tag.
I think that's a factor for sure, but is less important (generally) as the price gap increases. The Steam Deck also has a disadvantage in that only some of your existing library will be playable on the device.
There's definitely a price point for some where it will make sense to rebuild your library on the Switch vs pay the higher cost of a Deck.
The nice thing about the Switch 2 is you can find a plethora of games at your local library (if you have one, that is). That's essentially how my wife played 20+ games with her Switch 1.
> It's really hard to justify $1000 for it when the Switch 2 is $450 (soon $500).
I had a Nintendo Switch 1 and sold it. My wife wanted to play the latest Pokemon release, she did for 2 months, then it sat unused for 3 years in its charging deck.
If you like some titles that Nintendo has to offer, then sure (I never understood the appeal of the Zelda saga for instance).
If you want a portable PC optimized for gaming with a huge library and where you can also do anything else you want, including modding it, 1000$ is still a bargain for what it offers. EDIT: and the library will keep expanding as Proton keeps maturing.
Android handhelds (e.g. AYN Thor, Odin 3, Retroid Pocket 6) have been becoming more and more useful for PC gaming via apps like GameNative and GameHub. See for example, Elden Ring: https://youtu.be/GlzMkqFmKjo?si=w9q-j2ntt154b0--&t=621
You can buy a Macbook Air for that price. It doesn't make sense to buy it at that price.
I bought an original LCD Steam Deck and wouldn't purchase one if it was that price. This is great news for the Switch, but the Ally X would be the only other viable option right now (~$650)
The question is how long Apple will be able to maintain those prices, given the run for memory that there is. Someone is making a lot less money selling to apple than elsewhere, and while the long term contracts are worth a lot in stability, there's a limit to it. Not everyone gets hit equally by a demand shock, but nobody is immune.
There's definitely a number of reasons, but I vividly remember _struggling_ with Ember data at the time. The framework itself was already complicated and the data management story felt immature and rigid in addition to complex. That definitely pushed me towards and a number of others towards backbone and eventually React.
> The best part about blog feeds? It's just an idea. There's no central authority. There's no platform.
I think this is blessing _and_ a curse. I had an idea that I built a while back that centralizes RSS feeds so you get the centralized benefits of social media while authors can own and control their own content.
If anyone's curious, I built it out here: https://onread.io but I never had the time to really share it out or push it beyond the SUPER basic MVP that it currently is. I was thinking about pivoting it more into a tool that I could turn into an RSS feed for myself, but I haven't found the time, really.
Either way, I don't think RSS feeds as-is are as useful as they once were, and social media still has significant value over feeds due to conversation, sharing of content to folks with similar taste and interests, etc.
That’s always made sense to me in theory, but practically speaking a lot of logical units of service just don’t scale independently of your core service. Obviously this isn’t always true but I think it’s too easy to talk yourself into popping off new services and once you’ve built out the infrastructure for it and the incidental complexity is costly.
I had the same thought when reading the article too. I assumed (and hoped) it was for the sake of the article because there’s a stark difference between idiomatic code and performance focused code.
Living and working in a large code base that only focuses on “performance code” by default sounds very frustrating and time consuming.
Great article, memoization is pretty complex and full of trade-offs. We recognized a lot of these same pitfalls as we worked through making memoization a consistent and common pattern in our (very large, monolithic Rails) codebase via a `memoize def...` helper. The `false` and `null` pitfall is _surprisingly_ common, enough that it (and other pitfalls) warranted us writing our own memoization DSL.
We took the opposite approach of most libraries though (and a reason we rolled our own instead of pulling in an existing gem) by avoiding handling the complex edge cases that hide trade-offs:
1. Class methods can't be memoized.
2. Methods with arguments can't be memoized (so no LRU caches, weak refs, tracking arguments, handling default args, hash/deep object equality, etc)
The thought at the time was that those more complex scenarios deserve more thought than "prefix it with `memoize`". It's been a few years since we introduced the helper and after seeing it all throughout our codebase with no issues I'm even more confident this was the correct decision.
I haven't revisited it in a while, but I'd love to add some extra niceties to it, like hooking into `ActiveRecord`s `#reload`, although I dislike memoizing in models.
You can use :memo in a method if you like, in a lambda expression, defmacro, macrolet, labels, ...: anywhere you have a lambda parameter list.
There is a predefined parameter macro called :key which implements keyword parameters. (Common-Lisp-like keyword parameters are not native to the language run-time at all: you have to use this param macro if you want them.)
Another predefined parameter macro called :match allows you to express a function with pattern matching. :match will take stock of your patterns and implicitly generate a parameter list which can take any of those patterns, and a function body which then further handles the cases.
This thread's context is large rails userbase around 2008'ish (people were changing computers from pcs to macs with textmate to do rails, perception of devs changed from nerds to cool kids - the whole thing was quite huge) that dissolved substantially. Crystal's syntax in this context feels like huge wasted/missed opportunity.
If we can’t have native macOS on the iPad this would be the next best thing. Imagine having Linux or macOS on the iPad that is treated like any other app (sans memory limits and etc.). You could have a full blown desktop at the ready when iPadOS isn’t up to the task.
The iPad could finally utilize the m1 processor to its fullest.
FWIW this is how it works on ChromeOS today. From the Linux terminal app (crostini lxc container) qemu launches macOS, Windows and Linux vms. They even support nested virtualization on my Framework Chromebook - so vms can run inside those vms.
I agree if Apple implemented virtualization on iPad/iPhone this same way it would be a huge for unlocking their full usefulness and capabilities while still maintaining host isolation/sandbox.
I think this may miss the point of the article, which is pointing out that you can get a lot of value for very little effort by using a timestamp instead of a boolean. I don't think it's intention is to replace a complete change history/audit log implementation, which would require a significant amount more time/effort to implement.
I do think there's a bright future for PC handhelds, especially when (not if) ARM processors can be utilized. I'm less sure about that if prices keep rising since that quickly becomes the difference between niche hobbyist device and mainstream gaming portable.