Greetings, > Using a prefork or similar technique done by apache f.ex can really > accelerate such tasks, so a minimal vi editor with nice features can be > really achieved by delegating all such features to external apps or > libraries a minimal application with a dozen external modules, processes, pipes to achieve the required functionality will be 10x slower and nastier than if these things were built in.
Modularization isn't a cure-all - it has a direct impact on performance, "user-friendliness", maintainability, and especially on simplicity. It's also hard to get right. <anecdote> when I last used wmii a long time ago, a lot of functionality was off the core. To listen for keybindings, you had to interface with a virtual filesystem (because plan9 is automatically cool, right?) - with a cli util that you had to start everytime to read/write/touch a file. To drive the keybinding logic, you had to run a complicated shell script (at least this was the default solution) that read keyboard events through pipes and wrote back control commands, everything through this vfs util. So to make me able to start a new terminal, you had to continuously run at least 3 extra processes and a lot of code. How is this minimal or suckless? No wonder a lot of us flocked to dwm... I believe in fast, simple, but powerful CLI interfaces rather than programs pared down to bones. To be quite honest, I'd miss the color functionality from ls, dpkg argument-expansion from my shell, or the standard arguments from all the GNU software - if this means supporting --version in true, so be it. I'm not running an embedded system, a 97k ls doesn't hurt me too much. (I realize this is the same argument MS supporters use to validate the existence of a multi-gigabyte Visual Studio etc, but let's be realistic people, 97k ls in 2009 vs. Visual goddamn Studio.) Best regards, Mate