sure they use it, but I sort of feel the groups that use it and JavaScript are no longer likely to cross over each other, and thus new devs will not be making the historical mistake of rhetorical misunderstanding that was made in the old days.
Sorry but that comparison is nonsense. Potato chips are just fried slices of potato. How would you squeeze 6-8 medium potatoes (each weighing 5-10oz according to top Google result for "average medium sized potato weight") into a 7.5oz bag.
I used to feel this way but having installed Ubuntu on a friend's old laptop for him, it's crazy the amount of stuff you forget you do because it's second nature. I certainly think it's too far to say "absurd".
Not true, not sure why GP said that. Been writing Rust for many years and code does not just break on compiler upgrades. Super stable overall, including the wonderfully evolving ecosystem!
No, I believe you are forgetting the context. Big O is a upper bound on the growth rate of a function. In this case the function describes the time taken, therefore a higher time is a "worse case". So Big O is, in this scenario, a bound on the worst case time taken (essentially what the commenter said).
Certainly as I understand it your definition of Big O is incorrect - it provides exclusively an upper bound. Big Omega is used for a lower bound and Big Theta for an upper and lower bound.
Math definition goes something like this: f(n)=O(g(n)), if exists C such that f(n) < C x g(n), when n goes to infinity.
Function “quickSortExecutionTime(permutation)” depends on exact input (each permutation/shuffle has different exec time), parameter “permutation” can not go to infinity, so it can’t be used with O(n) directly. (Parameter need to be single real number)
QuickSortWorstCaseTime(n) is single valued function thus, it can be used with O(n) notation. Same is true for quickSortAvgCaseTime(n) and quickSortBestCaseTime(n).
But you answered my question. (Very indirect “Yes” :) )
It's true that in the case of a sorting algorithm it's not immediately obvious how to analyse the time complexity with Big O. However, I feel that you may be getting bogged down in semantics.
Perhaps it is accurate to say that when Big O is used to describe the time complexity of a function in computer science the variable n in O(f(n)) usually describes the size of the input, which may not be common knowledge. But if the question is:
> Have programmers redefined O to specifically mean worst case?
Then in general I would say no. I suppose to answer more concretely I would have to ask: "Which programmers?"
As someone who's worked quite a bit with both, no. I have hopes for Godot but in terms of actually shipping commercially-viable games, it's not even in the same league as Unity. This comes from many things, but some of the big ones are:
* Ability to do first-party console ports
* 3D rendering fidelity and speed
* Asset store quality & quantity
* Robustness & stability - they both have tons of bugs but with Unity there is almost always a way around the bug, due to the decades of commercial games that paved the path before you.
For one quick example, Godot's physics engine is well-known to be poor, both in terms of performance and in terms of accuracy/stability. It has tons of bugs, tunneling, jittering, etc. Both the 2D and 3D physics engines in Godot are currently slated to be ripped out & replaced with external ones of higher quality (Box2D and Jolt). But currently, that hasn't happened, so one of the foundational parts of most games - physics - is guaranteed to be broken to some degree in a Godot game.
I adore Godot and have been learning it on my own time, but it's just not there for XR stuff yet, our current project has the Vision Pro as a target, for instance, and Unity is really the only option there. Apple's native tools (Reality Composer Pro) are just abysmal.
But yes, all of my personal projects are in Godot now, and I'm planning to use it for some tooling at work, just because it's UI system is nicer than Unity's as well as it having better support for re-using editor UI components in an application.
I’ll add folks with a history of causing damage. It seems to be a habit with a few, but it can be impossible (or unclear if possible) to even ask the question under some new regulations.
Some landlords solve this by making the tenant pay the insurance on the rental. That way high risk groups get higher effective rent without the landlord having to look discriminatory.
People with a criminal record and/or history of nonpayment of rent (aka squatting) who you're forced to rent to under first come first serve ordinances.
I am also skeptical of any overly pessimistic alien interaction theories, but I don't think this analogy applies here. We already have open communication channels and centuries of trust between the British and French, and we certainly did pillage each other before we figured out how to speak to each other.
If you don't want to use the "artificial, unintuitive interface" (bit rude IMO) you could just google "best mario kart setup".
The selection of attributes is not exactly arbitrary. AFAIK speed has always been by far the dominant stat in mario kart, then acceleration. Choosing e.g. better handling at the expense of speed is an immediate disadvantage. If your problem is that this doesn't help you to choose atteibutes in the general case, take it up with the chaos of the natural world...
This article solves a problem people have (not knowing what setup to pick) in a very stylish way (subjective) and teaches the reader something along the way (what a Pareto frontier is).
Not a particularly constructive comment if you ask me.
Just because the selection is "correct" (e.g. gives best results in practice) doesn't mean it's not arbitrary.
The article starts with the premise and fails to deliver. The visual layer of the article is nice. But ultimately the example of using the Pareto's frontier is a FAIL because it doesn't deliver on its promise of finding the best kart setup.
Panic is a perfectly proper way for a well-built program to stop execution.
There is no point in juggling around Result types if a failure means that you can not recover/continue execution. That is in fact exactly what panic! is intended for [1].
A failure to write to stdout should not be unexpected given that stdout is routinely redirected to files or to pipes, both of which can be suddenly closed or otherwise fail from the other direction. Yes, you can't recover in this case, but you should at least properly report the error to stderr before exiting, in a way that lets the end user (rather than app dev) properly diagnose the error.
Now if you fail to write to stderr, yeah, that's a good reason for a console app to panic. The onus is on the user to provide something that is "good enough" in that case.
IMO the real problem is that print() etc defaults to stdout historically, but is used mostly for diagnostic information rather than actual output in practice, so it should really go to stderr instead. This would also take care of various issues with buffering etc.
Woah woah woah let's not get hasty. We can have panicking and nonpanicking versions of the API (at least until somebody builds the nonpanicking version of Rust, that will be great). The panicking version is for quick, off-the-cuff usage, and the nonpanicking one for production use.
There's value in the Hello, World and println-debugging style print, even if it should be eschewed in most general contexts.
I didn't say that there isn't value in "hello world" or println-debugging style print. The point is that both should go to stderr rather than stdout (and then panic if they fail). But for stdout, which is the channel for output and not for logging, the default should be to require error handling.
Consider something as trivial as `cat foo >readonly_file` to see why.
Panic is perfectly fine in certain cases, but it's absolutely not a general error-handling mechanism for Good Programs (TM). (Some contexts excluded, horses for courses and all that)
You can and should recover from bog standard IO failures in production code, and in any case you'd better not be panicking in library code without making it really clear that it's justified in the docs.
If your app crashes in flames on predictable issues it's not a good sign that it handles the unpredictable ones very well.
