This is factually wrong. Vim is emphatically not just a text editor - it is a full-fledged IDE, weighing in at over a million lines of code, with syntax-highlighting, HTML rendering, a completion system, complex multi-window and multi-buffer support, a multi-language plugin API, regular expression engine, complex key rebinding system, jump-to-definition functionality (tags system), and its own scripting language and interpreter for such.

A "text editor" in the Unix tradition edits text, nothing more - something like nano or pico, composed with other utilities for things like regexp matching (using grep externally) and shelling out to tmux or the X window manager for multi-window and tabs/split support. It certainly does not contain its own embedded scripting language.

Firefox is also definitely not a "does that one thing and does it well" tool - it's incredibly complex, at over 21 million lines of code, and contains its own cryptography, web rendering engine, PDF reader, developer console with its own IDE, remote development tools, tab system, UI toolkit, JS runtime, JS API implementation, and plugin API. It used to even be able to interact with FTP servers - and all this in a single, monolithic tool.

Firefox is exactly the opposite of the Unix philosophy is almost every way imaginable. Saying that it "does one thing and does it well" is about as true as saying that the Boost C++ libraries or the Windows OS "do one thing and do it well" - it's only true if you define that "one thing" to encapsulate all of the stuff that the tool happens to do, which is not the way that the Unix philosophy uses it.

Counting lines of code is not relevant at all.

Claiming that "x isn't relevant" is completely meaningless unless you describe how it isn't relevant.

Lines of code is a decent heuristic for complexity. An actually-used (so you aren't generating spurious lines of code) 21 Mloc program is more complex than a 21 Kloc one. So, it seems pretty darn relevant to me.

This sounds like the same discussion I always see about the SRP. I think the root of it is that whether you're following the SRP can always be true, depending on how you're looking at your code. If the one thing your code is supposed to do is "run the whole application" then putting everything into one file called "Application" sounds just fine. If the one thing your code is supposed to do is "add 2+2" then abstracting a module that only adds 2+2 seems just fine.

I always found the SRP too vague to be useful for actual decision making, it seems to just lead to arguments where everybody (and nobody) is correct. "Unix philosophy" sounds like it is just about as vague, or am I just really missing something that everyone else gets?

I really liked Dan's reasoning around SRP

"SRP mandates that you separate the rendering and business logic of the component. As a developer, having these living in different places leads to an administrative chore of chaining identical fields together. The greater risk is that this may be a premature optimisation preventing a more natural separation of concerns emerging as the codebase grows, and as components emerge that “do one thing well” and that are better suited to the ___domain model of the problem space."

Vim is not only a text editor, it's a fully extensible and programmable IDE. It's only perceived light in relationship with the Eighty Megabytes And Constantly Swapping monster.

>Firefox is a web browser, it does that one thing and does it well

Can't you justify anything that way? You called easily say that the rendering engine, JavaScript engine, etc should all be split up into programs that do that well.

Well, the Javascript engines certainly can be and have been. Firefox's is less popular than Chrome's but that's hardly the central point.

You can justify anything that way - that's why it's a useless non-argument. "Windows does one thing and does it well: computer-y things"

And emacs is.. well, okay, that one's not a good example.

Emacs follows the UNIX philosophy. All it does is interpret elisp.