pbw

In the post, I say private individuals can own assets in two ways, as individuals (up to a cap) or through a personal corporation (no cap).

So, if you start a company that becomes huge and your slice is worth $100 billion, or even $10 trillion, you can still own all of that via the personal corporation. And you can invest or spend all of it [almost] however you want.

The difference is that the personal corporation has oversight; I only specify there will be a "board" I don't have anything concrete beyond that.

But the idea is in extreme circumstances, the board can over-rule your money-related decisions. The intent is they will only step in if you are going nuts, but the devil is in the details of how exactly to do that. It might be impossible, but I'd rather see us at least try rather have brain-damaged trillionaires causing unchecked mayhem.

When I make this argument, people assume I want to tax or seize the billionaire's wealth, but no, I'm saying they can keep every penny. Although to be fair, if you did cleave apart people's finances like this, taxing the "personal corporation" higher than the individual portion would be tempting.

I wrote this in 2021: Billionaires: Our Single Point of Failure https://metastable.org/billionaires/

I don't think using AI to write code precludes learning deeply about the problem domain and even the solution. However, it could lead to those problems depending on how it's done. But done well you can still have a very knowledgeable team that understands the domain and large portions of the code, I believe anyway.

I think software engineers will drift towards only understanding the domain and creating tasks and then reviewing code written by AI. But the reviews will be necessary and will matter, at least for a while.

I always heard it as "software development is an exercise in knowledge acquisition."

I wrote this to probe the question of why “slow” languages are popular and valid when used in conduction with fast ones: https://tobeva.com/articles/beyond/

I don't love the analogy, but I 100% agree that we are putting AI tools into people's hands that they are not yet able to wield safely. I think this is mostly because of how quickly AI has been developed. New technologies can take decades to be absorbed by society. Early on with cars we had no traffic lights, speed limits, or seat belts. And modern freeways were many decades off.

"Early electrical systems were poorly insulated, and fires or electrocutions were common. The creation of standards for wiring, outlets, grounding systems, and circuit breakers took decades to develop." It could be that AI will develop so fast that society never catches up, but I'm sure we'll at least get better over time.

Everything is physics at the bottom.

I really enjoy these. I’ve listened to them while driving —- blog posts by Astral Codex Ten or Paul Graham that I had never bothered to read.

There are millions of real podcasts, but now there are an infinite number of AI generated ones. They are definitely not as good as a well-made human one, but they are pretty darn decent, quite listenable and informative.

Time is not fungible. I can listen to podcasts while walking or driving when I couldn’t be reading anything.

Here’s one I made about the Aschenbrenner 165-page PDF about AGI: https://youtu.be/6UmPoMBEDpA

Early on, the cloud's entire point was to use "commodity hardware," but now we have hyper-specialized hardware for individual services. AWS has Graviton, Inferentia and Tranium chips. Google has TPUs and Titan security cards, Azure uses FPGA's and Sphere for security. This trend will continue.

I always felt that true "scripting" with a "scripting language" was two things: 1) Most of your functions were linear: low cyclomatic complexity. 2) Functions rarely called into other functions.

While "programming" moves away from both of those: 1) Higher cyclomatic complexity is allowed. 2) Functions frequently call into other functions.

For instance, I like bash only for scripting. The moment it starts to resemble programming, I tend to switch to Python. However, some people are fine doing a fair amount of "programming" in bash, people who know it really well.

Bubbles are inevitable. Imagine a single company investing precisely the right amount into a new technology, not a penny more. Now imagine every single company and person doing the same thing, perfectly. It’s impossible.

The stock market has boom and bust cycles even with companies using 100 year old technologies! With an embryonic but all-promising technology like AI: it will pop then reinflate many times over. And this is fine.

This is a great point and very true.

I mentioned in another comment pylint’s 50 line limit for methods. So I agree - a well written 50 line method is sometimes better than the same code chopped up.

Although a significant factor is if you chopped it up, would there be multiple callers for the new smaller methods? Because that’s probably better than adding flags to your large method to make it behave differently for different callers, increasing its cyclomatic complexity.

Pylint warns if you have “more than X” for a lot things like local variables, number of arguments, number of member variables, etc.

For most of these the limits are in the 5 - 9 range but for lines in a function/method the limit is 50 lines.

I agree with this. One line functions are okay sometimes but 50 line functions can be fine as well if clear and well written.

A lot depends on the cyclomatic complexity: how many loops and branches, how drastically the indentation varies basically.

So I disagree with how strenuously Uncle Bob harps on short methods, although paradoxically I do agree many methods in the wild are too long. Most of them grew to be too long because it’s easier to add a few lines to an existing method than to refactor things —- particularly if a code review is required.

I’m not at all familiar with Julia but that sounds interesting. I’ve been thinking recently that with AI we might eventually decouple the style of the source code from the style of the executable code.

That is, let you toggle from DOD to OOP in your IDE. The way you can vary the font in your IDE today. Very non-trivial but in the long term could happen.

I’ll add that “use good names” is good advice. But “use the names Robert Martin prefers” may or may not be good advice.

I think DOD is great and Casey’s optimized version is great. But his claim that OOP inevitably leads to horrible performance is factually wrong. And he’s repeats it over and over even after the viral video. My main goal with the article/video was to debunk this false claim of his.

Also, something most people over look is the OOP example in his article is 100% vanilla OOP. There is nothing “clean code” about it. So he’s really railing against OOP and not clean code.

My article shows that the impact of the overhead of OOP, but really the impact of the overhead of _anything_, can range from huge to basically zero, depending on the time scales involved. So my main point is you should be very mindful of the time scales involved.

But if you want to rule out OOP for non-performance reasons I think that’s fine. All styles have pros and cons, and situations can vary widely. Like for instance the existing style of the project and the skills and preferences of the people involved.

> But performance isn’t the reason to reject his advice: common sense and good taste are more than enough of a reason.

My article and video are responses to Casey's mega-popular video "Clean Code Leads To Horrible Performance," which has 873k views. In it, he falsely claims that clean code always leads to horrible performance when, in fact, it only sometimes does. In my article/video, I explain when OOP/clean code does and doesn't lead to horrible performance.

My goal was to debunk Casey's claim since he was factually wrong and continues to mislead people about this to this day. I partially agree with your point that Uncle Bob's advice is wrong for other reasons. His main four books total 1,500 pages. Some of the advice is good, some is dated, opinionated, or just wrong. Untangling all that would require a much longer and very different article, which wasn't the one I was writing.

As the OP, I was not arguing that Uncle Bob's advice is good; I was arguing that performance is not the reason to reject his advice... unless you are counting nanoseconds, in which case performance is a great reason to reject his advice.

It's a story of two worlds. Casey lives in a world where nanoseconds almost always count. He says OOP is horrible for performance, but he really means it's horrible for performance in that world. But Uncle Bob's book is about a different world: business Java programming from 10+ years ago. There, the overhead of OOP is almost always negligible. One of my main points in the article was just to be aware of the world you are in.

Performance aside, is Uncle Bob's advice good or bad? I think it's a mixed bag. His four main books total 1,552 pages. Some of his advice is rooted in the Java programming world from the 1990s and 2000s, but I think other advice (like "use good names") is valid today in many languages. Sorting through all those pages of advice would require a much longer article; I didn't try to do that; I just tried to address Casey's performance claim, since I think he's totally wrong (in many cases) even while being totally right in other cases.

A prediction is a prediction; it's not necessarily a correct prediction.

The weatherman predicts the weather, even if he's sometimes wrong, we don't say "he attempts to predict" the weather.

If you knew a human, who you could text day or night, on any topic, and they’d respond within seconds with a lengthy answer, which was often correct, would you delete their contact number because they sometimes made subtle errors? I would not.

> people's views change from one generation to the next

I think that's what Kevin Kelly means by attention in the essay.

He writes:

> It is much easier to build a rocket that will sail 500 years to the nearest star, then it is to ensure that the future generations of people born on board that 500-year rocket maintain the mission

So he doesn't mean we'll flake out and flit our attention to something else on a whim. He's saying if we drop a project due to changing beliefs, opinions, and goals, that's "not having a long attention span".

I don't love his use of the word "attention" to mean that, but I think it's pretty clear what he means by the word from the essay.

The “end of history” fallacy is to acknowledge radical unexpected events got us here, but then insist nothing radical or unexpected will happen in the future. That things will just play out like clockwork. They won’t.

I like the engineering effort, but it's tainted by puerile comments like "visionary genius of Ross van der Gussom".

There's a rush because about 10 million people die from cancer every year worldwide, 7 million died from COVID, 6 million people have Alzheimer's in the US alone. All three of these can be tragic and brutal ways to die, which ripple out to family and friends. All told the US spends over $4 trillion dollars on healthcare per year, what if we could do way better and spend way less? And healthcare is just one thing of many that AI could improve.

The fictional primer is acted by a human. So the “last mile” is people there.

I agree I think it does a very good job. The last two were even not horrible, but it missed a key detail in each one. If it can get as good with coming up with memes, not just describing them, that would be pretty wild.

I made some drawings with GPT-4 Code Interpreter and Pillow. I think with its sub-mage and image composition features you could make some detailed drawings if you were clever about it.

[1] https://metastable.org/draw.html

Oh man that's an amazing document!

This is just growing pains for a new industry. OpenAI shot up to 100M users almost overnight. Hosting AI models at that scale has never been done before, and surely was costing them a fortune. It's not surprising to me they are futzing around with things and causing some regressions.

Yes self-hosting is one option, and probably a good one for many companies. But I also suspect OpenAI and AI APIs by others will get much more stable and reliable in the coming months and years as the industry matures and best practices are adopted.

I would guess AI API reliability and maturity will asymptotically approach that of other cloud services, like S3, as more and more things depend on them.