I don't know, presumably Topaz (who creates AoC) would know, but isn't telling.
We would probably find out if some inputs aren't co-prime because the naive multiplying solution breaks, but they could be non-prime and yet co-prime, for example 15, 14, 11, 23 is a set of numbers which are co-prime, but neither 15 nor 14 are prime.
Overpriced homes, out of control rent, retirement are extremely problematic in a lot of European countries. And in the US, healthcare is usually covered by the company (talking about big tech corps).
So the extremely high salary is still a net positive compared to EU
I thought git complains and doesn't allow you to checkout uncommitted code? Something along the lines of 'please commit or stash your changes before checking out'
It does, they wanted an automatic thing to happen. Imo, i would never want this by default. that complaint/warning has saved me a number of times, from breaking other things
You can do it as long as your changes are only to files that are otherwise identical on both ends of the checkout (meaning there's 0 possibility of conflict).
So it’s supposed to be ‘exemplary’ and ‘beautiful’ but literally the first script I opened had global variables used. That’s not my idea of elegant Python.
In Python every module is an object. It therefore makes less sense (in less situations it makes sense) to use classes, and a 'global' is a variable global to the module. It's like having a class, and calling attributes of the class 'globals', because they can be accessed by all methods of the class.
This and the fact Python is often used in the context of writing simple utilities, where globals (even without the defense above) are perfectly fine (because it's not a huge codebase with namespace collisions etc.).
Using absolute axioms like "globals are always bad" and religiously applying them is a toxic attitude in my opinion.
Elegant means written in the simplest, clearest way possible.
Agreed, a complex application riddled with global variables is not elegant.
In a fifty line self-contained script, global variables are often the simplest way to go. Turning the code into a reusable class with member variables, which will never be reused, is not simpler. YAGNI.
I understand where that sentiment comes from, especially looking at the slew of mid-sized companies that have never turned a profit despite paying multiple hundred K TCs, but if you look at the profits of the giants, it paints a different picture. The labor of thousands of very highly compensated engineers is still a drop in the bucket of the revenue generated by their labor. Alphabet seemingly employs somewhere between 20-40 thousand engineers, and it is their labor that produced all (?) of their revenue generating products. Spreading last year's revenue (~$282B) across their engineering staff would yield a revenue in the ballpark of $9M per engineer.
We all know that their engineers are paid well, but that's still potentially more than an order of magnitude off of the value they generate. Of course, there are many other expenses to running their business, but to claim that broadly developers are overvalued when one of the most prolific employers of developers is generating 10x+ the revenue of what they spend on them, is likely no more than only occasionally correct.
That raises an interesting question. If developers are toiling equally hard at company A and company B, on similar products, but company A currently had a dominant market position over company B thanks to network effects - are the developers at company A in any way responsible for its outsize gains and therefore due millions of dollars in TC?
reply