[shellac]

It's a minor thing, but:

> Most of my open source work followed Unix philosophy, so the packages did one thing at a time.

Nobody has suggested that libc -- to take the most obvious example -- is against the Unix philosophy. Debates occur around whether whether commands / daemons do too much (recent poster child being systemd) or aren't composable.

[0xAFFFF]

If anything, the left-pad debacle has shown that NPM package granularity has gone way too small, at a point where package overhead was outweighing the package simplicity benefits.

[whostolemyhat]

Left-pad was made at a time when tree-shaking wasn't really around, so it was good practice to only include the functions you needed to avoid making websites too heavy. If you just needed a small function then it'd be silly to include a huge utility library like Underscore.

[layer8]

What does the size or granularity have to do with the incident? If the author had combined all his 350+ packages into one (or had had a more comprehensive text-utils.js package) and pulled that instead, the issue would have been at least as severe?

I don’t think such small packages are sensible, in particular when versioned separately, but I also don’t see how the left-pad debacle has shown that.

[lmm]

> Nobody has suggested that libc -- to take the most obvious example -- is against the Unix philosophy.

Plenty of people have suggested that. I'll suggest it for you now if you like. The modern form of libc is very much against the unix philosophy; traditional Unix had a much simpler libc where many functions were just syscalls; some parts of today's libc were hived off into separate libraries like libm, and other parts like NSS and convoluted DNS resolution frameworks just didn't exist at all.

[cjs_ac]

The obverse to 'do one thing' is that you have to do the whole thing.

[IshKebab]

The "unix philosophy" is a useless philosophy - perhaps worse than useless even - because "one thing" is not well defined, so in practice it adds nothing and just leads to arguments.

You could say that Eclipse does "one thing" - being an IDE platform - but I don't think anyone thinks that's what the Unix devs meant. Similarly I don't think they meant for people to write libraries that contain one 11-line function.

The actual advice should be something like "programs/libraries shouldn't try to do too much or too little". How do you know how much is too much or too little? Like so many programming guidelines the answer is you need taste and experience.

[qsort]

I feel like "do one thing and do it well" is an oversimplification:

(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them

---

[1] https://archive.org/details/bstj57-6-1899/page/n3/mode/2up

[freehorse]

> because "one thing" is not well defined

That's what a philosophy is, gives you some general guideline and you have to use your thinking to figure out how to apply it in specific circumstances. It does not substitute that thinking neither does it prevent stupid choices, it helps guide you in a higher/strategic level. It is not responsible for people making stupid decisions.

[Lerc]

If you consider it from the point of view of how "clear is the scope?" Then it makes more sense.

Libc implementations have a very clear scope, clear enough that you can point to the specification. That is their 'one thing' do what that spec says.

Eclipse however, doesn't have that singular goal. You would be hard pressed to say how many of Eclipse's tentacles is a clear push towards being an ide. What should a completely finished version of Eclipse that met all it's goals look like?

Similarly the one thing could be "be a c preprocessor" or be a full "c compiler" these are both "one thing"s even while one is a subset of the other.

The intention of "do one thing, and do it well" is not to limit the scope but to show the boundary of the scope and to commit to doing everything within that boundary

By making your one thing "a full c compiler" you should be committing to doing everything that someone making a c preprocessor is doing, and to the same standard. The Unix philosophy should be considered a warning not to neglect components because you are working on a larger system.

You can't do everything, but you don't have to. If others are following the same principles then many of the parts of what you need will be done to a high standard by others.

[kragen]

The Unix philosophy tells you how to get a powerful interactive programming environment on a 16-bit minicomputer where the maximum text segment size was 64KiB. The libc I'm using on this cellphone is 1MiB, 16× bigger. So at least 90% of libc is against the Unix philosophy.

I don't see how anyone could read the Lions book or APUE, on one hand, and the pthreads manual or the ANSI C specification of setlocale(), on the other, and come to the conclusion that they represent the same philosophy. It's like thinking Ayn Rand is an exponent of the same philosophy as Epicurus; it betrays a staggering lack of sincere engagement with either one.