Live data from Hacker News

Left-Pad (2024)

azerkoculu.com

101–110 of 224 posts

Re: Left-Pad (2024)

#101

Earlier quoted context omitted.

Yeah, but this also happened to a colleague of mine who created the pug templating package. It's so long ago now that I forget what it was originally called but, basically, he'd chosen a name that infringed somebody else's trademark. I'm not a trademark law expert but the thing about trademarks is they have to be defended or the holder can lose the exclusivity of the mark. So my friend sensibly caved in and changed t…

>pug templating package. It's so long ago now that I forget what it was originally called jade, iirc. still best html/xml/etc templating package out there, jsx/tsx can't compare

Yes! Thank you! That was it. I still use pug in a side project because it works really well and would just be way too much hassle to untangle and migrate.

I just looked jade up on npm and it's still there, so the company that wanted Forbes to change the name didn't even want to publish a package by the looks of it.

Re: Left-Pad (2024)

#102

Earlier quoted context omitted.

I mean if you’re the CEO of a package manager then you should probably have thought that one through a little bit more? Maybe ask one of the engineers what would happen?

"CEO of a package manager" sounds like a 15 year old, and from their behavior was just an old 15 year old.

The older I get, the more I realise how many adults are just 15 year olds wearing suits to make themselves feel more grown up.

Re: Left-Pad (2024)

#103
post #16

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.

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

[deleted]

Re: Left-Pad (2024)

#104
post #70

Earlier quoted context omitted.

The 3rd option is the one Azer describes in the post: He wants to remove his stuff, but isn't sure what the right way to do it is, so he asks npm. npm provides him with a set of scripts to run to remove his stuff, and he, presuming that it's "ok" if npm told him to go ahead and run them, runs them. The impact isn't especially important to him, But since npm just gave him a set of scripts with an implicit "oh okay you…

What would the alternative have looked like? If NPM would have prevented the depublishing, he would have made a scene and in the worst case, they would have looked bad. How they actually handled it, the library author got full freedom but also full responsibility

> If NPM would have prevented the depublishing, he would have made a scene and in the worst case, they would have looked bad.

I mean he says he asked them to remove all his packages, expecting them to do so gradually, following whatever mitigation strategy they felt appropriate (e.g. some kind of warning and fadeout process), and instead they gave him a script to do it immediately so he did that.

Re: Left-Pad (2024)

#105
post #50

Earlier quoted context omitted.

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

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 inte…

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

Re: Left-Pad (2024)

#106
post #16

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.

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

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.

Re: Left-Pad (2024)

#107
post #16

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.

[deleted]

Re: Left-Pad (2024)

#109
post #16

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.

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

Re: Left-Pad (2024)

#110
post #72
post #65

I remember this incident and it is one of many reasons I was turned off by the entire JS ecosystem.

How come this is related to JS only? Like, if I own a python/rust/go/whatever public package named XYZ and later a company named XYZ forces me to release the package because of trademark issues, and I cannot do but obey, all my packages may run the same luck, so anybody relying on them would be screwed. I don’t see how the size of the package matters here.

To your point, in JVM the convention is to package based on domain name so you don't have this type of issue.

But I think the GP's point is that the cultural in other ecosystems didn't lean as heavily into "there's a package for that®" as JS does

Post reply on HN