At least in open source, I would claim that it's a result of volunteers doing the work for fun, which necessarily means they follow the dopamine: implementing someone else's work is not nearly as fun as figuring out a problem for yourself.

And the reading comprehension of CS people is near zero. You can give someone a paper with the solution, they will skim, not understand anything and then going back to reimplementing something poorly from first principles.

> reimplementing something poorly from first principles

Not-invented-here syndrome in practice. Which kinda works for the n-th shitty web framework. But it goes really poorly in any complex domain.

Are there any papers at all I. Web framework design?

This has nothing to do with open source. For GraphHopper I researched many papers regarding fast routing algorithms or advanced data structures etc ... and I'm pretty sure that this is true for other open source projects too.

It could be even the opposite: because many people can look into the code the code converges to the state of the art.

My theory is that open-source projects are a reflection of the language and all languages have the same flaw. Languages make it impossible to create simple objects with simple logic that can then evolve to more complex ability without modifying the simple object.

This results in new contributors being overwhelmed with the complexity of the classes and totally pushing aside the prior work in favor of starting at the basic level.

The module systems of common languages (like C# and Rust) tend to represent a "bag" of structs and traits, whereas a more advanced "evolutionary" language would represent source files or modules in a hierarchy of simple to advanced behavior.

Julia bucks the trend with its static duck typing; it's one of few languages where composition really works well. If your type defines + and * you can make matrices of them and multiply them together, then do linear algebra with them or format them as spreadsheets. Numpy, despite Python's duck typing, fails here because it's a thin wrapper over C, so the types are merely proxies and not extensible. Julia's compiled and heavily optimized, so it lives up to the promise. Also, unlike most static languages, the type system looks at the body of functions to infer what types they'll support - everything is maximally generic by default.

Julia has many flaws, but they're a different kind of flaws. Mostly caused by choosing function overloads based on vibes, and reckoning with the pandemonium caused by modules being glued together in unanticipated ways.

will look into this, thanks.

The industry is fundamentally conservative and un-imaginative. That being the case the M.O. is always a slightly tiny spin on an existing thing or a recreation of something that has been around forever but is currently slightly less popular then it once was.