Perhaps if you're driving, the things around you need to give you time to react to other things around you. Fewer things are more frustrating than getting honked at because you pressed a button, then got distracted by a car pulling up which you needed to look at to be aware of, then missed the printer asking if you want a receipt, and then having to press another button to talk to someone to ask for a reprint which, of course, holds up the line of cars growing behind you while someone gets paged to come to the kiosk.
So you wrote this new scenario where the parking ticket machine does NOT print a ticket unless you confirm it (after you already pressed the button)? And you get... mildly inconvenienced by some honking. Yeah you shouldn't drive.
Kotlin Multiplatform (KMP) is neat for android devs that want to be able to code for both platforms using a toolset/language they are familiar with, but for iOS development KMP is a hassle (personal opinion). I’d rather just write the code twice. Also, I actually like Xcode. As for Android Studio, up until the more recent versions the GUI felt really clunky to me (which made working in it a bit of a slog).
Have heard of it, haven’t investigated it deeply. Looks to still have some of the less-great points of the Java ecosystem on the build side of things (gradle) which is a detractor for me.
Kotlin’s syntax is also weird/quirky in some ways.
Doing charity work does not mean you don't expect to be paid for your regular work. Also, a lot of companies do pay devs to work on open source projects.
Open source isn't charity - just like playing non-professional sports isn't charity: the vast majority of participants see it as a hobby or social activity. A minority get paid, and a minority of the minority "break even", but vast majority are playing in self-organized leagues and pick up games, which are in no shape or form charities (even if the public can watch for free as a side-effect).
I think the next release is gonna give you a lot of flexibility to write your own helpers that can generate the raw fragments you need. Not as good as having the features built in of course, but it'll do in a pinch.
jOOQ and jOOQ-like API's in other languages are the Right Thing in most cases, IMO. I've worked with very abstract ORM's, I've worked with raw SQL, and I've worked with a lot of things somewhere in between and that's my conclusion.
I think that the author has a warped idea of how LLMs work, and that infects its reasoning. Also, I see no mention of the inequality of this new "copyright free code generation" situation it defends; As much as Microsoft thinks all code is ripe for taking, I can't imagine how happy they would be if an anonymous person drops a model trained on all leaked Windows code and the ReactOS people start using it. Or if employees start taking internal code to train models that they then use after their employment ends (since it's not copyright infringement, it should be cool).
I think the author has a much better knowledge of the legal implication of the situations you describe.
These situations might trigger a lot of issues, but none related to copyright. If you work for MS, then move to another company, there is no copyright infringement if you simply generate new code based on whatever you read at MS. There might be some rule regarding non-competitive, etc, but these are not related to copyright.
The very basic question is how the LLM got trained and how it got access to the source. If MS source code would leak, you cannot sue people for reading it.
Having read MS code and starting to generate new code that is heavily inspired - sure, that's not copyright infringement. But, if you had memorized a bunch of code (and this is within human capability; people can recite many works of literature of varying length with total accuracy, given sufficient study) - that would be copyright infringement once the code was a non-trivial amount. The test in copyright is whether the copying is literal, not how the copying was done/did it pass through a human brain.
This scenario rarely comes up because humans are, generally, an awful medium for accurate repetition. However, it's not really been shown than LLMs are not: in fact, CoPilot claims (at least in its Enterprise agreements) to check its output _does not_ parrot existing code identically. The specific commitment they made in their blog post is/was, "We have incorporated filters and other technologies that are designed to reduce the likelihood that Copilots return infringing content". To be clear, they only propose to reduce the possibility, not remove it.
LLMs rely on a form of lossy compression which can sometimes give back verbatim content. I think it's pretty clear and unarguable that this is a copyright infringement.
