Bringing Objective-C to the Amiga • Hacker News Board

Re: Bringing Objective-C to the Amiga

#61

Post by saagarjha » Mon, Apr 23, 2018, 8:30 AM UTC

LeoNatan25 wrote: post #41

saagarjha wrote: post #30

Earlier quoted context omitted.

I'm much more hopeful for ABI stability than C++ interoperatability. I think will take a long time before we'll be able to seamlessly work with C++ code as we do currently with say Objective-C or C.

Weren’t some steps taken to start working on preliminary support, or at least building blocks? I might be mistaken.

I've been mostly away from the Swift Forums for the last couple weeks, so if they've done something recently I probably missed it. Otherwise, though, AFAIK there's very few user-facing features that we can take advantage of right now. I do know that this is something that is on the roadmap, but so far the only changes related to this feature would be confined to the internals of the compiler, if at all. Here's a relatively recent thread by Doug Gregor where he outlines some of the challenges necessary to surmount if this feature is to ever land: https://forums.swift.org/t/c-objective-c-interop/9989

Re: Bringing Objective-C to the Amiga

#62

Post by saagarjha » Mon, Apr 23, 2018, 8:32 AM UTC

aplummer wrote: post #60

LeoNatan25 wrote: post #40

Earlier quoted context omitted.

Yes, but it’s not officially “condoned”, so it feels “out of place”. This is very individual, of course, but I don’t like bending the system to get patterns that are not “natively” supported. In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies. You couldn’t even load a nib without the ObjC runtime. Not even reflection. It’s telling what their priorities were with that…

Also I agree you can tell safety was the number one priority. However the positive is basically never getting runtime errors, except when interfacing with IB or obj-c even when people are programming in a hurry, which is nice for me.

> However the positive is basically never getting runtime errors

I don't quite think this is the "safety" that Swift aims for: rather, it prefers safety in the sense of failing fast and failing reliably if something goes wrong. Unwrapping nil and out of bounds array subscripting fall into this category of behavior.

Re: Bringing Objective-C to the Amiga

#63

Post by saagarjha » Mon, Apr 23, 2018, 8:34 AM UTC

LeoNatan25 wrote: post #40

saagarjha wrote: post #26

Earlier quoted context omitted.

There's nothing stopping you from writing dynamic Swift code or functional programming in Objective-C.

Yes, but it’s not officially “condoned”, so it feels “out of place”. This is very individual, of course, but I don’t like bending the system to get patterns that are not “natively” supported. In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies. You couldn’t even load a nib without the ObjC runtime. Not even reflection. It’s telling what their priorities were with that…

> In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies

In pure Swift, that is. These are all possible if you reach into the Objective-C runtime, as I'm sure you know well. Overall, though, I do agree with you: I'm unsatisfied with the current reflection API in Swift and I really think that this is something that the core team should focus on some time.

Re: Bringing Objective-C to the Amiga

#64

Post by mpweiher » Mon, Apr 23, 2018, 8:39 AM UTC

rimliu wrote: post #44

checker659 wrote: post #39

Earlier quoted context omitted.

I still use manual reference counting :) In John Oliver’s voice : “Fuck you Apple, fuck you.”

This kind of bragging sound just like "I don't read books".

To you, maybe. But that says more about you than the OP.

The tangible benefits of ARC are at best marginal, and there are downsides, which some can reasonably find more significant, and thus ARC not worthwhile.

First off, "manual" reference counting is misnamed. It is at the very least "semi-automatic" and highly automatable.

So how does a property declaration look with "MRC" vs. ARC?

    @property (nonatomic,strong) NSString *str;

vs.

    @property (nonatomic,strong) NSString *str;

Can you tell which is which?

So how about use?

    someObject.str = @"Hello World!";

vs.

    someObject.str = @"Hello World!";

Can you tell which is which? In use, ARC and MRC are mostly indistinguishable, as long as you use accessors/properties for all instance variable access. You do that, right? Right?

OK, so there is automatic dealloc. That's a nice convenience, but actually not intrinsically tied to ARC. How do I know? I implemented automatic dealloc for a project once. Didn't use it much after because the small effort spent on dealloc just didn't seem worth it, especially as you also had other boilerplate to implement, the coders, isEqual and hash.

The one biggie was weak, which was previously handled via non-retained references, so no automatic nilling. This could actually be a pain from time to time, but really not that huge a deal and it was also never really intrinsic to ARC, as shown by Apple recently adding weak for non-ARC code.

So those are/were the upsides. Not really that much.

Among the downsides is a performance penalty that could be both significant and somewhat unpredictable, on the order of 50%-100% slower in realistic scenarios (in extreme cases it can be an order of magnitude or more). You could also get unexpected crashes because of retain/releases added in unexpected places. We had a crash in a method that did nothing but return 0;

http://blog.metaobject.com/2014/06/compiler-writers-gone-wil...

However, for me the biggest pain point was the semantic changes in ARCed-C: what used to be warnings about an unknown message are now hard compile errors, and that seriously cramps Objective-C's style as a quick-turnaround exploratory language.

And yes, I have worked with/built both significant ARC and non-ARC codebases.

What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it and all its numerous warts (which were beautiful) wholeheartedly, and buy into all the BS.

Then when GC was dropped and replaced by ARC: same thing. Did anyone say GC? We meant beautiful shiny ARC, you ignorant luddite. And it quickly became an incontrovertible truth that ARC was faster than "MRC", despite the fact that this wasn't so. And when people asked about it, mentioning they had measured significant slowdowns, they were quickly attacked and everything questioned, because everybody "knew" the "truth". Until a nice gentleman from Apple chimed in an confirmed. Oops.

So please ratchet down the fanboy setting. Technologies have upsides and downsides. Reasonable people can differ on how they weigh the upsides and the downsides.

And of course we are seeing the same, just magnified by an extraordinary amount, with Swift.

Re: Bringing Objective-C to the Amiga

#65

Post by mpweiher » Mon, Apr 23, 2018, 8:43 AM UTC

aplummer wrote: post #60

LeoNatan25 wrote: post #40

Earlier quoted context omitted.

Yes, but it’s not officially “condoned”, so it feels “out of place”. This is very individual, of course, but I don’t like bending the system to get patterns that are not “natively” supported. In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies. You couldn’t even load a nib without the ObjC runtime. Not even reflection. It’s telling what their priorities were with that…

Also I agree you can tell safety was the number one priority. However the positive is basically never getting runtime errors, except when interfacing with IB or obj-c even when people are programming in a hurry, which is nice for me.

Hmm...like making every arithmetic operation a potential crash site?

Re: Bringing Objective-C to the Amiga

#66

Post by iainmerrick » Mon, Apr 23, 2018, 8:55 AM UTC

mpweiher wrote: post #64

rimliu wrote: post #44

Earlier quoted context omitted.

This kind of bragging sound just like "I don't read books".

To you, maybe. But that says more about you than the OP. The tangible benefits of ARC are at best marginal, and there are downsides, which some can reasonably find more significant, and thus ARC not worthwhile. First off, "manual" reference counting is misnamed. It is at the very least "semi-automatic" and highly automatable. So how does a property declaration look with "MRC" vs. ARC? @property (nonatomic,strong) NSS…

What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it

I don’t know how to check this, but that isn’t how I remember it at all.

There was a brief flurry of interest when Apple added GC, but it never caught on. If it had been popular, Apple would have kept it.

Then when ARC arrived, it was genuinely popular, and that’s why it was a lasting success. By automating the exact same retain/release/autorelease protocol that people were already doing by hand, it fit much more neatly into existing Obj-C best practices.

I do partly agree with you, that Swift seems to have some problems that haven’t yet been fully resolved, but Apple are still going full steam ahead with it. It feels more like GC, but Apple are treating it like ARC.

Re: Bringing Objective-C to the Amiga

#67

Post by saagarjha » Mon, Apr 23, 2018, 8:57 AM UTC

mpweiher wrote: post #64

rimliu wrote: post #44

Earlier quoted context omitted.

This kind of bragging sound just like "I don't read books".

To you, maybe. But that says more about you than the OP. The tangible benefits of ARC are at best marginal, and there are downsides, which some can reasonably find more significant, and thus ARC not worthwhile. First off, "manual" reference counting is misnamed. It is at the very least "semi-automatic" and highly automatable. So how does a property declaration look with "MRC" vs. ARC? @property (nonatomic,strong) NSS…

> Can you tell which is which? In use, ARC and MRC are mostly indistinguishable, as long as you use accessors/properties for all instance variable access.

Well, that's the beauty of upgrading to ARC: your declaration syntax doesn't need to change; usually it just means that you can drop a bunch of autoreleases in your codebase.

I read your blog post, where you mention this snippet of code being optimized in an odd way, printing "1 2" in Clang:

  int main() {
    int *p = (int*)malloc(sizeof(int));
    int *q = (int*)realloc(p, sizeof(int));
    *p = 1;
    *q = 2;
    if (p == q)
      printf("%d %d\n", *p, *q);
  }

Of course, when you have odd things like this happen you're reaching down into undefined behavior, and then all bets are off.

Really, I you're just focusing on performance too much and neglecting the fact that ARC isn't there for increasing the performance of your code: it's there so that you can program in a manner that's more safe. Sure, it's easy to manage memory manually, until that one time you double free and SIGSEGV.

Re: Bringing Objective-C to the Amiga

#68

Post by saagarjha » Mon, Apr 23, 2018, 8:58 AM UTC

iainmerrick wrote: post #66

mpweiher wrote: post #64

Earlier quoted context omitted.

To you, maybe. But that says more about you than the OP. The tangible benefits of ARC are at best marginal, and there are downsides, which some can reasonably find more significant, and thus ARC not worthwhile. First off, "manual" reference counting is misnamed. It is at the very least "semi-automatic" and highly automatable. So how does a property declaration look with "MRC" vs. ARC? @property (nonatomic,strong) NSS…

What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it I don’t know how to check this, but that isn’t how I remember it at all. There was a brief flurry of interest when Apple added GC, but it never caught on. If it had been popular, Apple would have kept it. Then when ARC arrived, it was genuinely popular, a…

> Apple are treating it like ARC

That's because Swift uses ARC instead of traditional tracing garbage collection.

Re: Bringing Objective-C to the Amiga

#69

Post by LeoNatan25 » Mon, Apr 23, 2018, 9:02 AM UTC

aplummer wrote: post #56

LeoNatan25 wrote: post #40

Earlier quoted context omitted.

Yes, but it’s not officially “condoned”, so it feels “out of place”. This is very individual, of course, but I don’t like bending the system to get patterns that are not “natively” supported. In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies. You couldn’t even load a nib without the ObjC runtime. Not even reflection. It’s telling what their priorities were with that…

You’ve made some good points though I’ve found the reflection in swift since v2 to be sufficient for my day to day. I think the nib thing is a problem but in reverse, nibs needs to be swift so we can instantiate them with generics, this would be a game changer!

Without reflection, you cannot create a nib system (or any general purpose archiving solution). For Encodable, they used hacks that were tantamount to macros in C, but that requires compile-time knowledge of the class/struct structure. That's not how nibs work.

Re: Bringing Objective-C to the Amiga

#70

Post by iainmerrick » Mon, Apr 23, 2018, 9:02 AM UTC

saagarjha wrote: post #68

iainmerrick wrote: post #66

Earlier quoted context omitted.

What's really troubling about these things (GC, ARC, Swift) is the rabid fanboyism. When GC came out, you were complete idiot and a luddite if you didn't embrace it I don’t know how to check this, but that isn’t how I remember it at all. There was a brief flurry of interest when Apple added GC, but it never caught on. If it had been popular, Apple would have kept it. Then when ARC arrived, it was genuinely popular, a…

> Apple are treating it like ARC That's because Swift uses ARC instead of traditional tracing garbage collection.

No, that’s completely separate.

What I mean is, ignore the specific technologies: Apple is treating Swift like an ideal incremental improvement (like ARC was) whereas it’s really a major change in direction that may or may not prove to be a good idea (like GC was).