I've been working on a type checker for a language with ad-hoc overloading and what I did was have the checker proceed iteratively, making passes over the set of constraints and applying deduction rules. So it never guesses, branches, or has to backtrack. If it can't make progress because there's too much overloading, it gives up and asks the user to add some type annotations. I suspect this will actually work quite well in practice even if it can't type check some valid programs.
Ok well you asked. I've been using Xcode for 15 years now professionally. I have two CS degrees and one of my apps was featured on the Mac App Store front page. So, basically, I know wtf I'm talking about.
I detest Xcode.
The latest horrible thing it has done to me is decide to ignore various important Build Settings, throwing them under User-Defined. Doesn't say way. Just pure magic bullshit.
It crashes occasionally, but that doesn't bother me that much. You just laugh at how bad it is and restart it.
Sometimes you'll get some code-signing errors and you just reboot. I kid you not. You reboot and they go away.
Xcode's connection to Xcode Cloud is pretty flakey too. Quite often it will fail to log in. You just restart Xcode and it goes away.
Xcode will display errors that are out of date all the time. I've gotten so good at knowing which errors are just BS that I'm kinda proud of myself.
Previews are useless. They could be so great but as soon as you break one, the debugging experience is so bad, you just give up. Sometimes your project will fail to build with them and the reasons are so opaque you just give up.
The xcodeproj file format is merge hell. It's so telling that tools like Xcodegen exist.
The new LLM-based code completion thing is mostly just amusing. Definitely not ready for prime time.
There's clearly no CI on the template projects because if you archive the Audio Unit one, the swift compiler crashes currently. Wheee!
Nobody uses the git integration on Xcode AFAICT. It runs faster if you just turn it off.
The GPU debugger is quite a crashy mess, though it has gotten better. Still you will not be able to debug your shaders and you'll have no idea why. The GPU debugger doesn't work if you put any MSL code inside a Swift package too. I used to have an icky work around for that, then just gave up on modularizing my project to the extent I would like to.
I experienced the issue mentioned in the article: couldn't add local packages by dragging them in. But somewhere along the line it went away. Don't know why, and I don't have the time to dig into it.
I really should compile a proper list. I'm sure I can think of more, especially if I go through the list of bugs I've filed over the years.
Anyway, now you've heard this opinion expressed by an experienced person. Consider it a data point.
Great list, way different than most of the comments on this thread. I don't see a single one I disagree with. I'd ask though, which IDE do you think is better than Xcode and in what way? My only argument I'd have against this list is it's kind of par for the course for an app of Xcode's age and complexity, e.g., you'd for sure get a similar list from Premiere or After Effects users, or any of the long-standing 3D packages (although, for a counterpoint, Logic Pro and Final Cut Pro users seem way happier, so it's at least theoretically possible to make complex, long-standing applications without these issues).
Before iOS, I was coding animation software on Linux using vim/scons for five years. So no real IDE. But not a fair comparison because we had a build team keeping everything nice. I also ported one of my apps to Windows and Visual Studio never drove me crazy. But I haven't worked with it to nearly the same depth as I have with Xcode.
So I concede that perhaps all IDEs are dreadful. I still hate Xcode.
I know pro users of Logic and Ableton and they never express such a level of displeasure. FWIW, having used Logic, Ableton, FCP, all non-professionally, those apps seem like a dream compared to Xcode.
I think it's likely that if Xcode weren't free, there would be serious competition and iOS development would be better for it. Or perhaps if Xcode were modularized so 3rd parties could use parts of it (Instruments, GPU debugger, memory graph debugger), lowering their development cost so they can compete with free.
I tried AppCode and while it seemed nice (refactoring was good in particular), I kept returning to Xcode to use the GPU debugger IIRC.
So, amusingly, I'm the inverse of your impression: the IDEs I've tried superficially I've generally enjoyed. The one I've used deeply I detest.
Thanks for sharing this! For Visual Studio, I always think of this video https://www.youtube.com/watch?v=wCllU4YkxBk that pretty much just leaves the JetBrains IDEs, which are obviously well loved. I've never had a good first impression with them, so I haven't bothered to get deeper into them, but I also don't have the experience to form a fair opinion (although when I read about what folks like about JetBrains, it doesn't resonate with me, usually it's about refactoring tools, which I don't care about).
Reporting in with my experience with JetBrains IDEs - they are generally OK, but the quality has gone massively down over the last couple of years (some worse than others, Rider has been okay, though new features often just don't work at all). Quoting my own comment with some memorable new issues in WebStorm from last year, written a couple of months ago (with links to the issue tracker)[0]:
- The autocomplete popup sometimes froze the IDE completely (and killing the process caused minutes of data loss), open for close to a year
- Since two months ago, the Typescript language server fails to start in Vue projects (due to a broken update by the Vue team). A fixed version of WebStorm was released yesterday, in the meantime you were apparently expected to search for the error message, stumble upon the YouTrack page, and apply a workaround
- Performance is abysmal in a larger React MUI project, think 10-15 seconds for feedback on code changes, sometimes errors just stick around for a good minute or more
- In some situations WebStorm makes autocomplete suggestions that aren't allowed - think effectively a type T with keys K | L, where Omit<T, K> leads to only suggesting K properties, while removing the Omit makes it suggest both K and L properties
- After updating from 2024.1.X to 2024.2.Y, the window had no buttons for minimizing/maximizing anymore. Now, this was partially caused by my environment, but after I found a workaround it was closed as "Third Party Problem". Still feels like a regression to me, since my environment did not change.
I've mostly stopped updating the IDE, as almost every version brings new regressions in basic editor features. This morning I updated and tried to copy some text. WebStorm showed me a "Copying..." dialogue for more than 30 seconds.
I’m not sure but you can see this in Reddit. Far left, right, and also the center subreddits have zero sympathy for United given high denial rates, likely illegal AI based denials, the breach of subsidiary Change Healthcare they leaked everyone’s private medical details, the insider trading from the CEO, etc. It highlights a massive unified appetite to bring megacorps under control.
Like a bizarro cousin of loop closure in SLAM— which is recognizing when you've found a different path to a place you've been before.
Except this time there is no underlying consistent world, so it would be up to the algorithm to use dead reckoning or some kind of coordinate system to recognize that you're approaching a place you've "been" before, and incorporate whatever you found there into the new scenes it produces.
I was imagining a few limitations to help with consistency: all scenes have the same number of edges (say, 10) ensuring there's a limited set of scenes you can navigate to from the current one and previously generated scenes can get reused, and no flying, that way we can only worry about generating prism-shaped rooms with a single ceiling and floor edge.
I suppose this is the easy part, actually; for me the real trouble might be collision based on the non-deterministic thing that was generated, i.e. how to decide which scene edges the player should be able to travel through, interact with, be stopped by, burned by, etc.
I know you didn’t mean it like this, but this is kind of an insult to the insane amounts of work that go into crafting just the RNG systems behind roguelikes.
If you have a recent machine, the actual developer experience isn't too bad. It's just not a language for language purists (was it ever?).
I'm enough of a purist to be annoyed whenever I see the "expression took too long to type check" error. (I think bidirectional type inference isn't worth it with Swift)
The gaggle of verbose pointer types makes me want to switch to C++ whenever I have to deal with memory directly.
As the article mentions, a bunch of features were added for the sake of SwiftUI. Function builders allow SwiftUI's syntax to be minimal. They allow you to write:
VStack {
SomeView()
AnotherView()
}
instead of something like
VStack(
SomeView(),
AnotherView()
)
Given the rather bad (still!) error messages you get with SwiftUI that seem to be a result of function builders, I'd say it wasn't worth it. At least I get fewer of the "couldn't produce a diagnostic, please file a bug" errors than I used to.
Then there are property wrappers, which wrap struct/class fields with get/set code (IIRC Lattner didn't like the property wrappers). They've been partially replaced in SwiftUI by macros. The @Observable macro (probably the most widely used one) decorates your class with code that notifies listeners (almost always SwiftUI) of changes. I'd be curious to see what SwiftUI would look like without property wrappers (or macros).
I think they had a missed opportunity to really add robust updating of views in response state changes. Currently it's still relatively easy to not have your SwiftUI views update because your data model uses some object that isn't @Observable.
I wrote a UI library inspired by SwiftUI, but in Rust [1], and of course I couldn't add anything to the language, and more experienced Rust programmers discouraged me from using macros. So it can be done without all the extra stuff Swift added.
Well, probably wouldn't be able to convince you that the artists playing shows using Euroroack (or Elektron, or TE) in front of bigger audiences that you ever have are "genuinely good."
> The OLED never really shows you anything useful to the act of music-making.
Thou art prone to hyperbole! Said instrument of synthesis ("Operator-1") has a step sequencer, mixer, ADSR envelopes, recorder, and other useful indications for the bard. One ponders how thou hast not consulted the scrolls [1].
I owned an OP1 from the day it was released until 6 days after I discovered it rotting in a drawer, unused, in a room full of far better examples of synthesizer interface. I tried really hard to accept Teenage Engineering's priority of non-sequitur over functionality.
Sure, the OLED occasionally shows you a few things. But its completely useless compared to, say, the utility eked out of the display of the Deluge, or Bluebox. By comparison to either of these devices, the OP1 is unacceptably paltry for the price.
And then, there are the Pocket Operators. Don't get me started on just how useless that very expensive bespoke LCD print is to the musician...
Blasphemy! Thou shalt not present such claims without the proper scrolls and ledgers of sales to substantiate. Ist thou not acquainted with the more-expensive instruments of musical synthesis available?
