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

In defence of Objective-C

splinter.com.au

Post reply on HN
Print view View original

111–120 of 122 posts

Re: In defence of Objective-C

#111

Post by matwood »

chubs wrote: post #9
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…

Wow - this is fantastic! I'm glad i submitted this now, just reading the comments here is very heartening. I was beginning to think i was the only guy in the world who liked obj-c :) (i work in a c#/java predominaated environment where most people troll me about obj-c all day!)

I like obj-c, and never really found it hard. IMHO, the real challenge with Apple development is not the language but learning all the frameworks and the Apple way of doing things. The learning curve is a bit steep at first, but quite powerful (and intuitive) once you get over the hump.

Re: In defence of Objective-C

#112

Post by Androsynth »

thought_alarm wrote: post #15
Bdennyw wrote: post #6

Earlier quoted context omitted.

Make no mistake Apple's priorities are: Apple, Users, Developers.

If you're a developer (or a business), what's your priority? If it's not your users (or your customers) then you're doing it wrong.

late comment that will probably never get read:

This is overly simplistic. In their heyday MS catered to developers first and their users second. You can make some snarky comment about this, but at the time it allowed them to become one of the largest and most powerful tech companies out there.

Google catered to it's own engineers first.

The point is there are different ways of building a business; don't blindly choose the Apple path just because they're currently at the top of the heap.

Re: In defence of Objective-C

#113

Post by veyron »

nolanw wrote: post #104
veyron wrote: post #30

Earlier quoted context omitted.

Why don't you expand upon this and your other comments into a full-blown defense of objective C? for the record: My preference for Smalltalk-style messaging over Simula-style objects is largely historical (having been exposed to the former first)

I'm curious why you ascribe that preference to historical reasons. My exposure was in reverse order to yours but we have the same preference.

(on a side note: would be cool if HN had a SO-style notification system which would tell me when someone replies ...)

I think I have a solid understanding of both models and how to work with each, but as far as syntax goes I'm fairly ambivalent (granted, most of my code is in C/assembly).

Re: In defence of Objective-C

#114

Post by dpark »

dextorious wrote: post #108
dpark wrote: post #95

Earlier quoted context omitted.

> And GC is always less efficient than no GC, even with more memory. No, it's not. GC allows for more efficiency in many scenarios. Imagine creating and destroying many small objects. With traditional memory management, every malloc incurs a cost to allocate a chunk of memory from the free store. This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for lat…

> This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for later restoring that memory to the block and possibly enlarging the block, merging with others, etc. This manual work incurs a penalty only for the developer, not for the performance. And you get to fine tune your memory allocations to your program's behavior. > in a modern generational GC, a mallo…

No, the work I described is not done by the typical developer. When's the last time you coded your own malloc ? Under the covers, though, malloc has to a lot of expensive bookkeeping of the sort I described that modern GC doesn't have to worry about.

And GC can be more efficient in terms of memory usage as well. Modern GCs compact and so avoid most loss due to fragmentation. Where malloc will generally leave blocks partially unused, GC can allocate objects consecutively with no space between them, even if the objects vary in size (though there may be loss due to alignment, but that loss will occur in any memory management scheme).

Re: In defence of Objective-C

#115

Post by dpark »

bitwize wrote: post #99
tomjen3 wrote: post #94

Earlier quoted context omitted.

Not necessarily. Especially not if you can program the cache (no idea if that is possible on an ARM processor). The thing is that Malloc isn't particularly smart about how memory is allocated so you can end up with various tangles, etc. On the other hand if you have enough memory you can do a hole world copy which, among other things, means that allocating memory is O(1). This is better than malloc if you have short…

That's what custom allocators in C++ are for. If your available memory is less than five times the working-set size, GC is less efficient than some sort of malloc/free perhaps with reference counting

Where did you get this 5x number? As for reference counting, that's rather time-expensive, and does horrible things to the cache in multi-threaded scenarios.

Re: In defence of Objective-C

#116

Post by bitwize »

dpark wrote: post #115
bitwize wrote: post #99

Earlier quoted context omitted.

That's what custom allocators in C++ are for. If your available memory is less than five times the working-set size, GC is less efficient than some sort of malloc/free perhaps with reference counting

Where did you get this 5x number? As for reference counting, that's rather time-expensive, and does horrible things to the cache in multi-threaded scenarios.

Hertz and Berger's "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management":

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.9...

The reference counting would only be used in certain cases where the dynamic extent of the object is unknown. Most objects can be cleaned up with an implicit management scheme like the RAII pattern in C++.

Re: In defence of Objective-C

#117

Post by dpark »

bitwize wrote: post #116
dpark wrote: post #115

Earlier quoted context omitted.

Where did you get this 5x number? As for reference counting, that's rather time-expensive, and does horrible things to the cache in multi-threaded scenarios.

Hertz and Berger's "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management": http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.9... The reference counting would only be used in certain cases where the dynamic extent of the object is unknown. Most objects can be cleaned up with an implicit management scheme like the RAII pattern in C++.

Thanks. I'll take a look at that.

Re: In defence of Objective-C

#118

Post by icodestuff »

rbxbx wrote: post #88
jasonlotito wrote: post #77

Earlier quoted context omitted.

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

filteredArray = [allRecords filteredArrayUsingPredicate: [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; in ruby: all_records.select {|r| r.some_field == some_field_filter_value} in clojure: (filter #(= % some-filter-value) all-records) in haskell: filter (\someField -> x == someFilterValue) allRecords

Let's be fair, in Objective-C, this could be actually more like

  NSIndexSet *indicies = [allRecords indexesOfObjectsPassingTest:^ (id obj, NSUInteger idx, BOOL *stop) { return [obj someField] == someFieldFilterValue; }];
  filteredArray = [allRecords objectsAtIndexes:indicies];
rather than what the article had in mind.

EDIT: oh, someFieldFilterValue was an integer, wasn't it. Fixed.

Re: In defence of Objective-C

#119

Post by seanalltogether »

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…

7. Additionally, automated file importing needs to be added to xcode.

8. Global space is polluted with constants and enums

Post reply on HN