6 ms·

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

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 1y ago
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 1y ago
  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.
  - yurishimo 1y ago
    You're missing the point. Nobody with a serious background in software development should ever need to pull in a package to pad a string or check if a number is even or odd. If someone is smart enough to use a package manager, they should be more than capable to write a function to pad a string (assuming the standard library doesn't include one already)!
    - baobabKoodaa 1y ago
      While you are correct, the problem compounds when popular package developers choose to use tiny packages. I don't need left-pad. But maybe I need react-starter-kit. Now, imagine that react-starter-kit has a dependency to markdown-js-blobber, which has a dependency to make-text-nice, which has a dependency to left-pad. In this scenario I am now "pulling in a package to pad a string". If I am "smart enough to use a package manager", I should be "more than capable to write..." an alternative to react-starter-kit..?
      - jstanley 1y ago
        The onus there is on the "make-text-nice" developer, not an eventual user of "make-text-nice".
      - yurishimo 1y ago
        I don't place any blame here on the person using `react-starter-kit` and I think you're being a bit obtuse to suggest otherwise. It's the original person who pulled in a package for <10 lines of code who is to blame.
        baobabKoodaa 1y ago
        I provided the real reason for the high download counts of these packages.
    - gpiancastelli 1y ago
      However, JavaScript never had a proper standard library. Combine this to mainstream education teaching that you should always reuse code when possible instead of "reinventing the wheel", and web shops agreeing to it because "using libraries saves time", and it's easy to understand the "popularity" of left-pad. To a certain extent, and to the best of my knowledge, those things haven't really changed.
    - eviks 1y ago
      How does serious background help the argument for wasting your time writing code that's already been written. By the way, why should serious people use padding from the standard library?
      - yurishimo 1y ago
        I would argue that a leftpad/is-odd package is the equivalent of writing a for loop. The time it cost you to search the internet, download the package, and rerun your build script cost more than the time to write the function from scratch and the behavior is indentical. Duplicate code across the ecosystem is fine. Not every function must be unique for an entire programming language.
        eviks 1y ago
        What about the time it cost you to search the internet, read the docs, and use the one from std? How many seconds does each variant take (with hot/cold memory cache?) And the behavior could also be worse, there is no guarantee of perfection. The last argument is too generic to offer any guidance. Why is it better for this function be duplicated?? Should it not be part of std to avoid uniqueness?
        Izkata 1y ago
        > Should it not be part of std to avoid uniqueness? > > > > (assuming the standard library doesn't include one already)
        eviks 1y ago
        This doesn't address the should
      - beej71 1y ago
        The standard library is a far less risky dependency than third-party libraries. It's far more reliable in presence and behavior.
    - eddd-ddde 1y ago
      Ironically I feel like this is something LLMs will improve. Now anyone can type "create left pad function" and it will essentially just vendor in the existing code.
- layer8 1y ago
  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.
  - baobabKoodaa 1y ago
    [flagged]
    - anonymars 1y ago
      Instead of teasing, can you just tell us what the difference is between unpublishing N small packages versus one large package containing the same set of functionality?
      - baobabKoodaa 1y ago
        Well, I sure can! When you develop software by gluing together 1000000 small packages, you now have 1000000 points of failure. When you develop software by... you know, writing trivial things by yourself instead of downloading a package... you have maybe 100 points of failure instead of 1000000 points of failure. Having 100 points of failure is better than having 1000000 points of failure. Note that in this example you are writing trivial things by yourself instead of adding a package. So we're not taking the same set of code as dependencies, slicing it into different number of slices, instead we're taking less code as dependencies.
        layer8 1y ago
        I don’t quite follow the reasoning. You can reverse the argument: When one package breaks, then — all else being equal — more dependents are likely to be affected if it is a large package with many functions than if it is a tiny package with just one function. What made the left-pad incident prominent is that the package had so many dependents. That’s due to how frequently its functionality is useful, not due to its size. And in general these are inversely correlated characteristics. Yet another argument: If any given function breaks, then the affected dependents are invariant under the granularity of packaging. Exactly those dependents will break that make use of the given function, regardless of the packaging. The one argument I could buy is that depending on a larger number of packages increases the likelihood of depending on unreliable maintainers. Still, in the case of left-pad that isn’t entirely convincing, since the maintainer in question maintained so many packages.
IshKebab 1y ago
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 1y ago
  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 https://archive.org/details/bstj57-6-1899/page/n3/mode/2up
  - PetitPrince 1y ago
    I agree with that. And like most rule of thumbs, it's very useful to go beyond the prescriptive part and ask yourself "why". And as qsort described, doing "one thing well" enables you to have desirable traits (easy testability, low cost refactoring, etc.).
- freehorse 1y ago
  > 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.
cjs_ac 1y ago
The obverse to 'do one thing' is that you have to do the whole thing.
deleted 1y ago
[deleted]
lmm 1y ago
> 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.
kragen 1y ago
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.

0xAFFFF 1y ago

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 1y ago
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.
- yurishimo 1y ago
  You're missing the point. Nobody with a serious background in software development should ever need to pull in a package to pad a string or check if a number is even or odd. If someone is smart enough to use a package manager, they should be more than capable to write a function to pad a string (assuming the standard library doesn't include one already)!
  - baobabKoodaa 1y ago
    While you are correct, the problem compounds when popular package developers choose to use tiny packages. I don't need left-pad. But maybe I need react-starter-kit. Now, imagine that react-starter-kit has a dependency to markdown-js-blobber, which has a dependency to make-text-nice, which has a dependency to left-pad. In this scenario I am now "pulling in a package to pad a string". If I am "smart enough to use a package manager", I should be "more than capable to write..." an alternative to react-starter-kit..?
    - jstanley 1y ago
      The onus there is on the "make-text-nice" developer, not an eventual user of "make-text-nice".
    - yurishimo 1y ago
      I don't place any blame here on the person using `react-starter-kit` and I think you're being a bit obtuse to suggest otherwise. It's the original person who pulled in a package for <10 lines of code who is to blame.
      - baobabKoodaa 1y ago
        I provided the real reason for the high download counts of these packages.
  - gpiancastelli 1y ago
    However, JavaScript never had a proper standard library. Combine this to mainstream education teaching that you should always reuse code when possible instead of "reinventing the wheel", and web shops agreeing to it because "using libraries saves time", and it's easy to understand the "popularity" of left-pad. To a certain extent, and to the best of my knowledge, those things haven't really changed.
  - eviks 1y ago
    How does serious background help the argument for wasting your time writing code that's already been written. By the way, why should serious people use padding from the standard library?
    - yurishimo 1y ago
      I would argue that a leftpad/is-odd package is the equivalent of writing a for loop. The time it cost you to search the internet, download the package, and rerun your build script cost more than the time to write the function from scratch and the behavior is indentical. Duplicate code across the ecosystem is fine. Not every function must be unique for an entire programming language.
      - eviks 1y ago
        What about the time it cost you to search the internet, read the docs, and use the one from std? How many seconds does each variant take (with hot/cold memory cache?) And the behavior could also be worse, there is no guarantee of perfection. The last argument is too generic to offer any guidance. Why is it better for this function be duplicated?? Should it not be part of std to avoid uniqueness?
        Izkata 1y ago
        > Should it not be part of std to avoid uniqueness? > > > > (assuming the standard library doesn't include one already)
        eviks 1y ago
        This doesn't address the should
    - beej71 1y ago
      The standard library is a far less risky dependency than third-party libraries. It's far more reliable in presence and behavior.
  - eddd-ddde 1y ago
    Ironically I feel like this is something LLMs will improve. Now anyone can type "create left pad function" and it will essentially just vendor in the existing code.
layer8 1y ago
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.
- baobabKoodaa 1y ago
  [flagged]
  - anonymars 1y ago
    Instead of teasing, can you just tell us what the difference is between unpublishing N small packages versus one large package containing the same set of functionality?
    - baobabKoodaa 1y ago
      Well, I sure can! When you develop software by gluing together 1000000 small packages, you now have 1000000 points of failure. When you develop software by... you know, writing trivial things by yourself instead of downloading a package... you have maybe 100 points of failure instead of 1000000 points of failure. Having 100 points of failure is better than having 1000000 points of failure. Note that in this example you are writing trivial things by yourself instead of adding a package. So we're not taking the same set of code as dependencies, slicing it into different number of slices, instead we're taking less code as dependencies.
      - layer8 1y ago
        I don’t quite follow the reasoning. You can reverse the argument: When one package breaks, then — all else being equal — more dependents are likely to be affected if it is a large package with many functions than if it is a tiny package with just one function. What made the left-pad incident prominent is that the package had so many dependents. That’s due to how frequently its functionality is useful, not due to its size. And in general these are inversely correlated characteristics. Yet another argument: If any given function breaks, then the affected dependents are invariant under the granularity of packaging. Exactly those dependents will break that make use of the given function, regardless of the packaging. The one argument I could buy is that depending on a larger number of packages increases the likelihood of depending on unreliable maintainers. Still, in the case of left-pad that isn’t entirely convincing, since the maintainer in question maintained so many packages.

IshKebab 1y ago

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 1y ago
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 https://archive.org/details/bstj57-6-1899/page/n3/mode/2up
- PetitPrince 1y ago
  I agree with that. And like most rule of thumbs, it's very useful to go beyond the prescriptive part and ask yourself "why". And as qsort described, doing "one thing well" enables you to have desirable traits (easy testability, low cost refactoring, etc.).
freehorse 1y ago
> 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.

cjs_ac 1y ago

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

deleted 1y ago

[deleted]

lmm 1y ago

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

kragen 1y ago

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.