Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
OS X Will Not Succeed Without Developer Support

By GusherJizmac in Technology
Tue Jul 17, 2001 at 07:05:17 PM EST
Tags: Software (all tags)
Software

With the recent arrival of OS X, many who have used it (myself included) feel that it is really the first thing in a while that could legitimately compete with Windows, as a server, business desktop and home system. OS X has UNIX at its core, but it has an attractive, usuable interface, is compatible with lots of hardware on the market, and has the support of many vendors that make it a great all-around alternative to Windows. But, I don't think it will ever be a real threat to Windows. Why? The developer tools and associated supporting documentation are years behind Windows (and even Linux to a certain extent), and have been for quite some time. This makes it very difficult for developers to write software for it, and this will reduce the amout of software available for it. This will then reduce the overall utility of the platform, since it's pretty obvious that people care more about applications than operating systems.


Is developer support important?

The first part to this argument is that the overall success and long-term viability of a platform lies with it's potential developers. There are numerous examples to demonstrate this, but the basic idea is that the easier it is to develop for a platform, the more software will be developed and the more successful the platform will become.

First, consider the largest share-holder of the market, Microsoft. Some may say that their dominance is due to unfair business practices and shady ethics. While that is outside the scope of this article, I would say that much of Windows success has been the wide variety of software available for it. Most desktop applications today are written for Windows and ported to other platforms. Why? Windows has the some of the best development tools on the market. Anyone who has ever done a serious project using Visual Studio knows what I'm talking about. It is integrated incredibly well with their help system (which is far superior to anything else out there) and tools like MFC and Visual Basic allow a developer (or non-developer) to pump out an application very quickly (Whether or not you are a fan of the IDE-style of development, it should be fairly obvious that an IDE makes entry into the market as a developer much easier, especially when you are building a GUI using a complicated framework). Even at the API level, things like DirectX are far more advanced than their competitors on Windows or other platforms. This makes developers happy, because they have good tools that save time and great support. Thus, the platform flourishes.

Now, let's consider Linux's success in the server market. Linux is a success because it is based on UNIX, which is a well-known, widely used set of APIs and way of developing which has been around for years. Thousands of UNIX developers world-wide can log into a Linux box and be ready to go. Here, Linux has embraced a standard that resulted in attracting developers. Those developers built rock-solid applications that made Linux a viable platform. Linux's cost locked it in to make it a success. If Linux had been free, but not been based on UNIX, it would not be very successful. Compare this to Linux's (lack of) success in the business desktop market. There are numerous GUI APIs, none with an advanced development environment, and certainly nowhere near the amout of reference or online help and support that Windows has. This makes it harder for a developer to learn what he needs, and more difficult to write desktop software for Linux. Thus, Linux has a lack of decent desktop applications, and is not currently a viable business desktop.

There are numerous other examples, such as Microsoft's inclusion of Javascript in IE to attract existing web developers to the IE platform as well as industry-wide speculation that the XBox will crush its competition because it can capitalize on the huge PC gaming industry, since XBox will support DirectX. Also consider the success of Java: javadoc alone is a huge factor (allowing anyone to create very readable documentation of their code and APIs), and Sun's support for it's developers is huge.

The point is that a big part of a platforms success is in it's developer support. If a platform makes it easy for developers to write software for that platform, much software will be written and the platform will succeed. If it makes it difficult, it will be harder for developers to write software for the platform, and less software will be available for it, and it will not succeed.

So, how does OS X fit in?

Using OS X, I was amazed. It's the Linux desktop I never had. Everything just works, and I can run real business applications (such as IE and Office) while using tcsh and UNIX for doing server-side Java work in Tomcat. It seemed to me to be the best of both worlds. When I started reading about the system architecture and the features it offered developers, I continued to be amazed at the potential of this platform. Then, I tried to write an application for it.

Writing an application for Mac OS X using "Cocoa" (which gives you the full range of Aqua GUI elements and is the native API for OS X) involves using mainly two tools: Interface Builder, which lays out GUI elements on a window, and Project Builder, which is a Visual C++ style IDE for writing your code. The code can be written in either Objective-C or Java (but writing it in Java involves use of the "Java bridge", where calls to the Cocoa API in Java are translated into Objective-C calls and executed).

Let me first say that Interface Builder (IB) is a pretty good tool. It is clearly superior in some ways to the equivalent tool in Visual C++ for laying out a GUI. IB makes it very easy to conform with the "Aqua interface guidelines" and will go a long way towards preventing ugly interfaces. That said, there is little to no documentation on how to use it, and connecting your GUI to your code is very non-intuitive. For example, in Visual C++, double-clicking on an object brings up a dialog allowing you to specify the code called during events relevant to that object. Not so in IB, double-clicking allows you to change the label. Connecting the button to code is a two step process that involves dragging lines from one window to the button and vice-versa. In fact, this metaphor is used frequently, and not always to the same effect. This makes IB very confusing and counter-intuitive to me, and certainly to the army of developers out there, it makes it tough to use.

Project Builder (PB), the IDE, is where things really start to fall apart. PB has typical features of an IDE: A tree view of project files, integrated build and debug, and a semi-decent code editor with syntax coloring. The real problem is that there's no integrated help system. In visual C++ you can cursor over an object, hit F1, and see documentation about the keyword in question. Even before that, however, when writing your code, you can tell Visual C++ to pop up a list of method names for the object you are using and it will even show you the parameter list. All from within the tool without having to go to the documentation. Not so in PB. Integrated help is one of the main points of an IDE. You might think that this is excusable because OS X is so new, but IB is from the old NeXT days and has been in constant use and support through the years, because it is the development tool for Apple's web application server, WebObjects. I would think a tool that has been around for so long would have more advanced features or at least be close to the competition.

Next, is Apple's online documentation. Searching the documentation is almost pointless, as it seems to use a typical web search that returns numerous unrelated documents. Browsing the reference is equally difficult. When you look at the docs for a particular class, you are not given an alphabetical list of methods and public interface elements, but you are given a list of methods grouped by "purpose", and even then the list is not complete (there are documented methods for a class that don't show up in any of the groupings or any other method list). So, finding the parameters for a method you need to call is very cumbersome and difficult. The documentation has been this way for at least 3 years (it's format and usefulness doesn't seem to have changed since I started using WebObjects). The documentation seems difficult to use for beginners and experts.

Finally, we come to Objective-C. I don't think there's anything inherently wrong with Objective-C, but it is fairly obscure (try searching Amazon for Objective-C books). Given the lack of reference materials and the fact that it's syntax is a large departure from two of the more popular desktop application languages today (Java and C++), this also can be a problem for developers new to the platform.

I'll finish this off with a brief anecdote of writing an application. I wanted to have one main window and a preferences window that pops up when you choosed "Preferences..." from the drop-down menu. I could not figure out how to open a new window by reading the docs, so I looked at some sample code. Fortunatly, they had the code to TextEdit available, and it has a preferences window that operates similarly to the one I wanted. I traced the paths of execution through IB and PB and found the API call that (apparently) causes the preferences window to appear. The code wasn't documented, and the call didn't seem to be something that would open a window. So, I tried to find the documentation for that call. I couldn't find it anywhere. So, their example code is using an undocumented API call with no inline code documentation explaining why! And keep in mind this was example code of what I consider to be a basic task; opening a window. So, already in my first project to do something very basic I have to use an undocumented API call.

Conclusions

I've shown that a platform's ultimate success lies with it's ability to attract and retain developers. The best way to do that is to support standards or to provide top-notch development tools, backed with highly available documentation and support. I've shown several examples of this. I've also described the current state of OS X's development tools and documentation, which is to say many years behind the competition, despite the age of many of the tools and APIs.

So, what can Apple do? In short, Apple needs to:

  • Provide an integrated help system with Project Builder; something searchable with reference, knowledge base and tutorials all in one. Think MSDN Library for OS X.
  • Vastly improve their developer documentation. Looking at what Apple has compared to Javadoc I generated for code I wrote makes Apple's documentation look just plain embarassing.

I think OS X has incredible potential. I think the features of OS X could crush Windows as a desktop OS and the rock-solid BSD core could compete with Linux and Windows in the server market. But right now, as a development environment, OS X is really lagging behind the competition.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
How will OS X succeed as an OS?
o Server 0%
o Desktop PC 13%
o Specialty PC (graphic design, digital audio, etc.) 45%
o Application Server Development 0%
o Back-end Systems Development 0%
o Home/Entertianment PC 3%
o It will not succeed 26%
o It will crush Windows into oblivion! 11%

Votes: 60
Results | Other Polls

Related Links
o Also by GusherJizmac


Display: Sort:
OS X Will Not Succeed Without Developer Support | 56 comments (52 topical, 4 editorial, 0 hidden)
Objective-C: Horizontal Programming (4.14 / 7) (#1)
by snowlion on Tue Jul 17, 2001 at 04:09:13 PM EST

My main objection to Objective-C is horizontal programming. Conceptually, Objective-C is beautiful. I love the design and everything. I just hate programming horizontally.

Anyone care to post the code for adding a single day to an NSCalendarDate? Anybody? Anybody? It's pretty hairy- It's been a year since I used Objective-C on OS X Server.

Now I know why Macintosh made those wide screen monitors- it's so that they can program in Objective-C..! I should have made the connection earlier...

You'd think that, in a language where you had to NAME your arguments as you call them, that you'd be able to transpose the positions of the arguments, or selectively specify arg's and leave the rest for defaults... Not So!


--
Map Your Thoughts
re: Objective-C: Horizontal Programming (none / 0) (#23)
by dadams on Wed Jul 18, 2001 at 08:52:12 AM EST

My main objection to Objective-C is horizontal programming. Conceptually, Objective-C is beautiful. I love the design and everything. I just hate programming horizontally.

Huh? Maybe the new Project Builder's editor doesn't do this, but the old one did some really keen formating if broke your message sends up over multiple lines. Basically, it would line up the colons in the argument tags, and space them out all pretty.

You'd think that, in a language where you had to NAME your arguments as you call them, that you'd be able to transpose the positions of the arguments, or selectively specify arg's and leave the rest for defaults... Not So!

Yeah. That's why DYLAN and OCaml are so rockin'.



[ Parent ]
All heads are hairy in the land of the bald... (5.00 / 1) (#30)
by Chris Marlowe on Wed Jul 18, 2001 at 04:01:20 PM EST

My main objection to Objective-C is horizontal programming. Conceptually, Objective-C is beautiful. I love the design and everything. I just hate programming horizontally. Anyone care to post the code for adding a single day to an NSCalendarDate? Anybody? Anybody? It's pretty hairy- It's been a year since I used Objective-C on OS X Server.

I got the following working in about 12 minutes. That included creating the build project and double-checking the documentation on NSDate and NSCalendarDate, as I've never used them for date calculations before.

Note that adding a method to get the day after any NSDate, including NSCalendarDates, took six lines. After that, the operative code is:

another = [oneDate dateOneDayAfter];
The rest is overhead, most of it coming from the file template Apple supplied.

The output is:

Jul 18 14:51:01 AddADay[532] oneDay = 2001-07-24 12:00:00 -0500
Jul 18 14:51:01 AddADay[532] another = 2001-07-25 12:00:00 -0500
Those who find these seven lines "hairy" would indeed be better off sticking to VC. I do confess to horizontal programming, though, as I was in bed when I wrote this. If "horizontal" means you can go a long way between semicolons, that's true. My experience with DOS C development ended in about 1985, but I seem to remember that even then, the C-86 and DRI compilers supported multiline statements, and WordStar knew about autoindentation, and even responded to the tab key. Did these features not make the cut in Windows?

#import <Foundation/Foundation.h>

@interface NSDate (AddADay)
- (id) dateOneDayAfter;
@end
@implementation NSDate (AddADay)
- (id) dateOneDayAfter { return [self addTimeInterval: 24 * 60 * 60]; }
@end

int main (int argc, const char * argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    NSCalendarDate *oneDay;
    NSDate *another;

    oneDay = [NSCalendarDate
        dateWithNaturalLanguageString: @"A week from Tuesday"];
    NSLog(@"oneDay = %@", oneDay);
              
    another = [oneDay dateOneDayAfter];
    /* If you're type-obsessive, add
        another = [another dateWithCalendarFormat: nil
                           timeZone: nil];
        to convert to NSCalendarDate.
        I found it wasn't necessary. */
    NSLog(@"another = %@", another);
    
    [pool release];
    return 0;
}

Chris Marlowe <xtofermarlowe@yahoo.com> Chicago, Illinois
[ Parent ]
horizontal programming ? (4.50 / 2) (#36)
by f5426 on Thu Jul 19, 2001 at 10:51:25 AM EST

It took me a while to understand that by 'horizontal programming' you meant the formatting of the source code. This is ridiculous. The crux of the problem is that you don't know how to write ObjC code.

First, you can't add one day to an NSCalendarDate, because those are immutable objects. So you meant creating a calendar date one day in the future of a given one. Good.

As Chris Marlowe said, adding one day to a NSCalendarDate is as simple as doing a [aDate dayOneDayAfter], if you use it a lot (ie: if the original effort to write -[NSDate(AddADay) dayOneDayAfter] can be considered as negligible.

Now, take your favorite language, and show us
1/ If he knows how to handle date
2/ If you can add a new concept to its date class

> You'd think that, in a language where you had to NAME your arguments as you call them, that you'd be able to transpose the positions of the arguments, or selectively specify arg's and leave the rest for defaults... Not So!

No. First, there is no argument naming in ObjC. For instance:

- (id)performSelector:(SEL)aSelector withObject:(id)object1 withObject:(id)object2;

have two arguments 'named' the same.

Second, technically, selectors contains the 'names' of the arguments, so -(id)doWithA:(id)aA withB:(id)aB withC:(id)aC really is the selector @selectors(doWithA:withB:withC:), so having selector part moving around would be quite a problem.

Third, default arguments are a bad practice, because defaults are applied at compilation time of the call site (because the call site have to push the arguments on the stack). This is a problem in the ObjC philosophy. The good way (ion that philosophy) to handle default arguments is at the called point, not at the call site, so defaults are handled with categories. [NSView init] is really a default for [NSView initWithFrame:NSZeroRect()]. If you look at the design of the FoundationKit or the AppKit, you'll see that there are not a lot of defaults. The idea is that the kit gives you powerfull operations that you can tailor to your needs via categories.

> Now I know why Macintosh made those wide screen monitors- it's so that they can program in Objective-C

I program on NeXTstep/OPENSTEP/YB/OSX since 1991, and indeed, I have two 21 inches. But this is not because of 'horizontal programming', but because having Terminal + Edit for notes + PB (the real one, not the PBX toy) + a few dozen of source files + the find panel + half a dozen documentation windows + the debugger and my running app is easier when I have 3200x1200 pixels at my disposition.

I developped with VC++ too, and boy, that was a huge pain (you end up with a tiny window for your source code surrounded by panels). Exactly as the new PBX, which is a badly done VC++ wanabee.

Cheers,

--fred


[ Parent ]
Python DateTime (none / 0) (#38)
by snowlion on Thu Jul 19, 2001 at 02:22:38 PM EST

After looking on the web for a couple of moments, I found the "DateTime".

Here's how you can use it.

from mx.DateTime import *

print now()
print now() + RelativeDateTime( months=+1 )
print now() + RelativeDateTime( days=+1 )
print now() + RelativeDateTime( months=+1, days=+1 )

If I wanted to extend the DateTime, I just create methods and attach them. It would look something like this:

def foo( self ):
#blah
#blah
#This is going to be some method on DateTime.
#blah

DateTime.NewMethodName = foo

I could use a lambda, but it doesn't look as pretty. It would be something like: DateTime.NewMethodName = lambda self: codecodecode

So there you have it. Rather straightforward, I believe.

Yes, I agree with your complaints about the VC++ IDE; That's why I use EMACS to edit my code.

One thing I learned by working with Objective-C: The NeXT-step people are different. You all are a whole culture unto your own, and you all have your own way of seeing things, and you all are particular about your own set of things. I'm not criticizing you; I just find it interesting. You have your disadvantages and advantages.

Take care.


--
Map Your Thoughts
[ Parent ]
Verbosity of Objective-C (5.00 / 2) (#46)
by sabi on Sat Jul 21, 2001 at 08:36:08 PM EST

The NSCalendarDate question - it's just a bunch of arguments that you don't fill in.

date = [[NSCalendarDate date] dateByAddingYears: 1 months: 0 days: 0 hours: 0 minutes: 0 seconds: 0];

That API is really stupid, though; you should just be able to add two dates together by doing something like:

date = [[NSCalendarDate date] dateByAddingInterval: [NSCalendarInterval days: 1]];

or just create a category on NSCalendarDate, as someone else did.

I've used Smalltalk, which has the same messaging syntax as Objective-C, and Python and Lisp, which have optional arguments, keyword arguments, and lots of other cool stuff. (I have NOT used CLOS, or any other system with multimethods, so that may somewhat color my comments). I have to say that I really prefer the Smalltalk/ObjC style. With optional arguments, when you have so many possible parameters to functions, it means that you have to account for them all in your code - lots of if statements - and disallow (again, in code) the combinations that don't make sense. Add inheritance to it, and it really becomes a nightmare - if you've had to do ugly things with dictionaries, update, **kw, etc. in Python otherwise your arguments get lost - (I found this especially bad with Pmw, extensions for Tkinter) you'll know what I mean.

ObjC - and this is Cocoa, not the language - tends to go for messages with 8 million parameters more often. What is more common in Smalltalk is just to create about 5 versions of the message, which call a main message, potentially after doing some massaging of the arguments (you see this in Java/C++ too, but without intention-revealing selectors it's a lot harder). It is really nice the way the selector names let you simply leave parameters out, and often you're left with a working selector. For example:

[someObject drawRectangleInView];
[someObject drawRectangleInView: someView];
[someObject drawRectangle: someRectangle inView: someView];

That way the implementor has to think about what combinations of arguments are permitted; there don't have to be any kludges like passing nil for things, and the code reads a lot more cleanly, if you need to do more with missing arguments than just provide defaults. Good Smalltalk VMs will automatically optimize these paths so none are slower than the others. I don't know enough about the Objective-C runtime yet to know whether it does something similar, but in any case computers are fast enough it probably doesn't need to.

Python makes it really bad because you can only have one true constructor per class. Basically, Python really SUCKS as an OO language, and believe me, I programmed in it every day for over a year. I'm not sure whether Perl is worse or not (for OO, it's a very nice language in general), since I have only read about OO in Perl. Ruby looks cool, but I haven't programmed in it at all.

ObjC is too hard to program in other ways, though; it's an old language. It really needs automatic garbage collection, and namespaces, a better IDE, etc. IMHO, it should be a compiled Smalltalk with some syntactic extensions. Several YEARS ago (WWDC '99) Apple demonstrated PB/IB automatically updating code in both directions, and it's STILL not implemented in the shipping version. This is a lot easier than it is with Delphi or JBuilder, since IB doesn't really generate code, it just has to manipulate the header files and generate function templates, but yet they still haven't done anything. I hope that PB can get some major improvements now the rewrite is finally done and mostly bug-free. I liked the old PB a lot, too, but am getting used to the new one slowly. Most of the features are still there, they've just moved. If you miss the history pane, there's now a key binding to the history popup, and you can use the keyboard (cmd-opt-left/right arrows) to move between files too. And the collapse-panels keyboard equivalents (cmd-shift-M for the top and cmd-opt-M for both) are very very useful if you need more room for source.

Finally, let me put in another request for more and better documentation. Inside Macintosh was of incredible quality, and from listening to Caroline Rose (one of the original IM authors) speak at MacHack, it seems that Apple is going about documentation exactly the wrong way these days. I'm reading Learning Cocoa now, and while it's not awful, it's certainly not the best book I've ever seen. The older Project Builder did a MUCH better job of online documentation, and the Librarian on NeXTSTEP looked great from the screenshots I've seen. Web browsers (especially slow ones like the OS X Help Viewer) are not the answer to everything.

All this said, Cocoa rocks. It is, bar none, the best GUI framework I have ever used - which includes several in Smalltalk, Python (with Qt and Tkinter), C++, and Java. The nicest thing for me is that I can subclass the standard UI components but still manipulate them in IB like their superclasses. I just about fell out of my chair yesterday when I saw the way it checks to see if menu/toolbar items should be enabled - check out the NSValidatedUserInterfaceItem protocol - and especially how it can be extended; I wrote an interface to validate buttons yesterday in about 20 lines of code. But like most of OS X, Cocoa and the development tools need a hell of a lot of work, and I just hope that the work can be done before Apple goes down in flames.

[ Parent ]
as a server? Since when? (3.00 / 6) (#2)
by WinPimp2K on Tue Jul 17, 2001 at 04:13:58 PM EST

I didn't know that Apple made high density rack mount Macs. All this time I thought they were just pricey desktop and notebook PCs with a niche market appeal.

Possibly... (we will know for sure on 18JUL01) (4.33 / 3) (#5)
by Hillgiant on Tue Jul 17, 2001 at 04:34:02 PM EST

The mac rumor sites are speculating that Mr Jobs will be anouncing a rack mac during the MacWorld Expo.

But that is not to say that some hacker hasn't already thought of rackmounting iMacs when their monitors go pop

-----
"It is impossible to say what I mean." -johnny
[ Parent ]

"third-party opportunity" (4.50 / 4) (#6)
by mbrubeck on Tue Jul 17, 2001 at 04:34:46 PM EST

Jean-Louis Gaseé (CEO of Be Inc and former Apple exec) always used the phrase "third-party opportunity" as an obvious code for "we're not going to do it, but we won't stop you from trying."

Third-party companies like Marathon Computer sell rack-mounted Macs, or DIY mounting hardware.

[ Parent ]

That's been an intention for a few years... (4.00 / 2) (#11)
by GusherJizmac on Tue Jul 17, 2001 at 05:36:30 PM EST

They've always intended to position OS X as a server from which to deploy enterprise-ready services. For one thing, they want you to run WebObjects off of OS X. Plus, I'm talking about the OS/Software, not the form-factor of the computer case.
<sig> G u s h e r J i z m a c </sig>
[ Parent ]
Yeah (4.44 / 9) (#3)
by trhurler on Tue Jul 17, 2001 at 04:26:20 PM EST

You cannot expect other people to support your proprietary product until after it is in their interest to do so - ie until AFTER you have made it a success. Billy boy learned that lesson the hard way in the 80s, and that was how Microsoft got into the applications business. Apple better figure it out damned quick, or there won't be any more Mac, because just having ports of old versions of Microsoft programs isn't going to cut it...

(And yes, I'm serious. Documentation and searchable indexes and lots of other chrome are nice to have, but they don't mean dick if a potential software developer looks at the market and realizes nobody is using your platform.)

--
'God dammit, your posts make me hard.' --LilDebbie

Actually... (3.00 / 2) (#18)
by intmainvoid on Tue Jul 17, 2001 at 08:56:32 PM EST

because just having ports of old versions of Microsoft programs isn't going to cut it...

Actually, the Microsoft apple team works semi-independantly from the windows team. IE and office for mac are more than just ports. Office 2001 was out on mac before it was out on windows!

[ Parent ]

sure it was (3.00 / 1) (#21)
by yannick on Wed Jul 18, 2001 at 01:05:59 AM EST

Office 2001 was out on mac before it was out on windows!

Both in terms of features and in terms of release cycle, Office 2001 for Mac is related to Office 2000 on PC. Office XP (aka Office 2002) has, therefore, come out on PC before a comparable product comes out on the Mac.

Besides, you think Microsoft would give a proverbial "F*** you" to its biggest market (PC users) to give Mac users the latest and greatest stuff first? nuh-uh.

In other words, trhurler is right: Apple's strongest desktop productivity suite is basically a port of last-generation PC software. I don't know about you, but that's not going to convince me to switch.

Cheers,
Yannick
---
"Hello, World" 17 Errors, 31 Warnings...
[ Parent ]

Apple vs GNU (3.28 / 7) (#9)
by mkc on Tue Jul 17, 2001 at 05:32:25 PM EST

Personally, I still recall the GNU boycott of Apple and the misbehavior that lead to it. Though I'm in favor of Unix-like OSes in general, I'd have mixed feelings about developing for OS X because of this.
-- Teach a man to fish and he will eat for a day. Give him a patent on fishing and he can enjoy watching everyone else starve every day.
details please? (3.25 / 4) (#14)
by delmoi on Tue Jul 17, 2001 at 06:39:57 PM EST

I still recall the GNU boycott of Apple and the misbehavior that lead to it.

And what misbehavior was that?
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Objective C compiler... (3.83 / 6) (#15)
by reeses on Tue Jul 17, 2001 at 06:52:27 PM EST

There was a brief GPL-violation battle when NeXT made modifications to the Objective-C engine for gcc, without making source for the modifications available after shipping NEXTSTEP. NeXT ended up caving. It's not tough to dig up info on this online.

[ Parent ]
Look and Feel (4.85 / 7) (#20)
by evin on Wed Jul 18, 2001 at 12:59:21 AM EST

Apple sued Microsoft and HP for using the "look and feel" of MacOS. GNU realized that such lawsuits were could potentially be a big obstacle to replacing proprietary systems, so they didn't want to support Apple. Thus GNU didn't support ports of their programs to MacOS and generally discouraged people from using Apple stuff. The boycott ended around 1995.

The NeXT thing with objective-C bindings to gcc is unrelated.

[ Parent ]

the gnu boycott (3.66 / 3) (#26)
by mveloso on Wed Jul 18, 2001 at 10:04:20 AM EST

was a ridiculous stunt by the FSF to look like they were principled, but in reality it was an easy way to score propaganda points for no cost.

For those of you who don't remember, the FSF was not implementing support for Apple platforms (specifically the MacOS) because of the ongoing case against Microsoft's alleged copying of the Mac UI. Copyright, intellectual freedom, blah blah blah.

The thing that the FSF never said is that porting stuff to the MacOS would be hard...really hard, like there's no shell, so how would you run the tools? So it really was a moot point. It would be like the FSF declaring they'd never port their stuff to the Timex Sinclair 100. First, how would you do it?

Then, at the same time they were dissing Apple, the FSF was supporting their stuff on the x86 architecture while Intel was busy suing competitors for using the x86 ISA in their x86 clones. Same idea, right? Well no. An FSF mouthpiece, when queried about this back then, said something to the effect that "well, it's complicated."

Basically, it was convenient to launch this campaign against Apple, but when it came to the same principles on one of its bread and butter platforms, the FSF was like "oh well."

[ Parent ]
The Apple Look & Feel Copyright (none / 0) (#54)
by Per Abrahamsen on Tue Aug 21, 2001 at 08:51:29 AM EST

First, we take your minor error, about the effect of the boycot. While ports of GNU software to the Apple GUI was unlikely, ports to MPW made a lot of sense, and were quite common. MPW was the official MacOS command line based development platform, and GNU was at the time mainly command line based development tools. There was even an unoffical MacOS port of GCC, today the maintainer of that port is the maintainer of the official MacOS X version of GCC.

The main cost was of course to alienate all the Mac fanatics, to whom Apple was unfallible, and anyone who critized them therefore the enemy.

They did boycot all who sued over look & feel, if you want to pick an example with no effect, the Lotus boycot might apply.

Secondly, GNU is basically a clone of the Unix look & feel. So while FSF dislike many kinds of interlectual property, including ordinary copyright and patents, look & feel copyrights was a direct threat to the project. Even more direct than software patents are today.

So while just about every computer-related company at the time did something the FSF dislike or disagree with, boycotting everybody is as effective as boycotting noone. For a boycot to have any effect, it must be limited to the worst offenders. And at the time, look & feel copyrights were the largest threat to GNU.

[ Parent ]
Disagree; get a userbase, the rest follows. (4.00 / 9) (#12)
by Surial on Tue Jul 17, 2001 at 05:45:29 PM EST

You're right - A good developer environment is a definite Good Thingtm. However, the reason it is is simply to generate some useful software from the die-hard supports of your platform.

The real key to getting around the chicken and egg problem (You won't get developers to release software for you unless you have users, and you won't get users until there is some decent software) is backwards compatibility.

As chulbert already said in an editorial comment, Microsoft has learned this lesson well. DOS was more or less backwards compatible with CP/M, and every upwards Microsoft product (DOS->Win3->Win4->win2k) Has been backwards compatible with the previous, With the notable exception of WinNT.

In fact, if Desktop linux is ever going to get a large market share, I think it'll be due to fully integrated wine and dosemu support in the commercial distributions. I essentially want to doubleclick on a .COM or .EXE file, and have Linux figure out whether to run it through dosemu or wine (simple, just look for the characters 'PE' near the start of the EXE).

This is currently possible. It's just not done yet. Also, while wine has gotten far in a short time, there are some problems with it:
  • You need the have a copy of windows somewhere on your system for some needed (and copyrighted) DLLs
  • It doesn't work yet on MSOffice and a lot of games.
The first thing means that it can't work on single-boot systems. This is important. The significant savings of some 150 dollars or so for not having to include a M$ license means some computer builders might release a very cheap low-end linux system, in the stores. That would seriously boost Linux marketshare for the Desktop.
Solving this issue probably means recreating the functionality of them. Also, a lot of Windows installers (which should of course also work) will copy MFC42.dll to the system, so that's one DLL that won't have to be rewritten.

The second issue is currently being worked on, especially with regard to games. The increased reliance of games on the GFX card and hardware drivers is great, because this means they have to be ported only once. NVidia already has, and if the Desktop segment grows the rest will not stay behind.

That leaves wine support for MSOffice. MS will probably try and deliberately make it incompatible with wine. An even better option is to build a really good (and user-transparent) filter, usable by any Word Processor for Linux. This development is already in progress, with OpenOffice and KWord joining forces to do this. The MSOffice file formats are very complex, and some say M$ is deliberately doing this to prevent competitors to allow MSOffice to be replaced.

Once that really works, and any PHB can just click on a .DOC, .EXE, .COM, .XLS, and other famous format files and it just works, Linux will gain Desktop acceptance in an extremely rapid pace. The business area will come through first, because a lot of IT admins are already administrating *NIX boxen, and will no doubt like the ease of remote configuration that comes with a Desktop linux install. Then there's also the cost picture. A company with 300 computers can save 150*300 = 4500 dollars in licensing costs.

At least, that's what I think. I am a bit surprised at the lack of true Desktop-oriented PHB-proof Linux installs out there. SuSE is getting there, RedHat is too, but I don't know of any distro which is really geared towards D-Top only use.
--
"is a signature" is a signature.

re: Disagree; get a userbase, the rest follows (none / 0) (#37)
by nohat on Thu Jul 19, 2001 at 12:58:21 PM EST

Excellent points, and understated: 150*300 = 45000

[ Parent ]
Backwards Compatibility != Sideways Compatibility (none / 0) (#51)
by Robert Uhl on Fri Aug 03, 2001 at 07:10:26 PM EST

The problem with sideways compatibility is that it drives developers away from one's platform. Observe what happened with OS/2: if one wished to develop for it, one could use Windows or OS/2 APIs. Using the OS/2 APIs limited the prospective audience; using the Windows APIs garnered a much larger audience. Eventually OS/2 died--what did it have which was unique?

Backwards compatibility, OTOH, is not a bad idea. Folks can use their legacy apps from the past, while using real apps in the future.

In general, though, I do not worry about compatibility. Give users a reason to switch: stability, cool games, whatever. When enough users have switched, developers will develop for them. We're seeing it already with Linux (incidentally, whatever happened to Chilliware?).

[ Parent ]

Apple is even worse then Microsoft (3.23 / 13) (#13)
by delmoi on Tue Jul 17, 2001 at 06:37:45 PM EST

They may not have the dominance that Microsoft does, but I'd really be afraid if they did. I mean, lets be honest here, Apple is a lot worse then Microsoft when it comes to making things proprietary. For starters, just look just look at there hardware. I mean, do you really think replacing a software monopoly with a software and hardware monopoly would be a good thing?

And lets not forget them doing things like suing people who made tools to extract the graphical resources from the OS.

I really don't see OS X becoming a challenger to windows the way Linux is, or can be. It may be smoother then windows, but no one is going to completely get rid of their hardware investment for the sake of more expensive and slower Mac hardware. And I doubt many corps are going to mess around with an unsupported Darwin on x86 when they could just use Linux or a BSD.

OS X may be Technically superior to windows, but that fact a lone is not going to make it beat windows, no matter what. Unless Apple releases an x86 version at a reasonable cost, and possibly using open source, it simply won't.
--
"'argumentation' is not a word, idiot." -- thelizman
do they... (3.00 / 1) (#22)
by poltroon on Wed Jul 18, 2001 at 01:09:18 AM EST

get any cookies for Darwin being open source? Couldn't that at least be considered a step in the right direction?

[ Parent ]
yeah, whatever (1.60 / 5) (#25)
by mveloso on Wed Jul 18, 2001 at 09:56:10 AM EST

monopoly, proprietary hardware, blah blah blah. Same old, same old. Maybe you should get some real opinions based on experience, instead of blithely parroting opinions of people who have no idea what they're talking about?

<
Apple is a lot worse then Microsoft when it comes to making things proprietary. For starters, just look just look at there hardware.
>

Why not check out the latest builds of Linux, a kind of neat operating system? The PPC builds seem to work fine.

Also, the first sentence is just prima facie ridiculous.

<
And lets not forget them doing things like suing people who made tools to extract the graphical resources from the OS.
>

Oh, boy! Let's not forget those "other companies" who dump poor product on people for free, subsuming real companies and developers with unfair competitive tactics.

<
I really don't see OS X becoming a challenger to windows the way Linux is, or can be.
>

You really can't see past your own behind, either.

<
It may be smoother then windows, but no one is going to completely get rid of their hardware investment for the sake of more expensive and slower Mac hardware. And I doubt many corps are going to mess around with an unsupported Darwin on x86 when they could just use Linux or a BSD.
>

Hah! Maybe you should go to a corporation and ask them how they decide which boxes they buy? What you think and how reality works are as distant as pluto and the sun.

<
OS X may be Technically superior to windows, but that fact a lone is not going to make it beat windows, no matter what.
>

Where have you been? People have understood this ever since the Beta/VHS wars.

<
Unless Apple releases an x86 version at a reasonable cost, and possibly using open source, it simply won't.
>

Hah! "I want to play with apple's toys on my crappy box, because I'm too cheap to buy a new machine."

Thanks for giving me some troll-bait! It's been fun, and distracted me from Real Work or a bit.

[ Parent ]
opening windows... (3.75 / 4) (#16)
by bnenning on Tue Jul 17, 2001 at 07:32:00 PM EST

There are documented ways to open a window in response to a menu selection. The easiest is to put the window in a nib file and have your menu action method call +[NSBundle loadNibNamed:owner:].

Cocoa can be confusing for new developers, but once you understand how it works it is amazingly powerful. I agree that the documentation should be improved, but there's nothing to stop developers from writing complex apps today.

That's not the point (4.00 / 3) (#17)
by GusherJizmac on Tue Jul 17, 2001 at 08:04:13 PM EST

The point isn't that it's not possible to write apps or that Cocoa isn't powerful, it's that the documentation is really terrible and far, far behind anything in Windows. The first time I used Visual C++ to do MFC, I was able to figure out, almost entirely on my own, how to open up multiple windows and dialogs. I only consulted the documentation for method and function prototypes.

With Project Builder and Interface Builder, I simply couldn't figure it out without looking at an example, and that example didn't use the method you are talking about. They really could make it easier without sacrificing their API. I'm just amazed that PB hasn't much changed in all this time. Have any of them used Visual C++ or JBuilder, or Visual Cafe? These are all superior products....
<sig> G u s h e r J i z m a c </sig>
[ Parent ]

ahh what a wonderful thread (4.50 / 2) (#45)
by mikpos on Fri Jul 20, 2001 at 06:47:45 PM EST

Poster A: "I agree the documentation needs improvement, but it's very powerful."
Poster B: "I agree that it's very powerful, but the documentation needs improvement."

Only on K5. Very amusing.

[ Parent ]

Delphi for Mac is needed (4.12 / 8) (#19)
by arbour42 on Tue Jul 17, 2001 at 10:09:43 PM EST

What an excellent article. I was thinking the same thing about a week ago. Without a VB/C# like development environment, Mac OS X will never become a common business machine.

If you can't make a good database front-end that people can use to input hundreds of records and spit out pretty reports, forget it. And browser front--ends do not count: the browser GUI is a piece of crap compared to a front-end i build in Delphi.

Apple needs to make their Interface Builder Delphi-like -and if they can't do it, contract Borland too, though that ain't likely.

Microsoft knows that once you've built 50 apps using VB (or even Delphi) for your company, you aren't going to switch operating systems. It won't happen, unless they can be rebuilt just as easily. This is something Linux needs badly, and Borland's Kylix is probably the most important app that has come out for Linux over the last year. We'll see what comes from that effort.

i really like the mac, and hope they do well - Apple has $4 billion in cash. take $30 million and dump it into building the right IDE: it will pay off 100 fold.

alex

re: Delphi for Mac is needed (none / 0) (#24)
by dadams on Wed Jul 18, 2001 at 09:11:03 AM EST

If you can't make a good database front-end that people can use to input hundreds of records and spit out pretty reports, forget it. And browser front--ends do not count: the browser GUI is a piece of crap compared to a front-end i build in Delphi.

This is exactly the point of the Enterprise Object Framework, or EOF. It makes creating slick DB apps a trivial matter. Interface Builder has a lot of support for it. Unfortunately, I think the only way to get the EOF is with WebObjects.



[ Parent ]
RE: Delphi for Mac is needed (3.00 / 1) (#32)
by pandaba on Wed Jul 18, 2001 at 08:45:44 PM EST

Actually there is a RAD and a fairly good one available. RealBasic is a product which is mostly syntax compatible with VB and can produce carbonized apps, and can also create windows apps. The latest version can integrate with the shell on X so it could even be used for simple shell programming. There's even a healthy dev community which produces some nice third party classes and components. It isn't as nice as Delphi but it is the best RAD available on the Mac.

[ Parent ]
Real Basic (none / 0) (#39)
by Revera on Thu Jul 19, 2001 at 09:56:33 PM EST

Last i checked Real Basic was the mac equivalent (read: almost exactly the same) to Visual Basic

[ Parent ]
Why not use java? (1.50 / 2) (#27)
by mveloso on Wed Jul 18, 2001 at 10:05:16 AM EST

Forget the objective C, and just go straight to java. You won't have to learn yet another weird language.

Re: Why not use java? (4.50 / 2) (#31)
by juri on Wed Jul 18, 2001 at 05:40:17 PM EST

Uh, Objective C is hardly weird if you know Java, the differences are cosmetic. You can learn it in an afternoon. Really.

In general, I have a hard time understanding this "I don't want to learn yet another language" thing. Usually, it's just syntax, which shouldn't be a big deal. It's just the same familiar ideas and it should be no problem handling them written in a slightly different way (especially when you are talking about two nearly direct descendants of C) if you have any programming experience. And learning new languages is good for you.

Besides, I would be surprised if you got equal performance from a JVM on PPC as from native code. It's not always a big deal, but sometimes it is (think about UIs written with Swing), especially if using Java doesn't buy you many other benefits besides the familiarity.

[ Parent ]

Single-Language Bozos (4.00 / 1) (#52)
by Robert Uhl on Fri Aug 03, 2001 at 07:20:58 PM EST

In general, I have a hard time understanding this 'I don't want to learn yet another language' thing.

In general, it comes form the sort of person who never really learned his first language--like a monkey, he imitated his trainers without understanding until they let him pass. Learning another language is fun, and as you note is a good learning experience. Haven't most hackers thought up their own üaut;ber-languages?

I can sympathise with your bewilderment. Methinks that people who don' wish to learn new languages are people who don't wish to program. That this trait is notable amongst Java programmers says something. I imagine that at one point it was notable amongst C++ programmers, and before then C programmers, and before then Pascal or Fortran programmers: the dominant (in terms of mediashare, not marketshare) language will draw the wannabes and nevercoulds. The rest of us will go on doing our jobs in whichever language is best suited to the task.

[ Parent ]

re: Why not use java? (4.00 / 1) (#33)
by pandaba on Wed Jul 18, 2001 at 08:50:52 PM EST

One more reason to use Java:

There's a beta JRE on the Apple Developer's site which will render an app's UI by using calls to OpenGL which makes any GUI Java app much faster than its Cocoa \ Carbon equivalent which is stuck using the mostly unaccelerated Aqua environment.

[ Parent ]
My personal solution - QT (4.66 / 3) (#28)
by dennis on Wed Jul 18, 2001 at 10:27:32 AM EST

Trolltech's QT version 3, currently in beta, will be available for OS X. A look at the new features mentions database GUI components, a full-fledged IDE, a cross-platform component model similar to COM, and lots of other nifty toys. Trolltech's documentation is excellent, and if you want to dive into the sourcecode that's nicely commented too. C++ developers who've used it tend to rave about it - it's a much cleaner api than MFC. I'm just now learning it, and so far I like it a lot. (And of course, your programs will run on Windows and Unix as well with just a recompile.)

My personal solution - wxWindows (4.00 / 1) (#41)
by tartlhuQ on Thu Jul 19, 2001 at 10:22:28 PM EST

WxWindows is my choice. It has a decent API, supports many platforms, is under a good license on *all* supported platforms (LGPL), has a lot of useful tools, etc.

All that's needed (IMHO) is AtheOS and OS/X support, and hopefully the BeOS support will come soon.

WxWindows.org.

--
Micro$oft: Happilly screwing people over and lining Bill Gates's wallet since 1975.

[ Parent ]

Question about wxWindows (none / 0) (#42)
by dennis on Fri Jul 20, 2001 at 08:37:15 AM EST

I was looking at wxWindows myself. The licensing is a definite plus. I had to pick one to learn first and QT had more docs, but I may well pick up wx later.

One problem I have is that I need sourcecode to a richtext editor. QT's got one, and I know wxWindows tends to wrap native components instead of reimplement them...what would you do to customize a text editor? (I can't just subclass something, I'm making deep, weird changes.)

[ Parent ]

wxWindows (none / 0) (#47)
by kurioszyn on Wed Jul 25, 2001 at 12:37:35 AM EST

Is relatively OK but lacks tons of nice utility classes some of which are covered by STL but still, it is nice to have Socket, XML support etc.
wxWindows , being wrapping toolkit, is also generally slower than qt solution and does not provide for theming (admitely rather abused feature)



[ Parent ]
OS X Projectbuilder isn't from NeXT (3.00 / 1) (#29)
by hask3ll on Wed Jul 18, 2001 at 11:55:21 AM EST

The Projectbuilder that ships with OS X (and WO 5 for OS X) isn't from the NeXT days at all. It's completely new. Anyone who has been reading the OS X developer mailing lists at all for the past few months knows this, and knows how much old NeXT developers dislike it. It's slow, has an annoying single window interface, and lacks a Miller column browser.

The old Projectbuilder still is available with WebObjects on Windows, and is called ProjectbuilderWO on OS X. It's much better, but isn't being supported.

Linking actions to buttons in IB works the same way as it does it WOBuilder, so I don't see why if the author is a WO developer (as he states he is) why it's "very confusing and counter-intuitive."

Some of the documentation is lacking, but Apple is working to update it, and I've seen many changes over time, from when I got DP3 up to the present. Unfortunately, there are only so many technical writers to spare, and a lot of APIs to document. There are many good references available from outside Apple, both on the mailing lists and from places like Stepwise

The article also completely fails to mention the Enterprise Objects Framework, one of the best parts of the stuff Apple got from NeXT, that is way ahead of anything else available (e.g. JDO)



Interface Woes.. (3.50 / 2) (#34)
by Chiron on Thu Jul 19, 2001 at 07:10:36 AM EST

Okay.. This is going to sound like a troll to anyone who likes OS X, but bear with me.. I loaded OS X on the wife's macintosh, mostly out of curiosity, and, frankly, I was tremendously displeased with the GUI. Aside from all the comments made by Jeff Raskin, who is a minor deity in my world, I just found the Aqua interface to be grossly excessive.

The main selling point of the Macintosh for my wife was its interface. It was clean, simple, and had relatively few pitfalls, compared to Windows, which she was brought up on, or the brute force sensibilities my Blackbox & Xterms bsd box, which she also understands, since she borrows my machine when I want to *ahem* play games on the big monitor.

At first, it looks wonderful.. But eventually, it all becomes rather annoying to my eye, and I find myself longing for simple, unobtrusive colors and simpler layouts.

Interface whining aside, OS X does intrigue me because one of my favorite environments to program for was NextStep.. I found Objective-C to be a joy, compared to C++, and, although NextStep's GUI is a little dated compared to modern toolkits, it had a very strong sense of internal logic. Unfortunately, when I start to program for OS X, I get the same lost feeling that I get when I start using JoeBob's GUI Tool Kit of the Week, due to Apple's current developer information being little more than a list of API calls. Sure, I can start studying the example code, but usually I miss the important little nuances of how and why someone did something that way.

My opinion is, while the OS X team was working very hard to look futuristic, and to give MacOS a more modern kernel, they weren't allowed the time to really consider how their modifications would affect the end user, or how to make it easier for developers new to the OS X environment to get their feet wet. Hopefully, Apple will resolve this as the product matures.

OSX a good idea, but..... (3.33 / 3) (#35)
by Orion Blastar on Thu Jul 19, 2001 at 09:57:13 AM EST

.....
Yes it does need developer support, as many developers as you can get for it. Just hope that it doesn't end up like A/UX or MkLinux, or even, dare I say it, NeXTOS/NeXTStep? It shall take more than just developers, that is for sure.

It also needs the software companies to throw behind it and develop OSX native programs to take full advantage of the OS. Otherwise users will have to run those Unix POSIX programs and MacOS applications. Sort of like OS/2 users running DOS and Windows 3.X programs a lot because the software companies stopped developing for OS/2 native programs. Remember when Lotus 123, WordPerfect, and other programs had the latest and greatest versions for OS/2? What happened?

OSX also needs hardware support to throw behind it for driver support. If users are going to upgrade their Macs to better video, audio, network, and other adapter cards, there better be OSX drivers for it. It was smart to adapt Linux drivers, but it is going to take more than that. When the new hardware comes out, better hope that it can work with OSX.

OSX is great; however, it seems to only run on Apple Macintosh hardware. To get the big corps using it, you'd need Apple Macintosh hardware with at least 32 processors in a server machine to get what they need. Either Apple needs to bring back the Mac Clones to do this for them, or they are going to have to make their own server hardware. Or they could just port OSX to IBM RS/6000 machines or other machines. Darwin still has a long way to go, but it does have potential.

OSX is a step in the right direction, in a few years maybe they will polish it up and come out with the support and hardware changes that the big corps need to run it? But in order to beat Microsoft, you have to fully compete with Microsoft. That means do almost everything that Microsoft is doing, have a counterpart to every software package that Microsoft makes. OSX is a counterpart to NT/Windows 2000/ Windows XP but where is the counterpart to BackOffice, MS-Money, MS Visual Studio, etc? If you cannot counter every move that Microsoft makes, then Microsoft wins. Then it becomes a poorly played Chess game where Microsoft has more pieces than any other player and can sacrifice them to knock the others out of the game.
*** Anonymized by intolerant editors at K5 and also IWETHEY who are biased against the mentally ill ***

Apple's Main asset is its user base. (3.00 / 1) (#40)
by woliver on Thu Jul 19, 2001 at 10:03:23 PM EST

In my experience, the user base is more important to apple than developers. That's not to say that developers are not important, but apple users are generally dedicated to their platform. Apple is aware of this, they created a shiny new GUI to try and attract them.

On the developer front they have at least bundled the tools with the OS. Compilers, libraries, an IDE and documentation (getting better with each release). This is not a small commitment and to my knowledge one of the only commercial OS's to give you the whole developer environment for free.

One last note, you can still program in C++ using carbon. There is a common belief that this is not native, not true. Carbon consists mostly of the old mac API's which could be based on the new CoreServices. That is, carbon is mostly native. There are a few issues with is but for most tasks they are pretty good, and in a language more people are familiar with.

All in all its not a bad job, a new OS, three native languages (C++, Objective-C, and Java). Give it time and the maturity will develop.



I disagree on one point (3.00 / 2) (#43)
by Betcour on Fri Jul 20, 2001 at 09:17:30 AM EST

is compatible with lots of hardware on the market

No it is not true - it is only compatible with Macs. This limit it to less than 10% of the personnal computer market. As long as Apple is counting on selling hardware to make profits, OS X will be limited. For now I'll just use Windows XP (yeah it's not as nice, not as powerful (no Unix core) etc... but at least I can install it on whatever I want)

are you drunk? (none / 0) (#50)
by Hakamadare on Tue Jul 31, 2001 at 05:30:18 PM EST

seriously, now.

but at least I can install it on whatever I want

you can install it on whatever you want as long as it's an x86 box, you mean. unless there's an Alpha port of XP somewhere, or a SPARC port, or a PPC port.

i suspect that the intent of the original statement ("compatible with lots of hardware on the market") was a reference to peripherals, not to CPUs. please think before posting.

there are sufficient real issues with OS X (voracious consumption of memory, poor handling of swap space, sluggish performance on non-Altivec CPUs, non-optimized Finder) for you to attack without having to resort to making vague, obfuscatory statements to hide the fact that all you really want to do is plug Windows XP.


---
Schopenhauer is not featuring heavily on the "Review Hidden Comments" page at the moment. - Herring
[ Parent ]

Whaaat? (5.00 / 2) (#44)
by asiufy on Fri Jul 20, 2001 at 03:07:20 PM EST

I still don't know what was your point here... Are you associating bad documentation with a platform's success?

First of all, OS X has not 1, not 2, but 3 "APIs" that can be used, Carbon, Cocoa and BSD. That will immediately bring all the MacOS developers of old (while not a huge number, at least they're used to the platform), Cocoa (old time NeXT folk) and all the BSD stuff (lots and lots of developers).

Then, you have the fact that even the NeXTSTEP APIs were in hibernation for a while, and now they're brought back as Cocoa. So, while it basically grew out of an existing API, Apple turned it into something new, and as anything new (1.0 versions), it's very hard to find quality documentation.

I have never read Microsoft documentation, nor do I want to, but I believe it took them more than a couple of months (make it years actually) to get it "right" (if they have it right at all). Give Apple some time to refine these documents and IDEs.

Also, even though Apple is bundling the developer stuff (IB+PB), 3rd parties will also be coming up with their own IDEs, compilers and environments.

The bottom line is: give Apple some time. Give it enough time so the developers are able to "digest" all the changes and adaptations required, after all, it's a new platform.

OSX will never compete with windows! (3.66 / 3) (#48)
by asv108 on Fri Jul 27, 2001 at 08:50:54 PM EST

With the recent arrival of OS X, many who have used it (myself included) feel that it is really the first thing in a while that could legitimately compete with Windows, as a server, business desktop and home system.

Compete with windows? How can OSX compete with windows when the only way to run OSX is to purchase overpriced proprietary hardware? The only way OSX could have a chance to compete with windows is if Apple ports it to x86 and it will be a cold day in hell before they do that. OSX has a ton of potential but it will never be realized because of Apple's insistence on using proprietary hardware only.

Port OSX to the PC (none / 0) (#53)
by physics on Thu Aug 16, 2001 at 09:24:16 AM EST

While I agree that developer support is needed for long-term survival in an OS, It's definitely the right hardware that makes for short-term user support. Without the users, why would developers bother?

When I first read a couple spec/hype articles about OSX, I mistakenly got the impression it was also finally available for the PC too (Unix underneath and all). I had plans to *buy* it and run it on one of may spare server boxes so I could get to know it better. I'll never buy an OS that forces me to ditch hardware that'll run "nearly every other major OS" and buy an expensive machine I may never use again.

Apple will never compete seriously till it get's off it's high-horse about the hardware. They should have learned from the Microsoft example that you don't have to be running top-of-the-line hardware/software to be generally accepted.

Never let your sense of morals keep you from doing what is right. - Isaac Asimov
[ Parent ]
so dumb - topic is so dumb (none / 0) (#49)
by BWS on Tue Jul 31, 2001 at 12:44:01 AM EST

[insert random os] will not succeed without developer support
-- Comments are by ME, not YOU! ME! ME! ME!
Apple to write key software (none / 0) (#55)
by solhell on Tue Aug 21, 2001 at 04:59:39 PM EST

As other people noted here, one of the reasons of Microsoft's success was that they wrote lots of key software by themselfes. I mean even games. They didn't wait other companies to write software. Currently Apple waits Adobe to port Photoshop to OS X.

I don't aggree that an OS needs a lot of software to be successful. It only needs to have a good versions of key software. Like a good web browser, good Office (and MS compatible), etc. No need to have 10 different web browsers to be successful. If you just have IE on OS X, that will be enough.
So apple should step in and write software, pay companies to write software, or find some other way to do it. With the linux/unix compatibility, lots of software will be available for Mac OS X and lots of BSD developers will be interested in it. Things like QT, GTK, Xfree, and many others are/will be available for easy porting. So the future looks very promising.

OS X server on Intel (none / 0) (#56)
by solhell on Tue Aug 21, 2001 at 05:09:15 PM EST

Sme people complained that OS X only runs on apple hardware. I truely believe that apple plans to release an OS X server for intel platform to compete with both linux and win2000. It is difficult for apple to keep up with the advances and intel based hardware is cheaper. Moreover with the upcoming 64 bit Itanium processor, OS X needs to run on it to compete.

Even though the GUI is not very important on the server, it matters if the interface is user friendly. I am not talking about aqua only. But easy and powerful interface for administring the server is important. Commandline isn't the best tool always.
For companies, if they can setup thin clients running OS X through a remote OS X servers, that will gain them a lot. Lots of competition for microsoft.
A powerful, scalable and (cheap) OS X server also increase sales of OS X desktops and imacs.

OS X Will Not Succeed Without Developer Support | 56 comments (52 topical, 4 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!