That does not match my experience at all. I'm sure this did happen, but what I see from agents is obsessively checking `git status` before doing anything git related.
It sounds like, of the three options given, you are squarely in the “authorities” camp (although it seems to me that you interpret the question as asking what you believe should happen, whereas it appears to be asking what happens in practice). Wouldn’t it be interesting to hear the other points of view?
Why this is preferable? I would rather have the apps I use represented as a list of apps in my system (drawing on a couple of decades of established UX conventions for how they are displayed and how I can interact with them), the web content I'm reading represented as tabs in my browser, and my terminal sessions represented in my terminal. You present the destruction of this simple separation of concerns as a benefit, but don't explain why it is one.
> You present the destruction of this simple separation of concerns as a benefit, but don't explain why it is one.
And you present the division of this simple unification of modalities as a benefit, but don't explain why it ought be many.
So far it's all just preference.
I'm not going to deny that the terminal has a ramp, is a lifelong learning curve. But I personally find it much more earnest, much closer to what is really happening, with less intermediation, and the way that terminal conposes with other things is usually unbeatable. TUI for humans, jsonl event sourcing for machine-to-machine.
> drawing on a couple of decades of established UX conventions for how they are displayed
I tend to not just click random apps open. I tend to have done some research and found what options there are on my own. I tend to know what I'm looking for, by the time I'm going to run something. In terms of getting there, finding stuff: the best convention I know of is aptitude, and dselect before it. Both very fine very old tui systems, and clear cuts above any app or web store, imo, for its power, directness, clarity, intent, and script ability.
If age of conventions is a valuable metric, TUIs have more. The keyboard hasn't change noticeably, and I can work way faster between separate windows/panes in a terminal and tmux, than in various GUI windows, where mouse focus dictates when I can start inputting.
While a mouse can theoretically use all pixels of a screen, in practical terms a keyboard has a much larger input space than a mouse, and if I can keep both my hands on the keyboard, I can work a lot faster.
At least that's my experience as a (starting) greybeard.
> From the various reports, including by people aware of gmail's stance, gmail may have had a bug allowing it at some point.
I think these are simply people who cannot believe that someone might give out an email address they do not actually own, either because they are confused or because they make one up on the spot just to fill in a required form field. So when they receive messages intended for someone else but addressed to another variant of their own address, they treat that as proof that the intended recipient owns that variant. In reality, people giving out email addresses they do not own is extremely common.
I see a lot of people swearing up and down that they have seen proof that such a Gmail bug exists. But whenever you dig into the details, it turns out that all they have actually seen is emails intended for someone else arriving in their inbox. There is never any direct evidence that two people were able to register two Gmail addresses that normalize to the same canonical address.
Wait, what you're describing sounds like Gmail working exactly as documented. If I understand correctly, your name is something like John P. Smith, and there is also someone named John Psmith. You own john.p.smith@gmail.com, which means you also own every variation of that address created by adding or removing dots, such as johnpsmith@gmail.com or jo.hnps.mith@gmail.com. This of course includes john.psmith@gmail.com. It is entirely yours, and nobody else can have it. If someone gives it out as their own address, they are simply confused.
I registered my Gmail account very shortly after the invite-only public beta began, so my Gmail username is simply my first name (in this example, it would be john@gmail.com). Believe me, I know a thing or two about confused people giving out email addresses that don't belong to them.
Importantly, the dot-normalization rule was there from the very beginning. You learned about it alongside all the other kooky ways Google had decided to reimagine email, including 1 GB of storage, conversation threading, and an interface with a prominent "Archive" button but no visible "Delete" button.
In my mind, the part that is most likely to fail is "return an HTML document that still contains the following text." Nowadays, more and more "HTML documents" do not contain any content at all, just some JavaScript that is responsible for then fetching and displaying the content.
If the text was returned using a staged process, whereby the server first returns an instruction (JavaScript), and the web browser then executes that instruction, which is what transfers the text, then that doesn't actually change anything. Those are just technical details of the transfer. You are viewing an HTML document on-screen; it makes no difference to this bet if it was returned to you by a different mechanism than originally conceived, since the bet doesn't specify any transfer mechanism, just that the URL was entered into a browser.
I understand that this isn't entirely clear-cut and that people will interpret it differently, but in my opinion, there is a significant difference between "a webpage that contains text X" and "an HTML document that contains text X." "Webpage" and "HTML document" are not synonyms - "HTML document" has a much narrower meaning.
Even if you interpreted the bet generously to allow for a browser to render the content using JavaScript, if I understand the bet correctly, the condition of working with a command-line tool like curl would fail.
I read the or's as giving alternatives, only one of which needs to work.
I can see how other interpretations are possible, but I don't see anything especially generous about mine. I'm not "allowing" anything: To make a judgement you have to pick a web browser to try it with, and you'd probably pick the most popular one, in the most popular configuration, that seems the most fair. If that web browser happens to execute Javascript when you navigate to an URL, then that's just how it is.
It says that the browser must download "an HTML document that still contains the following text". I can see how either interpretation could work, but I would interpret "contains" as "the text is in the HTML document", not "rendering the HTML document in a JavaScript-capable browser displays the text".
(Though, that said, some approaches to rendering sites via JavaScript would still have that text in the initially downloaded HTML file as JavaScript data.)
As for the "or", I read it as "doing either X or Y must", not "either X must or Y must (not necessarily both)", but yeah, I can see either interpretation being valid.
That depends on which side of the JS rendering bullshit you're sitting. If you're on the serving side, yes.
But I do the same as GP, just on the receiving side. That is, reaching out for help to baby eldritch entity, because that's healthier for my mind than dealing directly with the unspeakable horrors that half the websites are today. The industry has lost its collective mind in pursue of profit and control, and that was long before the thousand-mask wearing shoggoths became our daily consorts.
Oh, absolutely. I started writing Python professionally in 2010. Whenever a new group of people started working on a Python project, one of the first things they had to decide was tabs versus spaces. Everyone would begin by saying that the question was unimportant and silly, but then immediately add a “but” followed by a detailed justification of their personal preference. That would lead to people spending two full days exchanging arguments and links to blog posts.
Worse, sometimes you would start working on a project without having that discussion first, only to discover a few days later that the code was failing because different people had different indentation settings in their IDEs, both regarding tabs versus spaces and the number of spaces. You would then have to pause the work, go back, have the discussion, and decide who was going to fix all the code committed so far.
This only stopped when linters became popular. They may be a little like vaccines: when they work, you do not see them working, so it is easy to forget what things were like before. But believe me, when they appeared, they were a breath of fresh air. We could finally focus on discussing the work rather than the conventions.
And tabs versus spaces is only one example. There used to be PR discussions about countless style issues throughout the entire lifetime of a project. That was not entirely unreasonable, because a consistent style genuinely makes a project easier to work on. But when every individual convention has to be negotiated by humans, it takes enormous amounts of energy and becomes tedious very quickly.
> only to discover a few days later that the code was failing because different people had different indentation settings in their IDEs, both regarding tabs versus spaces and the number of spaces.
yeah, why Guido got away with the "we don't need deliminators, white space is just fine" for so long has always baffled me.
Because somehow a special character that marks the start and end of a block is hard for people to understand??
I think that tabs vs spaces is a rather extreme example because it has unexpected parser semantics - that is, it's not a style choice. So I don't think it's actually relevant to a conversation about conventions/ style.
It definitely is relevant to a discussion about linters. And as I said on my comment - it's just an example, I mentioned other types of discussions as well.
Since this is a long-standing, real-world problem that linters solved, how could it not be relevant to a discussion about the usefulness of linters?
And the choice of whether to use tabs or spaces does not affect semantics. It is purely a matter of style. Indentation using tabs and indentation using spaces work in exactly the same way.
Because the discussion is about style enforcement and you're talking about semantics enforcement. You may as well be talking about generator comprehensions vs list comprehensions - they're two totally different things semantically.
> It is purely a matter of style. Indentation using tabs and indentation using spaces work in exactly the same way.
This isn't true. It changes how the code can be interpreted by tooling, and it changes how Python interprets the code because it's whitespace sensitive. It's also invisible. It's such an extreme example, I don't think this is reasonable to bring into the conversation for style discussions.
You both seem to be using a different definition of "singularity" from the one I'm familiar with. I've always understood it to mean a rapid feedback loop in which AI creates successive, increasingly capable generations of AI outside human control, rather than simply a level of technological advancement that would be incomprehensible to someone
The reason the term "singularity" was used when that term was coined was in analogy to a black hole, which has a point on its radius called the event horizon where the gravitational pull is strong enough to stop light from escaping, thereby making it impossible to see beyond that horizon. "Technological singularity" itself here refers to the technological event which causes this, like a black hole is sometimes explained as a gravitational singularity
This is important to the framing of the idea: "the technological singularity" refers to a point in the future past which further developments can't be meaningfully foreseen or maybe even understood. This is often associated with particular paths people think will cause this, but not defined by those. As such, the prior comments are making the claim that you can get there not just by accelerating technological progress, but also by reducing the ability of everyone to comprehend what's happening, which I agree is unfortunately a plausible outcome in the current world
To expand on this, I prefer calling this "the event horizon" rather than "the singularity", as that makes it clear (I hope) that I mean "can't predict" rather than "goes to infinity".
With this framing, my prediction for that horizon has been "around 2030" for over a decade now, as several different currently-exponential growth trends start giving results with weird implications around that year.
(LLMs look like they're ahead of schedule for this, but consider their power requirements and limitations on AI in robotics that mean they're not quite good enough on the "G" part of "AGI" to affect non-desk jobs).
The singularity is when an AI can improve itself, which among the results include humans no longer being able to understand its code and exponential improvements so we can't catch up either.
It requires a level of self-driven intent LLMs aren't capable of on their own.
> And this thread is seemingly full of people claiming AI can read it while simultaneously sharing that AI could not read the actual message, only the decoy as demonstrated in TFA.
That’s 100% on the authors for failing to make the default main “hidden” text and the decoy easily distinguishable. The way this is set up is incredibly confusing.
reply