Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
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? More

Steve Jobs thinks Objective C is Perfect?

Comments Filter:

  • namespaces (Score:4, Informative)

    by Anonymous Coward on Monday December 26, 2005 @12:04PM (#14339897)
    Anyone claiming a language lacking proper namespace support is "perfect" is nothing short of delusional.

  • The emails are already gone. (Score:5, Informative)

    by CapnRob ( 137862 ) on Monday December 26, 2005 @12:05PM (#14339900)
    He's already taken down the emails in question, apparently having had second thoughts about the appropriateness of posting private emails.

    • Re:The emails are already gone. (Score:4, Informative)

      by Knytefall ( 7348 ) on Monday December 26, 2005 @04:40PM (#14341270)
      Here are the emails:

      From: Nitesh Dhanjani
      Subject: Re: Will XCode+ObjC ever suck less?
      Date: December 25, 2005 5:27:02 PM CST
      To: sjobs@apple.com

      I look forward to the improvements! Thanks,

      Nitesh.

      On Dec 25, 2005, at 5:10 PM, Steve Jobs wrote:

      I guess we disagree. First of all, .NET with CLI and managed code runs SLOW, so most serious developers can't use it because of performance. Second, the libraries in C# are FAR less mature and elegant than those in Cocoa. We are working on a better implementation for garbage collection than we've seen out there so far, but in the end its a performance hit and an unpredictable time that is not good for some kinds of apps.

      Steve

      On Dec 25, 2005, at 2:36 PM, Nitesh Dhanjani wrote:

      Objective C is old and clunky. Its almost 2006, and I _still_ have to look out for yucky pointers? I'd love to be able to write native apps with Ruby (or even C#!.) There are open community projects in progress that are trying to bind ruby and C# (mono) with Cocoa, but I'd love for Apple to step in and make this happen faster. Today, Microsoft seems to be _way_ ahead of the development curve - with their .NET implementation, you are allowed to code using a plethora of languages (C#, Python, VB, etc), as long as the interpreter/compiler follows the IL specification - pointers don't matter, garbage collection is done for you - ah the beautiful world of managed code.

      Having said that, most native OSX apps are still beautiful and well designed. Imagine how much better we could do if the developers had a more flexible choice of languages? I can _bet_ you a lot of OSX app developers use Objective C because they have no other choice.

      Nitesh.

      On Dec 25, 2005, at 3:11 PM, Steve Jobs wrote:

      Actually, Objective C is pretty great. Its far nicer than most other ways of writing apps. What don't you like about it? What do you like better?

      Steve

      On Dec 25, 2005, at 11:59 AM, Nitesh Dhanjani wrote:

      Hi Steve

      Will it ever be easy to write native OSX GUI apps? Objective C sucks.

      Thanks,
      Nitesh.

      • Re:The emails are already gone. (Score:5, Insightful)

        by Yaztromo ( 655250 ) on Monday December 26, 2005 @05:48PM (#14341550) Homepage Journal

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

        Yaz.

      • I read through this and suddenly I asked myself, do I walk back in time, or is something wrong.

        But sadly Top posting is so common nowadays, that managers complain if you don't do. Last time I normaly answered an email to an management person in our office and he complained later why my answer was not on top like "normal" people do ...

        oh where there world went thanks to preset outlook settings ...

      • The Real Irony (Score:3, Interesting)

        by Reverend528 ( 585549 )
        The real irony here is that Steve Jobs is calling Garbage Collection "slow" despite the fact that Apple sells a micro-kernel based OS. I know that microkernel-based OSes can be shown to be just as fast as monolithic kernels, but that takes a LOT of work to achieve (more than just kludging BSD onto Mach).

        Most well-designed programming languages allow code that can be optimized to reduce the amount of garbage generated. For the things where speed really matters, it can sometimes be possible to prevent the

      • Re:The emails are already gone. (Score:5, Interesting)

        by soft_guy ( 534437 ) on Monday December 26, 2005 @08:31PM (#14342202)
        I'm sorry, but I have to agree with Steve and completely disagree with Mr. Dhanjani. I think that the language "choice" on .NET is silly - you can use whatever language you want so long as the language has exactly the same features as C#. For example, look at the feature set of "managed C++". No multiple inheritance and other non-C# features have been removed. Same for other languages.

        I program with Objective-C and Cocoa all the time. I am mostly happy with it and in fact I will not be using the Garbage Collection feature for my apps.

        I have complaints about Cocoa, but not being able to program in Ruby or Python is NOT one of them.

  • objective-c is cool (Score:3, Informative)

    by matt4077 ( 581118 ) on Monday December 26, 2005 @12:05PM (#14339902) Homepage
    I develop with both objective-c and c# and while I like the c# syntax and gc better, Interface Builder is the most elegant way of user interface programming out there.

    • Re:objective-c is cool (Score:4, Interesting)

      by spectre_240sx ( 720999 ) on Monday December 26, 2005 @01:32PM (#14340330) Homepage
      I hear that constantly, but actually it's the biggest thing that turned me away from Cocoa programming. I'm far from a professional coder, but I just can't get my head around building interfaces and connecting them to the code with all of these menus. I'd much rather just write the code myself. Maybe after working with it for a while I'd learn to like it, but it made it hard for me to get into it and I ended up going for Java instead.
      • 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.

  • Making it "fun" (Score:4, Funny)

    by Rude Turnip ( 49495 ) <valuation@@@gmail...com> on Monday December 26, 2005 @12:05PM (#14339903)
    "I agree with Dhanjani. What has Apple done recently to wow the developers, and make it fun to code Cocoa components?"

    What, a fun and whimsical name like "Cocoa" isn't enough for you? Perhaps you'd prefer to code in puppies and rainbows?

    • Re:Making it "fun" (Score:5, Funny)

      by tomcres ( 925786 ) on Monday December 26, 2005 @01:20PM (#14340265)
      Actually, if you pronounce the word "Cocoa" a certain way, with the accent on the second 'o,' it sounds like a Portuguese word meaning, well, to be polite, "excrement." You should have seen the look on my wife's aunt's face (they are from Angola) when we were walking through the cereal aisle of the supermarket and she saw "Cocoa Puffs." :-)

  • Love it (Score:5, Informative)

    by Richard_at_work ( 517087 ) on Monday December 26, 2005 @12:06PM (#14339905)
    Sure, Xcode could do with a little bit of work to add features missing, but I truely find Cocoa a dream to work with. One year ago I only developed for the web, then I bought a Mac and was introduced to Cocoa by a friend. I havent looked back since, and have produced several 'scratch the itch' applications that otherwise wouldnt have been made.

    • Re:Love it (Score:5, Interesting)

      by rplacd ( 123904 ) on Monday December 26, 2005 @12:31PM (#14340001) Homepage
      On the other hand, after several years of writing code in mostly python and other similar languages, the thought of going back to something like C (pointers!) doesn't really motivate me to write code for my mac. It's a good thing there are bridges like py-objc and such.

      (Disclaimer: I first became aware of Objective-C about a decade ago, and have used IB/etc on Openstep -- on a NeXT slab, even).

      • Re:Love it (Score:4, Insightful)

        by jiushao ( 898575 ) on Monday December 26, 2005 @03: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".

      • I don't understand why people hate pointers. Is it the fear of memory math? What's going on? Because pointers have a ton of advantages. Make it easy to save memory, and also make it easy to allow generic function prototyping through function pointers.

        Function pointers are probably my favorite thing about low-level languages (and even a few higher-level languages that provide such support).

        • 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.

      • Re:Love it (Score:5, Interesting)

        by Yaztromo ( 655250 ) on Monday December 26, 2005 @05:45PM (#14341540) Homepage Journal
        On the other hand, after several years of writing code in mostly python and other similar languages, the thought of going back to something like C (pointers!)

        If this is what is keeping you from developing with Objective-C, then you've picked a poor reason to avoid learning it.

        Pointers are as easy to avoid in Objective-C as they are in Java. In Java, all reference types are in fact a pointer, but simply a pointer which you don't need to think about. There is no pass-by-value for reference types, and no pointer arithmetic is allowed.

        In Objective-C, everything is again passed by reference (as opposed to by value). Pointer arithmetic is generally completely unnecessary (although it is technically permitted).

        I recently finished v1.0 of a decent sized Objective-C application, and the "&" operator isn't used once. The '*' operator is only used when defining a variable, return type, or parameter.

        I don't even think of pointers when coding in Objective-C. I tend to think of it as no different than Java. Extra capabilities to do pointer arithmetic are there, but I simply don't typically feel the need to use any of them.

        Yaz.

  • well... (Score:4, Insightful)

    by soapdog ( 773638 ) on Monday December 26, 2005 @12: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...

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

      by Rew190 ( 138940 )
      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.

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

        by ceoyoyo ( 59147 )
        Use Python. No memory management necessary. With the pyObjC bridge you can do anything you could do in ObjC.

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

      by Frizzle Fry ( 149026 )
      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?
    • With programming, the correct cliche would be "evolve or die". Yes, it's true that "good enough" systems can stay around forever and ever and ever in programming, but it's also true that this only tends to happen if the system gets established. Apple is not established, they are still in a position of attempting to sell Cocoa to others. Worse, Apple is competing directly against one clearly-thus-inspired platform which attempts to replicate Apple's functionality (Java), and against another clearly-thus-insp

  • between himself and Steve Jobs (Score:5, Funny)

    by Dachannien ( 617929 ) on Monday December 26, 2005 @12:08PM (#14339913)
    posted an e-mail thread between Steve Jobs and himself.

    I always knew Steve Jobs was just a little bit crazy.

  • It's not like they're not doing anything (Score:5, Informative)

    by Anonymous Coward on Monday December 26, 2005 @12:09PM (#14339915)
    The development environment is hardly static. Key-value-observing and bindings, Core Data; we get more toys for every system version and they are working on adding garbage collection to Objective C.

  • Wowing developers... (Score:3, Interesting)

    by Svartalf ( 2997 ) on Monday December 26, 2005 @12:13PM (#14339929) Homepage
    While wowing the developers is important, also providing them with a high performance, high reliability, and easy to use framework is important as well- moreso than wowing them. It does no good if it's "cool" to develop for a programming language, etc. if I'm spending 2-3 times the coding time for the other one or 2-3 times the debugging time, etc.

    C#, for all of the claims of performance, is a a JIT based interpretive language. Ditto Java.

    C#, for all of it's nicety, is little more than Java taken in MS' desired direction. If it weren't for Mono, C# wouldn't even be a subject of discussion as it'd been an MS only tool for use only on Windows (or whatever MS ends up calling thier stuff in the future...)

    C, C++, and Objective-C are stable, robust languages that have been around for some time now. C# has not been around all that long, but since it's got all the "buzz" about it, people keep trying to deploy it everywhere.

    Objective-C is actually a fairly clean OO language, moreso than C++. C++, while it's really good, has been muddied up with a bunch of conflicting design ideas that make for some...fun...with your coding if you're not paying attention to what you're doing.

    All in all, I'd say that it's decent enough for doing Apple development- if you want to adapt Mono to that interface (Which, I believe, can be done...) knock yourself out.

    • Re:Wowing developers... (Score:4, Insightful)

      by Rew190 ( 138940 ) on Monday December 26, 2005 @12: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:Wowing developers... (Score:5, Informative)

        by coolgeek ( 140561 ) on Monday December 26, 2005 @01:17PM (#14340251) Homepage
        Memory management in Obj-C is really simple, and making issue of it is an extreme exaggeration. You merely have to follow the rule of "if you allocate it, you're responsible for it", and make sure to either send it [obj autorelease] upon allocation or [obj release] in the [parent dealloc] routine. It really is that simple. Maybe that's too much to ask of the sissy programmers coming out of school these days.
        • 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.

        • Re:Wowing developers... (Score:4, Interesting)

          by Leimy ( 6717 ) on Monday December 26, 2005 @05:35PM (#14341506)
          Non-sissy programmers make mistakes that can let in all sorts of problems with buffer-overruns and other fun vulnerabilities. C is a terrible language for trying to write "secure" or "safe" code.

          I'm not saying C is bad for all situations. I just wouldn't use a saw to drive a nail.

          By the same token I try not to find problems for my solution.

          It may be very simple to do the refernce counting by hand, I'm just saying that it's possible to do a lot of this stuff automatically in a language design. See Limbo. It even has a way to get out of dreaded cycles that cause reference counting to leak memory [a cyclic keyword]. It's a shame Limbo only really works with the Inferno OS.

          Also C++ has libraries of things like shared_ptr that do the reference counting in the constructors and destructors of the object. It also can suffer from the cyclic reference leaks of course but the need to double check code or even suspect it of being wrong at the "use" level is greatly diminished.

          At the end of the day it's worth noting that no language is perfect, and just knowing the syntax doesn't make you a good coder. It takes practice... and just having a degree in CS isn't gonna make you great.

      • Re:Wowing developers... (Score:5, Insightful)

        by Durandal64 ( 658649 ) on Monday December 26, 2005 @01: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.

      • Re:Wowing developers... (Score:3, Informative)

        by ceoyoyo ( 59147 )
        Python. There you go. Have fun! Oh, don't forget to install PyObjC or you may be disappointed.

        Note: Apple didn't come up with it. Neither did MS. It's open source. Apple employees have a lot to do with PyObjC though, which is also open source.

    • Python (Score:3, Informative)

      by truthsearch ( 249536 )
      There's also a Python bridge for Obj-C. So for those that prefer a very different language, with its interpreter already distributed with the OS, Python's a great option. You get the native objects exposed by OS X available to Python.

      And let's not forget OS X is built on top of BSD. So effectively anything which can be written for BSD can be written for OS X. There are, of course, limited GUI tools, but options are available. Qt libraries, for example, will display native GUI elements when possible.

  • .NET is a bit complex (Score:5, Interesting)

    by netwiz ( 33291 ) on Monday December 26, 2005 @12:17PM (#14339945) Homepage
    Personally, I prefer Obj-C to .NET, mostly due to the (IMO) superior organization and layout of the object model. It's simpler than .NET's API, which tends toward "everything and the kitchen sink." Not that Cocoa doesn't have it's problems. It's probably more difficult to write big projects using it, but for quick development, I find it faster to just throw something together in Xcode. Besides, it doesn't hurt that Xcode and it's related dev tools are free on OSX, whereas it's a $600 investement on Windows for the equivalent software.

    A good example of the complexity is the file access models for both APIs. .NET has something like three different objects to deal with different types of file access. Cocoa implements these in a single object with multiple methods for the data access style (streaming, read the whole thing once, etc.) Now, it's probably just personal preference on my part, but why invent multiple objects when you could just roll them up as separate methods for what is essentially the same data structure? There's probably a reason, and I'd be interested in learning why this is so, but it just seems to me that Cocoa did it right in the first place.

  • the Wow factor. (Score:5, Insightful)

    by revery ( 456516 ) <charles@cac[ ]et ['2.n' in gap]> on Monday December 26, 2005 @12: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.

    • It's not like Obj-C doesn't have a wow factor anyway. For starters you can create basically the entire interface of an application without writing a line of code by using bindings. What's even better is you know you will never see a crash in that code and it acts how a normal Mac OS X app should work removing tons of testing and freeing you up to do cooler things to sell your application. Secondly the ability to rapidly prototype a working application using the above glue code and the already built object

  • Objective C is hard to beat (Score:5, Insightful)

    by brindle ( 8241 ) on Monday December 26, 2005 @12: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

  • Learning ObjC/Cocoa (and others) now... (Score:5, Interesting)

    by piyamaradus ( 447473 ) on Monday December 26, 2005 @12:22PM (#14339966)
    As an old-school programmer (20+ years of Fortran, C, various assembly languages, C++ many many years ago), who's spent the last dozen years or so focused almost exclusively on server-side high-performance networking systems (in other words, heavy-duty C/Unix/threading), I've taken my 'spare time' in the last few months to teach myself ObjC/Cocoa, Java, and some of the .NET technologies. I found it unfortunate that Apple deprecated Java + Cocoa in the last XCode release -- not because I particularly enjoyed Java but because it was easier to learn both Java and ObjC at the same time when I could be doing the same things with it.

    Comparing ObjC to what MSFT offers nowadays seems to be apples and oranges (no pun intended) and the learning curve is much different -- coming from straight C, ObjC is much cleaner, and I can slide more extensive Cocoaization in as I go. On the other hand, the ObjC syntax is a mess and weird for people who've never done Smalltalk ... and I'm guessing the set of people who have is extremely small nowadays.

    As for development environments, so far I've _hated_ everything to do with visual * -- it seems to be a monster to use, to customize, and to work with efficiently, at least for this old Unix hack. XCode is far far far from perfect -- I wish the SCM integration were better, that the whole thing were a _lot_ faster, and that they'd release incremental documentation updates rather than 250M batches every couple weeks -- but since it's all wrapped on gcc/g++/gdb/make at the back end, you can entirely do your stuff with vi/emacs/whatever at the command line and never use the GUI much at all, if that's your preference...

  • Network Mirror (Score:4, Informative)

    by BushCheney08 ( 917605 ) on Monday December 26, 2005 @12:25PM (#14339982)
    Network mirror still has the original blog post up. [networkmirror.com]

  • Dev tools plus/minus (Score:5, Interesting)

    by boatboy ( 549643 ) on Monday December 26, 2005 @12:26PM (#14339985) Homepage
    As a .NET developer, I haven't looked too hard at Mac dev tools, but I will say I could see an argument that Microsoft's rich development environment has some unexcpected consequences. Microsoft has made it easy for just about anybody to pick up software development, and as a result, just about anybody has picked up software development. =)

    This can be good, but a downside is that some of the emphasis on design, best practices, etc. is lost. An office nerd who happens to get into VB is not traditionally pushed to think about things like standard UI guidelines. So in a sense the rich toolset can detract from good software. MS seems to be aware of this, and you can see a definite push for more guidance from them. Still, they have a ways to go IMO, and finding the balance between making development easy and making it "good" is difficult.

  • Xcode rocks. (Score:3, Interesting)

    by wangmaster ( 760932 ) on Monday December 26, 2005 @12:26PM (#14339986)
    There are legions of NeXT fans that would disagree with your statement regarding .NET. The Interface Builder component has always been considered one of the most elegant, easy to use, intuitive UI constructing tools out there. It does what it needs to do, is well integrated into the rest of the tool (and the language) and just plain rocks. I have yet to use a UI layout tool that comes near the ease of use and effectiveness of InterfaceBuilder.app. When it comes to Xcode (or ProjectBuilder.app as the old NeXT fans were used to), it's also an intuitive, easy to use project management system. I don't like IDEs, I hate IDEs. I prefer vi/vim to do all my code editing. The nice thing about ProjectBuilder in old days (I'm not sure about Xcode, I haven't had the opportunity to do much with my mac mini yet) was that it did what I needed (collect all my files in a nice visual fashion, manage my building and integration with UI components, and built skeleton files). It does all those things well, without forcing the user to be hampered by some built in editor components. There are legions and legions of developers out there that consider the NeXT development tools to be the ultimate developer toolkit (and objective c is a pretty nice language). It's nice to see it didn't disappear into history :)

  • Every time the ObjC/C++ discussion comes up... (Score:5, Insightful)

    by squarooticus ( 5092 ) on Monday December 26, 2005 @12: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.

    • Re:Every time the ObjC/C++ discussion comes up... (Score:5, Insightful)

      by penguin-collective ( 932038 ) on Monday December 26, 2005 @02: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.

  • Mangaged code good | .Net / Mono Bad (Score:3, Interesting)

    by bhima ( 46039 ) <Bhima.Pandava@[ ]il.com ['gma' in gap]> on Monday December 26, 2005 @12:37PM (#14340034) Journal
    The idea that the OS X development environment should include the option of using managed is code is fine (although I shudder to think just how much work this truly encompasses). But I haven't yet seen the real benefit of using .Net or Mono while I have successfully used Objective C.

    I think sometimes we get caught up in the tinkering with latest wizbang language and loose sight of the fact that if we simply paid attention and used the languages we already know we could solve whatever we are programming much simpler.

    Over the winter break I have run into two miserable examples of this...

    ONE the program Autopano-sift (100% managed C# code developed using mono) This program does nothing couldn't be done in C++ and little that couldn't be done in C. I've lost count of the megabytes I've downloaded to access the functionality of a program that has no cause to occupy much over a half meg... it's like having the bloat of windows and the user friendliness of circa '92 Linux all at the same time.

    TWO Canon and the "software" that accompanies their cameras, specifically the 350D AKA Digital Rebel XT. I am very interested in controlling that camera by computer (any computer) so I have also signed up for their development program. So I can tell that all of the canon software that came with my camera was developed with the current version of Microsoft Visual Studio and also uses the SDK canon uses to obfuscate the camera's true API. Because of the user interface and some truly bizarre design decisions this is the worst software I have ever installed on any of my computers. With the possible exception being Arcsoft's image management application which was also included. I must admit, I have seen Arcsoft's applications before and while technically they work... the user interface is so poor and has such arbitrary limitations as to make it unusable, so this is not really surprising. Bottom line... sending a few hundreds of kilobyte of data through a USB should be easily accomplished by an 8 bit Microcontroller mounted on a board the size of my thumbnail... and IT IS NOT... thanks to manged code.

  • Jobs doesn't get it (Score:3, Insightful)

    by NutscrapeSucks ( 446616 ) on Monday December 26, 2005 @12: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".

    • 100% agree (Score:3, Insightful)

      by bani ( 467531 )
      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 i

  • Can't go home again (Score:4, Insightful)

    by TapestryDude ( 631153 ) on Monday December 26, 2005 @01: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.

  • Notes from a Cocoa AND .NET developer (Score:4, Informative)

    by hkb ( 777908 ) on Monday December 26, 2005 @01:40PM (#14340372)
    I code various C#/.NET things at work, and code Cocoa stuff at home for fun. I'm well-versed in both environments.

    - The environments are apples and oranges (no pun intended). The languages, the workflow, everything is much different.

    - Moving away from ObjC would require some significant reworkings of Cocoa, as its workflow is based on the "ObjC way". Take a look at the mess that is the Cocoa/Java bridge, or Cocoa#.

    - Objective C is WAY more descriptive than other languages (take a look at how you pass arguments in functions, for example).

    - Objective C is easy to learn. Yeah, it's a lot different than the usual paradigms, but when you learn it, you'll enjoy its simplicity.

    Things I hate about Cocoa:

    - It's not managed code. Why should application developers in this day and age have to worry about memory management? (autorelease doesnt count)

    - Having to keep two different programming paradigms in my head. I never even learned C#, I learned Java and jumped right into C#, because they were so similar.

    - Practically no one else in the world uses Objective C, so it's not a very valuable (salary-wise) skill to have.

    - The X-Code/Interface Builder dance is quite clunky. It was cool back in the day, but Microsoft has a much better system developed.

    - VS.NET 2005 > Xcode

  • Comment removed (Score:3, Interesting)

    by account_deleted ( 4530225 ) on Monday December 26, 2005 @01:48PM (#14340429)
    Comment removed based on user account deletion

  • ObjectiveC and Cocoa (Score:3, Interesting)

    by macpeep ( 36699 ) on Monday December 26, 2005 @01:56PM (#14340481)
    I've been programming since I was 7. I've done Basic, Pascal, C, x86 assembly, Modula 2, SML, C++, Java, plus a large bunch of scripting languages. I've programmed for the Java VM (ME, SE and EE), Amiga, DOS, 16 and 32 bit Windows, most UNIX variants and a large number of mobile OS's including Symbian, PalmOS and Windows Mobile.

    When I got a Apple PowerBook, my intention was not to use it for programming. ObjectiveC and Cocoa was totally irrelevant for me and I didn't bother to learn it. That is, until one evening when I decided to just take a look at some of the ADC docs included with XCode. After reading for about an hour, I was very surprised. It couldn't possibly be this easy and straightforward. It felt like it Cocoa must be seriously limited in functionality. The API was so easy and so compact, and ObjectiveC was like a halfway mix of Java and C++. I bought a book on Cocoa and read through it in about a week. It covered everything from basic GUI programming to drag and drop, printing with pagination, OpenGL, making custom widgets, data binding and persistence, preferences, making and using frameworks (think DLL's), and so much much more. And all of this was amazingly simple compared to any other OS and language combo I had ever used. And not just easier, but dramatically easier.

    As an example, the chapter on drag and drop was something like 5 pages and covered making drag sources, drag targets, controlling the icon you see while you drag, data flavors, and so on. The classes involved were all extremely simple, easy and intuitive. Printing is even easier!

    I haven't really had any need to do any apps of my own lately, so admittedly I haven't used Cocoa for anything in particular other than simple test applications, but I'm thoroughly impressed!! I would give about 80% of the credit to Cocoa, and 20% to ObjectiveC. You can use Cocoa with Java too, but it seems a tad bit more compatible and elegant with Cocoa. Also, looking at the more recent API's like CoreImage, it seems there's more and more functionality in the Cocoa family of API's but the simplicity remains. I strongly recommend picking up ObjectiveC if you know C++ or Java!

    Peppe

  • better solution (Score:4, Informative)

    by penguin-collective ( 932038 ) on Monday December 26, 2005 @02:03PM (#14340523)
    The next generation Objective C and Xcode already exist: Smalltalk and Smalltalk programming environments.

    Smalltalk is a language with Objective C's object model, but runtime safety, garbage collection, and reflection. Objective C was an attempt to create a very low overhead version of Smalltalk that would interoperate more easily with C code, but most of the technical reasons for making the compromises that were made in the design of Objective C are gone.

    The only thing that would need to be done would be to extend Smalltalk with a notion of "native" or "unsafe" methods; that has been done multiple times before, and it can be done either by permitting C code to be embedded in Smalltalk (reversing the Smalltalk/C situation from Objective C) or by defining a Smalltalk subset that's close to the machine (as Squeak has done).

  • Apple blew off Metrowerks. Now they must suffer. (Score:3, Interesting)

    by Animats ( 122034 ) on Monday December 26, 2005 @02:33PM (#14340672) Homepage
    Metrowerks was there for Apple when all Apple had was MPW, which was a clone of the UNIX Programmer's Workbench, circa 1979. Metrowerks made the PowerPC transition possible. And recently, Apple made it hard for users of the Metrowerks environment to convert their programs.

    Metrowerks offered a stable, reliable development environment, even as Apple was frantically moving from one development platform to another. (Use Rhapsody! Prepare for Copeland! Use OpenDoc! Dump OpenDoc! Use Carbon! No, use Cocoa! Use OpenStep! Use Objective-C! Switch to XCode!.) Each time Apple pulled one of these stunts, more developers dropped their platform.

    • Re:Apple blew off Metrowerks. Now they must suffer (Score:5, Informative)

      by theAtomicFireball ( 532233 ) on Monday December 26, 2005 @02:57PM (#14340804)
      Well, Copeland and OpenDoc are pre-Jobs Apple, so go yell at Amelio or Sculley about those two.

      On the rest of it, Apple never made a blanket "use Carbon", or "use Cocoa" claim. They said, consistently, to use Carbon if you have a lot of legacy toolbox code, and to use Cocoa if you were starting a project from scratch or were bringing things over from NextStep. OpenStep is just the old name for Cocoa and Rhapsody is just the old name for OS X, so you're kinda overstating your point just to make it look more schizophrenic than it really was.

      Metrowerks was in it for the money just as much as anyone else; they weren't "there" for anybody but themselves (and later, their shareholders). Once Metrowerks released a Windows version, they stopped giving the Mac priority and the tools stagnated. Apple inherited a perfectly good IDE from NeXT and Metrowerks gave no indication that they were chomping at the bit to upgrade their tools in a urry so that developers could be ready when OS X came out. Metrowerks wanted to play it cautious and didn't want to gamble on Apple's transition to OS X, so what else was Apple to do? I've met relatively few people except a few cranky old Toolbox guys who didn't want to make the transition to OS X, who aren't happy with Apple Developer support compared with what it was historically. The Inside Macintosh books used to cost an arm and a leg and weren't available in soft editions, MPW was a nightmare, as you stated, and the only other way to create applications was to buy third party IDE.

      Life has been pretty good (not perfect, but pretty good) since Apple bought NeXT. It's been tumultous at times, but has steadily been heading in the right direction, and as a matter of fact, developers have not been leaving the platform in droves; there has been a well-documented and steady increase in the number of developers using OS X as their primary platform.

      I'd hardly say they're "suffering".
    • 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.

  • Don't ruin Steve, please (Score:5, Insightful)

    by hkb ( 777908 ) on Monday December 26, 2005 @02: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.

  • ObjC problems are many (Score:3, Insightful)

    by I'm Don Giovanni ( 598558 ) on Monday December 26, 2005 @03: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:ObjC problems are many (Score:5, Interesting)

      by theAtomicFireball ( 532233 ) on Monday December 26, 2005 @03:38PM (#14341012)
      Many of your complaints with the language seem to be much more a "it's different from other things, therefore wrong."

      Namespaces is the one I see foisted around the most. I can see some value to adding namespace, but not enough to muck up the language. Objective-C was designed to be the simplest wrapper around C as possible while enabling an OO approach. With the much flatter hierarchies Objective-C's weak-binding and dynamicism encourage, the lack of namespaces is a relatively minor thing. Some people want them, but there's really no compelling need for them. I, for one, am glad that Objective-C has avoided the "throw in everything but the kitch sink" approach that has caused C++ to bloat in recent years.

      Abstract class support? Again, why? The language doesn't need this. Objective-C's approach is to trust that the developer knows that he or she is doing. It doesn't take the paranoid approach that C++ and Java and the other Modula-3 inspired languages do, but that's not a flaw, it's a design choice. Objective-C is bad for stupid programmers, that I'll readily admit.

      All methods are public, but they don't have to be advertised in your header file. Again, it's the nature of the language, and the result of a conscious design choice, not a flaw. You don't need this, even though many programmers have been indoctrinated into thinking they do.

      I give you some points on the constructor issue. A language-level support for the DI or an official "constructor" method would be a good addition and add relatively little to the language and runtime. Garbage Collection is not something I personally want, but I know many people do; it's in the works. GCC 4.0 has support for it, it just hasn't been fully integrated into Cococa yet. Probably with the next release (is it Puma? I can't even remember all the cat names any more).

  • Categories (Score:3, Interesting)

    by vandel405 ( 609163 ) on Monday December 26, 2005 @05:19PM (#14341425) Homepage Journal
    Categories are *the* best feature of Objective-C. They let you keep problems object orrient when subclassing isn't avaiable. Simple example. Say you're working with a class library that exports a string class, and that string class doesn't have a 'spit/explode' function. In languages without categories you would write a static method some place, or a method on some unrelated 'toolbox' class that takes a string and splits it. In objective-c, you can just put a category on string that is a split method. This way the string is doing the split. If you later hve some subclass of string that can do a more efficent split, well override split, dont' swtich on the class type in your static method. YAY OO.

    I hinted on a much more important feature above. When you have to work with many objects that you know little about, categories are awesome. Take GORM for example. GORM should integrate with many flavores of objects but it really only knows a lot about a couple of base-classes. Classes like view, object, and window. GORM might need to know if a view acts as a container. To do this, it might put a category method on view called 'isContainer'. It could return NO by default and be overrided in all containers to return YES. Now when working with a view, GORM just has to say [view isContainer] to find out if the view is a container. This is much better than looking asside in some table, or manually coding up the reflection hack that would be nessecary to ask such a question in other statically bound/typed languages.

Slashdot Top Deals

1 Word = 1 Millipicture

Close