You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by V D <st...@drexel.edu> on 2006/02/11 06:47:37 UTC

Re: From Java to C#, ASP.NET [Off Topic]

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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org