DEV Community: Andrey S Kalmatskiy

CardDOM in C++: Ownership, Cycles, and Smart Pointers

Andrey S Kalmatskiy — Sat, 20 Sep 2025 21:02:58 +0000

This is the third article in DOM-handling series.

If you haven't read the prior parts:

Which Language Handles DOM-Like Models Best.
Building a DOM in JavaScript: Ownership, X-Refs, and Copy Semantics you might want to start there for context.

C++ offers no garbage collector or borrow checker, but its smart pointers can model ownership hierarchies - if you treat them like the sharp tools they are. The challenge: building a DOM-ish structure (Document → Card → CardItem) that supports cross-references, shared immutable resources, and topological deep copies without leaks or undefined behavior.

Result: A working C++ implementation of the CardDOM in ~150 LOC that survives Valgrind, enforces immutability at compile time, and auto-expires weak references - though it demands constant vigilance against pointer misuse.

Design Decisions

Ownership and Reference Tracking

shared_ptrs holding all nodes, with runtime checks preventing multiparenting or cycles.
weak_ptrs for cross-links (connectors, buttons) to ensure automatic expiry on deletion:
No manual unlinking required; expired weak_ptrs are safely handled with .lock().
Parent pointers validated at runtime during add/remove to block self-nesting or duplicate parents.

Handling / Avoidance of Shared Mutable State

Const Style types enforce immutability at compile time, blocking direct mutation of shared resources.
Copy-on-write via explicit clone(): Mutations require creating a mutable copy first.
No shared mutable state in the graph; reassigned clones become const again post-mutation.

Trade-Offs

No unique_ptr for hierarchy roots: since all nodes of DOM-like structure can be targets of cross-references (weak-ptrs) this force shared_ptr everywhere, complicating single ownership.
Two-phase deep copy: Custom traversal needed to resolve topology and rewire weak_ptrs correctly.
Discipline required: Smart pointers prevent use-after-free but not leaks from cycles.

Safety Guarantees

From the Language/runtime

Smart pointers automate deallocation and prevent use-after-free via reference counting.
Const-correctness rejects mutable access to shared data at compile time. But it does not prevent having const and non-const pointers to the same objects. In should be enforced manually.
Weak_ptr auto-expiry prevents dangling cross-references without explicit cleanup.

From the Design

Runtime exceptions on multiparenting/cycles maintain graph integrity during modifications.
Stack reference protection: All params should be passed by value/reference to smart_ptrs; no raw pointer exposure.

Code Size & Cognitive Overhead

Size: ~150 LOC, focused on pointer management, assertions, and two-phase copy logic.
Cognitive load: Every new DOM node must reimplement copy/add/drop-child logic.

Usage

//// Creation
auto doc = make_shared<Document>();
{
    auto style = make_shared<const Style>("Times", 16.5, 600);
    auto card = make_shared<Card>();
    auto hello = make_shared<TextItem>("Hello", style);
    auto button = make_shared<ButtonItem>("Click me", card);
    auto conn = make_shared<ConnectorItem>(hello, button);
    card->add_item(move(hello));
    card->add_item(move(button));
    card->add_item(move(conn));
    card->add_item(make_shared<GroupItem>());
    doc->add_item(move(card));
}

// Unshare-on-modification
auto hello_text = dynamic_pointer_cast<TextItem>(doc->items[0]->items[0]);

// Compile-time prevention of direct mutation:
hello_text->style->size++; // ERROR

// Explicit clone to mutate:
auto new_style = hello_text->style->clone();
new_style->size++;
hello_text->style = new_style;

// Stack references prevent objects from being deleted
{
    auto hello_text = dynamic_pointer_cast<TextItem>(doc->items[0]->items[0]);
    doc->items[0]->remove_item(hello_text);
    // hello_text is still alive here
    assert(!dynamic_pointer_cast<ConnectorItem>(
        doc->items[0]->items[1])->from.expired());
} // Actual deletion occurs here

// Topologically correct copy
auto new_doc = deep_copy(doc);
assert(new_doc->items[0]->items[0] ==
    dynamic_pointer_cast<ConnectorItem>(
        new_doc->items[0]->items[1])->to.lock());
assert(new_doc->items[0] ==
    dynamic_pointer_cast<ButtonItem>(
        new_doc->items[0]->items[0])->target_card.lock());

// Runtime multiparenting prevention
try {
    doc->add_item(new_doc->items[0]);
} catch (std::runtime_error&) {
    std::cout << "multiparented!\n";
}

// Runtime cycle detection
try {
    auto group = make_shared<GroupItem>();
    auto subgroup = make_shared<GroupItem>();
    group->add_item(subgroup);
    subgroup->add_item(group);
} catch (std::runtime_error&) {
    std::cout << "loop\n";
}

Evaluation Table

Criterion	Description	Verdict
Memory safety	Avoids unsafe access patterns	⚠️ Smart pointers block UAF; const prevents shared mutations, but raw pointer slips possible
Leak prevention	Avoids memory leaks	⚠️ Reference counting + RAII handles most cases; cycles or forgotten drops need Valgrind
Ownership clarity	Are ownership relations clear and enforced?	⚠️ Shared_ptr enables cross-refs but blurs single ownership; runtime checks enforce rules
Copy semantics	Are copy/clone operations predictable and correct?	⚠️ Manual two-phase deep_copy preserves topology and rewires `weak_ptrs`
Weaks handling	Survives partial deletions and dangling refs?	✔️ Weak_ptrs expire automatically; no manual cleanup, stack refs extend lifetime safely
Runtime resilience	Can DOM ops crash app?	⚠️ Exceptions on violations (multiparent, cycles); survives partial deletes via RAII
Code expressiveness	Concise and maintainable?	⚠️ Verbose pointer boilerplate offsets readable API; manual copy/loop logic adds overhead
Ergonomic trade-offs	Difficulty of enforcing invariants?	❌ High; relies on developer discipline - no compile-time ownership beyond const

Verdict

C++ can model complex DOM-like graphs if:

You standardize on shared_ptr for cross-referenced nodes,
Leverage const for compile-time immutability,
Implement two-phase deep_copy for topology-aware cloning,
And cultivate pointer discipline with runtime guards and Valgrind.

It's powerful but unforgiving - demanding vigilance.

At 150 LOC, it proves modern C++ handles shared mutable structures robustly, though leaks and UB lurk for the unwary. Ref-counting languages like Rust offer similar foundations with panic-based safety nets, but neither category natively groks DOM topologies.

Rust: Honorable Mention

Rust's borrow checker shines for stack values but falls back to ref-counting for heap graphs, mirroring C++'s smart pointers:

Box<t> = unique_ptr<t>
Rc<t> = shared_ptr<const t>
Rc<RefCell<t>> ≈ shared_ptr<t>
Weak<RefCell<t>> ≈ weak_ptr<t>

Differences between languages are centered around idea of how to handle object disposal while it's still referenced from stack:

C++ risks UB (and almost always damages memory)
Rust handles this situation in RefCell.drop() and if Rc is deleted while its inner RefCell is in a borrowed state, it panics.

So for DOMs, Rust adds safety via panics but sacrifices resilience and clarity.

The bigger revelation:

Almost every modern app depends on DOM-like structures.
Yet no GC-languages (JS) nor ref-counted languages (C++) is truly equipped to handle them.

Building a DOM in JavaScript: Ownership, X-Refs, and Copy Semantics

Andrey S Kalmatskiy — Sun, 10 Aug 2025 19:06:37 +0000

This is the second article in my DOM-handling series.

If you haven’t read the first part - Which Language Handles DOM-Like Models Best? - you might want to start there for context.

JavaScript’s garbage collection frees you from explicit memory frees, but it won’t save you from "dangling" references to semi-destroyed objects, multiparenting, or topology corruption in complex object graphs.

Building a DOM-ish model (Document → Card → CardItem) with predictable behavior means making manual decisions about ownership, weak references, and deep copying.

Design Decisions

Full JS solution (~330 LOC) here: 🔗 https://jsfiddle.net/0tv5yj37/4/

Ownership and Reference Tracking

Parent pointers (parent field) enforce single ownership of a node at runtime.
Registration sets (inboundButtons, inboundConnectors) simulate weak references:
- When an object is detached, it actively clears inbound links.
- This prevents dangling references after deletion.
Detachment cascade ensures that deleting a node cleans up all references to it before it’s gone.

Handling / Avoidance of Shared Mutable State

Shared Style and Bitmap instances are protected with Object.freeze() to enforce immutability at runtime.
Copy-on-write is achieved via mutateStyle() - editing a shared resource automatically clones it.
No shared mutable structures exist in the graph; all shared data is immutable.

Trade-Offs

Manual enforcement: Because JavaScript won’t stop multiparenting or cycles, we must check on every addItem() and setParent().
Two-phase deep copy: Required to preserve shared topology while creating new mutable nodes.
Cognitive overhead: The model spans ~330 LOC, much of it boilerplate for deepCopy() and resolve() methods.

Safety Guarantees

From the Language

Garbage collection eliminates leaks from unreferenced objects (eventually).
No raw memory access, so undefined behavior from freed memory is impossible.

From the Design

Ghosting prevention via explicit unlinking (detach()): On object removal, cross-references are broken to ensure no part of the remaining object hierarchy can continue accessing the removed object in a "post-detached" non-working state.
Runtime safety: Invariant checks (Card already has a parent, Loop detected) ensure structural integrity.
Topology safety: Connectors and Buttons x-refs are nulled on detach and rewired on copy.

Code Size & Cognitive Overhead

Size: ~330 LOC, with most complexity in repetitive deep copy/resolve patterns.
Cognitive load: Developers must understand the lifecycle of every object and call detach() correctly; missing one leads to “ghost” references until GC eventually runs.

Usage

//// This code throws exception - style is immutable
// doc.cards[0].items[0].style.font = "Helvetica";

// unshare on mutate:
myText.mutateStyle(style => {
   style.font = "Helvetica";
});

// Drop X-refs
doc.cards[0].removeItem(doc.cards[0].items[0]);
console.log("after item deleted and link lost", doc);
// Result shows that "hello" text is removed both from card and connector.
// Cross-references are explicitly broken to prevent ghosting -
// no remaining part of the object hierarchy can access the removed item.

// Copy
const newDoc = deepCopy(doc);
console.log("after copy, preserving button and connector links", newDoc);
// Result: newDoc is structurally and data-wise identical to doc,
// though consisting of newly allocated objects.

// Safety net against multiparenting and cycles:
// The following code successfully compiles but crashes
// because of multiparenting attempt
doc.addCard(newDoc.cards[0]);

// This code compiles and runs
// because copy operation prevents multiparenting
doc.addCard(deepCopy(newDoc.cards[0]));

Evaluation Table

Criterion	Description	Verdict
Memory safety	Avoids unsafe access patterns	⚠️ Safe from UAF/null deref by design; GC handles deallocation, though stack references can see partially destructed (detached) objects
Leak prevention	Avoids memory leaks	⚠️ GC works eventually, with memory overhead and causes sudden pauses
Ownership clarity	Are ownership relations clear and enforced?	⚠️ Implemented in code, enforced only at runtime via exceptions
Copy semantics	Are copy/clone operations predictable and correct?	⚠️ Manual
Weaks handling	Survives partial deletions and dangling refs?	⚠️ Manual, via registration sets and detach cascade; detached objects remain visible to stack references but in a post-detached, non-working state
Runtime resilience	Can DOM ops crash app?	⚠️ Yes, if invariants violated (multiparent) - throws exception
Code expressiveness	Concise and maintainable?	⚠️ Verbose; every class needs boilerplate deep copy and detach logic
Ergonomic trade-offs	Difficulty of enforcing invariants?	❌ High; language offers no compile-time guarantees

Verdict

JavaScript can host a reasonably safe DOM-like graph if:

You manually enforce ownership,
Treat “weak” links as opt-in and track them explicitly,
Accept that deep copy logic will be verbose,
And rely on runtime exceptions rather than compiler errors.

It’s not fully safe, but it’s miles better than a manual memory handling.

These conclusions can be applied to all GC-driven languages, which is why I won’t test Java, Kotlin, C#, Python, Dart, Go, or TypeScript - although I welcome any examples in these languages proving that they have extra features helping with DOM handling.

Next stop - C++

Which Language Handles DOM-Like Models Best?

Andrey S Kalmatskiy — Sat, 09 Aug 2025 18:37:51 +0000

Modern applications - from document editors to game engines from UI frameworks to databases - rely heavily on complex, interconnected data models to represent their internal state. These models often form what we call here DOM-like data structures, which in their simplest form can be imagined as a familiar XML or JSON tree.

What Are DOM-Like Data Structures?

DOM-like data structures are polymorphic, interconnected object graphs characterized by three fundamental layers:

🌲 Tree of Ownership Objects are organized hierarchically, with each parent exclusively owning its children. This structure is acyclic and maps well to serialization formats like XML, JSON, or Protocol Buffers. It forms the backbone of many application data models, enforcing clear ownership boundaries and safe, exclusive containment.
🕸 Web of Weak References Beyond ownership, objects often need to reference each other without owning - think of a GUI control referencing the currently focused element, or a paragraph linked to an entry in a document's stylesheet. These are implemented as weak references to avoid circular ownership and memory leaks, forming a web of safe, non-owning links layered on the ownership tree.
🧊 Directed Acyclic Graph (DAG) of Shared Immutable Resources Immutable resources like styles, fonts, or textures are shared across multiple nodes without duplication, following the flyweight pattern. This DAG layer sits at the bottom of the ownership tree and enables efficient reuse of common immutable data while maintaining acyclic dependencies.

Real-World Examples of DOM-Like Structures

Game engines: Scene graphs with nested spatial hierarchies of entities.
UI frameworks: Controls grouped into panels, windows, or forms.
MVC/MVVM architectures: Loosely coupled models, views, and controllers.
Document editors: Pages containing structured text flows, paragraphs, and styles.
Object databases: Graphs of owned objects representing serialized data.
Relational databases: Tables with nested records and fields.

Why Modern Programming Languages Must Support DOM-Like Structures

These DOM-like object graphs represent the foundational data model for modern, stateful, interactive applications. Unlike flat or strictly hierarchical data, these structures are:

Large, mutable, and heterogeneous
Richly interconnected with complex dependencies
Combining ownership, sharing, and weak references

A programming language capable of modeling these structures safely, efficiently, and ergonomically is better suited for real-world application development. Such languages should provide:

Memory safety - no dangling pointers, use after free, double free
Leak prevention - guarantees against memory and other resource leaks
Clear ownership semantics - ideally verified at compile time
Immutability and controlled mutation - support for immutable objects, efficient resource sharing, and automatic unsharing on mutation
Safe deletion - modifying the DOM should never cause crashes, memory corruption, or undefined behavior, even if deleted objects are still referenced on the stack
Weak reference invalidation - when an object is deleted, all cross-weak-references to it should automatically become invalid

Evaluating languages by their ability to handle these DOM-like models offers deeper insight into their practical suitability beyond traditional benchmarks.

How We’re Going to Test Languages

Let's attempt a well-defined task to evaluate and compare how different programming languages handle DOM-like structures under a common set of structural constraints.

Task Definition

Participants must implement a simplified DOM for a hypothetical card editor/player application.

This DOM consists of the following components:

Cards, each containing a list of Card Items.
Card Items may be one of:
- Styled text blocks
- Images
- Connectors with arrows (auto-routing)
- Buttons for navigation between cards
- Groups of card items (recursive containers)

Constraints and Invariants

The implementation must enforce the following:

Mutability. Cards and elements must be mutable, supporting live updates of all their attributes.
Shared Resources. Styles and bitmaps can be shared across elements, cards, or documents. Modifying a shared resource must not affect unrelated elements - mutation must be explicit and localized (copy-on-write or unshare-on-mutate behavior).
Ownership Structure
- Each Card belongs to exactly one Document.
- Each Element belongs to exactly one Card or Group.
- Groups may be nested recursively.
- A group cannot - directly or indirectly - contain itself.
Connectors. Connectors may target arbitrary elements. If a target is deleted, connectors must safely enter a detached state without crashing.
Button Navigation. Buttons link to other cards. If a target card is deleted, referencing buttons become safely detached.
Memory Safety
- No use after free, uninitialized pointers, double free allowed.
- No memory leaks allowed.
- Deleting an object must not crash the program - even if references are still on the call stack.
- Runtime resilience is critical; the app must remain stable, especially for sensitive domains like medical systems.
Copy Semantics. Copy of cards and card items must maintain predictable reference semantics and preserve topology (e.g., connectors and buttons must keep the same topology of links after duplication).

Methodology

Participants implement the DOM model in one or more languages, adhering to the constraints. They document:

Design decisions on ownership and reference tracking
Handling or avoidance of shared mutable state
Safety guarantees from the language or design
Trade-offs during implementation
Code size and cognitive overhead

A reference class diagram is suggested, though exact design and memory management can vary.

Evaluation Criteria

Criterion	Description
Memory safety	Avoids unsafe access patterns?
Leak prevention	Avoids memory leaks?
Ownership clarity	Are ownership relations clear and enforced by the language?
Copy semantics	Are copy/clone operations predictable and correct?
Weaks handling	Does the app survive partial deletions and dangling references?
Runtime resilience	Can DOM operations cause app termination?
Code expressiveness	Is the code concise and maintainable?
Ergonomic trade-offs	How difficult is enforcing invariants in the language?

Everyone’s Invited

If you have a favorite programming language to showcase:

Implement this DOM-like model.
Share what worked, what felt clunky, and where safety relied on discipline rather than language features.

💬 Join the Experiment!

Whether you’re a language enthusiast, a systems programmer, or simply curious, I invite you to participate, share your experiences, and help uncover which languages truly excel at managing modern, complex application state.

What’s Next

In the upcoming posts, I’ll take a deep dive into implementing this DOM model in several widely used languages with very different memory and ownership systems. After that, I’ll explore other languages and compare their strengths and challenges.

Let's discover a winner - or will we confirm that no acceptable solution exists yet?

Why Your Website in 2025 Should Stop Using Raster Icons

Andrey S Kalmatskiy — Thu, 19 Jun 2025 19:15:30 +0000

I feel a little awkward saying this - it seems like I’m stating the obvious - but even in 2025, we still see websites (including those backed by billions of dollars and the work of hundreds of developers and designers) using raster graphics for icons.

(Google Drive and FB.com)

Maybe companies shy away from vector graphics because they think it's too complicated.
This article aims to briefly dispel those doubts: vector graphics are simple, stylish, and modern.

Why SVG is the Right Choice

Modern web development offers two main approaches for vector graphics: TTF/OpenType fonts and SVG.
Here’s why SVG is better:

Crisper rendering at any size, including fractional scaling - fonts can blur.
Better accessibility - screen readers ignore decorative SVGs by default (fonts can cause confusion).
No font loading delay.

In short: a modern website should be using SVG, not custom fonts.

Inline vs. External SVGs

You can use SVGs in two ways:

Reference an external SVG file via <img src="icon.svg">.
Embed the full SVG markup inside your HTML using the <svg> tag.

The second method has major advantages:

No extra downloads.
Full style control via CSS and JS (colors, strokes, filters).

However, when pages contain many repeated icons, developers often include full copies of SVG markup inline.

(It's hard to believe that each instance of this tiny globe icon has 1.5Kb of coordinates in text form)

That needlessly bloats page size and creates serious performance issues:

Page size increases dramatically (see the above image).
Every SVG fragment is parsed and rendered separately, consuming CPU/GPU.
Each instance occupies separate GPU memory.

A Better Way: Define Symbols Once

There’s a simple solution - define all your icons once at the top of your HTML:

<svg width="0" height="0" style="display:none;">
  <defs>
    <symbol id="like-svg" viewBox="0 0 170 170" fill="#000">
      <path d="M 74 122 L 31 81 ... Z"/> <!-- Put the content of your SVG-file. -->
    </symbol>
    <symbol id="close-svg" viewBox="0 0 24 24" stroke="#fff" stroke-width="2" stroke-linecap="round">
      <line x1="17" y1="7" x2="7" y2="17"/> <!-- Same here- just an SVG-file data -->
      <line x1="7" y1="7" x2="17" y2="17"/>
    </symbol>
    <!-- More symbols... -->
  </defs>
</svg>

Then, whenever you need an icon:

<svg class="main-icon" width="24" height="24"><use href="#like-svg"/></svg>

Et voila.

Benefits of This Method

This approach gives you the best of all worlds:

No delays from additional resource loading.
No page size bloat from repeated code.
Potential for symbol-level caching.
Full CSS/JS control over transforms, scale, color, fill, stroke.
Ability to compose complex icons from layered elements.
Support for **filters **like soft shadows or outlines.

Native Light/Dark Theme Support with SVG

One of SVG’s most powerful features is its automatic adaptation to light and dark themes.

Here’s how:

Replace fixed fill/stroke in SVG with: fill="currentColor" stroke="currentColor"
Assign icon color via CSS:

.main-icon {
  color: var(--iconColor);
}

Define light/dark values:

:root { --iconColor: #225; }
@media (prefers-color-scheme: dark) {
  :root { --iconColor: #aaf; }
}

That’s it. No JS required - your SVG icons will automatically recolor based on the system theme using just one image.

Example: latis.cc in light and dark mode

Why This Matters

Using embedded SVGs + <use> + currentColor:

Delivers instant, synchronous rendering.
Enables GPU caching of rendered images (depending on engine).
Keeps your single-page app **lean **and removes all coordinate/geometry duplication.
Allows you to style icons freely via CSS.
Supports any scale or pixel density - your UI won’t feel outdated.
Supports any number of color schemes, with fill, stroke, and filters.

And most importantly: it’s much easier than it seems.

For example, my favorite community link sharing site, latis.cc, uses no raster graphics at all — except for user-uploaded images.
Even the logo and favicon are SVG.

This is how nice and sleek it looks:

Upcoming Topics

A few things I plan to cover in future posts:

Optimizing SVG path coordinates - with a few simple tricks, you can reduce size up to 10×.
Implementing a **programmatic light/dark **theme toggle.
Hosting icon atlases in external SVG files, referencing them via <use> - useful for multi-page sites.
Exploring SVG animations.
Soft shadows with filters.

TL;DR Bitmap icons got zero rizz, fr. SVGs only — no cap. 🧢✨

Test Your Layout for Zoom — Not Just Screen Size

Andrey S Kalmatskiy — Fri, 13 Jun 2025 01:40:09 +0000

Modern web design focuses on accessibility *and **responsiveness *— but there's one crucial detail we often miss: **zoom adaptability.
🔍Users (especially 40+ or visually impaired) often set site zoom to 130+ to read comfortably. But many layouts break: horizontal scroll, clipped text, hidden content, ellipses instead of info, that’s a UX failure.
How to test:
💡DevTools → mobile mode → set zoom at the top, next to sizes
💡Check on real device - mobile browser main menu → zoom. Try zooming in/out ±60%. Your layout should flex — not break.
Good news: with plain HTML/CSS, it’s easy to achieve:
🔧Use flex and grid (with media queries for ≤240px)
🔧Set sizes in fr, %, em
🔧Avoid hardcoded widths and positions
🔧Let containers auto-resize
🔧Don’t fight the layout engine (but sometimes you need to fight managers and designers which love pixels).
Zoom support is just as important as screen width adaptation — Your users (and their eyes) will thank you.

About Likes

Andrey S Kalmatskiy — Mon, 09 Jun 2025 01:05:23 +0000

"Like" is a button with a counter and a thumb-up icon. What function does it serve? It’s meant to rank posts and comments, helping to separate more valuable ones from less valuable ones.

Why the "like" is a UI/UX mistake

The "like" was created in an earlier era when social networks were filled with posts like “me and my dog,” “my kids’ graduation,” or “me in Bali.” A valuable post or comment was simply one that many people liked: it simply brought them positive emotions. But times have changed. Nowadays social media is a space for social and political discourse, where difficult topics are raised and proposed solutions aren’t always soft or pleasant.

Let’s consider the following image:

Be honest — does this post deserve public attention? Is it valuable? Now, another question: do you _like _the content of this post? Are you ready to hit this "like" button?

The problem with the "like" is that it carries emotionally overloaded meaning and symbolism, while many posts and comments deserve public attention despite offering no pleasure. These posts don’t get likes, don't get high ranks, and simply vanish. Our problem is: we’ve conflated two concepts: a value indicator and a positive emotional reaction.

How attempts to fix "likes" with "reactions" only made things worse

Many modern platforms sensed this issue, but without understanding the root cause, they layered in more UI/UX: instead of the simple "like" button, they introduced lists of emotional reactions: anger, surprise, joy, sympathy...

Why doesn’t this solve the problem? The original like button was a value counter. Now we have 3 to 10 separate counters. How should we evaluate or compare comment values now? What formula should we use? Is 2 “angry” equal to 1 “happy”? Should we count them all equally? If a comment gets 5 “laugh” reactions — are people laughing at it (mocking it, a downvote), or with it (finding it funny, an upvote)? No one knows.

Let’s take a look at another picture:

Personally, I find the first 3 reactions nearly identical, and the next 4 could be (mis)interpreted as either upvotes or downvotes.

So "reactions" come with three main problems:

There are too many to avoid confusion, yet too few to express the full emotional range.
They duplicate what comments do better. And now, with voice input, swipe keyboards, and emoji palettes, writing a quick emotional comment is just as easy as picking a reaction.
They fragment feedback into multiple independent counters — making clear, consistent ranking of posts and comments impossible.

How Latis.cc do it right

The solution can be simple. It comes from rethinking the purpose of the like counter: to reflect the value of a post or comment to the community.

Let’s give our button a neutral label: "upvote." If a post or comment presents an idea, upvoting means you agree — regardless of emotions. If it simply states an issue, upvoting means you’re helping to raise awareness.

It’s simple and unambiguous.

The only obstacle is that we’ve spent 20 years using the thumbs-up icon to represent a “like”, but we don’t yet have a universally accepted symbol for “upvote.” Here are a few options:

🤝 Handshake
⬆️ Up arrow
✅ Check mark

Let’s examine them:

The handshake icon 🤝 is too complex. At 16×16px, it turns into a colorful blob. It’s also hard to recognize on small screens.
An up-arrow icon ⬆️, when placed in the utility bar beneath a post (next to buttons like "reply," "go up one level," or "open in a new window") can easily be mistaken for a navigation element.
That leaves the check mark icon ✅, and that’s actually a good thing. It’s intuitive. Everyone understands voting. And if a check mark appears under a comment, its meaning is immediately clear.

The new version of latis.cc replaced the “like” button with an upvote, and that’s the right move:

What do you think — should other platforms make this shift?

Argentum programming language

Andrey S Kalmatskiy — Thu, 08 Feb 2024 16:57:20 +0000

Bold statements

A year ago I started developing Argentum - a new programming language that is safe, scalable, fast and tiny.

It is memory safe, type safe, null-safe, array-index safe and so on. It is safe.
It automates memory management, so you will never deallocate objects manually.
Unlike Rust and Swift it guarantees absence of memory leaks and doesn't force you to use unsafe hacks.
Unlike Java, Go, JS and Python, it doesn't use garbage collector, so no sudden pauses and overheads.
It has precise predictable object disposal moments so objects can control any resources, not just memory.
It's compiled to machine code, producing tiny executables (with LLVM).
It has multithreading without deadlocks and data races.
It is simple and expressive.
And also it's crazy fast and memory-effective (I repeat myself).
And its interop with C is mostly a pass-through.

Ag language home: https://aglang.org

Status

It's still in a prototyping phase. Syntax will definitely change and lots of features will be added in the future, but it's worth looking at right now.

Nowadays Ag runs on and builds executables for:

x86-64 Windows,
x86-64 Linux,
ARM64 Linux.

It is integrated with:

CURL
SQLite
SDL (window, image, ttf)

Give it a try

This week I made a Web Playground for Argentum.
Now it's possible to try it online without installing anything.

All details and a playground link: https://aglang.org/playground/
Happy hacking! :-)

Managing Object Lifetimes Why it led to a new programming language "Argentum"

Andrey S Kalmatskiy — Tue, 01 Aug 2023 17:52:42 +0000

At the core of any modern programming language there lies a certain reference model, describing the data structures that applications will operate on. It defines how objects refer to each other, when an object can be deleted, and when and how an object can be modified.

Status quo

Most modern programming languages are built on one of three reference models:

The first category includes languages with manual memory management. Examples include C, C++, and Zig. In these languages, objects are manually allocated and deallocated, and pointers are simple memory addresses with no additional obligations.

The second category includes languages with reference counting. These languages include Objective-C, Swift, partially Rust, C++ when using smart pointers, and some others. These languages allow for some level of automation in removing unnecessary objects. However, this automation comes at a cost. In a multithreaded environment, reference counters must be atomic, which can be expensive. Additionally, reference counting cannot handle all types of garbage. When object A refers to object B, and object B refers back to object A, such a circular reference cannot be removed by reference counting. Languages like Rust and Swift introduce additional non-owning references to address the issue of circular references, but this affects the complexity of object model and syntax.

The third category encompasses most of the modern programming languages with automatic garbage collection, such as Java, JavaScript, Kotlin, Python, Lua, and more. In these languages, unnecessary objects are automatically removed, but there is a catch. The garbage collector consumes a significant amount of memory and processor time. It activates at random moments, causing the main program to pause. Sometimes this pause can be extensive, halting the program's execution entirely, while other times, it might be partial. There is no such thing as a garbage collector without pauses at all. And the only algorithm that scans the entire memory and halts the application for the entire duration of its operation can guarantee the collection of all garbage. In real-life scenarios, such garbage collectors are not used anymore due to their inefficiency. In modern systems, some garbage objects may not be removed at all.

Indeed, the definition of unnecessary objects requires clarification. In GUI applications, if you remove a control element from a form that is subscribed to a timer event, it cannot be simply deleted because there is a reference to this object somewhere in the timer manager. As a result, the garbage collector will not consider such an object as garbage.

As mentioned before, each of the three reference models has its drawbacks. In the first case, we face memory safety issues and memory leaks. In the second case, we encounter slow performance in a multithreaded environment and leaks due to circular references. In the third case, we experience sporadic program pauses, high memory and processor consumption, and the need for manual breaking of some references when an object is no longer needed. Additionally, reference counting and garbage collection systems do not allow for managing the lifetimes of other resources, such as open file descriptors, window identifiers, processes, fonts, and so on. These methods are designed solely for memory management.
In essence, problems exist, and each of the current solutions have their flaws.

Proposal

Let's try to build a reference model free from the aforementioned drawbacks. First, we need to gather requirements and examine how objects are actually used in programs, what programmers expect from object hierarchies, and how we can simplify and automate their work without sacrificing performance.

Our industry has accumulated rich experience in designing data models. It can be said that this experience is generalized in the Universal Modeling Language (UML). UML introduces three types of relationships between objects: association, composition, and aggregation.

Association: This relationship occurs when one object knows about another, and can interact with it but without implying ownership.
Composition: This relationship occurs when one object exclusively owns another object. For example, a wheel belongs to a car, and it can only exist in one car at a time.
Aggregation: This relationship involves shared ownership. For instance, when many people share the name "Andrew."

Let's break this down with more concrete examples:

Database owns its tables, views, enumerations, and stored procedures. A table owns its records, column metadata, and indexes. A record owns its fields. In this case, all these relationships represent composition.

Another example is a user interface form owning its controls, and a UI list owning its elements. A document owns its style tables, which, in turn, own page elements, and text blocks own paragraphs, which then own characters. Again, these relationships represent composition.

Composition always forms a tree-like structure where each object has exactly one owner, and an object exists only as long as its owner references it. We always know when an object should be deleted, so we need no garbage collector nor reference counting for such references.

Examples of association:

Paragraphs of some document reference styles in the document's style sheets.
Records in one database table referencing records in another table (assuming we have an advanced relational database where such relationships are encoded using a special data type, rather than foreign keys).
GUI form's control elements linked in a tab traversal chain.
Controls on a form referencing data models, which in turn reference controls in some reactive application.

All these associations are maintained by non-owning pointers. They do not prevent object deletion, but they must handle the deletion to ensure memory safety. The language should detect attempts to access objects through such references without checking for object loss.

Aggregation is a bit tricky. The industry's best practices suggest that aggregation should generally be limited to immutable objects. Indeed, if an object has multiple owners from different hierarchies, modifying it can lead to bitter consequences in various unexpected parts of the program. There are even radical suggestions to completely exclude the use of aggregation, see Google's coding style guidelines. Though aggregation can be valuable and appropriate in certain scenarios, for instance, the flyweight design pattern relies on aggregation. Another example, in Java, strings are immutable, allowing multiple objects to reference the same string safely. Additionally, aggregates can be useful in a multithreaded environment where immutable objects can be safely shared between threads.

It is interesting that a hierarchy of immutable objects linked by aggregating references cannot contain cycles. Each immutable object starts its life as mutable since it needs to be filled with data before being "frozen" and made immutable. As we have already seen, immutable objects cannot have cycles. Therefore, cycles in properly organized object hierarchies can only occur through non-owning associative references. While owning composition references always form a tree, and aggregating references form a directed acyclic graph (DAG). None of these structures require a garbage collector BTW.

Side Note: In other words, the main problem with existing reference models is that they allow the creation of data structures that contradict best practices of our industry and, as a consequence, lead to numerous issues with memory safety and memory leaks. Languages that use these models then struggle heroically with the consequences of their architecture without addressing the root causes.

If we design a programming language that:

Declaratively supports UML references,
Automatically generates all operations on objects (copying, destruction, passing between threads, etc.) based on these declarations,
Enforces the rules of using these references at compile time (one owner, immutability, checking for object loss, etc.),

...then such a language will provide both memory safety and absence of memory leaks, eliminate garbage collector overheads, and significantly simplify the programmer's life. As objects will be deleted at predictable times, this will allow attaching resource management to the objects lifetimes.

Implementation

In the experimental programming language Argentum (https://aglang.org), the idea of UML references is implemented as follows:

A class field marked with "&" represents a non-owning reference (association).
A field marked with "*" represents a shared reference to an immutable object (aggregation).
All other reference fields represent composition (such a field is the sole owner of a mutable object).

Example:

class Scene {
   // The `elements` field holds the `Array` object, that holds
   // a number of SceneItems. It's composition
   elements = Array(SceneItem);

   // The 'focused' field references some `SceneItem`. No ownership
   // It's association
   focused = &SceneItem;
}
interface SceneItem { ... }
class Style { ... }
class Label { +SceneItem;  // Inheritance
    text = "";  // Composition: the string belongs to label

    // The `style` field references an immutable instance of `Style`
    // Its immutability allows to share it among multiple parents
    // It's aggregation
    style = *Style;
}

The resulting class hierarchy:

Example (continued) object creation:

// Make a `Scene` instance and store it in a variable.
// `root` is a composite reference (with single ownership)
root = Scene;

// Make a `Style` instance; fill it using a number of initialization methods;
// freeze it, making it immutable with the help of *-operator.
// and store it in a `normal` variable that  is an aggregation reference
// (So this `Style` instance is shareable)
normal = *Style.font(times).size(40).weight(600); 

// Make a Label instance, initialize its fields and store it in a `scene.elements` collection
root.elements.add(
   Label.at(10, 20).setText("Hello").setStyle(normal));

// Make a non-owning association link from `scene` to `Label`
root.focused := &root.elements[0];

Resulting objects and interconnection hierarchy:

The constructed data structure provides several important integrity guarantees:

root.elements.add(root.elements[0]);
// Compilation error: the object Label can have only one owner.

normal.weight := 800;
// Compilation error: `normal` is an immutable object.

root.focused.hide();
// Compilation error: there is no check-for and handling-of a lost `focused` reference.

But Argentum not only watches over the programmer (and slaps their wrists), it also helps.
Let's try to fix the above compilation errors:

// @-operator makes deep copies.
// Here we add a copy of the label to the scene.
// This copy references the copy of the text, but shares the same Style instance.
root.elements.add(@root.elements[0]);

// Make a mutable copy of the Style instance,
// modify its `weight`,
// freese this copy (make it immutable-shareable)
// and store it back to the variable `normal`.
normal := *(@normal).weight(800);

// Check if associative link pointes to the object and protect if from being deleted
// if it is not empty, call its method.
// after that remove the protection.
root.focused ? _.hide();  // if root.focused exists, hide _it_

All operations for copying, freezing, thawing, deletion, passing between threads, etc., are performed automatically. The compiler constructs these operations using objects fields' association-composition-aggregation declarations.
For example the following construction:

newScene := @root;

...makes the full deep copy of Scene with correct topology of internal interconnections:

Automatically generated copy of the scene subtree with the preservation of the topology of internal references.

This operation follows well defined rules:

All sub-objects by composition references, that should have a single owner, are copied cascading.
Objects that are marked as shared with aggregation references (e.g., Style) are not copied, but shared.
In the copied scene, the 'focused' field correctly references the copy of the label, because copy operation distinguishes internal and external references:
- All references to the objects that are not affected by this copy operation, point to the original.
- All internal references point to the copied instance preserving the topology of the original data structure.

Why Argentum automates operations:

It ensures memory safety
It ensures absence of memory leaks (making the garbage collector unnecessary).
It guarantees timely object deletion, enabling automatic management of resources other than RAM through RAII, like automatically closing files, sockets, handles, etc.
It ensures the absence of corruptions in the logical structure of the object model.
It relieves the programmer from the routine manual implementation of these operations.
It makes the data structures and code virtual-memory-friendly. Because garbage doesn't pile up and is never evicted from RAM but instead disposed of in a timely manner.

Interim Results

The Argentum language is built on a new, but already familiar UML reference model that is free from the limitations and drawbacks of garbage-collected, reference-counted, and manually memory-managed systems. As of today, the language includes: parameterized classes and interfaces, multithreading, control structures based on optional data types, fast type casts, very fast interface method calls, modularity and FFI. It ensures memory safety, type safety, absence of memory leaks, races, and deadlocks. It utilizes LLVM for code generation and produces stand-alone executable applications.

Argentum is an experimental language. Much remains to be done: numerous code generation optimizations, bug fixes, test coverage, stack unwinding, improved debugger support, syntactic sugar, etc., but it is rapidly evolving, and the listed improvements are in the near future.

The project's homepage: https://aglang.org.
The Windows demo can be found here github.com/karol11/argentum/releases:

In the next article I'm going to cover the semantics of operations on association-composition-aggregation (ACA-pointers) and their implementation in Argentum.

Any questions and suggestions are warmly welcomed.