4 ms·

This convinced me the issue is not with people, it's with the system. If the author chose Markdown for their blog and yet can't seem to spare a single minute to

by lucb1e 6y ago

This convinced me the issue is not with people, it's with the system. If the author chose Markdown for their blog and yet can't seem to spare a single minute to read up on how it works, then I guess we can't expect people on HN, stackoverflow, etc. to learn it either. Input whitespace (including newlines) does not translate 1:1 to output whitespace in Markdown and this mistake happens a lot in comments here, on stackexchange sites, etc. https://dro.pm/a.png https://dro.pm/a.png More on topic, I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. So if it's not on GitHub or if my users don't star it enough, you shouldn't consider it for use in production? Shouldn't the documentation, code quality, open issues / maintainer responsiveness to issues, etc. speak for itself?

mattgreenrocks 6y ago
> I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. Yeah, it's pretty gross for two reasons: 1. Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned) 2. Adopts a purely consumeristic view of open source The striking thing is that now these sorts of views are said out loud with no sense of shame.
- gridlockd 6y ago
  > Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned) It's not always the best way, it's a shortcut. While you're spending time figuring out which JSON library is the best by some metric that might ultimately be irrelevant to the task at hand, I'm going with the popular option that is almost certainly "good enough" for me - otherwise it wouldn't be popular. That gives me an advantage over you, 98% of the time. > Adopts a purely consumeristic view of open source I don't see how this relates to popularity. Most users of open source will always be consumers, whether something is popular or not. However, if something is popular, the likelihood of someone to contribute back also grows. Furthermore, if something is popular and there's an issue, somebody else will most likely run into it before me, write about it, get feedback on it, and so on. That's a valuable contribution, even though it isn't code.
  - denoma 6y ago
    The tendency to go for most popular library/framework/etc, with all the assorted justifications (which are valid to a degree and thus misleading) is an indication of just how rampant cargo culture is in software. Everybody always looking for the default thing to throw at the wall, hoping it solves their problem. And it’s fine, for prototyping and fast growth “products” (really mvps and demos) but with anything serious you must do the required legwork to figure out what is actually needed, and it’s often best to limit dependencies on external libraries and frameworks as much as possible.
    - gridlockd 6y ago
      I disagree that this is cargo culture. I'm not arguing for people to follow the latest hype, or do what everyone else does, in the hopes of winning. I'm saying that if you have the choice between a handful of projects that solve more or less the same problem that you actually have, just going with the most popular one is probably going to be the best choice, because having all these other people in the same boat is valuable. I agree with limiting dependencies and points of failure, but that's orthogonal.
bonoboTP 6y ago
It's common to write each sentence on its own line in the source text. It helps with version control. It doesn't mean the author thinks the line breals will also appear in the rendered document.
- lucb1e 6y ago
  You think the author meant for them to appear like this Like full sentences but with no punctuation in between This argument makes little sense to me Surely they did not mean it like this As the source code of the page shows, newlines were clearly attempted to be inserted and I very much doubt it was intended to only make the source code look pretty but not the article
gridlockd 6y ago
> More on topic, I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. Just because it's disheartening doesn't mean it's unwise. > So if it's not on GitHub or if my users don't star it enough, you shouldn't consider it for use in production? If it's big enough to be popular and not be on Github, that's a good sign. If it's not that popular and refuses to be (also) on Github, that's a really bad sign. > Shouldn't the documentation, code quality, open issues / maintainer responsiveness to issues, etc. speak for itself? No, because popularity adds value well beyond those things. It tells you that other people have found that the piece of tech is "good enough". They've already run into issues for you, so that you don't have to. They've already trained on it so you don't have to train. Popular projects are made better just by being popular, which is self-reinforcing. Of course that means sometimes ill-conceived technology (like HTML/CSS/Javascript) wins out over contenders that are better "on paper".
- lucb1e 6y ago
  > They've already run into issues for you A star does not mean someone used a library for an extended period of time and decided to endorse the project by giving it a star. I expect most people use it as a like button (showing appreciation for or approval of the work and nothing else), a bookmark (since you can view your stars), or both. Looking at my own stars on GitHub, the first one is something I never used, I just liked that someone documented the protocol for me and published some software around it, so I could make my (planned) open source alternative to the vendor's proprietary crapware more easily. The second one is a factorio mod that I enjoyed using. The third is a list with an overview of algorithms. I suppose I gave it a star for similar reasons as why I might give a comment or article an upvote. The fourth is a simple PHP project that looks nice, but I honestly don't remember seeing it and I certainly never ran it. So that's n=1 but given how easy it is to leave a star and that there is no way to leave a negative star or any sort of comment: no, stars have nothing to do with endorsement, quality, running into issues, or any such quality. If I want to leave a comment to indicate or warn that something is broken, of bad quality, or something similarly negative, a ticket ("issue") is what I might create, and so I circle back to my previous statement: look at other qualities like developer responsiveness in tickets, past tickets... A "clones+downloads from unique IPs+users" or something similar might be a metric for how often this was actually attempted to be used, and given that most people wouldn't forward bad software to others, that might say something about it beyond some threshold. But it still doesn't tell you anything about their experience with it, for that you'll (currently) really have to look at other factors.
fabian2k 6y ago
I'd be careful with Github stars, but in general I don't think it is unreasonable at all to take the popularity of a project into account before choosing it. Though this matters a lot more for things like frameworks that touch all parts of your application compared to smaller libraries that are more contained and can be switched out easily. The smaller a library is, the easier it is generally to just fork it and maintain it yourself if you need to. In that case there is no big danger in choosing an unpopular one. But for large, complex dependencies it can be very problematic if they become unmaintained. That is a risk that is always there, and that you have to keep in mind while choosing your dependencies.
staysaasy 6y ago
Thanks for the tip, we just fixed those bullets.
yCombLinks 6y ago
His github stars was just one possible measurement of how successful a technology is / will continue to be. That being said, github stars is an ok indicator of how likely a project is going to continue to be supported or more broadly be adopted.

by lucb1e 6y ago

mattgreenrocks 6y ago

> I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. Yeah, it's pretty gross for two reasons: 1. Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned) 2. Adopts a purely consumeristic view of open source The striking thing is that now these sorts of views are said out loud with no sense of shame.

gridlockd 6y ago
> Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned) It's not always the best way, it's a shortcut. While you're spending time figuring out which JSON library is the best by some metric that might ultimately be irrelevant to the task at hand, I'm going with the popular option that is almost certainly "good enough" for me - otherwise it wouldn't be popular. That gives me an advantage over you, 98% of the time. > Adopts a purely consumeristic view of open source I don't see how this relates to popularity. Most users of open source will always be consumers, whether something is popular or not. However, if something is popular, the likelihood of someone to contribute back also grows. Furthermore, if something is popular and there's an issue, somebody else will most likely run into it before me, write about it, get feedback on it, and so on. That's a valuable contribution, even though it isn't code.
- denoma 6y ago
  The tendency to go for most popular library/framework/etc, with all the assorted justifications (which are valid to a degree and thus misleading) is an indication of just how rampant cargo culture is in software. Everybody always looking for the default thing to throw at the wall, hoping it solves their problem. And it’s fine, for prototyping and fast growth “products” (really mvps and demos) but with anything serious you must do the required legwork to figure out what is actually needed, and it’s often best to limit dependencies on external libraries and frameworks as much as possible.
  - gridlockd 6y ago
    I disagree that this is cargo culture. I'm not arguing for people to follow the latest hype, or do what everyone else does, in the hopes of winning. I'm saying that if you have the choice between a handful of projects that solve more or less the same problem that you actually have, just going with the most popular one is probably going to be the best choice, because having all these other people in the same boat is valuable. I agree with limiting dependencies and points of failure, but that's orthogonal.

bonoboTP 6y ago

It's common to write each sentence on its own line in the source text. It helps with version control. It doesn't mean the author thinks the line breals will also appear in the rendered document.

lucb1e 6y ago
You think the author meant for them to appear like this Like full sentences but with no punctuation in between This argument makes little sense to me Surely they did not mean it like this As the source code of the page shows, newlines were clearly attempted to be inserted and I very much doubt it was intended to only make the source code look pretty but not the article

gridlockd 6y ago

> More on topic, I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. Just because it's disheartening doesn't mean it's unwise. > So if it's not on GitHub or if my users don't star it enough, you shouldn't consider it for use in production? If it's big enough to be popular and not be on Github, that's a good sign. If it's not that popular and refuses to be (also) on Github, that's a really bad sign. > Shouldn't the documentation, code quality, open issues / maintainer responsiveness to issues, etc. speak for itself? No, because popularity adds value well beyond those things. It tells you that other people have found that the piece of tech is "good enough". They've already run into issues for you, so that you don't have to. They've already trained on it so you don't have to train. Popular projects are made better just by being popular, which is self-reinforcing. Of course that means sometimes ill-conceived technology (like HTML/CSS/Javascript) wins out over contenders that are better "on paper".

lucb1e 6y ago
> They've already run into issues for you A star does not mean someone used a library for an extended period of time and decided to endorse the project by giving it a star. I expect most people use it as a like button (showing appreciation for or approval of the work and nothing else), a bookmark (since you can view your stars), or both. Looking at my own stars on GitHub, the first one is something I never used, I just liked that someone documented the protocol for me and published some software around it, so I could make my (planned) open source alternative to the vendor's proprietary crapware more easily. The second one is a factorio mod that I enjoyed using. The third is a list with an overview of algorithms. I suppose I gave it a star for similar reasons as why I might give a comment or article an upvote. The fourth is a simple PHP project that looks nice, but I honestly don't remember seeing it and I certainly never ran it. So that's n=1 but given how easy it is to leave a star and that there is no way to leave a negative star or any sort of comment: no, stars have nothing to do with endorsement, quality, running into issues, or any such quality. If I want to leave a comment to indicate or warn that something is broken, of bad quality, or something similarly negative, a ticket ("issue") is what I might create, and so I circle back to my previous statement: look at other qualities like developer responsiveness in tickets, past tickets... A "clones+downloads from unique IPs+users" or something similar might be a metric for how often this was actually attempted to be used, and given that most people wouldn't forward bad software to others, that might say something about it beyond some threshold. But it still doesn't tell you anything about their experience with it, for that you'll (currently) really have to look at other factors.

fabian2k 6y ago

I'd be careful with Github stars, but in general I don't think it is unreasonable at all to take the popularity of a project into account before choosing it. Though this matters a lot more for things like frameworks that touch all parts of your application compared to smaller libraries that are more contained and can be switched out easily. The smaller a library is, the easier it is generally to just fork it and maintain it yourself if you need to. In that case there is no big danger in choosing an unpopular one. But for large, complex dependencies it can be very problematic if they become unmaintained. That is a risk that is always there, and that you have to keep in mind while choosing your dependencies.

staysaasy 6y ago

Thanks for the tip, we just fixed those bullets.

yCombLinks 6y ago

His github stars was just one possible measurement of how successful a technology is / will continue to be. That being said, github stars is an ok indicator of how likely a project is going to continue to be supported or more broadly be adopted.