Steve Jobs thinks Objective C is Perfect? 784
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?"
namespaces (Score:4, Informative)
Re:namespaces (Score:3, Funny)
Re:namespaces (Score:5, Informative)
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.
Re:namespaces (Score:3, Insightful)
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.
Re:namespaces (Score:4, Insightful)
Re:namespaces (Score:3, Insightful)
Comment removed (Score:5, Informative)
Jef Raskin on Steve Jobs (Score:4, Informative)
Comment removed (Score:5, Insightful)
Re:Jef Raskin on Steve Jobs (Score:5, Informative)
Jeff Raskin was NOT the creator of the Mac. He was the originator (IIRC) of the Macintosh project, and its first manager, but his vision of the Macintosh was so at odds with Jobs', that to give Jef any credit for what the Macintosh became is unfair and incorrect. If you want to see Jeff's vision, go look at the Canon Cat, which he designed after being asked to leave teh Macintosh project.
Raskin was a smart guy, but he wanted to design interfaces for smart people; interfaces that had a learning curve associated with them due to all sorts of key combinations to remember. Though he backed away from this a little later in his life, when he saw how successful GUIs were (and, perhaps, wanting to claim an unfair amount of credit for that), all his interfaces were designed to be incredibly efficient for the intelligent geek who wanted to take the time to learn how to use them.
That doesn't really go along with the Mac's tagline "The computer for the rest of us."
Remember that history and fact are not the same thing. Jef & Steve both have (well, in Jef's case, had) their versions of what happened; neither is fact, and the real truth, if there is one, probably lies somewhere in the middle, probably a touch closer to Jobs' version, that is, if you know how to interpret the Jobsian language and make sure to read it outside of the RDF.
The emails are already gone. (Score:5, Informative)
Re:The emails are already gone. (Score:4, Informative)
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,
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
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)
And this, kids, is why you should never ever top-post.
Yaz.
Best example why top posting just sucks (Score:3, Interesting)
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)
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)
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)
Re:objective-c is cool (Score:4, Interesting)
Re:objective-c is cool (Score:3, Insightful)
Re:objective-c is cool (Score:5, Informative)
MS recognise the above, and will themselves be following a similar route in the future with XAML, which is set to replace WinForms as the UI-building methodology of choice once Vista is launched (XAML will be one of the Vista technologies back-ported to XP). WinForms is thus in life-support mode at the moment: they will fix bugs, but not add more features to it because it is considered to be a deprecated technology.
NB: I've adopted a mixed-mode approach to Mac programming that seems to work very well from a productivity viewpoint. I do a lot of the main stuff in AppleScript or F-Script, and "drop down" to Objective-C for performance-critical stuff, custom Cocoa sub-classes, Darwin-related tasks, and other things that AppleScript or F-Script either isn't good at, or does too slowly. One could of course do this equally well using (for example) Python with the PyObjC bridge, and I believe that there is something similar for Ruby (don't quote me on that, though!), so the scripting languages I use are just one of the options available to Mac developers. And XCode happily manages all the different language files from a single project, ensuring that Obj-C code is compiled before running the interpreted stuff, managing CVS repositories, and generally making the experience pretty holistic.
Making it "fun" (Score:4, Funny)
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)
Re:Making it "fun" (Score:3, Funny)
"Damn it! Take 47!"
Love it (Score:5, Informative)
Re:Love it (Score:5, Interesting)
(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)
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".
What's wrong with pointers? (Score:3, Interesting)
Function pointers are probably my favorite thing about low-level languages (and even a few higher-level languages that provide such support).
Re:What's wrong with pointers? (Score:3, Insightful)
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)
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.
Re:Love it (Score:3, Interesting)
well... (Score:4, Insightful)
Re:well... (Score:3, Insightful)
Re:well... (Score:3, Insightful)
Re:well... (Score:3, Insightful)
Did you just compare a language and framework to an IDE? How can that make sense?
Doesn't work with programming. (Score:3, Interesting)
between himself and Steve Jobs (Score:5, Funny)
I always knew Steve Jobs was just a little bit crazy.
Re:between himself and Steve Jobs (Score:4, Funny)
It's not like they're not doing anything (Score:5, Informative)
Re:It's not like they're not doing anything (Score:5, Informative)
Agreed. I just started using CoreData, and it's a pretty amazing technology. For instance, take a look at this tutorial [cocoadevcentral.com]. It's a whole working database-based app without writing a single line of code! If you want custom behavior, enhancing is very easy, too.
Key-Value Observing has revolutionized Cocoa development, most developers just didn't notice (b/c it takes some time to get used to it).
Comment removed (Score:4, Interesting)
Wowing developers... (Score:3, Interesting)
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)
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
Re:Wowing developers... (Score:5, Informative)
Re:Wowing developers... (Score:3, Insightful)
Re:Wowing developers... (Score:4, Interesting)
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)
And this says nothing about the ridiculous naming conventions of C++ and Java. Translate the following statements into English. and 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)
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)
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.
Re:Wowing developers... (Score:3)
So, a JIT-based interpreted language then?
Re:Wowing developers... (Score:3, Informative)
True, however in this interview [oreilly.com] with Anders (Chief C# Language Architect), he states that "I think one of the key differences between our IL design and Java byte code specifically, is that we made the decision up-front to not have interpreters". A bit further down he says "When you make the decision up-front to favor execution of native code over interpretation, you are making a decision that strongly influences design
.NET is a bit complex (Score:5, Interesting)
A good example of the complexity is the file access models for both APIs.
Re:.NET is a bit complex (Score:4, Interesting)
Comment removed (Score:5, Informative)
the Wow factor. (Score:5, Insightful)
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.
Re:the Wow factor. (Score:3)
Objective C is hard to beat (Score:5, Insightful)
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
-b
Comment removed (Score:4, Informative)
Comment removed (Score:4, Informative)
Re:Objective C is hard to beat (Score:3, Interesting)
You can write apps on Mac OS X using Python that you can't distinguish from ObjC apps without inspecting the contents
Learning ObjC/Cocoa (and others) now... (Score:5, Interesting)
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
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...
Re:Learning ObjC/Cocoa (and others) now... (Score:3, Insightful)
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? X
Network Mirror (Score:4, Informative)
Dev tools plus/minus (Score:5, Interesting)
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)
Every time the ObjC/C++ discussion comes up... (Score:5, Insightful)
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)
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.
Re:Every time the ObjC/C++ discussion comes up... (Score:3, Insightful)
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
Re:Every time the ObjC/C++ discussion comes up... (Score:3, Informative)
true. However, this sort of dynamic dispatch is limited to objects which are members of a certain inheritance hierarchy. In Obj-C, when a message is sent to an object the determination of whether or not that receiver can respond to the message is determined at runtime. It doesn't matter that the receiver is a member of a particular class which inherits from some class which defined some virtual functions.
With virtual functions in C++ it's sort of a cros
Re:Every time the ObjC/C++ discussion comes up... (Score:3, Informative)
Correct.
in which case type safety is not available. I don't know enough about ObjC; perhaps you can explain it to me succinctly?
You are actually almost right. The way to put it should be that type safety is available but not required. Method type safety is a compile-time warning, not a compile-time error, because while a program which passes the type safety checks is guaranteed to function without type errors at r
Mangaged code good | .Net / Mono Bad (Score:3, Interesting)
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)
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
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)
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)
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"
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)
- 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)
ObjectiveC and Cocoa (Score:3, Interesting)
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)
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)
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)
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".
Re:Apple blew off Metrowerks. Now they must suffer (Score:3, Insightful)
Don't ruin Steve, please (Score:5, Insightful)
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)
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)
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)
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.
Re:I dunno (Score:5, Insightful)
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
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).
Re:Compared to Intellij IDEA, XCode sucks (Score:4, Insightful)
The article is about Objective C (and Cocoa) versus C# (and
Re:Compared to Intellij IDEA, XCode sucks (Score:4, Interesting)
Nothing stops you from using a third party regular expression library like pcre. Or simply use the java - objective c bridge in cocoa to use java's regex stuff. Although java is a second class citizen, it is supported to some degree with cocoa.
As for xcode vs intellij, I would never use xcode for java after trying intellij. I use xcode for c/c++ programming all the time though. Its a great ide. I like the debugger interface as it reminds me of microsoft's vb.net debugger in some ways. One thing microsoft doesn't do is add a decent spell check library to
I don't think its fair to compare cocoa and
Objective c vs C++ is what people should be comparing here. I can see objections to syntax with objective C. It is much different than modern languages using the "." notation and so forth. My wife and I both have trouble remembering the syntax for objective C, but I haven't tried that hard to use it yet either.
If you think cocoa is so bad, try to write a
Apple could add more libraries to cocoa. That would be helpful. I personally found it confusing to connect buttons and objects in interface builder to backend code compared to
Re:Compared to Intellij IDEA, XCode sucks (Score:3, Interesting)
Honestly, I would like to know why you think IntelliJ IDEA [jetbrains.com] and the other IDEs are better than XCode. What features do you find important that are missing, or was there some unliveable annoyance? What language do you code in, and what level of debugger support are you expecting? IDEA doesn't seem to support C, so while I would get the benefit of less suckage compared to Xcode, I would have to switch programming languages.
Your post h
Re:Compared to Intellij IDEA, XCode sucks (Score:3, Insightful)
Re:Compared to Intellij IDEA, XCode sucks (Score:5, Funny)
Re:Objective C was a neat idea in the 80's BUT... (Score:5, Insightful)
Re:Objective C was a neat idea in the 80's BUT... (Score:4, Interesting)
The point of any programming language is to give the developer the tools they need to efficiently (programmer time + machine resources) accomplish the goal they set out to do. No more, no less.
Not using C functions simply because objective-C has methods is ridiculous; the language has the direct functional call built in for *exactly* the reason you're discussing. I write performance code for simulation data display in Objective-C; it simply requires a little thought into what functions require absolute maximum performance (and can therefore tolerate the lack of flexibility) and what functions (such as GUI functions) are better off with the dynamism that Obj-C methods provide.
I don't care what language you're programming in, but if you completely ignore one of the tools that the language provides you and then claim that the language sucks, it's difficult to lend any credence to your opinion.
Re:Objective C was a neat idea in the 80's BUT... (Score:5, Insightful)
A dumb developer will write bad code in ANY language. And of course, he'll blame the language
Re:Objective C was a neat idea in the 80's BUT... (Score:3, Informative)
I must strongly disagree. In no sense is the auto-release pool equivalent to garbage collection. For one, you still have to think hard about memory management in any complex application - for temporary objects that are just part of the internal works of a function, they work OK, but then stack allocation works better. For actually passing objects around insid
Re:Objective C was a neat idea in the 80's BUT... (Score:5, Interesting)
C++ started out as C with a special preprocessor. So what?
I'd be interested to see some up-to-date figures to back up your assertion. GCC 3.1 gave a 2x speed increase in method dispatch, and GCC 4.0 has -fobjc-direct-dispatch.
msgc_ObjSend without the GCC 4.0 optimization is 22 cycles. Somehow I doubt that's really your big performance issue.
This is the usual Java/C++ argument of 'There is no value in dynamic typing, because I can write a program that does the same thing using static typing'. Well, yes, and I can write a program that does the same thing in machine code, but that doesn't mean high level languages have no value.
Some of us like having introspection, metaclasses, true parametric polymorphism and so on, without having to implement ugly workarounds. Personally, I think that ubiquitous (implicit) dynamic typing is a major aid to code reuse and software development agility.
Re:Objective C was a neat idea in the 80's BUT... (Score:3, Informative)
Objective-C / Cocoa has it's warts, speed is not one of them.
As slow as javascript my ass. I doubt you've ever coded in obj-c. Please study a bit before you spread this kind of FUD.
Re:Objective C was a neat idea in the 80's BUT... (Score:3, Interesting)
That's highly inaccurate. The ObjC runtime is not as fast as a function call in C, I'll grant you that. However, it isn't that slow - see my signature for a 3D OpenGL game written in Objective C. Objective C overall is certainly faster than Java, and orders of magnitude faster than Javascript.
Re:No garbage collector (Score:4, Interesting)
On the other hand, smart pointers fall well short of what Java offers - since smart pointer based software typically suffer from reference count bugs, and don't handle references loops. And doing the memory collection inline rather than in a seperate thread is a real disadvantage - but then it isn't like C++ has a threading model anyway.
C++ really suffers in many ways by not having modern GC and threading support. It is really starting to look like modern technology is passing it by. THis is becommng more and more of a problem as processors become increasingly parallel.
Re:Get this guy off my platform (Score:3, Insightful)
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 a
Re:Resources (Score:3, Informative)
MS gives theirs away for free, too [microsoft.com].
MSDN membership is comparable to the price of ADC [apple.com], when you compare the same ADC and MSDN levels. (msdn level 1 costs $500, level 2 costs around $1500).
one really annoying thing about apple -- I can use the latest versions of microsoft visual c on my clunky old W2K installation just fine (no way in hell am i "upgrading" to xp!). however apple's latest xcode requires me to upgrade osx -- it won't install