We didn't implement Python BECAUSE IT IS ALREADY HERE

[Dawn Wolthuis]

I'm thinking about what to tell MV folks about MVON# at Spectrum. Those who do not like helping me with marketing tasks, please ignore.

This morning I saw Python run right with MV BASIC, just like C# does for applications running with MVON#. What did we have to do to implement Python for MVON# customers -- NOTHING! Why? Because it is already there. Not only is it running in the same runtime as your MV application (with MVON# your applications runs in .NET), there is also no client-server required -- Python and MV BASIC interact fluidly. Call a python subroutine from your BASIC code and it all just runs in .NET.

So, what is it that YOU think we are doing?

This is the typical scenario for sites running on Microsoft with MVON# -- sites can take advantage of anything out there. With the Python demo I saw this morning, we were using our MongoDB driver as well as our SQL Server driver -- same MV account with different files in different locations. Applications running with MVON# have features no other MV applications have. The answer to questions of "how do you do xyz" tend to be "you just do it, like everyone else does, google it if you don't know."

So, I thinking that what we have implemented is "MV, the Good Parts" allowing Windows and now Linux (Microsoft has done a good job implementing .NET on Linux, we have found) as the O/S, SQL Server or a DBMS of your choice (we have drivers for multiple DBMS's and business customers to date have typically chosen SQL Server), and any languages that run in the Common Language Runtime, including now MV BASIC (when your app, even if currently SB+, runs with MVON# Tools), with all of the interoperability with the rest of the industry that any site using .NET has.

We can be largely a team of techies because Microsoft does their own marketing, but we might all be a bit too close to it to get the mile-high view. People have said "well, we are lucky we found you," so maybe our marketing technique of being largely invisible is working (wink) -- but we can at least let people at Spectrum know what they can do with their application. So, I'm asking for any suggestions related to images, words, and phrases that might help us get the message across. We can see that you, your application, and your company all grow in value. How can we say that? I find the toolset to be truly amazing, but just saying that doesn't help people know what they can do with MVON#.

What is it that you think we are doing? I'm all ears, and will see if it is useful to crowd source some parts of this task. Thanks in advance for any suggestions.  --Dawn

Dawn M. Wolthuis

ONgroup Intl

M: 616-901-6293

P: 800-573-0300 x706

S: Dawn.Wolthuis

[Peter McMurray]

HI

I think that a lot of D3 users would be surprised to find the same answer. I am not yet in a position to be certain but I am in the process of installing MVS Toolkit. This is a different product to MVSP that uses MVSP functionality to interface to D3 that unfortunately hides behind a similar name. Ross Reichardt brought it to my attention due to my interest from TypeScript. Those who have not yet found TypeScript are missing out on a substantial user interface tool. One even expressed doubt about TS running a thick client, When you have an 80 megabyte exe running in Pick let me know because TypeScript does it's called Visual Studio Code.

I wonder if Dawn has Mr Crockford's "JavaScript, the Good Parts" in mind when she posts. :-) 

[Dawn Wolthuis]

Yes, good catch on the nod to Crockford, Peter.  

I have also used "Essence" as in "MVON# is the essense of MV without forcing the choice of operating system or DBMS nor using an MV-only runtime machine." Some might think that the essence of MV is a DBMS, as might be indicated by the name of this google group. It is a data model, along with languages and tools. The VOC (Vocabulary) or MD (Master Dictionary) files are the hub concept. They define everything.

In light of the emergence of the term "Multi-model database" which that is precisely what we do, adding the MV model to SQL Server or a DBMS of your choice, I'm hopeful that soon enough the industry will no longer think of MV first as a DBMS, just as long ago it switched from thinking of PICK as an O/S.

--Dawn

Dawn M. Wolthuis

Take and give some delight today

--
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
For more options, visit http://groups.google.com/group/mvdbms

[Tony Gravagno]

DBMS = Database Management System
The Management System is the entire system of functionality that facilitates management of the base of data. It includes the code that manipulates and implements the model - without such code there is no model. Compare a XML document, that is nothing more than data that is set into a structured model, from an application that performs all of the CRUD on that document to make that document useful. Data without context is usually useless. The DBMS is only distinct from application software in that the application builds upon the core which manages data. SQL Server and mySQL manage the base of data while applications above that tier manage the business-level structures. An application that uses CSV, INI, XML, or JSON doesn't need an underlying DBMS. However, significant libraries have been developed around all of these data storage formats to serve as data managers, to free higher-level applications to focus on their core purpose, rather than on lower-level data manipulation.

MV is not just a model, or rather, it's useless outside of the context of a DBMS. The concept of this model of delimited fields is easily reproduced elsewhere. Descriptive dictionaries, file structures, the BASIC language, the internal data formats and external masks ... all of this needs to be implemented by a tier that is above the raw delimited fields and below the application. This is the tier where the DBMS resides. To remove DBMS from MVDBMS suggests reducing the concept simply to delimited fields, and we do not have a monopoly on that concept.

What ONGroup is doing with MVON# is to add a management system for data over a DBMS. MVON# relies on the underlying DBMS to store data as a text blob. MVON# retrieves that data as an application over SQL Server. It then exposes elements of that data to higher-level consumer code. MVON# implements the MVDBMS using a different datastore. In this respect it's no different than Jedi, OSFI, QM Directory files, Unidata DIR files, or Universe type 1 or 19 files. It compiles BASIC down to C#, which gets compiled down to IL. This is a choice which is no different than compiling down to assembler or C. MVON# also exposes command functions to emulate DBMS functions in other platforms. This is an expected component for competitive purposes but it does further exemplify how this application facilitates management of the database. Where MVON# goes the extra mile is to facilitate external access to the SQL Server fields, with views that parse the blobs. It's an excellent, seamless bridge between what MV needs and what SQL clients expect.

MVON# does not change or redefine the nature of the MVDBMS. It does not separate essence from implementation differently than any other implementation. You know I'm a huge fan of this platform and sincerely respect everything that has gone into it (and MVON Express). What constantly bugs me though is this persistence on pitching it as something that redefines the platform, with new vocabulary that means nothing to consumers and only complicates the offering, with completely unnecessary deep dives into the CLR, and now implied nuances of the term 'model'.

On topic with this thread, I'd like to understand how you suggest Python runs directly from BASIC and/or .NET. This requires a bridge like IronPython or PythonNet which doesn't come with MVON#. Can you provide a code example?

The other platforms are making MV available to Python as a first-class citizen right next to BASIC. MVON# does indeed do the same with .NET, compared to simple language bindings and client/server access. But to compare apples to apples here, you'd need to demonstrate a Python program operating on MVON# data with MV-familiar nuances without the crutch supporting .NET tools. I appreciate the "it's already here" concept but this the exact point where that statement gets put to the test. If it ain't so, then this marketing vector needs to be quietly retired.

Quite specifically on-topic with your request:
1) I'm pointing out how your attempts at technical marketing are confusing with regard to the core offering.
2) I'm suggesting that simple examples would make your points much better than all of the rhetoric of (r)evolution of a model.
3) I'm trying to help by suggesting this is a great product that could speak for itself in much more modest terms. Your job doesn't need to be this hard. Less is more. More seems to be hurting a lot more than helping.

HTH
T

[Dawn Wolthuis]

Thanks Tony. 

a. This helps me see that I will need to be clear about the difference between MVON and MVON#. 

b. We can show you Python at Spectrum. I don't quite understand your comments on that front, so I'll pass that to those more qualified to answer. 

c. We have no difficulty showing how running an MV application using MVON# raises the value of a company in a demo. I'll look at what you wrote to see if it helps me translate that into words.

The only people I know who are skeptics are readers of this list, which makes sense when considering the somewhat religious nature of software choices. We might be perceived as as taking people out of MV into the industry at large. Yes, we do that, but in a way that retains everything an MV site wants while interoperability issues are handled the way that the rest of the industry handles them.

Looking over the types of talks at Spectrum year after year, they fit a similar pattern -- how to do this and that in ways that our users don't need to think about. For example, I love Kevin King's PowerBI talk, and an MVON# customer doesn't need the talk -- they just download PowerBI and aim it at their secured data. Talk after talk is tribal, with, perhaps, defining the tribe in a way that it shrinks over time. We could pop up to talking about Multi-model databases, with MV as one of the models.

It intrigues me that you think we are doing something very similar to others. I haven't seen anything similar. For example, to my knowledge, there are no other implementations of MV applications that employ horizontal scalability, other than those running with MVON#. That is because of the architecture. I think it is second to none, so either I am not describing it well (likely) or I am wrong about how advanced it is over anything else in the MV space.  A site that said "yes" this week said something like "there is nothing else that could possibly take us where we want to go with our existing application." They have seen their application running with it, however. Trying to clarify this in few words without a site seeing their own application running is hard, I think.   --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Dawn Wolthuis]

One of the engineers sent me this when I asked what differentiates applications running with MVON# Tools from those with a proprietary-to-MV platform

1. We can use pure BASIC, pure C#, and pure Python in the same runtime.

2. The same implementation on MVON# runs on .Net Core 2.0 on Windows, Linux an MAC.

3. Python, C# and BASIC developers are immediately productive without having to learn a new syntax

These are related just to the language side of things. On the DBMS side of things, the fact that we can run MV apps with the data persisted using any DBMS or combination thereof (SQL, Document/NoSQL, MV) in the same account and have horizontal scalability in addition to the features of your selected DBMS (Always On for SQL Server is a favorite, for example), certainly seem to differentiate MV applications running with MVON# Tools.

You are correct in thinking that I think that MVON# redefines MV as a toolset rather than a DBMS. You are also correct that the product speaks for itself when someone sees it. I'm thinking about how to use words that help people make the decision to see it. Some phrases I've used in ppt slides are

Raise your Value

Choose what you wish to run ON

Roots and Wings

MV now runs on Microsoft

MV runs in .NET with SQL Server

Thanks for your input. See you at Spectrum.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

On Thu, Mar 15, 2018 at 3:34 PM, Tony Gravagno <bacj8...@snkmail.com> wrote:

[Peter McMurray]

Hi Dawn

As you say semantic haggling. Data storage is rather like the difference between engines. Which is best? Diesel, petrol, gas or electric. It depends on where it is used, how easy it is to implement and how much it costs.

As always something does pop out. How do you run on a MAC? That surprised me. Do you run PARALLELS or do you run native?

The beauty of TypeScript is that it runs on all platforms because it transpiles into JavaScript that all platforms have implemented in their native code.

Yes you do debugging in Javascript not TypeScript although the bugs are dramatically reduced with TS logic checking. Plus presentation is dramatically eased with products such as Angular and Vue; which buy the way use different methods of addressing state storage, so where does DBMS start and finish?

In my opinion when using Rocket, QM or Jbase the best place for CRUD is the basic but that may change with MVON#. 

Note for the semantic hagglers! Transpile does not equal compile. I transpile my D3 code into U2 code then I compile into platform specific code. In fact the D3 Compile (o) option picks up a different code set to the Basic option so even that is transpiling before compiling. Apparently transpile has not made it into Google Group dictionaries yet. A surprising omission.

[grant...@prosol.co.za]

Hi. Tony

Thanks for you excellent description of MVON# architecture. I am going need to borrow it (with your permission)😊
To answer your question on how we achieved Python integration without a bridge or client server architecture.

We using technology developed initially by Microsoft called IronPython. Microsoft developed a technology in the .Net framework called the DLR. This allow for dynamically generating CIL code for execution within the same process that you are running. Because we are essentially running C# CIL, we pass the Python script to an instance of IronPython engine, all common variables and session details (which are in the process you are running) are available.

This is the same mechanism that we looking at to be able to expose any .Net language to be used on MVON#.

Short description but would love to engage you on lower technical levels

Cheers

[Patrick Payne]

You are correct that TypeScript is a transpiler just like coffescript.  Microsoft I think built this out to influence the direction of javascript and you can see it with EC6 specifications.

It will be interesting to see where Microsoft goes with c# and the entire platform.  Google pushed pretty hard on javascript and built out the V8 engine that then produced the Node server side engine.  Since your only option in the browser was javascript many users liked the idea of coding at both sides with the same language.  Microsoft is shifting quickly and .net core 2.0 appears to be their answer. This is NOT .net you see on windows, it is actually a open source .net engine and you can see the heavy influence of Node.  I just recently installed .net core 2.0 on my Centos 7.0 machine and it looks and behaves just like Node does (all command line, pull apps down, runs app as a contained app on a custom web port, etc).  It currently lacks everything full .net has but Microsoft seems to be closing the gap quickly.

Another item you see happening in the space is a blurring of the app code and the database.  In the Mongo space for example they have what is called map reduce to do data analysys.  Map reduce appears to really be a code deployment system.  You write a javascript query program to "map" out some information you need.  The code is deployed to each data node in your cluster and is run directly on the node server next to the data.  Since mongo is clustered this could be against multiple "shards". The reduce part is the results coming back and being added back together.  It looks like Microsoft is going the same way and replacing triggers with some type of stored/server side .net code which is what I believe MVON# is using.   Bottom line is you are running code on your database server.  This allows those systems to start approach classic pick speeds when we run code directly on our server (the norm) while manipulating or searching large datasets. 

I have to think in a few years you are going to see javascript via TypeScript/EC6 and c# get very close in style/functionality and that there will be compilers/transpilers/etc that allow code to run in either.  That is my guess.  It is interesting for example that Visual Studio Code is all written in javascript/node and not C#/.net core which must make for some interesting internal discussions.  I can see this changing in the future.

btw - When it comes to language bindings most languages offer C level bindings.  Since jBase is a C program we can pretty easily call into .net and python and java since they all have a C binding. The challenge always is mapping your variable types. I recently found out the U2 implementations are actually using unirpc I believe to bind between the two and I believe it causes some slowdowns.  It is much better to bind in the two.  To be honest I keep pushing that these all should be microservices.  If you really wish to have a Python based function that you are calling from pick I would build out a python web service and fire it up as a micro service.  This keeps you from incurring the overhead of firing up the interpreter on every call.  This is the way java applets are usually deployed.  If you install .net core and fire up a application you will see a 2-4 second delay before the app fires up.  But once fired up it is fast!  The .net way is more unique in that it wants to use CLR as the interpreter for all the languages which is what I believe IronPython is doing.  With jBase if you wish to go the other way and directly call jBase functions from Python and it is pretty fast because the jbase functions are really just C dlls or shared libraries.

I have never actually used it but here is a example of calling .net from jBase.  https://jbase.com/r5/knowledgebase/manuals/3.0/30manpages/man/jbc2_CALLdotNET.htm

[grant...@prosol.co.za]

Hi Peter,

Microsoft has spent a huge amount of effort in producing a single codebase .Net has implementation that runs natively on Windows, Linux and OSX. It is referred as .Net Core 2.o. (2.1 just realesed). This primarily came out of their acquisition on Xamarin.

The exact same dll’s generated on windows run on all 3 platforms without recompilation.
This has enabled us to to use the exact same object on all 3 platforms. The only effort we had to do was to put some compiler directives to cater for the different security models in each environment

[Peter McMurray]

Delighted to see some informative replies These are what I was hoping for when I posed which language.

I am intrigued by the split now being shown with user level Javascript on the client an in between layer on the server and then the database layer quite possibly with all 3 layers on separate machines. What is even more interesting is the asynchronous calls being developed by companies such as Vue where one gets the page ready in the middle layer. The separation of the state from the DOM as in Vue has significant advantages in my opinion.

Getting one's head around these layers can lead to a much better user experience and that is what programming is about. If nobody uses it then the greatest ideas are simply sound bites - Beta tapes anyone, better tech but marketing cruelled them. 

The Google/Microsoft joint effort on TypeScript overseen by the designer of Turbo-Pascal, Delphi and C# is a force to be reckoned with.

[Tony Gravagno]

Grant - always great to exchange notes with you.
I wrote a response a few days ago but set it to the side to think.

As I said in my first response, mixing Python with BASIC in .NET requires a bridge like IronPython, some kind of magic sauce that's not really in there by default. You've confirmed that that's what you're using.
It's great that you're using the DLR to marshal data types between languages. The other platforms are passing around variables and references to objects in a way that's much less elegant, more bolted-on than builted-in.

While it seems like Marketing fodder to go on about the methods used by these tools to integrate components, I think in reality that's not relevant as it only becomes a matter of syntax. Consider:

* Made up, but close to actual BASIC syntax with Python integration
INPUT NAME
CUST.REC = getPyObj("customer",ID)
RESULT = pyFunc("setCustField",CUST.REC,"Name",NAME)

If that can be used in an existing MV system then it doesn't resonate with the average BASIC developer that all they need to do is to change their database platform and write code in Visual Studio with Iron Python to get "ALREADY HERE" functionalty. In MVON# there is elegant syntax between BASIC and C# in the same code module. I suspect you can do the same as elegantly with Python or VB.NET, something like:

* Again, made up syntax
NAME = "Jane" ; * start with BASIC in MVON#
[C#]
   doSomething(TEST);
[/C#]
[Python]
def doSomething(info)
     print("Hi " + info)
[/Python]
CRT "That was cool!"

The only difference here is syntax.

I'm not criticizing or negating the claim that doing this is easier with MVON#, once someone is using it. I'm suggesting that now that other providers have done this in the traditional MV environments, that app developers don't need to port to a new platform for this functionality.

And (kinda OT) I'm sorry that the other DBMS providers don't understand their own offering well enough to recognize that they didn't need to come up with completely new syntax for their Python implementations when existing syntax would have been fine:
Consider:
HANDLE = getHandle("Foo") ; * prepend % for D3
RESULT = func(HANDLE,"myFunc",123,"ABC")
It shouldn't matter if that's a handle to Python, Java, C++, or Foo. I should be able to use the exact same syntax to invoke functions regardless of the underlying technology. Do we really need a new set of pyFunctions() with unique syntax? Will an implementation for Java really need to be done from scratch with changes to the BNF? Has anyone thought yet that the exact same structures can now be used to support any language? (Where I believe they're persisting state in handles in phantoms)

Meh, that's the result of some high-octane coffee. Time to get back to work.

Best,
T

[Tony Gravagno]

"It intrigues me that you think we are doing something very similar to others. I haven't seen anything similar. For example, to my knowledge, there are no other implementations of MV applications that employ horizontal scalability, other than those running with MVON#."

I believe that's due to lack of familiarity with the competition, a bit of tunnel vision, and poor marketing by your competitors. I'm reminded of a blog by a kid who said he thought PHP was "The Best" programming language ... and it turns that was because it was the only language he knew.

Consider:
- jBase has operated close to the OS since its inception. That means it's "horizontally scalable" with the OS. With jEDI it has always been able to use RDBMS datastores and benefit from their scalability.
- D3 supports networked systems such that many servers can host data that represents a single application. It's the failing of D3 Marketing to hype and explain this feature, not a failing of the platform.
- Universe and Unidata have both proven themselves to scale to whatever size required for large installations.
- Caché, and thus the MV implementation within, is vastly scalable.
- Heck, even QM claims to be scalable - I'm not sure if that's "horizontal" or vertical (just add more hardware).

"The only people I know who are skeptics are readers of this list"

This isn't skepticism, like negative energy from "the usual suspects", requiring stalwart fortitude to repel and overcome. Remember that I'm a fan of the offering. Skepticism is when someone doesn't believe that what you're saying is true or possible. This is resistance to redefinition of words and global concepts. It's rejection of the notion that your company is doing something radical with the data tier when they're not. They ARE doing cool things at the application/development tier. You're getting honest feedback from people who actually know what's available in the industry in which you're trying to operate. I know you're excited about things that you're learning but that doesn't entitle you to then redefine concepts for the rest of us as a part of your process.

Again, this steak already has flavor and sizzle: People don't need an analysis of the dB of the sizzle. People don't want details about the digestive system of the animal. You can't redefine the nature of meat, and putting this steak in another category just means people won't find it with a search for "steak". Consider - after all of this time you're still trying to figure out how to market this offering. It shouldn't be that tough. Less is more. Take it from someone who writes a lot more when he should be writing a lot less. ;)

Regards,
T

[Will Johnson]

What's the reasoning behind not just putting up a video freely viewable without appointment, on YouTube or somewhere else?