Comment by ramesh31
1 year ago
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).
https://www.swift.org/documentation/cxx-interop/
1 reply →
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 ...
> i dont perceive it as efficient to force codebase contributors to relearn their ingrained language syntax
That's why it's important that the transformation be reversible and what the gofmt-like code formatters are for.
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.
I think it comes from the folks that aren't really into Apple culture, rather they buy Apple because of UNIX, or want to target iDevices without culture background on the ecosystem.
1 reply →
>"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
Message passing belongs up there with lisp, forth and pure functional programming as paradigms that are worth learning for "the profound enlightenment experience you will have when you finally get it." But I often see that my peers in the profession lack the kind of growth mentality that enables a person to see past the alienness of less algol-y languages.
Quote from "How To Become a Hacker" by Eric S. Raymond: http://www.catb.org/esr/faqs/hacker-howto.html
12 replies →
Java is heavily based in Smalltalk and Objective-C, even if it has a C++ like syntax for mainstream adoption.
https://cs.gmu.edu/~sean/stuff/java-objc.html
Even Java EE was actually a rebooted Objective-C based project done internally at Sun during the OpenSTEP days, aka Distributed Objects Everywhere.
i have learned smalltalk, common lisp, java, python, ruby, perl, php, C, javacript and a few other languages, and i still do not understand the difference between message passing and function invocation. they look the same to me. according to wikipedia the difference is
"In contrast to the traditional technique of calling a program by name, message passing uses an object model to distinguish the general function from the specific implementations. The invoking program sends a message and relies on the object to select and execute the appropriate code."
Method invocation won out mostly because of Java and C++
but according to the wikipedia article java uses message passing.
supposedly the distinction is that i can have a generic method that gets called if a named method can not be found. in smalltalk that's doesNotUnderstand: in ruby it's method_missing. javascript used to have __noSuchMethod__, in php i can overload __call, in pike i do the same with defining a method called `(), and many more.
so are they all using message passing? and then if java is supposed to use message passing and javascript removed __noSuchMethod__ it seems that alone can't be the distinction.
if there is a distinction at all then it look more like an implementation detail that does not actually affect what kind of code you can write, and more importantly, based on that it is not at all clear that method invocation won out.
9 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'.