All the other tools before that made programming more efficient results in rising salaries. I imagine salaries would only fall if AI can 100% replace a human, which currently it cannot. It remains to be seen what happens in the future of course.
Remember that an average software engineer only spends around 25% of their time coding.
This looks more worrying than impressive. It's long files of code with if-statements and flag-checking unicode bit patterns, with an enormous number of potential test-cases.
It's not conceptually challenging to understand, but time consuming to write, test, and trust. Having an LLM write these types of things can save time, but please don't trust it blindly.
The Pearson correlation coefficient is covariance normalised to the range [-1, 1] by dividing with the standard deviations (https://en.wikipedia.org/wiki/Pearson_correlation_coefficien...). So not quite same as the normalised scalar product, even though the formulas look related.
Pearson correlation = cosine of the angle between centered random variables. Finite-variance centered random variables form a Hilbert space so it’s not a coincedence. Standard deviation is the length of the random variable as a vector in that space.
That makes sense; I don't actually know much about this.
That being said, weirdly, the normalization by standard deviation happens outside the call to `cov` in the paper (page 181, column 1, equations (unnumbered) 1 and 2). And in equation 2 they've expanded `cov` to be the sum of pointwise multiplication of the (scores - average score) people have given to posts.
Again, not my area of expertise, just looking at the math here.
They offered KTM a 10 hour advertisement series, which would go on to become a classic for motorcycling enthusiasts worldwide. KTM's response was "eh no you could never pull that off, and will make us look bad". It had nothing to do with the cost of the bikes.
> It is by far the most useful skill to have in workplace.
This might be defacto true in most workplaces, but defending "politics over competence" boils down to "I deserve the rewards from other people's work".
People oppose it because it is morally wrong, not because they think it is an inaccurate description of reality.
You say that as if politics is optional. It isn't, decisions need to be made and politics is the process of making those decisions: who decides, and why.
In academia, for example, there is less politics because the publishing system sort of becomes the decision process. You apply with your ideas in the form of papers, the referees decide if your ideas are good enough (and demonstrated well enough) for the wider audience to even get to see. Then some politics, a popularity contest. But crucially this system famously leads to a LOT of resources being wasted, good research that never goes anywhere because nobody cares about it, or bad research that does nothing but everyone cares (cold fusion).
Politics is just a name for how we decide things. And yes, it sucks, but that's because we suck.
With this understanding of academia, you are perfectly suited to doing software development for them, because if you think there is "less politics" in academia, you are being foolish.
Academia is notorious for politics, especially around tenure and grants, scholarships, etc.
Publication politics are just a small part of that, but even there, working out which name goes in what order of the authorship of the paper is political.
Academia is not more notorious for politics than a corporate job, in my opinion. I've done both. Academia tries its very best to be meritocratic if anything. There is of course some degree of politics, it is inevitable, which was the point I was trying to make.
LLMs produce human readable output because they learn from human readable input. It's a feature. It allows it to be much less precise than byte code, for example, which wouldn't help at all.
Db access in rust typically needs some sort of handle and a mutex. Limiting access to the handle makes the rest of the code pure with respect to the db. The handle plays a similar role to the IO type.
Actor-like patterns makes this nice. Message-objects can be passed to/from a module with db-access or other io.
But that is the result of having multiple applications needing to enforce valid states in the database.
"Business logic" is a loose term. The database is the effective store for state so it must enforce states, eg by views, triggers, and procedures.
Other "business logic" can happen outside of the db in different languages. When individual apps need to enforce valid states, then complexity, code, etc grows exponentially.
Other than a few ill-advised attempts to implement microservices infrastructure by well-intentioned co-workers I've not encountered situations where multiple applications needed to access a single data store. While I'm sure there are valid use cases there I suspect they're rare and should be treated like the outliers they are.
Falling salaries?
reply