Does anyone else look at Objective-C code, and just want to puke?
A few people. I would call them shallow in this regard, but that would imply there was something bad with the code in the first place, even if shallow.
Bringing Objective-C to the Amiga
51–60 of 113 posts
Re: Bringing Objective-C to the Amiga
#52Earlier quoted context omitted.
I actually prefer Objective-C to Swift.
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.
Re: Bringing Objective-C to the Amiga
#53Earlier quoted context omitted.
I prefer to keep the dynamism over unreadable fp "expressiveness" or safety that was not needed in the first place.
There's nothing stopping you from writing dynamic Swift code or functional programming in Objective-C.
Or building a house with toothpaste. But this was more about what's more common/supported by the language/approved by the community rather than what's possible.
Re: Bringing Objective-C to the Amiga
#54Earlier quoted context omitted.
> the colon overload of C++ There's a lot of colons here too: - (id)outputImageProviderFromBufferWithPixelFormat:(NSString *)format pixelsWide:(NSUInteger)width pixelsHigh:(NSUInteger)height baseAddress:(const void *)baseAddress bytesPerRow:(NSUInteger)rowBytes releaseCallback:(QCPlugInBufferReleaseCallback)callback releaseContext:(void *)context colorSpace:(CGColorSpaceRef)colorSpace shouldColorMatch:(BOOL)colorMatc…
In other languages, a function with that many parameters would be close to unusable. Far too easy to get them mixed up. The way Obj-C forces you to name each argument is great.
Yeah, I'm not complaining, I really do like argument labels. Objective-C sometimes does go overboard with sentence-like labels, but usually it's not an issue.
Re: Bringing Objective-C to the Amiga
#55Earlier quoted context omitted.
> the colon overload of C++ There's a lot of colons here too: - (id)outputImageProviderFromBufferWithPixelFormat:(NSString *)format pixelsWide:(NSUInteger)width pixelsHigh:(NSUInteger)height baseAddress:(const void *)baseAddress bytesPerRow:(NSUInteger)rowBytes releaseCallback:(QCPlugInBufferReleaseCallback)callback releaseContext:(void *)context colorSpace:(CGColorSpaceRef)colorSpace shouldColorMatch:(BOOL)colorMatc…
Yes, but they don't come in pairs and are neatly spaced away from each other.
This was mainly meant as a joke :)
Re: Bringing Objective-C to the Amiga
#56Earlier 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…
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!
Re: Bringing Objective-C to the Amiga
#57Does anyone else look at Objective-C code, and just want to puke?
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, afair).
Re: Bringing Objective-C to the Amiga
#58Earlier 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.
It’s gotten a decent but faster very recently for many cases, but still slow and throws weird false warnings sometimes.
Re: Bringing Objective-C to the Amiga
#59Earlier quoted context omitted.
Yea, but you lose C++ interop, your binary will be inflated with those Swift proxy libs and your compilation times will increase 2-3-fold.
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.
Sure, by all means they should keep up the good work. I'll be happy to switch when it's ready. But until then, I'll stick to my trusty Objective-C for serious work.
Re: Bringing Objective-C to the Amiga
#60Earlier 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…
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.