Yes, absolutely. How is that even relevant? Are you implying that it's acceptable to violate the rule of law when the government makes a mistake? Do you shoot your mailman when they mis-deliver a letter?
The reasoning is not circular, full stop. Just because the government both (1) deals in licenses and (2) can be sued in court does not make the situation logically inconsistent. You're confusing collusion/corruption for circular logic.
I don't see an objective reason this is more or less clear than
sqrt(sqr(b) - 4 * a * c)
or
(sqrt (- (sqr b) (* 4 a c))
Honestly, by objective measures the traditional style is probably the worst. The Forth style makes it easy to see large stacks because you'll see long sequences of literals. The sexp style makes it easier to work with subexpressions. Both the Forth and sexp style don't require remembering PEMDAS. The sexp style is easier to parse, and the Forth style doesn't even need a parser.
The only thing going for the traditional style is that it is an ugly approximation of mathematical notation - but that notation itself loses most of its value in the uglifying.
This is just a "minor usability issue". Seriously. In Factor, you can solve this with references to local variables, which under the covers manipulate the stack as needed. It can also typecheck, so you wouldn't be able to write the expression in a way which unbalances the stack.
Or you can just select to hold that package for updates in a package manager in a competent distro that actually gets needed security and usability updates.
Doesn't help that some ""stable"" packages are outright broken and won't be fixed until the next release (ie. MinGW is stuck on a broken version of 8.3 which has a buttload of compiler bugs I keep hitting)
That's fairly rude to the guy, and doesn't make your point any stronger.
I've worked with exceptions before, it leads to try/catch spaghetti code.
You can't possibly know instantly all the exceptions to handle for a function (given it calls other functions w/ exceptions), whereas, if it returns a fixed bunch of error codes, then you can know why that specific function failed and handle appropriately.
Doesn't help that (language) exceptions typically have awful codegen.
> You can't possibly know instantly all the exceptions to handle for a function (given it calls other functions w/ exceptions),
You also can't possibly know all error codes to handle for a function if it calls other functions returning error codes, unless a type system enforces that for you. In which case you should compare to a language where the type system enforces that all exceptions are handled.
I can make the same argument for exceptions - You're not documenting correctly. You also have the choice to ignore and fail with exceptions.
Example: you have a method which requests a file from disk, but it fails to load for some reason. With error codes, you force all callers of your resource loader to explicitly handle the failure case at the point of failure, or you lose all context on the error. If you just bubble the error up, you're manually doing exceptions.
With exceptions, the code that requests a file can assume it succeeds if it doesn't have enough context to handle the erorr, and you can handle at a higher level and still know what happened.
> You can't possibly know instantly all the exceptions to handle for a function (given it calls other functions w/ exceptions), whereas, if it returns a fixed bunch of error codes, then you can know why that specific function failed and handle appropriately.
presume that, despite not being able to know all exceptions to handle in advance, you somehow have knowledge of all error conditions in the event that you're using error codes?
> presume that, despite not being able to know all exceptions to handle in advance, you somehow have knowledge of all error conditions in the event that you're using error codes?
I guess that it is indeed the case. If you call one function, you can read the documentation of said function and read about its return values, including error codes. This specification cannot not change if one of the libraries nested deep within this function is replaced. However, with exceptions, if you use a new implementation of a deeply nested function it may raise a new exception that nobody was aware of at the time of writing the outermost functions.
Usually documentation tends to have this, or you can look at the function and immediately know what it will return, whereas with exceptions any passthrough errors are transparent.
Possibly a reaction to Valve and Discord's recent announcement of similar (more fully featured) releases. But I may well be wrong, and this was planned for a while, with a sturdy roadmap and a MVP release.
Or it's a late-ish reaction to the drama[0] surrounding Unity's "sudden" blocking of Improbable's SpatialOS cloud platform (if you believe Improbable - Unity said they were warned months in advance, Improbable said it was without warning). Then, within a couple days, Unity made an announcement[1] for their own paid cloud gaming plugin. It was all over HackerNews[2] in January when it happened with lots of commenters quipping that it's time to move to Unreal or GoDot Engine. During these days of back-and-forth drama between Improbable and Unity, Tim Sweeney from Unreal Games jumped into the fray and was tweeting his constant disapproval (and further muddying the waters with inaccurate information), at the end of which "Epic Games and Improbable announced the establishment of a US $25m fund to help concerned Unity customers shift their games over to Epic's Unreal Engine."
I'm still waiting to hear how they plan to fund devs but after following Tim Sweeney's recent behavior (i.e. the tweets above, plus paying Coffee Stain Studios to move their upcoming and popular (at least on Reddit) game "Satisfactory" off of Steam and do an exclusivity deal with Epic Games Store, which has caused nothing but bad press on Reddit), I would expect this fund will be nothing more than vouchers to use the paid-version of Unreal Engine for a limited time period, after which you will hopefully be reliant and forced to continue payment. Only time will tell I suppose. And competition is always a good thing.
