Hence the additional questions :) Making $2k+ in just a month (GPT4 API access opened for invite-only) would mean a ton of users quickly, which is hard to believe.
The only indication we need to know about the ethics of OpenAI is the fact that it's a private for-profit company that claims the name "OpenAI", where "open" has very clear meaning in its sphere of relevance (technology, computing, and software).
Surely you could make a far greater environment impact by donating $50 to a conservation or carbon credit charity instead of spending $100 on $50 worth of groceries that have less plastic in their supply chain.
The cost of diverting plastic from the waste stream is high, the cost of recovering it once it becomes litter is higher, and the cost of getting it out of the ocean is dollars per kilogramme. And once we have it the best option we have is either melting into lumps of generic plastic to use as weights, or shipping it to Sweden to be burned to generate electricity (only place that does this AFAIK, and I wouldn't trust anyone in the US or Australia if they wanted to).
At your school, sure. Not at the one I taught at in the 10s. And from knowing other teachers then, I'd guess the pressure was high at only one, maybe two, of the six high schools in the area.
Nope. Less code is not always better. Collapsing a loop into a single line lambda with single char variables doing 5 times is not elegant or better. It’s orders of magnitude worse.
Less code is more readable. But absolute minimal amount of code can be unreadable.
"Less" doesn't mean "fewer bytes", it means "less complexity". If two ASTs do exactly the same thing, but one is easier to understand and has less structure, that one is probably better.
Less complex in lots of situations means being explicit, not being too template'y, not being too generic, abstract and writing code that is supposed to be a kind of meta that takes in a config and does several things for several inputs.
Writing less complex code in lots of situations just means writing lots of code. Which is diametrically opposite to the original statement of less code being better.
Being kind of meta, taking config, and doing several things for several inputs are good examples of ways to reduce the amount of code--when used appropriately. Being explicit reduces code too. Over abstracting and premature optimization can result in bloated spaghetti code.
By less code I mean less logic, not less characters. Less code generally means less work for the CPU (faster), less surface area for attacks, a smaller codebase that is easier to pick up and work on. When working with sets of numerical data, there are often two or more ways to come up with the desired result. A dumb imperative way, that may involve several loops and stages, or a simple and intelligent way that requires a deeper understanding of the math to implement properly. I've seen pages of slow code reduced to a few simple lines that are performant and easy to grok.
At a nonprofit I work with, there was a series of web forms that volunteers had to go through in order to enter a bunch of data.
Volunteers have never liked this form, but it was at one point necessary to collect all this data. A decade after those forms were built, it was decided to finally spend some of our (all volunteer) engineering capacity to help streamline the process associate with those forms. So, a junior volunteer comes in, hears the groans about this form, and found out a bunch of this data was already stored in other tables (in the interim smartphones became a thing and customer intake went from completely free form to a self-service signup process). The volunteer writes a bunch of selenium code to pull data out of a few tables and use it to population about 80% of the form fields, leaving volunteers with only 20% of the original work!
Some time later the whole thing gets reviewed by an (again, volunteer) old hat staff who were around when the original form sequences was developed. Turns out we no longer needed those 20% of fields, and ofc we already had the data in the other 80%... so all the original form code was deleted,
So the forms were retired completely, the selenium code was deleted, and the original problem was solved in a strictly superior way with 0 LOC by understanding the business need and historical context.
> So the forms were retired completely, the selenium code was deleted, and the original problem was solved in a strictly superior way with 0 LOC by understanding the business need and historical context.
Quite. Code is a liability. LOC is an utterly idiotic metric of programmer contribution, as it incentivizes increasing liability, over all sorts of other better contributions like good design, more automation, mentoring, customer obsession, etc.
(And for those arguing that “but the least amount of lines is not necessarily best”, yes, of course, that can obscure logic; the point isn’t to flip the value of LOC as a metric, the point is to not treat it as a good metric).
Without verification you don't know if any of them are marking $2k+