Is creating a giant wobbly world of unreliable AIs all talking to each other in effort to get their own tasks accomplished, is that leaving us much better off than humans doing everything themselves?
Better yet, if you have an application that does exactly what you want, why would you (or an AI representing you) want to do anything other than use that application? Sure you could execute this binary and get what you want, OR you could reach to the AI-net and make some other AI do it from scratch every time. With inherently less reliable results.
The world right now is pretty strict just because of how software has to be, which has a lot of upsides and downsides. But there's some wobblyness because of bugs, which break contracts.
But I think then in the future you have AI which doesn't make mistakes and you also have contracts.
Like the airline agent booking your flight (human or AI) has a contract - they can only do certain things. They can't sell you a ticket for one dollar. Before applications we just wrote these contracts as processes, human processes. Human often break processes. Perfect AI won't.
And to us, humans, this might even be completely transparent.
Like in the future I go to a website because I want to see fancy flight plans or whatever and choose something.
Okay, my AI goes to the airline and gets the data, then it arranges it into a UI on the fly. Maybe I can give it rules for how I typically like those UI presented.
So there's no application. It works like an executive assistant at a job. Like if I want market research, I don't use an application for that. I ask my executive assistant. And then, one week later, I have a presentation and report with that research.
That takes a week though, perfect AI can do it instantly.
And for companies, they don't make software or applications anymore. They make business processes, and they might have a formal way for specifying them. Which is similar to programming in a way. But it's much higher level. I identify the business flow and what my people (or AI) are allowed to do, and when, and why.
What is different about it? I don't see any constraints here relevant to having a different type. Note that this thread has already confused the issue, because they said filename and you said path. A path can contain /, it just happens to mean something.
If you want a better abstraction to locations of files on disk, then you shouldn't use paths at all, since they break if the file gets moved.
Typically the way you do this is you have the constructor for path do the validation or you use a static path::fromString() function.
Also paths breaking when a file is moved is correct behavior sometimes. For example something like openFile() or moveFile() requires paths. Also path can be relative location.