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

Why Objective-C

inessential.com

Post reply on HN
Print view View original

111–120 of 160 posts

Re: Why Objective-C

#111

Post by andrekandre »

socialdemocrat wrote: post #21
netbioserror wrote: post #9

I bounced off of Objective-C not because of its message-passing OO. That was the actual cool part. I bounced off because of the insane amount of boilerplate prototyping and headers required to use it. I think every OO language should be using Smalltalk's message-passing style rather than holding hard references, and Objective-C is a great model. But discard the rest.

Apple should have made a modern Smalltalk on top of the Objective-C object model as a replacement for Objective-C instead of Swift. I want to love Swift, but the funny thing is that as they solve more problem with Swift they also add so much complexity that you wonder if all the problems they solved just added new problems.

i really really like swift actually, it lets me express things that are harder in many languages...

that being said, i also feel this as well... idk i feel like swift went too hard in the static direction which makes a lot of things harder than they should be such as hot-loading while developing etc

Re: Why Objective-C

#112

Post by favorited »

waynecochran wrote: post #72
frou_dh wrote: post #38

Earlier quoted context omitted.

Obj-C++ was used for some hall-of-fame OS X apps, e.g. TextMate

I have my suspicion that it is still used heavily inside Apple. It especially caters to programmers that are control freaks like me -- you are a little closer to the metal (pun intended).

It's not difficult to determine where different languages are used – you can run `symbols -noDemangling BINARY | grep _Z`, where BINARY is a path to any binary, and see how many symbols use Itanium C++ name mangling. You'll see it sprinkled in enough places to get an idea of which parts of the system use it more than others.

Of course, parts of the Objective-C runtime are written in Objective-C++, so someone more pedantic than I might claim that fact alone counts as it being "used heavily."

Re: Why Objective-C

#113

Post by favorited »

kccqzy wrote: post #67

I do not get this argument at all. A long time ago I ported a simple sudoku solver to Objective-C by using the foundation classes, like NSMutableArray. It was terribly slow. All those messaging sending just to do what should have been a single instruction (or less!) That’s when I realized that if you want speed in an Objective-C app, you really are going to reach for the C subset. The objective part is really good fo…

One of the great things about Objective-C, as a direct superset of C, is that you can identify the slow parts of your app and just implement them in C, inline with the rest of your code. You don't even need to move it outside of your class's @implementation.

Re: Why Objective-C

#114

Post by zadikian »

coliveira wrote: post #58
seanalltogether wrote: post #7

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.

If you use Objective-C objects, operations on null pointers are just a no-op, so there is not such thing as chasing exceptions.

So you silently ignore something being null when you don't expect it to be? That sounds even worse.

Re: Why Objective-C

#115

Post by zadikian »

seanalltogether wrote: post #7

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.

When Swift 1 came out, I was migrating an ObjC app that used CoreData to it and found a bug where nullable cols in the CoreData schema got non-nullable properties in the autogenerated Swift. Found out when I had a non-nullable property actually get set to null at runtime, and the compiler wouldn't let me add a check that it's null.

Re: Why Objective-C

#117

Post by MBCook »

mikehall314 wrote: post #64
samesimilar wrote: post #54

Earlier quoted context omitted.

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.

I think originally Apple was using SproutCore, which had similar aspirations to produce "desktop quality" web apps, and was one of the early frameworks to implement things like two-way data binding. This was back when iCloud was called MobileMe. SproutCore 2.0 became Ember.js 1.0, but I don't know if Apple are still using it.

Oh wow I didn’t know that’s where Ember came from.

Re: Why Objective-C

#118

Post by raincole »

estebank wrote: post #46
nicoburns wrote: post #39

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.

Examples?

Re: Why Objective-C

#119

Post by hackyhacky »

jcelerier wrote: post #106
coliveira wrote: post #59

Earlier quoted context omitted.

C++ is trying to make C easier to use for 40 years, and it's still not there. So I wouldn't call that easier.

how would you write something like #include #include #include int main(int argc, char** argv) { using namespace std::literals; std::string foo = "foo:"; foo += argv[0]; std::map m{ {foo, 123} , {"count: "s + std::to_string(argc), 456} }; std::println("{}", m); } in C

Sure, there are nice parts of C++. And there are also brain-dead parts that add needless complexity such as:

* rvalue references

* the difference between auto, decltype, typeof

* unreadable template monstrosities

* various different flavors of "smart" pointer

* the continued existence of footguns relating to UB, dangling pointers, unexpected temporary lifetimes, etc

* total absence of a build system or package management

* legacy APIs that still take raw pointers

* concepts, a half-assed attempt at generic constraints

Post reply on HN