Forgot your password?
typodupeerror
Programming Businesses Apple IT Technology

Steve Jobs thinks Objective C is Perfect? 784

Posted by Hemos
from the good-or-bad dept.
josht writes "Nitesh Dhanjani has posted an e-mail thread between Steve Jobs and himself. Dhanjani argues "I'd like to see Apple developers gain more choice. With every iteration of OSX, there seems to be so much effort put into innovation of desktop components, but the development environment is age old." I agree with Dhanjani. What has Apple done recently to wow the developers, and make it fun to code Cocoa components? I've looked into the Objective C and Xcode environment but compared to Microsoft's .NET solutions, it doesn't impress me at all. I think Apple can do a lot better. Steve Jobs disagrees. What do the readers think about Objective C and Xcode?"
This discussion has been archived. No new comments can be posted.

Steve Jobs thinks Objective C is Perfect?

Comments Filter:
  • by Anonymous Coward on Monday December 26, 2005 @01:05PM (#14339901)
    Frankly, compared to Intellij IDEA or even Eclipse orNetbeans, XCode sucks. (I don't know about MS stuff).

    I don't want to leave my good IDE for something less than what I have now.
  • well... (Score:4, Insightful)

    by soapdog (773638) on Monday December 26, 2005 @01:08PM (#14339910) Homepage
    not being a troll but remember "if it's not broken, don't fix it"? Objective-C and the Cocoa Frameworks are an amazing combo, very productive to code using it. I don't think there's much to add. It's not bloated like VisualStudio.NET, it's easy to grasp and understand, code is small... well, I just like the way it is, and XCode is a lot better than Project Builder so I think we're on a nice path, I don't want to see Apple reinventing its development environment every couple years...
  • I dunno (Score:2, Insightful)

    by log0n (18224) on Monday December 26, 2005 @01:10PM (#14339920)
    I've always felt Visual Studio (at least with all the .Net stuff) was turning more into a Visual Basic type of dev platform. A lot of automation, you don't have to know why your doing things the way you are doing, fundementals and such aren't important anymore, etc. It's more for application development than actual (think CS rather than IT) programming.
  • Re:I dunno (Score:1, Insightful)

    by Anonymous Coward on Monday December 26, 2005 @01:16PM (#14339940)
    True, you have that choice but you can also start your apps from main(){} and move out from there. Choice is good, and the choices are also good.
  • the Wow factor. (Score:5, Insightful)

    by revery (456516) <charles@[ ]2.net ['cac' in gap]> on Monday December 26, 2005 @01:17PM (#14339949) Homepage
    What has Apple done recently to wow the developers, and make it fun to code Cocoa components?

    When you pull in developers by "wowing" them, you get a certain type of developer. I certainly don't want my buildings and bridges built by engineers who were attracted to pastel concrete and click-and-deploy girders. Having said that, I realize that sometimes, small quirky apps written by "poet coders" can make a platform a lot more interesting, I just doubt that that's what causes innovation or platform acceptance.

  • by brindle (8241) on Monday December 26, 2005 @01:20PM (#14339958) Homepage
    Objective C is a very good language. I has a lot of the atractive OO features and still it lets you get as close to the machine as you'd like. For example you can drop into C and do your own memory management for parts of the code where you are allocating and deallocating lots memory. You can also code in assembly if you feel the performance gain is necessary.

    Objective C appears to be a good development environment. Apple for example, has developed a lot of software in a short amount of time that is of very good quality: Safari, ITunes, Page, Keynote, mail...

    The ability of .Net to use any language is kind of sexy, but I'm not sure you are going to gann anything in the long run.

    -b
  • by rheotaxis (528103) on Monday December 26, 2005 @01:21PM (#14339964) Homepage
    Let your application domain suggest the development tools you need. Listen to art, science, and your own experience before listening to people who own lots of stock in giant corporations. They are motivated by the need to sell their own product first.
  • Re:I dunno (Score:5, Insightful)

    by Tim C (15259) on Monday December 26, 2005 @01:22PM (#14339973)
    I've always felt Visual Studio (at least with all the .Net stuff) was turning more into a Visual Basic type of dev platform.

    I'm not entirely sure what that comment means - haven't you *always* been able to use VS as "a Visual Basic type of dev platform", with Visual C++ even ignoring Visual Basic itself? VS.NET does support Visual Basic .NET after all - is it really surprising that the drag and drop method of RAD is being further extended?

    It's more for application development than actual (think CS rather than IT) programming.

    Application development isn't actual programming? Theory is extremely important, and I'm the first to defend seeking knowledge for knowledge's sake, but to say that application development isn't real programming is to deny the entire point of programming - to automate processes and create applications in order to make tasks easier (or quicker) to perform, and to enable people to do things that previously they could not (eg edit video or audio).

  • by Timesprout (579035) on Monday December 26, 2005 @01:25PM (#14339984)
    There is a perfectly good reason, its called choice. There is no one solution that fits all approach. .NET is like Java in that its a minimilist rather that a Ruby style humanitarian interface approach were you can take the basics or roll your own implemenation. The chiice is yours.
  • by squarooticus (5092) on Monday December 26, 2005 @01:33PM (#14340007) Homepage
    ...I fire back with the almost-certainly-true statement that "You don't know C++ well enough to judge its value as a language."

    I have been coding in C++ for about 15 years; I have seen the language evolve over that time; and while there are aspects that I don't like, for the most part I think C++ is wonderful and natural to program in, as long as one takes the time to design API's in an extensible way. This is no different from any other language, though C++ certainly gives you more rope if you are already inclined to hang yourself; but, OTOH, the extra slack makes it possible to type-safely do things that cannot be done in languages without multiple inheritance or parametric polymorphism.

    FWIW, the same is true of me for Objective C: I can make only the most shallow, uninformed observations about it, so I generally avoid doing so. Perhaps one day I'll learn it so I can make an informed judgment about it, but until then, I'll keep my mouth shut.
  • by cosmo7 (325616) on Monday December 26, 2005 @01:34PM (#14340017) Homepage
    So why don't you use Eclipse then? Objective C isn't wedded to XCode.

    The article is about Objective C (and Cocoa) versus C# (and .net). Although I like the former, there certainly are items where the latter is ahead - compare .net's media layer with Cocoa's phoned-in Quicktime classes. Or regular expressions. Where are the regular expressions in Cocoa?
  • by Rew190 (138940) on Monday December 26, 2005 @01:36PM (#14340030)
    Objective C is pretty nice to use, but I think Apple really needs to come up with a language that doesn't require memory management. Not everyone is designing more upscale applications where management is essential. Personally, this is a rather large "fault" of Apple's development platform. Give me something that supports Cocoa (not Java) with managed memory and I'd be much happier.

    It would also be nice if they would use something with a more conventional syntax (I'm looking at you, method calls). Wasn't a huge deal, but I think it would make it easier to dive into or attract developers who are more used to the Java/C#/etc way of doing things.

    As a side note, much of .NETs attraction seems to be that it is very simple to put together GUI-driven applications (that actually look they're Windows programs) quickly.
  • Re:well... (Score:2, Insightful)

    by Anonymous Coward on Monday December 26, 2005 @01:37PM (#14340035)
    yeah, sure...not a troll but you throw out "bloated" and the obligatory .NET slam. Don't get me wrong I have some issues with .NET (personally I prefer java to .NET and old school C++ to both but just because I know it better....it's a personal bias not based on the technology itself) but it's not bloated. More important that what I like and to reiterate what someone said above if it doesn't have proper namespace support it isn't anywhere close to perfect. Keep trying, Troll.
  • by Svartalf (2997) on Monday December 26, 2005 @01:38PM (#14340038) Homepage
    Garbage collection is a bad thing in many cases...

    GC causes all kinds of load spikes that can bog down end user apps and blow server apps clean out of the water. GC makes things "easier" for the developer at the expense of overall performance. But, with at least C++, there are ways of accomplishing the same thing without needing a GC subsystem spooling up CPU cycles- smart pointers handle most of the same features that GC does in a safe and efficient manner. The code knows when a variable has dropped out of scope (it's compiled into the code itself...) and frees memory as opposed to a separate thread of execution periodically polling all the active objects to see which ones have dropped out of scope.
  • Re:well... (Score:3, Insightful)

    by Rew190 (138940) on Monday December 26, 2005 @01:38PM (#14340040)
    There's things that can be taken away, however; being forced to manage memory being a key one if you want to attract Java/.NET developers.
  • by NutscrapeSucks (446616) on Monday December 26, 2005 @01:59PM (#14340144)
    What Jobs is ignoring is that Macintosh customers are primarily non-technical, and have no need or want for a "religious war" around programming languages. Even if Obj-C and Cocoa are perfect, they are still for all intents-and-purposes a proprietary Apple-only environment (please don't pretend GNUStep has any wider importance), and is only used by True Believer devs.

    What the Mac platform needs the most is applications, good ones. And if the apps are good, the users simply don't care if the language frameworks are slightly faster or nicer to program with.

    ObjC/Cocoa is one set of good tools, but so is the .NET framework and C# and it is considerably more popular as well. Withholding .NET (and Java) from Mac users only hurts the variety of applicaitons, which in turn hurts the strength of the platform.

    NeXT was a developer tool company and he could get away with this approach. Mac is a mainstream platform (or trying to be), and there needs to be "more than one way to do it".
  • by joto (134244) on Monday December 26, 2005 @02:02PM (#14340160)
    This looks all good in theory. Fortunately, the objective C developers have thought about the problem, and they have come up with a solution that is quite fast. So in the real world, and objective C message send is about 2x-3x as slow as a C function call. Which is not too bad. The obvious implementation you hint at, would probably be more like 50x-100x slower. Fortunately, it's not the one that's used in practice, and I doubt you will ever find it in an objective C compiler (unless you were to write one yourself, just to prove your point).
  • by INeededALogin (771371) on Monday December 26, 2005 @02:08PM (#14340204) Journal
    From his thread:

    I _still_ have to look out for yucky pointers?

    I hate these fucking developers like this. These people that don't want to write code, but would rather have everything taken care of them in an unpredictable manner.

    Garbage Collection==excuse for not writing better code and don't give me the excuse that you can write your code faster. The time spent writing nasty code results in memory problems, garbage collections freezing an application, and numerous bugs. Not to mention that these developers use memory like its candy... Not knowing that every one of their objects in a list uses 2 megs of memory.

    pointers==I don't understand how my computer allocates, deallocates and references memory so I would rather have Sun wrap all that confusion and trust that they did it well. Sorry... but if you have never used pointers then you obviously do not understand the benefit of using them. And while it is nice that Sun can take away the need to use them, they should still be available in some manner to the developer. I feel I can optimize my code a lot more than sun can.

    IDE whores==hold my hand while I code. Honestly, developers that depend on an IDE and the hitting of a period to find the Integer.parseInt() method end up writing some of the worst code. I work at a company where I refuse to write Java code for them. Basically because these developers are morons and don't understand any of the hardware and software that they implement. A good example was a lot of developers started implementing JGroups which is a multicast memory replication useful for clustering. It worked great except every developer copied the same code snippet and every application was using the same multicast group and port. Instead of changing the address, they decided to handle it at the application level and filter it after they had read the packets off the socket. Gross.

    Bytecode is great==I don't understand how fast a computer really is with native code. Bytecode solves a few problems, but it is totally unacceptable for large applications. Whatever happened to Sun's Web Brower? It died despite being Java. Everyone says Eclipse is a great IDE, but its bloated and slow. I worked at a company that put all its Apples(No Pun Intended) into Java/Swing combination. When I left, 4 years after the project was started, they were still having UI speed problems. When I develop, I don't want anyting getting in my way and I don't want to have to buy a 3ghz processor to do it/run it.

    Now, I know all the Buzz word slashdot people will disagree with me, but Object Oriented programing adds a layer of abstraction, taking away pointers adds another layer of abstraction and then adding in a garbage collection adds another layer of abstration. And also having Sun hide all those pointers behing an extrememly gross hierachy of classes that always seem to hand-off work to another class has its penalties.
  • by TapestryDude (631153) on Monday December 26, 2005 @02:09PM (#14340207) Homepage
    Objective-C was my first object-oriented language (this was back in 93 - 95). I loved the syntax and the integrated vision of the tools and frameworks ... but I hated memory management. The whole retain/release/autorelease thing was always a bug waiting to happen, and I spent many wasted hours tracking those down (basically, retain/release works great for trees but flops around like a dying fish for graphs).

    Anyway, I simply can't go back to a non-memory managed environment again.

    I have seen that, as I've matured as an OO developer, and as I've distanced myself from Objective-C, my style has changed. The Objective-C libraries are heavily based on inheritance, but I've learned that "composition trumps inheritance" ... meaning that its better to combine many small focused objects. In Objective-C, you have a layer-cake approach, where each layer of inheritance mixes in a particular concern. This makes sense when you want to minimize the number of objects allocated, but in a GC language (Java, Ruby, etc.) you end up with better, more testable code when you let the GC do its thing.

    You can see this in Tapestry, where currently (through the 4.0 release) you extend base classes. I'm starting to gear up to break this limitation for 4.1 (where you will use simple objects and have framework dependencies injected into your classes).

    ProjectBuilder was great in its time, but compared to Eclipse, it's hopeless. IB still rocks, and I wish Sun had demostrated some intelligence when first designing Swing by investigating IB. That is, Swing treats UIs as a coding problem, IB treats it as a configuration problem.

    But, as I said, you can't go home again.
  • by Anonymous Coward on Monday December 26, 2005 @02:25PM (#14340297)
    How the hell did that even get posted to Slashdot in the first place? Does anyone actually check anything before these things go live?

    Sigh. I don't know how many times I have to point this out, but Slashdot has nothing to do with accuracy or "news". It is about PAGE HITS. PAGE HITS = ADVERTISING BUCKS. That is all you need to know about it.
  • by fpillet (41353) on Monday December 26, 2005 @02:27PM (#14340302) Homepage Journal
    Overall, objective c message call performance is comparable to Javascript.
    You haven't written any real code with Objective-C, have you ? I have a couple commercial apps written in full Obj-C and I can tell you that what you're saying is plain wrong. The message dispatcher is fast, uses caching techniques, and in case you have a really tight algorithm that neeeds to send millions of messages to perform some computation, you can always get the IMP pointer to the final address instead of going through the dispatcher. But I certainly never felt the need for that.

    A dumb developer will write bad code in ANY language. And of course, he'll blame the language ;-)
    Now, of course you can just call C functions, but then what is the point of objective C?
    ... or what's the point in any OO language, when you can code in straight C? Exactly the same: designing and structuring your code. The single selling point with Objective-C / Cocoa is the NSAutoreleasePool mechanism. This mechanism is like a garbage collector finally done right.
    Modern languages like Java, C# provide all the dynamsism of objective C, but do it effciently thougth vtables and reflection.
    Reflection is insanely costly to use. Actually MS recommends to avoid it if you can, especially on mobile platforms. Besides, are you saying that Java or C#, both JITted languages, are faster than Objective-C ? Think twice. Microsoft itself says that C# is slower than the less optimized C compiled code you can find. And I have yet to see a Java app doing anything significant that is not slow as molasses.
  • by Anonymous Coward on Monday December 26, 2005 @02:28PM (#14340314)
    You know, having written half a dozen medium-scale Cocoa programs of my own and worked on a dozen or so more in teams, I can say that not only have I never used regular expressions, it's never even occurred to me to want them.

    I'm willing to bet that if you find yourself wanting to use regular expressions in a Cocoa program, one of two things is happening. Either you're coming from a scripting background and you haven't really figured out how to program in Cocoa yet, or you're using Cocoa for a job that could be better done with a script.

    Don't just use Cocoa because it's the cool new thing. Use it for things that it's good for. For things that Cocoa's not good for, use something else.
  • Re:namespaces (Score:2, Insightful)

    by Anonymous Coward on Monday December 26, 2005 @02:29PM (#14340318)
    >> Had he not known Wozniak, more than likely he would be manager at Sears or Circuit City or something...
    > ...or Pixar.

    No. This is offtopic, but what's clear from Jobs' experience at Apple is that he had big dreams and a child^H^H^H^H^H undeveloped set of people-management skills.

    If he hadn't been thrust into a leadership role early on, Jobs probably would have been another big talker who never mastered the skills it takes to move up the ladder. A lot of entrepreneurs have this problem when they try to move into established corporate structures.
  • Re:namespaces (Score:3, Insightful)

    by golgotha007 (62687) on Monday December 26, 2005 @02:34PM (#14340346)
    Show me a single person on this planet with no ambitions?

    The Sears/Circuit City thing was just my attempt at humor. However, he would have no where near the success he's had if he didn't have the right friend at the right time.

    You may be right about his programming talent (I'm not saying you are) but clearly you don't know a single thing about human nature.

    If you think that Steve Jobs has any programming talent, then you don't know a single thing about Steve Jobs.
  • by jcr (53032) <jcr@@@mac...com> on Monday December 26, 2005 @02:50PM (#14340443) Journal
    he gives the inside story on Steve Jobs:

    No, Raskin gives his opinion of Steve Jobs. Read Andy Hertzfeld's book for some perspective on Raskin.

    -jcr
  • by StrawberryFrog (67065) on Monday December 26, 2005 @02:52PM (#14340454) Homepage Journal
    Garbage Collection==excuse for not writing better code and don't give me the excuse that you can write your code faster

    Yeah, that's why Java and C# will never catch on. Troll.
  • Re:well... (Score:3, Insightful)

    by Frizzle Fry (149026) on Monday December 26, 2005 @02:54PM (#14340467) Homepage
    Objective-C and the Cocoa Frameworks are an amazing combo, very productive to code using it. I don't think there's much to add. It's not bloated like VisualStudio.NET

    Did you just compare a language and framework to an IDE? How can that make sense?
  • by Durandal64 (658649) on Monday December 26, 2005 @02:54PM (#14340472)
    I'm sorry, but I have to disagree. Objective-C has the most intelligent syntax of any language I've ever worked with. Just because none of the latest "miracle" languages, like C# and Java, have adopted a new function calling syntax doesn't mean there aren't problems with it. Frankly, the constructor naming for C++, Java and C# is brain-dead. What makes more sense?
    color = NSColor(128, 128, 64, 0);
    or
    color = [NSColor colorWithRed:128 Green:128 Blue:64 Alpha:0];
    I would much rather have an idea of what parameters are without having to refer to a header file. And being able to have initializers that are of different names is a HUGE plus. In C++ et al, all your constructors are forced to have the same name, varying only among their parameters. I could do a
    color = [NSColor redColor];
    call and still get a new color object. In C++, you'd have to pass in some sort of enumerated constant or something.

    And this says nothing about the ridiculous naming conventions of C++ and Java. Translate the following statements into English.
    value = object.getValue();
    and
    value = [object value];
    The first is C++ and translates to "Assign value to get the value of object". The second is Objective-C and translates to "Assign value to value of object". This is why Objective-C is called a self-documenting language.

    As for memory management, yes, it can be a pain. Any Cocoa developer could tell you tales of how he accidentally released an autoreleased object and spent a half-hour trying to figure it out. But Objective-C is a strict superset of C. Being able to work with pointers is absolutely necessary. That's one of the biggest strong-points of Objective-C. Virtually any C library will work with absolutely no modification at all.

    I'd love to see garbage collection added, but not as the primary method of managing memory. It should be there to catch what the developer misses, not to be the sole method of memory management. We'll never get rid of pointers. They will always be there.
  • by squarooticus (5092) on Monday December 26, 2005 @02:55PM (#14340474) Homepage
    Objective-C does OO much more like Smalltalk: method dispatch is determined at runtime, not a compile time.
    So does C++: they're called virtual function tables.

    Unless you mean that in ObjC the possible methods for an object are not available at link time, in which case type safety is not available. I don't know enough about ObjC; perhaps you can explain it to me succinctly?

    Kyle
  • by matt4077 (581118) on Monday December 26, 2005 @02:55PM (#14340477) Homepage
    Well you don't HAVE to use Interface Builder. You can easily just init your interface programmatically. Although I don't see a reason to do it.
  • Re:namespaces (Score:-1, Insightful)

    by CmdrTaco on (468152) on Monday December 26, 2005 @03:04PM (#14340530) Homepage
    "The Sears/Circuit City thing was just my attempt at humor. "

    God damn you're fucking bad at humor. GOD DAMN!
  • by penguin-collective (932038) on Monday December 26, 2005 @03:09PM (#14340559)
    "You don't know C++ well enough to judge its value as a language."

    Ease of learning is an important part of language design.

    I think C++ is wonderful and natural to program in, as long as one takes the time to design API's in an extensible way

    The amount of effort a language forces you to invest up-front in design decisions is also an important factor to consider.

    Personally, I think C++ is a great language--but only for specialty applications and very skilled programmers.

    For most mainstream desktop applications, people are better served with Python, Visual Basic, or Smalltalk, precisely because those languages are easier to learn and require less experience to use well.
  • by penguin-collective (932038) on Monday December 26, 2005 @03:21PM (#14340621)
    I hate these fucking developers like this. These people that don't want to write code, but would rather have everything taken care of them in an unpredictable manner. Garbage Collection==excuse for not writing better code and don't give me the excuse that you can write your code faster.

    And (to use your language) I hate fucking morons like you: people who don't understand that they can't do memory management as efficiently as a machine, people who don't understand that pointer-based code is usually slower and inhibits optimization opportunities, and people who overestimate their own ability to avoid pointer errors.

    After programming in C for nearly 30 years, I can confidently say: I am incapable of writing a substantial C program without memory and pointer error bugs, I don't see the point in doing so, and I have yet to meet anybody who can. And the people who are the ones usually producing the most bugs are usually people like you, people who don't even understand their own limitations.

    And also having Sun hide all those pointers behing an extrememly gross hierachy of classes that always seem to hand-off work to another class has its penalties.

    Java is a bloated P.O.S., but Java is not representative of garbage collected or safe languages.
  • by jcr (53032) <jcr@@@mac...com> on Monday December 26, 2005 @03:23PM (#14340634) Journal
    You don't know C++ well enough to judge its value as a language

    I gave up on C++ in 1989, when it was far more defensible than it is today. I don't have to stand in line for nine hours to get half a kilo of bread to be able to judge the value of communism, do I?

    -jcr

  • Re:well... (Score:3, Insightful)

    by ceoyoyo (59147) on Monday December 26, 2005 @03:26PM (#14340645)
    Use Python. No memory management necessary. With the pyObjC bridge you can do anything you could do in ObjC.
  • by hkb (777908) on Monday December 26, 2005 @03:36PM (#14340692)
    The one thing I really like about Steve Jobs... well there are lots of things. The thing I like most about Steve Jobs is that he's unusually candid in email. I have written him a few times in the past from everything about OS X to vegan recipes and he's replied, often with expressed interest and candidness. This is something not to be abused. When this kind of stuff is publicized, I worry about two things:

    1. Steve gets inundated with tons of dumb emails just to get a "response from steve" to hang on the wall. End effect is that Steve stops reading his email.

    2. Steve stops being so personable because he figures anything he says will end up splattered all over the web. Within a few days, this simple "Dear Steve, I don't like Objective-C" thing will be blown out of proportion by cnet, dvorak, and other journalists who are entirely too clueless, et al. Remember, what Steve says could affect stock prices, etc. And Steve will just sigh and stop responding.

    It's really, really nice having a CEO that doesn't just communicate through press releases, folks. Don't ruin it. It was my hope that those few who knew Steve responded to his email would keep it on the down low.
  • by Anonymous Coward on Monday December 26, 2005 @03:46PM (#14340744)
    You missed the point. Keyword arguments make code easier to READ, not easier to write. Of course Xcode does automatic, interactive code generation with things like method signatures appearing in-line as you type. That's not the issue. The issue is that sooner or later somebody's going to have to back and READ the code you wrote, and that's where Objective-C's very-nearly-self-documenting syntax becomes a big win.

    Making it optional, however...

    Would be a fucking waste of time.
  • Re:namespaces (Score:4, Insightful)

    by Anonymous Coward on Monday December 26, 2005 @03:56PM (#14340798)
    Nobody gets to be as successful as Jobs without a lot of talent.
  • by blake182 (619410) * on Monday December 26, 2005 @03:59PM (#14340813)
    I characterize Objective C and the Interface Builder integration and a lot of those concepts to have been ten years ahead of its time when it was in its heyday (let's say 1988). So it's a 1998 environment in 2005 -- it's not really getting any younger -- they used up their "ahead of their time" card awhile ago.

    As much as everyone loves the warm fuzzy "objects send messages" purity, it all starts falling apart on hardcore refactorings (renaming messages and classes) which I consider to be a Large Problem with maintaining a large codebase. Don't get me wrong, I like Objective C. But man, it was a sad day when I learned that they're not going to keep Java up-to-date. Maybe Cocoa# is my savior.

    I programmed in Windows for 15 years before becoming more of a "server guy" and now an "OS X guy". I do agree with the comments that the API is far easier to grasp than the mishmash of shit that Microsoft shovels on you (Win32/COM/WinFX/MFC/ATL/Etc. etc.) But that doesn't have anything to do with Objective C or Xcode. That's just smart API design which isn't language or environment dependent.
  • Re:Love it (Score:4, Insightful)

    by jiushao (898575) on Monday December 26, 2005 @04:20PM (#14340908)
    This is an interesting point, a lot of people will stick on a higher level no matter what you define the interface in. On the other hand it would clearly be bad to define the platform interfaces in Python, sure it would perform fine for 95% of all tasks (these are system calls and such to a great extent after all), but it would still be too inflexible in implementation. It is troublesome trying to wrap a powerful Python interface in a lot of languages and systems, even when not considering the language and call model features Python still has a lot of runtime features that show through (garbage collection is already in itself very troublesome at the system interface level).

    The historical lowest common denominator solution has been to define it in C (though C++ has slowly crept up in the last decade) and then use higher-level bindings to make it easy to use. Gnome is a very modern system that has taken this approach. Apple on the other hand has went one step up on the abstraction ladder, they have kept the basic C interface style and linking behaviour but used the OO added by Objective C. The strong point here is that a lot of higher-level languages can now wrap much closer to the interface (getting close to a natural 1:1 mapping) while still retaining most of the possibility to go with C-style to-the-metal stuff. Objective C is even a nice enough language to make taking another step in abstraction unnecessary for a lot of people.

    Personally I really like this. Defining the platform in C has aged (though it is still useful for maximum flexibility of implementation, though very archaic to use) but going straight for a high-level garbage-collected language is a step too far still. For example I think it would be a mistake to enforce a garbage collection model on the system level, removes much too many possibilities from the application. Add to this proper function pointer objects, co-routines, "global" reflection, continuations and so on and it becomes clear that too much power at the interface becomes a liability when it has to be fitted into another system.

    This extra power is of course then a good thing for Python users on OSX just as for Objective C programmers. A straight wrapper around Cocoa is a lot nicer than say a straight wrapper around GTK+. Some may argue that this is unimportant since a "good" wrapper around GTK+ will be just as good, but personally I find that a wrapper that stays close to the unerlying interface is a very good thing when possible. Less bugs, often much more clarity, more available documentation, the skills one learns carry over if one switches languages and so on.

    Man this post is long and rambling. Better push "Submit".

  • by I'm Don Giovanni (598558) on Monday December 26, 2005 @04:21PM (#14340923)
    Here are a few ObjC problems off the top of my head.
    1. No proper namespace support. If multiple teams are working on a project, each team is advised to prepend the method names of its classes with a two or three letter abbreviation to avoid name-collision. WTF?? Hence, why all Cocoa methods are prepended with "NS" (short for NextStep). Apple should fix this asap.

    2. Horrible constructor support for derived classes. ObjC makes one proclaim one or more of a class's init methods to be "designated initializers", and these are the init methods that derived classes must override, no more, no less. Oh, and the proclamation of "designated initializers" is informal; there's no formal support by the language or runtime.

    3. All methods are public. To implement private methods, one must "simulate" them by not declaring them in the interface header file, but they're still accessible. Implementation of protected methods is even more of a hack, where one must create class Categories that are only known internally, and place the "protected" methods in those Categories. But the Categories are still accessible, and there's nothing stopping a third party from implementing a Category of the same name on his own, causing namespace-collision.

    4. Lack of proper support for abstract classes. One has to use [self doesNotRecognizeSelector:_cmd] to implement abstract classes (either in the init method or the individual abstract methods), another ugly hack.

    (Lack of garbage collection may also be a problem, although refcounting never bothered me and I rather do like autoRelease, by which one can achieve something akin to garbage collection (for objects, at least). :-))

    There are some other problems, all of which (and the above) stem from ObjC being an "old" language, having not added any of the advancements in language and runtime design that other languages adopted in the 90's.
  • Re:namespaces (Score:2, Insightful)

    by Tedium Unleased (764661) on Monday December 26, 2005 @04:46PM (#14341048)
    successful people make their opportunities. the other 99.99% of people tell themselves its luck so they can whine and tell themselves they could have been contenders.
    successful people may have some charming story involving luck, but of course luck does not keep them on top, and it's probably not much more luck than anyone else has, just like everyone else, they'll associate random events around good events as having some special meaning, or more likely tell you that.
  • 100% agree (Score:3, Insightful)

    by bani (467531) on Monday December 26, 2005 @05:12PM (#14341148)
    Apple's "our way or the highway" attitude is annoying. carbon is grudgingly provided for "those delusional c++ developers who refuse to walk the enlightened path of objc", but it is a second class citizen compared to cocoa, no matter how much apple waves their hands to the contrary.

    the problem here is that apple's obsession with objc means c++ is neglected, and it makes porting applications to osx a major pita (it doesn't help that carbon's api is wildly different from anything unix or win32 either.)

    apple is spending all their time and effort preaching to the choir. they aren't doing enough to get new converts. and objc/cocoa simply isn't the way to do it.
  • by bani (467531) on Monday December 26, 2005 @05:24PM (#14341199)
    pico > xcode

    really, i got tired of all the crashes. edit project properties in the ui, boom. internal error. build project. boom. internal error.

    i ended up writing everything in pico and using scons for builds. no boom.
  • by theAtomicFireball (532233) on Monday December 26, 2005 @05:42PM (#14341276)
    Great - you can write a specialized application with zero lines. Hey, here's an idea - I'll create a dev tool
    You set up the example, not me. I was just correcting your inefficient and exaggerated Cocoa solution to it. Don't compare the two using a simplistic example and then complain about the fact that it's a simplistic example.
    (1) The example I gave above was to illustrate the steps it takes to make a button perform a simple action (the action itself isn't the point). So, while I could've done something like have it use a built in action, I chose not to because it's not the point.
    How is it a fair comparison if you do it in .net the standard way and then intentionally choose a convoluted, non-standard approach with several unnecessary steps in Cocoa? All methods defined with IBAction can be accessed directly from interface builder without writing code, so I have trouble understanding why you would intentionally choose not to take advantage of such a fundamental feature.
    (2) The code I gave was clearly not VB - it was C#
    You are absolutely 100% right. Sorry about that.
    (3) Even with your solution for a very specific action, it STILL requires more steps
    What I suggested was not a solution to a specific problem, it is the standard way of doing the specific task you set up as an illustrative scenario, as you (of course) know. Despite that, how is it possibly more steps? You have to place the button on the window in both environments. It took me one more step to connect the button to the performClose: action method (two if you count each click of the mouse as a separate action) so it's hard to see how it could be more steps, since you have to drop to the code editor and type in a line of code in .net.
    I'm willing to bet that if you actually timed the number of seconds it takes to "write" the two apps, .NET would still win out.
    I would take that bet. I might just go ahead and do it for grins and giggles since I've got both environments open at the moment.
    Great idea, let's compare the sizes!
    Interesting. Not the same results I'm seeing, but I'll take your word for it. No point in arguing it, since it's a relatively minor issue.
    5) It's called terminate:, not performClose: - at least in Xcode 2.1
    No. You said to close the window. On Windows, that's the same as terminating the application, but on the Mac, it's not the same (as I'm sure you know); I was doing what you said - I sent the NSWindow instance a performClose: method, but we could just as easily have sent the application delegate a terminate: message (NSWindow does not have a terminate: method) - it would take no longer. The IDE version we used wouldn't affect which outlets were available in either NSWindow or NSApplication, however.
    my "professional" Cocoa work was at Apple so I was on salary, not paid by hours.
    Good thing, it would seem.
    Even my teammates there admitted that Xcode sucks and Visual Studio is much better. Many people would even use emacs because Xcode was that bad.
    I don't doubt that some people even at Apple admit that Visual Studio is a better editor. I wasn't arguing about which one was a better code editor; I was arguing about the flawed comparison you made between how long it takes to build a simple application in the two environments.
    You can say what you want about my Cocoa experience,
    I don't know anything about your Cocoa experience so have no comment on it; your resume could be absolutely amazing for all I know. The fact that you approached a matter as simple as closing a window in Cocoa by doing a half-dozen unnecessary steps does make me question your competence in Cocoa... but not your experience. If you know better, than it looks like you were intentionally trying to overstate the case to make Cocoa look bad. Neither of the two likely possibilities endears you to me.
  • by mj_1903 (570130) on Monday December 26, 2005 @06:04PM (#14341356)
    I agree. When programming Obj-C you will rarely see any memory related errors if you know what you are doing. It is not a beast to manage and the memory management is flexible enough to cover nearly all situations from some quick interface code (autorelease) to tight loops or backend components (managed retain/release). As a full time Cocoa programmer I can't really think of anything to change in that regard.
  • by bnenning (58349) on Monday December 26, 2005 @06:31PM (#14341490)
    I don't understand why people hate pointers. Is it the fear of memory math? What's going on?

    It's the nondeterministic bugs when you read or write to invalid pointers, and the risk of security holes via buffer overruns.

    Function pointers are probably my favorite thing about low-level languages

    Any decent high-level language has equivalent or superior functionality.
  • by Yaztromo (655250) <yaztromo AT mac DOT com> on Monday December 26, 2005 @06:48PM (#14341550) Homepage Journal

    And this, kids, is why you should never ever top-post.

    Yaz.

  • by tyrione (134248) on Monday December 26, 2005 @06:50PM (#14341555) Homepage
    BULLSHIT. Apple gave Carbon to Metrowerks and the rest of the ilk back in 1997 at WWDC and we told them to get ready to transition to Cocoa/ObjC. Seven years was plenty of time. Get over your loss and embrace change.
  • Re:namespaces (Score:3, Insightful)

    by saltydogdesign (811417) on Monday December 26, 2005 @07:13PM (#14341650)
    And I'm sure successful people choose to be born into stable, wealthy societies rather than in some God-forsaken African nation wracked by famine and war, yes? No luck involved there, huh?

  • For the record (Score:2, Insightful)

    by tod_miller (792541) on Monday December 26, 2005 @07:44PM (#14341803) Journal
    This guy is as retarded as he sounds ("yucky pointers").

    Gee I wish there was a 10 year old mature language available on Mac's that was better than .net....

    *thinks*

    yeah that would be cool. *thinks* You could name it Java if you want.

    This guy really sucks, not objective C.
  • by man_of_mr_e (217855) on Monday December 26, 2005 @07:47PM (#14341815)
    Indeed. I think there are some kick ass comercial unix debuggers available (or so i've heard, haven't really seen them), but Microsoft's debugger has always been bone simple to use, though not very featureful.

    That's really changed with VS 2005, the debugger can be extended in many ways that leave your jaw laying on the ground. You can create custom "visualizers" to visual data structures in memory, and the popup "drilldown" features are a dream come true.

    Want to be able to visual your HTML data buffer? XML? Custom document? Images? the visualizers are really cool.

    For example, here's a regex visualizer:

    http://regex.osherove.com/Articles/RegexKit.html [osherove.com]

    And here's an XML visualizer:

    http://blogs.conchango.com/howardvanrooijen/archiv e/2005/11/24/2424.aspx [conchango.com]
  • by samkass (174571) on Monday December 26, 2005 @09:09PM (#14342122) Homepage Journal
    While I don't know about the motivations of the original poster, I'll answer your question if you want. I've developed in Visual Studio, CodeWarrior, emacs/gcc, CodeGuide, IntelliJ IDEA, and many of the older packages. In my humble opinion, Xcode is the worst development environment out there that's being actively maintained. Worse, it is being touted by Apple as the preferred development environment for Macintoshes. I can't imagine a better way to discourage developers. Combine it with Objective C, which while somewhat elegant has a cryptic, unapproachable syntax and for all practical purposes locks you into the Macintosh, and you have an anchor on your software development community.

    But back to the question at hand...

    Although it got better with 2.1, XCode suffers seriously from configuration problems. Determining where to go to set something, where a setting is overridden, or what it actually does is insane. A simple comparison with CodeWarrior is enough to show how far development has fallen for the Mac in this respect. Then there's the plist and such files that are an inevitable part of Mac development these days. Why can't there be some better editor for that sort of thing with a nice GUI? ResEdit from the 1980's beats it. Then there's the error window. You click "compile" and you get a "ding!"... then you hunt for what happened. When you find it, you get a difficult to use pane of errors buried below, but in the same pane as, your project. Huh? Then there's the editor... having lots of files open is a pain compared to almost any other IDE. Then search... for the company that produced Spotlight, searching is amazing primitive in XCode. The general layout is a mess, the build outputs are annoying to keep track of, and things like the class browser aren't nearly as helpful as something like IDEA or even CodeWarrior. Then if you compare it to many of the Java development advantages (since we're including the old ObjectiveC language in the rant,) you start to miss out on TONS of refactoring options that Eclipse and IDEA both offer. Those types of things become essential for keeping code maintainable over the long-term. Things like xgrid for distributed compiling are near-useless for most small developers, so I hope they didn't take away any resources to develop those features, either.

    In short, I think the Macintosh community would have been much better served if Apple had simply bought CodeWarrior and wrote a gcc4 plug-in for it for PPC/x86 codegen. Then they could start adding some of the intelligent refactoring, assuming such things are possible in Objective C. Alternately, they could start over with Java or even Mono/C# and provide an environment that would let you create Mac apps quickly and efficiently, as well as being able to use the same code on Mac, Win, and Linux.

  • Re:namespaces (Score:2, Insightful)

    by mildgift (855983) on Tuesday December 27, 2005 @04:20PM (#14347181)
    This is true, but talent and circumstance are both necessary. I raised the issue because everyone's talking about talent, without thinking much about luck.

    Also, it's not like he's be able to have so much luck without the big pile of money that the Apple II generated, back in the 1970s. That cash funded a lot of failures, and one hit: the Mac.

    The Mac money was spent on a lot of things, but had one hit: Pixar. NeXT was cool, but it wasn't a financial success.

    With that string of success, he came back to Apple, made the iMac, brought back the old NeXT software from the dead, and basically trailed Windows for a while... until the iPod... which was originally a me-too product late to the market until it was mated with the music store (which is also a me-too product).

    It takes some talent to be that lucky.

"If I do not want others to quote me, I do not speak." -- Phil Wayne

Working...