andrewprock

Suggesting that people would stop reading Nature if they also included replication studies send like an incredible leap.

On the contrary, the best products are typically built by the users of the products. If you are building a product you don't use, it will be worse than if you used it.

Users should be everywhere, in and out of engineering.

There are many leaders that use information as a tool that serves their own needs.

They may have the context, but they are either too focused on their own job to share it, or actively manage dissemination so they can manipulate the organization.

In my experience, this is the typical operating mode, though I do not think it is sinister or malicious - just natural.

The whole point of micro-services is to manage dependencies independently across service boundaries, using the API as the contract, not the internal libraries.

Then you can implement a service in Java, Python, Rust, C++, etc, and it doesn't matter.

Coupling your postgres db to your elasticsearch cluster via a hard library dependency impossibly heavy. The same insight applies to your bespoke services.

In practice, there are a number of factors which make using Kelly more difficult than in toy examples.

What is your bankroll? Cash on hand? Total net worth? Liquid net work? Future earned income?

Depending on the size of your bankroll, a number of factors come in to play. For example, if your bankroll is $100 and you lose it all it's typically not a big deal. If you have a $1 million bankroll, then you are likely more adverse to risking it.

What is the expected value? Is it known? Is it stationary? Is the game honest?

Depending on the statistical profile of your expected value, you are going to have to make significant adjustments to how you approach bet sizing. In domains where you can only estimate your EV, and which are rife with cheats (e.g. poker), you need to size your wagers under significant uncertainty.

What bet sizes are available?

In practice, you won't have a continuous range of bet sizes you can make. You will typically have discrete bet sizes within a fixed range, say $5-$500 in increments of $5 or $25. If your bankroll falls to low you will be shut out of the game. If your bankroll gets too high, you will no longer be able to maximize your returns.

At the end of the day, professional gamblers are often wagering at half-kelly, or even at quarter-kelly, due in large part to all these complexities and others.

Run valgrind on any large successful code base and you will find tons of memory corruption. It just happens to occur in places where it does not matter.

Decades? Really? The UX was so bad in 1998 I just went back to windows for another decade.

He lost me when he boldly declared that correlation IS causation based on one chart.

Complex systems are a lot more .. um .. complex than he suggests

If you pay a lot for parking or don't use the car much this tracks. But if you have the volume, then owning a car is cheaper.

An affordable mid size car costs roughly $6k per year total cost for a new car, and about 2/3 that for a used car.

If you commute daily to work, that is 500 trips per year. Two weekend trips adds another 100 per year. Now we are talking about ~$10/trip if you own your car.

When you add the premium value you get from flexibility, then it's an even better deal. If you only drive 50x a year then yeah, just use services.

And all code is an asset. Have we just reduced the conversation to: everything has a cost, and everything has a benefit?

You can see the cracks in the feature early on:

"What do you think I'm doing? Hint: it's a game."

Anyone with as much "knowledge" as Gemini aught to know it's roshambo.

"Is this the right order? Consider the distance from the sun and explain your reasoning."

Full prompt elided from the video.

i.e. artifice-ial

This does highlight the gap between SOTA and business production. Google search is very often a low quality, even user hostile experience. If Google has all this fantastic technology, but when the rubber hits the road they have no constructive (business supporting) use cases for their search interface, we are a ways away from getting something broadly useful.

It will be interesting to see how this percolates through the existing systems.

There's not much to elaborate, tons of practical use cases for search, sort and storage rely on alphabetization. If you move through an analog world of organized data, you'll find and develop many practical approaches to interacting with data based on knowing the key and the alphabetic ordering. Whether it's a phone book, a map, a dictionary, or filing systems, alphabets were always used as an indexing mechanism.