They get power out of it (restricting the supply of capital).
In neoclassical economics, savings never pay off compared to investment. But in the real world, savings have important advantages:
1. They help you sustain longer in the case of strike (be it labor strike or investment strike).
2. They allow you to react to the market (for example, buying a promising startup winner after a competition consolidation) instead of being a first mover.
3. They allow you to price dump rapidly if a competitor threatens oligopoly pricing (usually the status quo), to drive them out of business.
That's why savings give you an actual power, which increases the richer you are.
Also, in my worldview, savings are liquid/reversible investments, while real capital investments are iliquid/irreversible - if you decide to build a factory you're commiting to an irreversible decision, if you buy an index fund, the decision is reversible, so it's basically savings. Making as few irreversible decisions as you can gives you an edge compared to others.
> If you have 1000 bits of semantic information you want to transfer, you can't give 300 bits of semantic information to an LLM and have it fill in the remaining 700, because it doesn't know what those 700 bits are.
LLMs do inference or computation among other things, so the remaining 700 bits can be something like that. The hidden implication in your claim is that computation adds no information content, which leads to an interesting philosophical discussion.
So for example, if I ask an LLM to give a proof or derive a new theorem from a set of axioms, according to your assumption, if it answers correctly, then I haven't learned anything new.
I am not really sure how to resolve this paradox in information theory.
If you input 300 bits into an LLM, and it outputs an additional 700bits of new information, I’d still rather you tell me those 1000bits than read ann llm’s output of 1000bits.
The primary reason is that human language is becoming a proof of work, that speaking out loud or writing directly indicates that the idea is important enough for a human to express. This is more costly than llm output, which is often just botspam.
From a purely information-theory perspective, the simplest solution is to say that yes, any content derived from existing information carries no information itself.
From a realistic perspective in the context of people copy-pasting LLM output, my thoughts are that asking an LLM to research for you is more defensible, but it's still better to read the LLM's research results and write the important parts in your own words (partly because the LLM probably used way more words than necessary for the context).
I am also not sure if the observation is true. People mentioned cats as a counterexample.
I think there are other species that could be considered more capable than humans, such as E. Coli, octopuses or ants.
And it's not even clear whether the AI will have its own individuality. It might become an extension of human brains, in the same way neocortex is an extension of amygdala. In that case the statement of who has control might become meaningless.
> where companies provide the user/customer with an interface to an AI that can do things for the user
I'm afraid it is the future. The companies will protect all documentation and IP by putting it behind AI agents, and will monitor (with another AIs) how is it being used.
It's gonna be a dark era for any knowledge in public domain.
I am from EU, leftist, socialist and liberal (the left parts), and I can assure you, (a) most leftists (90%) are as liberal and antiauthoritarian as it gets, and (b) we are as powerless to change these things as you are.
Possibly, if you choose to believe me, things can change, but it's on you.
Depends on country. Here in Czechia, Communist party is one of most socially conservative one, while conservative christian party is center-left economically. Social democratic party, when it was relevant, was also pretty socially conservative, which makes sense considering their working class demigraphics.
Liberal doesn't mean supporting liberty, it means some interpolation between supporting free markets (neoliberal means just this one), and pretending that as long as we just follow the established institutional norms everything is fine and there is no need for radical change. It's synonymous right now for "centrist" - note that political labels drift over time.
Liberalism has both economic (free market) roots and political roots. The first "leftists" were the French revolutionaries and they wanted (political) freedom as well. The reason liberalism is in the "center" is because both left and right tried to appropriate it. (Although I think liberalism, in the sense of individual freedom, is a distinct value from other values such as conservative/authoritarian or socialist/communal.)
This terminology change is mostly limited to anglosphere. Outside of that 'liberal' is still commonly used for economic-right low-intervention position.
I feel like the explanation is overcomplicated. Types are properties of values, not variables. Mutability is a property of variable, not of a value.
So it's kind of a categorical error. (I want to joke here that all categorical errors are just type errors in category theory.) When we speak of "type of a variable", we mean this variable can only be assigned (bound to) values of certain type. This has nothing to do with whether it can be reassigned (i.e. mutability).
So you don't even need the notion of subtyping to explain this.
Also, one could probably define variable as a monad over its type.
This post is about data structures, which are values, but like variables, they also contain values. Therefore they can be mutable. You can argue that a mutable data structure is an object not a value, I suppose. But it can go in the same place as a value, so it makes sense to talk about subtyping.
> Mutability is a property of variable, not of a value. [...] This has nothing to do with whether it can be reassigned (i.e. mutability).
I feel like you're using "mutable" too narrowly, as it's used colloquially in some programming languages. E.g. in JS, MDN itself talks about "reassignment"[0] and not "mutability" even though people often use "mutability" as a word to refer to the distinction between `const` and `let`. The only mention of mutability there is:
> Others may prefer `let` for non-primitives that are mutated
I.e. explicitly using `let` for mutated arrays, even if not reassigned, to make the signal mutability (which JS cannot express).
Note that you used "reassignment" which is the specific word for "mutating a binding", but the article is not referring to bindings at all.
Experimentally, at least one major programming language (Rust) places mutability into the type system.
Whether or not something belongs into a type system is ultimately determined by the type system. We can choose whether or not mutability is considered a part of a type.
> When we speak of "type of a variable", we mean this variable can only be assigned (bound to) values of certain type. This has nothing to do with whether it can be reassigned (i.e. mutability).
This is a bit too simplistic IMO. You're talking about name bindings, the article is talking more about things like interior mutability.
Rebinding a name is ... generally not a type system concern by my understanding.
You have a point; I am looking at it from quite functional programming perspective, because that's how type systems are typically understood. So from that perspective, interior mutability is a form of rebinding.
When you say "we can choose mutability as a part of a type", the question is, what kind of errors are we trying to prevent? What is the semantics we want to give? From that it should be obvious whether it can be subtype or not.
> So from that perspective, interior mutability is a form of rebinding
really? i honestly dont have _too_ much experience with functional languages, basically only elixir and consequently some amount of erlang in that vain... but i'd feel like thats not the same? but it may be that my point of view is too narrow.
from my experience with that functional language, the equivalent to this scenario would be a struct - and wherever i can mutate properties within it -- or need to reconstruct the struct from scratch.
both have technical consequences, eg if i passed the struct into a consumer somewhere which keeps it, it would get the "modified" version automatically when the property was changed
but on reconstruction, it'd have to introduce some kind of event listener to handle the reconstruction.
simple example for such a scenario would be eg a session within a SSE api.
the mutated struct would trivially allow for an uninterrupted stream no matter how long the session is extended, the latter needs to pay attention so its not opening a memory leak to support that feature.
A system programming language needs to match hardware where mutability is associated with memory addresses, something functional languages can afford to abstract away.
Mutability vs immutability describe the relationship between identity and state. Mutable values retain identity when their state changes. For immutable values, getting a new state requires a new identity, and importantly, existing identities never have their states changed.
Variables can be described by types. That is, a mutable slot referencing a value can be a value itself (a reference to a reference) and we can use subtype relationships to describe it. Variables are covariant when used as inputs (i.e code reads from the variable) and contravariant when used as outputs, and invariant when used as both. You can logically supply a Box<Cat> to a vet(in Box<Animal>) routine, and supply Box<Animal> to catchAndStore(out Box<Cat>). Substitute `ref X` for `Box<X>` when using a language that can pass variables by reference.
In statically typed languages, variables and expressions have a compile-time type and values have a run-time type.
> Mutability is a property of variable, not of a value.
In which languages?
In D, mutability is a property of a type. And variables and expressions have a compile-time type and values have a run-time type, so mutability is also a property of variables, expressions, and values.
(Immutability is also transitive in D, so an immutable value cannot have mutable parts, including mutable references, and a variable with an immutable type cannot contain a value or reference with any mutable parts.)
> When we speak of "type of a variable", we mean this variable can only be assigned (bound to) values of certain type. This has nothing to do with whether it can be reassigned (i.e. mutability).
This seems confused. "Mutable" or "immutable" are types like any other, like "String" or "Integer".
In computer science, specifically programming language theory, types are properties of terms (syntactic expressions). It wouldn’t be possible in general to typecheck a program before running it if you had to have a value before you could discover its type.
In semantics, types are properties of values and expressions. Type safety is about whether the type of an expression always matches the type of the value it evaluates to.
I was a PhD student for a while, but I always enjoyed "refactoring" proofs, more than coming up with new ones. Making them simpler, shorter, clearer. Unfortunately, it's not much rewarded.
I don't use one, but interestingly, every IDE (or other professional mega-app such as Blender) is essentially its own tiling WM.
So quite clearly they have won as an UI concept for people who want to get things done.
reply