Hacker News Reader

Comment by SeanAnderson | Hacker News Reader

I am so conflicted on this! On the one hand, I fucking love it. Who hasn't experienced a backlog grooming session where you know it's impossible to reach the end of the backlog and you just sort of go along with the process of scraping from the top. There's definitely something miserable about that feeling.

On the other hand, it's not like the issues are gone, they're just tagged differently, and if everything is just tags and organization then why not go with the flow rather than exerting control in an attempt to achieve this pseudo-perfect empty issue list. There's gotta be benefit in keeping those notes around and visible, right? Sort of feels like deciding to throw something out of your house while deep in a cleaning spree even though your subconscious is (reasonably) nagging at you to hold onto it because you might need it in the future.

On the whole I think I'm for it, though, if anything just for the cathartic release and presumed re-invigoration towards new issues.

View on HN

For a bit more context, the creator is doing a full rewrite.

I think it would probably have been cleaner to release the rewrite first, then close all the old issues as deprecated. You could isolate the rewrite branch issues with a version tag. Closing then while the new version isn't done may lead to contributers opening new issues on the old version without realizing that it is no longer supported.

But he's not just ignoring the issues and leaving problems in the code base, the entire project is getting a refresh.

https://twitter.com/jdalton/status/1571863497969119238

I like it, it's the "put everything in a giant mailbag, label it, and dump it in a storage locker" approach. If the issues are still relevant, they can be resurfaced.

"...and when resurfaced, they will be stuffed into the 4th mailbag for further 'resurfacing'"

Return To Sender. Oh, wait...

What percentage of the now closed bugs still extant in the current version will be reimplemented in the rewrite?

63.19%

Requirements are hard, but ... you don't need bug reports to implement bug free requirements. So the only value the bugs would have is if they are for behaviors that should be documented as requirements.

Given the history of rewrites, I would estimate between 150-225%.

The CADT model continues to demonstrate its relevance.

https://www.jwz.org/doc/cadt.html

Jamie ranted about GNOME devs because he was a few decades too early for the clown show that is frontend Javascript development. Once upon a time the noobs started with PHP and gave it a bad name with their insecure spaghetti code, now they start with React and build lovecraftian towers of abstraction that need to be rewritten from scratch every 6 months. Most of the JS frontend ecosystem is held together by people with 2 years of programming experience.

EDIT: wow, the testicle-in-an-eggcup has gone. Even jwz mellows down with age...

Probably not. HN began using rel="nofollow noreferrer" in links.

I think it's important to highlight how the myriad of bad ideas in JS and newbies implementing them really is no fault of the newbies. It should be obvious, but I wonder whether people reading posts like these interpret them as hostile towards the newbies. It's the technically challenged pseudo-leadership out there that is to blame for most of it. The running head-first into "DX" while still consistently having some of the worst developer experience known to man as a whole and not seeing this, this is a by-product of a largely inexperienced but overvalued senior layer in the tech world that find big voices either via Twitter or more directly via pseudo-lifestyle dev channels on YouTube.

Some of them flaunt credentials that would fall apart immediately in real conversations but they are the ones that host the conversation so it can't really come up. Not all dev YouTubers are like that, of course, but I'm sure a few come to mind as people are reading this.

On top of the above I think people aren't considering that software is often a reflection of values[0] and that people disguising theirs as "best practices" does not make them more valid than others. It's perfectly fine to not prematurely pessimize your solutions and that often requires making choices that some people will see as wrong because they have different values, for example. This is not only fine as a personal value but many businesses reach a point fairly fast where an ever-growing part of their work is performance oriented, despite what a lot of people tend to think. Solutions that see no real use or have no plurals tend to reach this point much slower or never than solutions that do.

The above is also interesting to think about; a lot of people don't value reasonably fast software because they've largely never experienced it. It's not an uncommon reaction to marvel at simple solutions that have no real optimization put into them but simply aren't written completely wastefully from the beginning, because they're so much faster than what people are used to.

[0] Bryan Cantrill - Platform as a Reflection of Values: https://vimeo.com/230142234

> No FP wrappers. That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly.

Can someone comment on this from the linked tweet? I haven’t been a js dev in a long time. Is functional style dead?

> Is functional style dead?

No, the javascript ecosystem is just full of people who have taken some pattern that occurs frequently in functional programming, such as currying, to itself be functional programming, and thus write wrappers and overly complicated libraries to implement that feature and call it a functional wrapper or the functional version of the API, despite those features having very little to do with functional programming.

Idiomatic javascript and typescript are full of functional programming, far more so than other major programming languages. Avoiding functional constructs would, in fact, make your code unidiomatic. So the functional style is about as far from dead as it could possibly be.

Additionally, not only has the ecosystem been adopting a more functional style as time passes (especially due to features that have been added such as destructuring and spreading, which heavily encourage a more functional style), some of the core APIs in the standard library that used to make (pure) functional programming a bit more awkward by mutating their arguments now have pure equivalents [0][1] as well.

[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

reduce() abuse is a peeve of mine.

I used to always use .forEach but now I use “of” as much as possible.

Map, reduce, and forEach are each for quite different things. When you say you always used to use forEach, are you saying that you used it for pure computations? Or is near enough everything you write effectful?

What got me to stop using reduce was when I and another sr. held a theoretical "gun" to a jr devs head and asked him what a block of code involving reduce did and they didn't have a clue. They were pretty bright; so I just threw it the towel at it being useful to the health of a large codebase after that.

Still love map. But reduce can feel very "code golf" real quick.

I’m confused. Do you not think that would have been a good opportunity to teach that person what folds are for?

Fold/reduce is fundamental. It’s weird to me that its use would be discouraged or outlawed somewhere.

If your language has a `for` keyword, I would just say use the `for` keyword.

But why?

The language I use has various flavours of `for`. It also has various flavours of map and fold. It also has recursion.

They each do different things. Those differences are meaningful and useful. Why would you limit yourself to just using `for`?

It depends. It isn't the case for Ruby, for example.

So. That. https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies...

"Easy to read" means "easy for others". Current efficiency is usually borrowed on future one.

Which junior devs?

How would you abuse reduce()?

MDN even had to make a whole chapter to discourage overuse of it.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Using reduce to perform a map is a fun way to annoy colleagues.

Or .map() as a for..of replacement. I always wanted V8/SpiderMonkey developers to make .map()/.reduce() "pure" in the sense of "optimizing away" the expression if its result is not assigned to anything, and see the world burn.

I think .map() as a for...of replacement makes sense for simple cases. newArray = oldArray.map(el => aFunction(el)) is short, sweet and clean.

It's definitely short, but are you doing it for the side effects? Then I find .map() misleading. I'd much prefer a .forEach(), or a for...of.

If you’re mapping for side effects you deserve a good rap on the head.

The main value of “map” is to denote a 1:1 data transformation. Plus this gets very fraught with many langages mapping lazily, and some not guaranteeing the order of operation.

Use it at all, presumably.

I'm probably on the mild side of abusing it, I've never seen another developer on my team use it, but I also include self-describing variables for the values. If the reducer function itself is non-trivial, I've give it a name so the final product may look like:

    const idNameMap = itemList.reduce(toIdNameMap)

It should be intuitive that itemList is a list of objects familiar to the context of the code, and the result will be like:

    [{"id1":"Billy"}, etc.

It’s really not clear to me what the transformation is, but from the naming and result it mostly looks like it’s an abuse of reduce and should be a map, possibly feeding into an Object / Map constructor / factory?

> It should be intuitive that itemList is a list of objects

…But how?!

I can't see how anyone could build an intuition for this opaque line and the example of its apparent result. It's confusing enough that `idNameMap` actually refers to a list (or array), and not a map (or object).

Yes. In Scala people seem to say it's the idiomatic way to sum a list of numbers which never felt right to me. It just seems to much code to look at for that.

It definitely is the idiomatic way. How would you do it otherwise? Recursion?

in Scala the idiomatic way to sum is the method sum on collections List(1,2,3,4).sum

Although this is indeed implemented with reduce. But is it really too much code? List(1,2,3).reduce(_ + _)

Summing a list of numbers is the exact kind of use case you should use reduce for. If it feels wrong to you it's just because you have more experience with for loops than reducers.

In languages like JS that have both styles, the place you probably want to use for loops over reducers is for more complex operations where mutation can simplify the code. For example if you have 10,000 elements in an array that you want to aggregate into 1,000 properties on an object (with a non trivial relationship between array elements and object properties), it's probably going to look nicer in a for loop than it is in a reducer with a bunch of spread and ternary operators.

IMO .reduce calls should probably be one line. If not then it's time to either write a for loop or compose more smaller functions.

Avoiding them entirely is just FUD though. To compare summing an array in JS:

  let sum = 0;
  for (const n of numbers) {
    sum += n;
  }

  const sum = numbers.reduce((acc, n) => acc + n, 0);

The latter is much nicer to read if you're used to both styles. What I particularly like about it is it clearly signals that 'sum' is a variable that we will be using further down. The for loop style leaves ambiguity as to whether 'sum' is going to be used later or if it's just some context for something that's happening inside the loop.

Actually, to throw a hot take in the mix here, I think people should be more accepting of multiple statements across single lines in C-style languages.

  let sum = 0; for (const n of numbers) sum += n;

That would be a perfectly fine way to signal to the reader that "this is a specific line of code to produce a sum value" (much the same as the reduce example), but people seem to have a dogmatic aversion to leaving braces off if/for statements or putting multiple statements on a single line.

I just expect it to be my list.sum() or sum(mylist) and to trust that the implementation under the hood is reasonable.

I disagree.

The first version is something most programmers could read and understand right away.

I also dont understand why the second version signals use of the variable any better than the classic version, esp if you declare the variable right ahead of it, but that is the classic "C" style.

How ever in a real system I would hope people use better names than sum. which would give it some comprehension of what the variable does / exists for.

What is the obsession with one liners? Perhaps if paper was quite expensive and it was printed out paper on a regular basis you could save a few sheets, I dont think one long line is easier to read than several short lines.

I suppose if everyone involved with the project prefers or is used to the second version it is fine.

> I also dont understand why the second version signals use of the variable any better than the classic version, esp if you declare the variable right ahead of it, but that is the classic "C" style.

Because you have no idea if the variable is used further down in the scope. Compare with something like parsing a csv file with support for quotes:

  let rows = [];
  let quoteMode = false;
  for (char c of csvFile) {
    ...
  }

rows is the end result, quoteMode is state only relevant to the process happening within the for loop. There's nothing past variable names to distinguish their intended use. Whereas:

  const rows = parseCsv(csvFile);

makes it totally clear.

The reason something like reduce can make for nicer code is because it lets you do simple operations (probably not parsing a csv lol) inline in a way that makes the code just as clear as a function call would be, without adding a bunch of extra layers of abstraction (meaning more scrolling and flicking between tabs).

Really it's not about the reduce function at all, it's about the "const foo =". Once you see that, you can completely disregard the rest of the line if you've already read it and/or are confident you know what it's doing. It acts as a refresher in a way that a for loop doesn't. After you get past the inital shock of seeing a scary one liner (which get less and less scary as you see them more), it makes the next 20 times you read it much more pleasant.

But lodash has a curry wrapper? So I'm still not understanding what functional wrappers the author is talking about that are so problematic.

> currying Ugh. It seems like such a combination of shallow, weird, and useless to me, I find it hard not to stop reading any "Intro to FP" article that sings its praises as one of the first things.

The big deal about FP is that you can see more easily what the damn function will do when you call it. A weird and long-winded notation for multiple inputs contributes jack.

Oh yeah. This is going to turn out just fine /s No second system syndrome and whatnot.

Here is an idea: write the damn thing under a new name and abandon /offer a path to migrate.

The old version is not going anywhere.

I suppose the rewritten version will be a drop-in replacement with an identical / 100% compatible interface. (Else it's not a rewrite.)

Lodash was 0 value to begin with, now it's going to the realm of negative value. Can't wait to debug compatibility issues of a convenience/utility library 5 layers deep into the dependency chain.

> The old version is not going anywhere.

The same can't be said about the tickets and PRs for the old version though!

Just guessing here: I don't think it's going to be 100%. Sometimes it's not 100% even between versions of the same lib (breaking changes, major versions).

If it's good enough people will start using it and the old version will just fail into obsolescence.

Lodash itself started as a 'better' version of underscore.js, and ended up bloated and over-engineering exactly as the prophecy says. If anything, this 3rd system will hit the right balance :)

Lodash started because underscore violated semver by releasing breaking changes as a minor version update.

As a user, I find such a “cleanup” problematic if it means closing the issue. If the issue still exists in the product, it should remain open, for documentation, and so that users running into it can easily find it and add to it. I find it more honest if a project acknowledges that the issue exists by leaving it open.

As a developer, I’d rather use a filter to hide older non-critical issues, if I’m bothered about seeing the amount of issues.

Closed doesn't have to mean resolved and the tickets would still be available either way. Closed is IMO ideal for these tickets as ultimately it means that they aren't being looked at.

But they should be looked at. They aren't because we don't have infinite time every day to look at issues.

If those issues are still a problem nobody will find them, they'll make new issues and lose all the previous history, unless the UI is designed to support automatically suggesting reopening an old issue instead.

It's not necessarily true that they 'should' be looked at. Most old projects that follow the 'never close without verification' philosophy end up, eventually, with a majority of open issues not actually reflecting the current state of the project.

A middle-ground might be to leave open the issues with recent activity, with the idea being that at least the ones that are affecting people the most are not swept under the rug.

> Most old projects that follow the 'never close without verification' philosophy end up, eventually, with a majority of open issues not actually reflecting the current state of the project.

There's a crucial question here that I find not enough people ask themselves: does that actually matter? And if yes, why? What, specifically, is the material problem caused by this situation?

It often feels like people are just chasing 'inbox zero', under the assumption that "0 open issues == good", without any actual material problem being solved in the process.

(Github probably isn't helping here, with their undeservedly prominent placement of the open issue count driving this sort of behaviour...)

Lots of projects on GitHub (not sure about lodash) automatically lock closed issues so you can't comment on it anymore. That closes an avenue for those that are impacted by the issue to discuss fixes, workarounds and alternatives.

Closed implies that a decision has been made that the issue is somehow not worthy of consideration anymore. That’s what bugs me as a user.

Whether any given ticket is being looked at can change over time. Closing it is a way to drastically reduce the likelihood that it is being looked at. As a user, I see no good reason why that should be done, in particular when it is applied across the board without considering the individual issue.

Closing means it's not worth of consideration at this time, it can always be reopened.

As a user you obviously see no good reason for that. As maintainers having more bugs open than will ever be worked on (e.g. because no one will put up the legwork), serves no good purpose.

PS: individually considering each of 100s of issues takes time and mind share, that can better be invested elsewhere.

Closed does mean resolved. One way or another. If it's not resolved, it's still open. If the ticket was improperly marked closed, that just means someone else has to create a new ticket for the unresolved issue.

Closed doesn't mean resolved, it means closed. Closing issues just shifts them to another tab, doesn't remove them entirely. What you propose, a filter to hide these, is exactly what has been done just through the official open/closed filters.

This is not accurate. When searching for issues, users won’t find closed issues by default. When issues are linked, closed issues are rendered differently (struck through). You can’t comment on them anymore without reopening them, and reopening them is often discouraged or not enabled at all. It is a drastically different state.

most of that is not really true. where are closed issues rendered struck through? It's up to the repo to lock closed issues or not, and it doesn't appear this repo did that.

Wait what? Since when can’t you respond on a closed issue without reopening it? I’ve partaken in lengthy discussions on closed issues without them reopening. Obviously you can’t reply to locked issues of course, but that’s a separate thing.

Either you are thinking of other project management tools or assuming that some of the "stale issue locking" and automated issue management tools that some larger projects use are default.

On GitHub, it is true that the Issues search shows only open issues by default, but I think users are quite aware that they may need to search for closed issues, especially since it's unlikely they are on the absolute latest version of a package, especially when debugging problems in production. Additionally, some projects close issues once the mainline has addressed them even if the fix isn't in a released version.

GitHub does not render closed issues as struck through, and it does not by default lock conversations on closed issues.

EDIT: I am not taking a side on whether or not it's a good idea to do this sort of "bankruptcy" mass close.

> On GitHub, it is true that the Issues search shows only open issues by default, but I think users are quite aware that they may need to search for closed issues

I think users are quite unaware, given how we have no evidence they're quite aware, and the normal thought process is "closed == resolved" (fixed, wontfix, etc)

A normal thought process would be to close individual bugs as you confirm they aren't present in the new version – the end user already bore the burden of writing a bug report, and you owe it to them to actually determine if the issue is resolved before closing, even if the resolution is "wontfix".

Closing bug reports without actually caring about whether they were resolved is giving the finger to your users. Why even have bug reports at that point? As far as users are concerned, you'll just close any new ones for some new reason anyways, based on your track record.

Now: new version, all bugs closed. Next: new name, all bugs closed. Then: new logo, all bugs closed. After all, you close whatever bugs you want, whenever you want, for whatever arbitrary reason you want. And why not? It's your repo. Why does it matter if the bugs are fixed or not when you close 'em? You got a new thing! Close all bugs!

> and you owe it to them

Stop right there. It's an open source project. You owe the users absolutely nothing.

If you perform marketing and/or evangelism for your project, it's not at all obvious that you owe your users nothing.

The act of marketing software doesn't invalidate the license, which often explicitly states that the software comes as-is and free from warranty / support.

Offering an as-is disclaimer doesn't rid someone of all social, moral, or legal responsibility.

Saying things that conflict with that disclaimer does indeed chip away at the effect the disclaimer has on your responsibility.

> You owe the users absolutely nothing.

Stop right there. When you ask people for feedback, be it 1-on-1s or bug reports, ignoring the feedback is ruder than never having asked in the first place.

If you decided to ask for feedback, and they're kind enough to take time out of their day and spend their efforts to help you out in the way you asked them to help you out, then yes, you DO owe it to the provider to not then tell them to bugger off with said feedback.

If you were going to do that, you should have disabled bug reports from users, instead of asking users to help you by providing feedback. Here is a helpful tutorial on doing that on GitHub: [0]

[0]: https://docs.github.com/en/repositories/managing-your-reposi...

Sure you do. Anyone asking for feedback owe to respond on said feedback.

Allowing feedback != Asking for feedback

opening your feedback system to users == asking users for feedback

I agree with most of this, but I do think that other than the worst of the users (which admittedly are much more visible than the better ones) do in fact understand how to navigate closed issues.

> Additionally, some projects close issues once the mainline has addressed them even if the fix isn't in a released version.

And that is a general issue with the maintainers not understanding what they're doing, or not understanding how issue trackers work.

If you close an issue that is still present in the current release, then you're doing it wrong - with one exception. If it is in fact functioning as intended and the issue was just a misunderstanding, then explaining that and closing the issue makes sense. (But even then you might want to update the docs or helptext or something to prevent future misunderstanding, if it's confusing enough.)

Closing an issue just because you don't feel like looking at it today just means that someone else will open a new issue tomorrow to report the same thing. And any history, workarounds, steps to replicate, etc. in the old issue will be lost/disconnected. That's not doing anyone a favor.

> > Additionally, some projects close issues once the mainline has addressed them even if the fix isn't in a released version.

> And that is a general issue with the maintainers not understanding what they're doing, or not understanding how issue trackers work.

> If you close an issue that is still present in the current release, then you're doing it wrong - with one exception. If it is in fact functioning as intended and the issue was just a misunderstanding, then explaining that and closing the issue makes sense. (But even then you might want to update the docs or helptext or something to prevent future misunderstanding, if it's confusing enough.)

The concept of an issue tracker was not bequeathed to us from on high. There is no single "right" way to do it, nor can you (context free) tell someone they're doing it "wrong".

Some people use issue trackers to inventorize bugs in current releases. Some people use them as a dev's todo list. If you do the latter, closing the issue once you've implemented the fix is perfectly reasonable.

> Closing an issue just because you don't feel like looking at it today just means that someone else will open a new issue tomorrow to report the same thing. And any history, workarounds, steps to replicate, etc. in the old issue will be lost/disconnected. That's not doing anyone a favor.

It feels like it's doing the developer a favour.

In my experience closed issues are usually closed with an associated PR and the issue it fixes gets merged into main/master.

I've never actually seen a project only close issues when they make a release. Rather they make a new release when there are enough resolved issues or new feature PRs. Though of course they can do whatever they want. There are a lot of projects where it is known that the latest git main should be used and the latest actual binary release is from years ago.

I keep issues open until a release resolves them for all my open source projects. It helps to prevent duplicates, helps me maintain good release notes, and ensures the open issue list is a more honest description of the software you get when you fetch it via your package manager.

In my project a ticket that is open / closed / tagged timbuktu means whatever I want it to mean.

Personally I am not going to assume that people are competent enough to check the open issues but too lazy to check the closed issues, or simply too dumb to understand a comment like "closed because I am not going to fix this".

"wontfix" is a perfectly good issue resolution.

I started closing issues unceremoniously with a maybelater tag.

If I won't be working on it, if no one is working on it, I won't leave the bug open.

Either someone shows up and decides to put up the legwork or it gets closed, even if it doesn't cross the threshold of wontfix (i.e. I won't accept a fix).

I'm also conflicted. On one hand I reach for it every time I'm back in JavaScript land. On the other I think that slightly less than half of this library should be in the standard library for Christ's sake.

Isn't this a task that Large Language models should excell at? summarizing tickets.

Yeah, it’s why Basecamp doesn’t keep a backlog. Anything important will come up again.

Only until users notice, and decide that reporting bugs isn’t a good use of time.

Reply on news.ycombinator.com