https://futureofcoding.org/ logo
Join Slack
Powered by
The "mutable variables and immutable values" model...
# thinking-together
d
The "mutable variables and immutable values" model is less complex than the "implicit references to mutable objects" model. See replies for more information.
👍 5
In C, a variable can contain an scalar value, like an integer, or it can contain a composite value, like a structure or array. If A and B are structure variables, then the assignment A=B copies the value of B into A. Unlike "implicit references to mutable objects" languages such as Java or Smalltalk or Python, the assignment A=B does not result in A and B being implicit references to the same mutable object. Instead, if I modify one of the fields of B, using B.foo=0, then the value of A is unaffected.
In C, you can still arrange for the variables A and B to reference the same mutable objects, but you must use explicit pointers. There are no implicit references.
My language Curv uses a simpler and purer version of this model. All values are immutable. There are mutable local variables, but the assignment statement works by copying immutable values. This means that the state of two local variables with different names is guaranteed to be disjoint, so it's easier to reason about the semantics of mutable state in Curv. Unlike C, Curv does not have pointers, and unlike OOP languages, Curv does not have implicit references to mutable objects.
Curv has two kinds of aggregate data: lists and records. One consequence of these semantics (no pointers, no references) is that all aggregate data is tree structured. There is no cyclic data. That's a feature, not a bug. It makes data easier to visualize and easier to reason about.
k
It's not just that you have no cyclic data. You have no aliasing. That's fine for the domain you're targeting, but won't work for a general-purpose language. Your first statement is still valid. But "mutable variables and immutable values" doesn't preclude aliasing.
d
@Kartik Agaram The requirement that there be no aliasing of mutable state is definitely viable for a general purpose high level language. I'm not sure if it works for system languages, though. The idea was taken seriously back in the 1970's. It does force you to use a different style of programming (it is incompatible with OOP). Today, that original line of research has been forgotten, but the idea has been rediscovered in other contexts. Pure functional languages like Haskell have no aliasing of mutable state, since they have no mutable state. Data oriented design is a style of programming that is compatible with no cycles/no aliasing of mutable state: it's motivated by efficiency and ease of maintenance in video games. The "Out of the tarpit" paper advocated radical changes to the way we design software, to eliminate incidental complexity, and it advocates putting all of your state into what is effectively a relational database, with hierarchical data, no cycles, no aliasing. If we want the future of coding to have less incidental complexity, then we need to look beyond the OOP style of programming.
💯 2
👍 3
k
Huh, you're right! I'd somehow never internalized this implication of Haskell: https://stackoverflow.com/questions/10386616/how-to-implement-doubly-linked-lists
e
OOP is an obstacle to progress, and I am finally being vindicated for loathing Java and refusing to use it.
😆 1
k
Edward de Jong, now weighing in at 50 milli-wolframs 😄 Reminder to both of you that regular imperative programming (C, Pascal, Lisp, Oberon) also has mutable values and aliasing. I enjoy ripping into (mainstream! not Smalltalk!) OOP and Java as much as the next PL hipster, but it's a pretty low-brow activity.
🍰 1
k
One aspect that I see rarely discussed in the context of (im)mutability is the scale at which it applies. At small scale (local, low-level, etc.), mutability is still needed for efficiency, but isn’t problematic exactly because of the small scale, which limits complexity. At the other end of the spectrum, system integration (a Unix installation with its file system, a Smalltalk image), mutability is often desirable because jt reflects the real-world requirements (e.g. editing a file), and again it’s usually unproblematic because the complexity is managed by the user. That leaves a huge collection of intermediate layers where immutability is extremely helpful for taming complexity.
👍 1
e
Wolfram is one of the best programmers on the planet, so being compared with him is always a compliment.
😄 1
🤺 1
Mathematica as a company has 700 full time people, certainly one of the largest pure tool companies in the software business. He chose a very interesting business model, to sell site licenses to universities, which gets people hooked on it, and lives off expensive commercial licenses. Mathematica is $2500 for single licenses, $7000 for enterprise users. By comparison Autocad is 9000 employees. So in terms of engineering employee count I think at this point it is Google > Adobe > Autocad > JetBrains > Mathematica > Embarcadero (Delphi)... not sure who slots in below that, there aren't that many tool companies when you think about how many computers there are.
i
I love this thread so far. Thanks everyone for the very useful thinking and discourse.
Cycling 74 might count as a small purely tools company.
Perhaps Unity, too
e
Unity has more than 2000 employees, so they are between Autocad and JetBrains, certainly in the top 10 pure tools companies.
Open in Slack
PreviousNext
Powered by