I personally have no problem with Copilot. To me every source should be open for personal use. For commercial use this might causes a problem, Github profiting from established sourcecode under restrictive licenses. For me a neural network is using the same principles as the human brain. A network of cells generating an output using complex logic. Would you disallow a human that has read a copyleft sourcecode file to write code of similar structure? To me the answer is no. So I have no problem with Copilot. This is more of an ethical problem for me than a moral one. Moral wise you could force Microsoft to only train copilot on permissive licensed projects.
The thing is, if Microsoft is actually confident in how copilot generate unique code and not just copies code from other things.
Why didn't they train it on office and windows code?
In the end it doesn't matter the code copilot generates is unique, and isn't bind by any license right?
You could, but uncertainty always exists in the real world, so if it doesn't exist in the trolley problem then your choice in the trolley problem doesn't map to the real world and is not useful.
For one thing, in the real world if the trolley is close and moving fast then you have little time to think and observe and high uncertainty, but if the trolley is distant and slow then you have lots of time to try calling other bystanders, untie or rescue people from the track instead. So the more your choice is constrained down to just moving the lever or not, the higher uncertainty and less clear the situation is.
And in the real world it's more likely that a group of young people would tie some shop mannekins to a track for a laugh, or a film studio would tie props to a track, than that a moustache-twirling villain would tie some real people to a track. There is uncertainty in simply believing what you see; seeing five people tied to train tracks and about to die and being convinced they are real people, would have me thinking I must be dreaming.
Its more likely that they just want the number for Multi-factor authentication. Not that I like, that every site now asks for a phone number. But it is more of a security reason. Otherwise there must be real people involved in oder to restore your account. It also insures that most of the user accounts are no sock puppets. Not every user has access to vast ammounts of mobile phone numbers.
In discords defense: It was never made for open source projects in mind, but gamers and small private communities. Having a free service provided might come with traps and pitfalls, but I would prefer that over having only paid online services. Choose your poison. I don't think discord is the right choice for FOSS communities.
> Its more likely that they just want the number for Multi-factor authentication.
You can do that with an app or an U2F key. You don't need a phone number for that and, in fact, SMS-based 2FA is mostly discouraged by now due to sim swapping attacks.
So it boils down to avoiding sock puppets (most likely IMO) and to collect your data (which is something nice to get on top).
The reason for having SMS-based 2FA as a default is that it's At least something.
Adding a U2F token and having SMS as a backup means that you don't have people locked out because their yubikey failed -- which happens.
Discord is trying to solve some of the bootstrapping problems that arise from "oh fuck my computer and phone were both stolen" -- which, again, happens.
It's to prevent people from creating unlimited "anonymous" accounts. Phone numbers cost money and are, in many cases, something that can identify you if needed.
It's also a good way to signal to investors and advertising partners about how many real humans actively use their services versus how many bots are using them.
I disagree. Using this technique will lead to more cyclomatic complexity. I aim to write small methods and readable code. In small methods, there is no problem using early returns. Early returns will also help in the readability, because you can stop reading as soon as you realise, that the method returns here, whereas you have to read the whole method in order to know if some other code is executed.
My take on such “rules” is that these are not really rules but guidelines you can take hints from to make code easier to read and understand. I rarely try to force these rules to my code whether I am writing new code or changing existing code. Sometimes breaking these rules will make it better, and sometimes enforcing the rule will make it easier to read.
My process is to write the code, take my hands off the keyboard and just read it. Take a break and come back and read it again. Then upload a code review request but before you “publish” it for review read it in the browser again and makes changes as you see fit. This applies to design patterns as well. To me it is always circumstantial and should not feel forced. Sometimes the inherent nature of the logic requires me to keep all the conditionals together in a tight method with good documentation to make it easier to read it a year later. Sometimes it just “feels” cleaner to split it out. It always depends.
