Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

What Did Objective-C Do Wrong? 15

Dixie_Flatline asks: "Okay, I really don't understand it. I've looked at C++ and C# and I don't understand what ObjC must have done wrong to be losing out to the likes of them. It's got only a few syntax additions to C, but is actually fully object oriented, unlike C++. My only hope for ObjC right now are the GNUstep project (which really isn't high profile enough) and MacOS X (which is fine with me...it's like having my NeXT resurrected). But why hasn't ObjC just caught on on its own?"
This discussion has been archived. No new comments can be posted.

What did Objective-C do Wrong?

Comments Filter:
  • It's still got more press than ObjC does. If and when it finally comes out, I'm sure more people will be using it than ObjC. For all intents and purposes, ObjC has already lost any sort of "battle" with C#. It won't be on the merits of the language that C# is picked, I'm sure, but rather the backing that it has, like you said.
  • I stand corrected.
  • I utterly fail to understand how you got a score 2 on your posting. The question was about Objective C, which is quite a different beast than C# and has been around for quite a few years. Actually, the whole GnuStep project is centered around this language.
  • While the language also supports the old-C style of [] for arrays, int, float, double and so on, it does have NSArray and NSNumber.

    So I guess what you are really saying is that it didn't catch on because it offered too much backward compatibility?

  • by CentrX ( 50629 )
    I don't see why you think C# has caught on, it really hasn't, and if it does, it's because MS is behind it.

    Chris Hagar
  • by CentrX ( 50629 )
    "I've looked at C++ and C# and I don't understand what ObjC must have done wrong to be losing out to the likes of them."

    Chris Hagar
  • 4. The world hadn't (yet) decided that C++ was a bad idea.

    A bit of a sweeping statement, don't you think? Care to elaborate?

    "...the programming world discovered the true horror of multiple inheritance, templates, and all the other landmines that lurk beneath the surface of C++. "

    Hmm, if you don't like those features of C++, or don't understand them, just don't use them. Lots of programmers have used those features very successfully in C++ programs. Quite a few may have met disaster using them too though ;-)

  • I would hesitate to say "C++ programs link to static programs that don't require anything extra". C/C++ also has a run-time library that needs to be linked into your program, regardless of whether you use the C/C++ standard library. On the Windows platform, I believe the C run-time is MSVCRT.DLL; with GCC, it is libgcc. The run-time library is compiler- and/or operating-system-specific.

    Most programming languages have some kind of run-time system. Some run-time systems are fairly complicated, e.g. the Lisp run-time is actually an interactive program, not just a library.


    Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
  • You should read Richard Gabriel's article Lisp: Good News, Bad News, and How to Win Big [naggum.no]. The gist of the article (paraphrased or cut-n-pasted from the article) is that:

    • "The worse-is-better philosophy means that implementation simplicity has highest priority, which means [such systems] are easy to port on machines that are worse than median (smaller or slower)."
    • "A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using [this] approach will work well both in small machines and large ones."
    • "There is a final benefit to worse-is-better. Because a New Jersey language and system are not really powerful enough to build complex monolithic software, large systems must be designed to reuse components. Therefore, a tradition of integration springs up."

    These points apply well to Objective-C in comparison to C/C++, and you would do well to at least read section 2.1 ("The Rise of Worse is Better") to see Gabriel's point.


    Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
  • First off, I agree with almost everything you wrote. I also agree with your main point - C++ won because it didn't require you to write in OOP. I'm just going to nitpick some things here

    One of C++'s selling points is that you can trivially call C++ from C functions. You can trivially call C from C++ functions. Mix-and-match as much as you like. Heck, you can even write C++ code in C.[*] You can't do that with Objective C. [**]

    Assuming that you are using an Objective-C compiler, you can easily mix C and Objective-C. You can easily call Objective-C methods from C. Look at the main.m file for any GNUstep or OSX project, and the first line in main() is a call to an Objective-C class. And you most certainly can call things like printf() from Objective-C.

  • ObjC doesn't remove anything from C. C-style arrays are not object oriented, you are correct. Furthermore, numbers aren't object oriented either, right again.

    However, the *objective-C* additions to C are *fully object oriented* as correctly stated in the original post. It has a dynamic runtime as flexible as Perl's and can cope with extremely complex dynamic binding, which C++ and Java can't do without massaging. It has polymorphism, inheritance and encapsulation. It goes one stpe further than Java and C++ (and most other OO languages) by having the concept of "Categories", which is one of the best things you could ask for when working with pre-built frameworks.

    In short, it's a SUPERB language that is trivial to learn and very flexible.

    GO LEARN IT! Warning: it'll make you HATE Java.
  • Objective-C is, in and of itself, a wonderful langauge, but comes with very little functionality. Even many of the fundamental object capabilities depended on NeXT's FoundationKit et al, which for a long time, was only available in Nextstep, and just before NeXT's assimilation by Apple, in Openstep, which was Nextstep's libraries licensed to other vendors.

    The GNUStep [gnustep.org] project is trying to get these libraries up to speed, meeting and in some cases exceeding the OpenStep specs, but without them, it is very difficult to develop in Objective-C on any platform but NextStep or that rare zebra, OpenStep for Solaris.

    For more info on GNUStep, I suggest looking at newsWire [current.nu].

  • by andyturk ( 92537 ) on Monday August 14, 2000 @10:42AM (#858970)
    #ifdef SLAM
    If you never used Objective-C for anything more than a college project, then you're probably not qualified to explain why it never caught on in a production environment.
    #endif

    I spent 7 years in the NeXT world both writing code personally and running a company that developed software for the platform.

    Here are my reasons why Objective-C never caught on:

    1. It was *perceived* as being too slow.

    The reality was that if you used objects at a very low level, there'd be a performance hit. If you used objects at a high level, like with NeXT's wonderful ToolKit, it was fine. Objective-C was never meant to be used for system programming. The "it's too slow" FUD stuck really well though.

    2. There weren't any other Objective-C libraries other than the one that NeXT wrote.

    The NeXT ToolKit was incredibly well thought out--it was a very productive platform to write code for. But that didn't help you if you were writing code for X11 or Windows or the Mac.

    3. While "better" than C++ in many respects, Objective-C didn't offer enough benefits to convince people to abandon the (huge) effort they spent learning C++.

    For better or worse, C++ is what educated most of the world to the benefits of OOP. Objective-C offered more OOP benefits, but was perceived as poor cousin. Since the value of a language is proportional to the amount of code written in it, this was probably accurate.

    4. The world hadn't (yet) decided that C++ was a bad idea.

    Long after NeXT ceased to be a factor in the workstation market, the programming world discovered the true horror of multiple inheritance, templates, and all the other landmines that lurk beneath the surface of C++.

    Summary

    Objective-C was cool, but the real value only came through using the libraries that NeXT wrote. Without a useful API, even a fine language will starve.
  • by rjh ( 40933 ) <rjh@sixdemonbag.org> on Sunday August 13, 2000 @09:53PM (#858971)
    Warning: this is the rant of a long-time C++ hacker who hasn't looked at Objective C since he was in college.

    PERFORMANCE

    Objective C was, at the time it was introduced, dog slow. This was due to its "cleaner" design and the way it delayed as much as possible until run-time (both of which are, arguably, the Right Thing). C++, on the other hand, had (and still has) an extremely strict philosophy: you don't pay for what you don't use. If you don't use templates, you don't incur the overhead of them. If you don't use virtual functions, you don't incur the overhead of them. If you don't use <foo>, you don't incur <penalty of foo>.

    CODE REUSE

    Objective C invalidated an awful lot of existing C code. Now, Objective C's defenders will say "... it did no such thing! My program still compiles just fine under C, just as it does under Objective C!" With due respect to them, that's not the point.

    One of C++'s selling points is that you can trivially call C++ from C functions. You can trivially call C from C++ functions. Mix-and-match as much as you like. Heck, you can even write C++ code in C.[*] You can't do that with Objective C. [**]

    Objective C required a vast change in how programs were written (see below). C++ offered a slower, smoother slide into the world of OOP.

    CONSTRAINED PARADIGM

    C++ is, contrary to popular belief, not an object-oriented programming language (OOPL). Objective C is an OOPL. [+] This is another major reason why C++ won out.

    C++ is equally at home with procedural programming, object-oriented programming, generic programming--heck, I've even seen functional programming done in C++ (admittedly, it was a nasty hack, but...). People who loudly trumpet C++'s object-oriented capabilities are, with all due respect, totally missing the point. Personally, I find generic programming to be much more breathtaking than OOP--but if I were to say "C++ is so cool because it's a generic programming language", I'd be missing the point.

    The point is, you can use whatever paradigm you need to get the job done. The unpleasant truth of object-oriented programming is that it is not a panacea; while it does some things really well, there are other things it's lousy at. To really enjoy any benefit from Objective C, you must use an object-oriented solution, regardless of whether or not an object-oriented solution is called for.

    This had the added side effect of making it very marketable to IT departments. Senior executives got to tell their bosses, "Yes, our entire IT department is working in C++ now"... and the techs got to keep on solving problems the same way they always had, and were able to take their time to slowly migrate things to C++. Management was satisfied that "we're using C++"; the techs were satisfied that "well, at least we can keep solving problems in the old C style while we come up to speed".

    With C++, I'm free to use whatever solution I need, whether it's a generic solution, procedural, functional, object-oriented or what-have-you.

    (Let me harp for another moment on generic programming. Damn, is it cool, and I wish more languages supported it. I think generic programming is a seriously overlooked part of programming. End the free advertisement for generic programming.)

    [*] Don't forget, the first C++ compilers were really preprocessors that spat out C sourcecode. Everything you can do in C++, you can do in C... C++ just makes it a lot easier.

    [**] At least, I've never had the patience to do it. I've tried a few times, but it quickly gets nontrivial.

    [+] This is kind-of true. Without fully embracing OOP, you can't use any of Objective C's really cool features--you lose everything which distinguishes it from C. C++ allows you more flexibility in this regard.
  • by Matts ( 1628 ) on Sunday August 13, 2000 @11:07AM (#858972) Homepage
    First of all, ObjC started out just on NeXT. That made it fairly niche stuff, as you wouldn't find any hobbyists or Universities developing on that platform due to the expense of it. And you didn't find it running on probably 99% of the general computers out there, like Windows machines or other Unix machines.

    The second thing was that despite the ease of development, ObjC was slower than C++ at the time. C++ used a vtable for method dispatch (static dispatch), whereas ObjectiveC was a truly dynamic dispatch system, which while being a better design overall, raised a lot of criticism that meant that a number of people didn't take up the usage of the language because of non-investigative bias (i.e. hearing this in a newsgroup post and basing everything on it). Nowadays ObjC has method dispatch caching code that makes it almost as fast as C++ vtables.

    Another point is the lack of compilers. And not just free compilers either.

    Then there's the runtime library issue: C++ programs link to static programs that don't require anything extra. ObjC programs require a runtime Objective C library (at least they did last time I looked at ObjC). This is offputting if the OS you are shipping for doesn't come with that by default. Note that this is not disastrous so don't flame me on it - its just something I've been told about that people have issues with.

    Finally there's the strange syntax, which doesn't really follow C-like calling convention. It's [Object method:param namedparam2:param2value] is unlike anything anyone has seen in C before, whereas C++ at least was mostly just an extension of the struct idea. Of course you could go on arguing about this forever, such as the fact that Objective C is easier to debug because you can see what are method calls very clearly due to the syntax, and the named params are better. But all that is history now. People don't like to change the way they work, thats why Perl appeals to both C programmers and shell programmers alike - because the cognitive dissonance is low.

    Anyway, I hope that helps.

    For more information on Objective C, apple provides free Objective C documentation (which I believe is based the original NeXT docs) at http://developer.apple.com/techpubs/macosx/System/ Documentation/Developer /Cocoa/ObjectiveC/ObjC.pdf [apple.com].

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Working...