With been in delusional trance for 30+ years generating "value" in form of endless documents, analyses, memos, presentations, reviews, reports, and so on and so forth.
The only thing that changed recently is that producing documents is now easier than ever.
Don't get me wrong. Planning is essential in getting anything done. But in my humble experience, 80% of planning documents are entirely useless, and the last 20% could be shortened by 80% without loss of quality. For other kinds of documents - reports, presentations, etc. - the numbers are even worse.
Corporate world is obsessed with producing text to unhealthy degree. AI generation is the result, not the cause.
There are teams that do work, and there are teams that don't do work. It's no coincidence that most documents exclusively benefit the latter.
Ironically, the documents that would actually help people doing work are often missing and/or incomplete and there's never budget to write them properly - up-to-date descriptions of processes, product manuals, API references beyond what's automatically generated, troubleshooting guides for common problems, onboarding materials, and so on. But somehow we have dedicated people to write detailed five year plans that never get completed and such. I can't help but wonder if ease of writing rather than usefulness is the core determinant of what gets written.
But "is far more likely to fall near the present" = "is far more likely to fall near the present". The author makes the claim about probability distribution themselves, then does the opposite.
You're right, yet I agree with the website's approach. The goal of this site is to educate users about how people lived, not educate them about stats. IMO. I would have chosen the same algo.
It's clear to me that an even bigger HC crowd would howl "Oh, how boring, look at him choosing pretty much only still alive people" if he had done the 'uniformly random" selection. C'mon!
> The goal of this site is to educate users about how people lived, not educate them about stats. IMO.
And IMO, a website that's 95% stats by volume very clearly is about stats. If the goal is teaching anything, it's teaching stats. It literally does animations showing the random process, and explicitly says how likely each outcome is, even sorts by likelihood in some places.
Again, I wouldn't have as much of a problem with that if the website itself didn't explicitly say that recent births are more likely than non-recent births.
Personally, the one 1990s person I've got was far more interesting than the dozen of 5th-15th century children that all died of one sickness or another before the age of 2. If anything, it's the dying of dysentery that should be non-uniformly random.
Traditionally, AGI means being capable of learning everything (not necessarily at once) that can be learned by the same AI agent. It differs from the commercially meaningful definition in that a standard specific-purpose-built AI can still do most tasks if you give it enough specific purposes, but it will be just as incapable of human intelligence as ever.
No - the term "AGI" was really coined to distinguish general intelligence from narrow intelligence(s). There's an obscure earlier usage, but it basically became mainstream as the title of a book edited by Ben Gortzel who had in turn got it from Shane Legg.
Shane Legg would a few years later go on to co-found DeepMind, with creating AGI as their declared mission. Legg's personal definition of AGI is not just generalist AI, but specifically human-level generalist.
Hardcoding feature flags prevents you from deploying the same build with different flag sets side by side and comparing results. Depending on the nature of the project, it might be irrelevant or it might be a deal breaker. Especially in cloud environments, it's usually the latter. And everything is in the cloud nowadays.
Obviously it is. Just like when you give a monkey a camera and it takes a selfie, the photo is obviously yours. But the legal system doesn't care about obviousness.
The joke about software developers refusing to enter an airplane running their own code dates back at least 30 years.
Software engineering is unique in STEM in that it has nearly zero regulations. Nobody keeps anybody accountable for quality and there are never any legal consequences. No other STEM jobs is like that, usually there are thousand hoops to jump through to do anything non-standard, but in software there's nothing. You can literally go to prison for forging an aircraft maintenance log, but you can forge JIRA logs to your heart's content and never get prosecuted (at most your employer can sue you for damages but that's it).
A Jira log is not part of a Quality Management System (QMS). An aircraft maintenance log is. If you fake data in the QMS, software or not, for a regulated industry, I can assure you that it won't be taken lightly by the regulators.
Try forging the software validation test records for that airplane's flight control system and see what happens.
My point is exactly that there's no such thing as legally required quality management system for software. And that's what makes software development uniquely shitty in terms of not having documentation or following written instructions, to a degree unseen in any other STEM discipline. Trying to explain lack of knowledge transfer in aviation industry by putting it in terms of software industry was the worst possible analogy out of all analogies that could conceivably be made on this subject.
Forging software validation records isn't illegal because you're forging documents regarding software, but because you're forging documents regarding an airplane. Nobody gives a flying fuck about forged records for software that isn't installed on any airplane. It's not the act of forging that's illegal, but the act of installing forged software on a real airplane. Unlike the airplane repair records, where forgery is a crime in and of itself even if the airplane never flies.
Your reasoning shows why it's so much harder to fix a duopoly than to fix a monopoly. If there was no Apple then Google would get its comeuppance. If there was no Google then Apple would get its comeuppance. But because we have both Google and Apple, we can't punish either.
The mathematician in me wants to solve the problem of the duopoly by first reducing it to a monopoly, which we have known solutions for.
Re: [1] - correct me if I'm wrong, but from what I remember, Rust originally did have GC and relied on it for safety, but as development went on, they added more static checks and eventually, very late into pre-alpha phase, realized they don't actually depend on GC anymore and can cut it out? As in, Rust wasn't part of the non-GC safety research at all, it just happened organically?
Yes, but at this point the critical piece that made no-GC memory safety possible - linear types - had already been researched and known in the FP community. Rust's critical invention was "what if we modeled heap ownership and borrowing with linear types".
Okay, strictly speaking, Rust types are affine, not linear. Leaking Rust values is a safe operation. In a linear Rust the compiler would have to prove all values do not leak, but this would be incredibly difficult and probably make reference counting illegal.
> Rust's critical invention was "what if we modeled heap ownership and borrowing with linear types".
Rust did not invent this (and I don’t believe Rust’s creators claim it did), see e.g. “Linear regions are all you need”[1] (ESOP 2006) and in general the work around Cyclone[2] in the 2000s. There was also Mezzo[3], which did very similar things but described them in a different style (effects instead of affine types), and a fair bit of work that went beyond what Rust can currently express (e.g. fractional capabilities). What Rust did is succeed at bringing a conservative subset of this academic work to production—which is not a small deal, mind you; others (including the Cyclone team) tried and failed.
Yeah, this makes sense. Although all this affine type stuff was also the basis for the C++ move semantics (although the resulting type system isn't affine at all, the mental model is very much that, with deleted copy constructors and all), which predates Rust project by at least a few years. So by the time Rust 1.0 rolled out, it wasn't a new concept at all even in system programming circles.
The actually innovative thing about Rust is how they made object lifetimes into a H-M-esque type system and used this 50 year old algorithm to detect dangling pointers at compile time.
The funny thing is, Rust doesn't quite have a destructive move either. Or, at the very least, it's not exposed to the type system. The Drop trait that tells you if a value of a type T was destroyed can only give you a &mut T to it. There's no type to represent a value you own stored in memory you don't. So we have the funny situation where if you implement Drop, you can't take values out of the thing that got dropped.
Destructive move is when the move skips destructor. Rust does have that. What it doesn't have is destructive destructuring - you can't skip the destructor when destructuring a struct. Meaning you can only destructure structs that don't impl Drop.
reply