*Words of Wisdom From The Elder

Interesting, but it more shows the faults of osx/mac development than anything specifically pro VS. I'm not knocking VS, but VB has been providing ways to do that sort of stuff, as trivially as you did in VS, since at least 1994 (likely earlier). That sort of basic 'button click sound' is pretty trivial in netbeans/java as well (can't speak for eclipse)

I would agree it was far lengtheir than your presentation - probably could have been done in 3 minutes, but the dude doing it didn't seem all that prepared.

That's pretty much my point to show the difference in the two. The point is isn't to focus on the code to make the computer beep that is trivial, it is the steps and lack of elegance and usability on developing for Mac OS X that is the problem.

Comparing VB to what we do today is still far fetched, yeah it is still visual studio, but technology wise night and day.

The only problem with your comparison is that the Xcode tutorial actually is more informative. He's teaching us about the actual development environment and how you can wire interface elements generally. If he were to use your outline, he probably could have finished in the same time.

Pretty silly comparison, you didn't even notice the MVC approach taken in the OS X sample.
The OS X sample was provided as a tutorial, paying attention to the message sent to the listener, panning over the screen to make it more readable. Your sample was just to prove that you could make it faster. No clear messages, no clear video, basically useless.

The main points I get are that (1) your video is better and more directed, but (2) the Xcode video spends more time talking about the development environment.

I have programmed a little in Xcode and it is fair to say that it takes some getting used to using IB and Xcode in concert. However, I don't see any huge differences between VS and the IB/Xcode development cycle. You're just used to VS and not used to Xcode.

Only place where XCode is inferior to MS is in the compiler. gcc was never designed for IDE so Apple has to go through hoops in order to give the amount of functionality that is present.
I hope that is showing XCode 3.0. In the future,
Apple will pass Microsoft in this deficit.

Regardless of how long mine took count the number of steps in each one. The winner is clear. Sorry about the video the video looked fantastic after I had recorded it, blame YouTube and Flash player for making it look like crap, not my fault.

The other point I'll make about this is that Xcode may have more overhead for small projects, but scales very well to large ones and the Cocoa frameworks give huge amounts of free functionality, especially in Leopard (10.5).

VS reminds me of Realbasic, which I've also used a little. For small projects, it is trivial to use, and it is all-in-one and looks a lot like VS. However, it doesn't scale as well to large projects...Xcode is better for that.

So, a more useful comparison, but harder to put in a short video, would be VS against Xcode for a more realistic (ie, large) example.

@Chuck, show me large scale enterprise applications written in XCode that have scaled to thousands and thousands of users that were built by large teams of developers. What are you refering to besides an opinion? To say VS doesn't scale cannot be more of a ridiculous comment. What proof do you have? You are just throwing out FUD and not backing it up. I've built large scale enterprise applications in team environments and scaled those applications to thousands of applications. What do you have besides an opinion?

BTW, I meant those applications to thousands of users.

Let me clarify. I said

"VS reminds me of Realbasic, which I've also used a little. For small projects, it is trivial to use, and it is all-in-one and looks a lot like VS. However, it doesn't scale as well to large projects...Xcode is better for that."

I meant Realbasic doesn't scale for large projects. I'm sure VS does (although I don't use it). My point is that what you think of as complexity in Xcode/IB is exactly what makes it useful for large projects, like, say, oh, OS X and all the Apple iApps.

Comparing VS and Xcode on a toy example is just not useful. You're bound to favor the one that you already know.

You ought to actually use Xcode for something real before deciding on the utility of the tools.

I'll leave a comment since my trackback system is being temperamental but I threw together another video using Xcode 3 to see if the steps are streamlined a little further. There has definitely been some improvements from my Mac developer perspective. I'll freely admit to the steep learning curve though. :-)

http://blogs.seapine.com/grant/first-look-at-xcode-3.html

Ok Chuck you said I ought to use XCode before making a decision. I've owned a Mac for years and have spent a lot of time researching XCode, development on OS X a lot compared to the Microsoft platform. As a matter of fact if you'd told me 5 years ago I'd be writing applications on the .Net platform and actually liking it I'd thought you were drunk. Why don't we do this.

Let's take a more complicated example and compare notes. We are all about learning how the other half lives right? If nothing else it could be a fun experiment.

I have a presentation that outlines a very simple scaled down three tiered application an enterprise developer would build with a database, SOAP services in the middle tier and a user interface which is the client. It can also be deployed to users simply by copying the files to a web server (we call this ClickOnce in the Windows world, I don't know what you call this in the Mac OS X world) and it updates itself automatically if a new version is copied to the server. Business rules are stored in the middle tier and it is built in a three panel layout style. While the code in the solution is made to learn the architecture it does work and I think would be a great thing for someone on the OSX side of the house to build. You can get to the source code here along with screen shots and a powerpoint:

http://keithelder.net/Presentations/DevelopingSmartClientAppsForEnterprise/default.aspx

The presentation I'm talking about is the second one by the way, not the first one.

I'll take on making a video of how that solution is built for the Windows platform from scratch and if someone else wants to tackle it for the OSX side of the house I think that will give us a better apples to apples comparison.

My take away from watching this is that the INTERFACE for XCode is alot more confusing and busy then Visual Studio. The actual coding seems to be alright, but watching the XCode video makes it seem like the IDE would get in my way, VS doesn't.

It's not about the technology it's about the tools. If I tried to code Objective-C and Coca in VisualStudio it would rock, if I tried to do C#/.NET in XCode I think I would go nuts...

Hi Keith,

I did a little head-to-head comparison a couple of years ago myself and came to some of the same conclusions. I haven't upgraded to Leopard yet so I can't comment on the new version of XCode and Objective C 2.0. There are two points where Xcode + IB shines over Visual Studio.

1) Enforcing the MVC pattern - the entire framework and interface design tool are built around MVC. With Visual Studio, as you demonstrated, it's very easy to fall into the drag-and-drop mush world of application design.

2) I never get the sense that IB is working against me. I feel like I'm fighting Visual Studios designer much of the time.

My personal opinion is that dynamic dispatch/message passing languages are much more productive that static languages. So in that respect, Objective-C wins for me. But thanks to the effort of John Lam and the IronPython team, that won't be the case for very long. :)

http://www.lazycoder.com/weblog/index.php/archives/2005/11/08/xcode-and-visual-studio-go-head-to-head/

I'm sorry but the MVC argument is getting really old and if that is the only leg you guys have to stand on it is sad. MVC is a pattern, guidance, not God's gift to programmers and by its nature is more complicated. In Visual Studio we have choices. I can chose to write my very little simple application that gets the job done and move one. Or, I can install a plugin that provides an MVC architecture in a client application (smart client software factory). I have choices, I see that as a bonus not a drawback.

We've only looked at one very very very very simple example and not even all of the other things that Visual Studio is capable of such as mobile applications, office integrations, windows communication foundation for building services, Windows Presentation Foundation (puts Cocoa to shame), Workflow Foundation, fantastic debugging, built-in unit testing, database source code versioning, load tests, architecture diagrams, clickonce, intellisense, javascript debugging (2008), silverlight, biztalk orchestrations, team source control, task tracking, data acess, web services, LINQ, and a bunch of other stuff. Look at the entire platform and you'll see this race was over way before it started.

Ah but that's getting back into underlying technologies. For me that wasn't even part of what this comparison brought up.

It comes down to this, make simple things simple and hard things as simple as they can be. XCode appears to make simple things harder then they need to be, REGARDLESS of platform.

Remember this is suppose to be about Visual Studio vs XCode not Windows vs Mac or C# vs Objective-C or WPF vs Coca....

I can't use XCode on Windows and I can't you Visual Studio on a Mac. At the end of the day it is about the platform. Sorry, I disagree Michael.

Indeed, you can't. But XCode could emulate Visual Studio's paradigm.

SharpDevelop is an example of a Free Visual Studio "like" environment.

Could and will are two different things.

I just want to say, that reading rants like this, no matter what technology is being touted, is exactly what turns me off to the speaker immediately. You sound overly aggressive, like you HAVE to make your point and that people HAVE to listen to you.

You're right, it is about choice. At the end of the day, most of us will not write simple applications that you can just drag and drop and be done. Sometimes the very nature of the IDE, be it from Microsoft or Apple over complicates development by enforcing and encouraging a paradigm that does not necessarily work for a particular job.

In this case, were you building a simple beep application, Visual Studio wins hands down, you did not need the power of the MVC pattern behind this app. Controllers were wasted architecture.

I think the point of the original tutorial was an introduction into how Xcode worked though, not how to write a beep application. Writing the beep application just happened to be the method the author chose (I will say, the Xcode tutorial was poorly thought-out and the presenter should have practiced it a few times, there are do-overs in the Internets).

In the end, I appreciate and admire that you are so passionate about what you do, but just because it is right for you, does not make it right for everyone else. Your point about Apple and enterprise tools is a very valid one, except, Apple never tried to say they were up to snuff with Microsoft when it comes to the Enterprise.

Apple is more about the individual and small team. Not to say Microsoft isn't. Microsoft just has the enterprise market cornered and I don't think Apple even pretends to want to compete there. Not at the moment at least.

With that all said, I'm going to go rip a movie on my MacBook Pro, play some games on my XP box and compile some code on my Linux box. Because, it is about the right tool for the job and I enjoy all three of them for their strengths and weaknesses.

P.S. Speaking of usability, thankfully Safari 3 let me resize this tiny textarea box. Otherwise I would have gone mad trying to fit this all in. :)

P.P.S. Though I'm addicted to running my unit tests from the console and writing my code in plain text, I think both Visual Studio and X-Code are very interesting and I have fun playing around with them. I have found that I rewrite more of the code that Visual Studio auto-generates than I do that of Xcode. That's just me though.

"For the record, XCode is developed by the same company that everyone praises for being the poster child of usability."

Yes, that was exactly my feeling when I bought my first Mac in 2005 and opened Xcode for the very first time. As much as I love the user experience that OS X give me, I do miss the developer's paradise that Windows provides.

I want to have C# and be able to write native apps for OS X with it. I want to have an IDE like SharpDevelop (it doesn't need to be Visual Studio). Xcode and Objective-C are just not for me.

For more than two years now, I am in the situation that I prefer to --use-- OS X and its apps, but I don't get warm with it as a development platform. Since Apple does not give much love to Java either, that's also not really an option, at least not for GUI applications.

For those of you not seeing the advantage of the little extra MVC work in this contrived example, take it one step further. Do a UI with 2 buttons that cause a beep. In the VS example, you will have to repeat the steps all over again, including creating another code file for another OnClick() method, or you will have to start inheriting your UI classes which will involve a bit more work. In the Cocoa example, since you separated the model behavior from your button view code, all you do is drop in another button, drag to hook it up to the controller object, and you're there. The take home message of watching these demos side by side is not that you can make a pointless program in fewer clicks with VS, it should be to see the potential flexibility that the Cocoa way of doing this example gives you. Yes you can write MVC code in .NET as well, but the pervasiveness of MVC in the Cocoa framework make it easier.

As for the UI issues comparing the two, really it's a OSX vs Windows issue that comes down to preference. Myself I actually just turned down a job since I refuse to work in VS ever again. Look at the program in the video, only about 25% of the screen space is actually used for my code editing. Want to have a code file side by side with a web page, email, and IM session, that will take a minute of resizing things. If you like and are familiar with the OSX way of handling SDI applications, use expose, hide/show apps, etc, then the XCode UI shows you only the parts you need when you need them, and doesn't clutter your workspace like VS does. Simply trying to look at two code files side by side in VS is an exercise in frustration. Using it makes me and pretty much every other Mac user feel claustrophobic.

@David,

MVC is cool David but it isn't needed in every single application built in the world. For your example of adding another button there wouldn't be another code file or inheritance in UI classes or anything like that needed to clarify that for the general public. Let's not make it sound over complicated and FUD the discussion.

If I did your example I would create a method to "beep" (we'll call this my model) and then simply invoke that method in both onclick methods. That's all your controller is doing is invoking the same method in the model but in reality under the hood an event still has to fire. There would simply be another click event that would call into the model. Something like:

onclick()
{
Model.Beep();
}

Second_Onclick()
{
Model.Beep();
}

Inheritance isn't needed, another file isn't technically needed although I could and probably would place this Beep() in a seperate project if I was doing .Net development.

If you want to see a MVC .Net application built and how that is or would be typically done I invite you to check out DevExpress's XAF framework. It is commericial but does MVC and shows how that is / could be done in VS if you so choose.

http://www.devexpress.com/Products/NET/Libraries/eXpressApp/QuickStart.xml

@Keith

How on earth am I adding FUD to this discussion? I made a point of mentioning that nothing in VS prevents you from writing MVC code, only that you are comparing classic MS style double click and code to a properly designed MVC example and then drawing the sweeping conclusion that:

"... Apple doesn't do anything to provide developers, especially those in the enterprise, a rich programming environment and I think the comparison in these videos drives this point home."

And then, despite the fact we are already comparing the free XCode to a very pricey VS, you go on and counter the MVC support that Cocoa (also free) provides by pointing me in the direction of the XAF framework, yet another expensive product. Then you claim that it is Apple in fact who not providing it's developers with a rich programming environment? Who is spreading the FUD now?

Here's a blog post by another .NET developer speaking on the same issue that you observe here, yet drawing the exact opposite conclusion

http://dotnetaddict.dotnetdevelopersjournal.com/dcacs.htm

His conclusion is that Cocoa in fact forces him to break bad habits which are allowed or even encouraged by the VS workflow.

Several people have pointed out in the discussion that MVC is overkill for this example and Cocoa in fact makes simple things harder than they should. The problem is doing things the wrong way with one button is one thing, but nobody ever writes a one button application. Every new feature gets implemented in the quick easy way, until it has ballooned into a poorly architected unmaintainable nightmare. Again nothing prevents you from writing things the correct way in VS, but in Cocoa you are forced to do it the right way, and this I would argue is a major advantage.

In a way we are back to the C++ vs <almost any language> argument. C++ gives you the choice to do anything you want, including blow your foot off. For this reason people are moving away from C++ to languages like C# for instance. If you choose your language because it doesn't let you do the wrong thing, why wouldn't you choose your development environment that way too?

I have to agree with Dave about the design of Apple's dev environment being better than VS. Having all those panes in one window is fine if you are just editing short lines of code but if those lines get long and complicated it a pain to use. If you separate your interface design tools from your coding tools and like in Xcode also have the choice of separating your coding window from your project files then you can have plenty screen space to view and read through your code. Also if you try the latest beta of Xcode 3.1 you will see some really sexy features added to help you with your projects. In my opinion the Xcode / IB setup on multiple screens is so the ideal solution. You should try it properly Keith before slating it. Why don't you have a go at porting one of your personal projects to the Mac using Xcode 3.1?

I just read the link Dave sent over for the blog of the guy that usually uses VS but now prefers Xcode/IB for the good architecture habits that the combination encourages with it's adherence to MVC.

I think you really should get rid of your prejudices Keith and put aside your preference for lazy click and code development and read the blog and all of the comments below with an open mind. Then properly port one of your own apps over to it. See how you feel about it then. :-)

This is an utterly pointless comparison. I can whip up a program that puts up a button that beeps in the old Amos Basic for Amiga, but that doesn' say anything about what it's like to program in that environment.

I don't have an opinion on which IDE or API is best, but to make a fair comparison, show us:

* How well is the IDE and debugger integrated, how well does the debugger interpret binary data in memory and associate it with your code?

* How does the interface builder app generated files relate to the GUI API, and how does generated GUI files relate to your code?

* In what ways do the IDE assist you when you're coding; code completion, parameter hints, code generation etc.

That's just a few things that you want to know if you're doing a real application. How fast you can whip up a skeleton app that does next to nothing tells us nothing at all about how well the environment is suited for app development.

(I happen to prefer VS to Xcode too, but that's irrelevant.)