This is a terrible idea. This meta tag will get copied and pasted by people who don't know what it means and the site will look just fine to the web developer, but whenever someone with larger text size tries to use the site it will be broken.
In other words this is going to make things worse for exactly the group of people it purports to help.
> No one gets in trouble for saying that 2 + 2 is 5, or that people in Pittsburgh are ten feet tall. Such obviously false statements might be treated as jokes, or at worst as evidence of insanity, but they are not likely to make anyone mad. The statements that make people mad are the ones they worry might be believed. I suspect the statements that make people maddest are those they worry might be true.
People are upset when AIs are anthropomorphized because they feel threatened by the idea that they might actually be intelligent.
Hence the woefully insufficient descriptions of AIs such as "next token predictors" which are about as fitting as describing Terry Tao as an advanced gastrointestinal processor.
The comment you replied to made a point that, if you accept it (which you probably should), makes that PG quote inapplicable here. The issue in this case is that treating the model as though it has useful insight into its own operation - which is being summarized as anthropomorphizing - leads to incorrect conclusions. It’s just a mistake, that’s all.
This article is so batty it's hard to take seriously. The Nordics are not going to be allowed to develop a nuclear weapon. I know the UNSC seems toothless most of the time, but on this issue they are united.
You literally mention 2 of the biggest whatsapp competitor and you have audacity to says "Nobody has even bothered to make an app that stands toe-to-toe with WhatsApp"
If normies who don't care for things (which is most people tbh) don't decide to switch, do you, as a techie/early adopter, just turn off whatsapp and disconnect with your normie friends? You are unlikely to be important enough in the friend group to force a switch, not to mention that this needs to happen enmass for a swing in the network effect to happen.
Being implacably stubborn is underrated. People can trivially have two messaging apps on their phone, which means they can all still contact you while using WhatsApp with other people. Then they all slowly end up with Signal on their phone, at which point who needs WhatsApp at all?
"The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
Yes, you can have two messaging apps, but people will have a “main app” which is typically the one used by important people in their life (family, partner,…) and/or the one used by most people. Meanwhile, if you all use two apps, everytime you want to check up on a friend you have to check two apps.
Imagine all your friends love pizza, as do you.
Suddenly you decide sushi is better so, naturally, you tell your friends to try out sushi at the next dinner.
Assuming some of your friends are not absolutely against sushi, yes, you’ll have that sushi dinner. But what if they don’t like it that much? They will revert to pizza or accept sushi, occasionally, when they want to see you, while still prefering pizza for all other interactions.
There has to be a perceived advantage for changing habits. If few people see the benefits of Signal or other non-Whatsapp apps, they will not change their minds.
> Meanwhile, if you all use two apps, everytime you want to check up on a friend you have to check two apps.
You just have to check the one they use. Also, both of the apps would support notifications when something has happened in that app.
> But what if they don’t like it that much?
There is no real advantage of WhatsApp over Signal except that some people are already using it, and a significant privacy disadvantage. Once someone already has Signal then the advantage of WhatsApp is gone and only the disadvantage remains.
Signal trades some decreased convenience (for example in terms of backup) for some added security. Whatsapp has more “cosmetic” features (polls,…).
If you value privacy over convenience and other features Signal is a great choice. If you value convenience and other features over privacy Whatsapp is a great choice.
I think it’s safe to say that different people have different priorities which result in different choices.
> Signal trades some decreased convenience (for example in terms of backup)
This can't be a barrier to adoption in practice because most people don't even know that it's a thing in order to consider it as a difference, and anyone who both does and cares about it from the outset would have no trouble setting up automatic backups with Signal, and then appreciate the privacy advantage.
> Whatsapp has more “cosmetic” features (polls,…).
> If you value privacy over convenience and other features Signal is a great choice. If you value convenience and other features over privacy Whatsapp is a great choice.
There is no actual reason to use Whatsapp except for the network effect.
> Therefore all progress depends on the unreasonable man.
and only those who actually succeed being unreasonable is remembered. The other unreasonable people simply get forgotten or ignored - the vast majority.
Succeeding a small percentage of the time results in dramatically more success than having no one even try.
Also, you're promoting defeatism. If it's just you and you succeed 1% of the time, it still helps a little. If it's millions of people -- even if that's a small minority of the population -- and they each succeed 1% of the time, that's actually a lot of groups getting converted. And it's more likely to succeed the more people in each group who do it.
So the conclusion should be that everybody should do it, since that improves everybody's odds, rather than that nobody should.
You didnt calculate in the cost of failure. The success of someone being unreasonable might return good results for everyone else (but this is not known ahead of time - otherwise, it would not be considered unreasonable before the success!)
Therefore, you risk the loss resulting from a failure.
It's why you don't just use this argument to gamble or buy lottery tickets.
If it's so easy to replicate, why isn't there any other app that has replicated it?
Signal is the closest but they fall short because they prioritize privacy over features. Which is their choice to make, but it means they have ruled themselves out from going mainstream. If you're not targeting feature parity with WhatsApp then you have zero chance of supplanting it.
Telegram prioritises idk the FSB spying on your chats, that app gives me the creeps.
Signal allows you to do local chat export for backup, as opposed to WhatsApp (which only allows backup to Google account on android). That's actually my biggest complaint against WhatsApp and Viber: why don't you allow local backup, or backup to something I control?
Correction, in case you're interested: Whatsapp does (and has always done) allow local file backups. I know because they are just there on the storage:
Android/media/com.whatsapp/WhatsApp/Backups/
I also know because for many years I was VERY cloud-averse so for several iterations of smartphone purchases I did migrate my chat backups between phones (plain copy-paste of files with a computer) without issues.
XML is extensible markup, i.e. it's like HTML that can be applied to tasks outside of representing web pages. It's designed to be written by hand. It has comments! A good use for XML would be declaring a native UI: it's not HTML but it's like HTML.
JSON is a plain text serialization format. It's designed to be generated and consumed by computers whilst being readable by humans.
Neither is a configuration language but both have been abused as one.
This assertion is comically out of touch with reality, particularly when trying to describe JSON as something that is merely "readable by humans". You could not do anything at all with XML without having to employ half a dozen frameworks and tools and modules.
> The complexity about XML comes from the many additional languages and tools built on top of it.
It's not just that, is it? There are also attributes versus child elements, dealing with white space including the xml:space attribute, namespaces, schemas, integration of external document fragments with xinclude:include or &extern;. Each of these is a huge can of worms in its own right. There are probably more that I'm not even aware of right now.
A few years ago, I wrote a fully functional parser for JSON that is easy to verify for correctness and that isn't just lying around somewhere as a toy, but is actually used (by me) in various projects time and again. Overall, building this parser was almost trivial. With XML, I'm not even sure I would be able to write a correct and complete parser.
But I agree with you that XML-based languages and XML tools make things even worse. I had to work with XML a lot over ten years ago. I still get annoyed when I think about XSLT, or dealing with schemas, or the challenge of finding usable tools that are reasonably compliant with standards.
You can only have a positive view of XML when you think of something like this:
And at that level, I have (almost) no problem with XML. But as soon as things get more demanding and you really take the various aspects of XML's value proposition seriously, you enter a world of pain and despair. At least, that's how it was for me back then. Maybe I would see things differently today, but I'm not really interested in finding out.
First, you're describing the parsing side, while the message I was replying to claimed that it can't be written by hand.
Anyhow, schemas, XInclude and even namespaces are what I was referring to as additional languages of tools.
In your application you use them if you want, they're not really part of XML.
Of course even a parser for plain XML is a lot more complex than one for JSON, but people usually use libraries for that...
In any case, in your application nothing prevents you from using a dumbed-down version of XML, without entities, white space handling, and even only looking at elements and attributes; there were some applications that did that.
That already gives you a format that's easier to read and write manually than json.
I had more to say about "attributes versus child elements", but it's taking me too much time, I'll probably do that tomorrow.
I think I understand your point. I only brought parsing into play to illustrate that XML is complicated, not because it's my general focus. I wouldn't classify namespaces, etc. as additional languages and tools, but that's beside the point.
> in your application nothing prevents you from using a dumbed-down version of XML
That's right. And if XML were exactly that, then there wouldn't be so many people frustrated with it. Unfortunately, in a professional work context, you don't always have control over whether it stays within this manageable subset. Sometimes the less pleasant aspects simply come into play, and then you have to deal with the whole complicated mess.
Are you sure about that? I've heard XML gurus say the exact opposite.
This is a very good example of why I detest the phrase “use the right tool for the job.” People say this as an appeal to reason, as if there weren't an obvious follow-up question that different people might answer very differently.
SGML was designed for documents, and it can be written by hand (or by a machine). HTML (another descendant of SGML) is in fact written by hand regularly. When you're using SGML descendants for what they were meant for (documents) they're pretty good for this purpose. Writing documents — not configuration files, not serialized data, not code — by hand.
XML can still be used as a very powerful generic document markup language, that is more restricted (and thus easier to parse) than SGML. The problems started when people started using XML for other things, especially for configuration files, data interchange and even for programming language.
So I don't think GP is wrong. The authors of the original XML spec probably envisioned people writing this by hand. But XML is very bad for writing by hand the things that it eventually got used for.
Perfectly sure. XML is eXtensible Markup Language, the generalized counterpart to Hypertext Markup Language.
XML, HTML, SGML are all designed to be written by hand.
You can generate XML, just like you can generate HTML, but the language wasn't designed to make that easy.
Computers don't need comments, matching </end> tags, or whitespace stripping.
There was a time, in the early-mid 2000s when XML was the hammer for every screw. But then JSON was invented and it took over most of those use cases. Perhaps those XML gurus are stuck in a time warp.
XML remains a good way to represent tree structures that need to be human editable.
I have always said this and had people on HN reply that they don't get much use out of autocomplete, which puzzled me.
I'm starting to understand that there are two cultures.
Developers who are mostly writing new code get the most benefit from autocomplete and comparatively less from Claude Code. CC is neat but when it attempts to create something from nothing the code is often low quality and needs substantial work. It's kind of like playing a slot machine. Autocomplete, on the other hand, allows a developer to write the code they were going to write, but faster. It's always a productivity improvement.
Developers who are mostly doing maintenance experience the opposite. If your workflow is mostly based around an issue tracker rather than figma, CC is incredible, autocomplete less so.
I’m in the “write new stuff with cc and get great code.” Of course I’ll be told I don’t really know what I’m doing. That I just don’t know the difference between good and bad quality code. Sigh.
The main "issue" I have with Claude is that it is not good at noticing when code can be simplified with an abstraction. It will keep piling on lines until the file is 3000 lines long. You have to intervene and suggest abstractions and refactorings. I'm not saying that this is a bad thing. I don't want Claude refactoring my code (GPT-5 does this and it's very annoying). Claude is a junior developer that thinks it's a junior. GPT-5 is a junior developer that thinks it's a senior.
Definitely agree here, have had so many cases where I would like ask Claude for XYZ, then ask for XYZ again but with a small change. Instead of abstracting out the common code it would just duplicate the code with the small change.
I don't think it's viable to containerize an IDE. Running user code at full permissions is a core feature for an IDE. The programs that the user develops in an IDE could potentially touch any OS surface. When the user is a developer, you have to trust them.
Though this autorun feature is crazy and should be completely off by default.
Yeah, there are already major opposition parties advocating EU exit in many countries already. Try to centralize further and their support will increase. Contrast that with the US when it unified. George Washington won the election 69-0 in the electoral college. And that's not even getting into any of the other massive problems with EU unification.
Claude is my loyal assistant who tries its best to do what I tell it to.
GPT-5 is the egotistical coworker who loves to argue and point out what I'm doing wrong. Sometimes it's right, sometimes it's confidently wrong. It's useful to be told I'm wrong even when I'm not. But I'm not letting it modify my code, it can look but not touch.
It's not like I'll get a choice between the task database going down and not going down. If my task database goes down, I'm either losing jobs or duplicating jobs, and I have to pick which one I want. Whether the downtime is at the same time as the production database or not is irrelevant.
In fact, I'd rather it did happen at the same time as production, so I don't have to reconcile a bunch of data on top of the tasks.
But even for the logical databases, if I want to revert to an earlier state of the database, why wouldn't I want the tasks as well? If I have a bunch of update tasks in flight at that point, wouldn't I want them to actually run? They are a part of the overall state of the system.
In other words this is going to make things worse for exactly the group of people it purports to help.
reply