Slashdot Mirror
Steve Jobs thinks Objective C is Perfect?
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?"
Anyone claiming a language lacking proper namespace support is "perfect" is nothing short of delusional.
He's already taken down the emails in question, apparently having had second thoughts about the appropriateness of posting private emails.
"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?
Bill Clinton: Pimp we can believe in. - The Shirt!!!
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.
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...
-- Por mais que eu ande no vale das trevas e da morte, meu PowerMac G4 Não Travará!!!
posted an e-mail thread between Steve Jobs and himself.
I always knew Steve Jobs was just a little bit crazy.
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.
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.
.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.
A good example of the complexity is the file access models for both APIs.
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.
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.
.Net to use any language is kind of sexy, but I'm not sure you are going to gann anything in the long run.
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
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.
... and I'm guessing the set of people who have is extremely small nowadays.
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...
I've always felt Visual Studio (at least with all the .Net stuff) was turning more into a Visual Basic type of dev platform.
.NET after all - is it really surprising that the drag and drop method of RAD is being further extended?
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).
It's official. Most of you are morons.
Network mirror still has the original blog post up.
Be a real patriot: Question authority. Think for yourself. Formulate your own conclusions.
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.
...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.
[ home ]
This looks all good in theory. Fortunately, the objective C developers have thought about the problem, and they have come up with a solution that is quite fast. So in the real world, and objective C message send is about 2x-3x as slow as a C function call. Which is not too bad. The obvious implementation you hint at, would probably be more like 50x-100x slower. Fortunately, it's not the one that's used in practice, and I doubt you will ever find it in an objective C compiler (unless you were to write one yourself, just to prove your point).
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).
... 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.
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.
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
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.
cat
A dumb developer will write bad code in ANY language. And of course, he'll blame the language
he gives the inside story on Steve Jobs:
No, Raskin gives his opinion of Steve Jobs. Read Andy Hertzfeld's book for some perspective on Raskin.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
And this says nothing about the ridiculous naming conventions of C++ and Java. Translate the following statements into English.andThe 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.
YOU suckf
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 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.
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".
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).
The interface can exist as separate code, though. All the stuff that IB serialises is available through the Cocoa API (check out the docs on NSView and NSControl, for example), and can be instantiated directly with programming statements if you wish. Using IB to keep the UI code separate from the stuff that interacts with it is however a better way to work, as it allows modifications to be to made the UI without having to recompile the application (separation of concerns).
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.
I'm not going to change your sheets again, Mr. Hastings.