Hacker News new | past | comments | ask | show | jobs | submit | Yajirobe's comments login

I don't think pirating mp3s is more attractive to the listener than Spotify.

> But if we multiply the numbers together we get a number that is divisible by every number in the table.

Wouldn’t LCM be the correct/more general approach? The periods could have common factors, right?


That's correct. In practice it appears that the AoC inputs provide numbers which are always co-prime (ie have no common factors other than 1).


Do you know if there were any inputs on this problem that had non-prime numbers? Like others, I used LCM in my code, but mine were all prime numbers.


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


Powered by Wolfram - interesting why this was the choice


Because it is a marketing page by Wolfram


It was created by wolfram.


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).


Microsoft?


> watt-hours

You mean joules (up to a constant factor)?


A watt-hour is 3600 joules but watt-hours or kilowatt-hours is commonly used because it’s easier to calculate.


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.


Exactly. Only "builtins" in Python polute the global scope. Module globals are closer to singleton instance variables.


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.


> Typically employees make poor money in comparison to what kind of profit they generate

I think it’s the opposite - developers are overvalued.


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?


Why are you leaving out all the other essential people that go towards that revenue figure?


Alphabet has at least twice those numbers.


Fake news. Lots and lots of fake news.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: