elevader

I feel like this isn't really framing the issue fairly. The issue isn't that Sony couldn't use GPL code, there is no law preventing them from doing so, they just choose not to (for a variety of reasons, I'd imagine). Just as the could contribute to FreeBSD but choose not to. And OS developers have the choice to prevent Sony (or some other company) from essentially using free labor to make money without any obligation on their side.

I'd guess that most simply don't care as this is really just an issue for the company, not the author. If the project is licensed with MIT/BSD it still isn't really likely that the company will contribute/donate/whatever. So I'd argue that companies not wanting to negotiate doesn't really change anything for >90% of OS projects, they would not gain anything with a more permissive license either.

It's true that reputation and trust matter - at least they should. I guess it comes down to the question if a large enough portion of consumers actually know and care about this stuff and would be willing to reward a more open/honest approach enough to actually keep a business running. It might ultimately mean that consumers would have to reward a site/channel that doesn't actually review product X - kind of hard to make a living on that when most revenue ist ad/click based. There might be smaller outlets/youtube channels that do exactly that and use patreon or similar support channels but the bigger sites apparently don't want to bet on that. There was some sort of attempt by consumers to highlight these issues a few years ago but that was completely curbstomped by the gamergate shitshow.

They most likely can't but reviewers basically depend on the goodwill of the publishers in order to get pre-release copies for early reviews. If they don't get them they will simply loose out on money (reviewing the game 1-2 weeks after everybody else already did so is kind of pointless) and I'd guess a reviewer would risk getting essentially blacklisted by the whole industry as there is no reason to assume that a reviewer would uphold one NDA but not the other.

Game publishers also tend to advertise their content on said review sites and youtube channels so that would be another income stream gone.

Which is nice (and very true) but hardly useful when all you want is to look at some actually used lisp code. Emacs might be a good candidate for that.

Maybe, but at the same time it seems like the best option for general language support in emacs.

A lot of languages have working lsp implementations (at least according to https://langserver.org/) and, assuming it will stick around, this means that emacs can get all of these nice features "for free" by having an lsp implementation. This is a much safer bet than just assuming that somebody will provide and maintain emacs plugins for <insert language x here> that provide everything that lsp would.

I don't do a lot of java development but https://github.com/emacs-lsp/lsp-java works really well for me.

I guess that depends on the definition of "complete". Games back then tended to ship with whole features simply not working. The already mentioned Final Fantasy series comes to mind, I think Diablo 2 shipped with a Holy Fire Aura Skill that was supposed to deal periodic damage in a radius but simply didn't. Games also had their fair share of bugs that nobody would really call "easter eggs", for example Elder Scrolls Daggerfall had the tendency to generate Dungeons that had no entrance/exit so once you got in you were stuck. Ocarina of time, a console release, had three different versions released to fix various crashes and possibly game breaking bugs (https://www.zeldaspeedruns.com/oot/generalknowledge/version-...).

I guess it mostly comes down to the fact that players just didn't notice a lot of things (the "blind" status effect in Final Fantasy 6 did nothing, but this is really hard to notice as the hit chance it affects is called a chance for a reason) because they didn't know how things were supposed to work or they just worked around bugs if possible because patches often weren't an option.

[Edit]: I'm not trying to argue that the current way of things is in any way better than the old, both have their fair share of pros and cons.

Yes, exactly. This code basically runs at compile time and creates functions that return static results. This case doesn't have to be wrapped inside of the quote thing (I'm not even sure if it would compile if you did...), which is somewhat confusing in my opinion.

The unquote in your code example doesn't necessarily need to be unquoted, it would be enough to unquote the codepoint variable here. The point, I guess, is about at what point you want to evaluate the code. There is a great little function called Macro.to_string that might make this more clear:

  Macro.to_string(quote do: length([1,2,3]))

will return "length([1,2,3])", so it basically creates a macro that, if included in some code, will calculate the length of the list [1,2,3] at runtime.

  Macro.to_string(quote do: unquote(length([1,2,3])))

will return "3" instead, it basically executes the length function at compile time and then the macro will simply return that if called.

So the code example you provided basically calculates the byte size at compile time and will then only return static results at runtime.