In defence of Objective-C • Hacker News Board

Re: In defence of Objective-C

#71

Post by jeswin » Mon, Oct 17, 2011, 11:00 AM UTC

I guess, the way to defend it would be by demonstrating expressiveness. Syntax hardly matters.

- Closures (I guess blocks might achieve the same, never worked in Obj-C)

- Lambdas

- Dynamic Typing or Type Inference. You need at least one of those.

- Or any other construct that enhances expressiveness.

Re: In defence of Objective-C

#72

Post by dfox » Mon, Oct 17, 2011, 12:02 PM UTC

saurik wrote: post #42

davedx wrote: post #37

Earlier quoted context omitted.

I stopped reading at: "Things like factories, adapters, and other design patterns are all thankfully not there." Huh? Design patterns are "thankfully not there"? What does that even mean?

Not that I agree with him, but I do understand what he meant by that, and might be able to explain slightly: many people believe that "design patterns" are something that languages like Java (quite in particular, this language is held up during these conversations) require to work around design deficiencies. Arguably, this is true: many of the patterns simply "fall away" if you have access to features like multi-meth…

Factory is actually perfect example of pattern that is mostly used to overcome the fact that passing classes around is unnecessarily complex in Java and thus it's favorable to wrap code calling constructor in it's own class and pass instances of it. In "dynamic" languages (including ObjC) you can simply use use the class object (and if the need arises: things that behave like class objects) itself instead of factory in most cases.

Re: In defence of Objective-C

#73

Post by dfox » Mon, Oct 17, 2011, 12:09 PM UTC

wisty wrote: post #64

5hoom wrote: post #8

Does Objective-C really need defending? After doing a couple of projects with it I've found it to be a really beautiful language from a code formatting point of view. The whole 'overly verbose' thing is probably just because you are encouraged to give your methods and arguments good descriptive names, and often when you do need short variable names for some maths calculations or something it will be while inside a me…

99% of the people who use it have no choice, so not really. But it's nice to see a semi-tutorial wrapped in an argument. Arguments are more fun to read than tutorials, so I picked up a few factoids (named args) without having to read Apple's documentation (which is a little dry).

It's important to realize, that ObjC (and Smalltalk, Self...) does not have named arguments in the conventional sense (ie. like Python, &key arguments in CL...) but mix parts of message name with it's arguments. In essence, it only looks like named arguments - and on the other hand, this syntax essentially precludes support for real named arguments. For why this is bad look at all these #with:, #with:with: ... #withValues: methods in Smalltalk's standard library that are only thin wrappers used to simulate true optional or named arguments.

Re: In defence of Objective-C

#74

Post by kaffeinecoma » Mon, Oct 17, 2011, 12:12 PM UTC

Not a fan of the syntax, but my real gripe is with the header files, and all the DRY that entails. If I were Apple that's the first thing I'd aim to fix, rather than giving us ARC.

Re: In defence of Objective-C

#75

Post by dbattaglia » Mon, Oct 17, 2011, 12:21 PM UTC

5hoom wrote: post #22

fbuilesv wrote: post #10

I wonder if I'm the only person that thinks that Xcode is the problem, not ObjC. Having experience with C I feel just fine writing code in Objective-C, but only the thought of trying to use Xcode instead of Emacs is painful. I'd love to know what Eclipse/VS/NetBeans users think about it, maybe it's easier if you're already used to working inside a huge IDE.

No, you're not the only one. Most of the problems I've hit with iOS development are Xcode-isms. I've recently been sent on a merry hunt to get the built-in git integration from imploding, and the project groups vs folders ambiguity has caused mistakes of the "what actual file is this name pointing too again?" variety (and this in turn leads back to the git integration issues when a file is not where you think it is).…

I believe JetBrains have an Obj-C IDE now. Haven't tried it yet but I know they are pretty good at the whole refactoring thing (I use ReSharper at work all the time).

Re: In defence of Objective-C

#76

Post by glenra » Mon, Oct 17, 2011, 12:54 PM UTC

mquander wrote: post #41

For example, to filter an array is lovely: filteredArray = [allRecords filteredArrayUsingPredicate: [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; A four-word name for filter and filtering for equality by using a string formatting DSL are not really on my list of lovely things. I'm sure Objective-C does something well but this guy is not pointing it out.

Yeah, I found that line hideous - ridiculously unintuitive and hard to read compared to the equivalent in say, ruby.

Maybe the whole essay would have been better framed something like: "Objective C: not quite as bad as Java!"

Re: In defence of Objective-C

#77

Post by jasonlotito » Mon, Oct 17, 2011, 1:02 PM UTC

glenra wrote: post #76

mquander wrote: post #41

For example, to filter an array is lovely: filteredArray = [allRecords filteredArrayUsingPredicate: [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; A four-word name for filter and filtering for equality by using a string formatting DSL are not really on my list of lovely things. I'm sure Objective-C does something well but this guy is not pointing it out.

Yeah, I found that line hideous - ridiculously unintuitive and hard to read compared to the equivalent in say, ruby. Maybe the whole essay would have been better framed something like: "Objective C: not quite as bad as Java!"

Just curious, for comparison: what would the equivalent be in Ruby?

Re: In defence of Objective-C

#78

Post by jinushaun » Mon, Oct 17, 2011, 1:03 PM UTC

5hoom wrote: post #8

Does Objective-C really need defending? After doing a couple of projects with it I've found it to be a really beautiful language from a code formatting point of view. The whole 'overly verbose' thing is probably just because you are encouraged to give your methods and arguments good descriptive names, and often when you do need short variable names for some maths calculations or something it will be while inside a me…

I think Objective C is awesome, but I suspect many people have a hard time separating the language from the library. Apple has a pretty unique way of developing frameworks and SDKs. Comparing Android and iOS development, the Android SDK makes sense out of the box because it follows typical Java/C#/C++ style framework design.

Re: In defence of Objective-C

#79

Post by chriseidhof » Mon, Oct 17, 2011, 1:07 PM UTC

DrJokepu wrote: post #69

I don't think these are the real problems with Objective-C. To quickly address this issues, before discussing the real problems: "Ugly" - get over it, "Verbose" - get over it, "Memory Management" - Obj-C memory management is in fact super simple as long as you follow some really simple rules, especially with ARC. Now the real problems I have: 1. Lots of unnecessary code. With the old runtime, you had to modify your c…

Very true, all of this would improve the language a lot. I have often thought about writing a language that does these kind of things and compiles to Obj-C.

Also, I would love to be able to do some kind of metaprogramming without resorting to strings.

Re: In defence of Objective-C

#80

Post by smweber » Mon, Oct 17, 2011, 1:22 PM UTC

After having spent a couple years doing embedded OS development in C, Objective C is beautiful. The verbosity makes it much easier to read than typical C code and the memory management is brilliant compared to doing it yourself. It walks the line between static and dynamic types quite well, with most things being static except when dynamic makes things a lot easier. I think Objective C is brilliant considering what they were able to add to C while maintaining great speed and full compatibility with C.