Design Philosophies of Developer Tools | Hacker News Reader

Design Philosophies of Developer Tools

stuartsierra.com

49 pointsfogus11 comments

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.

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.

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.

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.

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

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...

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

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.

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.

One word: "clusterfuck"

How does Rubygems modify the behavior of the Ruby interpreter?

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

Reply on news.ycombinator.com