Comment by itslennysfault
1 year ago
So, this is why the abomination that is Obj-C is/was used for iPhone/Mac apps. I can't overstate how much I hate Obj-C. I'm so sooo happy Swift has pretty much entirely taken over.
Side note... I feel similarly about the Java to Kotlin transition. Sooo much better. Although, I don't hate Java NEARLY as much as Obj-C.
I'm back in Objective-C now for a large mixed codebase for a client and enjoying it. It was my first compiled language starting in 2002 so I've got about equal time with only it as I do with Swift alongside. And I'm spending more time these days in other projects (microcontrollers, mostly) using C so it's a breath of fresh air. I'm finding it generally faster than Swift in Xcode, which is a bonus.
I too am back in Objective-C and being away from it for a long while and I'm also enjoying it. For the most part, I really like Objective-C. I think it's a very pragmatic language. My current project is macOS, but the vast majority of my prior work with Xcode and ObjC was with iOS development.
To each their own. I'm convinced it's just a visceral reaction to the square bracket syntax. Obj-C remains my favorite language of all time (although I haven't written it in years). Having a high level language that allows you to seamlessly drop into C felt like magic.
I'm using Obj-C for the first time in years for a side project. I'm working on making a Wayland backend for cocotron on Linux.
It is magical the way I can just use the C libraries with all the dynamic goodness Obj-C.
There's even more magic: You can even use/include/write/mix and match ObjC with C++, within the same source file - C++ classes calling ObjC methods, ObjC methods instantiating C++ classes, it's all there. No other language comes close to this kind of interop with C++ and it is one feature that Swift will never be able to match (albeit intentionally).
2 replies →
Someone really ought to do an alternative "skin" for Objective-C. That is, define some reversible transformation that can be applied to any Objective-C program that only changes the surface-level details but otherwise results in mapping the exact same program into the later stages of the compiler (and the section of programmers' mental pipeline that comes after the part where their eyeballs and sense of taste are concerned). It's important that the reversible part be adhered to.
It's really kind of a bummer that we don't have well-known examples of "skinnable" programming languages already. The closest we get are the ones that let you choose your set of keywords for different locales in case you don't want to work with an English-based PL and those block based languages that let you manipulate them as blocks or edit the textual form. I firmly believe that PL skinning would really benefit so many otherwise worthwhile languages that get short-shrift because of negative reactions to the surface-level details. I'm referring in particular languages like those in the Pascal family. (You could also conceive of e.g. a skin for Golang that doesn't have leading caps be the determiner for whether a function is public or not. There are lots of applications for this, and the variations are a non-issue when you have an ecosystem with strong norms about applying a code formatter (like gofmt), which can dictate the format of the canonical on-disk representation.)
Apple did implement this around the Mac OS X transition (I guess, probably Steve Naroff did it?) but it was not pursued, in favor Java bindings (which funnily enough are back in fashion with swift-java).
surely after 20 years this already exists , someone posted a header the other day that makes c syntax python like , macros are enough to accomplish what youre describing? i dont perceive it as efficient to force codebase contributors to relearn their ingrained language syntax , possibly more efficient for those having newly learned a language tho ...
1 reply →
The Four Stages of Objective-Smalltalk
https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...
Its first two stages are just that, but it has moved beyond, for good reasons.
For personal use, the only issue I take with Obj-C is how it's considerably less "batteries included" relative to Swift.
For collaborative projects on the other hand, it can become a handful to maintain if everybody contributing isn't staying on top of hygiene with null checks, type checks, etc. Swift helps to keep all of that under control.
Interesting, I guess that part was missed on me since I only really ever used it for iPhone apps and never really had a need to use C directly.
Also, you're 100% right. The square brackets are what immediately repulsed me and continued to befuddle me even after years of experience with it. Also, everything just feels "backwards" to me if that makes any sense. Coming from Java/C#/JavaScript everything just seemed unintuitive to me at all times. Also, I think this was heavily compounded by using xCode which (at the time) was incredibly laggy. So, I'd mess up the Obj-C syntax and the IDE wouldn't tell me for what felt like forever. Often I'd make a change and hit "play" before the syntax highlighting caught up and that always felt infuriating.
I last used xCode about 4 years ago and it was still an issue then (even with swift).
I've been an Mac and iOS engineer for over a decade, and none of this makes any sense to me. Everything you listed (besides the brackets) is worse in Swift than in Objective-C (Swift has real problems with live error checking in Xcode in particular, due to the additional compilation complexity since it's a significantly more complicated language).
I've observed some folks have a visceral reaction to having to use Xcode, I don't really understand it myself. I can understand being annoyed at having to use a specific IDE to write iOS and Mac apps, e.g., it's harder to bring your own text editor like you usually can, it's going to make your life a lot harder if you try to to avoid using Xcode. But comparing Xcode to any IDEs like the JetBrains IDEs I've used (mainly the discontinued AppCode), Android Studio (also JetBrains under the hood), or other similarly complex development environments like Unreal or Unity, I don't see any of these as a clear winner. Personally I'd prefer using Xcode to any of those. I suspect this comes down to just whether you like native Mac apps or not, Xcode is a native Mac app and if you like that aesthetic than you'll like Xcode. I suspect most of the dislike for Xcode is really just folks who dislike the Mac platform (e.g., the UI toolkit) overall.
2 replies →
>"Also, everything just feels "backwards" to me if that makes any sense."
Because it is. Obj-C comes from the Smalltalk lineage by way of Alan Kay, using message passing [0] versus method invocation. It's a subtle difference with huge implications to how you design systems. Method invocation won out mostly because of Java and C++, but there was a time it wasn't clear which was the better OO paradigm.
[0] https://en.m.wikipedia.org/wiki/Message_passing
24 replies →
The square brackets can be a huge impediment when first working on Obj-C (it was to me). I found that after some period of time to acclimate they eventually felt 'normal'.
Metal is implemented in a mix of Objective-C (CPU) and C++ (Metal Shaders), Swift only has bindings.
Maybe one it they will rewrite the Objective-C, who knows.
Kotlin transition is a Google thing, outside Android barely anyone notices that it exists.
“Kotlin transition is a Google thing, outside Android barely anyone notices that it exists.”
That’s not true.
It certainly is, one just needs to check any programming language market share analysis that omits Android deployments.
Kotlin hardly does more than 10% of JVM workloads, and it isn't as if any JVM vendor is replacing Java with Kotlin on their JVM implementation.
Besides Google with ART, which is anyway not a JVM proper, not fully TCK compliant to start with.
4 replies →
Did you start with Swift or Objective-C?
I started with Objective-C and loved it but I imagine that wouldn’t have been the case if I started with Swift.
Same. I realize that Objective-C is dated by contemporary standards. But when I first learned it 20-ish years ago it felt like a superpower. I bet it was even more impressive when it first appeared another 20 years further back.
I think that one of the tragedies of older programming languages is that they survive long enough for people to forget the technical - and technological - constraints that influenced their design. Swift is great, but there are reasons why there weren't any Swift-like languages being developed in or around 1984.
Similar feelings about Java. It is definitely not my favorite programming language. (I suppose Kotlin isn't either, but it's in the top n.) But it's hard for me to actually hate it. Java walked so that Kotlin could run.
I started the iOS development with Objective-C and hated the language. gp's comment is pretty much my feeling as well. I wonder if I'd enjoy Swift so much if it wasn't in contrast to how utterly horrible Objective-C was. These days I still need to revisit legacy Obj-C codebases occasionally or make Obj-C wrappers to interface with C++ code and every time it feels like diving into a cesspit.
I was first introduced to Objective-C in 2010 when I worked on my first iPhone app. I've come back to it a half dozen times over the past 15 years since then and always hate it. I only discovered swift a few years ago (when I had to do some iPhone stuff) and was so happy to not need to use Obj-C
I did a few things in Obj-C and I only regretted the memory handling stuff. I really liked the performance, reflexibility capabilities (reverse engineering classes is almost trivial) and smalltalk like style. I will not choose it for any project but it gives me the taste that there were more options around C/C++
There has been plenty of options back in the day, it was guaranteed that C and C++ would take over everything as they did during the late 1990's.
Even the Object Pascal to C++ transition at Apple was mostly caused by increased UNIX adoption, and Apple programmers wanting to offer similar experiences, thus MPW was born.
Same on other platforms, until C and C++ eventually won everywhere, at least until several new kids decided to challenge them in various fronts.
One that you seldom see nowadays, outside games, is pure GUI frameworks using C or C++.