Sven Slootweg (soft-deprecated) @joepie91@pixie.town

When someone challenges you on abolishing copyright by asking "well, do you know a better way to protect artists": don't answer that question.

The problem with the question is that it presupposes that copyright protects artists; something that it demonstrably just doesn't do, propaganda to the contrary notwithstanding.

By answering the question - even by legitimately suggesting protections for artists! - you implicitly accept that copyright is effective at protecting artists, and that sets a bar that you will never clear in the mind of someone defending copyright based on propaganda.

You'll be fighting a ghost, a propagandic framing that is impossible to argue with. You may *intend* to show people better options that actually work, but what people will *hear* is "so you agree that copyright is important".

Instead, deconstruct the premise that copyright protect artists. Only once there's agreement that it doesn't work, is it possible to have a useful conversation about how artists should be protected.

#AbolishCopyright

An interesting comment from a library I'm reviewing:

"This class does some very "javascripty" things in the name of performance which are ultimately impossible to soundly type."

Late addition: their reproducibility is trash. They often ship minified bundles, compiled WASM binaries, etc. in npm packages, and more often than not it's difficult or impossible to reproduce the build from source (with documentation on doing so being severely lacking).

Also, I think a reasonable assessment would be: the code from Facebook is about as good and consistent as any code from a typical corporate environment is ever going to be.

There's clearly some people internally trying to make good code happen, but this is hampered on a fundamental level by the constraints of corporate structures, and their internal incentives.

With less words: you just will not get great code from a corporation, even if you try your best.

In case anyone's curious, this is how I would summarize Facebook's code style in JS (after auditing/reviewing a lot of their 'open-source' libraries):

- The code is reasonably readable. Names are generally sensible, and there's no three-letter-abbreviation nonsense.

- There is not a lot of 'magic' in the code (unlike, say, in Google code); the structure is pretty straightforward and consistent to follow.

- ... However. It is very clearly corporate code. It tends to avoid using anything not written by Facebook, so there are lots of reinvented wheels that *should* have just been dependencies on something else.

- Those reinvented wheels often take shortcuts. Sometimes those shortcuts have security implications, sometimes they "only" make the code unreliable or buggy.

- There are a lot of claims of implementations being especially performant or scalable, as a seeming justification for having a reinvented wheel. Sometimes these seem true, most of the time they're very debatable.

- Their build systems are absurd. Ridiculous levels of complexity, bespoke build tooling with strange architectural choices that doesn't actually do anything the common tools don't already do. Just use what everybody else uses already, ffs.

- Lots of inlined workarounds for Facebook-specific usecases/situations. These are usually clearly marked, but it's clear that anyone who isn't Facebook is a second-class citizen in library design choices.

- Overall, the total complexity of their code is high. Use of abstractions is poor; there often seems to be three times as much code as is needed to do the job, because they keep reimplementing the same structures for different purposes even within the same library.

- Occasional inline vendoring. This is usually because they need some internals change in a library they're using, but that vendored fork then never gets updated again, and I often question whether it couldn't have been upstreamed.

I'm posting this review for two reasons:

1. To demystify 'big tech' developers and show that they're not some sort of infallible superheroes with exclusive tools that nobody else could reproduce. Their work is slightly above average, at best. I have seen random libraries from unknown developers with much better work.

2. To show how the environment in which software is developed, affects *how* it is developed. The shortcuts and reinvented wheels above make total sense for a corporate environment; because they are focused on internal demands and meeting deadlines in any way possible, not on collaboration with others in the public commons or the broader public interest.

https://plush.city/@mynameistillian/110915915236416824

Every live DJ set recording should have the MC on a separate audio track that you can mute into the void