Re: 'green screen' not sellable

On Mon, Jun 8, 2015 at 1:02 PM Mark D <mdlkml@xxxxxxxxxxxxxxxx> wrote:

C# provides a lot better support for connecting and using disparate
data sources IMHO. Things like linq are a godsend.

This can't be understated. Other things come close to LINQ, e.g list and
dictionary comprehensions in python, but, nothing is better. Visual Studio
2013 and 2015 are better IDEs than anything else in the market for C#.
Python and Java. The profiling and instrumentation in .NET is second to
none. Every database and file format has decent .NET support.

In my (admittedly
limited) experience with the i, it has a lot of trouble integrating from
other sources. Other sources are a fact of life as the average shop is
going to have quite a few different databases. When I say other sources
I mean connecting to a json service, reading xml files, reading a foxpro
database, etc. I know the i can do at least some of that stuff but it
is so ... painful.

Actually, php can do all these things just fine. So can Python, Java and
node.js. These are actually pretty vanilla use cases. Maybe they are hard
to do in RPG and CL. LINQ and a few other C# things might make these nicer,
but you've not named any straws that broke the camels back that would make
me say "this has to be C#." I could even do all those tasks in client side
javascript in a web browser or Excel VBA macros.

Now imagine for a moment you have a mobile application. If you use a C#
WCF service as an intermediary you can preprocess all of the data and do
any and all transformations from any number of data sources (because
.net does that stuff *really* well). You can use an ORM library like
entity framework and then you pass the benefit of that object oriented
access right through to the other end.

EntityFramework would make querying the database easier. Honestly WCF is
only marginally beneficial here. Unless I needed other endpoints besides
REST, or I'm talking windows to windows, its a lot of ceremony for not a
lot of gain.

Finally all of your data processing and access takes place over high
bandwidth wired lines and then the final result only is sent over
wifi/wlan. the whole thing ends up being faster even though there is
another layer. It also adds another layer of security and isolation
between your core business data and the nasty world of the internet.

How is that any different from turning each RPG green screen into an rest
service? As a matter of fact, if I use RPG or PHP on the i instead of C#,
data processing happens in process on the i, and nothing is transferred
over the lan.

For me developer productivity is paramount as they are the most
expensive part of the process. The hardware is cheap anymore.
Leveraging the existing i developers in a way they feel comfortable with
while simultaneous making use of new generation .net developers in an
environment they feel comfortable with just makes sense.

This I agree with, although I try to express it as "architect your

solution in a way your developers can deliver and your operations guys can
support"

But I speak more from the ideals of a shop that needs to be incredibly
flexible and reactive for in-house needs. Not a shop that is developing
a boxed application for resale. In that case it becomes more sellable
by requiring only one system I'd think. But even so, you might warm
some shops up with the whole "we're modern and integrated" aspect.

Agreed. When I'm making inhouse apps, I tend to be a little more "out of
the box" and creative. I have to create a system our team can support, not
one that I can convince most CTOs that they can support.