Re: Development ideas

You are overlooking the major issue with developing a critical app on
Windows technology.

Microsoft breaks their tech every 2 years.

VB6 to VB.Net breaks.

You wrote an app for Win9x and odds are you are having problems on the NT
line (and XP which you are forced to use).

The 5 million levels of MDAC and if you accidentally upgrade a version, you
can break your app.

The changeover from DCOM to .NET.

Hell, the varying levels of IE.

MAYBE developing with the idea that XP is your target OS might get you a
longer lifespan than typical MS development, but developing a critical app
for a windows environment is a gamble I believe and time and resources have
to be spent on development to follow the MS path of upgrades and changes.

I don't trust MS applications more than a client front end and have a
backend server do all the work, again though, you are still tied to any
changes they do to their architecture (vb6 to vb.net as a case in point).

Granted Java is not perfect either.  Sun can break things at will if they
chose too.

In reality, the only languages that are safe are open ones.  COBOL, C/C++,
etc.

I assume there are a lot more C/C++ coders than Cobol coders, as well a I
would assume the amount of COBOL programmers available dwindle year by year,
as well as cost to employ.  How many kids come out of college knowing C and
java as opposed to COBOL?

C/C++ will always be around for as long as we can see, currently.

As for back end servers, IBM and the *nixes have a better track record of
stability in run times and stability in cord life than MS has.  I think the
only time this company has had any issue with IBM on their AS/400 was
recently with a cisc to risc upgrade (and it was pretty minor) andthis
stupid OfficeVision API gut (which is keeping us from going to 5.1).

BTW, if you are looking at Linux desktops, Kylix from borland seems to be
real nice for application development.  The same Delphi code will compile
for Windows or Linux, natively -- as long as you use the cross platform
widgets and nothing OS specific.  Again though, I would make the real
processing on the server backend and make the desktop piece just an
interface and data validate.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Brad Jensen" <brad@elstore.com>
To: <midrange-l@midrange.com>
Sent: Friday, October 18, 2002 2:25 AM
Subject: Re: Development ideas


>
> ----- Original Message -----
> From: "Weatherly, Howard" <Howard.Weatherly@dlis.dla.mil>
> To: <midrange-l@midrange.com>
> Sent: Thursday, October 17, 2002 10:04 AM
> Subject: RE: Development ideas
>
>
> > This message is in MIME format. Since your mail reader does not
understand
> > this format, some or all of this message may not be legible.
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Not to pick a fight or start a war Adam, but what platforms do you know
of
> > that do not have a COBOL compiler on them, and what better language is
> there
> > for writing client server business applications that thousands of people
> can
> > probably understand?
>
> VB6 dlls in the ASP framework. Fast operation, interactive debugging, and
> three million programmers.
>
> Of course, Windows might go away, and some other computer than the PC
might
> be cheaper, faster, and
> more scalable, with a greater software support base and more trained
> professionals,
> but not in our lifetimes.
>
> And I speak as an expert COBOL programmer ( I wrote a query language in
> COBOL, as well as
> numerous applications, a text editor, and a macrocompiler.)
>
> > However, I am biased! but I do agree with your suggestion about Java, I
> just
> > disagree with the premise of your argument to get there!
>
> VB6 is a much easier language to learn and use than Java.
>
> Why people don't realize that the scarce resource is PEOPLE, not computing
> power, is
> beyond me.
>
> > -----Original Message-----
> > From: Adam Lang [mailto:aalang@rutgersinsurance.com]
>
> > To agree with Joe, I would look at a Java solution.
> >
> > You can develop for one platform and have a lot of flexibility to move
to
> > another if needed.
> >
> > The same expertise your coders have on making the server side
application
> > components will also extend to make a java "fat client" or web based
> applet.
> >
> > JDBC will interact with nearly all databases out there (from DB2 to
> > PostgreSQL (open source)).
> >
> > The only thing I would recommend besides Java would be C, then next
> > "portable" language.
>
> But be sure to make all your variable names in Russian, spelling them
> backwards to avoid comprehensibility.
>
>
> > I think when redeveloping applications, you want to avoid "lock in"
> > situations,which would be the situation when using RPG or COBOL.  You
will
> > be basically forcing reliance on the AS/400. Going a Java route, it
makes
> > you more adaptable, as I see it.
> >
> > Adam Lang
> > Systems Engineer
> > Rutgers Casualty Insurance Company
> > http://www.rutgersinsurance.com
>
> Use VB6 to write DLLs. host them in ASP (VBscript) on top of IIS.
> Maintain state inside the VB6 program, it's just like writing for one user
> at a time.
> Don't use the ASP session variables, and use ASP application objects only
> when you
> want to share something between sessions.
>
> IIS will create one copy of your code that will service all sessions, and
> remain
> in RAM while sessions remain active. There will be a separate data area
for
> each
> session invocation.
>
> It will run with a fairly small memory footprint, and like a bat out of
hell
> (ie fast for
> non-American English readers).
>
> And you can develop the application in the interactive VB environment,
> testing your web pages
> with breakpoints in the VB code.  Fast fast fast development.
>
> Java looks big, and slow, and not very robust to me. We saw one Java
> application try to load on a PC, and it took a 48 MB environment download
> just to get started.
>
> Brad Jensen
> www.elstore.com
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.