=?iso-8859-1?Q?RE:_[U2]_Where_Will_the_=2ENET_Apps_Live_??=

[brian]

I second what Tony states about the syntax not being important - the
main thing is a strong grounding in the underlying concepts. 

What .net DOES bring (and I'm not a great fan of .net for various
reasons) is order to the chaos that was the Windows API - one of the
main reasons why we have the different versions of e.g. file access
exposed by the different editions of VB. 

Of course, that is what COM was supposed to bring - there is no reason
why you cannot use the same Scripting.FileSystemObject used in VBA and
VBS from inside VB, C++, Delphi or even .Net: it is no more than a
convenient wrapper to abstract and bring a level of sanity to a set of
fairly horrible API calls that required a single set of data types that
were otherwise not portable. But the problems with the way COM was
implemented too often outweighed the advantages. 

In practice, most of these languages have converged to such an extent
that they are more alike than different: platforms have developed along
the same lines to embody the same concepts: and more often than not the
differences seem to ones of marketing stress than true technical
innovation or divergence. Each year it seems Linux becomes more like
Windows, and Windows more like Unix. And languages interoperate to such
an extent that it is more reasonable to talk about development
experience than experience in any particular language.

Remember that .Net and Java are both open to the extent that both VMs
are fully documented. If you want to write platform independent code
for the Java VM you do not have to write in Java: there are compilers
that can produce Java bytecode from just about any source language
(including Basic) and from a whole range of suppliers. I'm guessing it
shouldn't be too long before we see the same sort of choice for
developing in .Net - not just M$ or Borland. There is already at least
one fairly advanced effort to port .Net code to the JVM.

In a few years the choice of language may not matter anyway.

:-)

Brian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Where Will the .NET Apps Live ?

[David Jordan]

Whether one uses java or .Net, my recommendation is to keep as much of your
business logic in U2.  Always use the best of both worlds; U2 is an ideal
tool for developing business rules, processes transactions efficiently and
is tightly integrated to the database, something other RDBMS cannot
simulate.  Use java or .Net for the interface and call the business rules as
a subroutine, Message Queue, sockets or whatever.  By doing it this way if
you make a wrong choice, you do not have such a big conversion.  This
enables to develop both fat client and thin client solutions to your
application without duplicating the business logic.  

Then if you move to web services architecture then it is quite simple.  Both
Java and .Net are getting into web services, and building the application to
interface to a web service may simplify development.

For someone starting out and who is familiar with U2 Basic, then Visual
Basic is probably the easiest path, although .Net VB is more complicated
than VB6.  If you are just starting out, look at working with the beta of
Visual Studio .Net 2005 which is being made a lot easier for VB developers
and is streamlining the amount of code to do tasks.  Although .Net is a
simpler install without the need for the register, there is increased
complexity of security to deal with.

While java runs on more platforms, you have the choice of the lowest common
denominator that runs on many platforms but is less sophisticated or a more
sophisticated development that is limited to fewer platforms.  It is a
harder language to learn unless you have had C experience and can be slower
to develop in.  Another issue is that I have experienced java applications
to run slower than a windows application.

Other directions to look at is using revelation open insight which has
interfaces to U2, is a pick client development tool and runs on windows and
linux. Omnis development tool from raining data that runs on windows and
linux.  The other option is Borlands development tools that can run similar
code on windows and linux.

When selecting the tool weigh up the upfront costs of the development tool
against the long term labour cost of development and if client licenses are
required to run the application.

Regards

David Jordan
Managing Consultant
(U2UG founding board member)
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/