MV and language bindings

[Tony Gravagno]

Does anyone here ever think "if only my system supported languageX, it would be easy to find developers"? Or "I wish I could write this in languageX"?

Do you want to code in Java and/or JavaScript (via Node, Nashorn, etc) to access your database from "outside"? In other words, write a script with Notepad or vi that operates on your MV data, like BASIC.

Have you looked at products that facilitate use of Java or .NET? Integrations from VBScript or PHP?

If so, why haven't you done so already?
- Not aware of tools?
- Tried tools, didn't like them?
- Didn't even know we could do this?
- Prefer to do everything in the comfort of BASIC?
- Resistant to change?
- Too late to learn a new language?

Reasons for asking:
Over the years I've used many of the MV platforms with other languages and figured "why bother, no one cares". Others have written freeware or products that serve as language bindings, but these haven't revolutionized the industry. Rocket Software made Python a first-class citizen with BASIC for U2 coding, but few seem to care. And we're still seeing questions like "how do I do 'this' with BASIC" when the easy answer is always "write it outside and call in" or "call existing outside tools rather than feeling like you need to code everything from scratch". (Because that's what everyone else does!) So I think I'm missing something. Is there something that some of us think is dirt-simple that is still too inaccessible to others? Do you think everything is too hacky? Unsupported? Ineffective? Or requires too much knowledge?


Thanks.
T

[Kevin King]

Tony, I think the answer may be far more pedestrian than you might expect. Posts from members of this group would tend to suggest that a number of people are actively using these "outside" resources. However, there are a number of people who don't, and you're asking why.

What if the reason was as simple as time? What if, just possibly, some people simply don't have the time to do much more than survive their daily task list and aren't workaholics like some of us who trade endless hours of life to chase technology?

Everyone "cares", however what they care about differs. Some care first and foremost about their families and code merely as a means to provide. Some care about fame and fortune (neither of which a career in coding is likely to provide). Then there is a contingent that codes simply because we love the depth of the challenge and creative artistry that coding provides.

(Despite my intense love of this work, there are a few exceptions. For example, if my career path happened to require daily exposure to Perl, I may become a florist or guitarist in an 80's tribute band.)

On that note, I remain unclear about your "reason for asking". I suspect you have an idea or plan percolating so what's the real reason for your query?

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

[Peter McMurray]

Right on Kevin

When you're up to your neck in alligators, it's hard to remember you came there to drain the swamp. 

[Don Robinson]

Tony,

My first experience with programing was COBOL. After a year of college, I managed to write a couple of programs. My second language was SAS (Statistical  Analysis System) which has a BASIC like syntax and lots of statistical functions, which I don't need at the time. I used it to create a database (file) of about 30,000 items. It was a lot easier than COBOL but still not very exciting.

Then I discovered Pick BASIC and as they say, the rest is history.

So, to answer your question, I rarely encounter a situation I can't solve with BASIC and Unix commands and scripts. I want to check out Python in Universe when I have time, not so much to learn a new language but to use the libraries that it has.

As to the lack of Pick programmers, part of the problem is due to the rather low wages companies are willing to pay. I've seen companies run for years with 1 or 2 Pickies, then switch to a SQL database and hire 6 or 8 programmers at a higher rate. Hire capable people and teach them Pick and if they don't embrace it, let them go and hire someone else.

My grandson had to take a programming class in high school and they used Java. I tried to help him with very simple programs and found it totally frustrating. I thought BASIC was created as a teaching language but I guess it not classy enough these days. His Java experience was so bad, he has no desire to learn any programming.

Regards,

Don

Certified Universe Programmer and System Administrator.

On Sunday, December 11, 2016 3:08 PM, Peter McMurray <pgmcm...@gmail.com> wrote:

Right on Kevin

When you're up to your neck in alligators, it's hard to remember you came there to drain the swamp. 

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

[Tony Gravagno]

Fascinating that Don brings up this anecdote as it's spot-on with my recent activity.
And Kevin rightly redirected me to focus on what's really on my mind rather than just musing around the periphery.

When I'm not working I enjoy working on FOSS projects. I also enjoy playing in Minecraft. To combine these avocations I enjoy coding Minecraft plugins and helping other developers on their projects. One of the impediments I see to getting kids involved with programming is that languages like Java are just too low-level. There's no immediate "Hello World" gratification. With JavaScript, teaching programming is easy, there's virtually no rigorous syntax or infrastructure to interfere with immediate success. But wouldn't it be cool to teach JavaScript within Minecraft so that kids could also get that success in a game they enjoy? It turns out that we can do this, as these days with Nashorn JavaScript and Java and integrate quite nicely. So I'm spending some time in a project which exposes a JavaScript library for teachers to use in classes where kids learn programming through Minecraft. It's out there, there is a lot of success, and I hope there will be more.

But what about the Pick world? Why not use JavaScript with MV? It's easy. You can get anyone to do it. We lament the aging of the industry and the lack of new blood.
Hell, Don could get his grandson into JavaScript with Minecraft, make him feel like there's some value to programming - that kind of joy we all used to feel - and as he got older he wouldn't mind adding more complexity to accomplish more.

So I was thinking of exposing a JavaScript library through Nashorn. That would allow for command-line or IDE development with any OS.
It would also facilitate access through Java for those who would like to take advantage of Java functionality (and a world of components) without the rigors of the language.
I would even FOSS it just to give everyone a chance to contribute ... though I haven't yet seen a real multi-contributor FOSS project in MV succeed so I wasn't deluding myself too far with this aspect of it.

But then I got to thinking: We already have language bindings and people don't use them.
MV app providers could have collaborated with people years ago to interface with any language or UI of choice, but they didn't.
Time? Yeah, I get that people don't have time but when their client leave and their business dies I think people who are serious have a way of prioritizing in the interest of self-preservation.
So I'm left thinking - why bother add a new one to the mix?
And it's not just this. I mentioned mvEsperanto years ago which was a fledgeling effort to create a common API for all languages, MVDBMS platforms, OS's, and communications interfaces. With the zero interest received for that, I let that one die early.
With all of these things in the air I came back to ... What do these people want? What will they actually use? What do they see as fitting in that spot between where they are now and where they might want to be?

That's it. Cards on the table and chips pushed forward. I got nothing else to offer. :)
Thanks.
T

[Patrick Payne]

It has been my observation that a lot of pick developers like the ease of entry.  No installing Visual Studio, connectors, Sublime, etc, etc.  Just install your emulator and you are in your environment just like the old days of the dumb terminal.   

[Martin Phillips]

In my opinion, the problem with allowing mv developers to use a different language is that the features that make mv so powerful simply don’t exist in other languages. You end up having to invent a hybrid that extends the desired language to the point that it is far removed from the original starting point.

 

I have maintained for many years that a competent programmer can learn a new language in a week or two (though having said this, I started learning Java and was suicidal by page 10). I have recently delivered a multivalue programming course to several groups of experienced Java programmers. The reaction is usually amazement at just how simple our language is to use.

 

The mv Basic language has grown up to map directly on to the underlying data model concepts. The various implementations have then added their own extensions for proprietary features. Integrating concepts such as dynamic array handling or some of the very powerful string manipulation capabilities of mv into languages such as C, Java, JavaScript, Python, etc is extremely hard if the overall structure of the underlying language is to be preserved.

 

I recognise that developers want to be able to access the mv database from other languages but total integration may not be the best way to do this. I can only speak for QM but our approach has been to provide wrappers for other language interfaces based on the QMClient API. This has the additional advantage of not creating a maintenance issue where we continually try to catch up as the chosen language moves forward with its own developments.

 

 

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

--

[Wols Lists]

On 12/12/16 02:47, 'Don Robinson' via Pick and MultiValue Databases wrote:
> Tony,
> My first experience with programing was COBOL. After a year of college,
> I managed to write a couple of programs. My second language was SAS
> (Statistical Analysis System) which has a BASIC like syntax and lots of
> statistical functions, which I don't need at the time. I used it to
> create a database (file) of about 30,000 items. It was a lot easier than
> COBOL but still not very exciting.
>
> Then I discovered Pick BASIC and as they say, the rest is history.
>
> So, to answer your question, I rarely encounter a situation I can't
> solve with BASIC and Unix commands and scripts. I want to check out
> Python in Universe when I have time, not so much to learn a new language
> but to use the libraries that it has.
>
> As to the lack of Pick programmers, part of the problem is due to the
> rather low wages companies are willing to pay. I've seen companies run
> for years with 1 or 2 Pickies, then switch to a SQL database and hire 6
> or 8 programmers at a higher rate. Hire capable people and teach them
> Pick and if they don't embrace it, let them go and hire someone else.

My experience exactly. The company outsourced the database (at
considerable expense) and just wasn't interested in enhancing the Pick
system. It was an in-house system and I suspect they wanted "someone to
blame". We never had very much money to spend on it.

So they ended up with a bespoke system, which was probably just as
vulnerable to the bus factor (one of the reasons they got rid of the
in-house solution) because it was written and maintained by a systems
house that was pretty much created round a single contractor, that just
didn't feature as in-house.

Internal politics, basically. (And PHBs chasing buzzwords :-(

Cheers,
Wol

[Peter McMurray]

I have spent my programming life merging disparate systems and have yet to find anything that matches MV for commercial database programming. I am against fiddling directly with the data from outside as one simply cannot beat the power of commands such as MATREAD or LOCATE. I am delighted to see that Martin has this approach.

The one simple area that can be done externally is the initial data capture and display. We standardised it back in 1977 with formatted event driven screen handling that is form driven. My partner, Stuart Evans, was a heavy weight boxer whose hands did not suit keyboards, so the intention was that standard detail was written on forms that a data entry operator could enter and compile..

 I have fiddled with several options in more recent times only to see them deteriorate/vanish as the game changed. Silverlight anyone! However I see XAML as a serious contender for standardising a modern interface within the desktop environment with calls to MV subroutines for the heavy lifting in the database.. It can be standardised, generated or simply edited in a Notepad and works across all the devices.

OnGroup has standardised C# with SQL Server and I am just starting to look at it - more crocodiles getting in the way as clients dream up new ways of making work :-( - however it appears to be an effort to get rid of MV in the long run.

Python! Well I am afraid that that looks like a pet project of someone who learnt it at UNI, to quote StackExchange responses it has good specialised routines available but you will never get a job as a commercial Python programmer as it is a niche product.

[Tony Gravagno]

Let's be clear about the options for ongoing discussion. I hope this is a nice summary for anyone who doesn't do this kind of work.

QMClient, MVSP, UO.NET
These are all connectivity pipes that come in to MV through a socket with a proprietary server API. Each of them exposes a client/developer-side API for specific languages.

mv.NET
Includes as one of two libraries a completely unique interface for .NET developers. To connect to MV it uses either telnet or one of the above APIs, transparent to the developer.

So those options which we can term "bindings" allow for development outside of the environment, connecting in, which is familiar to ALL developers using any RDBMS or NoSQL platform. (Ignore SQL procs and C# stored procedures.)

Rocket Software's new "native" Python language support sits side by side with BASIC. It's built-in to the environment, doesn't connect in from outside. This is their approach to get new developers for the platform.

For the purpose of this discussion I'm just talking about outside language bindings coming in, not the Python-style native support as a sibling to BASIC. All of the bindings options come in through some pipe and then link into DBMS-side code that interprets requests and returns results. Bindings, also known as wrappers or mappings, exist for QMClient to facilitate development in various languages, so there is a .NET binding for QMClient, a Java binding, PHP, etc (if there's not there can be...)

So QMClient is a connectivity library with an API function to Read and someone has created a .Read method in each language that invokes the QMClient API, which then connects into QM with its own instruction (don't know or care what it is), which is then interpreted by code written by Martin. All of these interfaces work the same way for all of the DBMS platforms. UO.NET and MVSP could be augmented with other language bindings as well. Just because a library is .NET doesn't mean it can't be used by a non-.NET mapping. And MVSP is actually two things in one: It's a low-level socket API that's wrapped by two bindings, .NET and Java. Another should be trivial.

As to the efficacy of bindings in general, this is a proven method of interfacing with the environment. All of these interfaces support core functions like Read and Write and dynamic array manipulation. So there is no question as to the value of any language binding, as long it will be used by someone.

The thing that's different between these external language bindings and BASIC, is that BASIC is close to the DBMS and all operations are local to the server. Whereas with the external interfaces, manipulation of data may require retrieval of raw data followed-by client-side (or middle-tier) manipulation. For this reason we prefer to have some operations performed in the server rather than outside. All of the interfaces allow for calling BASIC or TCL functions. This is exactly the same as stored procedures in RDBMS, where parameters are passed into the server for execution. So again, this is all not only common, but The way to do this, Everywhere.

So this is where I come back to :
Why don't more MV app developers code to MV with the tools that exist?
One could probably summarize that the one-man shop guys just know BASIC and aren't interested in learning anything else. Even when I take my rosey glasses off, I don't get that pessimistic. Sure there are a lot of these guys, but I'm not even talking about them.
I'm talking about the majority of end-users and VARs that do have someone with non-MV programming experience, but they still don't know how to get in from outside, and some don't even know that they can.

For decades now the MV industry has seen third-party products that cater to the lack of initiative on the part of MV developers. DesignBais is a prime example of a fine product that claims you don't need to know anything outside of MV to put a GUI on your app. All of the other bindings have been available for years - Raining Data even took the approach of "look, we'll not only provide the binding but we'll explain what the technology is so that you know why you want to adopt it". And here I am saying: JavaScript is now the most commonly used language on the planet in web pages and now on servers with Node, kids can be competent in days of playing with a game, we can use it with MV, and Still I don't think that anyone would be interested!

One problem is that we have our entire applications written in BASIC within the DBMS - which RDBMS people never do as they separate the UI from data access as a matter of course. The essence of the complaint is that people don't know how to move from that mess to a multi-tier topology. I've written a number of articles on that to define the path. If they knew how to do it And they knew how to use the language bindings, we would probably see a lot more "mainstream" people interfacing with the platform with no problem at all. And if MV developers would hire/partner with others to help and learn, they could do it too.

We're Not talking about the capabilities of external languages.
We're ignoring people who will retire and take their application with them.
I'm talking about application owners who do want to breathe some new life into their apps - and I'm wondering after all this time, what Is it that stops them.
The world won't get much easier for us than it is now.

Why do I care about any of this? Because frankly I'm sick of hearing every day about some company dumping their VAR and platform for another offering. I do Not enjoy getting calls from end-users who say their VAR told them they can't do things. I get more calls now from companies asking for assistance in migration than for consultation for options about what they can do with their existing system. And I'm confounded why the MV DBMS companies aren't all aggressively informing their end-user base that all things are possible - without a costly migration - and linking their Demand channel with a Supply channel that can help with those annual renewals.

Ahem.
So uh, what do you guys think? LOL
T

[Peter McMurray]

Hi

Glad to see that we are in pretty close agreement TG.

ME "The one simple area that can be done externally is the initial data capture and display" 

TG "which RDBMS people never do as they separate the UI from data access as a matter of course."

MP "In my opinion, the problem with allowing mv developers to use a different language is that the features that make mv so powerful simply don’t exist in other languages. You end up having to invent a hybrid that extends the desired language to the point that it is far removed from the original starting point."

The separation of the UI and using subroutines called through MVSP, QMClient etc. gives one the benefit of both worlds. SQL server database admins freak at the thought of somebody touching their database designs which is as it should be. 

Get the database design right and write the CRUD rules in MV subroutines that can be called from anywhere then the other languages can be used to advantage. In my opinion UWP makes this now a reasonable option. 

In my experience a large proportion of the programming pool simply do not have the commercial comprehension coupled with the deep knowledge of how the database works to do good database design. Sadly many of those actually did some of the horrors that we meet such as items that are actually lists of records.

[Tony Gravagno]

About Martin's note about features missing from other languages for MV integration: That's what prompted me to clarify the difference between external access and the new Python support at RS. At this moment I can't think of ANY language that supports such DBMS-specific integrations outside of SQL dialects.

(I'll preface this by saying I know what Martin was talking about and I don't think he would disagree with any of this. My notes here aren't for him or in rebuttal to him, just another clarification of how we get from here to there for anyone who is interested.)

With OOP and the universal understanding of modules, plugins, etc, any language can make use of class libraries which expose all of the power required, without making it look like it's a bolt-on. In other words, rather than a library expecting a developer to open a file, read and parse a dynamic array, etc. It's much more elegant to be able to do this through a common factory method, extension methods, or other patterns which don't require the developer to understand the nature of the data source. I and other developers create these sorts of abstractions for ourselves so that we don't need to fuss with the MV-ness of our data. My application code never goes direct through mv.NET, it goes through an abstraction layer so that I can swap mv.NET for MVSP or even UO.NET. It's very easy, possible with every connectivity library, and this is extremely common practice in MVC. In fact, this is one of the GoF Design Patterns (Facade or Decorator). So no, other languages are not missing the features afforded by BASIC - the only difference being that they are further separated from the core so they need to call in to the DBMS to invoke such functionality, where the layer between BASIC and the DBMS (through the runtime engine) is much thinner.

Someone may correctly note that I'm not talking about "language" features there but calls to modules that implement features. I think the difference is purely symantic and just highlights the point that it's really not important whether a language supports a feature or whether we built onto it - the net effect is that easily get what we want so why is it a consideration?

Thanks.
T

[Tony Gravagno]

Peter wrote:
> Get the database design right and write the CRUD rules in MV subroutines that can
> be called from anywhere then the other languages can be used to advantage. In my
> opinion UWP makes this now a reasonable option.

To repeat what you've confirmed: This is the ONLY way that the rest of the world interacts with databases. So UWP can't possibly just now present a reasonable option, for MV or otherwise. I did a demo at the Pick Systems conference in 2000 which profiled MV access from several languages and IO mechanisms, including voice synthesis and speech recognition. It was easy then with the tools available. Nothing has changed in the 16+ years which have followed.

By focusing on UWP you do serve to promote your new favorite technology. Great. Run with it. I wish you the greatest success.

But at the same time you make it sound like once again MV is somehow limited in how it might interoperate with the world. That sort of backhanded compliment to the platform (which we see a lot in these forums) is exactly the kind of affirmation that keeps people wondering if MV is capable of supporting their business into the coming years. I'm here to confirm for you that MV has been accessible by every language and protocol for well over a decade. This thread is here to ask "why haven't people used that accessibility yet?" And for those who feel compelled to say "I did", I feel compelled to explicitly add "the request is directed to those who have not done so".

Regards,
T

[Bob Dubery]

At the place I currently work, we use a product by the name of Psygn. This puts a web interface on UV, manages the sessions, and adds some javascript extensions by which you can manipulate MV data and call BASIC subroutines  with javaScript. There's a dev kit that you can use to create pages (containing objects) and tables (sit within the tables and present the data). The general idea is that you use javascript (and CSS and DHTML) in the interface and basic for manipulating the database and for your batch updates (monthly invoice runs etc).

This is a good division of duties. MV BASIC is not well suited to what is now considered an acceptable user interface.

[Ian McGowan]

Sounds interesting - is that an internal-only tool or do you have a link to share?

[Bob Dubery]

I've been asked off-group already. It was developed here in South Africa. I remember an early demo, years later I end up working with it. I don't know the history of the product, but AIUI it is no longer on sale.

In general, I think these tools have to be properly evangelised and explained to MV programmers. I learned about SB from somebody who was very keen on it and knew it well. Then I moved to another job where they had SB+ but really just used it as a screen painter and didn't make any use of things like transaction definitions - which seemed a waste, and also left management wondering why SB+ which was supposed to be so great didn't do various things that actually it could do if somebody just bit the bullet and decreed that it be used to the full.

With Psygn there is an ability to bind a basic subroutine to a page, so there is a temptation, and sometimes giving in to that, to just write huge subroutines instead of using HTML and javascript. 

This may be more difficult in the scenario I've run into many times where you have programmers on an MV system who are by no means stupid people, but they are not programmers. They are people who fell into programming as a means to get a job done.

[Steve Trimble]

I've used Coyote from EasyCo for years (since around 1996). It is a full HTTP 1.0 compliant web server running real time in 'PICK' (many flavors available). I began using it with mvBASE, but now use it extensively in D3/Linux and QM/Linux. Very fast and reliable. You need to know HTML and mvBASIC. It also has a RPC module which allows reads/writes/deletes from multiple 'PICK' machines. Quite fascinating to see how well and fast it handles static and completely dynamic web pages. I typically have Linux, Apache, mValue, Php running. I let Apache manage all static pages and images, with mValue handling ALL dynamic. If you set Apache HTML up to allow Php within HTML pages, it's even more dynamic in all kinds of ways. Coyote web server runs as phantoms, so normally, licenses of PICK are not affected.

Steve Trimble

Computerized Data Mgmt Inc

(501) 615-8674 office

(501) 772-3450 cell / text

--

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

[Tony Gravagno]

Since I started this thread with a specific intent, I'll ask that it not digress into the same direction as all other threads on the topic of "favorite web development tools".
That's not what this thread is about.
Thanks.
T

[Dawn Wolthuis]

pSygn was from us -- the same group of developers who now have MVON# as a product. We are still in the rather-quiet phase where I'm giving folks here a bit of a preview, but we are preparing web pages, etc. 

Whether you currently use pSygn, SB+, Blacksmith, or a code or app generator for which you have source code, we can transpile it all to C# so the application can run in .NET, optionally with SQL Server as the DBMS. The "MV" aspect is still there, but it can be run in the Common Language Runtime (of .NET or Mono) and the MV data can be persisted with SQL Server.

I think at least 2 pSygn sites are now running in .NET.

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

Take and give some delight today