Here's a good one for you:
"Explain the double slit experiment which way variation"
If they say anything about leaving two straight lines, then it fails. Just tried Gemini, and it failed.
This is an extremely common misconception that has spread all throughout the internet, and so it is baked into the training data. The real answer is that there are multiple ways to do which way double slit experiments, but Einstein's thought experiment proves it's impossible for any of them have an interference pattern, as that would violate Heisenburg's Uncertainty Principle.
Somehow, not leaving an interference pattern became twisted into leaving a specific pattern of two lines, which then falsely implies that quantum objects lose their quantum behavior in certain circumstances. The field of quantum physics becomes so much simpler to understand once you realize that all of this is hogwash.
The best reference I can find for where this myth started is a documentary about quantum physics that tries to connect it with mysticism. On the other hand, Wikipedia actually has it correct. In its "which way" section in the double slit experiment page, it correctly says "A well-known thought experiment predicts that if particle detectors are positioned at the slits, showing through which slit a photon goes, the interference pattern will disappear".
I'll add to that: you are more likely to have a good experience if it has a lot of relevant data that it was trained on. You are also more likely to have a good experience if errors don't cause major issues.
So one-shotting a game of Snake should be great (tons of training data, errors are easily caught because it's a small program). Similar with building a lot of web UI front end, or one-shotting a personal project. On the other hand, I haven't been convinced that it's good enough to maintain large codebases or assist with niche topics that are not very well documented.
I'm one of those developers, and I think it makes sense to write documentation for Claude and I have no issues with that.
The point of self-documenting code isn't to get rid of the documentation. Instead, it's to integrate it into the code. This fixes the two biggest problems with documentation. First, that the code will often be updated and documentation left behind, making it useless. And second, that English and code are intertwined in the same document, making you constantly switch mental contexts of how you are reading. So no, I don't consider developers who write documentation to be inferior. If anything, I value documentation even more, and the purpose of self-documenting code is to make the documentation better, not get rid of it.
With Claude, the documentation you make for Claude is just fine as it doesn't run into any of the above two problems. The documentation isn't being left behind, because you add to it instead of the code. And it's not intertwined with code, because you are just writing English for Claude, you are not writing code in-between.
While I haven't had this issue with Gmail, I recently got a new computer and the first two weeks for full of moments like this. It's shocking to me how much we've let popups go rampant on everything. Perhaps the worst offender is Windows update, as it won't even let you use your own computer without clicking through 10 screens refusing all sorts of products they are trying to push on you.
The author is definitely not inventing a problem. I ran into this issue at work this month.
We were using WPF, which is C# combined with XAML. I needed to call some async code. First, I tried to call it from synchronous code. That compiled correctly and seemed okay, but then I got vague crashes, and after doing research, I found everyone was like "don't ever call an async function from a sync function" for that exact reason. So instead, I had to change whatever called that to be async, and then whatever called that to be async, and so on. The solution I ended up having to go with was literally changing the code in over a hundred places. This is legacy code that I touch as little as possible, and instead of the one line fix that it felt like it should have been, async turned it into over a hundred small changes throughout the entire project.
I'm not saying there isn't a better approach. I'm pretty new to async/await code as I've been doing asynchronous code through threads my whole programming career. I don't think WPF is a good technology, so maybe some newer tech has solved it better. But what I can say is that this problem was not invented, it is a real problem and it caused a simple change to become a complicated one.
There are two types of "brainrot" that are related but not the same. Essentially brainrot is anything that is anti-thinking.
The first type of brainrot is what happens when you let other things think for you and your thoughts and opinions become not your own. AI is anti-thinking because you can let the machine think for you. Social media is anti-thinking because you can let other peoples' opinions think for you.
On the other hand, memes actually communicate ideas. For example, The Simpsons Ralph meme "I'm in danger" and the dog on fire "This is fine" memes both represent understanding being in a dangerous situation while doing nothing about it. Star Trek was actually way ahead of its time with the episode "Darmok and Jalad at Tanagra" which was about a culture that used memes as communication.
So what do you get when you combine brainrot ("anti-thinking") with memes? You get brainrot memes, which is the second type of brainrot. For example, 6-7. 6-7 doesn't communicate ideas. It doesn't mean anything. Instead, it communicates the opposite of an idea. So when someone says "6-7", they are embracing using language in an anti-thinking way. In this way, brainrot memes can be thought of more as an anti-meme. It's as contagious as an idea, but since it doesn't contain any information, it acts more like a virus. So brainrot memes are essentially mind-viruses that embrace the lack of thinking that comes with brainrot.
They really aren't all that different from each other. One is imaginary things that might one day be possible, and the other is imaginary things that won't ever be possible.
And even then, that can swap between the genres. Scifi often contains FTL tech, which from what we know is almost certainly impossible so it's actually more like fantastical magic. Meanwhile, fantasy can have hard rules for its magic, in which case it acts more like technology that we haven't discovered yet. I haven't read it yet myself, but I've heard of Wizard's Bane, where a programmer is transported to a magical land and becomes really powerful because he treats the magic system like a new programming language.
Other things I've noticed is that scifi tends to involve spaceships and is more mystery oriented, whereas fantasy tends to take place on the ground and is more hero's journey oriented. But even these aren't defining traits. Plenty of scifi books involve investigating alien planets and many contain the hero's journey (including the original Star Wars if you count that as scifi). Meanwhile plenty of fantasy books are on some sort of ship (Narnia - Voyage of the Dawn Treader) and many are more mystery oriented (Harry Potter for example).
Personally, I think a better line of division is hard vs soft. Was the world created first with actual rules and the characters molded to fit the world (Dune, Lord of the Rings)? Or were the characters created first and the rules are bent to create the story that is being desired to tell (Star Trek with its technobabble, Star Wars's prequels and sequels, the entire universe of Harry Potter)?
I agree, and one place I've observed this is in quantum physics. The double slit experiment is an experiment where you shine light through two slits, and instead of the expected two bands, it makes a wave-like interference pattern. This single experiment changed how we view all of physics. However, nearly every source targeted at laypeople claims that there is a variation where you can put a detector on one of the slits and it will show two bands. This is false.
One clue is that these claims never detail on what this "detector" is. There are various types of detectors, and instead of showing a two band pattern they show a single slit interference pattern. By not giving specifics, the claim becomes much harder to disprove. This may not be malicious though, as the source of the faulty claim is likely the miscommunication of a thought experiment proposed by Einstein. Einstein proved by thought experiment that any detector couldn't show an interference pattern, which is easily twisted into the incorrect claim that it does show the two band pattern that people initially expected.
Even with all that, it's simply hard to refute. Like you said, it requires rigorous technical arguments, specifically as the faulty claim didn't specify what kind of detector they use. So the layperson has to choose between <some detector makes shape you'd expect> and <multiple complex existing detectors makes different shape>.
In the end, to a layperson, it wouldn't even seem to be all that important. And yet, almost all of the misunderstandings people have about quantum physics come from this one faulty claim. This claim makes it seem like some objects have quantum behavior, and some don't, and that you can change an object from quantum to non-quantum by detecting it. When in reality, all objects have quantum behavior, we just don't usually notice it.
She graduated with a computer science degree in January, and then her dad passed away. The estate was a mess so she ended up spending time figuring that out. Then, we found and fixed a medical issue that had been draining her energy. She's doing a lot better now, but as a result she has an 8 month gap on her resume. She also never took an internship so that she could finish a semester earlier with summer classes. So now she's absolutely screwed for phase 1.
She switched to phase 2 recently. She got a hit for software support. She got rejected, but the person was like "Why aren't you applying for programming jobs, since you like programming?" They set her up for an interview for an actual programming job, and said her lack of experience wasn't an issue because they had a lot of pull, and that they would offer her a test where she could prove herself. She spent the next several days preparing non-stop for the interview, only for the same guy to be angry at her for not having multiple significant projects on Github and refused to even give her the test.
After that we thought about continuing phase 2, but we both felt like it was just a waste of time, especially after the last experience. She's had previous experience tutoring and I've written some instructional books, so we've now just decided to ignore the job market and form an LLC related to teaching. She'd be a great programmer, and it's really stupid that no one wants to give her a chance, but at some point you just figure the job market is so irrational that we should be able to beat it by doing it ourselves.
I agree, but I'd add that it's not just the tech giants who want them to be better than they are, but also non-programmers.
IMO LLMs are actually pretty good at writing small scripts. First, it's much more common for a small script to be in the LLM's training data, and second, it's much easier to find and fix a bug. So the LLM actually does allow a non-programmer to write correct code with minimal effort (for some simple task), and then they are blown away thinking writing software is a solved problem. However, these kinds of people have no idea of the difference between a hundred line script where an error is easily found and isn't a big deal and a million line codebase where an error can be invisible and shut everything down.
Worst of all is when the two sides of tech-giants and non-programmers meet. These two sides may sound like opposites but they really aren't. In particular, there are plenty of non-programmers involved at the C-level and the HR levels of tech companies. These people are particularly vulnerable to being wowed by LLMs seemingly able to do complex tasks that in their minds are the same tasks their employees are doing. As a result, they stop hiring new people and tell their current people to "just use LLMs", leading to the current hiring crisis.
I don't feel threatened at all. Until we have true general AI like we see in the movies, there's no chance that an AI like AlphaCode could design software, and there's no chance that it could write actual code because it wouldn't be able to name variables. Because of these two things, AlphaCode will always need to take in very specific instructions and output incomprehensible code. Does that sound familiar? That's essentially what a compiler does. There are only two differences that I can see AlphaCode ending up as compared to a compiler.
The first is that we could end up with a programming language that can accept natural language as its syntax. The best case scenario of this is that more people learn how to code as they don't need to learn strict specialized syntax to program. However, whenever this topic comes up it always turns out to be more of a pipe dream, because when you are programming you want precision, and to have precision you need strict specialized syntax. In other words, the advantages of not needing strict syntax are small unless you are not a programmer, and the disadvantages are massive as you might be misunderstood and end up with hard to fix bugs.
The second possibility is that we could end up with generation systems that can build small, well defined functions for us, similar to the problems that AlphaCode is already solving. The problem with this is verifying correctness. As mentioned before, the code that AlphaCode outputs is unreadable. As such, verifying correctness would likely take longer than building it yourself. As a result, anyone needing to use small, well defined functions would be better off using the existing solution of human built libraries. Because libraries are shared between so many programmers, it is much easier for bugs to be discovered and fixed.
So for my summary, all AlphaCode really is, is yet another attempt at a natural language type of compiler, which even if it succeeds wouldn't affect programmers much as languages being well defined is critical for making sure everything runs correctly.
I'd say it was because of the nature of two of the three punishments. Taking away money from someone who had won it in a tournament was too far and "firing" casters (banning casters for either 6 or 12 months is basically firing) who may not have been involved was too far. I think the PR would have succeeded if they had only banned him, even if it was for a whole year, and if they had fined him a fixed amount.
I think the biggest thing that sparked the situation was the casters. While some people feel that they were not neutral due to some comments made, Blizzard themselves in their response did not mention those comments. As such, it appears that Blizzard fired casters for merely allowing controversial topics spoken, which makes it very unclear how Blizzard wants casters to handle similar situations. In other words, Blizzard fired people who were neutral-ish and who were stuck between a rock and a hard place instead of clarifying the situation. TLDR: If a situation is complicated and unclear, clarify instead of firing.
The answer to this which makes the most sense to me is that the wave function collapses when the information exists that determines the quantum state. In Schrodinger's cat, this would be when the Geiger counter detects the quantum state, but by the time the cat dies/does not die and the researcher opens the box, everything is already in the classical world.
Schrodinger's cat was made to be a thought experiment to show how absurd some of the ideas about the quantum world are. We are unable to prove whether the cat does go into a superposition or does not. Personally, the ideas that superposition is tied to whether consciousness observes it doesn't make sense to me. After reading about some of the stranger experiments such as the quantum eraser experiment, I've gravitated towards information theory being the missing link. If that is true, then the astounding conclusion would be that the fabric of our universe is information!
I don't have experience with it, but I have heard of what you are saying and I believe the technical term for it is "hyperacusis". If you haven't already done so, search that term and I'm sure you will find people with similar experiences. I would also suggest trying to find communities on Reddit, it looks like they even have a subreddit with a few hundred people subscribed, "https://www.reddit.com/r/hyperacusis/"
Definitely not the same technique, but at one point I watched a Mario Maker puzzle level someone had uploaded that used part of its own level code as a clue. The trick was that only two characters of the level code were used, which is hexadecimal, so there are 256 combinations of those two characters, allowing the level creator to brute force re-uploading the level until getting the desired combination.
I very much agree and love how the programming language AutoIt does it. When I was starting out, both C and Java took several frustrating hours to set up (don't get me started on requiring environment variables to be manually changed). However, after a basic installation, AutoIt gives its au3 files a right-click context menu option to compile to an exe. It also gives you a shortcut to a help file that contains basic examples, a complete list of language concepts, and a complete list of all first party functions and a page on every single one complete with an example of how to use it.
My take on this is that it has some valid points, but is mostly unjustified rants:
1. Versions: Definitely an issue with Python, the v2 to v3 split was a huge mess and is Python's biggest issue IMO.
2. Installation: Pros and cons, what I find is that Python tends to be easy to set up, but that it does it automagically for you via pip, which means if you run into trouble it is harder than doing it manually
3. Syntax: Python's syntax is wonderful and I find these arguments mostly flawed. The space vs tabs wars are the exception and a valid criticism that the language doesn't force one or the other. As someone on the tab side, I don't run into his issue at all of accidentally putting 3 spaces instead of 4 in, but then I do run the issue of going against the language's grain so to speak.
On the other hand, his issue about deep nesting is a problem in any programming language - unless he is not indenting properly when he wants to, which is my guess. If that is the case, that will cause severe issues when anyone else tries to read it! Debug code without indents also sounds like a bad idea to me. And even if you aren't a fan of Python's whitespace, I find that there are other features, such as using words instead of symbols (and, or, not instead of &&, ||, !) that definitely make Python one of the most readable languages out there.
4. Includes: I'm mixed on this one. On the one hand, I don't understand the first half of what he is saying, I have to go track down includes in any language. In Python at least I only have to deal with one include, whereas in C and C++ I have to go track down two, the header include and the actual library. This mostly seems to be complaining for the sake of complaining.
The last bit I personally agree with though. I once worked on a project that would analyze other people's Python code. At first Python seemed to do this extremely well as it can take any Python code and change it into its abstract syntax tree for further analysis. However, I soon found that in order to do this, it would have to execute any global code while it was reading it! I'm definitely not a fan of how Python technically runs anything it imports.
5. Nomenclature: Definitely unfair criticisms here. First, Python's lists aren't arrays but are lists! Arrays are blocks of unchanging memory, whereas lists are a structure that under the hood points to an array, but that array can be deleted and reallocated to resize it. I admit, I've never liked Python's word for dictionaries, but I don't like hash either, I think map is the better term, but it's still just a single name of a concept, not a huge deal. His arguments about the names of libraries are stupid, they are third party libraries that Python doesn't even control! And as someone who is very picky about function and variable names, a library name hardly ever matters, especially as Python allows you to rename imported modules.
6. Quirks: I don't even understand what his complaint is here. Does needing to triple quote multi-line strings really bother him that much? The binary and raw syntax might be a bit confusing, but I'll take that any day over C++'s L"" for wide strings and _T() for strings that may be wide or not and are determined at compile time. The string vs unicode is a bit confusing, I'll give him that, but I think the entire concept is confusing in any language.
7. Pass by object reference: I actually completely agree with him here, though I don't know how Python would fix this. I think I can explain it better than he does though. The issue is that if you create a list "list1" and then set "list2 = list1", and then append the element "3" to list2, list 1 changes as well even though list1 was never directly changed. This was one of the biggest things I struggled with in Python until I learned C++ better which taught me how Python was working under the hood. Python makes you think that it doesn't have pointers, but the truth is that everything in Python is a pointer, which I found confusing relative to how everything else in Python was beginner friendly.
8. Local names: I don't really understand his complaint here, don't shadow names.
If they say anything about leaving two straight lines, then it fails. Just tried Gemini, and it failed.
This is an extremely common misconception that has spread all throughout the internet, and so it is baked into the training data. The real answer is that there are multiple ways to do which way double slit experiments, but Einstein's thought experiment proves it's impossible for any of them have an interference pattern, as that would violate Heisenburg's Uncertainty Principle.
Somehow, not leaving an interference pattern became twisted into leaving a specific pattern of two lines, which then falsely implies that quantum objects lose their quantum behavior in certain circumstances. The field of quantum physics becomes so much simpler to understand once you realize that all of this is hogwash.
The best reference I can find for where this myth started is a documentary about quantum physics that tries to connect it with mysticism. On the other hand, Wikipedia actually has it correct. In its "which way" section in the double slit experiment page, it correctly says "A well-known thought experiment predicts that if particle detectors are positioned at the slits, showing through which slit a photon goes, the interference pattern will disappear".