Rust's library documentation has this feature as well; each item has a [src] link that takes you straight to the code being documented; see for instance [0], and you'll find the link to the right side of the heading. This even works for crates not in the standard library because it's actually a feature provided by rustdoc, the standard documentation generator; for example, you can get to the source for functions in serde (the most popular Rust serialization library) directly from its documentation [1].
The thing that kept me from trying Ada (back a couple of years ago when I was writing firmware and so was kind of on its home turf) was a lack of good resources for learning it. I got a copy of the book "Programming in Ada" by Barnes, and did not find it very helpful. Often the advice seems to be to go read the Reference Manual, which I agree is highly readable for a language standard, but it's not aimed at users of the language. If anyone here has any other resources to recommend, I'd be happy to hear about them.
Unless I misunderstand their test code, the article says they could reproduce the problem using an array of 67108864 Integer objects. That doesn't sound like an impossible amount of memory.
It's also noted in the relevant thread on the Python mailing list[1], which also says that this is different from Java with regards to whether or not it can be triggered:
"Since it's impossible to trigger the error on any current machine anyway (no machine has enough memory), increasing the size of the stack would be absurd. If you read the paper, they note that this is what the Java folks first did (they changed this part of timsort in a way that _did_ make it possible to provoke the stack overflow on current hardware)."
To clarify the above, new API's introduced since around Vista are more likely to be COM (and WinRT is of course entirely COM when used from C++), but the existing C API's have not been replaced, and some new C functions have been added since then as well.
The only items I have in that sharing menu are e-mail, which clearly there would be no need for this service if that were good enough, OneNote, which makes no sense, and advertisements for Store apps that I don't want to use. I think it's safe enough to say that menu does not replace a service like this.
The problem with that is Windows' lack of apps. The UX is better and will be consistent regardless of if you're sharing from an app, File Explorer, or file picker.
Console dev kits for major platforms never included game engines, and the primitives included with older console dev kits, if any, were often ignored because more custom versions were required to get the desired performance.
What's happened to the console ecosystem is a whole bunch of different things. More accessible tools (e.g. Unity) and platform holder development programs have gotten more developers who are less experienced and not as well funded onto the console platforms. Availability of easy online patching has lead to physical releases, which have to be finalized months before the actual release date, being intentionally left incomplete, with gaps to be filled in by a release day patch. Changing technology cycles have made console generations blurrier. And yes, online DRM has become a thing, although I'm not sure that's quite as onerous in practice as you suggest; it's not like current consoles just refuse to run any games while offline.
That's not an exhaustive list. The appeal of consoles is what it has always been, they're still the easiest and cheapest way into modern video games. But it's true that some of the advantages over the PC platform have begun to erode.
Let me see if I understand this argument (with the awareness that you are attempting to restate it and not directly advocate it yourself).
When someone is being subjected to abuse in what is supposed to be a professional setting, the correct strategy for them is to take matters into their own hands and probably begin a disruptive and draining conflict which they are almost certain to lose in the end because the deck is stacked against them. Under absolutely no circumstances should the victim ask for assistance, because that would demonstrate weakness and a lack of self-respect. If only the victim had better strength of character, they could put those assholes in their places and nothing like this would ever happen again.
I really don't think I can make myself see the world that way. I don't think I want to.
Indeed, and in the larger context it's a contradictory set of advice.
If she struggles, it'll be a "poor culture fit." At-will employment means it's very challenging to push back against your boss's toxic culture. But if she doesn't, she isn't "strong enough" for the industry.
Actally madsax, reading your post you make a pretty strong case for never asking for help.
> By dragging in HR, parents or the state you are cultivating a draconian environment where nobody at the job will respect her and she will never respect them, no matter how much they eschew sexism
You say here that if at any point any authority figure (which you curiously include "parents" in the list of) is involved it will disqualify the subject of these treatments any hope of future respect. To name the torment as such is to condemn yourself to it.
I'm starting to think you may be using the phrase "strawman" in the more popular counter-factual sense than have a grasp of how the word is historically used. Because it sure seems here like you're saying, "Never go to an authority or appeal to the rules a group establishes because if you do, you forfeit all respect in perpetuity."
Maybe you didn't mean to say that. Maybe this didn't read like you intended it to. But it's not fair that you call foul on us for reading what you wrote and interpreting it within the scope you defined.
Game engine vendors also care a great deal about iOS, since they have a large number of customers who do, so that's also driving support for Metal in those engines.
[0] https://doc.rust-lang.org/std/vec/struct.Vec.html#method.tru...
[1] https://docs.serde.rs/serde_json/ser/fn.to_string_pretty.htm...