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

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

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

My admittedly shallow impression of PHP was that, because of how determined it generally is to keep going despite any errors that may occur, it doesn’t really need outside help to acquire a bad name or amass insecure code.

Now, on one hand, this is an opinion of someone who tried doing PHP for at most a couple of months nearly a decade ago (ugh), so it’s of very limited value. On the other hand, the reason I stopped trying was exactly the above: I found that writing it made me incredibly nervous and that I just couldn’t make peace with the fact that I won’t be able to make my code fail on all reasonable but unforeseen errors. Never before or after have I encountered a language that so actively fought me when I wanted to crash my program (and I’m perfectly comfortable writing C and Forth on microcontrollers). I could’ve been using it wrong, but one way or another that awful impression still lingers.

Can someone comment on this from the linked tweet? I haven’t been a js dev in a long time. 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...

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

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

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`?

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

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

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.

    const idNameMap = itemList.reduce(toIdNameMap)

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

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

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

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

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;

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.

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

  const rows = parseCsv(csvFile);

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.

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.

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

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

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

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

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.

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.

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.

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

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.

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.

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.

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!

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

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

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.

So yes, 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, you 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. Here is a helpful tutorial on doing that on GitHub: [0]

The rest of the post you replied to remains unaddressed by your 14-word-long opinion. Please provide a more substantial reply to this one if you are having a serious conversation.

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

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.

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

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.

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

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