users
[Top] [All Lists]

RE: [cinjug-users] Does corp. America still trust Java?

To: "Mark Windholtz" <windholtz@xxxxxxxxx>, <users@xxxxxxxxxx>
Subject: RE: [cinjug-users] Does corp. America still trust Java?
From: "Michael Schneider" <michaelschneider@xxxxxxxx>
Date: Thu, 24 Feb 2005 15:57:51 -0500
Cc: <yevgeny@xxxxxxx>
Delivered-to: mailing list users@cinjug.org
Importance: Normal
In-reply-to: <3a4860b405022411531b2b38d1@mail.gmail.com>
Mailing-list: contact users-help@cinjug.org; run by ezmlm

Mark,

I would agree with your statement "Most Java/J2EE applications are written in a Data Processing (DP) style."

If you flip your statement around " Most java software in the Data Processing environment continue to be developed with similar paradigms that were successful in COBOL"

Just like " Most Java software in the Scientific Programming environment continue to be developed with similar paradigms that were successful in FORTRAN"


There is a lot more Data Processing software developed then Scientific, so most of the Java/J2EE applications are being written in a data processing style".

A software development ecosystem (Scientific or Data Processing) tends to resist change and only evolves the minimal amount necessary to sustain life.  Virginia Satyr quantified this to be a maximum of 10%  change at a time.  If you are charted to transform the behavior of your ecosystem (project, division, company, segment), then you need to plan which 10% to do first.  Most companies choose tools rather then software engineering.  This is often why a FORTRAN programmers first class, looks allot like a FORTRAN procedure  (I would guess that it is similar for a COBOL programmer).  Some companies move from tools to software engineering techniques, some do not.

Since most java ecosystems that develop data processing code, still tend toward a DP Software Engineering style, injecting C# will still yield a DP software engineering style. A java team that was transitioned to C# will be measured to be more productive then the same team switching to Java. 

This is because there is a large tool change from COBOL to Java, and a minimal tool change to to go from java to C#.   

 

My opinion on why a company use .NET?

  • Reduced development cost ( real or perceived)
  • Fat Client development (java really missed the boat by not being included with the Microsoft OS, by not being on each client box, you are stuck be a server side solution)
  • Pilot Project  to evaluate cost  of development an ownership.
  • Wizard based development for common tasks.
  • A simple glue language is shipped with .NET (VB).  You can use Jython or Jruby, but they are not widely deployed.
This is a big subject, and could be discussed at length over a beverage................
 
Mike



 




-----Original Message-----
From: Mark Windholtz [mailto:windholtz@xxxxxxxxx]
Sent: Thursday, February 24, 2005 2:53 PM
To: users@xxxxxxxxxx
Cc: yevgeny@xxxxxxx
Subject: Re: [cinjug-users] Does corp. America still trust Java?


Yevgeny wrote:
>
> my company is being constantly asked for .Net related services anymore.
> Whether it is putting together a .Net Architecture or simple development,
> it is mostly on the MS side and barely ever on J2EE one.

 Most Java/J2EE applications are written in a Data Processing (DP) style.
 Rather than an OO style.
 I'd say over 90% of the java Ibeing written is DP-oriented.

 At the end of my talk, I asked:
 Since most development is in DP style,
 is Java really the best choice for building DP programs???

 That's why I called the talk COBOL oriented J2EE.
 You can't (probably shouldn't) build OO apps in a DP culture.

 It may take a .NET person to answer then,  if .NET is either:
 (1) better at building DP-style applications
 (2) has a better OO requirements culture.

 Any one have an answer?  (guesses also accepted).

--
Regards,
-Mark
(513) 226 8259

---------
You may unsubscribe from this mailing list
by sending a blank email addressed to:
users-unsubscribe@xxxxxxxxxx

--
Find additional help by sending a blank email
addressed to:
users-help@xxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>