91–100 of 122 posts
Earlier quoted context omitted.
I am a fan of Eclipse, but I hate xcode - it hasn't got half of the features it should have and the code completion is just horribly bad.
Code completion in XCode 4.2 using llvm/clang has improved a whole lot. I'd say it's on par with Eclipse now.
If you have worked in smalltalk and C (a somewhat rare combination these days, I must admit) , Objective C is trivially readable.
And even if you haven't, you can learn how to read it in ten minutes. Say what you want about Obj-C, but I think its readability is really outstanding.
Earlier quoted context omitted.
They could have added garbage collection if they wanted to add as much ram to the iphone as the Android phones have but I guess they already made their choice long before one could develop code for the iphone.
The Android phones appeared a year or so later. Memory prices weren't the same. And GC is always less efficient than no GC, even with more memory.
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 lived and small objects.
Earlier quoted context omitted.
They could have added garbage collection if they wanted to add as much ram to the iphone as the Android phones have but I guess they already made their choice long before one could develop code for the iphone.
The Android phones appeared a year or so later. Memory prices weren't the same. 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 later restoring that memory to the block and possibly enlarging the block, merging with others, etc.
On the other hand, in a modern generational GC, a malloc typically consists of adjusting a single pointer to the nursery pool by the size requested.
Depending on the scenario, GC can be just as fast, or even faster. In other scenarios, manual memory management may be faster.
If the libraries were designed more like C++'s (say what you will about STL, but at least set is called set), I'd probably have no issues whatsoever.
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.
[someInstance doSomethingWithObject:a andAnotherParam:b];
It just reads beautifully. Otherwise working with Objective-C was like pulling teeth at times. It had been a long time since I had to write so much code to get such simple things done.
Earlier quoted context omitted.
The Android phones appeared a year or so later. Memory prices weren't the same. And GC is always less efficient than no GC, even with more memory.
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…
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
Xerox PARC, GUI, inspired Steve Jobs, all that fun stuff.
Objective-C is a sort of nerfed Smalltalk bolted onto the side of C. Yes you can see the seams and it's clunky-looking, but it works. Smalltalk semantics means it's much easier to build robust and loosely-coupled programs than in C++, and you don't even occur that much runtime overhead.
I do all my game dev in Objective-C, and I don't even have a Mac that I use actively. In fact I defy people to write significant Objective-C programs that don't use or need the Cocoa or NS libraries. I think they will have an easier and more fun time of it than when working in C++.