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

101–110 of 113 posts

Re: Bringing Objective-C to the Amiga

#101

Post by saagarjha »

mpweiher wrote: post #85
saagarjha wrote: post #78

Earlier quoted context omitted.

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

> [undefined behavior for optimization] Yes, I am aware that that is the excuse. It still is a terrible excuse. > because you violated an invariant at some point of program execution. Not true. The code in question is a callback, so my code is getting called by Apple code, and ARC dereferences a pointer it has no business de-referencing. May I remind you that the code that crashed due to a segfault was { return 0; }…

> if you think "You have violated something, for which we will give you no diagnostic, and therefore we feel free to crash you at some random other place in the program that has nothing to do with the place where the alleged violation took place, again with no diagnostics" is reasonable

No, I generally don't, which is why I use a safer language like Swift most of the time (well, that, and the fact that I can take advantage of a nicer standard library). You put "safer" in quotes, because I don't think you quite understand how compiler optimizations are supposed to work. I think Chris Lattner's three part series, "What Every C Programmer Should Know About Undefined Behavior"[1], is a great explanation from a compiler writer for why dangerous optimizations have to exist. It certainly helped me when I was in a similar place as you, not quite understanding why the optimizer did seemingly stupid things.

Really, the crux of the issue is that every language has tradeoffs: you can program in assembly and know exactly what your program is doing, but you lose the portability and convenience of higher level languages. Then you have the C family of languages, where you get access to some higher level concepts at the cost of ceding control to a compiler. The compiler's job is to generate assembly that matches what you are trying to do in the most efficient way possible. Of course, if it did so too literally it would be very slow to account for every single "stupid" thing you could have done, so there are some general rules that are imposed that you must follow in order for the compiler to do what you want. Then, of course, we have the high-level languages which do account for every stupid thing you might do, and so can provide proper diagnostics.

[1] http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

Re: Bringing Objective-C to the Amiga

#102

Post by saagarjha »

LeoNatan25 wrote: post #73
aplummer wrote: post #60

Earlier quoted context omitted.

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…

This might also be because Swift is more likely to crash than fail silently at runtime.

Re: Bringing Objective-C to the Amiga

#103

Post by jmpt »

mpweiher wrote: post #87
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…

Fantastic rant! Can I borrow it? I'd like to add a category: People that are aware of Objective-C's limitations and want(ed) an actual improvement, not the 1 step forward (sort of), 3 steps back that we got. And they were pretty close, even got it in the marketing slogan: Objective-C without the C. Or at least without most of C much of the time. Or some. Instead they consistently doubled down on the things that were…

Of course you can borrow it :) It's not very articulated. Just an early morning brain-to-keyboard dump.

I would count myself on your added category. Objective-C has been mostly unchanged for decades. I wanted an improvement, even if a breaking improvement.

We got properties and dot notation, which I was skeptical of. I saw a lot of misuse of those (specially with slower than O(1) accesses.) They were supported to signal intent, but instead were used as a shortcut.

We got ARC, which I must admit is useful for a large segment of developers, even though it creates a false sense of not needing to understand memory management and bites people left and right with circular dependencies. The good thing about ARC is that you can use it on a per-file basis and you can still do the performance sensitive parts with MRC.

The magic isa optimization was good.

But these were either small syntactic sugar/quality of life or internal performance optimizations. None provided significant leaps forward.

Apple could have picked Objective-Smalltalk :) And poached Lars Bak from Google.

Swift's slogan is great, but it's misleading. I read Rob Rix's rant shortly after he wrote it, and it was on the mark.

Re: Bringing Objective-C to the Amiga

#104

Post by gurkendoktor »

saagarjha wrote: post #29
checker659 wrote: post #16

Earlier quoted context omitted.

Swift is a solution to a non existent problem.

How so? I personally feel that most of the changes Swift made to the language really do solve real problems that Apple and third party developers have had with Objective-C (and other languages, as well).

If I had to implement a compiler or a database, I'd definitely pick a language with a powerful and strict type system like Swift. It's fantastic when the compiler can prevent large classes of errors. I mean, even trivial concepts like an Array are frustrating to express in Objective-C (wrapping C structs with NSValue? Ugh).

But that's not how iOS development works in my experience (YMMV). Most of the logic lives either in the backend or in C/C++ libraries, and Objective-C is just the glue between that and UI frameworks. When this glue layer gets complicated, it's usually because of animations, AutoLayout, UIKit bugs, or workarounds around performance issues. But all of these are issues with the frameworks, not with the programming language.

Objective-C is effectively a domain-specific language for Cocoa. Swift aims to be the next big general-purpose programming language, but it's still only being used for Cocoa. I think this is fundamentally the wrong direction.

Re: Bringing Objective-C to the Amiga

#105

Post by gurkendoktor »

coldtea wrote: post #52
jmpt wrote: post #36

Earlier quoted context omitted.

Good! Have you faced difficulty in the market by stating this to your employer and or in a job interview?

As a professional, they work with what is asked, not with what they prefer -- especially when dealing with a platform that might totally stop supporting Obj-C down the line. So what they prefer would be irrelevant job wise.

They're professionals, not slaves. They might have a say in the choice of tools, and they can turn down jobs otherwise. There's still plenty of Objective-C work around.

Re: Bringing Objective-C to the Amiga

#106

Post by mpweiher »

saagarjha wrote: post #101
mpweiher wrote: post #85

Earlier quoted context omitted.

> [undefined behavior for optimization] Yes, I am aware that that is the excuse. It still is a terrible excuse. > because you violated an invariant at some point of program execution. Not true. The code in question is a callback, so my code is getting called by Apple code, and ARC dereferences a pointer it has no business de-referencing. May I remind you that the code that crashed due to a segfault was { return 0; }…

> if you think "You have violated something, for which we will give you no diagnostic, and therefore we feel free to crash you at some random other place in the program that has nothing to do with the place where the alleged violation took place, again with no diagnostics" is reasonable No, I generally don't, which is why I use a safer language like Swift most of the time (well, that, and the fact that I can take adv…

I have programmed in C since ~1986, so please don't try to explain the language to me, and don't assume that my POV comes from a place of ignorance.

The craziness with undefined behavior is a fairly recent phenomenon. In fact, I started programming in C before there even was a standard, so all behavior was "undefined", yet no compiler manufacturer would have dreamed of taking the liberties that are taken today.

Because they had paying customers.

The actual benefits of the optimizations enabled are fairly minimal, and the cost is insane, with effectively every C program in existence suddenly sprouting crazy behavior, behavior that used to not be there.

Yeah, and while I know Chris personally, like and respect him, I am not taking his word for it.

> The compiler's job is to generate assembly that matches what you are trying to do in the most efficient way possible

Exactly: "matches what you are trying to do". The #1 cardinal rule of optimization is to not alter behavior. That rule has been shattered to little pieces that have now been ground to fine powder.

Sad times.

See: Proebsting's law, "The Death of Optimizing Compilers" and "What every compiler writer should know about programmers or “Optimization” based on undefined behaviour hurts performance"

Re: Bringing Objective-C to the Amiga

#107

Post by mpweiher »

Midar wrote: post #99
mpweiher wrote: post #37

Funky! I "brought" Objective-C to the Amiga sometime in ~1986/1987. I had recently acquired one of the first Amigas in Germany, still a US NTSC model, and also seen Objective-C discussed in a BYTE article. The beautiful OO structure of the Amiga Exec kernel and the higher OS levels built on top of those abstractions (except the abomination that was AmigaDOS) was almost certainly an inspiration. Having also recently p…

That all sounds too familiar. When I was still a little kid going to school, I was using Linux and found Objective-C. Really liked the language and concepts, but lacking a framework for Objective-C on Linux. So I started ObjFW a few years later. Seems you had the same experience before I was even born, except on Amiga :).

:-)

Not sure what you mean with "lacking a framework", though, there's at least 3: gnustep, libFoundation and Cocotron.

Re: Bringing Objective-C to the Amiga

#108

Post by saagarjha »

mpweiher wrote: post #106
saagarjha wrote: post #101

Earlier quoted context omitted.

> if you think "You have violated something, for which we will give you no diagnostic, and therefore we feel free to crash you at some random other place in the program that has nothing to do with the place where the alleged violation took place, again with no diagnostics" is reasonable No, I generally don't, which is why I use a safer language like Swift most of the time (well, that, and the fact that I can take adv…

I have programmed in C since ~1986, so please don't try to explain the language to me, and don't assume that my POV comes from a place of ignorance. The craziness with undefined behavior is a fairly recent phenomenon. In fact, I started programming in C before there even was a standard, so all behavior was "undefined", yet no compiler manufacturer would have dreamed of taking the liberties that are taken today. Becau…

> I have programmed in C since ~1986, so please don't try to explain the language to me, and don't assume that my POV comes from a place of ignorance.

I apologize for my tone, it was more patronizing that I had intended it to be.

> The craziness with undefined behavior is a fairly recent phenomenon. In fact, I started programming in C before there even was a standard, so all behavior was "undefined", yet no compiler manufacturer would have dreamed of taking the liberties that are taken today.

I feel that the current renewed focus on optimizing compilers has really been born out of the general slowing of Moore's law and stagnation in hardware advances in general, as well as improvements in program analysis taken from other languages. Just my personal guess as to why.

> Exactly: "matches what you are trying to do". The #1 cardinal rule of optimization is to not alter behavior. That rule has been shattered to little pieces that have now been ground to fine powder.

The optimizing compiler has a different opinion than you do of "altering behavior". If you're looking for something that follows what you're doing exactly, write assembly. That's the only way you can guarantee that the code you have is what's being executed. A similar, but not perfect solution is compiling C at -O0, which matches the behavior of older compilers: generate assembly that looks basically like the C code that I wrote, and perform little to no analysis on it. Finally, we have the optimization levels, where the difference is that you are telling the compiler to make your code fast; however, in return, you promise to follow the rules. And if you hold up your side of the bargain, the compiler will hold up its own: make fast code that doesn't alter your program's visible behavior.

Re: Bringing Objective-C to the Amiga

#109

Post by aplummer »

saagarjha wrote: post #102
LeoNatan25 wrote: post #73

Earlier quoted context omitted.

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

This might also be because Swift is more likely to crash than fail silently at runtime.

I don’t see how this is possible, example?

Re: Bringing Objective-C to the Amiga

#110

Post by mpweiher »

saagarjha wrote: post #108
mpweiher wrote: post #106

Earlier quoted context omitted.

I have programmed in C since ~1986, so please don't try to explain the language to me, and don't assume that my POV comes from a place of ignorance. The craziness with undefined behavior is a fairly recent phenomenon. In fact, I started programming in C before there even was a standard, so all behavior was "undefined", yet no compiler manufacturer would have dreamed of taking the liberties that are taken today. Becau…

> I have programmed in C since ~1986, so please don't try to explain the language to me, and don't assume that my POV comes from a place of ignorance. I apologize for my tone, it was more patronizing that I had intended it to be. > The craziness with undefined behavior is a fairly recent phenomenon. In fact, I started programming in C before there even was a standard, so all behavior was "undefined", yet no compiler…

> The optimizing compiler has a different opinion than you do of "altering behavior".

Obviously. And let's be clear: the optimizing compilers of today. This rule used to be inviolable, now it's just something to be scoffed at, see:

> If you're looking for something that follows what you're doing exactly, write assembly.

Er, no. Compilers used to be able to do this, with optimizations enabled. That this is no longer the case is a regression. And shifting the blame for this regression to the programmers is victim blaming, aka "you're holding it wrong". And massively counter-productive and downright dangerous. We've had at least one prominent security failure due to the compiler removing a safety check, in code that used to work.

> Finally, we have the optimization levels, where the difference is that you are telling the compiler to make your code fast;

Hey, sure, let's have those levels. But let's clearly distinguish them from normal operations: cc -Osmartass [1]

[1] http://blog.metaobject.com/2014/04/cc-osmartass.html

Post reply on HN