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.

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

> Once upon a time the noobs started with PHP and gave it a bad name with their insecure spaghetti code

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.

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