The 'It Just Works' Philosophy
The primary appeal of Fish is its powerful set of features that work immediately after installation. For proponents, this is a massive win for productivity. While other shells like Bash or Zsh can be heavily customized to achieve similar results, they
often require managing complex configuration files and third-party plugins. Fish, by contrast, provides smart autocompletions, syntax highlighting that validates commands in real-time, and intuitive command history recall out of the box. An engineer who values a polished, ready-to-go experience sees this as a clear advantage. They can start being productive instantly without spending hours tinkering with a .bashrc or .zshrc file. This camp argues that a tool should come with sensible defaults, allowing them to focus on their actual work, not on building their tools.
The POSIX Compliance Sticking Point
The most significant and controversial aspect of Fish is its intentional lack of POSIX compliance. POSIX is a set of standards that ensures shell scripts behave consistently across different Unix-like systems. Bash, the default shell on most Linux distributions and older macOS versions, adheres to this standard. Critics argue that by breaking from POSIX, Fish introduces a different scripting language, making it fundamentally incompatible with countless existing scripts and online tutorials. For a senior engineer who frequently works on servers, in containers, or collaborates on projects with standardized scripting, this is a deal-breaker. They argue that using a non-standard shell can lead to bad habits that cause subtle bugs when writing portable scripts. Adhering to a common standard, they contend, is more important for team cohesion and long-term maintenance than individual convenience.
Interactive Use vs. Scripting Discipline
Defenders of Fish counter that the POSIX debate is often misunderstood. They argue that a developer's interactive shell (the one they type into) doesn't have to be the same one used for scripting. A script can and should declare which interpreter it needs (e.g., `#!/bin/bash`) to run correctly, making the user's personal choice of shell irrelevant for script execution. From this perspective, Fish is optimized to be the best interactive shell, not a universal scripting environment. Those who adopt this workflow use Fish for its day-to-day interactive benefits but continue to write scripts in Bash for portability. However, opponents find this context-switching inefficient, arguing that it creates a mental disconnect and forces them to remain fluent in two different shell syntaxes.
Opinionated Design vs. Infinite Customization
Ultimately, the disagreement reflects a classic developer divide. One side favors the Zsh model: a highly extensible and customizable framework that can be molded into whatever the user wants, even if it requires significant effort. The other side prefers the Fish model: an opinionated tool that makes deliberate design choices for the user, prioritizing a great experience out of the box over limitless flexibility. Some engineers find Fish's constant suggestions and colorful interface 'busy' and distracting, preferring a quieter, more minimal environment. Others find those same features indispensable for catching typos and working faster. There is no right answer; it's a fundamental difference in what engineers expect from their tools and how they prefer to interact with their systems.
