-
Subtype mutability violates immutability expectations – Commenters noted that making a mutable type inherit from an immutable one (e.g.,
NSMutableArray→NSArray) breaks the Liskov Substitution Principle and forces work‑arounds like runtime checks.“Basically inheritance is the wrong tool for this kind of stuff. … Because otherwise, it’ll be mutable after all.” – bartvk
“The fact that it requires so much explanation, indicates the level of degradation in the reasoning ability of the audience. A value of a subtype shall deliver all of the expectations of its super type…” – zkmon
“Yes, that’s ObjC, any NSMutableArray is an NSArray (and an NSObject) - classes passed by reference.” – catoc -
OOP is overrated / should be relegated to historical study – Several participants argued that object‑oriented inheritance is a flawed tool for expressing immutability and suggested it be taught only as a relic.
“I truly believe OOP should only be taught in computer science as a relic.” – bartvk
“intelligence is overrated” – pestatije
“Does obfuscating a simple logical concept by describing it in academia‑wanky‑terms … make it More Logical? Or does it just make the author and their in‑crowd feel more intelligent?” – applfanboysbgon -
Immutable ≡ read‑only is a false equivalence – The discussion highlighted that immutable collections and read‑only wrappers serve different purposes, especially in languages with value‑type arrays (Swift) vs. reference‑type collections (C#).
“In other words, immutable != read only.” – raincole
“In C#ReadOnlyCollection<T>andImmutableArray<T>are two completely different things for this exact reason.” – raincole
“Swift is completely different. Standard arrays are structures, always mutable - value types passed by value.” – catoc (illustrating the contrast)
Why isn't mutable a subtype of immutable, or vice versa?
📝 Discussion Summary (Click to expand)
🚀 Project Ideas
Generating project ideas…
Immutablint: Static Immutability Linter
Summary
- Detects unsafe mutable collection usage in Swift, Objective‑C, and C# codebases where immutable semantics are expected, helping avoid subtle bugs.
- Core value: automatic detection and one‑click fix suggestions that enforce true immutability at compile time.
Details
| Key | Value |
|---|---|
| Target Audience | Library authors and API designers working with Swift/ObjC/C# who want to guarantee immutable contracts |
| Core Feature | AST‑based analysis that flags mutable arrays/dicts passed to parameters expecting immutable types, suggests let, ImmutableArray<T>, or readonly wrappers |
| Tech Stack | Swift/SwiftSyntax for Swift/ObjC, Roslyn analyzers for C#, packaged as a CLI (Node.js wrapper) |
| Difficulty | Medium |
| Monetization | Hobby |
Notes
- HN commenters lamented that “immutable != read only” and wished for a way to catch NSMutableArray being passed where NSArray is expected (catoc, bartvk).
- Provides concrete feedback that could spark discussion on type safety and LSP violations in collection APIs.
CollectionSemantics Playground
Summary
- Interactive web playground that visualizes value vs reference semantics, upcasting, and Liskov substitution for arrays in Swift, ObjC, C#, and Java.
- Core value: lets developers experiment and see instantly why a mutable array can break immutable expectations, reducing confusion.
Details
| Key | Value |
|---|---|
| Target Audience | Students, junior developers, and interview preparers grappling with mutability concepts |
| Core Feature | Live code editor with side‑by‑side memory diagram showing stack/heap, type hierarchy, and mutation effects; supports multiple languages via Monaco + language servers |
| Tech Stack | React + TypeScript frontend, Monaco Editor, WebAssembly bindings for Swift/Wasm and .NET IL interpreter, Node.js backend |
| Difficulty | High |
| Monetization | Hobby |
Notes
- Commenters noted the need for “so much explanation” and linked to Principia Mathematica to show the depth of confusion (zkmon, Shorel); a visual tool would make the logic tangible.
- Could be used in teaching sessions or blog posts, generating discussion about covariance/contravariance and OOP relics.
ImmutableFacade Library
Summary
- Small language‑specific facade that provides a guaranteed deep‑immutable view of any collection, with compile‑time checks via source generators (C#) or property wrappers (Swift).
- Core value: one‑line conversion from mutable to immutable collections that cannot be circumvented, eliminating the read‑only vs immutable gap.
Details
| Key | Value |
|---|---|
| Target Audience | API developers who need to expose immutable collections but want to avoid boilerplate and runtime casts |
| Core Feature | ImmutableView<T> wrapper that enforces deep freeze at runtime and, where possible, proves immutability at compile time; includes conversion helpers from NSArray, NSMutableArray, List<T> |
| Tech Stack | C# source generators (Roslyn), Swift property wrappers + SwiftMacros, ObjC category; distributed via NuGet/CocoaPods/Swift Package Manager |
| Difficulty | Medium |
| Monetization | Revenue-ready: $5/mo per team for private registry access (optional) |
Notes
- Bartvk pointed out that “you can't use NSArray anywhere” because of hidden mutability; this facade gives a true immutable alternative that satisfies the expectation.
- Addresses the pain of ReadOnlyCollection vs ImmutableArray distinction (raincole) by offering a single, clearly immutable type usable across languages.