[OnlyMortal]

I’m with you. The original applications of Project Builder, Interface Builder and TextEdit were better because they were focused.

Feature creep is never a good thing.

It’d have been better to build tools for Swift in its own right, allowing those tools to integrate - probably by using distributed objects.

But, it isn’t that way so such is life.

[azinman2]

I strongly disagree. I don’t want to have to open multiple tools when it should all interoperate together for the same effective high-level task. Unifying it all just allows for better (hypothetical) integration between all the parts.

Just remember — integration doesn’t mean it has to be bad or slow (current Xcode can always be improved).

[adrusi]

Multiple tools doesn't mean that they can't interoperate. It's just that Apple (and everyone else) has given up on graphical IPC.

[nexuist]

+1 for the term "graphical IPC." It is a huge pet peeve of mine that native apps choose to push new views onto navigation controllers instead of just opening a new window. They're looking to invent browsing history when there shouldn't be any (and if you need browsing history - use a browser!).

[adrusi]

Ah, but if you open a new window, then users will have too many windows open and get confused or frustrated! You would need some kind of innovation in window management beyond the 1990s for that to be feasible.

But desktop OS vendors seem to still be operating under the paradigm of making their desktop environments as approachable by computer novices as possible. Maybe still a good business decision, but the future for desktop OSs is clearly with professionals and enthusiasts, and it's my hope more advanced human/computer interface approaches will follow.

You can have better window management facilities on Linux, but you have to choose between software that copies the mainstream paradigm of, as you say, pushing new views onto navigation controllers (and I'd add using tabs/split-panes built into the window itself instead of being offloaded to a more sophisticated window manager), or software that's quite rough around the edges.

[colejohnson66]

What’s a graphical IPC? How would processes communicate graphically?

[nexuist]

Not OP but my layman's understanding is that it would just be two GUI windows communicating over standard IPC. The current trend is for the entire application to be represented as a singular window, using navigation or tab controllers to switch between views rather than popping them out into their own windows.

[adrusi]

Better window management paradigms aren't quite what I was referring to, but would also be great for mainstream software vendors to not have given up on. I use the Sway compositor on my personal machines to get some sort of reasonable window management tooling, which is lovely to the limited extent that even Linux software embraces composability in graphical environments. Would be nice to have similar tools on my work macbook.

[karlmdavis]

Check out Amethyst for Mac OS. It’s a bit buggy, and it’s not Sway, but it’s Sway-like enough for me to get by on my work system.

[adrusi]

More precise would be to say "graphical IPC control" or "graphical IPC initiation." I'm trying to point to the ability for users in a graphical environment to coordinate intricate communication between processes. Copy/paste and drag-n-drop are canonical examples, but I'd say that macOS tools like Alfred should also count.

[nexuist]

> Just remember — integration doesn’t mean it has to be bad or slow (current Xcode can always be improved).

How is VS Code so popular, if its big brother Visual Studio can do everything it does and more?

Doesn't this signal that the market prefers lightweight IDEs over heavier ones?

Me personally, I would love to have a text editor on the left and the iOS simulator on the right and that's all you need to ship. Xcode Playgrounds attempted to execute this shift, but they still need much more attention until they can function as well as the regular workflow does (which is sad, 'cause the regular workflow sucks).

[jcelerier]

> How is VS Code so popular, if its big brother Visual Studio can do everything it does and more?

I only know extremely few people who'd use VS Code for C++, so "popular" is really ecosystem-dependent

[BearOso]

I use it. VS Code+clangd intellisense makes it easy to enumerate available classes, functions, and members, and because you don’t have to remember excessively verbose objects, writing self-documenting C++ is simple. Plus, you get automatic syntax checking as you go. That you can get these in a less-than-IDE nowadays is wonderful.

[plorkyeran]

Visual Studio does not do a superset of what VS Code does. There's the very obvious difference in that VS is Windows-only while VSC is not (there is a Visual Studio for Mac, but it's a third unrelated program and not a Mac version of Visual Studio). Even if you are running Windows, VSC has more functionality than VS for non-C/C++/.NET development.