Hacker News Reader

Comment by jimbokun | Hacker News Reader

Objective C was a far more elegant and powerful solution to the problem of extending C to be "object oriented" than C++.

The square brackets made very clear when you were engaging with SmallTalk style message passing semantics. But the language was still a full superset of C, allowing calling any legacy code you wanted. Or using C syntax for performance critical parts.

And for as much criticism as the language received, it was still the perfect fit for the original iPhone. Performance critical parts in C for the constrained hardware resources. But still allowed for rapid iteration on dynamic UIs for applications.

View on HN

The hate Objective-C has received for its syntax is unreal. It’s a minimalistic, easy-to-navigate language, but people assumed Swift would be easier just because it looks more like Java and C#.

Meanwhile, Swift is such a mess that even its own creator said the following in an interview:

“Swift, the original idea was factor complexity (…) massively failed, in my opinion (…) Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff”

https://x.com/krzyzanowskim/status/1812238141496934738

Swift should have been an alternative syntax targetting the same Obj-C runtime IMO.

I lost hope for Swift after seeing a minor holy war about the c-style for loop.

Well arguably he stated the whole thing since Chris wanted it to be one language to rule them all from assembly to javascript. It was that moment I knew Swift is wrong from birth.

Now 10 years later, Apple is stuck with hundreds of engineers trying to improve the language, rewrite some of the API in Swift. And Apps as well. All with very little user benefits. This actually reminds me of Apple without Steve Jobs era.

Imagine if Apple had simply said we are going to use Objective-C for another 10 years on a wait and see approach. I think the decline in Apple's quality is simply because when Apple has too many resources, different teams are all trying to get resources and put something out for credit in Resume Driven development.

The ability to mix languages is really underrated I think. Today you can toss a ball of Objective-C/C, C++, and Swift at clang and it’ll figure it out and spit out a single binary. That’s kinda crazy, and it lets you use whichever makes the most sense for each component of your app and gives you the ability to leverage a staggering number of libraries between the four.

It’s a stark contrast to e.g. Android world where making use of languages/libraries outside of the JVM bubble is technically possible but not necessarily a good idea in many if not most situations due to the caveats involved.

That is by design, of course it doesn't work easily, people keep trying to fit a square peg into a round hole.

From the official NDK documentation.

"The NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps. However, the NDK can be useful for cases in which you need to do one or more of the following:

- Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

- Reuse your own or other developers' C or C++ libraries. "

Anyone that keeps not understanding that point of view naturally run into walls that Android team has no plans to ever change.

Even so, it’s quite limiting and makes it difficult for e.g. non-JVM UI libraries to exist on Android. No other popular platform has this issue.

Mostly because Android was on the forefront that is about time to move from C and C++ for the whole application stack.

Note that you also aren't without issues on Apple platforms if the language doesn't plug into the Objective-C or Swift runtimes in some form.

Likewise on Windows if the language isn't able to talk .NET or COM/WinRT.

>languages/libraries outside of the JVM bubble is technically possible

Isn't Truffle/GraalVM an attempt to bring in more interpreted languages under the JVM?

No, that is a side effect.

Truffle/GraalVM is the evolution of projects like MaximeVM and JikesRVM, of having a meta-circular JVM, with a compiler development toolchain.

Naturally by having a compiler development toolchain, there is also interest on going forward beyond just Java programming language, and see which other languages it can handle.

JVM itself already had a more friendly take on dynamic languages, following the .NET DLR efforts, with invokedynamic on the JVM (Java 7). Which was later also used as mechanism to implement lambdas due to the way as invokedynamic works, it can be faster and less resource hungry than the anonymous class approach many think is used instead.

> But still allowed for rapid iteration on dynamic UIs for applications.

This is the aspect that IMO was most harmed by the transition to Swift - and then later to a much deeper extent by SwiftUI, which makes quickly refactoring UI code very painful.

Reply on news.ycombinator.com