megrimlock

> giving folks the ability to wait-and-see for years, with zero risk, before pulling the trigger isn't really fair

Isn't that what an option represents? The freedom to choose later is the inherent value of the option.

And that value isn't acquired risk free: it's compensation for putting time in in lieu of salary.

Perhaps there's room for a rust equivalent of cdecl, a tool to map rust to plain English descriptions, offering a gradual onramp to the syntax.

This kind of thing seems silly to experts but could raise the rate at which folks make it through language learning funnel.

That Niko's text-arrow lifetime annotations are so helpful here suggests a rust IDE could offer similar highlighting or annotations to explain borrow checker errors.

One of the ergonomic hurdles to rust adoption by experienced C++ users is that the language looks similar enough that such people may think they fully understand the semantics even before they've fully internalized all the details. It's a tricky zone when something feels familiar enough that you don't realize the remaining mistakes in your conceptualization.

You are not alone. If you look at the "target retirement date" funds Vanguard etc. run you'll see that by the time the target date is 5-10 years out they have shifted largely to bonds to provide defined income.

Anything with low-effort access will always connote little value in people's minds because endless alternatives exist. Anyone who wants to get paid for doing something hard should avoid channels like that, or only use them to float associated freebie products that can introduce people to the real product.

Thankfully the executive health plan has 100% coverage so the dna regen and orbital massage treatments are gratis. It's the little things.

> If you could point me to a single bank president who says

Why do you think they would say what their true goals are to you? People in positions of power are extremely judicious and strategic about what they say and to whom. They get daily exercise in this and only the best survive. The most effective are excellent at pursuing their goals while maintaining a socially credible exterior. The less effective use coded language (corpspeak or political rhetoric) to try to hedge through via indirection.

Anyone know what they mean by an "inverse modulo" algorithm? That only seems meaningful for numbers coprime to the sensor ceiling value.

You can approximate low frequency light fields with a suitable distribution of virtual point lights.

Neat stuff. It's worth noting that shadow rays don't entirely avoid precision issues either. You still need to handle self-intersections. One option is to add a bias epsilon (which introduces other artifacts, depending on the scale); another is to reject local self-shadowing (which means you can't get finely shadowed surface cracks); another is to give artists explicit control over which sets of objects shadow which others (which adds artist time). Offline rendered movies use all of these.

A suggestion. Your comment reads as though you wrote your own press release to then take issue with. Mis-quoting them with hyperbole for emphasis is less persuasive than directly addressing what they actually wrote.

For a reference point on how far this tech has come: https://en.wikipedia.org/wiki/Soviet_laser_pistol

Makes sense. I didn't realize the problem description was for a game that would be played repeatedly with the same opponent -- i.e. one where you can gather information. If we were doing this in person instead of on a internet forum and async post/response we'd probably iron that out quickly. Thanks for elaborating.

Ok, I'm stumped. If I've parsed your description correctly, we get no info about our opponent's actions or the results until the end. Absent any ability to observe their strategy, it seems like you do want to maximize for expected value of your own actions, and I'm curious about the counterexample.

How do we maximize EV? A single throw's pdf is 1, for x in [0,1], so its EV is 0.5. The question is how to improve on a single throw by deciding to re-throw. A re-throw is independent and gives the same EV. We want a strategy that gives us higher cumulative EV. Say our strategy is that we have a threshold A, where we re-throw any result below A. Because x is uniform, the probability that we re-throw is also A. The cumulative EV of the strategy is A * EV(second_throw) + (1-A) * EV(keep_first_throw). Since we only keep the first throw for results in [A,1], the EV for that event (integrating x * pdf from A to 1) is (1+A)/2. So EV of the whole strategy is A/2 + (1-A) * (1+A)/2. It has max EV when A is 0.5, giving EV of 5/8.

So how do you do better?

Old unit testing habits compelled me to txt a photo that already has a mustache. Result? Better mustache. Test passed.

It feels pretty grand to consider the prospect of no longer having to debug crashes due to expired QTreeViewItem pointers, or spending time counseling junior team members to check for expired weak pointers.

Qt is excellent for its epoch, but if you've read the source you will know that we should not treat it as sacrosanct. Algebraic types and explicit lifetime declarations and macro syntax extensions could all do wonders for it.

Agreed. I'd also make an analogy to C++ where you sometimes must hop between std::string and char*'s with ambiguous lifetimes. Not to mention various custom string types that any big app will have (ex. one that internally exploits jemalloc's allocator optimizations (i.e. exposing block overages), or does rope-style allocation, or intern's into a shared table, or whatever).

The history of gamedev (in particular) eschewing C++ for years until the consensus flipped gives me hope that something similar might happen here. The strings thing may take a similar path to so many aspects of C++ -- where it took years of folks like Scott Meyers and Josuttis and Herb Sutter and Alexandrescu talking through the details and rationale before enough people grew to like the decisions C++ made. Think of how many C++ programmers had to get their head around (say) RAII -- it probably first seemed horribly odd and weird, and now it's seen as a fundamental reason why it's a great language.

Agreed -- I've found these pearls of received wisdom often crumble on non-trivial projects. "Premature optimization" can lead some to defer thinking about performance at all. "Profile and fix the hotspots" without simultaneously thinking about architecture can yield a mass of uniformly slow branchy code with no path forward. It's hard to appreciate until you've been there. However, I do have faith that mozilla folks have most certainly been there and that those lessons inform the rust design.

Your observation reminded me of the Million Short search engine that skips past the first N ranked hits.

Is there a name for the phenomenon that the first entries in any contested ranking tend to be less interesting?

There's something about the ranking systems used on the web in the way they tally the nearly-effort-free actions of hordes (clicks, likes, upvotes, star ratings) that means they represent one kind of magnitude (statistical average impulse behavior) but very little of another (deeper reflection & significance). Deeper stuff tends to see less impulse attention and therefore sinks down the ranking, but is there some other way to identify it?

This api really needs to operate off an atomic snapshot, or at least return a timestamp of when monkeyness was observed, to avoid latency & synchronization issues. What if the monkey hands the phone off before the client code can continue execution?

"Framework" for some has the connotation of being dogmatically prescriptive: a monolithic culture of libraries where you must buy into the whole system to use any of it. For example, a classical C++ framework might come with its own string class, its own container classes, its own smart pointers, its own way of binding to other languages, etc. Escaping the cultural ecosystem to integrate something external can be quite a burden.

A middle ground is where you try to factor out useful parts but do so in a way that keeps in mind that users might not want to also use associated packages X, Y, and Z. This means backing off a bit from the maximally elegant integration you might do when you have a giant framework ecosystem and imagine people wanting to use all of it in its glory.

Doing this requires resisting the inclination to build a code empire -- a megalomania that anyone ambitious among us has felt as your excitement at being able to build more complex things grows. You only learn the opposite instinct after being burned suitably by frameworks, or looking upon your own empire and despairing.

I have done it and it's not bad. Well worth the trouble and makes a 2008 feel like a new machine. There are detailed tutorials online with pics and everything you need.

For some reason this resembles the issues you get with numerical precision when doing things like ray tracing with shadow maps, or Z-figthing in depth buffers, or guessing prices on Price Is Right.

Here each processor is trying to achieve a market position relative to their competitors almost as an epsilon. They want to be seen as cheaper but no cheaper than necessary, and they want to retain simple terms. That drives them to tweak the 1st and 2nd order terms (constant + a scale factor).

That's a clever idea. Apple absolutely makes use of Open Source, but only when it makes strategic sense, not out of idealism. (Examples: BSD->OSX, khtml->WebKit, LLVM.) In this case Apple needs a way to massively upgrade the quality of their data-set (they still have fundamental errors right in San Francisco! presumably Cupertino near 1 Infinite Loop is sorted by now). They do not want to be in the business of cultivating a gigantic geographic database, so aligning themselves with the many others out there who would like access too a Google Maps quality db is quite clever. They would have to think carefully about how to present this, to make it clear the data is not theirs, in case there are any horrendous gaffes in it.

Computational complexity theory tries to find equivalence classes of problems that can map to one another. Each class has a primary representative such as TSP (travelling salesman problem) or 3-SAT that memorably capture the essence of the class. While it's not clear that you can map Grand Theft Auto to anything useful, you might be onto something here: Imagine a mechanical turk system where the grunt tasks are remapped onto inherently enjoyable gameplay scenarios. It would be an arbitrage play between turk vendors needing menial tasks done, and players needing entertainment. Recaptcha is a (brilliant) example, but I don't know of others. Maybe UAV control might be one. (Note that mapping one valuable task to another enjoyable task is a different idea than the "gamification" fad of inventing events to adorn with tawdry badges.)

One reason I've seen these projects (take an existing system and make it work well) fail to gain traction is an unstated lack of faith in the people pushing for refactoring. In my experience this often comes from others having been burned by their prior proposed projects, where they've wasted 6 months doing self-indulgent refactoring that went nowhere or introduced bugs or made it hard for the rest of the team to contribute because of a bunch of new abstractions "to make the system flexible and generalized". The same people who care about code quality enough to argue for a cleanup project sometimes go overboard and burn their credibility. Unfortunately the right mix of judgment is hard to evaluate in any sense that isn't super-context-dependent.

Does the color coding indicate anything?

There is something deep about software that thwarts our dreams of making it re-usable, and makes debates about what primitives to put into the stdlib difficult. For one thing, it seems like we should be able to collectively determine a DAG of concepts, starting from simplest primitives and progressively building up derived concepts, like the tech tree in a game like Civilization, or Principia Mathematica. But that tree is so vast, and the most-useful points so sparse along it (ex: I don't think anyone's asking for Church numerals in their stdlib) that we end up debating which are the most-useful derived concepts to surface. Moreover, there's no language or compiler that is sufficiently smart to efficiently map all those concepts to the hardware we have, we instead go with expertly-wrought implementations.

To take this example, you _could_ count enumerations and permutations by passing a range(n) list to itertools and then counting how many actual results you get back, but that's silly when you could also just use the binomial theorem to get there directly. A compiler that could generally perform such transformations would be miraculous -- well beyond the territory of automated proof assistants like mathematica or gcc -O3 that trundle along cultivated routes of expert system rules, into the realm of actually discovering deep linkages at the frontier of our knowledge.

Until then it seems like stdlibs will just fracture along lines of strain among the userbase. Presumably, most Python users don't need anything beyond what a financial calculator would provide, and anyone else should head to numpy.

Put differently, you want the functions that count the number of permutations and combinations possible, not functions that yield/generate the actual permutations and combinations.