Mojo 1.0

“Lowering the barrier to programming AI applications”

Why? If AI has taught me anything, it’s that lowering the barrier doesn’t make anything better. Do we need more of these applications?

I donnow. Lattner’s track record is kinda wonky. Yes, he does academically very interesting and even cutting-edge stuff, but on a practical level, Swift *still* feels like an academic experiment that still falls short of what made Obj C so developer friendly. It feels clever, vs thoughtful.

So is this just another academic exercise?

@Octothorpe I’ve not used Mojo, but my impression is that it’s more pragmatic and fixes a bunch of the things that he found to be mistakes in Swift.

@Octothorpe, could you give some details? I understand this is how you feel, but why?

-- Please, my question is meant with respect. And no, let's agree to leave SwiftUI out of things.

-- "...academic experiment..." "...Obj C [almost left the space out] so developer friendly...". It's this that leave me hoping you could explain. I find Swift (versus ObjC) more concise, flexible, and anymore, having a (slightly) more broad reach than ObjC.

As for Lattner... I have no real judgement, other than to say his professional accomplishments FAR exceed anything I'll ever do. I might add IMHO he (a) did the right thing with Swift (again, not SwiftUI - ws he part of that?) by making it Open Source and (b) oddly, his name doesn't come up much in negative ways regards to Apple. Maybe because he left before everything changed with [take your pick here from COVID, Liquid Glass, Butterfly Keyboards, profits from services, etc.] what seems to be a group conception of how Apple is today.

Maybe you already answered? Swift feels clever to you? ObjC is thoughtful? Okay. I'll cut my wordy comment short in the hope of it not coming across as thoughtful. Call it a "Swift" like comment. Peace!

> I find Swift (versus ObjC) more concise, flexible, and anymore, having a (slightly) more broad reach than ObjC.

Is this a joke?
ObjC is way more flexible. It’s dynamic. You can do all kinds of cool hacky things with it like swizzles. How is Swift with its 100 keywords and strict concurrency rules more flexible? I’ve swizzled my way out of dozens of bugs in Apple’s frameworks with Objective-C.

Did you mean to say:
“Swift doesn’t have square brackets so it looks more like the first programming language I learned.”

@Dave Lots of things are more concise in Swift, but some things are way more verbose. There can be a lot of ceremony around types and concurrency, where sometimes you have to spend a huge amount of effort convincing the compiler that what you are doing is correct. It prevents you from doing lots of bad stuff but can also get in the way of doing various reasonable things, too, e.g. the way deprecated APIs are handled.

@ObjC4Life, @Michael_Tsai, great replies. Thanks. Much more detailed than the comment I replied to. And, yeah... it also shows *my* comment was pretty weak.

First, this was certainly not a joke. (It probably was merely a weak attempt to raise the level of comments from blind Apple-bashing to something more constructive. And while one complaint I have about ObjC isn't the square brackets - I reserve that style of complaint to ObjC requiring a separate files for a header and the actual code for each method - I'll just say that (a) the first language I learned was COBOL-74 followed by Assembler (sorry, it was a mainframe where I received my BSCS and so am not sure the exact flavor. Both were before I blew through that Basic class we all had to take.

@ObjC4Life... my turn to learn something today. Swizzling... keep in mind I know "just enough" to be dangerous... what is a good business case for using it on a totally new project/app?

@Michael_Tsai... are you confusing "compiler" with "Xcode builds"? By that I mean I've found that Xcode builds - particularly starting with Xcode 26 but it's even worse in 27 betas - seem to get more noisy every dot-release. I see no less than 2 reasons for this on my end, and maybe yours'. First is the migration to Apple Silicon, and to a smaller degree for now, AI, whatever it may stand for. Second (for me) is the now eight(/) year old deprivation of GLKit. I really have no clue how, much less when, Apple can seriously shut down OpenGL. Sure, they can stop supporting it. But to shut it off? Apple may as well say their iPhones will no longer support 3G cellular. Maybe they can increase the odds of it happening while making it hard on developers, but it's not pragmatically likely to happen.

@Dave I guess the most famous use of swizzling is in implementing Core Data. I mostly use it for working around bugs in Apple’s frameworks. No, I’m definitely talking about the Swift compiler rather than Xcode’s build system.

> @Dave I guess the most famous use of swizzling is in implementing Core Data.

Also KVO: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueObserving/Articles/KVOImplementation.html

> what is a good business case for using it on a totally new project/app?

You don't go into a new project with swizzling in mind. Swizzling finds you. You use it when you need it when there are no other reasonable options available.

I thought this might be good for Python programs that are slow in parts. Right now my strategy for dealing with too-slow Python programs is to ask Claude if there’s anything that can be done to make them faster, or if it’s best to rewrite the slow parts in Rust. (Python is frequently a good choice because there’s a great library that’s written in it.)

But then after reading the website, apparently this is much more interesting, even if it has a bunch of use cases that I’m not poised to take advantage of…

Quoth Manx:

Do we need more [AI] applications?

Without getting into a long argument about what constitutes “need”, this seems like the sort of thing you’d want to write, say, tobi/qmd in. If you’re in the Apple ecosystem you can probably just use Apple’s own frameworks and have them abstract over the differences in the different chips’ Neural Engines that they provide, but this appears to be much more hardware-agnostic.