More Microsoft: .NET as the run machine for MultiValue

[Dawn Wolthuis]

I just read what Albert wrote, including information about the .NET run machine, and thought I'd ruffle more features, I mean ask another question.

I'm going to use what I learned here wrt the DBMS and not call .NET a MultiValue run machine. It is, however, a run machine for MultiValue applications. You transpile all of your MV code to C# using MVON# tools and it runs. Combine this with our SQL Server tools, and then it is just you (your application) on a Microsoft platform. Lovely stuff!

I am going to do another dog and pony, so I'm looking at the run machine slide I've been using. I want to net it out. I know why our team thinks that .NET is frickin' awesome as a runtime environment (see image below), but you folks have a way of helping me gain clarity. 

Why do you think that .NET is or is not a better run machine for some purpose or another than other run environments for MV applications?  

Thanks in advance.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[stope19]

Is .Net a 'better run machine' than a purpose built MV environment? IMHO, No. Is .Net even a 'run machine for MultiValue applications'? (IMHO) No again. An MV app, running on .Net, does not change .Net to 'be' an MV run machine.

[Dawn Wolthuis]

Ah, OK, clue me in on how you define that. The picture in my head is that as application developers, if we write MV BASIC, there is a compiler that turns it into some byte code, p-code, intermediate language that is run by a run machine, aka p-machine.

In the case of TAFJ that Temenos wrote and runs, they compile MV BASIC to Java byte code and their p-machine is the JVM. In the case of UniData, the compile to their own p-code, not to a p-code backed by industry standards, and have their corresponding p-machine, the UniData run machine, to run it. In the case of someone using the MVON# framework, they compile to CIL with .NET as the run machine. ECMA has standards for CLI and .NET meets those standards (if I'm saying that right). 

These are 3 different run machines for 3 different implementations of MultiValue, so if I ask someone running one of these "what MultiValue run machine are you using?" I would expect any of these answers would provide an appropriate answer. I would ask it this way because some are running applications in .NET but the MultiValue code is on the back-end, running in the UniData run machine, for example. Such a site has .Net in the application mix as a run machine but not as their MultiValue run machine

Does this way of thinking of run machines, including MV run machines, work for you, even if different than what you were previously thinking?  --Dawn

Sent from my iPad

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Wols Lists]

On 23/09/17 13:16, Dawn Wolthuis wrote:
>
> Does this way of thinking of run machines, including MV run machines,
> work for you, even if different than what you were previously thinking?
> --Dawn

I'd certainly agree with this. If there was a standard p-code that all
MV implementations ran on, then maybe it would be correct to say ".net
is not an mv run machine". But as far as I can see, CIL is a p-code, and
if a MV program is compiled to CIL, then .net is the run machine...

Cheers,
Wol

[Dawn Wolthuis]

Excellent, that's how it seems to me, and it helps convey an accurate picture.

Thanks Wol. --Dawn

Typed on a mobile keyboard

[Ed Clark]

Is the mv code compiled to CIL, or is it converted to C# and then that is compiled to CIL?

[Dawn Wolthuis]

Transpired to C# that is optionally stored, then compiled. This way an MV BASIC program can call out to any C# libraries using C# in a block of code. There are other advantages to this approach as well. --Dawn

Sent from my iPad

[Wols Lists]

On 23/09/17 19:47, 'Ed Clark' via Pick and MultiValue Databases wrote:
> Is the mv code compiled to CIL, or is it converted to C# and then that is compiled to CIL?

Irrelevant, imho. The p-code is the CIL. Who cares what happens in-between.

(That's actually pretty much the same model as GCC. It used to stand for
Gnu C Compiler. It now stands for Gnu Compiler Collection. And if you
delve into its workings, it has a bunch of front ends, one for each
language, that compile that language into some sort of p-code. It then
has a bunch of back-ends, one for each chip, that converts said p-code
into actual machine code.)

And actually, what's the difference between p-code and machine code?
Hard to say, given that most modern x-86 style processors are actually a
mini computer that are RISC engines with an x86 instruction set
interpreter (which is why you can update them with microcode), and
somebody built a chip with used Pascal p-code as its machine code.

And I know our Pr1me 50-series machines had a special microcode update
which allowed them to run PI p-code directly ...

Cheers,
Wol

[Ed Clark]

I think it’s relevant considering the conversation topic. MV code becomes C#, not CIL, and neither C# nor CIL have native support for multivalued operations. On a true "MV run machine", a BASIC statement like:
0001 x=field("ab.cd",".",2)
compiles directly into a machine operation:
00001 00000 : 084 field "ab.cd" "." 2 1 => x
(example from the uniVerse VLIST command)

If you say that .Net is an mv run machine, then you could just as well say that the x86 (or the RISC engine underneath) or the ppc64 or the itanium processor on an HP box is an mv run machine.

[geneb]

On Sat, 23 Sep 2017, stope19 wrote:

> Is .Net a 'better run machine' than a purpose built MV environment?
> IMHO, No. Is .Net even a 'run machine for MultiValue applications'? (IMHO)
> No again. An MV app, running on .Net, does not change .Net to 'be' an MV
> run machine.
>

It would be kinda cool to see a DataBASIC.Net compiler that spat out MSIL
instead of this "transpiling" stuff. :)

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

[Albert Kallal]

Actually, probably the only REAL reason why this setup works well is WHEN SQL server gained or was given the ability to consume + run .net code as an assembly. The reason why this is significant is for several reasons.

 

SQL T-SQL code does not have a native compiler. For most T-SQL code this is not an issue, since the script like code spends “most” of its time running and consuming the native SQL library of code (often referred to as super-visor code).

 

A great example is thinking that some pick TCL select commands will run faster in DataBasic code. Since the selects both from DataBasic and TCL are really using the same system/supervisor code, then the “portion” of time you spend running and interpreting actual the set of TCL statements is not a big deal. Some select statement issued in TCL does not run faster than the SAME statement issued from DataBasic.

 

However, the instant you do looping, or have to execute lots of TCL, then of course such code would benefit being re-written in Databasic. (Since it compiled to p-code). And of course for some years D3 etc. DataBasic gave us a “native” compile option. And again for general code, it was often not worth the effort to compile such code as native. However for complex “screen gen” code and lots of looping like code (non data retrieval), then such systems benefited GREATLY from use of the native compile option.

 

So the instant you start doing lots of string process, input out processing of fields etc., then native code becomes a real advantage.

 

If SQL server did not support .net assemblies (.net code) as an option in PLACE of T-SQL code (script like interpretation), then such an approach to “plop” MV on top of SQL would certainly take a large hit in terms of performance. (in fact it would be a bad idea).

 

And attempting to convert DataBasic into a limited language like T-SQL would be really messy from a coding point of view, but even worse from a performance point of view.

 

It would have been in theory possible to simply write a .net code stack outside of SQL server, but then integration with SQL commands would be messier and less seamless then using what is called .net SQL assemblies.

 

So just like TCL + “SELECT” or calling of database programs is quite seamless in pick TCL, the same goes for using SQL .net assemblies in place of a separate .net code approach.

 

For DataBasic – the “strength” and “ease” of use was always this ability to READ a record, or execute TCL commands right in the code without having to adopt “messy” connection strings and other approaches that are so typical in languages like say c# or vb.net.

 

To be fair, other vendors have been successful with building an external code library approach. (jBase comes to mind).

 

So while there are some advantages of using .net such as being a key technology that runs on Microsoft platforms. Toss in excellent tools” Sure, certainly .net makes a great choice.

 

However, I think the REAL key benefit and genius of MVON was to jump on this CRITICAL change and feature addition to SQL server.

 

That “magic” moment and change was the arrival of .net assemblies for SQL server. This meant the “library” and code stack was running with close ties to SQL server. That code is called and run directly from SQL server.

 

The results is the “reverse” of most approaches. Ie: Most approaches build an external library that connects and calls and uses SQL server.

 

The MVON approach means that such code is driven and consumed by SQL server – the result is more seamless integration of such a code library that is thus tight coupled with SQL server. A similar comparison would be PICK TCL code that runs lots of select and database commands. Or even how DataBasic can easily execute select commands. Or now in this case T-SQL routines can seamless call + consume .net assembly code. In all such cases, you not dealing with database “connection” issues – the connect “just” exists and you are free to “select” data.

 

So the fact of this being built around .net is a great feature but that’s not really the make or break feature IMHO.

 

I think the architecture of using sql .net assemblies which are tightly bound to SQL server is what makes this solution a better approach than that of external libraries that would connect to SQL server.

 

So sure, .net is a great platform, but I think the key takeaway here is the choice of using SQL .net assemblies – that gives a closer integration to the SQL platform in general.

 

Last but not least, from a .net developer’s point of view, one tends to stay away from SQL .net assemblies for many reasons, but that of building a database stack to run with SQL server would not be such a reason to avoid this approach, but a compelling reason to do so.

 

Trying to keep this short, but I will point out that yes, there is a difference between p-code and native code. (Just use the D3 native compile option to see such a difference). As I pointed out, the “pick machine” was a library of OCONV() etc. bits and parts. For Ultimate, prime and some vendors, their hardware boards executed the “pick” instruction set directly – and did this well.

 

For R83, they cross compiled the pick machine to native x86 – and by doing so near wiped out most “mid line” PICK vendors that could not offer nor compete with the astounding performance one would get from a cheap off the self x86 computer.

 

In strange way, the GREAT design of the pick machine allowed it to adopt the x86 platform with relative ease – and that in turn caused the collapse of near most mid line PICK vendors that simply could not offer the performance for the cost of an off the shelf x86 computer.

 

 

Regards,

Albert D. Kallal

Edmonton, Alberta Canada

Nospam...@msn.com

 

 

 

 

 

 

 

 

 

[Tony Gravagno]

geneb wrote:

It would be kinda cool to see a DataBASIC.Net compiler that spat out MSIL
instead of this "transpiling" stuff.  :)

 

That's actually what MVON# does. It doesn't matter to me whether the intermediate language is C# or VB.NET. We don't see it unless we want to, just like we don't see standard p-code. With D3 FlashBASIC we don't see the C++ or whatever it generates, and it doesn't matter.

T

[Tony Gravagno]

Dawn Wolthuis wrote:

Why do you think that .NET is or is not a better run machine for some purpose or another than other run environments for MV applications?  

Are you asking us how we think MVON# over .NET might compare to other MV platforms specifically for applications?

I would really like to be able to run MVON# in a common hosted Windows environment with SQL Server - think Rackspace or Hostgator. I don't know if we can do that yet. The ability to do so would separate this from the other platforms that have a more extensive installation profile, even QM.

Even outside of a hosted environment, the ability to run MV within the RDBMS is compelling as it eliminates the presence and ill-perception of VME environments. This only applies to MV platforms that still have a blob.

I think with MVON# we can get away with truthfully saying that an application running in this environment is a .NET application. Regardless of the source code, it IS all .NET. But reducing this to being a .NET application and saying nothing more is disingenuous. The code is not C# or VB.NET or any other CLI-compliant language, which is implied when we say .NET. The true nature of an application must be explained in the sales cycle of any MV app over .NET and SQL Server.

.NET is extremely extensible. This ability to make use of other libraries, static and dynamic, is not built-in to other MV environments.

With BASIC code embedded within .NET code, we get benefits of obfuscation, easy assembly deployment, and debugging with common .NET tooling, none of which are available with other platforms.

.NET really does run INSIDE SQL Server, where all other MV platforms connect TO another DBMS via sockets. How might it use other databases, MV or otherwise? Easy - with any common .NET library that can access those systems.

I have a lot more in mind but I'm not sure if this is the expected type of response. There are also benefits in the sales cycle, with getting and retaining developers, etc.

T

[geneb]

It's just an extra step. Instead of DataBASIC -> C# -> MSIL, it should be
DataBASIC -> MSIL. :)

[Doug Averch]

I tried to ignore this thread, but it does not seem to be going away.

To be honest your technology does not do diddly squat for U2logic. Most of your would-be customers are Universe, Unidata, or D3 customers with around 3 million licenses under maintenance give or take. There is no compelling reason to spend any money on an underfunded operation like MVON. Rocket is a billion-dollar company and your sales, if I can guess are easily under 3 million.

So, U2logic should bet the company, spend resources, learn a whole bunch about Microsoft SQL for what gain? Our MV market is a lot of companies with technology rooted in the ancient terminal interface or telnet. So, will the companies’ screens be faster, no? Will the MV Basic reports run faster, maybe? Will I be able to use any Microsoft tools like Visual Studio, to code, compile and debug? No, silly we still writing MV Basic code.

U2logic identified in 2000 that telnet was a dying technology. U2logic created tools for Universe, Unidata and now D3 because Informix/IBM/Rocket failed to bring Microsoft style tools to our marketplace. Did this market embrace them? No. Did we care? Yes. Did we stop developing them? No. Nonetheless, you are going after a bunch of VAR’s that have many applications that cannot and won’t run on your technology. There is no money in going after users who will abandon this technology as soon their CEO reads the Wall Street Journal about some up and coming database.

U2logic has ported from R83 to Prime Information to Revelation and to Unidata/Universe. There were a bunch of other platforms we have forgotten them in between. This sounds just like another port for no benefit except to line the pockets of MVON. MVON will be another in a long line of failed companies in MV Family tree poster!

Regards,

Doug Averch

U2logic, Inc.

[Will Johnson]

Explain your term transpire or transpile, what does this mean?

[Dawn Wolthuis]

I'm not caught up on this thread, but I can answer this one quickly. I googled to see if others define it as I do, and found this at the top. Transpiling is compiling, but the resulting language is at the same level of abstraction as the source.

https://www.stevefenton.co.uk/2012/11/compiling-vs-transpiling/

So, we compile to CIL (MSIL) by means of transpiling to C# and letting the C# compiler do the rest. This makes it so that all .NET libraries are available from MV# (MV BASIC that transpiles to C#). See https://mvsharp.com/2017/06/26/insert-c-within-mv/

--Dawn

Dawn M. Wolthuis

Take and give some delight today

On Tue, Sep 26, 2017 at 10:25 AM, 'Will Johnson' via Pick and MultiValue Databases <mvd...@googlegroups.com> wrote:

Explain your term transpire or transpile, what does this mean?

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Will Johnson]

That's as clear as mud.

Can not transpiling be defined as the creation of Source code in your target language, from Source code in your initial language.

So transpiling BASIC into C, means the actual creation of C Source Code from the BASIC.

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Wols Lists]

On 26/09/17 20:01, 'Will Johnson' via Pick and MultiValue Databases wrote:
> That's as clear as mud.

What's that saying about theory and practice? In theory, theory and
practice are the same. In practice, they're not.

To a computer guy, transpiling is quite clear - it's going from one
*source* language to another *source* language, or one intermediate to
another, or one machine code to another.

So if I've got some old M68000 code and compile it to x86, that's
actually a transpile.

What did I say about theory and practice? While the definition of a
*source* language isn't too hard, the difference between an intermediate
language and a machine language is extremely vague.

So BASIC to c# is a *trans*pile, they're both *source* languages, then
c# to CIL is a *com*pile, CIL is an *intermediate* language, then CIL to
x86 is also a compile as it's a machine language (except it's not - it's
a p-code that runs on an x86 interpreter inside a CRISC cpu ... :-)

Cheers,
Wol

[Glen Batchelor]

Machine language is what the processor itself requires at the highest hardware level, in order to use the registers to process operands within those registers.

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Wols Lists]

On 26/09/17 20:32, Glen Batchelor wrote:
> Machine language is what the processor itself requires at the highest
> hardware level, in order to use the registers to process operands within
> those registers.

But what's the processor? :-)

What's in that little black package called an x86 chip, be it Reizen or
Core i? or whatever, is what used to be an entire board not *that* long
ago. And not that long before that, it used to be most of an entire cabinet!

"There's nothing that another level of abstraction won't cure. Except
too many layers of abstraction, of course!" :-) Where does microcode fit
in to all this? :-)

Cheers,
Wol

[Glen Batchelor]

 Machine language is not abstracted, though. It is the layer which is the instruction set the hardware itself can interpret to perform operations directly on the registers. You can't compile microcode/assembly/machine code as it is the basis of the hardware architecture itself. You abstract set of microcode operations into a higher language object or function.

[Wols Lists]

On 26/09/17 21:18, Glen Batchelor wrote:
>
> Machine language is not abstracted, though. It is the layer which is
> the instruction set the hardware itself can interpret to perform
> operations directly on the registers. You can't compile
> microcode/assembly/machine code as it is the basis of the hardware
> architecture itself. You abstract set of microcode operations into a
> higher language object or function.

So p-code is a machine language?

Don't forget - somebody designed a chip that ran UCSD Pascal on
hardware. Pr1me ran p-code in hardware. Etc etc.

Cheers,
Wol

[Glen Batchelor]

Psuedo-code is not machine language. It's psuedo machine language code as the name suggests which means it's translated to the microcode that the hardware understands directly. It's abstracted.

[Wols Lists]

On 26/09/17 21:25, Glen Batchelor wrote:
> Psuedo-code is not machine language. It's psuedo machine language code
> as the name suggests which means it's translated to the microcode that
> the hardware understands directly. It's abstracted.

Even when there's a chip that actually runs it, as per your definition
of machine code?

THAT is my point - you can't take a language and say "that is p-code,
that is machine code". There are chips that will run Pascal p-code, or
PI p-code, and there are interpreters that will run x86 code on, say, Power.

If Power is running x86 code, is it p-code or machine code? (Didn't
Apple do exactly that the other way round - install your Power programs
on the new x86 Macs?)

Cheers,
Wol

[Glen Batchelor]

 Of course you can. You need to define the architecture that is being used though. Context is everything right?

[Tony Gravagno]

But the BASIC code and C# are polyglot here, like PHP+JavaScipt+HTML, or ASP.NET with C#+JavaScript+HTML in the markup. Going direct to IL sacrifices features for maintainability as well as integration with other resources.

[Tony Gravagno]

I see MVON# as a vehicle for companies looking to offer their products to a mainstream audience. It eliminates the weird looks, digressions, explanations, and loss of attention that occurs in any presentation of MV apps to non-MV prospects. Yes, we say "we sell apps, not databases" but in full disclosure the platform must be revealed and that's when the questions start.

With a .NET application over SQL Server, all of that is eliminated. The benefit here is not to the developer but to the company trying to sell business application software in the modern climate. Benefits also extend to end-users who ask "where can I get someone to maintain this?". Well, your data is in SQL Server and the code is in .NET ... question answered. Yes, the polyglot BASIC code is in there as well, ensuring some level of job security for the Pick people. With this topology it becomes much easier for .NET and Pick devs to learn how to collaborate on the same code set, rather than trying to figure out client/server-style black boxes with no one to translate between them.

[ad]
BTW, one of the services I offer is helping teams like that to work together.
[/]

So yes, this is a niche product. If it doesn't apply to you, fine - much like AccuTerm GUI doesn't fit a company that wants a browser app, mv.NET doesn't suit devs who don't know .NET, and QM OOP means nothing to devs who still want to code to R83 standards.

T

[Ed Clark]

I seem to recall p-code was often referred to as the machine language of a “virtual machine”. That term has other meanings now, but if you were running r83 in a vmware virtual machine hosted on some non-x86 hardware, what’s actually the “machine”

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Dawn Wolthuis]

Really good points, Tony. While a developer dividing time between .NET and an MV environment will get relief by using .NET and SQL Server as their platform (with MVON# Tools), some developers will not want their tools to change at all.

The real winners here are the company that owns the application software and the company that is running the application software.

VARs sometimes try it out, see what it will take to get there, and can turn that around into new sales very quickly.

End-customers looking at whether to select Microsoft Dynamics or some other applications can instead use their existing application on the Microsoft platform, using the toolset.

I hear you saying that perhaps asking a group of MV developers whether this looks good could even cause offense if anyone thinks it would make them obsolete. We had two different managers bring in their "die hard pick developer" who they were concerned would not like it and both came out delighted that it looks just like what they are accustomed too plus has features they were seeking.

I added it up and our tight band of developers has a total of more than 200 years of experience in MV, so we certainly do not want to let MV developers down. We also have more than 100 years combined specifically in MV with SQL. Our user developers (folks using the MVON# libraries) are 

a) at home in .NET using MVON# tools and 

b) able to get the -ilities they want of high availability, reliability, securability, etc

c) able to branch out to other ways of writing applications, dovetailing with their existing app

Additionally, if it is an SB+ application, then the same specs, when pulled into MVON# Netbuilder allow the app to run in character, GUI, or BUI. 

I can imagine that this might not excite someone who has a toolset and wants to work that and protect it from expansion, although most seek the type of interoperability this brings. It is "Bob, the owner" of an application that wants the company and applications to be worth as much as possible from whom we likely get the biggest smiles. So far, we have found that developers and executives alike appreciate the strategy, but I am hearing some of the possible push back here. That is also helpful to understand when working with such a game changing strategy.

Thanks.   --Dawn

Dawn M. Wolthuis

Take and give some delight today

--

[Glen Batchelor]

There is only one hardware layer that converts electrons into zeros and ones for virtualization. That hardware layer runs microcode. Anything else is simulated and therefore inherently abstracted from the hardware layer.

[Will Johnson]

Really?  "To a computer guy" ?
So you're going to insult me like that?

It's not "quite clear", which is why I asked.
It seems to be reinterpreted by whoever wants to talk at that moment.

However I'll discard your below and use the definition I found online :)
As one "computer guy" to another.

[Albert Kallal]

On Monday, September 25, 2017 at 1:52:06 PM UTC-6, Doug Averch wrote:

>>Will I be able to use any Microsoft tools like Visual Studio, to code, compile and debug? No, silly we still writing MV Basic code.

U2logic, Inc.

100% agree. For running most legacy mv apps, most don't care.

However tools like Visual Studio (VS) allow one to build and consume web interfaces to that data. So for example sage50, and QuickBooks both are pushing hard their "cloud" or hosted based accounting systems (and now they are adding payment gateways etc. for customers to pay by web etc.).

So those web based service systems have WSDL or standard rest/soap interfaces. Thus you can point Visual Studio to those web services and consume those web services WITH GREAT ease. So while "most" of the application would continue to be written + maintained + running DataBasic code, the ability to interface to FedEx, UPS, or cloud based accounting systems is "significantly" enhanced by tools designed to interface with web services.

I written interfaces in .net to both  Sage 50 (simply accounting) and that of QuickBooks. Their provided SDK's and .net objects saved a GAZILLION dollars in terms of developing such interfaces because they support and have SDK interfaces for Visual Studio and .net.

The problem today is "more" and "more" data is being consumed from OTHER sources, and more and more this is cloud based or "web services" based. So you might have a robust MV application, but now need to consume data from SalesForce or some other system. Software today is fast becoming about WHAT and WHO you interface with.  If you can interface your customers to you data in place of employees typing in some commands then you save "huge" amounts of labor. When is the last time you used a travel agent?

Now to be fair? I think a rather large portion of MV applications being used by companies that simply want  a "box" to run that application - they often "little" care much about that box - they just need their software to run. No question that such MV systems "tend" to have some long term person that knows the software well, and been tweaking it over the years, but often they just run the software - and don't care about anything else.

The real issue is how active that software is and is it being changed.  As a developer I don't really care about the cloud, but I find myself MORE and MORE having to write some code and work on some data - but that data is NOW in the cloud, or is web service based such as interfacing to UPS/FedEx, or some other application in which the data and application is web based, and I have to use + adopt some kind of web interface to that system.

Such vendors of these systems thus tend to supply and build a API built around web based services - and that plays nicely into adopting mainstream tools like Visual studio/.net that have amazing tools to consume and interface to such systems.

Some people loved green screen, but the REAL change in adopting GUI systems was developers having to adopt new tools to build GUI's etc. Companies often really don't care much about the platform - but the rise of the GUI or say now the cloud is occurring due to benefits drives such adoption. Those companies are not saying, hey, lets consume some data from some web service - but are simply adopting systems built around such technologies due to cost and practical considerations.  However, because of these changes in the marketplace, then this is forcing developers to more often interface with web services data.

The base PICK system not up to snuff in terms of building a GUI or say now consume web based services. However, to be fair, given so many MV systems run on Linux, then ample tools exist in terms of these challenges on the Linux side of things. However, if those Linux tools don't provide easy consuming or interface to the MV database, then such interfacing to web services is a challenge.

The huge and SELDOM talked about revolution on the pc desktop was the advent of "com" or often called ActiveX. So any code could consume any other application. You need to interface to QuickBooks - it was a simple "com" object instance you create, and all of a sudden all the properties and methods of QuickBooks is available in your .net code.

Web services is really just an abstractions of the above desktop revolution based on market needs. Now in place of creating a "object" that interfaces to quickbooks desktop, I am using a object interface say to their web based version of QuickBooks, or maybe FedEx shipping. And again, with WSDL, then you point Visual studio at the web service, and all the properties and methods and interface is automatic generated for you.

And we seeing even web services now interface to other web services (called mashups).

So the trend in our industry is just like in the past - software has to talk to and interface to other software. So the  overall industry trend is and will be code that interfaces to other web services systems. This thus makes a compelling reason to adopt tools like .net that facilitate this kind of software shift and Paradigm change occurring in our industry.

So while you general changes to that MV system may well continue to be DataBasic, AQL, and procs, the probability of that system needing to consume data from some other system will continue to increase - and such code in general is rather costly to write in DataBasic without the supporting tools that seamless interface to those other web systems that provide API's build around industry standards such as SOAP.

As I said, I think most companies simply want a place and a box to park their MV system and be done with it. However for MV applications that are still being enhanced and needing to be updated to change to new  business requiems WILL benefit if new tools can be adopted that can integrate with both the data, and also with emerging industry trends.

[Dawn Wolthuis]

There are ways in which Visual Studio might be useful -- if you want to write or use .NET libraries written in C# or if you want to own the source code of MVON# yourself and maintain the tools. You can also look at the generated code for debugging purposes. We do have one prospect that plans to just maintain the generated C# code (not my recommendation, but they have a choice).

If I had VAR software today, I would run it in .NET and start writing new modules there using Microsoft tools and patterns for developing software, such as Xamarin for mobile, ASP.NET CORE 1.x (formerly ASP.NET MVC 5.0) for web, etc. Then your existing application fully runs as it did and can be maintained as it was, and you can move forward with Microsoft developer approaches.

--Dawn

Dawn M. Wolthuis

Take and give some delight today

[Albert Kallal]

 

@Dawn wrote:

There are ways in which Visual Studio might be useful

 

Much of the choice one makes really centers around what development stack of software one is familiar with. I think .net only much useful if that’s ones current hammer to hit a nail with.

 

Like endless Ford vs Chevy discussions in high school, I am long past that point now!

 

Much of the choice one makes really centers around what development stack of software one is familiar with.

 

I mean if a company is heavy invested in say LAMP (Linux, Apache, MySQL, PHP), then their developers and efforts are going to center on using such tools for significant amounts of their software approaches.

 

Same goes for .net.

 

The problem today is these “stacks” take significant amounts of time to master, or at least become productive. I mean, in the old days you could adopt Turbo-Pascal, and dump it 1 or 2 years later. Same goes for say Paradox, Knowledge man, dbase/FoxPro a RATHER long list of tools that have falling by the way side.

 

So choice of platform X or Y will be often dictated around what tools and stacks a company has invested in. I am heavy invested in SQL server + .net. And this choice has forced me to drop down and use JavaScript for some web work (but I try to avoid as such when possible and can even avoid AJAX in most cases and still avoid web page post-backs). And I use VB.net – a language familiar to me as VB, or several other BASIC languages I used and mastered over the years – including pick.

 

And I am rather comfortable setting up and using IIS (Internet services) say as opposed to working with Apache. So there is “several” layers of technology that one has to absorb and become familiar with – this is a “human” limit and challenge.

 

Given that our human lifespan is only about 32,000 days, then we have limited time to learn new languages (be it spoken ones), or software stacks. Heck 1$ per day = $32,000 over your whole lifespan! That is not a lot of time if count each day as 1$

 

So advantages of .net exist, but only for those companies that invested and adopted that stack. I can’t see one adopting .net if that’s not already a consideration at some company. So for LAMP centric companies, then .net likely of little consideration.

 

I can’t tomorrow out of the blue “just” adopt some new platform, since today such platforms take VERY significant efforts to become productive with – much more so then previous systems I worked on.

 

Regards,

Albert D. Kallal

Edmonton, Alberta Canada

Pleasenos...@msn.com

 

 

[Dawn Wolthuis]

Agree completely from the "management" perspective too. For the past decade or more I have said I was on the .NOT side, and my clients were typically using MV plus open source stacks, including LAMP. All stacks have pros and cons. I said I didn't do .NET simply because I couldn't stretch that far. I was previously also not happy with some of Microsoft's choices (Silverlight, for example).

I hit enough flies in the open source ointment when testing out node.js, with version skew becoming more than an irritant in the open source arena, even with good package management, that I took the opportunity to look more closely at .NET. I also think Satya Nadella is addressing some of the same problems I was seeing, and that guy's thinking seems to align so much more with mine than any previous person in that position that I wanted to have a better idea where MS was heading. I was doing Angular and MS people were talking Angular, for example. Many Angular developers were heading to React or back to MS when Google did terrible marketing and compatibility with Angular 2.0.

I have looked from a consultant and ISV owner perspective looking at what I was testing (full stack JS, node.js, AngularJS, MongoDB) compared to ASP.NET CORE 1.0 with SQL Server (sans Angular). I have done more reading than hands on, but I made a single-page-app and a few other things to get a high-level feel. My hands-on with the Microsoft stack has been slim but enlightening. The skill set required was amazingly similar. Version skew is always an issue, but having a single vendor for the stack has some clear advantages.

When facilitating folks moving MV apps from Rocket to Microsoft, I know some will want to go the .NOT route instead. They can choose to stick with a .NOT stack, including MV DBMS and runtime environment. I understand not everyone was ready when I was to look at .NET while many were far ahead of me in doing so.

I've expanded to the MS .NET side of the house on the developer stack side. That means Tony can say "I told you so" and I can say to the .NOT folks -- more power to you. I'm solving business problems, and I'm not alone in the industry in choosing Microsoft as my platform and stack.

There are pros and cons to every solution. I aim for Big Bang for the buck with overall cost of ownership. I'm working with one full stack JS (node.js, Angular) and NoSQL software company and the others are Microsoft. So, I'll get to see somewhat closely, but not currently as a hands-on app developer, the comparison over time. I think there will be more and more folks who can use both as they become quite similar.

--Dawn

Sent from my iPad

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com