[AD] Requesting eyes. What questions does this prompt?

[Dawn Wolthuis]

Due to a recent partnership, I'm working on a web site that is not yet ready for prime time for a product that is already deployed and in production use (although quite stealth). Before we do a Press Release and get more eyes on it, I'm all ears regarding comments you have on this (still quite minimal) content. 

  

http://mvsharp.com

QUESTION: For the information on this site to be the most useful, what questions would you like to see answered in what is currently a brochure-ware start? Feel free to respond either on the list or off-list. If on the list, please be nice. Smiles.

Thanks in advance.  --Dawn

P.S. If anyone is interested in knowing more about the products, there is an email address on the contact page, or you can ask me.

 

P.P.S. I paid for the WordPress template but not yet for the features to customize it, so I'm happier getting content suggestions than template changes. I'm trying to avoid those for starters as they have been known to suck both the time and life out of me.

--

Dawn M. Wolthuis

President, Tincat Group, Inc.

Take and give some delight today

[Rex Gozar]

The question I'd most like to see answered is "what is it?"

I read the webpage, but I'd be hard pressed to tell a colleague what it is.

rex

> --
> 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

[Dawn Wolthuis]

Thanks Rex -- Perfect feedback. That is very helpful. 

If I tell you that it is a "transpiler from MV to C#" that might seem understated, but that is what I have been telling people. Too nebulous? "MV running in .NET using Microsoft's runtime rather than an MV-specific p-machine"? "MultiValue running in the Common Language Runtime"?

The product takes MultiValue code, whether MV BASIC, MV Query, TCL, PROC and runs it with VOC, DICTs and all, in .NET. Using SQL Server (or Oracle) is optional, but everyone so far has opted for it.

Suggestions for how to say this?  Thanks.  --Dawn

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

> For more options, visit http://groups.google.com/group/mvdbms

--
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

--

Dawn M. Wolthuis

[Rex Gozar]

"Compile your MV BASIC application to run in Microsoft C#"

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

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

[Dawn Wolthuis]

Thumbs up. I put the logo-with-tagline back in the header and I agree -- I'll fit those words in so they are clearer.  Thanks. Rex.  --Dawn

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

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

--
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

[Dawn Wolthuis]

Made some changes to https://mvsharp.com/ so I think it should be clearer what it is about. Thanks Rex. Any and all comments appreciated (in spite of having previously said they should be "nice"). No actual marketing folks were harmed in the making of this site (just me doing marketing-emulation), so your suggestions are very much appreciated. Thanks.  --Dawn

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

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

--
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

[Glen Batchelor]

I'm trying to understand why I wouldn't just use something like MV.NET to transpose the existing rules into methods and objects. What does this save? Benefits over a native .NET offering?

[Dawn Wolthuis]

Thanks Glen. It is a "native .NET" offering if I am understanding your question, Glen. MV.NET still has the rules running in, effectively, a PICK p-machine (e.g. UniData, UniVerse...). 

MVON# tools have everything running in .NET. Does that sound clearer?  --Dawn

[Glen Batchelor]

From a business perspective, to sell the product, what is the benefit over one-another? You eliminate the Pick side with one and not the other? Development is still done in a .NET IDE to build the application either way so why convert to C#? Cheaper developers? I've been working in Progress OpenEdge and honestly I don't see a benefit to running any of them over one-another except for personal preference and licensing costs.

[Dawn Wolthuis]

Thanks Glen. I agree that it would need to align with a goal an organization has to work within .NET, not unlike when we moved from Primos to Unix in order to run on an common O/S.

I see it as a progression of MultiValue. It was a proprietary operating system, typically now a proprietary p-machine on common operating systems, with a natural progression to tools that now run with a common runtime environment. .NET and the Common Language Runtime fit the bill, turning MV into .NET managed code.

I'm definitely interested in both what questions arise from looking at these posts and any reasons you can think of why a site might be interested. What I see is that it can raise the value of a software company and those using their software applications from some objective perspectives when heading into the .NET world in this way. Is that something clear (CLR??) or highly subjective from your perspective?  

I'm also working with SQL Server with MV#, so some of the gains are from that. I told someone recently that in 2006 I told people in a presentation that UniData was faster for many tasks than SQL Server, but now it anecdotally sure is not. I asked an expert when that happened. They said that SQL Server 2008 R2 had indexing and other enhancements that turned the tables on that. Not only that -- now I just point PowerBI and SSRS at the data without any export required. It is very cool.

--Dawn

[Glen Batchelor]

 The progression of multi-value is also its demise. Multi-value doesn't need to progress it needs to embed and expand which is what some people are trying to do with OpenQM. With SaaS and PaaS popping up everywhere and hadoop filtering into the data storage setups the monolithic environment is going away and the only benefits left from MV are the language and the storage structuring.

[Dawn Wolthuis]

I almost agree with you Glen, except that I would say that the benefits are the data model and the languages, which are the things we retain. You get your data projected both as MV and as SQL at the same time. In the past I have seen examples of tools that made me think we had the worst of both worlds. This one gives the best of both worlds. I'm fine with hash tables, but I don't live and die by them. I'm a pragmatist, not an evangelist. If SQL Server is a whole lot easier for my customer to work with, then I don't need to do headstands to provide hash tables. Does that jive with your angle too?

Oh, by the way, another ONgroup product, MVON, can run as a back-end to OpenQM if you prefer to use the cool features that Martin and company have put into OpenQM. We can persist the data in SQL Server so you use it in MV as you would if it were in a hash table but it is right there were many people want it to be. We were going to market this, but the .NET product captured our imaginations more and we think there is more call for it. We have an awesome OpenQM SQL Server tool, however, as soon as there is someone interested. That is with MVON rather than the MVON# tools. There is a free version of MVON Express but we will not package MVON for OpenQM until someone is interested. I have seen it and Martin has seen it and it is very cool.

Cheers!  --Dawn

[Tony Gravagno]

Lots of thoughts. Please don't take this as being critical. This is just what I'm thinking, no evaluation of fitness or quality intended.

1) If I understand what's being done, I disagree with the description "Compile your MV BASIC application to run in Microsoft C#" .
This isn't running IN C#. There's no such thing as running IN C#. If the BASIC code is being converted TO C#, then it IS C#, and this is the literal definition of the word "transpile".

2) The problem with such tools is that when they fail we often don't know what happened. If the C# source is a black box, perhaps deleted after compilation, then a developer will need to do a lot of guessing to figure out why something went wrong: Should I modify my BASIC source and re-transpile? Is the translation incorrect? Did they generate invalid C#? Is it valid C# but something invalid in the query/execution? So unless the C# source is available I would consider this extremely limited. I have no doubt that this is the reason why "to date our customers have all opted to acquire the tools with the source code".

3) It seems obvious that the first task is to ensure the BASIC code is MVON-compatible. If that doesn't work then it doesn't seem likely that a translation to C# will work in the same environment. So this presents another tier of effort to an adopting developer.

4) As with all such efforts, the UI needs to be stripped out. While this is clear and obvious to any of us who do this kind of work it might not be to someone new to the game. More specifically, INPUT and CRT statements have no place in this code unless the C# renders a character UI. PRINT statements are OK but only where they generate a report. A parser will probably not understand this. So common code may need to be prepared, replacing PRINT with CRT for screen output - so that the CRTs can get stripped anyway.

5) C# is object-oriented. MV BASIC code is not. I'm really hoping that the implementation doesn't do line for line translation, creating a single monstrous C# method from a BASIC program, with all of the tasty GOTO goodness included.

6) And what about GOSUB? Are subroutines abstracted out into methods? If so, how is variable scope managed? BASIC variables are globally scoped but C# variables are private to their methods - unless the transpiler globally scopes all vars.

7) And what about data typing? Nuff said.

8) "SQL Server is optional. MV# works with MultiValue DBMS products too." OK, so we convert MV BASIC to C# and then run that back against MV? OK, there is some advantage there but it really does take the rules further from the DBMS, which is opposite of what's being done with SQL Server where C# code can now be run in the DBMS as stored procs. That one quote can't be picked apart in a brochure but there's a huge discussion that goes behind it about Why we would want to do that.

9) Implied in the site but not emphasized is the benefit where BASIC>C# code can take advantage of the wealth of other .NET code (doesn't even need to be C#). That said, what this implies is that once the code is moved to C# and enhanced to take advantage of the benefits of .NET, that the BASIC code could be deprecated. Or there will be this weird hybrid of "we need to stay with the C# here but the rest of it there is still BASIC". What's happening here is that there may never really be a full transition from BASIC to C# for some/most apps. So what's the point of the effort if both skillsets are still required? This is some of the challenge that InterSystems had, where they encouraged developers to recode into a OOP/BASIC hybrid.

What this all comes down to is that crappy BASIC code will transpile to a pile of crappy C# unless there is a lot of preparation done on it. Without the C# source, it stays crappy. Aside from my point #2, one could say "why do we care about the C# source? we write BASIC code, it runs in a RDBMS, we're done!" But if we just run BASIC code in a RDBMS we have MVON (a fine offering) - why bother with the C# and this whole MV# concept?

So I'm wondering what the MV#/C# part is buying us. And I really hope this isn't yet another "this will do it all for you...except for that whole slew of things that it doesn't do", which is the same problem that every other similar offering in this space has had.

And as an aside, I find a huge sense of irony that the MV person most fervently against anything Microsoft and .NET is now involved in this fascinating offering.

HTH
T

[Kevin Powick]

Interesting, but I agree with Glen and Tony.  My questions reflect some of what they've said.

Why would a site want this? What problems does it solve?

If I'm going to use the .Net platform and SQL Server, why would I add the MV layer at all?

If I'm doing this to "convert" MV to C# code, it seems that mvBasic, green screen, code will require a lot of massaging before it can be "transpiled" to C#.

Tranpiled to C# implies that the result is C# code.  Can this code be examined and edited?  If not, then where's the upside?  I still use/need MV programmers, vs. abundant C# programmers, and the only "improvement" is that I can tell someone the MV code is ultimately executed under the .Net runtime environment (CLR).

I've likely misinterpreted the features and intent of of this product offering, which perhaps indicates where work on the website needs to be done.  I'm looking forward to learning more.

I know you don't want any website design advice, but here is some anyway from a guy that can't even draw stick figures.  If you're serious about the product(s), hire a professional to do the website and marketing materials.  It's money well spent.

--

Kevin Powick

[Tony Gravagno]

Kevin Powick wrote:

If you're serious about the product(s), hire a professional to do the website and marketing materials.  It's money well spent.

(OT, sorry) And don't bother buying WordPress themes until you really know what you want. There are thousands of free ones out there and even the ones you buy won't last for more than a couple years given that WP has frequent major releases. Also, WP has matured from being blogware into a full CMS. Whatever you do, try to keep it from looking bloggy unless that's the intention, in which case, don't try to hide the blogginess.

More ON-topic. (Get it? ON? nevermind...) I just wanted to re-affirm as Kevin did that none of this is critical on the product or the website. I think we're all constructively poking holes at the Marketing (messaging and presentation) so that you have a good idea of what you're going to be facing in the sales cycle and beyond. I DID offer consultation for the .NET initiatives sometime last year and would have had the exact same comments back then. (Wow, two "I told ya so's" in one thread, I'm on a roll!) :)

Good luck.
T
(Now spending more time with WordPress and Minecraft than MV/BASIC, and a little happier.)

[Ross Ferris]

I'm not seeing anything FAB here (feature and benefit = something that tugs at my heart strings to make me want to buy). One could argue that transpiling isn't new - jBase have been doing it for years. Tempt me with some sizzle - I want to smell that BBQ so I can salivate with anticipation. </crickets>

The One & Done option implies a one-off fee whereby I get my code transpiled, delivered as source that I can compile & run against SQL Server (rather than my MV platform of choice) & don't have to pay for anymore runtime licences (apart from SQL Server) ... what I don't get is the magic bullet whereby my application now has a GUI face,or do I?

So, now I have (possibly) spaghetti code in a language I don't know or understand, tied to a database I have no knowledge of, and depending on how the mapping from MV --> SQL is handled, I may not even be able to get any benefits from the fancy point & click query tools that can be run against SQL Server. I probably have significant refactoring involved in getting my new GUI face on, which I'll have to hire new talent to do, so will I actually save money using this product over just starting again with my conceptual design & do "properly" using toolset of my choice.

To some extent this reminds me of PicLan ... great product with a loyal following, but a little late to the party and so never achieved the heights it was capable of.

Why would I want MV# if I'm keeping my MV database intact, when I could now leverage Python from UV, or use MV.NET as a gateway --> how does this option compare on a price basis.

I can't find anything to excite me on the website. This may be something new from MVON, or it might be the same old stuff with a new sticker, but I'm not feeling excitement when I look at the site, nor are the words jumping off the page, and the sad reality is that even if you ticked these boxes I'm not sure that people are going to pony up the $ or time to make it work.

Please prove me wrong :-)

[Simon Verona]

I'm kind of joining in on the skeptical camp here.

The thought is why would I want this product?    Who is the intended audience?  What is the end game?

Is the aim to migrate away from MV licencing by "porting" the code to c#?

Or maybe to leverage SQL Server as a datastore ?

or to open up development to the wider pool of development resources (dotnet developers)?

Most MV products will allow use of RDBMS datastores as "native" databases, so I don't see any advantage on this point.   My experience of transpilers is that the resultant code is not in a style that is then maintainable (jbase for example doesn't expose it's intermediate c code for pretty much this reason) - so whilst not having viewed the product, the limit may simply be down to licencing ?       

I'm struggling here - particularly as a software development company that works in dotnet AND data-basic(we use vb.net for client, databasic for server, QM for database) - I struggle to see the need for this product.    

I hate to be a downer, but I don't get this product. 

I guess I'm echoing much of the response here... 

Simon

[geneb]

On Tue, 1 Nov 2016, Tony Gravagno wrote:

>
> T
> (Now spending more time with WordPress and Minecraft than MV/BASIC, and a
> little happier.)

[WAAAAAY OT]....
Tony, try Minecraft on the Oculus Rift. It's AMAZING. :D

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_!

[Dawn Wolthuis]

Thanks Tony, Kevin, Ross -- Like Glen and Rex, your responses are very helpful. I can definitely see where your comments and questions are coming from.

Because I have seen the products with real applications, I am confident that, as Tony mentioned, the messaging here could be better. The product rocked my world, and I can see my words are definitely not, so I will work on painting a more accurate picture. 

Of course, it is also the case that no tool is for everyone, although most people have migrated from Pick as an O/S to Pick as a DBMS. I think it will become a natural progression to start using a common runtime container. I thought for sure you would pummel me for being so late to the .NET game, Tony. I've been a .NOT person for a long time. I like where Satya Nadella is taking the company. They are speaking my language and giving me open source tools backed by Microsoft. So, I'm all in now. I even like Xamarin and I'm interested in Mono and SQL Server on linux too. I thought I'd get a big "told you so" on the .NET side from you.

What do you think about this --

The key thing I think I am downplaying with the messaging is that the transpiler produces code that really runs in .NET. Your full MV environment is right there in .NET. It is, effectively, a .NET implementation of MultiValue. When you start using MV# instead of MV, your application runs in the .NET CLR.

In response to other comments in this thread, while we could have made it a compiler direct from MV BASIC to CIL, having C# in the mix add in a positive way to the efforts. Yes, to Kevin that you can (optionally) have the C# there to inspect or use for debugging. Application software companies often have their own proprietary way of doing screen generation. If you have a screen generator written in MV BASIC, well, now you have one for .NET. Sure, your team will be doing some things differently than the software company down the road, but that is always the case. Your .NET developers will not only know C#, they will know your .NET tool set. That's the norm. That yours includes the MV BASIC language makes it a highly productive environment for highly useful green screen apps. That everything runs in .NET (and with SQL Server) makes it highly usable.

I'm all ears on how to say this so that it resonates. I'll work on it some more too. Thanks.  --Dawn

--
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

--

Dawn M. Wolthuis

[Dawn Wolthuis]

Just saw your response too, Simon. Thanks. Your questions are helpful.

One question I have -- you wrote "Most MV products will allow use of RDBMS datastores as "native" databases, "  I know that MVON does this and also jBASE has the feature because Temenos uses Oracle. I also know that Ellucian uses UniData as middleware, but I don't know of anyone else using it that way. Are there people using U2 or D3 for the application with only SQL Server storage?

I'm going to mull over your comments about transpilers. TypeScript transpiles to JavaScript. This was once frowned upon, but is now pervasive in the industry and highly useful. No, we would not expect you to then maintain the C# code directly. MV# would be the language for the screens written in MV#. C# would be the language for a corresponding mobile app, perhaps, and you also have a full range of tools when you are sitting in the .NET world, as you know.

I'll re-read all of these. Keep 'em coming. If anyone "gets it" from my descriptions here, that would also be helpful to know. Clearly I have some work to do.  Thanks. --Dawn

--

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

--

Dawn M. Wolthuis

[Simon Verona]

Dawn

Just picking up on transpilers - I think the key here is to clarify *why* you are transpiling.  If it's to make a standalone executable that doesn't need an environment to run in, and c# is a means to an end, then this is very different to "convert your code to c# and maintain from there" 

In many respects I guess it's up to the person reading to see what they want and whether this does what they need.   For me, products like mv.net fulfill this requirement better, as they are native c# and provide middleware to a MV backend.   We have a middleware layer that does the same.    I don't buy user licences for QM - we have a few server based ones for our middleware to run with and that's it.    There is no QMclient in our dotnet client code.

For someone who has databasic code that they want to port, by definition the code will either have a) no user interface, or b) be character interface in nature.   Option a) makes little sense to port as it's "server-side" code anyway in likelihood.  Option b) presumably builds a character console app in c#?       If I wanted to build a User Interface with this code then I'd have to wire in c# forms (windows/web ?).  In my experience, it's better to re-write, separating the User interface from the business logic.  The Business Logic should reside close to the database anyway and the user-interface would need constructing from scratch in any case - I don't see the win with MVON. 

My  *fear* is that you have re-invented the wheel.... 

Sorry if I sound negative, or haven't understood your product!

Thanks

Simon    

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

For more options, visit http://groups.google.com/group/mvdbms

[Kevin Powick]

On Wednesday, 2 November 2016 09:43:40 UTC-4, Dawn Wolthuis wrote:

The key thing I think I am downplaying with the messaging is that the transpiler produces code that really runs in .NET. Your full MV environment is right there in .NET. It is, effectively, a .NET implementation of MultiValue. When you start using MV# instead of MV, your application runs in the .NET CLR.

In response to other comments in this thread, while we could have made it a compiler direct from MV BASIC to CIL, having C# in the mix add in a positive way to the efforts. Yes, to Kevin that you can (optionally) have the C# there to inspect or use for debugging.

So, you're saying that MV# is like a "new" CLI language such as F#, Oxygene (pascal), IronPython, etc, BUT you are first converting/transpiling to C#, then compiling THAT C# code for the CLR?

If that's the case, why not go all the way an have MV# be a new, fully fledged CLI language? 

Though you indicate that the C# produced can be inspected, I'm guessing it cannot be edited, as all edits would be lost on the next compilation of MV code.

Since you're calling it MV#, the big question for anyone familiar with .Net and # (sharp) languages is, will I be able to use and have the full power of Visual Studio at my disposal?  i.e. Can I create a new MV# project, drop a component on a form and code MV# Basic for that form?

Again, not being critical, just trying to understand both the product and the use/business cases.

--

Kevin Powick 

 

 

Application software companies often have their own proprietary way of doing screen generation. If you have a screen generator written in MV BASIC, well, now you have one for .NET. Sure, your team will be doing some things differently than the software company down the road, but that is always the case. Your .NET developers will not only know C#, they will know your .NET tool set. That's the norm. That yours includes the MV BASIC language makes it a highly productive environment for highly useful green screen apps. That everything runs in .NET (and with SQL Server) makes it highly usable.

I'm all ears on how to say this so that it resonates. I'll work on it some more too. Thanks.  --Dawn

On Tue, Nov 1, 2016 at 3:05 PM, Tony Gravagno <bacj8...@snkmail.com> wrote:

Lots of thoughts. Please don't take this as being critical. This is just what I'm thinking, no evaluation of fitness or quality intended.

1) If I understand what's being done, I disagree with the description "Compile your MV BASIC application to run in Microsoft C#" .
This isn't running IN C#. There's no such thing as running IN C#. If the BASIC code is being converted TO C#, then it IS C#, and this is the literal definition of the word "transpile".

2) The problem with such tools is that when they fail we often don't know what happened. If the C# source is a black box, perhaps deleted after compilation, then a developer will need to do a lot of guessing to figure out why something went wrong: Should I modify my BASIC source and re-transpile? Is the translation incorrect? Did they generate invalid C#? Is it valid C# but something invalid in the query/execution? So unless the C# source is available I would consider this extremely limited. I have no doubt that this is the reason why "to date our customers have all opted to acquire the tools with the source code".

3) It seems obvious that the first task is to ensure the BASIC code is MVON-compatible. If that doesn't work then it doesn't seem likely that a translation to C# will work in the same environment. So this presents another tier of effort to an adopting developer.

4) As with all such efforts, the UI needs to be stripped out. While this is clear and obvious to any of us who do this kind of work it might not be to someone new to the game. More specifically, INPUT and CRT statements have no place in this code unless the C# renders a character UI. PRINT statements are OK but only where they generate a report. A parser will probably not understand this. So common code may need to be prepared, replacing PRINT with CRT for screen output - so that the CRTs can get stripped anyway.

5) C# is object-oriented. MV BASIC code is not. I'm really hoping that the implementation doesn't do line for line translation, creating a single monstrous C# method from a BASIC program, with all of the tasty GOTO goodness included.

6) And what about GOSUB? Are subroutines abstracted out into methods? If so, how is variable scope managed? BASIC variables are globally scoped but C# variables are private to their methods - unless the transpiler globally scopes all vars.

7) And what about data typing? Nuff said.

8) "SQL Server is optional. MV# works with MultiValue DBMS products too." OK, so we convert MV BASIC to C# and then run that back against MV? OK, there is some advantage there but it really does take the rules further from the DBMS, which is opposite of what's being done with SQL Server where C# code can now be run in the DBMS as stored procs. That one quote can't be picked apart in a brochure but there's a huge discussion that goes behind it about Why we would want to do that.

9) Implied in the site but not emphasized is the benefit where BASIC>C# code can take advantage of the wealth of other .NET code (doesn't even need to be C#). That said, what this implies is that once the code is moved to C# and enhanced to take advantage of the benefits of .NET, that the BASIC code could be deprecated. Or there will be this weird hybrid of "we need to stay with the C# here but the rest of it there is still BASIC". What's happening here is that there may never really be a full transition from BASIC to C# for some/most apps. So what's the point of the effort if both skillsets are still required? This is some of the challenge that InterSystems had, where they encouraged developers to recode into a OOP/BASIC hybrid.

What this all comes down to is that crappy BASIC code will transpile to a pile of crappy C# unless there is a lot of preparation done on it. Without the C# source, it stays crappy. Aside from my point #2, one could say "why do we care about the C# source? we write BASIC code, it runs in a RDBMS, we're done!" But if we just run BASIC code in a RDBMS we have MVON (a fine offering) - why bother with the C# and this whole MV# concept?

So I'm wondering what the MV#/C# part is buying us. And I really hope this isn't yet another "this will do it all for you...except for that whole slew of things that it doesn't do", which is the same problem that every other similar offering in this space has had.

And as an aside, I find a huge sense of irony that the MV person most fervently against anything Microsoft and .NET is now involved in this fascinating offering.

HTH
T

--
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

[Dawn Wolthuis]

I just re-read all of the responses and I do see that Tony added a comment about it being "ironic" that I'm proposing a .NET solution. I'm a pragmatist, not an evangelist in that way. Satya Nadella's directions have brought me into the .NET world. There are good reasons to be here.

I'm working on responses to many of the questions. My angle has been on the advantages to the business, so I'll try to get some clearer statements on that as well as address some of the technical questions. This is very helpful.  Thanks.  --Dawn

[Dawn Wolthuis]

Yes, good questions Kevin. I have some information from the developers and will try to clarify. What I have seen work is C# libraries included and C# code employed in an MV BASIC program, so the full power of .NET services are available.

Yes, you can edit the C#, and you are correct that would not be ideal as then you would be working with the generated code as your source, ditching MV BASIC. Some might decide to do that as it is viable, but we have not seen anyone do that. There is no reason. The MV# tools include the colon prompt and everything we expect, plus they run right in .NET. You can continue to use the tools and supplement with the full range of Microsoft offerings.

Your questions are helpful in clarifying the information presented to people. Because the products are in use, we can see the whole new world they open up and hard ROI with the savings in "per seat" and connection pooling licenses, for example, that people gain. So, now I just have to work on communicating the story in a way that people know what it is. This is not small in the MV space, and I have no doubt that many people could raise the value of their company and of their software applications because of what it can provide for end-users as well as developers. You guys are helping me, as I was certain you would, sharpen the saw on just what is so terrific.

I'll pull a better list together and maybe add a new entry to the blog laying out some of the benefits. It will take me a bit, however. It would be good to know if there is any benefit that you are able to guess might be there based on what is on the site.

Thanks.  --Dawn

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

For more options, visit http://groups.google.com/group/mvdbms

[Dawn Wolthuis]

One thing to clarify, Ross, is that with ONE & DONE, you get all of the source to MV running in .NET. In other words, you no longer need an MV vendor at that point as you have it all. This is not for everyone, but it helps companies who are concerned about the risk in working with MultiValue. How does that sound?

Another clarification is that this is not MVON proper. MVON has its own p-machine. This product was written by our partners in South Africa, which might be why it works for System Builder customers too (with our Netbuilder tool). Does that help with the FAB factor? I'm still working on writing it up better but thought I would respond to these points.  Thanks.  --Dawn

--

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

--

Dawn M. Wolthuis

[Kevin Powick]

On Wednesday, 2 November 2016 14:47:04 UTC-4, Dawn Wolthuis wrote:

One thing to clarify, Ross, is that with ONE & DONE, you get all of the source to MV running in .NET. In other words, you no longer need an MV vendor at that point as you have it all.

Ah.. Now I better understand part of this.  This is essentially a new "distro" of a MVDBMS, right? 

Someone switching to this would no longer use D3, QM, U2, etc.  They would migrate to MV#; An implementation of a MVDBMS which runs under .Net and includes familiar MV concepts such as Proc, TCL, and mvBasic.  Under the hood, the mvBasic code one writes is transpiled into C#, which is then compiled so that it may execute against the CLR.  Also, if one so desires, their data store can be handled by SQL Server.

It was the MV # name tripping me up, as I associated that with just a language and not a completely new flavour/distro of a MVDBMS.

It probably would have been better to call it MV.Net, but I guess that name was already taken. ;-)

Ok, I think I get it.  Now... performance, cost, migration effort, vendor size and support offerings, success stories, etc.

--

Kevin Powick 

[Glen Batchelor]

 Also, if I understand correctly, you can inject calls to methods and objects in MV# markup while in the BASIC code so you can re-purpose the business rules without having to port it all over.

[Dawn Wolthuis]

Yes, yes, perfect, Kevin! You've got it. It does not require switching the DBMS out if you want to stick with an MV DBMS, so the options are broad, especially options for how to step into these tools. MV# is the name of the MV BASIC language and also used to refer to all of the "MV source" you have. Instead of writing in MV, you write in MV# where the MVON# implementation of MV is right there in .NET.

UniBASIC is to the UniData p-machine

as

MV# is to the .NET p-machine with MVON# tools

UniBASIC running in a UniData p-machine is to the UniData DBMS 

as

MV# running in .NET is to SQL Server or an MV DBMS (we started with U2 as options)

I'm definitely looking over your wording again, Kevin. I think you have made some things very clear.  Thanks!  --Dawn

--
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

[Dawn Wolthuis]

Yes. Thanks Glen. The MV code gets transpiled to C# and has a nice means of including any C# in that source MV# (MV BASIC) code if useful when running in .NET.

You guys rock!  --Dawn

[Ross Ferris]

Dawn,

With reference to U2 & D3 using/accessing external databases, this can be done from both products (D3 has a specific Oracle driver & also a generic ODBC connector for "anything" that talks ODBC). I'm aware of people using these facilities to integrate information from external data sources, and also to export MV data into an SQL store for BI type purposes.

I'm not personally familiar with anyone using an SQL database as THE primary data store from their MV application (in much the same way that jBase used to demonstrate this connectivity, but in commercial reality, why introduce an additional external DB licence (OK, mySQL et al are "free") when you have the faster native capability to hand - they might be out there.

Likewise, U2 & D3 provide facilities for you to easily expose & consume web services these days

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

For more options, visit http://groups.google.com/group/mvdbms

[Ross Ferris]

If MV# was a first class CLR citizen this could be more interesting, but I fear the reward/effort calculation provides a number << 1, so I will not hold my breath :-)

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

For more options, visit http://groups.google.com/group/mvdbms

[Dawn Wolthuis]

Well, Ross, I can see why you think that would be preferable, as in the 80's I complained about CICS going through a translator to become COBOL and then COBOL being compiled. However, because I am working with C#, I like that there is both an MV# debugger for the basic language and also a means of working well with C# in a variety of ways. MV# is a toolset, much like many software companies have toolsets within their environments. Either way the result is managed code running in the CLR. It isn't running naked in the O/S like jBASE nor does it use an uncommon p-machine. 

One thing you can get with this approach is full source code in C# for your MV "toolset" that runs in .NET. It's all about MV, it's all C#, it's all .NET and it's all running in the CLR. If you mull this over and can see any benefits to running MV as a toolset where the application runs in the Common Language Runtime in .NET instead of a less common p-machine, I'm interested in hearing that too.

As for the reasons to use SQL Server, there are many, few of which have anything to do with any love lost between me and the SQL language (recognizing that once upon a time a few people called me "the SQL queen" and I do have an acknowledgement from Joe Celko in one of his SQL books). I much prefer the MV data model to 1NF and 3VL. 

SQL Server does MultiValue very fast with high scalability. Simply decoupling your application from your DBMS helps with scalability, of course. With every product there are stories, and this is no different -- applications running a daily process in > 24 hours going down to minutes, for example. SQL Server 2008 R2 is where we no longer had speed on our side in a UniData vs SQL Server battle.

Go Cubs.  --Dawn

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

For more options, visit http://groups.google.com/group/mvdbms

[Tony Gravagno]

Two things got my attention here:
Partners in SA: Would that be XBASIC from where John posted this note?
SystemBuilder: OK, NOW we have something to talk about. I have a use for SB to C# right now.
Emailing now.
T

[Dawn Wolthuis]

Awesome. You can see photos of our partners on the site, by the way, so that should give more clues.  --Dawn

--

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]

Dawn, there seems to be a contradiction. Kevin said this is another MV implementation. You say yes, yes, but then it does not require switching the DBMS out. I think you mean it still communicates with "A" MV DBMS, just not the same one you started on. Or if it does we're back to why would we want to do that when our BASIC code is already running within the MV virtual machine. What does .NET and now a networked connection to slow down data access buy us here?

If this IS an implementation of MV, how is it NOT MVON? And if it IS MVON, why transpile when MVON already runs MVBASIC?

The Uni-Foo is X as MV# is Y also seems contradictory. I'm not following that yet.

Maybe what some of us need is to come back to basics, so to speak. Leave out the marketingspeak with MV# and MVON. Leave out C# which is mostly irrelevant for the target audience though of some value to the fringe nerds (waves hand). Tell us in plain terms what this does that we don't have yet, or why it does what we do better.

Or stated another way, the people who have responded in this thread have literally "been there, done that". We've written parsers and transpilers, converted data, written abstractions over APIs to get systems to communicate. Half the people here could write the product you describe given time, funding, and a belief that it was worthwhile (add enough funding, subtract some belief, and ultimately we don't care if there is a future for it as long as we're paid the right amount). So you come to us trying to explain this in marketing terms and most of the questions you get back are fairly technical. Now, don't take this wrong, but you've referred to the technology as DotNOT, openly acknowledged lack of depth on this topic and others. I'm wondering if we could get our fill of technical information from one of the developers, come to understand the offering, and then with that understanding discuss with you how that can be presented to a general audience - which ultimately I think accomplishes all of your goals.

Thanks.
T


 Dawn Wolthuis wrote:

Yes, yes, perfect, Kevin! You've got it. It does not require switching the DBMS out if you want to stick with an MV DBMS, so the options are broad, especially options for how to step into these tools. MV# is the name of the MV BASIC language and also used to refer to all of the "MV source" you have. Instead of writing in MV, you write in MV# where the MVON# implementation of MV is right there in .NET.

UniBASIC is to the UniData p-machine

as

MV# is to the .NET p-machine with MVON# tools

UniBASIC running in a UniData p-machine is to the UniData DBMS 

as

MV# running in .NET is to SQL Server or an MV DBMS (we started with U2 as options)

I'm definitely looking over your wording again, Kevin. I think you have made some things very clear.  Thanks!  --Dawn

[Tony Gravagno]

 Dawn Wolthuis wrote:

... and I do have an acknowledgement from Joe Celko in one of his SQL books).

"SQL for Smarties: Advanced SQL Programming". :)

[Tony Gravagno]

You got my attention here too, Dawn. I'm hoping you can clarify this with as much certainty as possible.

Dawn Wolthuis wrote:

No, we would not expect you to then maintain the C# code directly. MV# would be the language for the screens written in MV#. C# would be the language for a corresponding mobile app, perhaps

As most folks know, Java is the language of Android, Objective-C for iOS, and C# for Windows mobile devices. But Xamarin, based on Mono, is cross-platform C#, and Microsoft acquired Xamarin not too long ago. The take away is that we get all of the primary mobile platforms now with one language, and depending on the project anywhere from 70% to 95% of the same code driving every target.

SO.... If you're suggesting that we can use a flavor of MVBASIC, transpile to C#, and deploy that to mobile, there's obviously an audience for that, far beyond the MV industry. Now I know there is a ton of magic going on in there with UI handling, communication with APIs, device-specific coding, etc. I'm under no delusion that there is a plug-n-play scenario yet. But some dots are connecting. Google "android BASIC" and you'll see this is already "a thing". With some more dot connecting you may get that "oh I get it, tell me more" response that you want. Dots, for example, like "how do we weave BASIC with .NET assembly integration?" or "can we write both BASIC and C# in a single module (code item) and have the BASIC transpile without affecting the C#?"

Now, if the transpiler leaves the code with ugly platform-specific artifacts, then it's probably not very good for mobile. I'm relying on you to be able to help connect those dots, or maybe to acknowledge that mentioning "mobile" was a step beyond where this product fits at the moment.

Thanks.
T

[Kevin Powick]

On Wednesday, 2 November 2016 21:04:30 UTC-4, Tony Gravagno wrote:

Dawn, there seems to be a contradiction. Kevin said this is another MV implementation. You say yes, yes, but then it does not require switching the DBMS out. I think you mean it still communicates with "A" MV DBMS, just not the same one you started on. Or if it does we're back to why would we want to do that when our BASIC code is already running within the MV virtual machine. What does .NET and now a networked connection to slow down data access buy us here?

Yeah.  I'm confused again. :(

--

Kevin Powick

[Dawn Wolthuis]

Thanks for the questions, Tony. Yes, I'm aware that some in this group are precisely the folks who could have written this, just as many could have originally written UniData, for example. This software has matured over several years and is LIVE at sites. I recall Philippe Kahn saying "Delivery is a feature" and that is a feature that MVON# tools have. We know what it took to get to this point. What I'm hoping is that people build on it as it can help raise the value of software applications and software companies here that do not want to write their own implementation of MV running in .NET from scratch (or worse yet, attempt to rewrite their entire app from scratch -- oh, the humanity!)

I'm working on hitting the nail on the head so that I'm telling you more precisely what it is. I'm gathering info to answer other questions too, and, yes, there are some much more knowledgeable people than I with whom I can field questions. Anyone interested can request a demo with techies present so you can have better answers than I can give, and we can make that happen.

I'll take a shot at your first question. With your application running in .NET, whether you are using an MV DBMS or SQL Server, this includes a decoupling of your application from your DBMS. There are DBMS connectors for SQL DBMS products and for MV DBMS products once the application is running in .NET. So, yes, you can continue to have your data in your current production DBMS and/or you can have it in SQL Server, specifying different files in different places if desired.

Quite plainly (I hope), the primary advantage I see in leaving the data in an MV DBMS when the application is running in .NET is to get the gains on the application side when there are constraints or designs requiring that you leave the data in the MV DBMS, perhaps as a tactic to stage in changes. In practice, I doubt many will choose to do that for very long. Use a connector to UniVerse, for example, then switch it over to use the SQL connector when you see a reason to do so, whether hard costs or features. Your ROI could be within a year of going live, or your end-users could be satisfied with some feature or another even sooner than that.

When people have evaluated the options, so far they see enough advantages in persisting their data in SQL Server (obviously ONgroup has been doing that for a long time and this is an implementation written in C# and taking advantage of more SQL Server features). We anticipate others might want to use Oracle, where we also have plenty of experience (or PostgreSQL or MySQL...), but with the application running in Microsoft .NET, Microsoft SQL Server is an obvious choice. 

The read-write SQL Server views show the metadata/data as a SQL Server user wants it and in MV# (MV BASIC and query languages) it is MV data and dicts, just as expected. Groovy stuff, I gotta say.

Too good to be true? So far from what I have seen and touched, the business case for it just oozes out, so I am trying to paint that in words, and I'm appreciative of the help here. 

There are brilliant developers backing it and we think our team will grow virtually and horizontally through partnering with third parties who do the services for organizations choosing to go this route. Wanna see Netbuilder (SB+ emulator)? Even sexier is your Netbuilder app with a browser user interface -- it's in the labs now.

Let me know if you would like to chat further and bring in the smarties. Until then, you are stuck with the likes of me attempting to say it correctly and well. Thanks for your help and your patience.  --Dawn

--

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

[Kevin Powick]

On Tuesday, 1 November 2016 14:35:06 UTC-4, Dawn Wolthuis wrote:

I see it as a progression of MultiValue. It was a proprietary operating system, typically now a proprietary p-machine on common operating systems, with a natural progression to tools that now run with a common runtime environment. .NET and the Common Language Runtime fit the bill, turning MV into .NET managed code.

You mention the advantage of MV# over proprietary p-machines because MV# is transpiled to C# for the CLR.  Ok, but isn't your transpiler proprietary? Unless it's open source, I see no difference between a proprietary p-machine and proprietary transpiler.

Or is the idea/advange that once written in MV#, the resulting "system" can use any MVDBMS as the datastore, or even SQL Server?

--
Kevin Powick  

[Dawn Wolthuis]

I'm dabbling with ASP.NET CORE 1.0 and doing nothing more than watching videos with Xamarin development. With the Xamarin CLR on mobile devices and the ability to include C# in MV BASIC, i can imagine someone going the route of writing their mobile app that way. That is not what i was thinking when I wrote that, however. I was thinking that with the application running in .NET with SQL server, I might add on a mobile module with Xamarin. All the "I-desc subroutines" work in SQL Server so you can reuse business logic that way and maintain the same DBMS. I would yield to someone more clever than I to suggest how else we might do that given this toolset. Does this help answer that question?  --Dawn

--

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

[Dawn Wolthuis]

Good questions, Kevin. I think that as I pull together answers for all of the questions to date, these will get answered, but quickly here --

Yes, in either situation there is something proprietary. In one case, you are using .NET and in the other case a less common run machine. If you opt to get MVON# with all of the source code for the tools, that changes the risk assessment too. i see it more like the progression from Prime Information to UniData. It just made sense at some point in time to run in a common O/S and for some software companies and end-customers, it just makes sense now to run applications in the common language runtime. 

Does that analogy resonate with you?

The use of SQL Server and the related features we have in that regard are a big reason that some sites would benefit from using it. We can do that with MVON on its own or OpenQM on the front-end too, however, using MVON for SQL Server or Oracle persistence. There are additional features because we are in .NET, but I'll try to get more precision with that and get back.

Does this help answer your questions? Definitely feel free to follow-up. I'm trying to find the right words and phrasing to make it clear and crisp.

Thanks. --Dawn

--

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

[Kevin Powick]

On Wednesday, 2 November 2016 22:50:56 UTC-4, Dawn Wolthuis wrote:

Yes, in either situation there is something proprietary. In one case, you are using .NET and in the other case a less common run machine.

But your transpiler is even less common than both of those.  And how am I actually "using" .Net?  Yes my mvBasic code is transpiled to C# which ultimately runs under the CLR, but what features of the .Net framework are made available to me as a developer?

I would also like to hear more about the SQL server option in terms of useful data access outside of MV#, because the cost advantage of dropping traditional MV user licenses will likely be nullified by the cost of SQL Server licensing.

 

If you opt to get MVON# with all of the source code for the tools, that changes the risk assessment too.

Is MVON# an extra purchase over MV#?  Is it required to get source code?  What is the extra cost?

 

i see it more like the progression from Prime Information to UniData. It just made sense at some point in time to run in a common O/S and for some software companies and end-customers, it just makes sense now to run applications in the common language runtime. 

Why does running in the CLR make sense?  Why is it important and advantageous with respect to the MV# offering?  Most people only care that an application "runs on Windows".

 

Does that analogy resonate with you?

Sorry, but I'm still struggling to see what major advantages one gets with MV# (+ MVON# ?)  

--

Kevin Powick

[Dawn Wolthuis]

That's OK if he doesn't have enough relevance to your projects, Kevin.

I'll try to get the chief architect of the software to answer some of the questions too.

Regarding names MVON# is the product suite and MV# is "the MV languages." If I have to distinguish, then MV# can be thought of as the MV BASIC implementation and MV# Query as the query language, but I will typically use "MV#" for all MV source code including paragraphs, procs, voc entries, dicts.

Both of the following work for me

MV# is to MVON#

as

UniBASIC is to UniQuery

MV# is to .NET

as

MV is to UniVerse

The latter form might not be of much interest to people who are heads down in code as it is a big brush stroke and lacks some precision about what aspects of UniVerse are comparable to .NET, for example. Recognize that it would not be accurate to call it an MVDBMS. It is not a DBMS at all. SQL Server (or DBMS of choice) is the DBMS. 

--Dawn

--

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

[geneb]

On Thu, 3 Nov 2016, Kevin Powick wrote:

> But your transpiler is even less common than both of those. And how am I
> actually "using" .Net? Yes my mvBasic code is transpiled to C# which
> ultimately runs under the CLR, but what features of the .Net framework are
> made available to me as a developer?
>

It would almost make more sense if it skipped the C# step entirely.

> I would also like to hear more about the SQL server option in terms of
> useful data access outside of MV#, because the cost advantage of dropping
> traditional MV user licenses will likely be nullified by the cost of SQL
> Server licensing.
>

I wonder if the back end DB could be MariaDB or Postgres...

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_!

[Martin Phillips]

Hi Dawn,

 

I have so far stayed out of this conversation as a database vendor but there are some questions puzzling me that I haven’t seen anyone else ask.

 

Ok, so this product converts Basic to C# but which of the multivalue Basic variants is it? If it is only the core features common to all multivalue products, this seems to prevent use of the proprietary features of some products such as QM’s data collections and OO programming or the unique features found in U2 or D3. Even simple things like LOCATE have different semantics across products.

 

Also, if I use for example Oracle as the underlying data store how will indices work? Oracle itself would have no concept of indexing a multivalued field so indices must have to be managed separately in some way. But if that is done, any update to the Oracle data from outside this environment would not be reflected in the index. And having got an index, where is the query processor in this system? And dictionaries? And encryption? And…..

 

 

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200

--

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

[Bill Crowell]

I think we should call this product "The Son of jBASE."

I don't see the value added by the "transpiler." Tony has pointed out the vastly different ways that coding is done in BASIC vs. C and C-derivatives.

Back in the day, we were being told that going to jBASE was the answer to performance issues - that our code would be converted into "PURE C" - whatever that means and then compiled into machine-specific byte code for execution. The universe changed and processors got faster and we got better implementations such as UV and later QM.

What is the value statement for this product? If it is to take an existing pile of BASIC and make a one-time migration to C# to get rid of the existing MV application so that non-BASIC programmers would ostensibly maintain it, that's one thing. If it's intended to be a replacement for existing systems such as QM, I fail to see the point.

The PCODE interpreter in QM is blazingly fast and the same BASIC PCODE (within limits) runs across platforms.  I run the same compiled PCODE on QM on Linux and Mac and I've run QM on a Windows server at S&B. The QM and PCODE interpreter binaries are about 1MB of executable. The .NET 3.5 runtime redistributable is 197MB.

I'd like to see what the official value statement is.

Bill Crowell

Pavuk Systems

Pearland, Texas

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

Hi Martin,

My name is Grant Hart and I am the architect of the MVON# product suite. Dawn has asked me to assist with some of the more technically focused questions

On Thursday, 3 November 2016 16:21:48 UTC+2, Martin Phillips wrote:

Hi Dawn,

 

I have so far stayed out of this conversation as a database vendor but there are some questions puzzling me that I haven’t seen anyone else ask.

 

Ok, so this product converts Basic to C# but which of the multivalue Basic variants is it? If it is only the core features common to all multivalue products, this seems to prevent use of the proprietary features of some products such as QM’s data collections and OO programming or the unique features found in U2 or D3. Even simple things like LOCATE have different semantics across products.

The product has switches similar to Universe that dictate the flavor of the environment. It support Universe/Unidata and Pick style environments. It supports A,S ,D and I type dictionaries . These can also be mided within the same account. Pick style A and F correlatives as well as Prime style Itypes

 

Also, if I use for example Oracle as the underlying data store how will indices work? Oracle itself would have no concept of indexing a multivalued field so indices must have to be managed separately in some way. But if that is done, any update to the Oracle data from outside this environment would not be reflected in the index. And having got an index, where is the query processor in this system? And dictionaries? And encryption? And…..

 

What we have done with Sql Server is build a normalization  engine and deploy that engine within Sql Server. The data is physically stored as a key value pair but presented to the user via the normalization engine as 1NF environment. Index's are created by persisting the field to index (itypes included) and creating sql index's. Whenever the table is updated either via MVON# or via sql statements, Sql server manages the update of the index's.

The query processor can either be standard SQL (SSMS) or MVON# (Access/Retrieve/Recall)

Please let me know if you require any further info

Cheers

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

Grant Hart here, I am the architect of the MVON# product suite.

I posted a reply to Kevin where I showed how you can mix both C# and BASIC code within the same program. Xamarin is an awesome product and we use it extensively for some of our other developments. With relatively small changes to the compiler, we can target the Xamarin libraries and apposed to the Microsoft/Mono libraries.

There is of course the UI bits between the various targets from Xamarin but core business logic could be MV#.

Excellent idea.

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

Hi Kevin,

Allow me to introduce myself, my name is Grant Hart and I am the architect of the MVON# product quite. Dawn has asked me to assist with some of the technical questions around MV#. With regards to MV# Compiler/Transpiler and what value does it give to MV developer.

When designing the compiler we wanted to create and environment where MV BASIC and C# could co reside within the same program. Allowing one to mix and match C# and BASIC depending on the developers requirements. Take this code snippet for example

0001 Program Test

0002      Url = "http://www.myurl.com/post.php"

0003      HtmlResult=""

0004      [USING]

0005      System.Net

0006      [/USING]

0007      [CSHARP]

0008         string myParameters = "param1=value1&param2=value2&param3=value3";

0009         using (WebClient wc = new WebClient())

0010         {

0011             wc.Headers[HttpRequestHeader.ContentType] = "application/x-www-form-urlencoded";

0012             HtmlResult = wc.UploadString((string)Url, myParameters);

0013         }

0014      [/CSHARP]

0015      NoOfDivs = Count(HtmlResult,"<div>")

0016      Crt @(10,10):"The html document contains ":NoOfDivs:" <div> elements"

0017 End

A developer can include C# code anywhere within his basic program . You can also call any library method giving the developer access to any CLR package.

Because the resultant code is all C#, there is no marshaling of objects between 2 different environments. Variables defined in the BASIC portion of the code can freely be used in the C# portion and vica verse.

With regards to SQL licensing vs MV licensing I can relate the cost advantages by using one of our sites as an example. The customer had a 160 user U2 license on an HP server. The maintenance cost on those licenses  for U2 was 250K per annum (South African rands which is about 18K usd). There SQL license (a new purchase) was 12K USD. Had they purchased a new 160 user U2 license that would have been about 60K USD.

If you have any more "techie" questions, I will gladly assist

Cheers

[Dawn Wolthuis]

Thanks Bill. Maybe "daughter of MV" or "granddaughter of PICK"? 

I have some ppt slides and other value statements from many sources coming out my ears and am working to fashion those into something more coherent than what I've posted to date -- a list, perhaps. Let's just say that working with .NET with SQL Server for persistence is multi-valued. I'll let you know when I have shaped it up a bit, likely this weekend.

smiles. --Dawn

--
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

[Glen Batchelor]

   It's a tool in search of a dying developer market. You're hitting the wrong audience here Dawn. It's a great idea and it works but you aren't going to convert existing shops over to it unless they are looking for an out for their outdated Pick solution. Then, what point is it to keep using dataBASIC once your logic is available in a more "mainstream" language and run-time environment? A transpiler is a double-edged sword unless you offer solutions on both sides of the fallout. In this case, no one would be moving from C# to say UVBASIC so you're effectively reducing your source market inherently with such a technology.

[Tony Gravagno]

I'm getting the picture as crafted by everyone here.

MV# is not just BASIC, it's BASIC plus proc, query, etc.
It seems to me MVON# is MV# plus the libraries like the DBMS interfaces and whatever else they do/will bundle with it.

Their flavour of BASIC includes whatever they have chosen to support. They're going down the same path as QM and Caché, trying to be as compatible as possible to attract the widest audience. I suspect that with the MVON connection, which is no newcomer to this game, that their BASIC flavour is adequate to support most common code.

They certainly would not support QM objects, for better or worse. But this is where we get to the C# mix and my follow-up to Grant.
I _really_ like the mix of languages here - it's exactly what I was hoping to see. It's sort of like PHP mixed with HTML, or C# or JavaScript in an ASP.NET page. The mix of variables is critical and something that Dawn wasn't able to describe. I would be interested in how BASIC would refer to object methods and properties, perhaps generic collections, etc. And how is data typing handled where C# provides a DateTime(), for example, and BASIC treats it as a variant. This is what the QM OO BASIC functionality emulates within BASIC constructs. This MV# implementation must be much richer. This is also where BASIC developers need to look carefully for where they need to re-write some code if they want to take advantage of the environment - you won't be parsing date strings anymore if you are working with DateTime objects.

Grant and Dawn, I suggest that since you're talking to technicians here, people at your tier, that you provide more code samples which demonstrate the fluidity between components. This would help to answer the "what do I get with the CLR integration?

Something else of note: The example below shows CRT @(), which means we aren't sacrificing the Character UI (CUI). That's huge and this also wasn't previously communicated. So we Don't need to strip initial code of the I/O. That removes yet another huge barrier to adoption.

OK, how is ONgroup going to get this into the hands of developers? (Like mine, right now?) I really hope you don't consider developers to be the revenue tier. I for one am burned out on expensive tools, making a huge purchase in the hope that I can sell a solution to end-users. No, make the tools available and developers will pave the path to the paying end-users. Witness how Microsoft has gone down this path as well as countless other tools.

Speaking of Microsoft, there's another dynamic mentioned but not emphasized: Since .NET is now available over Linux and Mac, this platform can or will provide the same scope. .NET is no longer just Windows. And I've seen a reference or two to Mono, that's getting to be old school - this is now ".NET Core". While we've always had the ability to use MV at the OS command-line, most developers don't know how or care. But consider how macros, PowerTools, BASH scripts, and other command-line coding options are hugely popular these days. If we have the ability to code in BASIC+C# ( =MV#) as a sort of scripting language for these OS's, Lots of doors will open.

Oh, and on mobile, I'm definitely seeing a Xamarin connection there, which means BASIC+C# apps for Android, iOS, and (as if anyone cares) Windows mobile.

Regards,
T

[Glen Batchelor]

 It's great geeky goodness, yes, but I just don't see the market Tony. Hopefully I'll be proven wrong.

--

[Wols Lists]

On 03/11/16 02:36, Kevin Powick wrote:
> You mention the advantage of MV# over proprietary p-machines because MV#
> is transpiled to C# for the CLR. Ok, but isn't your transpiler
> proprietary? Unless it's open source, I see no difference between a
> proprietary p-machine and proprietary transpiler.

Isn't # a proprietary p-machine too? (And no, unless you actively make
sure it works with mono too, then you can't claim to be Free or Open).

This is shades of the Unix/NT wars where MS called Unix "proprietary",
carefully skating over the fact that exactly the same could be said for
NT ...

Cheers,
Wol

[Dawn Wolthuis]

Yes, agreed. The word I have been using is "common," as in "common language runtime."  .NET is a proprietary run-time of sorts, even if .NET CORE is open source. Microsoft has plenty of proprietary pieces, including Windows. In spite of having a license, I've been trying to work with the free and open source pieces so that whatever I learn on the .NET front is available freely for all.

If you were using a Power95 p-machine, let's say, and then you start using the open source (tools and runtime) .NET CORE as the p-machine, would you think of that as going from one proprietary runtime to another? I'm OK with that use of the terms, but at the very least you starting with something uncommon with Power95 and then with .NET you are using a common strategy with the common runtime. "Common" has some benefits, and there are pros and cons to any approach.

I'm not religious about this, just practical. For practical and theoretical reasons, I like the MultiValue data model and the industry is heading that way, or at least broadening to include it. We are in a good place to dovetail with "the industry" in new ways. SQL Server started as Ingres with the QUEL language. They are practical too. We can "teach it" (with our tools) MultiValue and you get some of the best of both. 

--Dawn

--
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]

Respected colleagues, I'm understanding this in large part from the code sample provided by Grant, and I'm getting stoked.

A solution for a dying market? Perhaps. But this seems better than any transitional tool I've seen yet. Who's dying? The BASIC-only developers. They don't want or need a solution - nothing is going to help these folks. End-users who Are looking to a future aren't dying. They are either migrating or (my recommendation) integrating, and this certainly should be considered by them.

This can help to keep a company using MV when all of their data is already in a platform, it works, they like it, but they want to hedge their bets with mainstream tech. Pure BASIC developers should look at this as an opportunity for them to help end-users to transition - as their skills will continue to be required until their end-user decides to completely transition out. So what's better, being phased out now or in 5-10 years?

(Relatively) seamless blending of BASIC and C# is better than the common topology where we have BASIC here and .NET there and never the twain shall meet. With all of the MV variants, we can call from .NET (Java, PHP, etc) into BASIC and retrieve results, whether via some class library, web services, or by executing a command line and parsing the results. Most of the MV variants have mechanisms for calling down to DLLs, though I can count on one hand the developers I know who actually use or even know about such things. I would think that most MV developers (especially those who appreciate QM OOBASIC) would recognize the elegance of keeping everything in the same tier. Brian Leach's mvScript facilitates BASIC code in web pages in the same style as JavaScript, ASP.NET, ColdFusion, and Coyote. Forget the concept of transpiling for a moment and consider that BASIC and C# in the same module is not unusual, not inelegant, and as useful as all of these other options - but more accessible for the typical MV developer.

With this # offering, existing BASIC code and the runtime can be ported outside of the VME. That's a big deal on its own, as any jBase user will tell you. It's also Very valuable to a number of companies that call me for such a solution.

This is a way of getting the BASIC rules closer to where they are required. All of us who do this are familiar with the grief of architecture where the UI or middle-tier needs data and we need to go into the DBMS to process rules and then perhaps page-back the data. There are issues with timeouts, volume of data, disconnection, etc. We don't need to put ALL rules into this # tier, for some projects where the existing MVDBMS is still in use I think a mix would be appropriate, because you often don't want to pull a huge amount of data from the DBMS across a wire in order to process it.

Now if some or all of your data is in SQL Server, I sure don't want to have to code in T-SQL just to keep my rules close to the metal. For this reason we can (within limits) put C# code into Stored Procedures (procs, the other kind). And with this # option that means we should be able to use BASIC>C# in there. For anyone who says "I use an RDBMS now and I really miss being able to use BASIC", this responds to that.

For Oracle or other platforms, meh, we can't put the C# into the procs but we can now code with BASIC, combined with C# as we wish, and use common drivers to get into other data sources. For anyone who uses Java with those drivers and PHP with other drivers and C# with yet somethig else, I think it becomes pretty clear that there are advantages for coding with the familiar BASIC.

What about the future? Do you keep running this BASIC>C# transpiler? Do you dump the BASIC and use the ugly C#? (Is it really ugly?) I'm thinking that after the initial transition a company can decide where it wants to go. There's no reason not to continue with some BASIC plus some C# in the same modules. If the company wants to transition away, they can copy some of the transpiled C# back to their source and clean it up, replacing the related BASIC code, and ultimately going entirely C#.

Dawn mentioned SB+ conversion. That right there is a holy grail for which there are no other good solutions. I've heard the term SB-killer a number of times, no product actually delivers. I'm very interested to see just how much SB+ this product actually converts and what it looks like afterward. Anyone who has used System Builder would recognize the dynamics here - some sites are happy with their SB but many are not, and often opt for a complete replacement of MV as their only real solution.

The ability (planned?) to use this in Linux opens doors for calling BASIC/C# rules from Apache (or now ASP.NET) more elegantly than we have been able to in the past.

The link between this and mobile via Xamarin, on its own, should be enticing to some developers and end-users. How many companies want a mobile app or just some mobile integration, but they're not sure how to go about it? Thinking of hiring a Java dev? Concerned about supporting only iOS or only Android? No clue where to start? How about starting with MVBASIC? I did write a prototype utility a few years ago to generate Android apps purely from MVBASIC. I gave it up due to industry apathy (or my own?). But frankly this # option would be Much better for that kind of work compared to what I was doing.

(From the "coulda fooled me" department) I'm not slobbering over this product yet, haven't even seen it. But I am finally connecting dots and I like the outline that' forming. I think the only people who will not like it are those who sell competing products. My advice to them:
- Partner and collaborate. Don't try to compete with this offering. Embrace it and port your tools for use with it.
- Facilitate integration to prevent migration.
- Look at it as a source of value-add to your base, not the death of your life's work.
- And try to survive by having a better DBMS rather than just forcing people to lock-in to your syntax. If you can't do that then you've been surviving on maintenance agreements and not having a better product, so maybe it's time to make way for people who actually innovate.

Aside from that group there will be those who don't see the value for their work. That's fine, there's no such thing as "one size fits all". I do see that there is a much larger audience for this than we've thought as we dance with this thread. As a businessman, I like large audiences. As a technician, I'm turned on by the possibilities. I just hope the reality isn't a huge letdown - and that I haven't completely misunderstood what this thing is. In which case .... Nevermind. :)

Regards,
T

[Dawn Wolthuis]

Hey thanks, Tony! Yes, I think that in spite of whatever I wrote, you have figured it out. Great. We can try to trace that path so we can help make that an easier road for others, because I can see that YOU GET IT! 

--Dawn

--

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

[Kevin Powick]

The code snippet was great.  Would like to see more of those.

Does this model mean that each and every workstation is running the .Net code independently of a server and the datastore there?  If so, then we have to consider things like workstation horsepower, data transfer across networks for local/workstation processing, and deployment of current codebase version across all workstations.

You could say this is no different than keeping a regular Windows application up-to-date for all users, but in the MV world, we don't worry about that.  There is only the current version of the code, running on the server.  Changes there, are "instantly" available to all users.

--

Kevin Powick

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

Hi Kevin

The users connect to a server just like all other MV systems. The application runs on the server and there is no need for the .Net runtime on the client. The MVON# suite comes with a Telnet client similar to Wintegrate and also a .net library equivalent to Uniobjects

Hope this helps

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

Hi Tony

Thanks for the positive feedback. Working off my phone right now (10:45 pm) so am unable to provide some more details and examples. I will send you some more code details and the info on our sql integration in morning

Cheers

[Kevin Powick]

Hi Grant,

On Thursday, 3 November 2016 16:23:44 UTC-4, grant...@prosol.co.za wrote:

Hi Kevin

The users connect to a server just like all other MV systems. The application runs on the server and there is no need for the .Net runtime on the client. The MVON# suite comes with a Telnet client similar to Wintegrate and also a .net library equivalent to Uniobjects

It does help.. Thanks.  I think it's an important distinction. 

--

Kevin Powick

[Tony Gravagno]

This discussion was transpiled over into the other thread which had nothing to do with MV or this new offering. I HIGHLY suggest you bring it back home.

The whole discussion about CLR, C#, .NET, open source, proprietary etc is SUCH a turn off to me as someone who uses this stuff every day. There's way too much nit picking on terminology and nuances that mean absolutely nothing in the real world. It's like stating "it's raining" and then going into a discussion about the quality of air, atomic weights of nuclear particles in water molecules, and a digression into how many drops fit into a barrel.

PLEASE STOP.

It's enough to say the MV# tier is transpiled to C#. DONE.
Anyone with a clue knows what that means. Anyone who does not (after .NET being around for over 15 years) is not the target audience.
When it comes to cross-platform, just say there are options available via .NET Core. DONE. This is all new, again anyone with a clue will recognize Mono and .NET Core and the nuances. You Don't need to get into it in a product description. It completely distracts from the product itself. Raining Data made a huge mistake when first offering PDP.NET. They took on the responsibility for trying to educate people as to what .NET is. That didn't get them new sales and did help to kill the product.

Now focus on what the MV# tier is:
- Like ASP.NET, PHP, and Java/JavaScript via Rhino and now Nashorn, it facilitates ployglot development.
- What's that? ASP.NET transpiles XML, HTML, C#, and/or JavaScript into a single executable module. PHP parses PHP mixed with HTML into a single final document. Nashorn facilates execution of JavaScript within Java. (Please ignore subtleties of compilation, parsing, scripting, etc - that's my point - get out from the ground level and move up over the trees.)
- And MV# allows for MVBASIC and C# to be used in the same program item, ultimately compiled into C#, and from there using the resources of the .NET Framework to integrate with everything available to that platform.

DONE. Go any further with that and it turns into a rat hole, as we've seen with this entire discussion.

I don't know how Proc and TCL, macros, ITYPES, triggers, indexes, and other details fit there. THAT is where the discussion should go.

HTH
T

[Kevin Powick]

On Monday, 7 November 2016 14:10:35 UTC-5, Tony Gravagno wrote:

This discussion was transpiled over into the other thread which had nothing to do with MV or this new offering. I HIGHLY suggest you bring it back home.

The whole discussion about CLR, C#, .NET, open source, proprietary etc is SUCH a turn off to me as someone who uses this stuff every day.

There are a lot of people that don't use this stuff every day, so may find the distinctions rather important.

There's way too much nit picking on terminology and nuances that mean absolutely nothing in the real world.

The nature of technology requires precise terminology.  Ideas are expressed via words/terminology.  Use the wrong ones, and you get the wrong ideas.

 

PLEASE STOP.

 

Why do you care about a debate in a separate thread that, you believe, has nothing to do with this one?  If you don't like the other thread there is no reason to read it.  Frankly, it's a little bizarre that you would jump into this "unrelated" thread to tell people to stop discussing what they want to discuss in another thread.

[condescension snipped]

Wow....  Just wow.

--

Kevin Powick

[Peter McMurray]

I am definitely interested in the detail and yes I did treat the other thread as a pleasant distraction. One can enjoy a little lighthearted banter even if the instigator has a well known bias :-)

dotNET has suffered with some issues at Microsoft in recent years despite being the best idea they ever had. I for one would like to know where things like WPF are headed now that Windows Forms are apparently deprecated. The obvious people to answer these issues are the people who have created MVSharp.

The simple fact is that most Pick people have not embraced what is undoubtedly the dominant force on the desktop and would not know that it runs across multiple platforms. As a current thread re 7.4 goes "if it works don't fix it" is a far more common attitude.

I particularly want to know what LOB (that is Line of Business in Microsoft speak) application developers are using in this new endeavour. XAML on WPF seems to be great as a UI design interface but am I going to find after investing a lot of time and money that it does not easily fit my event driven data entry design?

. I have always felt that the only access to MV database should be the Basic provided and that external UIs should go through CRUD basic routines. However I can see that boxing the actual database as is apparently done in MVSharp is actually simpler than one would think when one looks at FSI which is great.

I am bewildered as to why Rocket have introduced Python to MV as I have always thought, possibly wrongly, that it is a plaything of people who like fooling around with Unix command line programming.

Dawn is putting together suggestions. Please keep on doing so.

[Tony Gravagno]

Well, this is exactly the puddle of word soup that I was talking about, with nothing actually on-topic for this thread, and nothing that a little googling couldn't clarify for the curious.
Meh, I'll back off. Have fun.
T

[Peter McMurray]

I am particularly interested in answers regarding the UI. As anyone who has used Accuterm and the like who Googles the topic knows there is considerable confusion as to the preferred Microsoft product. Can WPF provide the event driven field entry interaction that I prefer or is it a more page oriented product. What product do people use now that Windows Forms has slid down the list?

[geneb]

WPF is basically the same event-driven stuff but written in XAML files.
As far as I know, Windows Forms has in no way been "deprecated".

If you buy a copy of the 6th edition of Programming Windows by Charles
Petzold, you'll get a good review of how WPF works - it's currently the
"blessed child" even though the designer is crap. :)

The layout editor for WPF (as of Visual Studio 2015) still isn't as good
as Windows Forms is.

[Peter McMurray]

Thanks Gene

My research had revealed a lot of confusion - see Wikipedia on Windows Forms or http://www.markheath.net/post/is-windows-forms-dead-yet - so I was hoping for sound input from actual users not a TG rant.

In reading about C# and XAML in WPF I found several saying that it might be easier to just do the lot at the C# level. However I can now see it is a bit like the D3 7.4 argument - use what you are used to even though it is out of date.

It appears that Windows Forms cannot translate to the wider platforms that Xamarin, Mono etc. are targeting because of low level calls so it is now in maintenance mode.

As my interface has been standardised for 40 years I believe that I can easily pull it out to XAML and the MVSharp route may be a quick and easy way of getting the 1000 plus programs in my standard application suite across whilst I learn a new way of doing what comes naturally.

[Dawn Wolthuis]

Peter -- You might look at the Microsoft application dev approach that looks a lot like Angular -- ASP.NET CORE 1.0. This follows after ASP.NET MVC and is open source. I did something shy of a POC simply to get hands-on and take a look at the way they do routing, views, controllers, etc. 

Take the same-ish approach with Xamarin for mobile, as I understand it (only head knowledge, no hands on in that case).

--Dawn

--

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

[geneb]

On Thu, 10 Nov 2016, Peter McMurray wrote:

>
>
> Thanks Gene
>>
>> My research had revealed a lot of confusion - see Wikipedia on Windows
> Forms or http://www.markheath.net/post/is-windows-forms-dead-yet - so I was
> hoping for sound input from actual users not a TG rant.
> In reading about C# and XAML in WPF I found several saying that it might be
> easier to just do the lot at the C# level. However I can now see it is a
> bit like the D3 7.4 argument - use what you are used to even though it is
> out of date.
> It appears that Windows Forms cannot translate to the wider platforms that
> Xamarin, Mono etc. are targeting because of low level calls so it is now in
> maintenance mode.

The good news is that Xamarin is now free and can be used with the
community version of Visual Studio - you can hit multiple targets from
the one IDE. It's very nice. (You might want to look into Visual Studio
Code as well, but it's more of an uber-editor than a RAD IDE like Visual
Studio.) I'm hoping that the WPF layout editor is going to get some help
in the next version of Visual Studio. :)

> As my interface has been standardised for 40 years I believe that I can
> easily pull it out to XAML and the MVSharp route may be a quick and easy
> way of getting the 1000 plus programs in my standard application suite
> across whilst I learn a new way of doing what comes naturally.

I'd recommend buying Mr. Petzold's(sp?) book. I've got every edition he's
written and they're all top notch.

I'd also recommend that you get a copy of C# 6.0 in a Nutshell from
O'Reilly. The pocket ref is a good pick(ha!) too, especially if you take
it down to your local Staples/Office Depot, have the binding sheared off
and then coil-bound. I've done this with all the various pocket refs I've
purchased from O'Reilly. I just wish they'd offer spiral binding so I
could skip the extra step. :)

[Wols Lists]

On 08/11/16 20:41, Peter McMurray wrote:
>
> I am definitely interested in the detail and yes I did treat the other
> thread as a pleasant distraction. One can enjoy a little lighthearted
> banter even if the instigator has a well known bias :-)

Not to go even further off-topic :-) but at least one of the problems
with American Politics is that it is getting too easy for people to live
in an echo-chamber bubble where all they hear is people agreeing with
them. So everybody else must be wrong ...

I try to get to know my fellow posters, get a feel for their opinions,
and try to understand *WHY* they think the way they do. That doesn't
always stop me thinking they're wrong :-) but it reminds me that not all
people think the same way I do, and they have sound reasons for doing so.

Cheers,
Wol

[Glen Batchelor]

"sound" is a relative term :D   Just because the psychopath thinks he's helping doesn't mean that he is.

*popcorn*

[Peter McMurray]

Thanks Gene and Dawn.The Petzold reference has blown me away the first hit was his free book CODE, just the way I like to see things, if only somebody had taught like that, Morse would not have been such an enigma in cubs I look forward to getting his Microsoft tomes. :-)

Regarding the plethora of books he has written are you referring to the Xamarin one. I had only found the charge version of Xamarin and shall look for the free studio extension.

The trick with the O'Reilly books I have never come across and shall check for availability in Australia, UTAS printers will be a likely start. I wore out copies of Jon Sisk's Pick Pocket book

[Peter McMurray]

Gene thanks again for the Petzold reference. I have just watched a presentation on XMAL at the Xamarin conference, he answered practically all my general questions in the first few seconds.

He then put my mind to rest about code-behind that seems to cause C# programmers so much angst. I would never have found him amongst all the postings without your guide.

https://youtu.be/H6UOrSyhTEE. 

Also thanks to Dawn I now have to work out the reasons for ASP core versus standard which tosses up questions about MVVM versus MVC. 

[geneb]

On Fri, 11 Nov 2016, Peter McMurray wrote:

>
>>
>> Gene thanks again for the Petzold reference. I have just watched a
>> presentation on XMAL at the Xamarin conference, he answered practically all
>> my general questions in the first few seconds.
>>
> He then put my mind to rest about code-behind that seems to cause C#
> programmers so much angst. I would never have found him amongst all the
> postings without your guide.
> https://youtu.be/H6UOrSyhTEE.

Thanks for the video link!

[Peter McMurray]

I realised long ago that nobody is an island and that many fear to ask questions in case they appear silly. If I am confused so are others, that is why we have discussion groups.

The one thing that this thread has made abundantly clear to me is that many developers worldwide do not realise that Windows 10 ,NET framework is a completely new product reprogrammed from the ground up in managed code.

The components are open source available on GitHUb.

All APIs are available across all platforms in all the supported languages. That is the same programs can be run on Android, Ios and Windows Phones, Desktops ,Xbox and Surface Hubs. 

The Microsoft preferred tools are C# and XAML with MVVM but you can use the tool of your choice. 

Visual Studio 2015 is a Universal Application Development environment that MV# can drop us into up and running from day one.

So my 1000 program application can suddenly add an Android phone app for order delivery just by writing a small app and using my current complex pricing and database update programs. No special calls required for different flavours of Pick that may change next week. For a quick taste https://www.youtube.com/watch?v=mGv-F-_hfEI 

[Dawn Wolthuis]

Yes, MV# provides a way to head toward industry best practices, toward Microsoft development approaches that fit right in handily with the industry, toward many free/open source Microsoft products (SQL Server being an exception unless you can make SQL Server Express work), and toward a course of least resistance for reporting, BI, and techology integration across the board.

I have one different impression regarding XAML in that I think XAML is not (yet) in the new development approaches with ASP.NET CORE 1.0. In addition to .NET CORE (Windows), both Xamarin (mobile) and Mono (linux) are run-time platforms for deployment of "the new stuff." I'm tinkering without XAML by using Views, much like Angular views. They use Razor syntax https://www.asp.net/web-pages/overview/getting-started/introducing-razor-syntax-c

I don't know if XAML will be moving forward into the free frameworks or whether they will just try to keep the installed base happy enough to move forward the non-free XAML approach too. I'm still new to .NET, so if anyone has a correction, I'm all ears. 

In any case, MV# gets me right where the action is without sacrificing a terrific "NoSQL" (non-first normal form, boolean logic) data model and corresponding languages for anything we want to do that way. Don't think that you have to rewrite what you have -- you get to add to it for mobile etc in the same way a business starting out today would do it.  --Dawn 

[Peter McMurray]

Hi Dawn

I believe it is the Core and MVC that is the issue not XAML and MVVM which you will find everywhere in the standard .NET.and XAMARIN offerings.

Watch today for Visual Studio on Apple hardware.

• "System.Xaml. When creating UWP applications, developers will use the WinRT XAML APIs. Hence, .NET Core currently doesn’t include the managed XAML framework, which includes the ability to parse XAML documents and instantiate the described object graph."