Yeah, hard to see how better this is than Gradle. If anything, it's worse by the mere fact this is Scala, but it's really so incredibly verbose to accomplish basic tasks such as upload to Sonatype.
making it easier to generate maven poms I thought was a reasonable idea 18 years ago but gradle and other tools all went down the "making the build Turing complete" path.
Actions compose, types (generally) don’t. So Monad X and Monad Y may not make a valid Monad Z, but Kleisi composition very much exists for actions within a monad.
But the whole promise of monads is precisely that they are a type that can compose.
It basically allows you to pipe successive function calls returning different types by lifting these types into a monad.
Don't get me wrong, that promise is very powerful and in the rare few cases where it works, it unlocks beautiful composition, but the simple truth is that monads are really not that useful outside of Haskell (and I'd say, it's even questionable within).
Not really. COM/OLE is a different paradigm, their answer to an infamous vaporware called Taligent/OpenDoc that bankrupted many developers. Microsoft was sort of stuck with that security nightmare though
"COM" by itself is a rather broad umbrella. What you're describing seems to be OLE Automation. That's the one that has type libraries (which you need for discoverability).
And then Active Scripting was supposed to be how you'd script those endpoints...
That's an extremely naive take that shows some stark ignorance of the tech and market forces at work.
From a tech standpoint, Denuvo negatively impacting performance has been debunked many times over (see my previous post about that).
On the economical side, you need to realize that whenever you are playing and enjoying a game, it's most likely due to the fact that the previous games sold by that developer have been successful in making money, which was most likely made possible by Denuvo.
In other words, making piracy harder allows the next generation of games to be created.
> On the economical side, you need to realize that whenever you are playing and enjoying a game, it's most likely due to the fact that the previous games sold by that developer have been successful in making money, which was most likely made possible by Denuvo.
>
> In other words, making piracy harder allows the next generation of games to be created.
That's an extremely bold claim. There are many games which are successful and don't use Denuvo. In fact I'm quite sure there are more successful games that don't use Denuvo, then those which use it - so I don't believe that "whenever [I'm] playing and enjoying a game" it was "most likely" created thanks to Denuvo.
And then there are people like me who simply refuse to play any game which uses Denuvo. There are thousands of excellent games out there, why should I waste time on those which treat me as a thief?
> I don't believe that "whenever [I'm] playing and enjoying a game" it was "most likely" created thanks to Denuvo
I never made that claim, please reread what I wrote, but here is my point again.
When you play a game from a publisher, they were able to create it because their previous games sold well. Therefore, anything that allows games to sell well is a positive for the entire gaming community, creators and players.
Denuvo is an important part of this picture, but it's obviously not the only one.
> And then there are people like me who simply refuse to play any game which uses Denuvo. There are thousands of excellent games out there, why should I waste time on those which treat me as a thief?
That's great, and I do that as well. And this is one of the reasons why Denuvo is not anti-user: everyone has the choice to not support it.
It's the truth standpoint. DRM is an overreaching preemptive policing, i.e. by its mere definition it's always aimed against the user, therefore it's always an anti-feature.
Things like fourth amendment exist for a simple reason that overreaching policing skews into being abusive. Police could always argue abusive policing "helps prevent crime" same as copyright maximalists could argue DRM "helps prevent piracy". But both would be invalid due to overreaching nature or such policing.
To put this concept into perspective. DRM runs on your personal device, in your personal digital space, for the benefit of someone who tries to police you, treating you as an a priory criminal. So conceptually it's not any better than what fourth amendment is aimed to prevent.
Excusing such concepts with "market forces" is simply cringe.
> by its mere definition it's always aimed against the user, therefore it's always an anti-feature.
Describing it as "anti user" is theoretically correct but practically incorrect. It's true that it might prevent mods and possible future uses if the servers go down, but in practice, users don't care, as is demonstrated by the fact that games that contain Denuvo routinely sell in the millions and users have no idea it's even there, and they will never know.
Overreaching?
I don't know. Companies put out a product, you're free not to buy it if you don't like it. That's one of the reasons why I call this natural market forces.
> So conceptually it's not any better than what fourth amendment is aimed to prevent.
That's a gross exaggeration. The Fourth amendment is about unreasonable searches by the government, I completely fail to see how willingly buying a digital product from non governmental organizations is connected to Fourth amendment in any rational way.
Again, at the end of the day, nobody forces you to buy that product, hence "natural market forces".
The fact that millions of these games are being bought every month tells me users don't feel that whatever flaws, perceived or real, Denuvo has matters less to them than playing these games.
Policing by some corpo isn't better than policing by the government. The basis of why overreaching policing is bad doesn't depend on it. Compare DRM to someone installing surveillance in your house to preemptively "stop any potential crimes" ... namely, by you. Are you going to be OK with that just because it's some corpo doing it and not the government?
You get the point of why the above is wrong. DRM is wrong exactly for the same reason. The ethical problem with DRM is that it invades your digital privacy based on presumption of guilt.
Whether users care or don't care doesn't really affect the concept. A lot of things in digital space are less tangible for people to care becasue they are clueless, which doesn't mean these things aren't as dangerous and damaging when abused.
And those are fundamental problems, before we even get to bad consequences that you mentioned, like DRM damaging digital preservation, losing access to your purchases and so on, which are bad too, but not on the level the above is bad.
So to sum it up, DRM is always anti user in many senses.
> Are you going to be OK with that just because it's some corpo doing it and not the government?
If I willingly let them in my home and I knew they were going to do that? I don't really have the option to complain, do I?
Your analogy doesn't make sense. People buy the game, Denuvo is clearly advertised on it. They have the option to not buy the game. Period. It's not overreach if I willingly accepted the reach.
> So to sum it up, DRM is always anti user in many senses.
How do you reconcile this claim with the fact that Denuvo games sell by the millions every month?
> The industry will take whatever steps it needs to protect itself and protect its revenue streams ... It will not lose that revenue stream, no matter what ... Sony is going to take aggressive steps to stop this. We will develop technology that transcends the individual user. We will firewall Napster at source – we will block it at your cable company. We will block it at your phone company. We will block it at your ISP. We will firewall it at your PC ... These strategies are being aggressively pursued because there is simply too much at stake.
Note the repeated usage of "your" which increasingly creeps into user's private digital space. Being in denial about this isn't an excuse for these problems.
A lot of that verbiage is absurd exaggerations and most of these things never became true.
> Being in denial about this isn't an excuse for these problems.
I'm not in denial, I know exactly what Denuvo entails. Whenever I buy a game with Denuvo (which pretty much never happens any more), I know exactly what I'm giving away, and I'm doing so because I'm getting something in return.
Similar situation to someone dropping their business card in a jar at the exit of a restaurant with the hope they'll win a free meal. They give a bit of personal information because they think they'll receive more in return.
You don't get to take away the choice of customers to decide how to manage their information.
As long as everyone is free to make that choice, nobody is getting hurt and the market forces will ultimately land on an equilibrium, like we have today.
They express the intent behind DRM very precisely. I don't see anything about it being an exaggeration. DRM proponents will try to control as much as they can grab. There is no excuse for unethical garbage like that.
I don't understand why there are people always defending denuvo every time it comes up. Are you associated with denuvo directly or indirectly? Are you an ordinary gamer but for some reason post falsities to try to look superior?
> If a function fails, then you need to handle its failure
And this is exactly where Go fails, because it allows you
to completely ignore the error, which will lead to a crash.
I'm a bit baffled that you correctly identified that this is a requirement to produce robust software and yet, you like Go's error handling approach...
On every project I ship I require golangci-lint to pass to allow merge, which forces you to explicitly handle or ignore errors. It forbids implicitly ignoring errors.
Note that ignoring errors doesn't necessarily lead ti a crash; there are plenty of functions where an error won't ever happen in practice, either because preconditions are checked by the program before the function call or because the function's implementation has changed and the error return is vestigal.
Pedantically, every single one of those examples are a case of unspecified behaviour, not bugs. There may be no meaningful difference to the end user, but there is a big difference from a developer perspective. Can we find cases of the same where behaviour was specified?
We see:
Camel case Snake case Mix of camel case and snake case whatever that is