tayistay

Viewable from the commuter train (BART), there is a large storage facility in Oakland which advertises air conditioned units. Outside is a large homeless encampment. Sigh.

Can I call into the interpreter from multiple threads or does it use global state?

Congrats! I think this could be quite useful for me.

I noticed that `let`-declared variables seem to be mutable. I'd strongly recommend against that. Add a `var` keyword.

Re 2: Iran previously launched drones and missiles at Israel about a year ago. See https://apnews.com/article/strait-of-hormuz-vessel-33fcffde2...

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.

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.

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.

What podcast?

I suspect the problem there is that the multiple paths to a new location will not yield consistent results.

Google says: “California is the largest agricultural exporter in the United States”

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.

[1] https://github.com/audulus/rui

Does the article mention if the 1 in 6 is actually a change vs previous years/generations? I didn’t see anything.

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].

[1] https://teenage.engineering/_img/54b7f9bf8681400300255cab_or...

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?

Under disadvantages:

> You can also call the layout code twice (once to get the size, once to do the interaction), but that is not only more expensive, it's also complex to implement, and in some cases twice is not enough. egui never does this.

I've found multi-pass imgui to work totally fine, and I use it for one of my apps [1]. I can support (nested) hstack and vstack layouts which IIRC egui can't. There is added expense of calling the "draw" code again, but it's negligible in my profiles (doing the actual layout calculations is more expensive, so I only invalidate the cached layout when the data model changes). It wasn't particularly complex to implement: each ui function simply does different things if you are doing a layout pass vs a draw pass.

[1] https://audulus.com

So much is bad about it:

> After two weeks, I come up with some of my own tweaks that make the algorithm work a bit better. I happily add “built a state-of-the-art library for numerical integration, with novel improvements on the best techniques in the academic literature” to my resume.

Ok so he's a liar. He made something "work a bit better" and then claimed to build the whole thing. Two weeks of work. Talk about resume padding.

> After declaring, I finally get assigned an adviser who doesn’t tell me to take easier courses.

Where I went, you barely got any such advice. P R I V I L E G E.

> Math classes haven’t saved me from getting bored of college.

Links to an another article "Why I left Harvard early" oh FFS

> directly trying to improve the world, at Wave.

As opposed to those lesser folks who aren't "directly" trying to improve the world, or just not improving the world at all. Just trying to get by and live a decent life.

> For some reason, a lot of smart college students end up with the idea that “solving hard technical problems” is the best thing they can do with their life

Well it's better than fucking up the world at least.

> most graduates of elite schools—including me—

Yes mr elite.

> my root goal was to use my skills to get the most possible leverage on improving the world.

I'm reminded of the great "Make the World a better place" skit from Silicon Valley.

> Thanks to Eve Bigaj, Alexey Guzey, Jeff Kaufman, Dan Luu, Lincoln Quirk, and Yuri Vishnevsky for reading a draft of this post.

Someone actually didn't catch the lameness of the post.

I think the explanation for "defund the police" is simpler... they just see the bad stuff cops do on the news, but haven't ever actually needed the cops personally (and few of their friends have too), primarily due to their affluence. There are exceptions, obviously.

Of the people who have obtained a restraining order, I wonder what percentage want to defund the police.

Can that be done without disabling JIT for the rest of us? My app would benefit greatly from JIT compilation, and it's always been a bummer that it can't realize its full performance potential on iOS.

Isn't this more of a problem of Google being too permissive about trash browsers on their store than an issue of whether a browser can have its own JIT compiler?

While I agree with that general sentiment, far more than that experienced homelessness over a 20 year period.

They haven't. You can't get a paper into SIGGRAPH that misses relevant existing research.

Various comparisons with plenoxels are in the paper.

> The argument that a cooperative scheduling is doomed to fail is overblown. Apps are already very much cooperative. For proof, run a version of that on your nice preemptive system : [pathological example which creates tons of threads and files]

The example is just too contrived. On a preemptive OS, apps typically hang in ways that don't turn the whole thing cooperative (thread deadlock, infinite loop, etc.). Also, a preemptive system could kill an app if it creates too many threads, files, or uses too much RAM, long before it gets effectively cooperative. Our systems are just more permissive.

> [Sandboxing] comes free once you accept the premises.

and yet

> any app can casually check the ram of another app ^^. This is going to be a hard problem to solve.

So no, sandboxing doesn't come for free.

That said, it's a cool idea and I wish the author success!

The article matches my experience with SwiftUI [1][2]. For example, AFAICT, it's not really possible to write a usable node-graph editor using SwiftUI due to layout and dependency analysis overhead. You have to put the entire node graph inside a Canvas and do your own event handling, which is what we did in [3].

UIKit and AppKit aren't slow though, and Apple has every incentive to make this faster (they wrote SwiftUI's dependency graph in C++ after all, so they do seem to care), which makes me think there is just inherent slowness from the dependency analysis that is required for these sorts of systems (that seems to be what I see on the profiles).

[1] https://audulus.com [2] https://sculptura.app [3] https://github.com/audiokit/flow

Metal is not a standard graphics API. It's a platform-specific Apple thing. I use it and it's pretty nice, but it's not a cross-platform standard.

Is this essentially the "cyclic reference counting" algorithm from the Garbage Collection Handbook [1], Chapter 5, Algorithm 5.5?

[1] https://gchandbook.org

From the paper [1]:

> However, these existing approaches typically face multiple drawbacks which limit their proposed applications, including (i) surface discontinuities

Which cites the MIT inFORM project (3 in the references).

[1] https://www.nature.com/articles/s41467-023-39842-2

From the article:

  const result = comptime square("hello"); // compile time error: type mismatch

ok, cool. But if the error occurs deep in some hierarchy of comptime calls, do you get the same kind of long errors that you do with C++ templates? Does zig have a way of achieving better ergonomics? One nice thing about generics in Rust and Swift is they are constrained by traits/interfaces so you get a concise error at the call site.

I'm using this technique in a compiler [1]. One thing I really like about it is that, unlike pointers, I can reuse the integer indices (`ExprRef` in the article) between arrays. So, for example, I have separate arrays for the AST and computed types, which allows the AST to be immutable. (perhaps the article already mentions this advantage, but I didn't see it in the list of advantages)

[1] https://github.com/audulus/lyte