Thank you for sharing your experience. I am surprised to see no one
reply your message. For the thread, here's what I have to say. The
original poster shared some frank and sincere experience and feeling.
However, it lacks sorely the technicality of the comparison.
For example, no links to the video demo the guy was talking about, no
point about each feature, and why he thinks one is better than another.
I didn't look at the video, but scan through the tutorial, I was
surprised to find out that Netbeans and Creator would do most of the
things it shows. What tool did the author used? What kind of app did
he develop (I know he mention J2EE, but that's a large spectrum).
From playing with the previous version of the studio (2003 or
something), looking at many of the tutorial today on the site, I don't
see much advantage. For the language itself. I have seen discussion
about delegate, and other stuff and I don't see a clear advantage. I am
surprise the thread head thinks it is. I programed in Swing and the
event model seems to fine for me. It's never was a problem for me. The
IDE needs better GUI development support, but not the language. Layout
also is a bit problem, but 10 times better than the old VB days. With
Netbeans 5 and Matisse, I think the thread head should check it out and
compares a bit better.
I see a lot of praise from the thread head, but I just don't see the how
that is true.
George Sexton wrote:
I've been developing with Microsoft Products for 15 year. At one point I was
an MVP, and I was on the original MVP program steering committee. Here's
what I can tell you about MS product development. A lot of my comments are
going to be about FoxPro, which I used most, but the same issues exist with
other tools.
Corporate strategy drives tool development, not developer desires. Several
years ago, with FoxPro, OLE forms was the big thing. So, the bulk of the
development effort went into creating the ability to run FoxPro forms as OLE
controls in a browser. None of the developers wanted it. They wanted an
improved report writer and menu system. No one that I know ever used this
capability.
There are ALWAYS a lot of unexpected problems when using MS tools. Take for
example, memo fields and ADO. You basically only get one shot to read a memo
field from an ADO result set. Once you access it, its consumed and you can't
get the value again. There's also a problem in ADO if you don't make sure
that memo fields are the last elements in a select list. In FoxPro, if you
assign a string longer than 200 characters to a caption, the caption isn't
displayed at all. Its not truncated, and it doesn't throw an error, it just
doesn't display. You're just sitting there, scratching your head wonder why
the heck it isn't working. If you create a view in FoxPro that is "select *
from table", and someone modifies the base table, you'll get an error
opening the remote view, and you have to drop the view and re-add it. Don't
even get me started on Windows Installer technology.
Bugs RARELY get fixed. There's a problem in the Excel ODBC driver. If the
first 6-8 rows are digits, the driver assumes the column type is numeric and
will throw an error if later rows have characters. There's supposed to be an
override feature to set the type, but it doesn't work either. Another
example is THEAD/TBODY tags. There is a KB article for IE 4.0 (Q190278)
saying that failure to support THEAD/TBODY tags for printing was a defect
(although the revised KB article now says this is by design). This was never
fixed in IE 4.0, 5.0, 5.5, or 6.0. I don't have IE 7.0 so I can't say if
they have added support for it or not. There's a real corporate culture that
says customers are fools, and these quirks don't have to be repaired. The
problem is that a small bug in a development tool can easily consume a day
of developer time.
Tool strategy churn is another problem. Their development tool focus changes
every two years. Did I mention tool strategy exists to sell servers (SQL,
Windows, etc)? Right when developers become comfortable with a technology,
the focus is changed. The end result is that companies end up with a series
of core applications, each developed using a different toolset, methodology,
or mindset. Developers never become proficient at a tool, and consequently
quality of applications just sucks.
These things make it almost impossible to accurately fix bid a project. You
just never know when some obscure bug reported 5 years ago is going to come
out and bite you.
From my experience, I've had perhaps 1/10th of the development tool problems
with Java compared to using MS tools. I can accurately cost estimate Java
projects, and do them profitably. I know that I probably am not going to run
into any bugs (where a large project will hit at least 5-10 in the MS
world).
So, good luck. I hope you're really happy. But, I think that when you have
the experience and the career span that I do you'll start to see these
things as I do and look for a way out.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
