Delta’s airplanes also require a great deal of maintenance, and I’m sure they strive to have no more than are necessary for their objectives. But if you talk to one of Delta’s accountants, they will be happy to disabuse you of the notion that the planes are entered in the books as a liability.
Whoa whoa whoa let's not bring the accountants in!
Code isn't a liability b/c it costs money (though it does). Code is a liability like an unsafe / unproven bridge is a liability. It works fine until it doesn't - and at that point you're in trouble. Just b/c you can build lots of bridges now, doesn't mean each new bridge isn't also a risk. But if you gotta get somewhere now, conjuring bridges might be the way to go. Doesn't make each bridge not a liability (risky thing to rely on) or an asset (thing you can sell, use to build value)
Even proven code is a liability. The point of it being a liability is that it costs time and effort to maintain and update.
The same with the bridge. Even the best built and most useful bridge requires maintenance. Assuming changing traffic patterns, it might equally require upgrades and changes.
The problem with this whole “code is a liability” thing is that it’s vacuous. Your house is a liability. The bridge that gets you to work as a liability. Everything that requires any sort of maintenance or effort or upkeep or other future cost is ina sense a liability. This isn’t some deep insight though. This is like saying your bones could break so they are liability. OK, but their value drastically outweighs any liability they impose.
If Delta was going bankrupt it would likely be able to sell individual planes for the depreciated book value or close to it.
If a software company is going bankrupt, it’s very unlikely they will be able to sell code for individual apps and services they may have written for much at all, even if they might be able to sell the whole company for something.
The other half of the quote about liability is that the capabilities of the code are an asset. I don’t know if your bankrupt company would be able to sell their code, but they sure as hell couldn’t sell their capabilities without the code.
You're hinting at the underlying problem with the quote. "Asset" in the quote reads, at least to me, in the financial or accounting meaning of the term. "Liability" reads, again to me, in the sense of potential risk rather than the financial meaning. Its apples and oranges.
Liability is also an economic term. As in, "The bank's assets (debt) are my liability, and my assets (house) are the bank's liability."
I don't think it's a wrong quote. Code's behavior is the asset, and code's source is the liability. You want to achieve maximum functionality for minimal source code investment.
Sorry, my point wasn't that liability doesn't have a meaning in finance. My read of the quote is that it uses liability in the sense of risk not debt on a balance sheet.
I could always be wrong though, that was just my interpretation of it. I don't get how code could be a liability in the financial sense, but I do get how every line of code risks bugs and other issues.
Tech debt is not part of a financial account or disclosure though. Yes those are forms of debt, no they aren't financial debts or financial liabilities.
If we're bringing in other industries, you'd be wise to consider banking. Savings accounts are something most people would consider an asset, because it's money the bank has on hand and can use for loan purposes.
But it's the opposite, deposits are liabilities because they need interest paid out and can be withdrawn at any time.
Just because the company has a thing that could be assigned value doesn't make it automatically an asset.
Not a terrible example. The planes delta owns are delta’s assets; the planes the leasing company owns are the leasing company’s assets. The point is, the code and the planes are assets despite the maintenance required to keep them in revenue-generating state.
Neither of those assertions means anything. For many years, people have been using them to make confident predictions about what AI systems will never be able to accomplish. Those predictions are routinely falsified within months.
Of course, some of those predictions may also turn out to be true. But either way, we have abundant empirical evidence that the reasoning is not sound.
1. Because no one knows how to do it.
2. Consider (a) a tool that can apply precise methods when they exist, and (b) a tool that can do that and can also imperfectly solve problems that lack precise solutions. Which is more powerful?
The author has exclusive claim to their own aesthetic sensibilities, of course, but the language in the piece suggests some degree of universality. Whereas in fact, effectively no one who is knowledgeable about math would share the view that noncommutative operations are ugly by virtue of being noncommutative. It’s a completely foreign idea, like a poet saying that the only beautiful poems are the palindromic ones.
Recently I've used Claude Code to build a couple TUIs that I've wanted for a long time but couldn't justify the time investment to write myself.
My experience is that I think of a new feature I want, I take a minute or so to explain it to Claude, press enter, and go off and do something else. When I come back in a few minutes, the desired feature has been implemented correctly with reasonable design choices. I'm not saying this happens most of the time, I'm saying it happens every time. Claude makes mistakes but corrects them before coming to rest. (Often my taste will differ from Claude's slightly, so I'll ask for some tweaks, but that's it.)
The takeaway I'm suggesting is that not everyone has the same experience when it comes to getting useful results from Claude. Presumably it depends on what you're asking for, how you ask, the size of the codebase, how the context is structured, etc.
Its great for demos, its lousy for production code. The different cost of errors in these two use cases explains (almost) everything about the suitability of AI for various coding tasks. If you are the only one who will ever run it, its a demo. If you expect others to use it, its not.
As the name indicates, a demo is used for demonstration purposes. A personal tool is not a demo. I've seen a handful of folks assert this definition, and it seems like a very strange idea to me. But whatever.
Implicit in your claim about the cost of errors is the idea that LLMs introduce errors at a higher rate than human developers. This depends on how you're using the LLMs and on how good the developers are. But I would agree that in most cases, a human saying "this is done" carries a lot more weight than an LLM saying it.
Regardless, it is not good analysis to try to do something with an LLM, fail, and conclude that LLMs are stupid. The reality is that LLMs can be impressively and usefully effective with certain tasks in certain contexts, and they can also be very ineffective in certain contexts and are especially not great about being sure whether they've done something correctly.
> But I would agree that in most cases, a human saying "this is done" carries a lot more weight than an LLM saying it.
That's because humans have stakes. If a human tells me something is done and I later find out that it isn't, they damage their credibility with me in the future - and they know that.
In the vast majority of cases, developer ergonomics are much more important than freeing memory a little earlier. In other scenarios, e.g., when dealing with large data frames, the memory management argument carries more weight. Though even then there are usually better patterns, like method chaining.
FYI John Carmack is a true legend in the field. Despite his not being a lifelong Python guy, I can assure you he is speaking from a thorough knowledge of the arguments for and against.
>developer ergonomics are much more important than freeing memory a little earlier
Preach to the python choir bro, but it should be telling when a python bro considers it's too ergonomic and wasteful.
At some point being clean and efficient about the code is actually ergonomic, no one wants to write sloppy code that overallocates, doesn't free, and does useless work. To quote Steve Jobs, even if no one sees the inside part of a cabinet, the carpenter would know, and that's enough.
tl;dr: Craftmanship is as important as ergonomics.
In this case, overuse of re-assigning is the sloppy thing to do, and immutability by default is the craftsman's move. Reducing your program's memory footprint by re-assigning variables all the time is a false economy.
So if you are preparing a 50Kb webpage, and you do 10 steps of processing, you would have a 500KB memory footprint that might be held during the life of the connection? All the while the footprint and thus capacity of your server could have been 100Kb? Nice craftmanship dude!
We are not even talking about in-place algorithms, just 10 functions that process an html into a new array, maybe:
html = load_template(route)
html = formatstring(html,variables)
html= localize_paths(html)
...
And you would rather have the latter? For what gain? I think you wouldn't.
"Only a sith deals in absolutes", you have to recognize that both are valid under different contexts. And I'm merely explaining why inmutable is the default in python, 1: python doesn't do programmer self restrictions like const and private; 2: memory is automatic, so there's no explicit allocation and freeing like in C++, so using a new variable for each thing isn't a zero overhead abstraction.
Even for smaller cases, (not 50kb arrays), it's still the proper thing to do, although you have freedom to choose, it's easier to just follow one style guide and protocol about how to do things, if it's pythonic to reuse the variable name, just reuse the variable name. Don't fall for the meme of coming from another language and writing C++ in python or Java in python, you are not a cute visionary that is going to import greatness into the new language, it's much better to actually learn the language rather than be stubborn.
There's places where you can be super explicit and name things, if it's just an integer then it's a very cheap comment that's paid in runtime memory instead of in LOC. But this is why the default in python is not const, because variable name reuse is a core python tactic, and you are not our saviour if you don't get that, you are just super green into the language.
This is a textbook example of damning with faint praise. If your VCS's interface is so bad that it motivates you to scale back your use of any nontrivial version-control features and instead just content yourself with rudimentary file syncing, that's a case against the interface. Either the additional features are useful and you're missing out on that benefit, or they're extraneous and are saddling the tool with unnecessary baggage.
Or, hear me out, the tool has enough features to cover a wider range of use cases than your own. You're not missing the benefit of features outside your use cases.
The author lists that as a separate benefit, though.
My interpretation is that jj makes certain useful operations convenient to use that would be so complex in git as to be completely impractical. Something like jj undo would be a simple example: jj users can do it, and git users can’t, even though it’s logically possible in both systems.
This is not relevant. An observer who deceives for purposes of “balancing” other perceived deceptions is as untrustworthy and objectionable as one who deceives for other reasons.
