DEV Community: Jigar Gosar

DRY Is a Lie: Confusion by Design

Jigar Gosar — Sat, 12 Jul 2025 06:44:47 +0000

The hidden cost of abstraction in modern software culture

TL;DR: Abstraction isn’t free. DRY isn’t sacred. And “clean code” isn’t always readable. We’ve built a culture that worships design principles without questioning their cost. It’s time we did.

🧱 The Gospel of Clean Code

When you write duplicate lines of code, your brain reflexively itches to extract them into an abstraction—not because the code demands it, but because the culture does.

You extract a function—or a class—and then try to pigeonhole it into another use case, forcing reusability where it wasn’t meant to fit.

And just like that, your local reasoning—perfectly at home in its corner—is marooned in the frozen tundra of remote abstractions.

Tracing indirection turns your mind into a stack of context switches, each deeper than the last.

But hey—it’s DRY. SOLID. Reusable.

Right?

Until it breaks your brain.

🧨 The Lie Beneath DRY

DRY—Don’t Repeat Yourself—was never meant to mean “never write the same line twice.” It was about not duplicating knowledge. Don’t let the same business rule live in two places.

But we turned it into a reflex. A dogma. A purity test.

And that’s when DRY becomes a lie.

We avoid repetition—and trade it for something worse: indirection, entanglement, and fragile abstractions.

🧩 The Hidden Cost of Abstraction

Abstraction is powerful—but it’s not free. Every time you extract something, you’re making a bet:

That the duplication is real, not just superficial
That the abstraction will hold up under future change
That the people reading your code will understand what you’ve hidden

When those bets don’t pay off, the cost is brutal:

Cognitive load: You’re jumping between files, tracing layers, decoding generic names—just to understand what’s happening.
Rigidity: Your abstraction locks you into a structure that resists change.
Fear: No one wants to touch the “shared” thing because it’s used in 12 places and no one remembers why.

But at least it’s DRY.

📚 The Cultural Blind Spot

We’ve built an entire culture around abstraction, and almost no vocabulary for its cost.

We have bookshelves full of Clean Code, Design Patterns, and SOLID Principles. We have workshops on “how to write reusable components” and “how to architect for scale.”

But where are the books titled:

The Cost of Abstraction?
Refactoring to Duplication?
The Art of Intentional Repetition?

They don’t exist—because we’ve treated abstraction as a virtue, not a tradeoff. We’ve made avoiding duplication a rule—and reasoning an afterthought. And we’ve confused “reusable” with “good.”

🧘‍♂️ Local Reasoning Over Abstraction

Here’s a radical idea: what if we made local reasoning our highest design virtue? Not reusability. Not elegance. Not DRYness. Just code you can understand without chasing it across files and layers.

Because the real cost of abstraction isn’t in the code—it’s in your head. It’s the number of things you have to remember just to answer: “What does this actually do?”

Repetition isn’t the enemy. Indirection is.

Because the truth is: duplication is easy to fix. Bad abstractions are hard to unwind.

🔄 The Alternatives We Ignore

There are principles that push back against abstraction dogma. But they’re rarely taught with the same reverence:

AHA (Avoid Hasty Abstractions): Don’t abstract until duplication becomes painful.
YAGNI (You Aren’t Gonna Need It): Don’t build for a future that may never come.
Rule of Three: Duplicate once, maybe twice. Abstract on the third time—if it still makes sense.

These aren’t anti-design. They’re pro-timing. They recognize that the cost of a wrong abstraction is higher than the cost of a little duplication.

🧨 The Callout

So here’s the challenge: Next time you reach for that abstraction—pause. Ask yourself:

Am I solving a real problem, or just avoiding repetition?
Will this abstraction make the code easier to change—or harder?
Am I doing this for understanding, or for comfort?

And if the answer isn’t clear—don’t abstract. Repeat yourself. On purpose. With pride.

Because sometimes, the cleanest code is the code that’s just… repeated.

If this idea of local reasoning struck a nerve—good. You’re not alone. In a follow-up post, we’ll dive deeper into the real complexity we forgot to measure: not code complexity, but cognitive complexity. Because the hardest part of software isn’t writing it—it’s thinking about it.

Footnote: Acronyms like WTFW (Why The Framework Works) and GRR (Generalized Refactor Regret) are real-ish, at least emotionally.

🔍 Tracking Global Keyboard Shortcuts in Node.js (Windows)

Jigar Gosar — Sun, 06 Jul 2025 15:10:46 +0000

Capturing global keyboard shortcuts like Ctrl + C or Shift + Alt + S can be incredibly useful for building productivity tools, real-time overlays, or accessibility utilities. But doing it cleanly — without logging noisy or repeated key events — requires careful handling of modifier keys and key state.

This post walks through how to build a global key combo tracker in Node.js on Windows, and explains the logic behind each part of the implementation.

🧩 The Challenge

Most global key listeners log every key event — including repeated Ctrl, Shift, or Alt presses — which leads to noisy, unreadable logs like:

LEFT CTRL
LEFT CTRL
LEFT CTRL
A

To build a clean and useful tracker, we need to:

❌ Ignore modifier keys when pressed alone
✅ Log only meaningful combinations (e.g. Ctrl + A)
✅ Normalize key names like LEFT CTRL → Ctrl
✅ Prevent repeated logs while keys are held
✅ Support global tracking, even when the app is not focused

⚙️ Implementation

1. Install the Listener

We use node-global-key-listener, a native module that captures global key events across the OS.

npm install node-global-key-listener

2. Core Logic

const { GlobalKeyboardListener } = require("node-global-key-listener");

const keyboard = new GlobalKeyboardListener();
const heldModifiers = new Set();
const loggedCombos = new Set();

const MODIFIERS = new Set([
  "LEFT CTRL", "RIGHT CTRL",
  "LEFT SHIFT", "RIGHT SHIFT",
  "LEFT ALT", "RIGHT ALT",
  "LEFT META", "RIGHT META"
]);

keyboard.addListener((e) => {
  const key = e.name.toUpperCase();

  if (e.state === "DOWN") {
    if (MODIFIERS.has(key)) {
      heldModifiers.add(normalizeModifier(key));
    } else {
      const combo = heldModifiers.size > 0
        ? [...heldModifiers, key].join(" + ")
        : key;

      if (!loggedCombos.has(combo)) {
        loggedCombos.add(combo);
        console.log(combo);
      }
    }
  } else if (e.state === "UP") {
    if (MODIFIERS.has(key)) {
      heldModifiers.delete(normalizeModifier(key));
    } else {
      loggedCombos.clear();
    }
  }
});

function normalizeModifier(key) {
  if (key.includes("CTRL")) return "Ctrl";
  if (key.includes("SHIFT")) return "Shift";
  if (key.includes("ALT")) return "Alt";
  if (key.includes("META")) return "Meta";
  return key;
}

🧠 Why This Works

🔹 Modifier Filtering

We define a set of known modifier keys (LEFT CTRL, RIGHT SHIFT, etc.) and track them in heldModifiers. These keys are ignored when pressed alone — they only contribute to a combo.

🔹 Normalization

The OS reports keys like LEFT CTRL and RIGHT CTRL separately. For clarity and consistency, we normalize them to a single label (Ctrl, Shift, etc.) using the normalizeModifier() function.

This ensures that:

LEFT CTRL + A and RIGHT CTRL + A both log as Ctrl + A
The output is clean and human-readable

🔹 Combo Construction

When a non-modifier key is pressed:

If modifiers are held → log the full combo (e.g. Ctrl + A)
If no modifiers are held → log the key alone (e.g. A)

🔹 Duplicate Prevention

We use a loggedCombos set to ensure each combo is logged only once per press. This avoids repeated logs when holding keys.

🔹 Reset on Key Release

When a non-modifier key is released, we clear the loggedCombos set so the next press can be logged again.

🧪 Example Output

Ctrl + C
Shift + Alt + S
Escape
A

✅ Ctrl alone → ignored
✅ A → logged
✅ Ctrl + A → logged once
✅ Holding keys → no spam

🚀 What’s Next?

This Node.js core is a clean foundation for more advanced tools. You could extend it by:

🖼️ Wrapping it in an Electron app with a floating overlay
💾 Logging combos to a file or clipboard
🎨 Styling the UI with themes and transparency
📦 Packaging it as a cross-platform desktop utility

🧠 Conclusion

This project demonstrates how to:

Handle global keyboard input in Node.js
Filter and normalize noisy key events
Design a clean shortcut-tracking system

It’s a great one-day build with real-world utility — and a perfect launchpad for more advanced desktop tools.

You can find the full source code on GitHub: global-key-logger.

Comparing IntelliJ IDEA Navigation Plugins: AceJump, MJump, and KJump

Jigar Gosar — Sun, 06 Jul 2025 11:49:34 +0000

When you’re deep into code, efficient cursor movement is a game-changer. IntelliJ IDEA offers several plugins—AceJump, MJump, and KJump—that bring Vim-style “jump anywhere” navigation. This post breaks down their key features, strengths, and trade-offs to help you pick the right tool for your workflow.

Overview of AceJump

AceJump tags every visible location with short labels, letting you jump in two keystrokes. Beyond character jumps, it offers:

Target Mode: Jump and select whole words in one go.
Line Mode: Jump to line starts, ends, or first non-whitespace char.
Declaration Mode: Skip straight to a symbol’s declaration by repeating the shortcut.
Full-text search: Scrolls off-screen if no match is visible.

Install via Settings → Plugins → Browse Repositories → AceJump.

Overview of MJump

MJump is a fork of KJump with added cross-editor support. Key highlights:

Multi-editor jumps: Navigate across all open editor tabs.
Vim-style modes: Char, word, and line jumps, mapped to MJumpAction, Word0, Line, etc.
IdeaVim integration: Use same <leader><leader> mappings as KJump for a seamless Vim feel.

No default shortcuts—assign your own under Settings → Keymap → MJump.

Overview of KJump

Ported from vim-EasyMotion, KJump focuses on minimal keystrokes:

Quick char jumps: Single or two-character searches.
Word jumps: Jump to any word or words starting with a given char.
Line jumps: Snap to any line on screen.
IdeaVim integration: Use :action KJumpAction mappings in your ~/.ideavimrc for native Vim commands.

Install under the Plugins marketplace, then bind keys via Settings → Keymap → KJump.

Feature Comparison

Feature	AceJump	MJump	KJump
Character jump	Single-char	Single-char	Single-char (`Char1`), two-char (`Char2`)
Word jump	Tag first char of words	Same as KJump modes	Word0, Word1
Line jump	Line Mode (start, non-ws, end)	Same as KJump Line mode	Line
Declaration/Target modes	Declaration & Target modes	—	—
Cross-editor jump	No	Yes	No
IdeaVim integration	Supported	Supported	Supported
Default shortcuts	Ctrl+; variants	None	None
Latest compatibility	Actively maintained	Syncs with new IDEA versions	Basic scaffold maintained

Data sources: AceJump, MJump, KJump

Pros and Cons

AceJump

Pros:
- Versatile modes (declaration, target, line) for both navigation and selection.
- Scrolls to off-screen matches automatically.
Cons:
- Tag clutter if many labels are needed.
- Multiple modes can overwhelm initial learning curve.

MJump

Pros:
- Cross-editor jumps keep you from switching tabs manually.
- Maintained to work with the latest IntelliJ IDEA releases.
Cons:
- Lacks AceJump’s declaration and target modes.
- Still requires manual keymap setup.

KJump

Pros:
- Faithful Vim-EasyMotion experience with minimal keystrokes.
- Clean, straightforward feature set.
Cons:
- No default shortcuts—initial setup required.
- Doesn’t support cross-editor navigation.

Tips for Getting Started

Installation:
- Open Settings → Plugins → Marketplace.
- Search and install your chosen plugin.
Keymap Setup:
- Go to Settings → Keymap.
- Locate AceJump/MJump/KJump and assign easy-to-remember shortcuts (e.g., Ctrl+; for char jumps).

IdeaVim Users:

Add mappings in ~/.ideavimrc, for example:

 nmap <leader><leader>s :action KJumpAction<CR>
 nmap <leader><leader>w :action MJumpAction.Word0<CR>

Adjust for each plugin’s action names.

Conclusion

All three plugins excel at reducing cursor travel, but they serve slightly different needs:

Choose AceJump for advanced modes and rich selection capabilities.
Choose MJump if you jump across multiple editor tabs frequently.
Choose KJump for a lean, EasyMotion-style Vim integration.

Give each a spin and see which one becomes your go-to for lightning-fast navigation. Happy coding!

Looking for even more? Check out IdeaVim-EasyMotion for IdeaVim-native jumps or AceJump-Lite if you want a lightweight variant.

Fixing "monacoEditorPlugin is not a function" Error

Jigar Gosar — Sun, 06 Jul 2025 11:46:41 +0000

If you see the error:

monacoEditorPlugin is not a function

when trying to use Monaco Editor with Vite, it means the official vite-plugin-monaco-editor is not compatible with your setup or is being used incorrectly. The best solution is to use vite-plugin-monaco-editor-esm instead.

How to fix:

Install the correct plugin:

  npm install monaco-editor vite-plugin-monaco-editor-esm --save-dev

Update your vite.config.js:

  import { defineConfig } from 'vite';
  import monacoEditorPlugin from 'vite-plugin-monaco-editor-esm';
  export default defineConfig({ plugins: [monacoEditorPlugin()] });

Use Monaco Editor as usual in your app.

This will resolve the error and allow Monaco Editor to work smoothly in your Vite project.

The Dark Art of Safe Rebasing: Mastering "Onto" in IDEs and CLI

Jigar Gosar — Mon, 23 Jun 2025 06:09:40 +0000

Git rebasing can sometimes feel like deciphering a cryptic incantation—especially when your IDE throws around the term “onto” without clear context. Whether you’re working with the intuitive interface of IntelliJ or the plain commands on the terminal, understanding what “onto” means is essential. At its core, the rule is simple:

The branch on the left-hand side (LHS) is the one that gets rewritten, while the branch on the right-hand side (RHS) remains safe.

In practice: Always have your stable branch (usually main) on the RHS.

In this post, we’ll first break down how IntelliJ presents this concept and then show that the same logic applies on the Git CLI.

1. IDE and "Onto": Understanding How IntelliJ Handles Rebasing

When working with IntelliJ, you’ll often see rebase options that explicitly mention both branches. Typical examples are:

Rebase feature onto main
Rebase main onto feature

Unlike the CLI—which requires you to know which branch is active—IntelliJ clearly displays both sides. But the key is to understand the role each branch plays in the phrase:

Left-Hand Side (LHS):

The branch that appears first. This branch’s commits will be rewritten—essentially, this is the branch that is being “rebased.”
Right-Hand Side (RHS):

The branch following the word “onto.” This branch serves as the stable base, remaining completely untouched during the operation.

Let’s consider the two options:

Option 1: "Rebase feature onto main"

Here, feature (LHS) is the branch whose commits will be replayed, while main (RHS) acts as the solid base. If main is your stable branch, this is the safe and correct operation.
Option 2: "Rebase main onto feature"

In this scenario, main (LHS) would be rewritten, and feature (RHS) would act as the base. If main is your primary, stable branch, this option is dangerous and should generally be avoided.

The Golden Rule in the IDE

To ensure your history remains clean and your stable branch is protected, follow this simple rule in IntelliJ:

Always have your stable branch (typically main) on the Right-Hand Side (RHS).

This positional rule means that when you see an option like “Rebase feature onto main,” you know exactly that the active branch (feature) is rewritten while main stays safe. It transforms what might seem like confusing interface language into a clear, memorable guideline for safe rebasing.

2. CLI and "Onto": Reinforcing the Concept with Command-Line Clarity

The same principle applies when you work on the Git CLI—even if the commands don’t explicitly label branches as “onto.” Consider the common rebase operation:

git checkout feature    # Switch to the branch you want to modify (LHS).
git rebase main         # Rebase the current branch onto 'main' (RHS).

Here’s what happens:

feature (LHS):

Being the branch you’ve currently checked out, feature is the one whose commits will be rewritten. Its history is recreated on top of the base branch.
main (RHS):

This branch is simply used as the foundation for the rebase. It remains as is—untouched and secure.

In both the CLI and the IDE context, the operative idea is identical:

LHS (the branch you’re working on) = Modified,
RHS (the branch you’re rebasing onto) = Safe.

Remember, the mnemonic “Always have main on RHS” reinforces that your stable branch should never be the one being rewritten.

Conclusion

Whether you’re clicking through IntelliJ’s rebase dialog or typing out commands in the terminal, the dark art of safe rebasing boils down to a single, clear rule: Always have your stable branch (commonly main) on the Right-Hand Side (RHS).

In the IDE, the option “Rebase feature onto main” means that your feature branch (LHS) is modified while main (RHS) remains untouched.
On the CLI, the command sequence confirms the same idea—the branch you’re on gets rewritten, and the branch you rebase onto acts as a fixed base.

By understanding and consistently applying this LHS/RHS model, you can confidently navigate Git rebasing without fear of inadvertently rewriting your stable branch. Embrace this rule, and let it be the guiding principle in your every rebase: if it’s not on the RHS, it might be in danger!

Happy rebasing—and may your Git history always be as pristine as you intend it to be!

From Grid to Square: Designing a Fully Adaptive 2048 Board in CSS

Jigar Gosar — Tue, 17 Jun 2025 15:50:56 +0000

When building web applications like a 2048 game, one common challenge is ensuring that your game board always maintains a perfect 1:1 aspect ratio and fits within a dynamically sized area. In our layout, the board resides in the center area between a header and footer whose heights vary based on content. Using modern CSS features, we can build a solution that avoids hardcoded dimensions and JavaScript calculations.

The Layout Breakdown

1. Overall Layout with CSS Grid

We start by splitting the viewport into three rows using CSS Grid.

– Header and Footer rows size to their content (using auto).

– The Center row (using 1fr) automatically fills up the remaining vertical space.

Markup:

<div class="container">
  <div class="header">Header Content</div>
  <div class="center">
    <!-- The board will be placed here -->
  </div>
  <div class="footer">Footer Content</div>
</div>

CSS:

.container {
  display: grid;
  grid-template-rows: auto 1fr auto;
  height: 100vh;
}
.header, .footer {
  background: #ccc;
  padding: 1rem;
  text-align: center;
  flex-shrink: 0;
}

Setting the container height to 100vh ensures the layout fills the entire viewport.

2. Centering the Board: Absolute Positioning

Inside the .center section, the trick is to create a square board that always occupies the maximum space without clipping or stretching. We achieve this by:

– Making the center container position: relative.

– Absolutely positioning the board so that it centers itself within the container using top: 0; right: 0; bottom: 0; left: 0 and margin: auto.

Markup:

<div class="center">
  <div class="board">
    <!-- Internal game grid goes here -->
  </div>
</div>

CSS:

.center {
  position: relative;
  background: #eee;
  overflow: hidden;
}
.board {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  margin: auto;
  aspect-ratio: 1 / 1;
  max-width: 100%;
  max-height: 100%;
  border: 2px solid #333;
  background: #fafafa;
  display: flex;
  align-items: center;
  justify-content: center;
}

Here, the new aspect-ratio property forces the board to stay square, and the maximum constraints ensure it never exceeds the dimensions of the center area.

3. Building the Game Grid Inside the Board

Inside the square board, we build a 4×4 CSS Grid that represents the 2048 game grid.

Markup:

<div class="board-inner">
  <div class="cell">2</div>
  <div class="cell">4</div>
  <!-- Additional cells here -->
</div>

CSS:

.board-inner {
  width: 90%;
  height: 90%;
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-template-rows: repeat(4, 1fr);
  gap: 5px;
}
.cell {
  background: #bbada0;
  border-radius: 4px;
  display: flex;
  align-items: center;
  justify-content: center;
  font-size: 1.5rem;
  color: #776e65;
  font-weight: bold;
}

Using width and height at 90% makes sure the inner grid leaves some padding around the edges of the board.

How It All Comes Together

By combining CSS Grid for the overall layout, flexbox (plus absolute positioning) for centering the board, and the aspect-ratio property for preserving the square shape, we create a responsive board that always looks perfect. The board automatically becomes the largest square possible within the center area without clipping in any direction—even as the header and footer sizes change.

Complete Code

You can copy and paste the following complete code into your project:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <!-- Responsive viewport -->
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Responsive 2048 Board with Perfect Square</title>
  <style>
    /* Global Reset */
    *, *::before, *::after {
      box-sizing: border-box;
      margin: 0;
      padding: 0;
    }
    html, body {
      height: 100%;
      overflow: hidden;  /* Prevent unwanted scrollbars */
      font-family: sans-serif;
    }
    /* Overall layout using CSS Grid: header, center, footer */
    .container {
      display: grid;
      grid-template-rows: auto 1fr auto;
      height: 100vh;
    }
    .header, .footer {
      background: #ccc;
      padding: 1rem;
      text-align: center;
      flex-shrink: 0;
    }
    /* Center area made relative so its child can be absolutely centered */
    .center {
      position: relative;
      background: #eee;
      overflow: hidden;
    }
    /* The board is absolutely centered and constrained by .center,
       and uses aspect-ratio to enforce its square shape. */
    .board {
      position: absolute;
      top: 0;
      right: 0;
      bottom: 0;
      left: 0;
      margin: auto;
      aspect-ratio: 1 / 1;
      max-width: 100%;
      max-height: 100%;
      border: 2px solid #333;
      background: #fafafa;
      display: flex;
      align-items: center;
      justify-content: center;
    }
    /* Internal game grid: a 4x4 board for a 2048 game */
    .board-inner {
      width: 90%;
      height: 90%;
      display: grid;
      grid-template-columns: repeat(4, 1fr);
      grid-template-rows: repeat(4, 1fr);
      gap: 5px;
    }
    .cell {
      background: #bbada0;
      border-radius: 4px;
      display: flex;
      align-items: center;
      justify-content: center;
      font-size: 1.5rem;
      color: #776e65;
      font-weight: bold;
    }
  </style>
</head>
<body>
  <div class="container">
    <!-- Header -->
    <div class="header">
      <h1>Header Content</h1>
      <p>Dynamic header info (height may vary).</p>
    </div>
    <!-- Center area containing the board -->
    <div class="center">
      <div class="board">
        <!-- Internal 4x4 game grid -->
        <div class="board-inner">
          <div class="cell">2</div>
          <div class="cell">4</div>
          <div class="cell"></div>
          <div class="cell">2</div>
          <div class="cell"></div>
          <div class="cell">8</div>
          <div class="cell"></div>
          <div class="cell">16</div>
          <div class="cell"></div>
          <div class="cell">2</div>
          <div class="cell">4</div>
          <div class="cell"></div>
          <div class="cell">8</div>
          <div class="cell"></div>
          <div class="cell">2</div>
          <div class="cell"></div>
        </div>
      </div>
    </div>
    <!-- Footer -->
    <div class="footer">
      <p>Footer Content</p>
      <p>Additional footer details here.</p>
    </div>
  </div>
</body>
</html>

Final Thoughts

The key to this responsive design was combining several modern CSS techniques:

• CSS Grid for Layout – Splitting the page into header, center, and footer with grid-template-rows: auto 1fr auto ensures proper allocation of space.

• Relative & Absolute Positioning – Making the center area position: relative and the board position: absolute (with margin: auto) centers the board perfectly.

• Aspect Ratio – The modern aspect-ratio property keeps the board square automatically.

• Maximum Constraints – max-width and max-height ensure that the board never exceeds its container.

These approaches eliminate the need for JavaScript or hardcoded calculations and let the browser do the heavy lifting. Happy coding, and feel free to experiment with these techniques in your own projects!

Elm vs. The Feature-Addiction Epidemic in Programming

Jigar Gosar — Fri, 16 May 2025 09:42:14 +0000

Elm has always taken a distinctive path—one that shuns the "more is better" mentality in favor of a lean, well-curated set of language constructs. In many mainstream languages like JavaScript, Python, and even Haskell, developers often find a hefty toolbox of features that promise flexibility and convenience. Elm, however, intentionally leaves many of these tools at the door. And while that might seem limiting at first glance, it is precisely this excision of "extra" features that makes Elm so robust, predictable, and enjoyable to work with.

In this post, we'll first explore additional examples of features that popular languages offer but that Elm leaves out. Then, we'll dive into several uniquely powerful Elm features—elements so carefully designed that you won't find their counterparts in any other language.

What's Missing in Elm: Features Other Languages Take for Granted

1. Object-Oriented Constructs

Other Languages:

Languages like JavaScript, Java, and C# embrace object-oriented programming with classes, inheritance, and polymorphism. These languages let you define objects with mutable state, along with constructors, methods, and inheritance hierarchies.

Elm's Choice:

Elm forgoes classes and inheritance entirely. Instead, it models data with immutable records and pure functions. By avoiding object-oriented concepts, Elm reduces the potential for side effects and unpredictable state mutations.

Example Comparison:

JavaScript:

  class Animal {
    constructor(name) {
      this.name = name;
    }
    speak() {
      console.log(this.name + ' makes a noise.');
    }
  }

  // Usage:
  const myAnimal = new Animal("Dog");
  myAnimal.speak(); // Output: "Dog makes a noise."

Elm:

  type alias Animal =
      { name : String }

  init : String -> Animal 
  init name =
      { name = name }

  speak : Animal -> String 
  speak animal =
      animal.name ++ " makes a noise"

  -- Usage:

  myAnimal = 
      init "Dog"

  -- Returns: "Dog makes a noise"
  result = 
      speak myAnimal  

  -- Alternative: returns same value while 
  -- logging "Speaking: Dog makes a noise" to console (side-effect)
  result_ = 
      Debug.log "Speaking" (speak myAnimal)

In Elm, the absence of classes forces you to focus entirely on transforming data without hidden side effects.

Note: While `Debug.` functions work in development, Elm's compiler refuses to compile production code containing them.*

2. Looping Constructs

Other Languages:

While modern languages like JavaScript provide functional methods (map, filter, reduce), they still require imperative looping constructs for complex patterns because recursion leads to stack overflow on large datasets. They must rely on mutable state and imperative control flow for performance-critical iteration.

Elm's Choice:

Elm also provides List.map, List.filter, and List.foldl, but when these aren't sufficient, Elm relies on explicit recursion with pattern matching. Elm's compiler automatically optimizes tail recursion into efficient loops, eliminating stack overflow risks. More importantly, recursion naturally encapsulates problem-solving by breaking complex iteration into clear base cases and sub-problem divisions, leading to more comprehensible code structure.

Example Comparison:

JavaScript (forced to use loops):

  // Must use loops - recursive version would crash on large arrays
  function findFirstInvalid(items) {
      // Recursion here would cause: RangeError: Maximum call stack size exceeded
      for (let i = 0; i < items.length; i++) {
          if (items[i] < 0) {
              return items[i];
          }
      }
      return null;
  }

Elm (recursion with clear problem decomposition):

  -- Safe recursion with natural problem breakdown
  findFirstInvalid : List Int -> Maybe Int
  findFirstInvalid items =
      case items of
          [] -> Nothing                    -- Base case: empty list
          first :: rest ->                 -- Sub-problem: check first, recurse on rest
              if first < 0 then
                  Just first
              else
                  findFirstInvalid rest    -- Tail call optimized to loop

Pattern matching with recursion encourages thinking about problems structurally—what are the building blocks, what are the stopping points. Elm optimizes tail calls for efficiency.

3. Exception Handling vs. Explicit Error Types

Other Languages:

Languages such as Java, Python, and even JavaScript (with try-catch) provide built-in mechanisms for exception handling. These constructs often let you trap and handle errors through runtime mechanisms.

Elm's Choice:

Elm eliminates runtime exceptions entirely. There's no try/catch block. Instead, error handling is done explicitly with types like Maybe and Result. This forces you to design for failure from the start, ensuring errors are caught at compile time rather than letting bugs propagate at runtime.

Example Comparison:

Ruby:

  # Form validation with if-else and exception handling
  def validate_user_name(name)
    if name.nil? || name.strip.empty?
      raise ArgumentError, 'Name cannot be empty'
    elsif name.length < 2
      raise ArgumentError, 'Name must be at least 2 characters'
    elsif name.length > 50
      raise ArgumentError, 'Name cannot exceed 50 characters'
    else
      name
    end
  end

  # Usage with exception handling:
  def handle_form_submit(name_input)
    begin
      valid_name = validate_user_name(name_input)
      "Hello, #{valid_name}!"
    rescue ArgumentError => error
      "Error: #{error.message}"
    end
  end

Elm:

  -- Form validation with Result type
  validateUserName : String -> Result String String
  validateUserName name =
      if String.isEmpty name then
          Err "Name cannot be empty"
      else if String.length name < 2 then
          Err "Name must be at least 2 characters"
      else if String.length name > 50 then
          Err "Name cannot exceed 50 characters"
      else
          Ok name

  -- Usage with Result handling:
  handleFormSubmit : String -> String
  handleFormSubmit nameInput =
      case validateUserName nameInput of
          Ok validName ->
              "Hello, " ++ validName ++ "!"
          Err errorMessage ->
              "Error: " ++ errorMessage

In Elm, explicit error types help create bulletproof code that compilers can fully check.

4. Mutable Variables and In-Place Updates

Other Languages:

Most mainstream languages allow you to reassign variables and mutate objects. Languages like JavaScript or Python let you change values or update objects directly, which can sometimes lead to unexpected side effects.

Elm's Choice:

Elm takes a hard stance on immutability. Once a value is bound, it never changes behind your back, allowing you to reason about your code with complete confidence—no hidden mutations can break your assumptions or corrupt your program's logic. This might seem constraining at first, but it eliminates an entire class of bugs related to state mutation.

Example Comparison:

Python:

  counter = 1
  counter += 10  # Mutable update

Elm:

  counter : Int
  counter =
      1  -- Once assigned, counter's value cannot change

  -- This would cause a compiler error:
  counter = 
      counter + 10  -- ❌ Cannot redefine 'counter'

  -- Correct approach - create new value:
  newCounter : Int
  newCounter =
      counter + 10  -- ✅ Creates new value instead of mutating

This immutable approach ensures predictable, reliable code behavior.

5. Reflection, Macros, and Metaprogramming

Other Languages:

Languages like Java and C# give you a reflection API for runtime introspection. Meanwhile, Lisp or Rust allow metaprogramming with macros to generate or transform code at compile time.

Elm's Choice:

Elm deliberately omits such facilities. There is no reflection, no runtime type introspection, and no macros. This design decision prevents the "magic" that can obscure a program's behavior and hinder maintainability.

Example Comparison:

C# (a glimpse of reflection):

  Type myType = typeof(MyClass);
  Console.WriteLine(myType.Name);

Elm: Elm's type system is entirely static and does not support runtime inspection, forcing the designer to plan all structures explicitly.

By removing these reflective and metaprogramming capabilities, Elm ensures that nothing "hidden" lurks in the language—every operation is transparent and explicit.

6. Asynchronous Programming Primitives

Other Languages:

JavaScript (with promises and async/await), Python (with asyncio), and even modern Java provide native syntax for asynchronous operations and concurrency, which can simplify managing background tasks.

Elm's Choice:

Though Elm supports interactivity and concurrency through its task and command model, it does not have language-level asynchronous primitives like promises or async/await. Instead, Elm uses a model of commands, subscriptions, and the Elm Architecture to handle side effects. This forces you to manage asynchronous operations in a way that preserves the purity of the core language.

Example Comparison:

JavaScript (using async/await):

  async function fetchData() {
    let response = await fetch('https://example.com/data');
    return response.json();
  }

Elm:

  -- HTTP command
  fetchUserData : Cmd Msg
  fetchUserData =
      Http.get
          { url = "https://example.com/user"
          , expect = Http.expectJson GotUserData userDecoder
          }

  -- Update function handles all possible outcomes
  update : Msg -> Model -> ( Model, Cmd Msg )
  update msg model =
      case msg of
          GotUserData result ->
              case result of
                  Ok userData =>
                      ( { model | user = Just userData, loading = False }
                      , Cmd.none
                      )
                  Err httpError =>
                      ( { model | error = Just "Failed to load user", loading = False }
                      , Cmd.none
                      )

In Elm, every possible outcome must be handled explicitly—success, network errors, parsing errors—making async operations predictable and robust.

Notice the verbosity trade-off: While Elm's code is significantly longer than JavaScript's 3-line async function, this "verbosity" is actually explicit safety. The JavaScript version can silently fail with unhandled promise rejections, network timeouts, or parsing errors, while Elm's compiler forces you to acknowledge and handle every possible failure case upfront. This upfront investment in handling edge cases prevents mysterious runtime failures and makes debugging trivial—you always know exactly where and why something went wrong.

The Other Side of the Coin: Powerful Elm Features Others Don't Offer

While Elm deliberately omits many features available in other languages, it also introduces innovations that are hard to find anywhere else. Here are some of the uniquely powerful characteristics of Elm:

1. Guaranteed Absence of Runtime Exceptions*

Elm's design ensures that if your code compiles, it will run without unexpected runtime errors. By relying on a robust type system and requiring explicit error handling via Maybe and Result, Elm provides near-absolute guarantees of reliability. No null, no undefined, and no unhandled exceptions means that once your program passes the compiler, you can trust it to operate predictably.

*Edge cases like stack overflows, integer division by zero, and rare Html.map bugs can still occur.

2. Human-Friendly Error Messages

Elm's compiler is renowned for its exceptionally clear and friendly error messages. When something goes wrong, Elm doesn't just point out that there's a problem—it gives you detailed hints and suggestions for how to fix it. This design philosophy dramatically improves the developer experience, especially for beginners, and is an area where many languages fall short.

3. Forced Purity and Predictable Data Flow

Elm's commitment to immutability and pure functions is not simply a restriction—it's a feature that radically simplifies reasoning about code. In most languages, you often have to track mutable state and worry about side effects. In Elm, every function is pure by design. This means you get explicit, unidirectional data flow that naturally leads to cleaner and more maintainable code. The "Elm Architecture" itself has inspired frameworks in other ecosystems, thanks to its clarity in managing state transitions.

4. A Minimal Surface Area for Maximum Clarity

By stripping away many syntactic constructs—from imperative looping constructs to reflection and macros—Elm forces you to think more explicitly about the problems you're solving. This minimalism isn't about lacking features; it's about eliminating the unnecessary so that every construct you do use carries clear meaning. In doing so, Elm creates a development experience where bugs related to hidden side effects or ambiguous code are practically nonexistent.

Summing It Up

Elm isn't trying to be a watered-down version of other languages—it's a deliberate experiment in minimalism and clarity. While it omits many features you might expect from a modern programming language—such as object-oriented constructs, mutable state, imperative looping constructs, reflection, and even built-in async syntax—it makes up for it with powerful guarantees that no other language quite offers:

No runtime surprises: Compile-time error checking and explicit error handling mean fewer surprises when your code runs.
Clear, transparent code: Every part of your code is explicit; nothing is hidden behind reflective or metaprogramming "magic."
A model for pure functional programming: The Elm Architecture enforces unidirectional data flow, immutability, and pure functions, offering a level of predictability that's increasingly rare.

By selectively choosing what to leave out, Elm pushes its developers toward better design, more maintainable code, and ultimately, a more delightful programming experience. If you're coming from languages that offer every convenience imaginable but struggle with complexity and hidden bugs, Elm's disciplined approach might just change the way you think about software design.

Interested in exploring more about how Elm's minimalist choices lead to robust, error-free applications? Consider diving deeper into Elm's architecture and error messaging—perhaps even comparing it firsthand with your experiences in imperative or object-oriented environments. The trade-offs made in Elm remind us that sometimes, having less truly means gaining more.

Edit 1: Based on feedback in comments, special shoutout to @phollyer.

Perfection Is Not Adding More, It’s Removing What’s Unnecessary—The Story of Elm

Jigar Gosar — Fri, 16 May 2025 09:09:54 +0000

Introduction

Elm is a fascinating anomaly in the world of programming languages. While most languages evolve by adding features, Elm has taken the opposite approach—removing unnecessary complexity while maintaining its practicality for large-scale projects. This philosophy has made Elm one of the most stable, predictable, and enjoyable languages to work with. Unlike other languages that continuously introduce new syntax and bloated standard libraries, Elm has remained lean and focused, proving that simplicity is a strength rather than a limitation.

In this post, we’ll explore the history of Elm, its philosophy of feature removal, and how this approach has contributed to its longevity and reliability. We’ll also highlight real-world projects that have successfully used Elm and examine specific features that have been removed from the language and its core libraries.

The Origins and Evolution of Elm

Elm was created by Evan Czaplicki in 2012 as part of his thesis at Harvard University. Initially designed as a functional language for building web applications, Elm quickly gained traction due to its strong type system, immutability, and absence of runtime exceptions. Over the years, Elm has influenced other technologies, including Redux, Rust, Vue, Roc, and Gren.

Elm’s early versions included features that were later removed to streamline the language. Unlike JavaScript, Python, or even Haskell, Elm does not chase trends or introduce unnecessary complexity. Instead, its development has focused on removing features that do not contribute to its core philosophy.

Why Elm Removes Features Instead of Adding Them

Most programming languages evolve by adding more features—syntax enhancements, expanded standard libraries, and new paradigms. Elm takes the opposite approach: features that introduce complexity, unpredictability, or redundancy are eliminated to keep the language simple and practical. Let’s explore some of the most significant removals in Elm’s history.

1. Removal of Native Modules

Earlier versions of Elm allowed developers to write native JavaScript modules to extend functionality. While this was convenient, it violated Elm’s core guarantees of no runtime exceptions and predictable behavior.

Native modules could lead to uncontrolled side effects, making debugging difficult. By removing them, Elm ensured that all code written in Elm remains safe, type-checked, and fully verified by the compiler. This move solidified Elm’s reputation for reliability—if your Elm code compiles, it works.

2. Elimination of Higher-Kinded Types

Functional languages like Haskell rely heavily on higher-kinded types, which allow for abstract structures like monads, functors, and lenses. While these features are powerful, they also introduce steep learning curves and additional complexity.

Elm deliberately avoids higher-kinded types, making its type system intuitive and approachable. The result? Developers can focus on practical application development rather than wrestling with complex abstractions.

3. Standard Library Simplifications

Elm’s standard library has undergone multiple reductions to maintain simplicity and predictability. Some notable removals include:

No implicit number-to-string conversions → Instead of allowing automatic type conversion, Elm forces explicit formatting using String.fromInt or String.fromFloat, making type handling more predictable.
No complex data structures → Elm favors simple lists and records over intricate abstractions like monads or lenses, ensuring that code remains straightforward and readable.

4. No Custom Operators

Unlike many functional languages, Elm does not allow developers to define custom operators. While operators can make code more concise, they often introduce ambiguity—different developers might interpret the same symbols differently.

By enforcing explicit function calls, Elm keeps code clear, maintainable, and beginner-friendly.

5. Removal of Case Guards

Elm previously supported case guards, a feature common in languages like Haskell and OCaml. However, they were removed due to their syntactic complexity and tendency to make pattern matching less predictable.

Instead, Elm encourages explicit conditional logic, making the flow of programs easier to follow and debug.

6. The Removal of Custom Side Effects

Elm’s approach to managing side effects is one of its most defining characteristics. In earlier versions, developers could define custom effects tailored to their application. However, Elm later removed the ability to create arbitrary effects, restricting developers to a predefined set of managed side effects.

This decision wasn’t about limiting power—it was about preserving predictability. Many languages allow developers to introduce uncontrolled side effects, leading to hidden bugs, unexpected interactions, and difficult debugging. Elm avoids these pitfalls by offering a structured effect management system, including:

HTTP requests
WebSockets
Ports (interacting with JavaScript)
Time-based events
Randomness

By restricting side effects to only those officially supported by Elm, developers no longer need to worry about unintentional bugs, race conditions, or concurrency issues. Every Elm program follows the same uniform rules, making debugging easier and system behavior entirely predictable.

Successful Projects That Use Elm

Elm’s minimalist approach doesn’t just work in theory—it has been successfully adopted by major companies and large-scale projects:

1. NoRedInk

A leading education platform that helps students improve their writing skills. Elm’s stability ensures that NoRedInk’s complex interface remains predictable and maintainable.

2. Rakuten

The global e-commerce giant Rakuten has used Elm in its frontend applications, benefiting from type safety and easy refactoring.

3. Norway’s Railway System

A surprising but powerful application—parts of Norway’s railway infrastructure use Elm for mission-critical systems, proving its reliability in high-stakes environments.

4. Blissfully

A SaaS company that utilizes Elm’s predictable and structured development environment to scale its platform efficiently.

5. GWI

A global market research company integrating Elm for frontend stability and maintainability in a competitive industry.

Why Elm’s Minimalism Works for Large Projects

Even though Elm rarely changes, it remains highly effective for building large-scale applications. Why?

1. Stability Over Time

Projects written in Elm years ago still work without modification. Unlike JavaScript frameworks that demand constant upgrades, Elm applications remain stable and easy to maintain.

2. Predictable Performance

Elm’s strong type system and immutability prevent runtime exceptions, ensuring applications run smoothly and consistently.

3. No Bloat, Just Essentials

Elm’s small core libraries contain only the necessary functions, preventing feature creep. Developers can focus on building applications instead of navigating unnecessary complexities.

4. Joyful Development Experience

Elm’s compiler messages are legendary—clear, informative, and helpful, making debugging a delight instead of a frustration. Developers spend less time fixing errors and more time writing quality code.

Conclusion

Elm stands as a testament to the power of removing features rather than adding them. By focusing on simplicity, stability, and practicality, Elm has remained one of the most enjoyable and reliable programming languages for web development. While other languages chase trends and introduce bloat, Elm thrives by doing less, but doing it well.

If you’re tired of languages that constantly change and introduce unnecessary complexity, Elm might be the perfect choice for your next project.

What do you think of Elm’s minimalist approach? Have you experienced the benefits of its simplicity firsthand? Let’s discuss in the comments!

Elm’s Type Inference: Crafting Sound Code with Friendly Compiler

Jigar Gosar — Thu, 15 May 2025 14:05:15 +0000

Elm’s type system lets you write clear, correct code without the clutter of explicit type annotations. Its friendly compiler not only infers types automatically but also provides helpful error messages that guide you toward writing sound code. In this post, we'll explore practical examples that highlight how Elm’s type inference and compiler feedback enhance code correctness and simplify your development experience.

Letting the Compiler Work for You

When coding in Elm, the compiler deduces the types of values based on their usage. This lets you focus on application logic rather than on managing repetitive type declarations.

Automatic Type Inference in Action

Consider a simple arithmetic function:

square x =
    x * x

Since the multiplication operator (*) applies only to numbers, Elm infers that x must be a number. No extra annotations are needed, keeping your code concise and correct.

Similarly, look at a greeting function:

greet name =
    "Hello, " ++ name

Elm automatically infers that name is a string because it’s concatenated with another string. This approach minimizes boilerplate while ensuring your program behaves as expected.

Working with Collections

Elm’s type inference extends naturally to list operations. For example, take a function that doubles each element in a list:

doubleAll nums =
    List.map (\x -> x * 2) nums

Here, Elm deduces that nums is a list of numbers because of the arithmetic operation inside the lambda function. This automatic inference guarantees that your list operations remain correct, and it helps you confidently refactor code later.

Higher-Order Functions and Function Composition

Elm handles functions passed as arguments seamlessly. Consider this example:

applyTwice func x =
    func (func x)

If you define a helper function like:

double x = x * 2

Then calling applyTwice double 3 allows the compiler to infer that double must be of type Int -> Int and that x is an Int. This automatic type matching ensures that your functions compose correctly, promoting code correctness throughout your program.

Friendly Compiler Guidance: Learning from Mistakes

Elm’s compiler not only infers types automatically but also provides clear error messages when things go wrong. This friendly guidance helps you quickly identify and fix errors, ensuring that your code remains sound.

Example 1: Mixing Types in Arithmetic

Imagine a function that mistakenly combines a number with a string:

wrongFunction x =
    x + "5"

The compiler detects the type mismatch and outputs an error like:

The right side of (+) is a String, but it needs to be a number.

5|    x + "5"
           ^^^
Hint: Use String.toInt or String.toFloat to convert the String into a number.

This message clearly pinpoints the error and suggests a remedy, making it easier to maintain correctness.

Example 2: Boolean Operator Mismatch

Suppose you mistakenly mix types in a Boolean expression:

wrongCombine a =
    a && "True"

Since the && operator requires Boolean values, the compiler might produce an error similar to:

The right side of (&&) is a String, but it needs to be a Bool.
Hint: Ensure both operands in a boolean expression are of type Bool.

This clear feedback helps you quickly adjust the code for proper Boolean logic.

Example 3: Mismatched If-Else Branches

A common error is returning different types from an if-else expression:

checkValue x =
    if x > 0 then "Positive" else 0

Elm expects both branches to return the same type. The compiler then outputs:

The 'if' branch returns a String, but the 'else' branch returns an Int.
Hint: Ensure both branches return the same type.

This guidance prompts you to harmonize the types, ensuring your conditional expressions are correct.

Conclusion

Elm’s type inference combined with its friendly compiler guidance creates an environment that promotes code correctness while reducing development overhead. By automatically inferring types and offering clear, actionable feedback when errors occur, Elm allows you to focus on writing your application logic confidently, knowing the compiler has your back.

Embrace this balanced approach and enjoy a smoother, more efficient coding experience where every error message is a stepping stone toward crafting sound, reliable code.

Happy coding!

A Deep Dive into Types in Elm: Unraveling the Magic of Static Typing

Jigar Gosar — Tue, 13 May 2025 15:21:37 +0000

Elm stands out as a language that not only simplifies building web applications but also fortifies your code against a host of runtime errors. At the heart of this reliability lies Elm’s robust type system—a mechanism that ensures every value in your program behaves exactly as intended. In this post, we’ll explore what types in Elm are all about, how they make your code safer, and why embracing them leads to more robust and maintainable programs.

What Are Types and Why Do They Matter?

In programming, types are labels that define the nature of data. They specify what kind of values you can work with—for example, numbers, text, or more complex structures. In Elm, types aren’t just annotations; they’re guarantees. When you write a function, you’re providing explicit clues (or letting Elm infer the clues) about what kind of data the function takes in and what it outputs. This explicitness helps catch potential issues long before your code is executed, meaning fewer surprises at runtime.

Elm’s compiler leverages these types to ensure that:

Every value is used consistently. The compiler checks the flow of data and makes sure that numbers don’t suddenly turn into text midway through your function.
Errors are caught early. If there’s a mismatch—say, a function expecting an integer ends up receiving a string—the compiler halts the process and provides you with a friendly, descriptive error message.
Your code is self-documenting. Even without running the program, anyone reading your type signatures can understand the intended use of each function.

The process that allows Elm to automatically deduce types from your code is known as type inference. This means that while you’re encouraged to write type annotations for clarity, Elm can intelligently analyze the patterns and infer types, reducing the burden on the programmer without sacrificing safety.

Exploring Elm’s Primitive Types

Elm comes with several built-in types that serve as the foundation for almost every program.

The `Int` Type: Whole Numbers

age : Int
age = 25

The Int type handles whole numbers such as counts, ages, or any other integer values used throughout your application.

The `Float` Type: Numbers with Decimals

pi : Float
pi = 3.1415

Whenever you need precision with decimals—whether it’s for geometry, physics calculations, or financial numbers—the Float type is your go-to.

The `String` Type: Text Data

greeting : String
greeting = "Hello, Elm!"

Text in your applications—be it user messages, titles, or logs—is represented as a sequence of characters using the String type.

The `Bool` Type: Logical Values

isWeekend : Bool
isWeekend = False

Logical decisions in your program (choices between two paths) are managed by the Bool type which holds either True or False.

Custom Types and Pattern Matching: Tailoring Data to Your Domain

As your applications grow, you’ll encounter situations where primitive types are not enough. Custom types let you create data structures that precisely reflect the needs of your program.

Defining Custom Types

Imagine you’re modeling pets in your application:

type Animal
    = Dog
    | Cat
    | Bird

This Animal custom type can only be a Dog, a Cat, or a Bird. Such definitions not only constrain the possible values but also enable Elm’s compiler to enforce exhaustive checks.

Pattern Matching with Custom Types

Once you’ve defined a custom type, handling each possibility becomes both natural and safe using pattern matching:

describeAnimal : Animal -> String
describeAnimal animal =
    case animal of
        Dog ->
            "This is a playful dog!"
        Cat ->
            "This is a curious cat!"
        Bird ->
            "This is a cheerful bird!"

Here, every possible variant of Animal is addressed. The compiler ensures that if you ever decide to add a new kind of animal, you’ll be reminded to update your pattern matches accordingly.

Type Aliases: Clarifying Complex Structures

When dealing with more intricate data, type aliases help by giving names to complex structures. This boosts readability and helps keep your code organized.

A Practical Example of a Type Alias

type alias Person =
    { name : String
    , age : Int
    }

Instead of repeatedly writing out the record structure for a person, you simply use Person as a shorthand. This also serves as clear documentation for what constitutes a person in your application. For example:

jigar : Person
jigar = { name = "Jigar", age = 30 }

Polymorphism: The Flexibility of Generic Types

Elm also supports polymorphic functions, which means you can write functions that work over many types. Take the classic map function as an example:

map : (a -> b) -> List a -> List b

Here, a and b are type variables representing any type. This flexibility lets you apply a function seamlessly over a list of elements, no matter what data type they hold.

Type Inference: The Compiler’s Magic

One of Elm’s greatest strengths is its ability to infer types, sparing you from writing out every type signature. Consider a simple addition function:

addNumbers x y =
    x + y

Even without a type annotation, Elm deduces that x and y must be numbers (either Int or Float). This powerful feature:

Simplifies code writing, allowing you to focus on logic rather than bookkeeping,
Catches mistakes early, as any mismatch in the inferred type will trigger an informative compiler error,
Promotes cleaner code, eliminating unnecessary annotations while still ensuring type safety.

In Conclusion

Elm’s type system is more than just a safety tool—it’s a comprehensive design philosophy that guides you towards writing clear, error-resistant code. By understanding and leveraging primitive types, custom types, type aliases, and polymorphic functions, you not only make your code safer but also more readable and maintainable.

Elm’s robust type inference further enhances this journey by reducing boilerplate and catching errors before your application even runs. Whether you’re adding two numbers, handling a complex data structure, or defining your own types to mirror real-world entities, Elm’s type system is there to ensure that every value finds its rightful place in your program.

What intrigues you most about the world of Elm’s type system? Are you ready to dive even deeper, perhaps exploring advanced patterns like recursive types or error management strategies? The possibilities are endless, and your journey into Elm’s rigorous yet friendly type system is only just beginning. Happy coding!

Elm: Guarantees Over Guidelines—Eliminate Bugs, Not Just Reduce Them

Jigar Gosar — Tue, 13 May 2025 15:14:25 +0000

Elm vs. Functional Conventions: Guarantees That Eliminate Entire Classes of Errors

Elm's strict guarantees provide structural safety that functional conventions in multi-paradigm languages simply can't enforce. Let's look at some concrete examples of how Elm eliminates errors that would require discipline in other languages:

Example 1: Eliminating Null References (No Runtime Exceptions)

In JavaScript or TypeScript, developers rely on conventions like avoiding null or checking for undefined:

function getName(user?: { name: string }) {
  return user ? user.name : "Unknown"; // Manual check required
}

Miss the check, and you’ll face runtime errors!

In Elm, this isn’t even a possibility—its type system requires all values to be handled explicitly:

getName : Maybe String -> String
getName maybeName =
    case maybeName of
        Just name -> name
        Nothing -> "Unknown" -- No accidental `null`

The compiler forces exhaustive handling, eliminating null-related crashes entirely.

Example 2: Enforcing Pure Functions

In JavaScript, functional purity relies on developer discipline:

let count = 0; 

function increment() {
  count += 1; // Mutates external state, leading to unexpected bugs
}

Without strict enforcement, side effects sneak into code.

In Elm, functions are pure by design. You simply cannot modify outside state:

increment count = count + 1 -- Always returns a new value, no hidden state mutation

By enforcing purity at the language level, Elm prevents unintended state changes altogether.

Example 3: Exhaustive Case Analysis Prevents Edge Case Errors

In TypeScript, developers must manually ensure every possible case is handled:

type Status = "Success" | "Error" | "Loading";

function handleStatus(status: Status) {
  if (status === "Success") {
    return "Operation complete";
  } else if (status === "Error") {
    return "Something went wrong";
  }
  // Missing "Loading" case—leads to undefined behavior
}

Elm requires handling all cases explicitly, preventing these oversights:

type Status = Success | Error | Loading

handleStatus : Status -> String
handleStatus status =
    case status of
        Success -> "Operation complete"
        Error -> "Something went wrong"
        Loading -> "Please wait..."

No forgotten cases—no silent failures!

Conclusion: Why Elm Wins Over Developer Discipline

Functional conventions in multi-paradigm languages can reduce errors, but they rely on developers following best practices—an inherently fragile approach.

Elm ensures correctness by design, eliminating entire classes of errors rather than simply reducing their likelihood. With guarantees like enforced purity, exhaustive case handling, and immutability, developers spend less time debugging and more time building robust, maintainable applications.

The Importance of Exhaustive Case Statements: Why Every Possibility Matters

Jigar Gosar — Tue, 13 May 2025 14:51:30 +0000

In programming, unexpected runtime errors frequently hide in unhandled branches of logic. Exhaustive case statements force developers to consider every possible input explicitly, resulting in safer, more maintainable, and robust code. In this post, we’ll explore what makes a case statement exhaustive, see concrete examples in Elm, discuss how TypeScript handles similar patterns, and highlight the extra verbosity and convention-dependence of achieving exhaustiveness in TypeScript.

What Is an Exhaustive Case Statement?

An exhaustive case statement (or pattern matching) requires that every possible variant of a data type is explicitly handled. Imagine designing a function that operates on a union type where disregarding even one possibility could lead to unexpected behavior at runtime. Enforcing exhaustiveness is like ensuring you’ve catered to every dietary need at a dinner party—it prevents a scenario where some guest’s requirement is accidentally overlooked.

Exhaustive Case Statements in Elm

Elm is renowned for its robust type system and for insisting that functions be total—meaning every possible input must yield an output. When writing a case statement in Elm, the compiler automatically checks that every variant of your union type is handled.

For example, consider a simple union type for fruits:

type Fruit
    = Apple
    | Banana
    | Orange

A corresponding function to describe each fruit might look like this:

describeFruit : Fruit -> String
describeFruit fruit =
    case fruit of
        Apple ->
            "A crisp apple that's both sweet and tart."

        Banana ->
            "A smooth, ripe banana perfect for a quick snack."

        Orange ->
            "An orange bursting with vitamin C!"

Since every declared variant—Apple, Banana, and Orange—has been addressed, the Elm compiler is content. Should you later extend the type:

type Fruit
    = Apple
    | Banana
    | Orange
    | Grape

the compiler will immediately flag that describeFruit lacks a branch for Grape, enforcing a timely update and preventing potential runtime issues.

Exhaustive Pattern Matching in TypeScript

TypeScript, while powerful with union types, does not provide native exhaustive pattern matching. By default, it will not force you to account for every possibility in a switch statement. Instead, you must rely on established patterns to simulate this behavior.

Here’s a similar example in TypeScript:

type Fruit =
  | { kind: "apple" }
  | { kind: "banana" }
  | { kind: "orange" };

function describeFruit(fruit: Fruit): string {
  switch (fruit.kind) {
    case "apple":
      return "A crisp apple with a tangy flavor.";
    case "banana":
      return "A smooth, ripe banana, ready to eat.";
    case "orange":
      return "An orange bursting with vitamin C!";
    default: {
      // The `never` type here ensures that if a new variant is added, a compile-time error occurs.
      const exhaustiveCheck: never = fruit;
      throw new Error(`Unhandled fruit: ${JSON.stringify(exhaustiveCheck)}`);
    }
  }
}

In this TypeScript code, the default case uses an assignment to a variable of type never. This manual check will catch any missing cases during the development process, but it relies entirely on the developer to include this convention. Without this extra clause, TypeScript will not enforce exhaustiveness, and errors could slip past unnoticed.

The Verbosity of TypeScript

One of the key differences between Elm and TypeScript in this context is the verbosity and discipline required on the TypeScript side. Whereas Elm’s compiler automatically enforces that every branch is covered, TypeScript demands the following:

Extra Code: You need to write additional boilerplate (such as the default case with the never check) for every switch statement that you want to be exhaustive.
Developer Discipline: Without a built-in mechanism to ensure exhaustiveness, the safety net entirely depends on coding conventions. If the convention isn’t applied consistently, unhandled cases may lead to runtime issues.
Manual Maintenance: As your union types evolve, ensuring that the manual pattern matching remains exhaustive requires vigilant maintenance, whereas Elm handles these changes for you automatically.

This reliance on conventions makes TypeScript more verbose and, potentially, more error-prone compared to languages with built-in exhaustive checking. Developers need to remember to incorporate and maintain these safeguards in every relevant part of their code.

Comparing Exhaustiveness: Elm vs. TypeScript

Let’s break down the performance of exhaustiveness in both languages:

Aspect	Elm	TypeScript
Compiler Guarantees	Automatically verifies totality of pattern matching.	Relies on manual implementation (e.g., using the `never` pattern).
Code Safety	High – Missing cases trigger compile-time errors automatically.	Moderate – Missing cases require discipline to catch using conventions.
Ease of Refactoring	Changes in union types immediately enforce necessary updates.	Developers must manually update the switch statements, which can lead to oversights if not managed carefully.

Elm’s built-in exhaustive checks provide a seamless experience, whereas TypeScript offers developer-driven methods that require extra attention.

Why Does Exhaustiveness Matter?

Enhanced Reliability: By forcing every possible input to be accounted for, exhaustive case statements reduce the risk of runtime errors.
Improved Maintainability: As your data types evolve, exhaustive checks act as a guide, highlighting areas needing updates, thus easing the maintenance and refactoring process.
Clear Design Intent: Code that explicitly handles every possibility naturally communicates its intent and logic, making it easier for future developers to understand and extend.
Compiler Assistance: In languages like Elm, the compiler’s enforcement of exhaustiveness ensures that no case is accidentally omitted. In TypeScript, while this is simulated through conventions, the extra boilerplate in turn serves as a constant reminder to consider every possibility.

Looking Ahead

While we’ve spotlighted Elm's built-in exhaustive checking and TypeScript's more verbose, convention-driven approach, the principles remain broadly applicable. Several modern languages—including Haskell, Rust, and Swift—offer their own strategies to enforce complete handling of possible cases. Delving into these aspects can provide fresh insights into designing robust, maintainable software.

For additional exploration, you might consider:

Advanced Pattern Matching Techniques: Study how nested patterns and guards can further enforce logical integrity in your functions.
Leveraging Compiler Feedback: Discover how different languages use compiler feedback to drive safer coding practices.
Designing for Scalability: Learn how ensuring exhaustive coverage can make your codebase easier to extend as new features are added.

By embracing exhaustive case statements—whether automatically enforced like in Elm or manually maintained as in TypeScript—you’re not merely writing code; you're constructing a robust framework that stands the test of time and evolving requirements.

Are you intrigued by these patterns? How do you balance the trade-off between brevity and safety in your projects? Whether you’re leaning into Elm’s compiler guarantees or meticulously applying manual checks in TypeScript, every extra line of code is an opportunity to make your logic more resilient and your development process more predictable.