51–60 of 160 posts
That's it, I'm pivoting my startup technically and rewriting everything in ObjC! /s
In a previous life, one would select the programming language according how expensive developers were. Nowadays it's the quality that an AI can generate. What a wonderful future we've put together. /s
I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language. (There's a decent argument it encountered it in iOS and macOS too.) [1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy,…
> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting. I think the way to think about it is that with Rust, it's as if all…
* automated exclusivity with value types and value witness tables, classes as arc types (ie Arc>)
* automated interop with C/C++/Obj-C through the clang ast importer
Maybe they could have started with rust and added on what they needed, but why not build a new language at that point where things so fundamental are involved?
Source: I worked in lattners org at the time of swifts inception (on an unrelated backend) but that was the motivation. I also worked on the swift compiler for a little bit some years later on in my career.
I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language. (There's a decent argument it encountered it in iOS and macOS too.) [1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy,…
> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting. I think the way to think about it is that with Rust, it's as if all…
I get that there's a tradeoff. Rust requires you to be way more explicit about what you're intending upfront and that can, in the long term, lead to simpler code -- but there's no dimension (depth-wise or breadth-wise) that I'd call Rust simpler.
Every so often I get weirdly obsessed with Objective-J, which "has the same relationship to JavaScript as Objective-C has to C". It is (was?) an absolutely bonkers project. I think it has more or less died since 280 North was acquired. https://www.cappuccino.dev/learn/objective-j.html
At this point in my career, I can't go back to a language that doesn't have support for Optionals or compiler validation of nullable types. I can sacrifice async or fancy stream apis, but I will never go back to chasing null pointer exceptions on a daily basis.
Obj-C does have a "nonnull" annotation now (apparently added to assist Swift interop). One of the final jigsaw pieces turning it into a really pleasant language.
I recently started writing for macOS in Swift and, holy hell, the debuggability of the windowing toolkits is actually unparalleled. I've never seen something that is this introspectable at runtime, easy to decompile and analyze, intercept and modify, etc. Everything is so modular, with subclassing and delegation patterns everywhere. It seems all because of the Objective-C runtime, as without it you'd end up needing s…
I've found the DX for GTK to be at least tolerable. Not fantastic, but I can at least look at a particular API, guess how the C-based GObject code gets translated by my language bindings of choice, and be correct more often than not. The documentation ranges from serviceable to incomplete, but I can at least find enough discussion online about it to get it to do what I want.
Also, GTK apparently ships with a built-in inspector tool now. Ctrl-Shift-I in basically any GTK app opens it. That alone is extremely useful, and you basically have to do nothing to get it. It's free.
I've never tried Qt. The applications that use it always seem off to me.
As for OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism.
OLE is dead because its use case died. Compound documents as a concept don't really work in the modern era where everything is same-origin or container sandboxed. But COM is still alive and well. It's the glue that holds Windows together - even the Windows desktop shell. All the extension interfaces are just COM. The only difference is that now they started packaging COM objects and interfaces inside of .NET assemblies and calling it "WinRT". But it's the same underlying classes. If you use, say, the Rust windows crate, you're installing a bunch of language bindings built from WinRT metadata that, among other things, call into COM classes that have been there for decades.
Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron.
[0] Petition to rename ActiveX to WebOLE
[1] OK, yes, XAML existed in the Vista era, but that was .NET only, and XAML apps didn't look meaningfully different from ones building their own USER.dll window classes like it's 1993.
At this point in my career, I can't go back to a language that doesn't have support for Optionals or compiler validation of nullable types. I can sacrifice async or fancy stream apis, but I will never go back to chasing null pointer exceptions on a daily basis.
Earlier quoted context omitted.
> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting. I think the way to think about it is that with Rust, it's as if all…
One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.
Every so often I get weirdly obsessed with Objective-J, which "has the same relationship to JavaScript as Objective-C has to C". It is (was?) an absolutely bonkers project. I think it has more or less died since 280 North was acquired. https://www.cappuccino.dev/learn/objective-j.html
Anyone know if this is or ever was the basis for Apple's iCloud web apps on iCloud.com (e.g. Keynote / Pages / Notes etc.)? Those apps are heroic attempts to replicate the desktop app experience in the browser. I'm curious what web framework is underlying it. Side note - if I could install 3rd party apps w/ similar UIs in my iCloud dashboard that would be interesting.