From the author: "Folks. Please STOP +1 and :+1: -ing GitHub tickets. We get it, but it makes tickets hard to have conversations on. Contribute with something substantive instead."
This is a very common problem for github issues posted on HN/any social media. Would be great if github had a voting mechanism.
I really think that GitHub needs better tools to deal with this, this is very frustrating - the only options right now are deleting a ton of comments or locking it preventing all discussion. Prompting people with a modal informing them what comments are inappropriate would go a long way.
In the past you would create a few mailing lists; I think sourceforge automatically did that for you too.
They should have locked the thread or use a wiki page for this. A wiki page is less likely to be edited to add this kind of comment or at least it would be easier to clean up with a bot.
I appreciate that the voting keeps the conversation from devolving into a competition for laughs. But, sometimes it seems that HN has no sense of humor whatsoever.
Looks like people don't get it. Or maybe they have a different view on what's funny. In any case, commenting about downvotes just attracts more downvotes.
Comment voting ala hackernews / reddit would be useful but in this case so would some attached polls. The +1, -1 was from "back in the day" when it was a useful way for the active contributors to actually vote on something (or straw-poll it) in a mailing list etc.
It's annoying in some cases now because 1) it's anyone, not just the active contributors or even users, 2) people don't use it as a vote but as a general expression of support, 3) -1 isn't really used anymore so you can't scan them and see what the sentiment is, and 4) in this case, it's not even clear what they are lending support to- the merge, or that it is time to discuss a merge seriously.
So yeah, in this case it's noise but in some contexts +1/-1 is a quick and simple way to govern code and it has historical roots. Just ranting as I think they and some in this thread are a little too quick to judge. +1/-1 from the right people could be considered very relevant information to a discussion (esp. within a focused community).
I don't get why people don't just subscribe to the issue instead of +1. Google's issue trackers have the same issue: they support starring but people insist on doing "me too" posts.
> I don't get why people don't just subscribe to the issue instead of +1
Because subscribing does not show interest/support: the repository owner does not see how many people have subscribed to the issue. Furthermore, supporting the resolution of an issue does not mean you want to be spammed with updates to said issue.
> Google's issue trackers have the same issue: they support starring but people insist on doing "me too" posts.
Google's issue tracker has the same issue to a lower extent: while everybody can see the number of stars on an issue (which is good), starring an issue requires following it and being spammed by it (which is bad).
Only way I see to mitigate that is assuming the tracker has orthogonal subscription and voting ruthless moderation and removal of worthless "+1" comments.
Of course, but the point is you can have commented ("voted") and not subscribed (/unsubscribed) from the issue. Although commenting subcribes by default (which does make sense) they are orthogonal.
From random people, it's not usefull for sure. But, I think doing +1 or thumb up when you are contributing somehow to the actual project is actually valuable to gauge support.
It's actually awful. Often times everyone pretty much agrees a change is needed. It needs a bit of work which needs to be discussed.
The +1s are so irritating because you have to read through a huge conversation and you also keep getting email notifications because you want to keep in touch with a thread. It actually makes it harder to do what the github topic is about with the +1s.
I think everyone agrees gauging support is valuable. The issue is that the mechanism should be an up/down voting feature like HN has, not a post in a thread meant for conversations.
> Lodash is currently > 12k lines of code, and Underscore is 1.5k.
Never knew that before. Does Lodash have more features than Underscore? I never got too heavy into using either but I always thought of them as essentially being interchangeable libraries.
Lodash has many features that underscore does not have. Also, I am told that Lodash has been implemented in such a way that functions are largely independent of each other so that you can build a custom lodash package that only includes the subset that you use.
In practice, I'm not sure how truly valuable this is... it's far easier to just accept it as a whole, and with min/merge versions in the browser it's not so big at all.
It's not a macro framework like jQuery... the kitchen sink isn't in there... though, I do think that probably the string templating could/should become a sub-module... the rest belong together more.
It's both terrifying and exciting that you have to specifically point out when something is as little as "a few months old" when it comes to JS frameworks/libraries.
One of the core differences between Lodash - iirc - is that Underscore will just use a browser's built-in version of functions like .map and such, while Lodash often implements them themselves - circumventing JS spec compliance, often with significantly better performance than native implementations.
For those that dig a more fp-style (auto-curried, iteratee first methods) and are used to lodash there's lodash-fp — https://www.npmjs.com/package/lodash-fp
I really like Ramda myself as well... Though there are a few bits that I prefer how lodash/underscore work... in terms of methods that will work against an object or an array. In Ramda it's more expressly separated, and not always a good ratio.
I very much appreciate being able to use Ramda for composition of methods, which can mean much more concise code[1].
My experience with currying in Javascript is that passing the wrong number of arguments to a function leads to errors that are tricky to debug and ugly stack traces. In ML-family functional languages this isn't as much of a problem because of the static type checking.
I'd say Underscore largely made writing JS tolerable, given how crappy the standard library is and the number of gotchas the language has. So yes, very important!
As someone who once contributed some bits to lodash, I don't see how this will work out.
Other than perf, modularity, etc, I like lodash's doc better. The doc is written as inline jsdoc in lodash.js, with each parameters documented and behaviors explained through examples.
But here is @jashkenas's take:
> Documentation style. Ideally I'd like the Underscore docs to be written even more conversationally than they are at the moment.
Personally I also trust @jdalton more. Other than technical skills he's very hard-working and responsive. He seems to be following a zero-issue-and-PR policy and get all issues/PRs sorted out in 2-3 days.
The issue is backwards compatibility and ensuring API compatibility. I don't care if I can switch from underscore to lodash if I have to change X lines of code and then test them many times over to make sure that it all works.
big kudos to both these incredibly smart and talented guys for putting their differences aside (there has been some ugly exchanges between them in the past) and getting this done, the JS community will greatly benefit from this.
So basically these libraries are like Python's itertools for JS? Except they made a silly/arrogant choice of using a single character for the library name.
Imagine if every library you used named itself with a single character. Does your language have more than 27 libraries available? Then sorry, some of their choices of letter will overlap and those libraries will conflict, perhaps requiring you to manually edit the distribution source or build scripts. Do you ever want to create a project that has more than 27 transitive dependencies? Yeah, good luck with that. Found a code snippet online and want to figure out what library it's invoking? Hint: Google is probably going to be useless when searching for a single-letter name.
The problems with using single-character names for libraries are so self-evident, I'm not quite sure how to respond to someone who doesn't see it.
* list and dict were lacking vital methods like list.remove() and dict.__len__()
* dicts weren't really a real thing (real ones coming in ES6 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... ), but it was easy to add random properties to arbitrary objects while accessing a missing one simply returned None, and so these were used instead
* Which leads to for x in dct being subtly broken in certain use cases unless you understand the above and how it interacts with prototypes
* So loads of utility functions were added to deal with the above facts, plus the kind of useful tools you would find in Python's functools and itertools and a large number of other utility functions while they're at it.
(EDIT: One of these days I will remember HN doesn't use Markdown, but not today)
So basically the JS built-in container and prototype semantics are totally stupid, broken and confusing. I already knew this.
Apparently underscore is a community-driven "stdlib" that implements more functionality and saner container classes, and has more freedom to evolve since it's not part of the core JS language.
And the justification for using a single-character name is that it's basically a de facto part of the stdlib?
From the author: "Folks. Please STOP +1 and :+1: -ing GitHub tickets. We get it, but it makes tickets hard to have conversations on. Contribute with something substantive instead."
This is a very common problem for github issues posted on HN/any social media. Would be great if github had a voting mechanism.