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

Bringing Objective-C to the Amiga

heap.zone

Post reply on HN
Print view View original

71–80 of 113 posts

Re: Bringing Objective-C to the Amiga

#71

Post by saagarjha »

rimliu wrote: post #43
jmpt wrote: post #35

Earlier quoted context omitted.

No, and if you do, then I suggest you visit a doctor. Rant: Objective-C is a wonderful language, once you learn it properly. There's a lot of Swift fanboiism (is that a word?) and a lot of Objective-C hate. I have an opinion on why. The vast majority of people that used Objective-C were drawn to the success of iOS. They were developers, used to languages like Javascript, Java or C++. Coming to Objective-C, their imme…

Not sure if you are that bad at Swift of that good at trolling.

Please don't do this. It really drives down the quality of conversation if you engage in ad hominem attacks of the poster. This is especially true in this case because one of the arguments brought up was "rabid fanboyism", which your comment clearly isn't helping disprove.

Re: Bringing Objective-C to the Amiga

#72

Post by iainmerrick »

cmsj wrote: post #57
iainmerrick wrote: post #49

Earlier quoted context omitted.

Not me. Objective-C is lovely. For me the addition of Automated Reference Counting was key. That took a while bunch of tedious but essential boilerplate out of the language. Before ARC, Obj-C was a weird but interesting language that I didn’t want to use. With ARC it all came together into a nice expressive high-level language with raw C power available when you need it.

Totally agree. ARC is excellent and almost always completely transparent. When you're doing something unusual (like storing a pointer to an ObjC object in a C struct or something), there are very simple compiler hints that keep everything happy. It's so much nicer than all the faff of manual retain/release before (and probably nicer than ObjC garbage collection, but I started ObjC after that was already discouraged,…

Come to think of it, garbage collection was an obvious “me too!” feature to catch up with Java and C#, but proved misguided because it didn’t fit well with Objective-C.

ARC was less obvious, but quickly proved to be a much better approach (edit to add: for the typical use cases of Obj-C )

It makes me wonder whether Swift’s vtables and generics are just “me too!” features, this time chasing after C++ fans... Maybe not a great idea, as they’ve also picked up some of the bad stuff like exploding compile times.

Re: Bringing Objective-C to the Amiga

#73

Post by LeoNatan25 »

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.

"Never getting runtime errors" is as far fetched as it can be. Consider Xcode suggesting developers use force unwrap ("!"), that leads to many more crashes with unexperienced developers than the ObjC message to nil paradigm.

Subjectively, I have seen much more crashes in third-party software written in Swift than in ObjC (usually unwrapping or casting incorrectly), including in Apple's software. I cannot say if this is down to more inexperienced developers, less time allotted to experienced developers or a worse development model. I'd say a combination of the three.

Re: Bringing Objective-C to the Amiga

#74

Post by LeoNatan25 »

mpweiher wrote: post #42
LeoNatan25 wrote: post #22

Earlier quoted context omitted.

Those are actually temporary problems. Once ABI stability is implemented, those DLLs will not be needed. The compiler is obviously a WIP and will take years to become more mature and optimized. Likewise for C++ interop. There are fundamental issues with Swift, but those are not them.

Compile times are not a temporary problem, they are fundamental. Yes, they can fix some of the more egregious specific problems, but the model they have chosen is inherently expensive to compile as it leans so much on the compiler. And they no longer have Mr. Moore to bail them out by mere passage of time. In fact, last I checked the compiler has actually gotten slower, overall, in recent versions.

Could you provide a documentation on the compiler model of Swift, and why it would be slower? How can that model be compared to clang's c++ compiler model?

Re: Bringing Objective-C to the Amiga

#75

Post by LeoNatan25 »

saagarjha wrote: post #61
LeoNatan25 wrote: post #41

Earlier quoted context omitted.

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

Yes, that's what I meant, some groundwork in the compiler internals. As I said, I could be misremembering.

That's an interesting thread, thanks!

Re: Bringing Objective-C to the Amiga

#76

Post by saagarjha »

jmpt wrote: post #35
blackrock wrote: post #3

Does anyone else look at Objective-C code, and just want to puke?

No, and if you do, then I suggest you visit a doctor. Rant: Objective-C is a wonderful language, once you learn it properly. There's a lot of Swift fanboiism (is that a word?) and a lot of Objective-C hate. I have an opinion on why. The vast majority of people that used Objective-C were drawn to the success of iOS. They were developers, used to languages like Javascript, Java or C++. Coming to Objective-C, their imme…

> Objective-C is a wonderful language

I agree with you there

> In my opinion, Swift is not a great language. I would even say that it's not good. It's OK.

That's where I'll have to disagree. I really think Swift is a great language, though it's great in a different way than Objective-C is (though, who knows? Maybe one day it will gain enough reflection facilities to match Objective-C).

> The vast majority of people that used Objective-C were drawn to the success of iOS. They were developers, used to languages like Javascript, Java or C++. Coming to Objective-C, their immediate reaction was "WUTT??? Brackets!" Instead of properly learning the idioms, they fought the language on a daily basis and cursed Apple for forcing them to use a language unlike the one they were used to, in order to jump on the iOS bandwagon. These people, once Swift was released, jumped boat immediately because they never really understood Objective-C and Swift is familiar.

I used to be a Java programmer, and I started iOS development when Swift came out because it looked familiar. Sure, at first I really thought Objective-C was ugly and outdated, but once I really got its design I really came to enjoy it. I'm not saying that it's perfect, or that it does everything right, but there is a certain charm in its model.

> Another group of people actively dislike Swift, and really enjoy Objective-C. These are considered dinosaurs and have to either hide their opinion or face hiring difficulties, or even dismissal from companies where they are currently employed.

Sure, to each their own, but I really think that a lot of these developers just haven't spent enough time with Swift to really get its benefits. It's the same issue that you've mentioned with Swift developers, but in reverse.

> messaging to nil is a FEATURE

The Swift language designers hear you; that's why there's the optional chaining operator.

> In Objective-C you can drop to C at any given time and have access to all the insanely fast libs. You can also write such insanely fast code yourself.

You can do both in Swift.

> Complex as in C++ complex, but without the speed.

Swift is complex, and it's still a bit slower than C++ for certain things, but this doesn't mean this won't always be the case.

> Have something you wrote 2 years ago? Good luck with that.

Swift is still a new language, and it's in active development. However, you do have the guarantee that your code from today will continue to compile in the future.

> Swift is safe and everything. Right. Except developers with deadlines will just ! all the optionals when they get in the way.

I don't think you quite understand the safety that Swift offers. In Swift, an optional unwrap is designed to deterministically fail. The same is not true in the C family of languages, where it would be undefined behavior.

> Now, Swift does have some cool things, but so could a new version of Objective-C

There are some things that would be rather difficult to shoehorn into Objective-C at this point, even assuming that Apple is interested in adding these in. For example, Swift's generic functionality is far ahead of what Objective-C offers.

Re: Bringing Objective-C to the Amiga

#77

Post by mpweiher »

saagarjha wrote: post #67
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…

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

> drop a bunch of autoreleases

And add a bunch of allocs, which I find less useful because they don't really communicate intent, whereas the autoreleases usually do. Also, in my code-base, autoreleases are less than 0.5% of the total code, and that includes a lot of legacy code.

In fact, after creating a macro for creating class-side convenience creation methods along with initializers in one go, I could probably drop the use to nearly zero. (The convenience creation methods are always +fooXYZ { return [[[self alloc] initXYZ] autorelease]; } so very automatable).

> undefined behavior

Yes, that's the excuse. It's a bad excuse.

> focusing on performance

Well, performance is my specialty. It also has the advantage of more likely giving you actual data, rather than vague feelings.

> that one time you double free and SIGSEGV

I've not found ARC code to crash less, and if you remember the article, it is about code that cannot possible crash actually crashing due to ARC.

Re: Bringing Objective-C to the Amiga

#78

Post by saagarjha »

mpweiher wrote: post #77
saagarjha wrote: post #67

Earlier quoted context omitted.

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

> drop a bunch of autoreleases And add a bunch of allocs, which I find less useful because they don't really communicate intent, whereas the autoreleases usually do. Also, in my code-base, autoreleases are less than 0.5% of the total code, and that includes a lot of legacy code. In fact, after creating a macro for creating class-side convenience creation methods along with initializers in one go, I could probably dro…

> Yes, that's the excuse. It's a bad excuse.

I'm amazed that you find this to be a bad excuse, since it's what all optimizing compilers rely on to produce performant code.

> I've not found ARC code to crash less, and if you remember the article, it is about code that cannot possible crash actually crashing due to ARC.

The code crashes because you violated an invariant at some point of program execution. The way the C-style languages work, it's legal to crash (or not) at a place that isn't necessarily the place where the undefined behavior happens (interestingly, not only does this have to be after: it can also happen before the buggy code executes, due to reordering, pipelining and such). This is one of the guarantees you get "for free" by using a safer language such as Swift.

Re: Bringing Objective-C to the Amiga

#79

Post by mpweiher »

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…

> [GC not catching on]

Well, GC was much harder to adopt, as it wasn't incremental. Either your code was GC or not. All of it.

> If it had been popular, Apple would have kept it.

Weeelll...I think the bigger problem with GC was that it didn't work; they never could get all the bugs out. Including the performance issues, but more significantly potentially huge leaks. Well, technically that's also performance.

I also very much liked the idea of ARC, it looked exactly like what I had lobbied for, and it certainly was much better than GC, if more limited (cycles). And then I tried it and noticed (a) for my idiomatic and highly automated use of MRC, the benefits were between minimal and zero and (b) the drawbacks, particularly the stricter compiler errors, were a major PITA, and unnecessarily so.

This becomes noticeable when you write TDD code in an exploratory fashion, because with the errors you have to keep 3 sites in your code up-to-date. That becomes old really fast, but I guess most people don't really do TDD (their loss!), so it's not something that's a major pain point in the community.

Incidentally, someone once mailed me that they had switched some code back from ARC to MRC (partly due to what I'd written), and contrary to their expectations and previous assumptions could confirm that the difference was, in fact, negligible.

> [Swift like ARC when it's more like GC]

That's a good observation. Of course, Swift is a much more dramatic change than even GC ever was, and interestingly the community seems to be much more radical/rabid than Apple. For example, in the community it seems de-rigeur that you must use immutable structs whenever possible, whereas Apple's Swift book gives a few conditions where you might consider structs and then says you should use classes for everything else.

Post reply on HN