I like these AI threads with everyone's measurement of how good a model is starting with: "it feels like..." and that says a lot on how incapable we are to judge and compare these models.
Because Sony and all digital publishers with the exception of GOG are lying thieves. This is just another step in getting rid of ownership, and we are too naive and passive to stand up against it. Physical copies are a must to retain any sense of ownership over purchased games. If this is done, it must be forbidden to show "Purchase" on playstation store as that implies ownership,which it will never be. Also just look at the parallel issue that happened exactly these days with Sony deleting purchased movies from libraries. The same will happen with games. This is legalized theft.
I saw a photo of Destiny 2 for same at Walmart. First, game is Free-to-Play for years now, second version of a game that is on that disc cannot be played.
Tell me how does physical disc protect ownership? Then compare it to my digital downloads in steam where I can just copy game files between computers (if it's DRM-free)
> Also just look at the parallel issue that happened exactly these days with Sony deleting purchased movies from libraries. The same will happen with games.
I don't think Sony is much to blame here. They lost rights to distribute that content, so they can't distribute it. Blame copyright laws, not Sony.
How were they allowed to "sell" those titles in the first place then? Because it was never implied that access might be lost or restricted,it was very much sold to customers,not rented.
As for Destiny not working,this is a related but different problem, stopkillinggames tries to tackle it, but both issues go hand in hand.
1. If we give up physical copies,we lose ownership,as simple as that
2. Server side components must be released by the publisher once they take offline a game, as long as that game was "sold" to the customer
So ownership is a very important component in this, don't make it sound absurd.
My main argument is that I have more ownership of games that I have downloaded on PC (be it from steam, gog or that girl who is into fitness) than physical media on consoles.
> How were they allowed to "sell" those titles in the first place then? Because it was never implied that access might be lost or restricted,it was very much sold to customers,not rented.
I believe you are miscalculating the effect of skill atrophy, there is benefit and actual experience gained by doing the work yourself. You are an experienced dev and already have a lot of tools and knowledge under your belt so at the moment it is hard to see the actual issue, as this is just a productivity multiplierfor you. But give it a couple of years working under these conditions, your tech savvy nature will be severely diminished.
Indeed. I think it's a much bigger issue for juniors, who haven't yet had a chance to build that systems design muscle.
When an LLM is making a bad design decision but the engineer doesn't have the experience to spot it AND the consequences don't become apparent until much later (which is often the case) -- it's kinda hard to learn.
Agreed, I thought this is a wrapper for STL under Python, what does the py prefix stand for here actually?
As for the why c++ at all, as long as one falls into the "don't care" category, it works fine.. lately I found myself I rather build my apps in C with NODEFAULTLIB (under Windows at least), and creating my own size-optimized standard library which on Windows wraps the Win32 API wherever possible. The size savings are incredible, my executable is in the ~500KB range, ultra small and ultra fast. This is unattainable with normal modern C++.
Understood, yes, but I described my reasons in my reply to another comment already.
Your proposed solution is not equivalent to what I am doing, it cannot work on all the systems I support, and would never be as dependency free.
Even trivial stuff causes the linking to vcruntime, this is an extra dll dependency that I don't tolerate, no msvcrt, no vcruntime, nothing except core Win32 dlls are allowed on the platform. Static linking can relieve some of this pain, but that bloats the binary. C++ simply does not allow the same level of minimalism that can be achieved by C, and for many these are unimportant details, for me they are deal breakers and this is a core pillar of my architecture.
First of all VC++ isn't the only C++ compiler on Windows, as it isn't like UNIX with the one true compiler original approach, secondly there are ways with the compiler and linker flags.
I have been avoiding C as much as possible since 1992, starting with Turbo C++ for MS-DOS.
Sure, just to clarify, I am not arguing that c++ doesn't work, only that c++ produced binaries are either having more dll dependencies, or are more bloated (in size).
I also tried clang-cl and MingW, and while both work, the binaries produced by them are even larger then any MSVC produced (regardless of how I try to optimize it). C is a winner when it comes to binary size.
Yes, I am building GUI apps. This "standard library" of mine is built from the ground up in a cross platform manner, such that it compiles on Windows wrapping Win32, with Windows 95 being the CI machine, making sure it works on the whole Windows family upwards, and it wraps POSIX under Linux/MacOS/any POSIX system. The goal being to reuse the available shared library dependencies that are always present on these platforms anyway, giving me these ultra small binaries.
For the last couple of years I got into retro computing, realized how much more I enjoyed the 9x era Windows systems compared to anything that came later, and made it a personal goal that if I build anything, it will have to work on Windows 95 as well. I realize the actual number of 9x users would be really small, but they still exist, e.g. seeing the vogons community, they are still using lots of such apps and would value support.
But they haven't been good performers, and don't deserve joining s&p, and that is the point, do not make exceptions just because Elon Musk or whatever delusional billionaire says so.
reply