Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Subjective Charms of Objective-C

wired.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: The Subjective Charms of Objective-C

#51

Post by pjmlp »

cosmic_cheese wrote: post #29
jimbokun wrote: post #17

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 receiv…

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 wher…

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.

Re: The Subjective Charms of Objective-C

#52

Post by msarnoff »

The language is one thing, but the Objective-C runtime is brilliant. Read about the implementations of key-value-coding, key-value-observing, and bindings to get a sense of the bonkers things that have been done with it.

And ARC (automatic reference counting) blew my mind when it was first released. Rust was a blip on the radar, so the idea of automatic memory management, handled at compile time, without GC, was amazing.

Re: The Subjective Charms of Objective-C

#53

Post by krackers »

cosmic_cheese wrote: post #29
jimbokun wrote: post #17

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 receiv…

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 wher…

>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?

Re: The Subjective Charms of Objective-C

#54

Post by cosmic_cheese »

pjmlp wrote: post #51
cosmic_cheese wrote: post #29

Earlier quoted context omitted.

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 wher…

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…

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.

Re: The Subjective Charms of Objective-C

#55

Post by pjmlp »

cosmic_cheese wrote: post #54
pjmlp wrote: post #51

Earlier quoted context omitted.

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…

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.

Re: The Subjective Charms of Objective-C

#56

Post by pjmlp »

krackers wrote: post #53
cosmic_cheese wrote: post #29

Earlier quoted context omitted.

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 wher…

>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.

Post reply on HN