Re: ObjC/Cocoa/PB/IB vs. C#/.NET/er,something
Re: ObjC/Cocoa/PB/IB vs. C#/.NET/er,something
- Subject: Re: ObjC/Cocoa/PB/IB vs. C#/.NET/er,something
- From: Andy Satori <email@hidden>
- Date: Wed, 3 Sep 2003 11:10:38 -0400
I can, though, I'm probably a little biased.
First of, let's dispose of the notion that .NET is in fact one unified
platform. It's not, depsite the MS claims to the otherwise.
.NET is more like three seperate Toolkits. ASP.NET, Windows.Forms, and
a "Foundation" kit.
At the most basic layer, the "Foundation" is the CLR, or Common
Language Runtime. This is analogous to the JVM, or Java Virtual
Machine. Under .NET this Runtime is more or less language independent,
the reality is less than the marketing makes it. That foundation
provides basic services, and in .NET is a wrapper around the Win32 API.
Using just this foundation, it is possible to develop command line
applications that behave much like the equivalent of a Cocoa Java
'Tool'. This foundation is what has been approved as a Standards based
platform and is available on the Mac OS X today in a god awful slow
implementation via Microsoft's 'Rotor' project. The dotGNU project
also has much of this segment of the .NET framework to an almost usable
status. The Mono project is not quite usable on Mac OS X yet, but
appears to be the strongest Mac candidate of the options.
At the next layer, are the two other toolkits. Both are built upon
the ECMA standard foundation, but are not themselves part of the
standard.
ASP.NET is most like Java with JSP and Jakarta's Struts library. It is
the foundation of both the WebServices and the ASPX / Web Development
toolkit. While it does use portions of the foundation, it is only
vaguely related to Windows.Forms development. This is a Web framework.
Windows.Forms is the closest thing to the IB / PB / Cocoa framework on
the Windows platform today. It's an evolution of Visual Basic and
Visual C++ converging, with a heavy dose of Delphi and Java development
methodologies included.
As a developer that has spent many many years working on the Windows
environment, .NET is not your typical Microsoft project. It's probably
the most robust and robust new tool they've ever put to market. It
accounts for things that as a developer are extremely nice. It's
development environment is complete, and elegant, while being buggy and
crash prone all at the same time.
In terms of a unified approach, it's got a lot going for it.
Particularly in the following aspects.
(1) Ease of Remoting.
Write, debug test locally. Strong Name, Deploy to remote server,
export proxy, install proxy on client, user as if local. Or, write as
webservice, then use .NET to implement all the SOAP wrappers for you.
It will handle all of the XML-RPC hassles behind the scenes. This is
literally a 30 second implementation.
(2) One Tool for Most Needs.
If you learn one tool and one language, VS.NET / C#, you have
everything you need to develop Web Applications, Web Services, Windows
Applications, Command Line Tools, Shared Libraries, Scripts.
(3) Good debugging tools.
While not a direct hit at Cocoa, this is a big deal for those who
also do Web Development. PB and the Mac in general, have weak
debugging tools when it comes to Web Development. It's very nice to be
able to use a single tool to step from Web code into library code for
debugging.
(4) Built in Database tools.
My pet peeve with the Mac in general. Database access and the current
state of it basically stinks. FreeTDS for SQL Server, iODBC with no
drivers, JDBC and the Java Bridge overhead. Uggh.
On the downside, VS.NET is a pig. 148 meg minimum running footprint.
I've seen it balloon to over a gig of ram while debugging. The .NET
framework itself is a pig. It's a 28 meg ram just to run a command
line program. Admittedly, as more .NET apps appear this becomes less
of an issue as the run-times are already loaded and stay loaded, again
analogous to Java. The Global Assembly cache is in many ways a bigger
mess than the infamous DLL Hell. Look for most .NET developers to
quickly migrate to WebServices to avoid the nightmares of Strong Named
assemblies in the GAC with Remoted COM+ dll's and mixed mode interop
assemblies.
On the Cocoa / Mac side of the fence. PB and IB are outstanding tools.
Tools that appear to be maturing quite a bit with XCode, though I have
no direct experience with XCode yet. Database access and management is
an aspect that appears to be improving, though not to the degree of
what is provided by .NET. The ability to use Java, and to create EJB
objects within PB & XCode is a good thing. With the coming of Panther
and the built in JBoss, I see the potential for either Apple or a third
party to make some serious progress at making the Mac + Cocoa + Java
toolchain a serious competitor to VS.NET. Adding WebObjects to the PB
/ IB mix actually makes PB competitive from a technical standpoint to
VS.NET, but from a selling it to your boss at an "Enterprise" level
business is a non-starter. When was the last time anyone saw an
advertisement for WebObjects?
After all of this, I'm doing much of my development on a Mac. I use PB
for EJB development side by side with Cocoa & Objective C for UI tools.
I use Dreamweaver for JSP, ASPX & C# development on the web front. I
don't do Windows UI's much anymore, and when I do, I still use C++ and
ATL. Windows.Forms has too much overhead for my needs. I do run
VS.NET in a Virtual PC window to compile and debug my Windows code,
which is my day job, but when I get home, or I need a quick tool to do
something that is not destined for the corporate source code
repository, it's done in Cocoa and Objective C or Java in Project
Builder.
Andy
On Wednesday, September 3, 2003, at 01:16 AM, Kenneth Ferry wrote:
Can anybody comment meaningfully on these development systems? The
little bit I've read about .net seems cocoaish to me..
Thanks,
Ken
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.