
Design Philosophies of Developer Tools - fogus
http://stuartsierra.com/2011/08/30/design-philosophies-of-developer-tools
======
SwellJoe
I feel like a lot of problems in software come from lack of understanding of
things that were figured out by previous generations of developers. That's not
to say there aren't improvements to be found in modern software projects; just
that sometimes there's a lot of reinventing the wheel, badly, because folks
don't understand the beautiful simplicity and power of the UNIX system.

I suspect the fact that git exhibits a _deep_ comprehension of that history is
one reason git pretty much took over the mindshare for DVCS in record time.
Where it took years for Subversion to oust CVS, and numerous DVCS systems had
been plodding along for years, git was the obvious leader seemingly overnight.

So many projects have vastly over-engineered interfaces and component
architecture and such, with a huge variety of interdependencies, often
proudly, as though it is a benefit.

~~~
dasil003
The other thing about git, though, is that it's a manageable project. Linus
thought through how he thinks source control should work, and then designed a
robust and brilliant repository structure first, with the tools growing up
around that solid conceptual base.

Comparing that against the general madness of the Ruby ecosystem seems unfair.
Why not compare the state of unix utilities as a whole, which also have their
incompatibilities? Granted, Unix and POSIX in particular are far and away
beyond the kind of standardization that exists in the Ruby world, and of
course that leads to stable (yet powerful) interfaces that strongly benefit
the ecosystem as a whole, but look at the time and resources it took to get to
that point. Expecting that somehow the developers on a new programming
language could wade through the lessons in Unix history and somehow spring
forth a perfect Ruby dependency solution that was nothing but an improvement
over the past is a bit unrealistic.

~~~
SwellJoe
I wasn't really judging the Ruby ecosystem. I don't actually know enough about
it to know, though our Ruby on Rails and RoR application installers in
Virtualmin have been destroyed beyond repair on all but the very latest Linux
distros, by the dependency chain and the very rapid change to new Ruby
versions; mostly due to how crazy fast Ruby gems evolves and how eagerly it
breaks backward compatibility. I was speaking more in general terms. Every
major ecosystem I can think of, from languages like Ruby, Python, PHP, and
Perl, to CMS like Joomla (which is horrific) and Drupal, to Linux desktops,
spend a lot of time reinventing wheels, usually badly.

------
substack
Reading the section on ruby reminds me of the things that I take for granted
in node.js right now owing to the long history of package management and
module systems that it builds upon.

It's super nice having the dependencies specified by semvers in a package.json
and installed locally in a project node_modules directory so that libraries
can't step on each others toes.

The "Don’t use Bundler version X with RVM version Y" can be specified directly
in the package.json and concurrent versions of module dependencies even work
without incident in the same project.

~~~
PLejeck
NPM is by far the best package manager ever. We all owe Isaac so much booze
for that.

------
drothlis
The stability of most unix tools' interfaces is wonderful. With the rise of
tools like bash-completion, even the output of a tool's '--help' option[1] or
debug output[2] needs to be stable.

[1] [http://anonscm.debian.org/gitweb/?p=bash-completion/bash-
com...](http://anonscm.debian.org/gitweb/?p=bash-completion/bash-
completion.git;a=blob;f=bash_completion;h=03d8942#l784)

[2] <http://david.rothlis.net/tools/case_studies/#bash_completion>

------
PLejeck
I would be curious to see an analysis of the Node Package Manager (npmjs.org)
and the general Node package structure.

NPM is basically encapsulated into one command (npm), and there are no ways
for modules to modify the way Node itself works, without the permission of
other modules, plus NPM automatically resolves dependencies and ensures that
things Just Work.

------
andrewflnr
I'm not clear on exactly what design philosophy the Ruby ecosystem is supposed
to embody. I guess it's something to do with the way everything modifies and
uses everything else, but it doesn't coalesce into a single idea in my mind.
Maybe it's just a matter of my not having much experience with it.

~~~
PLejeck
One word: "clusterfuck"

------
zachrose
How does Rubygems modify the behavior of the Ruby interpreter?

~~~
substack
Presumably by modifying `require_paths` and therefore changing how `require`
behaves.

