[Hinson]

Okay, I'm a Mac user at home--used Macs since 1989, never owned a non-Apple computer, OS X combining Unix and the Mac was a dream come true, etc.

At work, I've done various programming jobs for our Window's environment (not a professional programmer, but I can hold my own pretty well). In the last few years, that work was done with Visual Studio and the .Net environment. I think that this is the best stuff MS has ever put out (I know, not necessarily saying much, but its hand's down the best coding environment out there, I believe).

Now, I've also tried some stuff in XCode with Objective C. Yikes! Compared to XCode, it's like VS.Net is to XCode as Mac OS is to Windows (and probably more of a Windows 95 era comparison). I can't imagine others not seeing this. If you have no idea what I'm talking about, check out the two videos at this URL (very simple stuff, but it gets the point across):

Visual Studio for Windows vs XCode for Mac OS X

Anyone else find this embarrassing as a Mac guy/gal? Honestly, I'm starting to think that Apple should pay MS to make VS for the Mac with full support for the .Net framework. It does some pretty awesome stuff (one of many, many examples come to mind: how easy it is to use DataSets to connect to and exchange data with a database, interact with a DataTable's data using a DataGridView simply by pointing the grid's DataSource property at the DataTable, etc, etc, etc.)

If I had to do development at home, then for the first time in my life, I'd seriously consider purchasing a PC. Not that you care what I buy, but the point is that VS.Net vs XCode is that big a difference to me.

Anyone else see it that way?


-Jay

[Chuckit]

A different perspective. Some salient quotes:

"My first reaction was to drop Xcode and go back to Visual Studio where I felt comfortable. You know how, even though something might actually smell really, really bad, the fact that you're familiar with it and might even call it home makes it endearing? The same is true of a development tool. Regardless of whether your tool is good or bad, the fact that its the tool you've been using for years makes it feel comfortable and familiar, like a security blanket."

"I took a step back and tried to figure out what the hell was going on. After a few minutes, I realized that Xcode was actually doing a really, really, really good thing."

"I am used to right-clicking my Visual Studio 200x project and adding elements to the project. Its fast, its easy, and it keeps everything in a single, easy-to-find location. Here's the rub - keeping things in a single location like VS 200x does might not be the best thing."

(He's got several more interesting entries under the Mac category as well.)

[Warren Pease]

Originally Posted by Hinson 

... I can't imagine others not seeing this. If you have no idea what I'm talking about, check out the two videos at this URL (very simple stuff, but it gets the point across):

Visual Studio for Windows vs XCode for Mac OS X

I don't think the videos make a good case. First off, one (MS) is aimed at just writing the app and running it, the other one (XCode) has more of an explanation of what is going on. So the blog writer complaining about the length of the video seems pretty stupid.

If all you want is an application that makes a sound when you click on a button (because this kind of application is quite indicative of the power and capabilities of XCode and VS.Net), you don't even need to write any code in XCode to accomplish this; simply apply a sound in the Button Attributes of Interface Builder. Took me all of 30 seconds.

[olePigeon]

I think the real power is in Integer BASIC.

[beg_ne]

Originally Posted by Hinson 

Anyone else see it that way?

Nope not at all. Although from the VS video I do get the following impressions:

1. Holy crap there is a lot of junk in the way, how the heck are you supposed get any work done with all those split views eating your coding space??

2. How pathetically stupid it is setup to do the most basic UI stuff. You have to go the the properties "window" to change the button text, as well as having to explicitly set the button to resize to the correct width...ugh.

[alex_kac]

1) You customize things to the way you want it.
2) That's the stupid way to do it. No real programmer worth his salt would do that. You lose any localization usage.

The fact is that VS2005/2008 is an awesome environment. However, Xcode 3 is, from little I've seen, just as good or even better. Cocoa can do what .NET does too, but you have to learn the framework. Just like .NET.

As a C++ programmer using direct Win32, I find .NET incredibly stupid. Sure its great for writing business apps, but not commercial apps. Cocoa, on the other hand, is great for both.

[smitty825]

I kinda agree with the first poster, but for different reasons.

First, regardless of which settings you chose, it seems like the XCode designers couldn't decide if they wanted to do a multi-document-interface or a single-document interface. This annoys me :-)

Secondly, one cannot customize the application as readily as Visual Studio. For example, on Visual Studio, it's trivial to replace the buttons on the toolbar to allow me to chose to run the program in debug mode or not. On XCode, I'm stuck with the default buttons of "Build", "Build and Run", etc. (Granted, there is the "Active Build Configuration" pane, where I can define how I want that configuration to be built)

Third, GDB takes _forever_ to launch whenever the application is built in debug mode. The Visual Studio debugger launches much more quickly in my experience.

Fourth, Visual Studio is an order of magnitude more stable than XCode (well, mainly interface builder) While I've experienced several "lockups" with Visual Studio in large projects, it's nothing compared to the number of crashes I've experienced using Apple's Tools. (Anytime I look at IB funny, it crashes)

(Note: These comments are just on the tool. Discussing the advantages/disadvantages of each framework is a completely different discussion for another day)

[Chuckit]

You can customize the toolbar in Xcode — including putting a Debug button.

[Hinson]

Originally Posted by beg_ne 

Nope not at all. Although from the VS video I do get the following impressions:

1. Holy crap there is a lot of junk in the way, how the heck are you supposed get any work done with all those split views eating your coding space??

2. How pathetically stupid it is setup to do the most basic UI stuff. You have to go the the properties "window" to change the button text, as well as having to explicitly set the button to resize to the correct width...ugh.

Okay, on the first point, VS's interface is very customizable. If you don't like all the split views, just close them or drag them into one-another to get multiple windows tabbed in the same docked area or set them to auto-hide or drag them out and make them float. VERY customizable and much cleaner the XCode's multiple floating windows.

Second, "pathetically stupid" seems pretty soaked with emotion, not thought. You don't HAVE to go to the properties window to set the text. When you first create it, just type a new name. But there are some properties of controls (like a button) in VS that I don't find in XCode--not to mention some cool controls (though I'm sure that goes both ways). The Dock property is an examle. Dock a flow-layout container at the top of a window and you get a strip that's stuck to the top and resizes left and right as the window resizes (a flow-layout container is just one of .Net's cool controls--don't worry about specifics). Now, add--for example--a user-control (a panel-like class that you customize with certain components) and set it's docking property to "fill" and it will fill in the rest of the window, automatically resizing as the window resizes.

I also wonder about comparing .Net events to XCode. In .Net, components have several events (like click, double-click, mouse-down, mouse-up, mouse-hover, mouse-move, move, resize, drag/drop events, events that fire when certain properties change, etc, etc.). You can subscribe to an event so that when it fires it calls one of your methods (with the right signature, of course). A single event can activate multiple event handlers when it fires, and in your classes you can build your own events so that external modules can act when your event fires. They're even good for cross-thread actions if you invoke them correctly. I'm sure someone will tell me how the equivalent works in XCode, but I really like the way .Net does it.

I also find VS's intelli-sense very well done. you get the list you need when you need it. Hover over a field/property/method and get a tool-tip showing you what it is. Then, when you're in debug, hover over a property or field to see its value instantly.

Finally, what about setting properties of a component programmatically? In VS, a component is just another object. It has a name that you can set (like button_ok, for example). If you want to change a property, you do it like any other object (like button_ok.top = 25; button_ok.AutoSize = false; button_ok.Width = 20; ). Perhaps its just as easy in XCode--I'm sincerely asking about it.


Thanks for the reply.


-Jay

[Hinson]

Originally Posted by alex_kac 

1) You customize things to the way you want it.
2) That's the stupid way to do it. No real programmer worth his salt would do that. You lose any localization usage.

The fact is that VS2005/2008 is an awesome environment. However, Xcode 3 is, from little I've seen, just as good or even better. Cocoa can do what .NET does too, but you have to learn the framework. Just like .NET.

As a C++ programmer using direct Win32, I find .NET incredibly stupid. Sure its great for writing business apps, but not commercial apps. Cocoa, on the other hand, is great for both.

Are you really comparing Win32/MFC to .NET and calling .NET the incredibly stupid one? This seems totally backwards in so many ways. Just one tiny example--I never worry about how to link libraries in .Net--it just works. You reference the project or module, include the namespace at the top, and then just use it--period. Compare that to exporting/importing from .dlls and which one seems stupid?

Just my opinion, I guess.


-Jay

[Hinson]

Originally Posted by Chuckit 

A different perspective. Some salient quotes:
...
"I took a step back and tried to figure out what the hell was going on. After a few minutes, I realized that Xcode was actually doing a really, really, really good thing."
...

XCode's forcing of MVC has its benefits, but the ability to do MVC WITHOUT being forced is better, IMHO. In .Net, components are objects. Objects have fields, properties, methods, and events (in general). One property of a class derived from a Form (the basic window element in .net) is a list of components that it "owns." It makes COMPLETE sense to program those controls within the code space of the form that owns them--that's where they have their scope; it's where they live.

Access external methods to do non-GUI related tasks (like calculations, etc)--that's good coding because the methods don't depend on the existence of the GUI. But if a button needs to take the results of the calculation and display it in a field on the form, do that inside the code space of the form class that owns those controls. That's also good coding. It just makes sense.

When you double-click on a button, behind the scenes VS adds code that subscribes a method to the click event of the button and creates the declaration of that method for you. It's not magic--you can code it directly if you like. That code resized inside the class that owns the button (generally, a class derived from an existing component class). You're designing the "controller" class as a derivative of a base component class (a GUI element). For best practices, you should keep that design specific to the GUI interactions, but that's you're job as a programmer. It's pure object-oriented thinking, as I see it.


-Jay

[Chuckit]

NSViews are objects in Cocoa as well. In fact, all Interface Builder does is create a tree of objects and serialize them in the nib file. I'm not sure what you think is going on in Cocoa, but it's really all just objects connected by a few common design patterns.

It sounds to me like the problem is that you are familiar with Visual Studio and not with Cocoa. It might change your view to actually do some stuff with it.

[CharlesS]

Originally Posted by Hinson 

Finally, what about setting properties of a component programmatically? In VS, a component is just another object. It has a name that you can set (like button_ok, for example). If you want to change a property, you do it like any other object (like button_ok.top = 25; button_ok.AutoSize = false; button_ok.Width = 20; ). Perhaps its just as easy in XCode--I'm sincerely asking about it.

And in Cocoa, they're all plain old objects too. Specifically, your button is an NSButton object. Read the documentation for NSButton to see what you can do with it.

NSButton Class Reference

[alex_kac]

Originally Posted by Hinson 

Are you really comparing Win32/MFC to .NET and calling .NET the incredibly stupid one? This seems totally backwards in so many ways. Just one tiny example--I never worry about how to link libraries in .Net--it just works. You reference the project or module, include the namespace at the top, and then just use it--period. Compare that to exporting/importing from .dlls and which one seems stupid?

Yeah, I am. Yes, there are many nice things that make things "just work", but there are many aspects of .NET that because of that design also are stupid. Well for commercial application developers. If I was an IT shop, .NET is a dream.

As a C++ and .NET dev, I've never had trouble finding what to link in C++. All of 30 seconds to check in the docs what to use. With .NET you still have to know what reference to use. What's the diff?

BTW - I've been using .NET since 2000 or so when it was in beta. I've been programming in C++ commercially since 2000 as well.

[VLich]

As a fairly frequent user of both VisualStudio and Xcode, here's my take:

VisualStudio has the best debugger I've used. It's fast, it's easy to use; it's also really good at displaying variables. Things like showing the return value of functions without having to step into them really make debugging easier. The only part of the debugger I don't like is the view memory window which is basically useless. Maybe it's better in 2008?

In contrast, Xcode's debugger is slow and gets confused easily. For objective-C, I've basically given up on using it for more than stepping through code and the "Print Description to Console" function.

VisualStudio also has great autocomplete support; Xcode's works OK but it doesn't restrict its suggestions as well based on context.

However for project management I much prefer Xcode. VisualStudio has trouble keeping track of files and search paths; it seems like I'm always fixing them. The file management pane is much clunkier than Xcode's and integrates poorly with explorer. Part of this is because of the MDI setup which I also find terrible - things like dragging files into a project become a real chore.

Along the same lines, I like Xcode's multiple floating windows a lot more than VS's monolithic window. I always feel cramped in VS, and I'm always hunting for the window I want. In fact, I find VisualStudio's interface in general to be very awkward and unfinished feeling.

[GoPe]

Originally Posted by alex_kac 

Yeah, I am. Yes, there are many nice things that make things "just work", but there are many aspects of .NET that because of that design also are stupid. Well for commercial application developers. If I was an IT shop, .NET is a dream.

What are you taking about??? Can you elaborate on this?
The fact the you think Win32/MFC is better than .NET tells me that you obviously do not understand .NET - the dll hell, anyone?
In enterprise solution you'll have few different versions of the same dll that are referenced by number of other dll's - there is no elegant way of dealing with it in non .NET environment (COM?)

.NET not good for a commercial application developers? Well the only thing that is not good is that you cannot protect your intellectual property, in other words anyone can crack you serial number.

------

I have not used Xcode yet, I'm trying to find some spare time to try it...

One thing that I like about .NET is that an application written in .NET can run, with support of Mono, on Mac, Windows, Linux and Unix, while a Cocoa app would only run on Mac .

[Brass]

Originally Posted by GoPe 

One thing that I like about .NET is that an application written in .NET can run, with support of Mono, on Mac, Windows, Linux and Unix, while a Cocoa app would only run on Mac .

Here's hoping Apple brings back the Yellow Box one of these days. I wonder if they've still got it running in secret in some basement lab - as they claim they did all along for Mac OS X for Intel (originally the Red Box, I think?).

My memory is completly knackered, but I think in the Rhapsody days, the Blue Box was the Classic environment (ie, Mac OS 9 running on Mac OS X for PPC), the Red Box was Mac OS X (Rhapsody) running on Intel, and the Yellow Box was effectively Cocoa for Windows. The Yellow Box is the only one that never saw the light of day in a production release.

[Chuckit]

Red Box was supposed to be to Windows what Blue Box was to Mac OS 8/9 and Yellow Box was to OpenStep — it would let you run Windows apps under Rhapsody. I don't think it was ever real.

[Brass]

Originally Posted by Chuckit 

Red Box was supposed to be to Windows what Blue Box was to Mac OS 8/9 and Yellow Box was to OpenStep — it would let you run Windows apps under Rhapsody. I don't think it was ever real.

ah... sounds like I had it the wrong way around. Never mind.

In any case, it would be good if Apple were to produce the Cocoa frameworks for Windows.

[CharlesS]

It would certainly be good for Cocoa programmers. It would expand our audience quite dramatically. It would also be good for the variety of software available for OS X, as it would attract a lot of new people to Cocoa. Unfortunately, I think Apple considers Cocoa to be a competitive advantage of OS X that they don't want to give away.