"Things like factories, adapters, and other design patterns are all thankfully not there."
Not sure I understand this? How does Obj-c enable the developer to avoid factories?
In defence of Objective-C
51–60 of 122 posts
Re: In defence of Objective-C
#52I 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.
xcode - unstable piece of sh*t. Even after so many years it still tends to crash randomly...
Re: In defence of Objective-C
#53Earlier quoted context omitted.
On #4: personally, I believe it is a mistake to attempt to abstract memory management from developers unless you can abstract all resource management (as there is no fundamental difference between memory mappings, file handles, database connections, or minimum-wage bicycle messengers), and in the attempt to fully abstract memory management (as in, with garbage collection) it usually becomes impossible to abstract arb…
>as there is no fundamental difference between memory >mappings, file handles, database connections, >or minimum-wage bicycle messengers The number of programs you can write without file handles, database connections or minimum-wage bicycle messengers is dwarfed by the number of programs that are extremely painful to write without dynamic memory allocation. We can argue all day about how 'fundamental' the difference…
I would love to see a reference for the "profound practical difference well-recognized in the decades of work that's gone into memory GC".
Many languages, including Objective-C (although, arguably/mostly Foundation), manage to provide primitives that make it easy to manage either at once; the only high-level complexity you have to give up is cycle detection, which is a serious problem and "known tradeoff" in many fields, including deadlock detection (hence, why I mention an interesting connection to things like CAP).
Also, I would also love to see a reasonable program that does not have external resources: I find that almost all the work my programs are doing are managing and moving around external resources... from threads to sockets to money, you are probably not doing anything terribly useful unless you are dealing with a non-memory resource.
Regardless, the goal of these statements is "a defense of Objective-C", not "why Objective-C is amazing": the "defense of Java", when you show someone a four-level nested try/finally whose sole purpose is to make non-deterministic finalization of File objects exception-safe, is "but we have garbage collection, which has these nifty properties, including automatic cycle detection".
Re: In defence of Objective-C
#54-quote- Go and look at some Lisp, then come back – obj-c will suddenly look better :) Trust me, it grows on you. You’ll soon learn to see through the brackets – just like the green vertical text in the matrix, it becomes invisible after a while. -end quote- Its ironic that a Lisp/Scheme person would say the same as to why s-expressions are good (the parens become invisible!) so I don't see why objective-c syntax is b…
"You’ll soon learn to see through the brackets"
@I @hope @that @also @applies @to @the @the @at-@signs. ;-)
Re: In defence of Objective-C
#55Go and look at some Lisp, then come back – obj-c will suddenly look better :)
...
For example, to filter an array is lovely
(filter foo? all-records)
Re: In defence of Objective-C
#56Earlier 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?
Probably that you can get stuff done simply, without writing a lot of boilerplate code.
Yup, that's pretty much what i meant, plus a bit of what veyron meant when he was talking about obsession with the GoF.
Wow, you guys really are reading a lot into what i've written, keep in mind that this was written as a light-hearted and hopefully factual rebuttal to all the anti-iphone/objc trolling at my work. Peace :)
Re: In defence of Objective-C
#57I 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.
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.
Re: In defence of Objective-C
#58Is it considered poor form around here to submit your own articles? If so, i'm terribly sorry and will remove, however i feel strongly that a lot of people write off obj-c based on superficial weaknesses, and that it has a lot of strengths that are very underrated, and i wish i'd known a lot of this stuff when i started off in iphone development.
Don't worry, it's on-topic.
Your first two code samples are about twice as wide as the space allowed for them, so they are hard to read (horizontal scrolling on text is bad).
Re: In defence of Objective-C
#59As someone who likes Objective-C a lot, I have to say this is a pretty bad defense of it. No offense, clearly we are both fans of the language, I just don't think this will convince anyone on the other side. In fact, I find very little defense of it at all in this post. It seems his fundamental argument is "its a matter of taste", which while true, in no way conveys the many "whys" of the choices made in this languag…
Hi, Thanks very much for your thorough and constructive criticism :)
For me, writing articles like this is as much about learning to be a better communicator as anything, and you've (indirectly) really got me thinking about how i could have written this better.
I'm thinking there should be a single 'theme' to an article, and that every topic/point discussed should be related to that theme. In the case of this blog post, it should have been 'pragmatism' as you identified.
If i had written with that in mind, i could have used every point to illustrate how obj-c really reflects pragmatic principles in so many ways, which would have been a much better article.
Re: In defence of Objective-C
#60Earlier quoted context omitted.
>as there is no fundamental difference between memory >mappings, file handles, database connections, >or minimum-wage bicycle messengers The number of programs you can write without file handles, database connections or minimum-wage bicycle messengers is dwarfed by the number of programs that are extremely painful to write without dynamic memory allocation. We can argue all day about how 'fundamental' the difference…
I would love to see a reference for the "profound practical difference well-recognized in the decades of work that's gone into memory GC". Many languages, including Objective-C (although, arguably/mostly Foundation), manage to provide primitives that make it easy to manage either at once; the only high-level complexity you have to give up is cycle detection, which is a serious problem and "known tradeoff" in many fie…
>I would love to see a reference for the "profound practical difference well-recognized in the decades of work that's gone into memory GC".
I don't think you need a reference - when we discuss algorithms we have a notation to describe an algorithm's behaviour in time and space yet never bicycle messengers. If anything, this suggests these resources are, indeed, somehow (and obviously) more fundamental.
The 'defense of Obj-C' article thing is pretty silly, no argument there.