6 ms·
The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects conta
by Lavinski 6y ago
The article goes through a series of examples to show motivations for the following:
1. Variables should not be allowed to change their type.
2. Objects containing the same values should be equal by default.
3. Comparing objects of different types is a compile-time error.
4. Objects must always be initialized to a valid state. Not doing so is a compile-time error.
5. Once created, objects and collections must be immutable.
6. No nulls allowed.
7. Missing data or errors must be made explicit in the function signature.
The idea being that each feature or constraint _enables_ you to reason and predict more about a program than you could otherwise.
I encourage anyone interested in these ideas to play around with F# or a similar language and get a feeling for how they influence your code. If you've mastered one paradigm such as OO one of the best ways to find holes in your mental models is to try and find another point of view to look at the same problems. Even if you keep writing most of your code like you do today, in the language you do today, it can still be beneficial.
- nyanpasu64 6y agoRust's borrow checker would prevent Example 5 from compiling, since once you add `cust` to the collection, you can't touch it anymore (unless you insert a clone or etc.). So in this case at least, the inability to reason about code can be resolved by banning mutable aliasing, without eliminating mutability.
- masklinn 6y agoRust's ownership system would prevent example 5 from working (because you have to move the instance into the set). The borrow checker is about validating that references don't outlive their target, and R^W.
- nyanpasu64 6y agoOops.
- leephillips 6y ago5. Once created, objects and collections must be immutable. So this language would not be general purpose, as it would not be suitable for high-performance computing. Large scale simulations almost always involve arrays that are modified in place. Being able to somehow declare a collection to be immutable would be highly useful, but not having the option of mutable collections limits the kinds of problems that can be approached with the language.
- Athas 6y agoI'm not going to claim that mutability is never useful for performance, but many large scale simulations can be expressed quite elegantly using bulk operations on arrays or other structures, with no mutability in sight. Both particle simulations a la n-body and stencil operations are in this category. An efficient low-level implementation of such bulk operations involves mutable updates, just like any functional language is compiled to "impure" assembly code, but the programming model used for application programming can remain pure.
- leephillips 6y agoI concur, I should have been more precise in my comment.
- vram22 6y agoInteresting. Can you explain, with a somewhat simple example, how this can be efficiently implemented, or at all? I mean preserving the appearance of immutability at the source language level, while mutating the original structure under the hood for performance.
- zabzonk 6y agoC++ supports this via the mutable keyword https://stackoverflow.com/questions/105014/does-the-mutable-keyword-have-any-purpose-other-than-allowing-the-variable-to https://stackoverflow.com/questions/105014/does-the-mutable-... though not particularly for performance purposes.
- deleted 6y ago
- hansvm 6y ago1. Variables should not be allowed to change their type. This sounds nice, but is there a way to accomplish it without losing some expressibility or concision? Rather than looking at JS, consider low-level operations on a small chunk of memory as a niche example. Interpreting the same region as a buffer of 64-bit ints vs 16-bit uints gives entirely different behavior to the standard operators like addition, multiplication, and shifts, and there are plenty of cases where it makes sense to mix and match those operators. It's possible to construct a single type that encompasses all that behavior, but the price for doing so is a formidable wall of similar-looking method names rather than just being able to use a plus sign or other easier-to-understand constructs.
- masklinn 6y ago> Interpreting the same region as a buffer of 64-bit ints vs 16-bit uints The variable doesn't change its type though, instead you change your interpretation of it. That's a very different and explicit operation & manipulation. Although example 1 doesn't strictly have anything to do with types, you could get the same behaviour with `x = 0` in any language with closures (like javascript), or `foo = 0` in a language which passes parameters by (mutable) references as long as that information is not visible in the caller.
- scns 6y agoIn descendants of ML (Haskell, OCaml, Rust etc) you can use Algebraic Data Types to condense your wall of methods to one function
- nyanpasu64 6y agoAlgebraic data types have runtime case information, and won't let you reinterpret the underlying bits of a binary buffer between types. I think grandparent meant they wanted pointer casts, unions, reinterpret_cast, or transmute.
- deleted 6y ago[deleted]