Consider a new project : MV or RDBMS?

[Tony Gravagno]

I face this scenario a lot.

Someone suggests a new project, whether a mobile app or a consumer-facing website. We get excited, write up some specs, and then decide what technologies to use. No, I don't start with the assumption that I'm going to use MV or .NET or LAMP or Java or Xamarin or WordPress - I define the problem and then ... wait for it.... wait for it... choose the right tools for the job! When it comes to considering the database, sure, I'm really inclined to put MV on the table first, but if it doesn't fit I need to pull it off that table.

I think about things like the volume of transactions that might move from UI to server. Working with other technologies I always feel like we're closer to the metal when we use a common client library to get into MySQL/MariaDB, SQL Server, Postgres, etc. With MV, the connectivity always seems like a bolt-on. It feels like it's going to be slow because I'm intimately aware of each connection/failure point. This is irrational because I know all databases work exactly the same way, opening a socket/handle, marshalling transactions, closing, and formatting the results for either side. But without benchmarks (for different connectivity methods and platforms) I can't shake that awkward perception.

I think about how many different clients and platforms might be included in the topology. For a site that make use of a WordPress infrastructure for user and content maintenance, and transactions handled "elsewhere" it's natural to first consider keeping all data in MySQL. But if WP isn't the only client, then WP can use MySQL for its stuff, but the app code and data will be completely separate.

I think about who else will be involved. If I am writing this myself, MV stays on the table longer. If collaborating, I need to encapsulate the MV connectivity in an agnostic wrapper for whomever is accessing the server. I don't want to have to explain how to do MV stuff to a non-MV developer, working with connectivity like mv.NET, QMClient, MVSP, Linkar, mvConnect, etc. If I give them a wrapper then I can re-tool underneath without affecting the middle tier or UI in any way. This is the way it should always be done anyway, but for a solo project this luxury can be deferred until later.

I think about cost. How much will MV licenses cost with the stupid, antiquated per-seat model (or "Enterprise" licensing or whatever they call it this year)? How much will the site grow and how active will the DBMS connections be? If I'm hitting the database a lot, the choice for MV becomes more difficult. I know developers that have been successful with their web UI, after struggling to re-fit and modernize for a new age, only to face the high cost of having to get more DBMS licenses than expected. While we've cheered for ages about how cheap it is to run MV, that rhetoric doesn't hold up when we apply per-seat licensing to a modern internet topology.

I think about ease of maintenance - hands-down MV wins here. But if the UI is written with different tools than the back-end, ongoing maintenance requires different skillsets, maybe different people. Compare to a PHP-only site, or Java-only, or C#-only, or these days even JavaScript, where skill with one language covers most of the middle-tier and server development.

None of this is black or white. It's all arguable. There are other considerations. I'm asking what others do when confronted with these real-world considerations. I don't maintain my own business apps. I like to write new stuff. (Like most people. :) ) So for me this is a common scenario. If you're not inclined to write new applications then this doesn't apply to you so much. Most MV app developers have faced the problem where they already have the MV app and they need to consider the UI. If we have any interest in attracting new application developers to this platform, we need to have answers to these questions.

Or maybe it's just one question: When we have a worldful of options, why might we use MV? The answer has to be better than just personal comfort.

T

[Albert Kallal]

Well, I think much of the issue comes down to investment of time vs rewards.

I would love to say learn and become comfortable with the LAMP stack. The problem is time! It is the same reason why I don't speak 3 languages (I only speak English).

The only hammer I know is often why I choose the set of tools. However another  large issue is return on invested time.

So, for web stuff, its .net for me all the way. And while I been lucky, my clients use  those platforms. This is a combination of chicken and eggs here. Since I know  that particular platform, then that's the work I gravitate to.  The web tools is a really big world right now. So, while I try to avoid learning JavaScript  and messing with CSS? However, there is just no way to avoid it! (so both of those skills of mine have dramatic increased - not due to me wanting to, but it being in my face so to speak). To be fair,I am starting to grow rather fond of how amazing CSS is.

But, the problem is the rewards part of this formula. Any web stack is a big deal and a big thing. So, for my precious time, then what tools I learn are going to be the ones that I can parlay into other work and other systems.

I shall try and stay on topic here, and that means do MV solutions and MV databases come up  beyond companies using MV systems? Unfortunately that choice is not in the running. And given that the tools I use are windows concentric, then that's the platform and area where I can offer work of value. 

Just like we saw a big push from DOS or green screen to windows desktop, clearly the web UI and march is where things are going. The database used matters less and less, but then again, that's part of the problem. My investment of time vs rewards of learning another MV system is ONLY of value if one drops on my lap - and that is occurring less and less in regards to  mv systems. 

So even right now where I have full choice? Well, cost, licensing issues, and finding existing code samples etc.? Again, MV systems can't offer that to me.

I wish there was more work in MV land, and as a result my MV skill set would continue to grow. But right now, its SQL server skills of mine are growing. The asp.net skills are growing. JavaScript and CSS skills are growing.  If more MV concentric work existed, then my MV skills would grow.  But, for a new developer to invest in MV skills will not occur. And for new systems,then again MV not in the running.

It hurts, but I only see these web systems working with MV systems as a means to preserve MV investments, but not a platform that I can afford to invest mv skills into. (but, hey, paying work really changes what I willing to learn and use!).

I love MV systems, and I love my time I spent with these systems. In fact, I rather miss them!

But, from a new platform choice? I can't see MV  systems being in the running. 

The only bright spot is that a good number of web stacks can play nice with MV systems, but the general approach to the data is SQL and related tables. While the rise of the  no-SQL movement helps, its again not really the mv platforms that are causing this trend.

So, to get me back on the MV wagon and have MV systems as recommended choice? Gee, there have to be a hodge podge of business running these MV systems, and I watched companies move away from them. I used to know (and do contract work) in our industrial parks - all kinds of companies from Accounting firms, Trucking companies, propane suppliers etc. had pick systems running. ( a few still do), but most now have migrated out of mv systems. And when they go shopping for a web system, those same firms pitching a web system also tend to jump at the chance to wean these companies off of mv systems. 

The mv systems that seem to go away are the companies that are just under the size that can afford a full time developer.  They tend to be un-capitalized, but toss in few people knowing mv systems, then it just justifies the move off of mv systems. This is not a new story to anyone here.

So, I have to invest in a set of tools - they have a nasty learning curve, and once you get up to speed in which you can offer solutions, then I have to turn that skill set into money. 

I will say some of my most enjoyable work with MV systems was leveraging my skills working with office (Excel, Word). I did some great work were we replaced JET documents and started using MS Word. (build a nice bridge and word merge system). And then the same with Excel. A client had a complex spreadsheet on Pick. Some of the cells pull data directly from the datbase. I used the Pick ODBC  and tools to re-create the same effects for some cells in Excel. 

So, my strong VBA/Office skills combined with mv systems resulted in some great work. 

But, now the demand and what a business is willing to pay for is web portals, and how they can un-lock all that business data in their systems and let the customer have at that information. (gee, when is the last time you called a travel agency - one that likely ran some nice mv/pick system?). Now you use the web to get at the same data they had, and you don't even need  that travel agency. Same goes for package delivery. Even a local company running a mv deliver system now wants their customers to see and view that data. So, while no work is required on their mv system, they will most certainly pay for web portals to work with that data.

So, everthing I am doing right now is based on increasing my skill set for the given market.

To answer you basic question:

What would it take me to offer mv systems again?

Answer: by offering such systems, it would create more work and cause me to have a increasing skill set for other business. Its that simple - I don't know how to make this occur, but that's the simple answer!

The wheel making the most noise is going to get my attention.

regards,

Albert D. Kallal

Edmonton, Alberta, Canada

[Dawn Wolthuis]

First, I will answer a variation of your question -- "Why might we use NoSQL"?

I would use NoSQL in any situation where there is

a) an RDBMS already running in production and the requirements make it such that it makes sense to work with that DBMS or make use of the RDBMS skillset already in house or 

b) a clearly missing feature in all NoSQL databases that is a requirement and for which there is no feasible mitigation strategy

c) a better ROI with an RDBMS than with a NoSQL DBMS after doing a feasibility study, perhaps due to use of the combination of Cloud and open source databases

Now to your question.

Once it is clear that a NoSQL would be a better business decision for a particular project (e.g. Chipotle switching from SQL Server, an excellent RDBMS, to Cosmos DB, an excellent NoSQL offering), why would I choose an MV option from among the NoSQL providers?

1. Retaining an existing investment in order to move it forward rather than a rewrite or new choice of app vendors

That's it. If I already have MV BASIC in house and want to retain the business logic, then I need an MV BASIC compiler and related trimmings, else Fauna DB (or one of numerous others) might be a better bang for the buck. Look what I can get for free -- https://fauna.com/pricing and GraphQL is part of it (Fauna DB is from an Alphabet company, so, if my initial impression is correct, Google is behind it).

The "platform" will include the cloud and the database, and we can, in theory, write the app in a way that it can be moved from one to another as pricing changes. Now, how to write serverless-vendor-independent apps. Hmmm.

--Dawn

Dawn M. Wolthuis President, Tincat Group, Inc. 616-901-6293 | dw...@tincat-group.com 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
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/d90ac5bd-63c9-49d3-bc6a-4fea1ad764fa%40googlegroups.com.

[Dawn Wolthuis]

Oops, that early line should be 

I would use an RDBMS

or I would NOT use a NoSQL DBMS ...

Dawn M. Wolthuis President, Tincat Group, Inc. 616-901-6293 | dw...@tincat-group.com Take and give some delight today

[Tony Gravagno]

Albert and Dawn - thank you both for your considered responses.

So far I'm hearing you would (probably? most likely?) not put MV on the table for a new project - subject to due consideration.

I don't want to get into NoSQL branding - that's covered well in other threads.

And I am really focused on new projects, not existing environments. As an example, and I'm sure this happens with most of us, I get a lot of family and friends that say something like "you work with computers, I had this idea for a website that does 'this cool thing' but I have no idea how to do it." Sometimes the idea is good and deserves more thought. My mind instantly gravitates to the design of MV data and code, sort of as a mental prototype, and then wanders up through UI and other topology considerations noted in my OP.

As Albert said, I think when non-MV people think about such things, they think about whatever tools they're comfortable using - LAMP, .NET stack, or the latest with newcomers seems to be NodeJS and Mongo plus Angular. Ultimately after all of the considerations, I don't think there's anything wrong with keeping MV on the table longer, just like other options. But I think we face this stigma of how MV is the platform that people are migrating away from, that it's only used for old "legacy" apps, that it somehow doesn't fit with contemporary business requirements.

This comes back to the notion that MV advocates are actually it's worst enemy. We internalize those notions as a trend and then we perpetuate the trend ourselves by not using MV where it actually does have value. Yes, for client projects we don't want to be remembered and faulted as the people who used some unrecognized software at the core of their systems. But if we actually use MV where it fits then that stigma goes away to some extent - the stigma is inversely proportional to our usage (and new developers) of the platform for new projects. That's exactly how these other stacks become popular amongst developers and recognized by those who sponsor such efforts.

I think what we lack in this regard is the feeling of a good fit between modern UI tools and the back-end. I think this is due to most MV people growing up in a character-based world with PRINT and INPUT coupled with linear code, rather than <tags> and an async I/O model. Until asynchronous I/O with a remote client feels as natural to code against as the 80x24 screen, older MV coders are not going to do the kind of mental connecting of dots described above. I think when a new idea comes along, most MV people will think it through entirely from the MV perspective, and seize up at the interface through the server and out to the UI. I think that's why we don't see older MV people writing new consumer-facing web apps.

I don't think we're going to get most MV people (who don't already do this kind of work) to ever get comfortable with new paradigms. To bridge the gap between here and there, I've blogged a few times on the concepts of modularizing code to separate UI from rules, and partnering with others to do that middle-tier + UI stuff that they don't.

http://nebula-rnd.com/blog/mv2web1 - to 3

http://nebula-rnd.com/blog/let-go

Specifically - If you are presented with a challenge for a new site, don't think about it as "I can't do everything so I can't do it", think of what you can do and then consider partnering with others for what's left. Tip : They don't know everything either.

I'm dancing on both sides of this topic:

- I'm sharing my personal concerns for if, when, and how to use MV for a new project.

- I'm encouraging others to reconsider how they approach the topic so that they/you can make decisions based on a more complete analysis.

And I'm hoping others will join in this thought process. There is no right answer or conclusion. It's about thinking through what we do and why, and getting insight from others in the same position.

Thanks for playing.

T

[Donald Montaine]

I still "play" with OpenQM, just because it is fun.  However all my paid work is using an integrated set of tools that allow me use a single language, but target desktop, web and mobile, and avoid having to dig deeply into the mess that is current web programming.

For new projects, the biggest barrier to MV is the licensing model.  The tool I use costs me around $1500 per developer, per year to license, only if I want to stay current.  It is not a subscription, rather an upgrade.  So, I don't have to even have that cost every year.  The very good included database is free of licensing charges or I can use MySQL or Postgresql connectors, also provided without additional charge.  Web servers can be between free - $350 per year, depending on what add-ons are needed.

-- These cost comparisons do not include design, programming and implementation costs -- just the ongoing cost the client sees after paying for the development of the system.

So say a company needs 20 concurrent connections:  The max third party cost my client is going to see is $350 the first year and less than $250 every year thereafter if they need an upgrade for web apps.  There will be no yearly licensing charge to a third party for PC or Mobile based apps.

A similar QM solution is going to cost the client around $2800 for first year licensing and around $600 per year for maintenance.  And we haven't even gotten to the costs for a web add on products which will probably double or triple that cost.

------------------------------

I love QM programming, and I have several licenses that do not expire until 2027 - so it is a cost free hobby.  But, I want to sell my skills and not have to then sell third party licensing costs to my clients.  The fact is that there is no MV product that is inviting to a new programmer or entrepreneurs.  No new programmers are going to spend money to learn the MV model or try out ideas on an MV system when they can do the same work on so many other systems with a zero cost of entry.

I choose to pay a small yearly cost so that my users can, in most cases, avoid any third-party payments.  I could choose to use entirely free development products, but for me the tools provided by my current vendor are worth the cost.

--------------------------

I have said this before, but I will say it again.  All the marketing in the world is not going to do any good until there is an entry point into the MV ecosystem that is cost competitive with all the other competing SQL and No-SQL products.  For almost all of them, their entry level cost is zero.   The same needs to be true with MV.  Get people hooked with a no cost product and then only charge when they need enterprise level features.  Even Microsoft has finally learned that lesson.

[Albert Kallal]

Thanks kindly Tony,

That post was a bit hard to write, since I did not want to come off as being against MV solutions.

I will say that the rise of the web is in fact a opportunity for new work - including MV systems. Just like a saw a number of customers jump from green screen to GUI when that started really going by the last 90's.  New customers simply did not want green screen applications anymore - even if they were good. But that ALSO meant that a whole new round of work and opportunity appeared. 

A "change" in technology is often good - if you can use that change.  I remember when fax machines came out in the mid to late 80's. There were "many" long time business supply outfits that had been around years and years. So trying to break into the office business supply industry would be VERY hard. But I knew some folks who started selling fax machines door to door. They soon had a office. And in 5 years they had as many customers using their photo-copiers as they did fax machines. In fact their revenue from photocopier service contracts soon exceeded their fax machines.  The WHOLE point was they would never have been able to break into this saturated business machines market if not for the fax machines appearing.

I saw the same thing with that green screen to GUI. I saw some companies not change, and they were hurt bad. But I saw a whole new round of work and business opportunities occur because business wanted new GUI applications.

So, new things like Fax machines, or GUI and now the web is creating a whole new round of work.

What the above means?

Well, for MV systems, there is a whole new round of work and opportunists occurring. (because emailing documents etc. to customers is giving way to customers hitting some kind of "customer web portal" in which they can self serve project status, approve work, or even enter and setup and become part of the business process required to work with customers).

This "new" round of opportunity can cause companies to migrate out of MV systems, or with the correct offerings, not only keep existing customers, but actually create demand for new systems.  But in near all cases business have somewhat mature internal computer systems. So they now have 30+ years of internal business systems and software built up. A LOT of value exists here, but their customers can't use that information system.

So the new action (and work) is thus web portals. Web portals are not occurring because they are new and shiny, but have the MOST potential to save business a LOT of money.  Why have some internal staff say ask a customer to phone, or email the specification or details about some product or project. Internal staff then sends that information over to some quote department. They then fire up a nice internal quoting system,and RE-ENTER the data that the customer just sent them.

So from customer to sales rep. From sales rep to quoting department (again might use some complex quote system), then  send it back to sales rep, and then back to the customer.

With the web? Well, customer fills out the information - but it can now interface to the same quote and estimating system that internal staff are using, spit out the quote, and no internal staff need be involved. I mean, I seen a number of companies estimate that EACH TIME a internal staff handles a document or paper is a cost of about $25 dollars. 

So the potential of customer web portals is huge and a hot market right now. It is ALSO a means to un-lock the huge amount of software (internal) that business have built up over the last computer revoluion of 30 years. Portals can un-lock that internal software and  expose that software and business process directly to customers. The labor savings as a result are huge, and since they are so huge, then business will pay for this work. (just like they did when they paid lots for building those internal software systems. But those internal systems are mature, and don't need much investment anymore).

To STAY on topic?

This was about offering MV systems. So, the rise of web systems means new work, and new opportunities. And that EVEN means that adding web portal software to existing mv systems can not only benefit business in a big way, but in fact can drive sales of that software to NEW business. 

Just like some business are migrating out MV to adopt web systems, it also possible for the reverse to occur. But I can't stress that web portal options are fast becoming part of near any kind of comprehensive business solution software. So even if one is not looking to drive sales to new customers in terms of MV solutions, one better offer web portal solutions as part of that "offer" else the exit rate out of MV systems will occur or even increase as a result of this change to customer web portals.

As noted, Ford vs Chevy, or this framework vs another debate was fun in high school. That's not the real issue.

The issue is  web offerings are fast becoming standard fair as part of software systems and offerings. This in fact is a opportunity for MV systems, but only if they run with this change and thus resulting opportunity. 

Regards,

Albert D. Kallal

Edmonton, Alberta Canada

[Donald Montaine]

Simple summary:

There are companies who are deeply committed to MV because of years and years of investment.  While the may slowly migrate some systems to other database platforms (ADP Dealer Services with Postgresql and Oracle for example), the level of investment will make many migrations cost prohibitive.  Some software vendors will continue to sell, upgrade and support MV based systems to existing clients while developing more "modern systems" to sell to new clients (think Columbia Ultimate, now Ontario Systems).  Other former MV software vendors will transition entirely away from selling new MV systems (Jenkon).

All this means that there will be ongoing opportunities to sell add-on software to existing clients (Evoke), and continuing opportunities to maintain existing systems.  There will be very few opportunities to develop new systems, except to market to the existing base of MV users. It also means that slowly, over time the opportunity universe will continue to contract.  Some MV users will finally be forced to to migrate because of an aging and diminishing group of professionals who have the experience to maintain large, complex systems.  

Most new developers and entrepreneurs will not invest in learning MV for a very long list of reasons, including a high cost of entry, a marketing model that is not normal for today's market, the layering of products necessary to produce applications that meet current standards for usability, the lack of advertising, and the lack of education in universities, and the unwillingness of most MV shops to embrace the distributed workforce and/or perks of modern software shops.

[Kevin Powick]

On Saturday, 7 December 2019 11:31:55 UTC-5, Dawn Wolthuis wrote:

....e.g. Chipotle switching from SQL Server, an excellent RDBMS, to Cosmos DB, an excellent NoSQL offering

Please  link a case study or presentation about this.

I've googled various questions referring to Chipotle and Cosmos DB, but can find nothing in the first pages of search results.  Only once did I come across a Chipotle job posting that did mention Cosmos DB, but nothing about what aspect(s) of the company have moved to that platform.  Perhaps my "Google Fu" is wanting.

--

Kevin Powick

[Bob Markowitz]

Thanks for the Evoke mention Donald.  I fully agree with your "simple summary". 

Evoke will help keep legacy MV apps around for a few more years.  But because Evoke allows for multi-tenancy (differing databases in a single app) some of our users are writing transactions back to SQL as well as MV allowing a much easier transition to SQL and speeding up the end-time of their MV application.   

On Monday, December 9, 2019 at 1:52:39 PM UTC-6, Donald Montaine wrote:

Simple summary:

[Donald Montaine]

What I find sad is that it appears all the core vendors (Rocket, Zumasys, Reality), buy into this scenario, ie: support  the existing users, but don't do anything to become a reasonable alternative to mainstream and new technologies. This would require a product that was sold and supported the way most other app development systems are today; having the ability to do full stack within a single product of which the database was only a part, and an effort to make the product appealing to young entrepreneurs as an alternative to the other current options.  The core strength of MV was simplicity.  Today, products that are focused on making the web "simple" compile to HTML, Javascript and CSS, hiding the complexity behind a single language.  In the past, the same thing could have been done with PC based apps.  This could have been done with MV as the back end technology, but apparently the "vision" and "will" was lacking by the former and current custodians of the MV model.

I think products such as Evoke are wonderful, but the reality is that the layering of products, the complexity of dealing with multiple vendors, and the entry and ongoing subscription costs make the solution unlikely to appeal to anyone writing new systems.

This is not advertising, just an example.  One example is Lianja, who took the Foxbase language and database structure and created a product that provides legacy Foxbase coders with a platform that supports PC/Lan, Web and Mobile at a reasonable subscription price with inexpensive subscriptions for their end users.  In addition they added the ability to use Python, PHP and Javascript scripts as well as ones written in the FoxPro language so that it appeals to persons knowledgeable in newer languages and technologies, not just legacy programmers.  I can not believe that the opportunity to do the same with MV did not exist.

[Dawn Wolthuis]

Hi Kevin -- Check out the 3rd keynote here, just after minute 6. 

https://www.microsoft.com/en-us/ignite  

Let me know if you also hear him say that they switched from SQL Server to Cosmos DB. It has been a while since I listened. I think they were doing Vue on the front end, Cosmos DB on the back-end.   --Dawn

Dawn M. Wolthuis President, Tincat Group, Inc. 616-901-6293 | dw...@tincat-group.com 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
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/3accae5d-55d4-4091-8259-6daa0547df67%40googlegroups.com.

[Kevin Powick]

On Monday, 9 December 2019 17:59:46 UTC-5, Dawn Wolthuis wrote:

Hi Kevin -- Check out the 3rd keynote here, just after minute 6. 

https://www.microsoft.com/en-us/ignite  

Let me know if you also hear him say that they switched from SQL Server to Cosmos DB.

Well, one very small mention of Cosmos DB and a failed website demo doesn't really impress me.  It took 3 tries to submit the taco order without a service error, and when they submitted payment, the camera cut away from the webpage spinner that kept going round and round.

Sure, it sounds like Chipotle is using Cosmos DB in some capacity for their on-line ordering system, but with so very little detail, it's not a ringing endorsement for company-wide replacement of SQL Server.

A case study would be great.  Maybe someday they'll have one.

--

Kevin Powick

 

[Dawn Wolthuis]

So this is another way in which we might differ, Kevin. We have different perspectives, and that's fine. I'm a "strategic doer." While I cannot see the future, I feel tragectories, and I try to nudge it in directions I want to see.

When Microsoft gives a keynote where at Ignite where they have a customer say that they were going to use SQL Server and they chose Cosmos DB instead, that's big news to me. That says that Microsoft just encouraged a customer to choose NoSQL over SQL. Additionally, I didn't hear Xamarin or XAML -- I heard Vue. That's the customer Microsoft brought on stage to show off, successful demo or not.

I think of where we were and what I visualized of where the industry would go and bam! this is a milestone, at least in my own little project (to change the industry from Iowa, hah!). There are several other milestones I can picture ahead of us, but having a big SQL vendor endorse NoSQL for a business customer is big. That it is Microsoft is huge. Huge, I tell 'ya. Remember when people thought that "relational databases" were the norm for businesses, as far into the future as we could see? I was pro-NF2 and boolean logic, so I didn't think that in 2002, and MIcrosoft doesn't think that now. Does anyone else think that is super groovy cool?

--Dawn

Dawn M. Wolthuis President, Tincat Group, Inc. 616-901-6293 | dw...@tincat-group.com 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
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/6ae5937b-c51e-4acf-aa0f-0cdbc1a6d1e8%40googlegroups.com.

[Brian Speirs]

Hmmm. My take is a little different.

I didn't watch the whole presentation, but the basic theme is: We'll help you do what you want, using any platform, and any language.And Chipotle are using mostly a Microsoft stack - specifically Azure, .Net core, and C#. OK - so they were using Cosmos DB - but the MS guy was emphasising that they were using the connectors built into .Net core. i.e. we are helping you do what you want.

Put it another way. Microsoft recognise that people use many products that are not part of the Microsoft stable. Why should Microsoft cut themselves off from those people. Rather, let's help them, and give them tools and platforms that work with those products. And we'll clip the ticket along the way. It seems to be working - their revenues and profits continue to increase.

Cheers,

Brian

[Kevin Powick]

On Monday, 9 December 2019 23:20:00 UTC-5, Dawn Wolthuis wrote:

When Microsoft gives a keynote where at Ignite where they have a customer say that they were going to use SQL Server and they chose Cosmos DB instead, that's big news to me.

Big news?  They chose one MS offering over another, likely because they were already so invested in MS.

 

That says that Microsoft just encouraged a customer to choose NoSQL over SQL.

Not at all.  The customer, already heavily invested in the MS platform, chose the MS NoSQL option.  Path of least resistance, and a marketing opportunity for the Azure/Cosmos team.  The real question might be if MS did not have Cosmos DB, would Chipotle have chosen a different noSQL option?

The industry is "into" document stores and MS isn't stupid (too often).  However, it seems the primary use for NoSQL is BI, analytics, insights etc.; Dump massive amounts of schemaless data into storage (data lakes), index everything, then perform the desired queries to populate analysis tools.  It's a good use case, but that doesn't make NoSQL the RDMS "killer".... At least not yet.

 

I think of where we were and what I visualized of where the industry would go and bam!

No words, oh soothsayer. 

 

... but having a big SQL vendor endorse NoSQL

Were they endorsing it before they had their own offering?  Clearly they believe in NoSQL enough to build Cosmos, but let's not pretend they were pushing NoSQL before they could profit from it.

 

 I was pro-NF2 and boolean logic, so I didn't think that in 2002, and MIcrosoft doesn't think that now.

Always ahead of the curve, eh?

 

Does anyone else think that is super groovy cool?

I think that software companies exist to sell software and services.  To that end, they must continually develop products and services that result in the deprecation of previous services and offerings.

--

Kevin Powick

[Dawn Wolthuis]

Not sure if I’ll ever figure out what your need for ill will is. I could have said “we” instead of “I” re angling on NF2 over time, but I didn’t want to speak for anyone else. I’m not a soothsayer, but I am a futurist and “strategic doer,” a project manager.

Where I have spent full days writing algorithms to prompt a computer to do something, visualizing how it would work before coding, sometimes right the first time, sometimes not, I also pop up a level of abstraction from the machine to larger, more complex systems that include people, such as organizational projects. I also sometimes pop up from there to industry movement, recognizing how insignificant I am while having big goals for bettering software development. I write “algorithms” for these systems too, sometimes visualizing accurately where things will go, sometimes not. 

I’m OK with others not finding joy in what I consider an industry milestone. The feeling I get from your writing is as if you loath me or something I stand for. So, I don’t feel a need to convince you to see what I’m seeing as much as I feel a need to ask you if you are OK. I hope you can find joy in this Christmas season Kevin.  —Dawn

Sent from my iPad

On Dec 10, 2019, at 2:55 AM, Kevin Powick <kpo...@gmail.com> wrote:



--

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
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/8dfddc04-c40f-45de-a078-8a4c7cfbee99%40googlegroups.com.

[Dawn Wolthuis]

Brian — yes, I think you are correct re Microsoft working to play nice with others these days. Cosmos DB is Microsoft’s offering. It is in their stable. Now I’m watching how they position it. Many here can see that it competes with SQL Server to address many of the same use cases, but they have been careful not to suggest that very loudly. Building and deploying Cosmos DB was a bigger milestone. That is more obviously an industry change. Those using Cosmos DB violate some of Codd’s Rules, after all. 

We have seen various NoSQL failures, such as at Twitter (haven’t looked at that recently, maybe they are successfully using NoSQL now, but Cassandra was a problem at one point) and articles about how NoSQL slots into some “big data” category or social media or anything other than “NoSQL for business” in place of an RDBMS. NoSQL is clearly a threat to the RDBMS as DBAs have been pushing back, but they have had Microsoft, Oracle, Amazon, and IBM backing their RDBMS business choices in a big way.

The way NoSQL is riding back in (MV never having left) is on the cloud. Microsoft has a much bigger Azure message than SQL Server these days. They might have promoted Cosmos as an alternative to SQL Server for a business use case before, but this is the first promo I have seen of this nature. So, I’m seeing this as a pivot point worth noting, as an industry milestone I’ve been looking for in my work. 

Again, if others here do not find it the least bit interesting, this is the wrong audience (or I’m overly delighted by it). What I’ve found, however, is that there is an interest here in such topics even when not among those who speak up on the list. Thanks for your consideration.

—Dawn

Sent from my iPad

On Dec 10, 2019, at 1:42 AM, Brian Speirs <br...@rushflat.co.nz> wrote:



--
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
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/ac2dd6ab-99cb-40fa-be24-cdcd84c50091%40googlegroups.com.

[Kevin Powick]

Oh, Dawn.

A couple of gentle jabs at your self-congratulatory comments and that's your response?

The majority of my post was directly on topic, but from a slightly different perspective.  I've already acknowledged that NoSQL has its uses, and agree that industry heavyweights legitimize it further.  So, I'm unsure how you construe my post as some type of personal attack. 

<snip>

I had written a bit more, but you see any critique from me as an attack, so in the spirit of the season, Merry Christmas.

--

Kevin Powick

To unsubscribe, email to: mvd...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mvd...@googlegroups.com.

[Dawn Wolthuis]

Thanks Kevin. 

I was trying to congratulate all of us, the MV folks who stuck it out through the relational database era and now see the industry move in our direction. 

I like MV BASIC, but I don’t have as much affection for BASIC that those who have developed in it day in and out for years have given that I spent my heads down days in CICS. I was looking for preservation of the data model abstraction, although I would like to see business rules (existing code) be able to make the ride too. 

Seeing Microsoft name their product “Cosmos DB,” (“coincidentally” the name of the first MV company implementing MV on a Microsoft O/S) now giving enough insider info (I suspect) to a company like Chipotle that they SWITCH from SQL Server to Cosmos DB, gives me hope for the industry. I thought we could stop for a second and share a little industry celebration.

I know I trip some button of yours so that you feel a need to write responses to dim my joy, so thanks for tapping into the season for some joy even if not sharing the “NoSQL for business” excitement. Maybe we should do a zoom meeting sometime and “meet.” I’ve met Tony, and when he trips my buttons, I can just text him (and vice versa).

—Dawn

Sent from my iPad

On Dec 10, 2019, at 12:54 PM, Kevin Powick <kpo...@gmail.com> wrote:



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 Google Groups "Pick and MultiValue Databases" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/17677a65-22ef-49d4-96c9-bdfa19977b79%40googlegroups.com.

[Albert Kallal]

Well, if you folks are wondering where and what and why the folks at MS will use no-sql?

It is called share-point. And that system and offering from MS was one of their fastest products to reach 1 billion in sales.

the MV market is not driving the no-sql movement. In fact, it is web services, SOAP (Simple Object Application Protocal), and that of REALLY nice kick you know what search engine technology. There are even some using grapics cards in the same way that "everyone" who is serious about bit-coin mining is use parrellel abilitis of graphis cards?

We seeing a simple "bit-wise" searching systems now occurring on files - and they are again use graphics cards extensions (SMD functions). In other words some of the no-sql stuff is occurring due to new kinds of indexing being used for retrieval of data. The other area is NOT due to data, but SOAP and JASON etc. in which we pass objects around by HTTP. None of the pick architecture has this concept of passing PROGRAM objects as serialized strings of data and then un-corking them on the other end. 

While Pick/mv follows a XML like structure, it certainly not benefiting from the rise of web services in which code communication is occurring by these serialized objects. 

 If one adopts web based services and technology, the developers will be passing back and forth a lot of data, but between the web services and BEFORE the data layer that pick or MV systems EVER is reached. So, this movement away from a rigid table structure is NOT only data driven, but a means for web systems to talk to each other. It is THIS reason that is giving rise to the no-sql movement, and also that of new types of engines to index data (again, something that mv systems tend to not have or do at all (serialize and de-serialize objects).

In effect - I agree with you about no-sql, and it not MV systems that are driving Microsoft in any direction here - it all the other reasons for no-sql, but that's due to how web services work - not necessary the data system.

Regards,

Albert D. Kallal

Edmonton, Alberta.

[Tony Gravagno]

Donald - you've made some really excellent points and we're thinking along the same lines:

I've recently noted in these forums that I'm using QM with BASIC as a script engine, an alternative to JS, VBS, BASH SH, PHP, etc. By using the platform like just another component in the toolbox, the way people are using NodeJS these days, I'm hoping to define a set of patterns and use cases that will profile MV for applications outside of the traditional box that MV people see themselves in.

Zumasys understands what I'm trying to do. Rocket/TL/RD/PS never did. I've given them 20 years of encouragement to join the modern world and now I've given up on them. I'm still a D3 fan but it's not practical to let appreciation for a product stand in the way of industry growth or personal business growth. I need to look beyond the limitations of the owners of the D3 platform if I'm going to use MV in a broader context.

Your example with Foxbase is right on. That's an example of how people packaged an old product in a new way, and got an industry to see itself differently. In a way we see that in the JavaScript industry now, where people who started with client-only scripting have now extended themselves to the server. Some have not done that. Many people have started with JavaScript in the server and know nothing about client-side development. It's a new paradigm. We could do this with MV, many people onboard will fall off, and I would hope that with the proper approach to evangelism that many more will come aboard.

Cost is indeed a huge factor. The per-seat model comes from serial portals, centralized servers, and service bureaus based on user counts. The pricing model for databases needs to change from a user count to the load on the server - pay for how much the environment is being used, not how many people are connected to it (and logged in while they go to lunch). This needs to be coupled with the notion that we should be selling to more sites at a lower price, rather than looking to get big hits on individual sales. In short, flatten the model so that revenue is generated from a huge number of sources.

That's at the MVDBMS provider tier. My theme for this thread and my personal goal is about defining a use case where MV make sense technically, the cost is zero or a negligible cost of business, and there is clear and easy integration with other tiers. MV BASIC needs to be as approachable as PHP or JavaScript. Access to the MV database needs to be as seamless as SQL queries or common RDBMS connectors. Developers need to feel as comfortable with a LAMB stack as LAMP (Linux, Apache, MVDBMS, BASIC).

Randomly yours,

T

[Wol]

On 13/12/2019 17:54, Tony Gravagno wrote:
> Donald - you've made some really excellent points and we're thinking
> along the same lines:
>
> I've recently noted in these forums that I'm using QM with BASIC as a
> script engine, an alternative to JS, VBS, BASH SH, PHP, etc. By using
> the platform like just another component in the toolbox, the way people
> are using NodeJS these days, I'm hoping to define a set of patterns and
> use cases that will profile MV for applications outside of the
> traditional box that MV people see themselves in.

I'd like to use BASIC as a scripting engine too, but to my mind - if you
are using it as a database - it's an excellent object-relational
database. As people have said over the years, it's easy as a developer
to keep the database model in your head - the same model in relational
is just so much more complex.

And as I put it, you have emergent complexity where you can look at the
level that matters to you. With relational you're trying to explain how
a Rolls Royce works at the level of atoms and molecules - you can't go
up a level to simplify things.

>
> Zumasys understands what I'm trying to do. Rocket/TL/RD/PS never did.
> I've given them 20 years of encouragement to join the modern world and
> now I've given up on them. I'm still a D3 fan but it's not practical to
> let appreciation for a product stand in the way of industry growth or
> personal business growth. I need to look beyond the limitations of the
> owners of the D3 platform if I'm going to use MV in a broader context.
>
> Your example with Foxbase is right on. That's an example of how people
> packaged an old product in a new way, and got an industry to see itself
> differently. In a way we see that in the JavaScript industry now, where
> people who started with client-only scripting have now extended
> themselves to the server. Some have not done that. Many people have
> started with JavaScript in the server and know nothing about client-side
> development. It's a new paradigm. We could do this with MV, many people
> onboard will fall off, and I would hope that with the proper approach to
> evangelism that many more will come aboard.
>
> Cost is indeed a huge factor. The per-seat model comes from serial
> portals, centralized servers, and service bureaus based on user counts.
> The pricing model for databases needs to change from a user count to the
> load on the server - pay for how much the environment is being used, not
> how many people are connected to it (and logged in while they go to
> lunch). This needs to be coupled with the notion that we should be
> selling to more sites at a lower price, rather than looking to get big
> hits on individual sales. In short, flatten the model so that revenue is
> generated from a huge number of sources.

This is why we need an Open Source compiler/interpreter that can use
other data stores, or its own, as a back-end :-) That's why when I get
the chance I'll take another crack at doing a new MaVerick :-)

>
> That's at the MVDBMS provider tier. My theme for this thread and my
> personal goal is about defining a use case where MV make sense
> technically, the cost is zero or a negligible cost of business, and
> there is clear and easy integration with other tiers. MV BASIC needs to
> be as approachable as PHP or JavaScript. Access to the MV database needs
> to be as seamless as SQL queries or common RDBMS connectors. Developers
> need to feel as comfortable with a LAMB stack as LAMP (Linux, Apache,
> MVDBMS, BASIC).
>

To my mind, MV makes a lot of sense simply because it's much easier -
simpler - to comprehend. If the system discourages certain types of
programming mistake (without encouraging others :-) it improves
programming efficiency.

Cheers,
Wol

[Donald Montaine]

I just got a Raspberry Pi 4 kit (metal case, power supply, heat sinks) with a 1.5G CPU, 4 cores, 4G memory, 2 HDMI ports for $99.  It has more power than an MVBase server I saw in 1995 that was serving a whole room of data entry clerks.  I think it had a Pentium processor.

The computer is cheap, the OS is free.  I can conceive of uses using single user QM on workstations communicating with a QM server using QM Net as a way of communicating between stations, everything using Rasberry Pi based computers running on Ubuntu server or Raspbian OS.  What a great way for IOT devices to communicate with each other.  QM would be the perfect, very light weight data store for such a system.

Am I going to pursue it, no.  Why, cost;  a $116 / user license with $23 / user yearly support fees when I can use Firebird, Maria DB, or Postgresql for free (and that IS cheap compared to the other MV options).  If Zumasys really wants to capture new hearts and minds, release OpenQM for free on the Raspberry Pi.  Let people be creative and come up with great ideas that might eventually migrate to systems with more capacity.  I know they have a 5 user "Educational" version, but that it still not really competitive with the IOT market today.  As with all things MV, not enough to energize the market.

I am an old time Revelation, Pick, Universe, Unidata developer that does all my new work now using a Windows based SQL development system and pays $1500 per year for a subscription, because the system has no per user charges I have to pass on to my clients. If I was just doing PC based development the subscription would be $600 per year.  I don't do this because I want to, I do it because of the ridiculous per seat licensing fees that all the MV products charge.   How many passionate MV developers have left the fold because of the absolutely stupid approach to licensing?

And on the Pi, solutions without a GUI actually make sense, so QM would be a real option to connect with new, young developers.

Yep, if you want to just sell to existing MV users, or if you want to maintain old code written before structured programming techniques, then MV is the place to be.  But if your passion is solving new problems with original development, then MV just doesn't work any more, not because of the technology, but because of the pricing.

[MAV]

Exact. In environments like Raspberry pi, a special 5-user special license would be great. Very interesting.

Marcos Alonso Vega

INGESCO Sistemas Informáticos

[Patrick Payne]

At Zumasys we are reviewing some ideas around a free version of QM.  OpenSource models are very challenging and these sites are figuring out how to make money elsewhere or are moving to cost models or are being absorbed into larger hosting designs.  In addition, SQL server has some very confusing licensing models that many end shops are often violating (Meaning you are supposed to either have a CPU license or purchase an additional CAL license for each user, not concurrent user, but each named user).  Other free offerings such as Mongo have frozen the free version feature-wise and now offer enterprise support for advanced functions.  Others such as Mysql are being purchased by the big vendors.  Pick is also not just the database, it is also a file system and programming language which is close to a full-stack historically. 

We have a large customer that did a net-new application in jBASE which replaced an open-source SQL project.  The use case was perfect for MV and you can read about it here.   https://www.pickmultivalue.com/the-center-for-the-collaborative-classroom/  

[Wols Lists]

On 17/12/19 16:35, Patrick Payne wrote:
> At Zumasys we are reviewing some ideas around a free version of QM.
> OpenSource models are very challenging and these sites are figuring out
> how to make money elsewhere or are moving to cost models or are being
> absorbed into larger hosting designs.

The danger is the dishonest guys ... but one model that will not cost
you money (provided the other side is honest) is freebie home/personal
licences. Not the 30-day evaluation licence, but a permanent (maybe
single user) licence that says "free to play, free for home use, not for
business". I know Adobe, and MS, and that lot are trying to push users
into subscription licences, but Adobe have probably lost a LOT of
amateur photographers - I can't justify £20/month for their software -
not when I only take about 1000 photos a year, don't post-process them
much, and can't take advantage of cloud offerings because uploading a
24MP RAW image over my broadband is SLOOOOWWWWWW.

And I'm not going to pay £70 or whatever it is for Office 365 - not when
I can buy a legit 2019 Pro for £20 or so :-)

Cheers,
Wol

[geneb]

On Tue, 17 Dec 2019, Patrick Payne wrote:

> We have a large customer that did a net-new application in jBASE which
> replaced an open-source SQL project. The use case was perfect for MV and
> you can read about it here.
> https://www.pickmultivalue.com/the-center-for-the-collaborative-classroom/
>

Out of curiosity, what was the user interface written in?

tnx.

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

[Patrick Payne]

AngularJS talking to jAgent/MVConnect into jBASE.  All the JSON work was done with jBASE dynamic objects in jabba. https://docs.jbase.com/42948-dynamic-objects/dynamic-objects-tour?from_search=39800208

[geneb]

On Tue, 17 Dec 2019, Patrick Payne wrote:

> AngularJS talking to jAgent/MVConnect into jBASE. All the JSON work was
> done with jBASE dynamic objects in jabba.
> https://docs.jbase.com/42948-dynamic-objects/dynamic-objects-tour?from_search=39800208

Thanks for the info Patrick.

I'm having a difficult time understanding how a browser-based interface
would be appropriate for anything but the most simple of tasks. Thick
clients are my primary focus and maybe that's coloring my view of it...

[Patrick Payne]

That is no longer the case.  HTML5 with javascript can create SPA apps that can duplicate most of what a desktop app can.  Google docs is a great example. Another great example is Visual Studio Code which is an HTML/Javascript app that runs within an Electron container (self-contained Chromium engine).  The biggest change is UI design which today favors building screens that are Mobile friendly.  There is nothing stopping you from building screens with absolute positioning that looks and feels much more like a desktop app.

[Albert Kallal]

I'm having a difficult time understanding how a browser-based interface
would be appropriate for anything but the most simple of tasks.  Thick
clients are my primary focus and maybe that's coloring my view of it...

Well there is  quiet revolution occurring here. I mean, most software for Android phones is based on writing XML markup.

So you can write hand coded c++ for high speed performance. And given that a $80 dollar snap dragon processor has 4 cores running at 1.4 ghz?

Well, a pick box running a 486 at 66mh could handle 30 users. One of those 4 cores is 1.4 ghz. (so 1400 mhz). that is 21 times! And you have 4 cores!

So that smartphone has 80 times that 486.

Ok, but Google spent huge dollars on a JIT. (just in time compiler). The result? Well, JavaScript is kind of like writing a Pick PROC. They are slow, interpated, not compiled, and much slower then say even Pick BASIC. (which can native compile).

So, Google spent HUGE dollars on a that HTML + JavaScript compiler. The result is NOW that JavaScript runs FASTER then hand code native compiled c++ code!

In other words, the phone eventually compiles and runs that web based JavaScript code as 100% native raw ARM based assembler code. So you can write little scripts and use markup to build and write a Android phone application, and the speed of execution of that application is now that of desktop software - and in fact better then most such software (because of the 10's of millions spend on the JIT).

For all but the most demanding software (graphics and video editing), we find:

The web interface has MORE toolbox options. (nice picture sliders, nice drop down boxes, dynamic boxes for entering text, and viewing pictures. combo boxes that display pictures along with choices. The choice of UI tools for the web is now MUCH better.

As a result, as a designer, I NOW have more options for UI, a better UI. 

And guess what? Web Browsers now have JIT's. They even accelerate rendering with your graphics card.

The result is say with google docs, the word processor or the spreadsheet runs as well as desktop versions of that software. 

I am now finding that my web applications actually respond better, feel better, look better and run faster then my desktop applications that I write!!

You can go from simple:

Here is a pacman game:   

https://www.webpacman.com/pacman-html5.php

You have to hit a key or space bar to start it.

However, even more interesting this is on-line visio (diagramming) tool:

https://www.draw.io/

Try creating a few diagrams. It works as good as any desktop diagramming tool, but zero installs.

The simple matter is that with the rise of HTML5, then browsers can quite much run any kind of software you would run on your desktop. As noted, about the only exception is large video editing, but EVEN THAT is starting to get better, and with a huge server farm then you are now actually able to better edit and process some types of video better on-line then off line local.

There is a quiet revolution occurring here, and that revolution is speed of browsers - they are now able to run and render things as good if not better then desktop programs.

But MORE important is the design tools to create UI's are resulting in a far more fluid type of interface. One that flows, has more dynamic display widgets. Windows desktop quite much has text box, combo box and a few more. Sure they cook up new bits and parts now and then, but it takes a LONG time for such new widgets to make their way say into .net or Visual Studio.

With the web? It is occurring in real time. So frameworks like bootstrap and others are rising up, and giving developers not only MORE choices for UI, but in fact these choices run faster and work better then their desktop rivals.

Just 10 or even 7 years ago? 

Web applications:  great for simple data entry forms.

Now:

They are BETTER then desktop applications.

No question that a class of high bandwidth applications still will prefer the desktop, but even those are starting to give way to browser based.

Why download some huge video to edit it? Edit that video on some huge server farm that does all the work with a HUGE warehouse of servers crunching away.

The desktop is not dead, but if you ever seen a REALLY nice new application written with all the latest web tools? They run circles around desktop versions, and they actually provide a nicer, faster, and more response UI experience then even what the desktop offers.

Regards,

 

Albert D. Kallal

Edmonton, Alberta Canada

 

[geneb]

On Tue, 17 Dec 2019, Patrick Payne wrote:

> That is no longer the case. HTML5 with javascript can create SPA apps that
> can duplicate most of what a desktop app can. Google docs is a great
> example. Another great example is Visual Studio Code which is an
> HTML/Javascript app that runs within an Electron container (self-contained
> Chromium engine). The biggest change is UI design which today favors
> building screens that are Mobile friendly. There is nothing stopping you
> from building screens with absolute positioning that looks and feels much
> more like a desktop app.
>

Well if nothing else, I have more to look into. I don't think I can be a
fan of "mobile" until 8" screens are standard. :)

Thanks Patrick.

[Wols Lists]

On 17/12/19 20:13, Albert Kallal wrote:
> Why download some huge video to edit it? Edit that video on some huge
> server farm that does all the work with a HUGE warehouse of servers
> crunching away.

Not to rain on your parade, but if I've shot that video myself, I don't
want to wait a week while my ADSL2 broadband struggles to UPload said
video for editing ... :-)

Yeah the technology is brilliant, but sometimes (most of the time?) I
feel like the evangelists are sales-people who don't actually have a
clue about the practicalities of what they're selling - run a
word-processor on your 5" phone screen? No thanks!

Cheers,
Wol

[geneb]

On Tue, 17 Dec 2019, Albert Kallal wrote:

>
>>
>>
>> I'm having a difficult time understanding how a browser-based interface
>> would be appropriate for anything but the most simple of tasks. Thick
>> clients are my primary focus and maybe that's coloring my view of it...
>>
>>
> Well there is quiet revolution occurring here. I mean, most software for
> Android phones is based on writing XML markup.
>

Hand-crafted XML UI interfaces are how alcoholics are made. ;)

> So you can write hand coded c++ for high speed performance. And given that
> a $80 dollar snap dragon processor has 4 cores running at 1.4 ghz?
>
> Well, a pick box running a 486 at 66mh could handle 30 users. One of those
> 4 cores is 1.4 ghz. (so 1400 mhz). that is 21 times! And you have 4 cores!
>
> So that smartphone has 80 times that 486.
>

That's incredibly simplistic and not comparing like-load to like-load.
Interactive terminal sessions are very light weight. That being said, I
know the point you're trying to make.

> Ok, but Google spent huge dollars on a JIT. (just in time compiler). The
> result? Well, JavaScript is kind of like writing a Pick PROC. They are
> slow, interpated, not compiled, and much slower then say even Pick BASIC.
> (which can native compile).
>

Well no, writing JavaScript is like being trapped in a never ending loop
of The Shining. ;) I've written JS code before and it's the closest thing
I'll ever come to PTSD. (Well save for having to hack on sendmail
configuration files, but I've blotted most of that memory out. ;) )

> So, Google spent HUGE dollars on a that HTML + JavaScript compiler. The
> result is NOW that JavaScript runs FASTER then hand code native compiled
> c++ code!
>

Now this is pure nonsense. JavaScript, even JIT compiled has a lot more
instructions to execute for the same construct than C++ does, primarily
due to the JS->JIT process. Just because Google lit a few billion dollars
on fire to help Android doesn't make JS or Dalvik as fast as code compiled
to run on native iron.

> For all but the most demanding software (graphics and video editing), we
> find:
> The web interface has MORE toolbox options. (nice picture sliders, nice
> drop down boxes, dynamic boxes for entering text, and viewing pictures.
> combo boxes that display pictures along with choices. The choice of UI
> tools for the web is now MUCH better.
>

As a user of both Davinci Resolve and Adobe Premiere Pro, I call
shenannigans. A full non-linear editing suite running in a browser is (at
least for now) a fever dream.

> As a result, as a designer, I NOW have more options for UI, a better UI.
>

How do those tools compare to Visual Studio and Delphi/C++ Builder's UI
tools? (Or even Qt for that matter.)

> And guess what? Web Browsers now have JIT's. They even accelerate rendering
> with your graphics card.
>

I'm well aware of that. (google "internet archive emularity")

> I am now finding that my web applications actually respond better, feel
> better, look better and run faster then my desktop applications that I
> write!!
>

What were you writing desktop applications in? What do you write
browser-based applications in? (the tools, not the language)

> However, even more interesting this is on-line visio (diagramming) tool:
>
> https://www.draw.io/
>
> Try creating a few diagrams. It works as good as any desktop diagramming
> tool, but zero installs.
>

And all your work is gone and you're completely screwed when the company
folds or is shredded by a buyout or accquihire.

> There is a quiet revolution occurring here, and that revolution is speed of
> browsers - they are now able to run and render things as good if not better
> then desktop programs.
>

A browser IS a desktop application. ;)

> But MORE important is the design tools to create UI's are resulting in a
> far more fluid type of interface. One that flows, has more dynamic display
> widgets. Windows desktop quite much has text box, combo box and a few more.
> Sure they cook up new bits and parts now and then, but it takes a LONG time
> for such new widgets to make their way say into .net or Visual Studio.
>

You should investiate the Infragistics NetAdvantage product sometime.
You'd be surprised.

> Now:
> They are BETTER then desktop applications.
>

Maybe eventually, but not based on what I've seen.

> The desktop is not dead, but if you ever seen a REALLY nice new application
> written with all the latest web tools? They run circles around desktop
> versions, and they actually provide a nicer, faster, and more response UI
> experience then even what the desktop offers.
>

I've seen absolutely nothing that supports this assertion, but I'd love to
learn more.

[geneb]

So you're saying that entering a 200 line product order on your phone is a
no-go? ;)

[Wols Lists]

On 17/12/19 21:37, geneb wrote:
> On Tue, 17 Dec 2019, Wols Lists wrote:
>
>> On 17/12/19 20:13, Albert Kallal wrote:
>>> Why download some huge video to edit it? Edit that video on some huge
>>> server farm that does all the work with a HUGE warehouse of servers
>>> crunching away.
>>
>> Not to rain on your parade, but if I've shot that video myself, I don't
>> want to wait a week while my ADSL2 broadband struggles to UPload said
>> video for editing ... :-)
>>
>> Yeah the technology is brilliant, but sometimes (most of the time?) I
>> feel like the evangelists are sales-people who don't actually have a
>> clue about the practicalities of what they're selling - run a
>> word-processor on your 5" phone screen? No thanks!
>>
> So you're saying that entering a 200 line product order on your phone is
> a no-go? ;)
>

With my fat fingers, I can't see myself getting past the first TWO lines
without messing up, let alone 200 :-)

Cheers,
Wol

[Albert Kallal]

--  same construct than C++ does, primarily due to the JS->JIT process.  Just because Google lit a few billion dollars on fire to help Android doesn't make JS or Dalvik as fast as code compiled to run on native iron.

--

Well, in many cases it does!

The JIT has very efficient memory subsystems and garbage collection that can be MORE efficient then a c++ programmer explicit doing this with their own code freeing up that stack.

I mean, most computers can play chess better than humans.

And the JVM + JIT can do dynamic analysis at runtime, and thus make better decisions then a pre-compiled bit of code. So as the application runs it can figure out what parts need love and care, and then take corrective actions – that’s something pre-compiled code systems can’t do.

 

And of course different processors support different SSE extensions etc., and again a JIT can utilize these extra features where as a c++ has to compile to the lowest common denominator. (But then again, that’s a different argument here). But as we march towards different devices of all kinds? Then this point actually becomes VERY important. It means investment dollars will flow into this area over that of c compilers, because that’s where the benefits are to be had. So, you write code, and it runs on all kinds of different devices, EACH with special optimizing that a pre-compiled system can’t match. So for embedded, it will not optimize UI parts for example.

 

Now to be fair? Yes, hand optimized c code will be faster and faster in most cases. But it NOW not a given. That’s whole point I am making here that these JIT’s change everything.

 

So will a JIT always beat c code? No, of course not.

 

For android 5, C code would typical beat Js by about 38%, and in some cases much more (much more!).

 

Now for android 6, that margin drops to 3% in many cases. And in some cases we see the js running faster

And android 7 gets even better again!

You can see where this is going!

The layers they are creating AFTER the source and instruction sets are where this is going. You think the x86 inturction set is what results in the stunning performance of desktop CPU’s? (no!!).

So js can beat C in some cases right now, and the margins of difference are becoming smaller EACH day as I write this.

 

This is kind of like RISK vs CISC processors. Eventually both sides started layering pipelines and stuff on top – they both would up at near the same spot in the end. So on top of the x86 instruction set they built huge bits a parts that pipeline that code. And the RISC folks wound up doing the same thing (that layer after the standard instruction set is what did all the magic here in terms of performance). They both would up with a layer on top of their respective instruction sets that looks VERY similar.

 

So sure, in most cases, yes I would give the edge to C, but the gap has become very small, and in some cases we see the JIT + js doing better than the c code.

See this article:

https://www.androidauthority.com/java-vs-c-app-performance-689081/

 

--  What were you writing desktop applications in?  What do you write

 

--  browser-based applications in?  (the tools, not the language)

 

Both cases, Visual Studio. Long time user.

The browser issue comes down to what AJAX tools you use. (Telerik ones here are great:

I mean launch this page:

 

https://demos.telerik.com/aspnet-ajax/diagram/examples/overview/defaultcs.aspx

 

Now drag a item on the screen?

 

Try this grid:

https://demos.telerik.com/aspnet-ajax/grid/examples/overview/defaultcs.aspx

 

And there are other frame works that are even better then above. But I do like Telrik tools.

 

-- I've seen absolutely nothing that supports this assertion, but I'd love to

 

I assume the context is desktop experience vs web (not issues of deployment).

Yes, I am starting to see rich line of business applications that due to the web interface result in a BETTER interface then desktop software. This is due to the UI choices, and the rise of better tools. The rate at which we see new UI options appearing for web is outstripping what the API’s and offerings and choices we have as developers on the desktop. The desktop model and choices can’t move as fast as what is occurring in web land.

 

--  As a user of both Davinci Resolve and Adobe Premiere Pro, I call shenannigans.  A full non-linear editing suite running in a browser is (at least for now) a fever dream.

--

 

No not at all. People view HD video content at 30 or higher frame rates all the time. What do you think pay per view cable boxes do?

 

To jump around key frame video, you hardy needing more then 30 frames a second. With new SSD extensions to processors, then you can easily jump around in video. And when you cut + paste a video segment, you not actually cutting the binary file – but only the start and end frame. That server going to have a larger raid drive and bandwidth on THEIR end then most desktop computers – except for a high raid local hard drive (a expensive custom setup). But you not transferring the video file back and forth – only editing and picking parts and looking at key frames. Everyone streams video content right now – the frame rates we see are VERY fine for this task. And when you tell it to render the final video? Well, it “already” on the server – you don’t have to up-load it anymore, do you?

 

In fact that we even debating that video editing is possible based on a client to server setup is already a crazy concept!

 

All I am saying here is there is a quiet revolution occurring.

 

For “most” line of business applications, the web can now provide as good or in fact a better user experience. That alone is a stunning occurrence in our industry.

 

The desktop paradigm is not going away anytime soon. But even just 5+ years ago? I would have flat out stated that desktop systems are not only faster for most applications but ALSO provide a better user experience. I can’t say that anymore!

 

Regards,

Albert D. Kallal

Edmonton, Alberta, Canada

[Albert Kallal]

No need to get silly here. No one is suggesting, hinting or implying such a idea.

What you do is put your phone down on your table,and your 40 inch screen on the wall will turn on, fire up what you were last doing at work, and you can continue doing whatever it was before.

This is not about small form factors. Any video device will recognize your face, turn on and allow you do continue working. Heck you not even need your phone or wallet anymore.

You walk into a store, grab a shirt, and as you walk out, wave hello to the kisok that will flash up the cost of what you are walking out of the store with.

So, you not even use you phone or carry your wallet with you - but walk up to any large display - and just start working. 

R

Albert

[Bob Markowitz]

The rise of modernity as applied to MultiValue.  Thanks Albert for mentioning Telerik, it is a hell of a product.  It is also a low-code platform.  You know what?  It doesn't work with MV.  You know what does?  Evoke.  Evoke does what Telerik does, they do it their way and we do it ours.  Evoke designs generate Visual and Xamarin Studio projects that are delivered to the developer's computer that includes standardized technologies - not proprietary.  Whatever component libraries and languages that are supported by the latest versions of VS can be included in an Evoke project.  Evoke eliminates the need tor MV developers to understand much of today's technologies to deliver amazing apps.  Create it once, have it adapt as web or native on all (most) devices, desktop and mobile, Android, iOS and Windows - the developer's choice. And Evoke created apps are fast. And of course you wouldn't create a mobile app that mirrors a desktop for data entry BUT you could adapt the desktop app to mobile for the important stuff.  Absolute positioning, gimme a break.

[izzizman]

Here we go again ! [AD][Start Bob]....Blah, Blah, Blah !!!.....Give us a trial Month by Month if you want us to try ! [End Bob[End AD]...

--

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
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/35525baa-46a3-4a1b-b6e9-30daab11c941%40googlegroups.com.

[Dawn Wolthuis]

Agreed. We have moved 

--from green screen 

--through the screen scraper GUI era, 

--then beyond the previous thick client user-must-keep-it-current desktop approaches, 

--and we are now firmly into web/mobile for the UI, 

--with optional evergreen desktop (typically using Electron or a Microsoft XAML approach)

We are still in search of single-sourcing the UI/UX code, which is one of the reasons for the rise of "low-code" application tools -- they can take in a higher level spec and produce code for each relevant platform from their non-standardized, proprietary, sometimes-only-GUI-editable specs. This is a good way for some "end customer" companies to go, but not as likely to be a good scenario for a software company, an ISV, unless they are already married to C#-related Microsoft developer approaches, expecially ASP.NET.

We can get close on the open source side with

Web: Svelte, Vue, React, Angular (skipping jQuery-centric approaches for better SPA UX and maintainability over time)

Mobile Web: Progressive Web App libraries for mobile experience (not identical to the native experience, but there are pros and cons)

Desktop: Electron (like Slack, Discord, and many other contemporary apps with a desktop version)

Native phone apps are an unfortunate complexity. With no really great way to share the same application source code (even between the iPhone and Android devices), but with a similar stack, there is:

Native: React Native, Vue Native (wrapper around React Native IIRC)

I'm not reading a lot of positives regarding these native libraries, but there are pros and cons compared to Xamarin (Microsoft) or Flutter (Google), two of the other ways to do cross-platform native.

CSS

Application developers too often relegate "the look" to designers coding css, thinking it can be "added on" rather than building in a clean design from the start (that can then be tweaked by graphic designers if needed). I've made this mistake. It is still not easy to develop top tier UX and UI design, especially if there is no graphic designer from the start of the project. There have been several CSS pre-processors (scss, sass, less, stylus, ...) and now there is a css post-processor emerging as one of the winners in the css arena, slipping into the bootstrap space, it seems -- tailwindcss. I don't see a good way to get material design controls without scss (a pre-processor), but I would like to switch to css in Svelte or Vue components and tailwind as a post-processor. Right now, I can get good UX/UI from Vue with nuxt and vuetify popping right out of the box, using a pre-processor. I haven't been as successful with that for Svelte and Sapper out of the box, skipping the pre-processor and attempting to just use tailwindcss (post-processor). I haven't given it enough time to fully focus on it, so take that as the results of a "shallow dive."

I don't see a slam dunk here, but I'm hoping that Svelte will get the type of backing it needs to compete with Vue and that both will be competitive with React and Angular. For a while, many were on the ASP.NET bandwagon, with XAML/Xamarin. There are vast numbers of developers married to that camp, so the open source approaches might be best for those who do not already have a horse in the race. The ASP.NET folks will stick with C#, XAML, Xamarin for a while, I'm guessing, even though for their own internal projects, Microsoft has used React and such (with their Cosmos DB NoSQL DBMS too!).  

In any case, notice how Java has slipped into the "legacy" realm these days? [That's my "poke the lion" statement to close. I'll could pick on Python too, when talking about UI/UX, but it is still trending up, in spite of developers now trying to figure out how to get it to the browser by transpiling to JavaScript]  

smiles. --Dawn

Dawn M. Wolthuis President, Tincat Group, Inc. 616-901-6293 | dw...@tincat-group.com 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
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mvdbms/53176086-52d6-4ecc-afe2-3c125af56b83%40googlegroups.com.

[Albert Kallal]

 Telerik's offerings will certainly work with MV systems. Assuming you have a connection layer and mapping to a MV system.

All Telerik is offering is a nice bunch of AJAX enabled tools that replace a lot of the native asp.net web controls (and a nice bunch of extenders).

The only issue then becomes say how will you fill a grid or form on a screen? The approaches used in net are 100% the same when using Telerik tools, or even more popular are the offerings from Dev-express (they again have a great set of tools).

The only issue then is how will one map data from MV systems into that .net application.  There nothing that suggests once some mapping from MV to a relational model has occurred, then the standard tool box or Telerik wig gits can be dropped into those forms.

The ONLY reason why Evoke don't support these tools is because they created their own custom web forms builder, and thus you are limited to their tools in for that form. So this would be like say "screen-gen" for Pick vs the other popular one (can't remember  the name right now system-builder???).

Spending 10 minutes poking around their site? Gee,  Evoke is a VERY nice RAD developer tool. So just like popular desktop tools like FoxPro, or MS-Access, they had their own custom user interface and forms builders. 

asp.net is not really a rad tool (like FoxPro or say MS-access). So you wind up coding + writing out forms. However, .net certainly has "some" of the RAD parts.

So you can  toss in a bunch of AJAX tools and widgets and extenders (like from Dev-express or Telerik), the results are very nice - but still not on par with a RAD environment. So, Telerik tools are mostly widgets -  you still be wiring up forms and code. (but, with the data set designer, or now entity frame works - both very similar in how they work), then the work of data binding into web forms is VERY much reduced, and thus again we are a big step closer to asp.net being more of a RAD tool - but not full RAD. Coding out CRUD (a application with lots of forms is still too expensive in regards to web applications right now).

So just like in pick land? Well, some coded up their screens in data basic, but for a lot of pick applications, one adopted ScreenGen or one of several popular screen builders like system-builder etc. to create those green screen applications. it just not practical to code up tons and tons of forms, be it in pick land, or web land.

I VERY much accept that Evokes strong points are a pick friendly interface, a pick friendly environment, and a fast + easy forms builder. 

However because they are using the net data providers, then introducing say some grid or option from other vendors is certainly a future possibility.  I don't know if he Evoke forms are asp.net forms, or MVC forms. However, my spider sense suggests they work much like how say screen-builder or other builders for pick worked. (it is a array/list structure of lables, text boxes etc. saved in a file, and then code draw out that screen for you based on the defines in that file.

How such tools work in windows land, or pick land are much the same. The only issue for such tools is can you introduce 3rd party tools?

However, the data layer (after spending 5 minutes on Evoke's site) is the standard .net layer. (so all of the standard .net data objects are used in Evoke).

That bodes well for writing the business layer code, or using existing pick code.

I like what I see in Evoke a lot - just after 10 minutes of reading. You not limited to MV systems. It looks to be a really nice web RAD tool. Looking at the HUGE popularity of FoxPro, and even more so tools like ms-access? Well, we really - but really really need the same idea for the web.

I just think for a forms rich environment, coding up forms in old pick days, or coding up web forms is simply a VERY poor approach to web development. And systems like Access were great since you did not spend all that time learning to create a form, but build a form and then attach code to that form builder. 

I going to take a closer look at Evoke, as I can think of a number of sites (sql server based) were we could use such a nice rad tool. 

I am actually kind of sold on Evoke already. I been searching for a great rad tool - but one based and built around industry standards.

However, I am busy right now!!! - but this is MOST certainly on my to-do list. I been looking for  a RAD web tool, funny how this might be a gold nugget find, and one in a MV group to boot! The web stacks are really a huge plate to digest, and in most cases overwhelming for one developer.  We need a great RAD web tool 

I going to look into this since their product plays nice with Sql server. 

Regards

Albert D. Kallal 

Edmonton, Alberta Canada

At the top most in net we have several data providers.

oleDB - starting to go out of fashion

ODBC - still a rather strong and popular choice.

.net sqlprovider - likly the most common.

After the above data provider choices, then the next level in .net is the SAME for all the above.

So, datatable, dataset, datarow etc. are platform neutral.

This tends to mean and suggest that we wind up mapping data from MV systems into the "base" .net data object types. This is imporant, since THEN these base data types are what feeds the asp.net controls. So, if I use listview, datagrid from .net, or from Telerik or Dev-express? Well they all work because they work on the common above "base" data objects we have in .net. Those data objects don't change - only the "providers" at one level above change. 

So, while it can be some work, but if you swap out a data provider in .net, then all of the code and more imporant the data objects at the level below are what near all toolbox offerings from companies creating widgits and tool offerings work on. In a way, those vendors are offering a  simular concpet as to what we used for windows development (ActiveX).  So you might purchase some spinners, or sliders or some grid or treeview control. 

[Albert Kallal]

That last bit after my sig was a cut + paste error on my part - no big deal.

R

Albert

[Donald Montaine]

Postgresql is open source, licensed under the Postresql license, which does not have the copyleft limitations of the GPL. It is free for both commercial and open source work and they have made a commitment that it will stay that way.  Whatever other DB vendors are doing, Postgresql will be your competition.  Heck, even Amazon is dropping Oracle for their own internally developed database which is based on Postgresql.

"The PostgreSQL Global Development Group remains committed to making PostgreSQL available as free and open source software in perpetuity. There are no plans to change the PostgreSQL License or release PostgreSQL under a different license."  <from the Postgresql site>

I think the Pi version should be free without limit and without support  It should be the place where you get developers "hooked" on the system.  You could make it so that the QM net feature for the Pi only works with other Pi servers.  If they want to connect a Pi to a Linux or Windows server, then there is a fee.   When they want more capabilities using larger hardware, then they start paying.  In any case, just drop the per user fee.  Charge by the OS level, the number of cores, the CPU level, the included modules or by the support level or whatever for larger systems.  

[Bob Markowitz]

Hi Albert - thanks for looking at the Evoke website.  Please let me know when you would like a demo.  We would be most happy to present a one-on-one.  Heck, if the group thinks that a demo for this whole crowd would be of interest or just some more one-on-ones also please let me know.  We do welcome comments and opinions - especially after someone has seen Evoke in action.

May some of you have a very Merry Christmas.  And may some of you have a Happy Hanukkah.  And may we all have a happy, healthy and prosperous New Year!  Please take a look at Evoke, it couldn't hurt!!!

[Tony Gravagno]

On Friday, December 13, 2019 at 1:10:03 PM UTC-8, Wol wrote:

This is why we need an Open Source compiler/interpreter that can use
other data stores, or its own, as a back-end :-) That's why when I get
the chance I'll take another crack at doing a new MaVerick :-)

I think you're describing OpenInsight ... and jBase ... and MVON (Express)?

But take a step back. MV isn't "a thing" here in this industry just because of the compiler. We navigate with TCL. We use Dict items and sometimes Procs. The verbs help us to manipulate the environment. Phantoms and other subsystems help to complete the picture. It's a full DBMS, not just a database, and not just a language.

As to MaVerick, I don't have faith that a new platform will have much success. Of course there is new stuff springing up all the time and having great success. But if MaVerick or ScarletVME or some other platform is under the umbrella of the MV industry then I fear it will be subject to the same challenges as all other MV platforms : lack of drive and initiative in the community, few resources for information, low-traffic forums, very little excitement. Sorry to rain on our parade but these Are our challenges - and some of the reasons why I started this thread.

T

[Wols Lists]

On 24/12/19 18:36, Tony Gravagno wrote:
>
>
> On Friday, December 13, 2019 at 1:10:03 PM UTC-8, Wol wrote:
>
> This is why we need an Open Source compiler/interpreter that can use
> other data stores, or its own, as a back-end :-) That's why when I get
> the chance I'll take another crack at doing a new MaVerick :-)
>
>
> I think you're describing OpenInsight ... and jBase ... and MVON (Express)?
> But take a step back. MV isn't "a thing" here in this industry just
> because of the compiler. We navigate with TCL. We use Dict items and
> sometimes Procs. The verbs help us to manipulate the environment.
> Phantoms and other subsystems help to complete the picture. It's a full
> DBMS, not just a database, and not just a language.

As I understand it, the bulk of INFORMATION was written in BASIC. That
was my original aim - to do the absolute minimum in other languages like
C etc, and enable other people to write all the verbs, etc. If I've got
a BASIC compiler, I can write TCL using BASIC. I can write LIST using
BASIC. Etc etc.

>
> As to MaVerick, I don't have faith that a new platform will have much
> success. Of course there is new stuff springing up all the time and
> having great success. But if MaVerick or ScarletVME or some other
> platform is under the umbrella of the MV industry then I fear it will be
> subject to the same challenges as all other MV platforms : lack of drive
> and initiative in the community, few resources for information,
> low-traffic forums, very little excitement. Sorry to rain on our parade
> but these Are our challenges - and some of the reasons why I started
> this thread.
>

Then we need to get it working, and advertise it on other forums. I'm
active (at a low level) on the LibreOffice development channel. Likewise
on LWN. I'm quite happy to try and get some exposure (and write articles
for) our UK linux print magazines. I'd emphasise the NF2 nature, and how
easy it is to work with. Pull in people who want to have a personal
database.

If it's a freebie (which is an important bit) and self-contained, then
we get back a bit towards the days of kids playing with BASIC on their
Ataris, Commodores etc.

And I'd like to put some stuff in so that we can "print" to a
LibreOffice document, to make it relevant to them, and other stuff if
people have ideas ...

Basically, if we have something we can advertise OUTSIDE of the MV
forums, that actually works, we might be able to bring in new people...

Cheers,
Wol

[Tony Gravagno]

Dawn - Before I start here - My notes are inspired by you, but this is not about you.

I'm one of the people here who made a business model of Researching technology and then using it for Development (Nebula R&D, get it?). But all of this ongoing rhetoric about technology drives me nuts. Certainly we enjoy sharing notes of value with colleagues, helping one another to find our way. But some actually do find their way and others just keep talking about options.

In this industry people spend a lot of time looking for the perfect technology to put a GUI on their one application. There's so much commentary, with careful inclusion of all of the right buzzwords and competitive points that really don't matter much to the people who are actually focused on making things work. MV people philosophize over technology from its first buzz until its last breath, not actually using it, just talking about it. In the meantime, other applications spring up, dominate, put these MV people out of business, and then fade away and get replaced by the Next big thing.

Just. Pick. One. I've been saying that for over 20 years now. They all work. People are using all of them for something and there is no end to support for any one platform. You will never find the "right" tech because they are all right. If you don't pick one, you will remain here forever, debating how none of it is as good as the BASIC of R83.

I think Many of the people who we hear from less often, or not at all, are those who Did pick some tech, ran with it, and now they don't feel a need to be in these forums anymore. They've accomplished the goal, got what they needed, actually used some tech to do what they wanted. It is quite likely that after you write your first great production offering that you will look back at the challenges and then look forward to other options for less pain and more profit. But you will be doing so using revenue generated from what you used. Compare this to going out of business from not having done anything but second guessing every option that becomes available over time.

Carpe Diem - Sieze the (technology of the) day. This is how the moving train of technology solutions works. You don't wait for the train to stop so you can hop on and find a comfortable seat, or for it to stop so you can hop off for lunch and then get back on. The train doesn't stop. You just need to jump. Learn from those who have done this.

And when you have found some technology that you like, come back here so that we can talk about the MVDBMS.

T

On Wednesday, December 18, 2019 at 1:45:40 PM UTC-8, Dawn Wolthuis wrote:

Agreed. We have moved 

--from green screen 

--through the screen scraper GUI era, 

--then beyond the previous thick client user-must-keep-it-current desktop approaches, 

--and we are now firmly into web/mobile for the UI, 

--with optional evergreen desktop (typically using Electron or a Microsoft XAML approach)

We are still in search of single-sourcing the UI/UX code, which is one of the reasons for the rise of "low-code" application tools -- they can take in a higher level spec and produce code for each relevant platform from their non-standardized, proprietary, sometimes-only-GUI-editable specs. This is a good way for some "end customer" companies to go, but not as likely to be a good scenario for a software company, an ISV, unless they are already married to C#-related Microsoft developer approaches, expecially ASP.NET.

We can get close on the open source side with

Web: Svelte, Vue, React, Angular (skipping jQuery-centric approaches for better SPA UX and maintainability over time)

Mobile Web: Progressive Web App libraries for mobile experience (not identical to the native experience, but there are pros and cons)

Desktop: Electron (like Slack, Discord, and many other contemporary apps with a desktop version)

Native phone apps are an unfortunate complexity. With no really great way to share the same application source code (even between the iPhone and Android devices), but with a similar stack, there is:

Native: React Native, Vue Native (wrapper around React Native IIRC)

I'm not reading a lot of positives regarding these native libraries, but there are pros and cons compared to Xamarin (Microsoft) or Flutter (Google), two of the other ways to do cross-platform native.

CSS

Application developers too often relegate "the look" to designers coding css, thinking it can be "added on" rather than building in a clean design from the start (that can then be tweaked by graphic designers if needed). I've made this mistake. It is still not easy to develop top tier UX and UI design, especially if there is no graphic designer from the start of the project. There have been several CSS pre-processors (scss, sass, less, stylus, ...) and now there is a css post-processor emerging as one of the winners in the css arena, slipping into the bootstrap space, it seems -- tailwindcss. I don't see a good way to get material design controls without scss (a pre-processor), but I would like to switch to css in Svelte or Vue components and tailwind as a post-processor. Right now, I can get good UX/UI from Vue with nuxt and vuetify popping right out of the box, using a pre-processor. I haven't been as successful with that for Svelte and Sapper out of the box, skipping the pre-processor and attempting to just use tailwindcss (post-processor). I haven't given it enough time to fully focus on it, so take that as the results of a "shallow dive."

I don't see a slam dunk here, but I'm hoping that Svelte will get the type of backing it needs to compete with Vue and that both will be competitive with React and Angular. For a while, many were on the ASP.NET bandwagon, with XAML/Xamarin. There are vast numbers of developers married to that camp, so the open source approaches might be best for those who do not already have a horse in the race. The ASP.NET folks will stick with C#, XAML, Xamarin for a while, I'm guessing, even though for their own internal projects, Microsoft has used React and such (with their Cosmos DB NoSQL DBMS too!).  

In any case, notice how Java has slipped into the "legacy" realm these days? [That's my "poke the lion" statement to close. I'll could pick on Python too, when talking about UI/UX, but it is still trending up, in spite of developers now trying to figure out how to get it to the browser by transpiling to JavaScript]  

smiles. --Dawn

On Tue, Dec 17, 2019 at 2:13 PM Albert Kallal wrote:

I'm having a difficult time understanding how a browser-based interface
would be appropriate for anything but the most simple of tasks.  Thick
clients are my primary focus and maybe that's coloring my view of it...

Well there is  quiet revolution occurring here. I mean, most software for Android phones is based on writing XML markup....

[Tony Gravagno]

I'm kinda hoping people come back to the main topic of this thread. Thanks.

[Tony Gravagno]

Basically, if we have something we can advertise OUTSIDE of the MV
forums, that actually works, we might be able to bring in new people...

Cheers,
Wol

I agree with that approach. Another "clean room" project like this was recently announced. I don't recall the name or if you posted notes on that. Perhaps collaboration on that would be preferable to starting fresh?

I smell a new thread brewing...

T

[geneb]

On Tue, 24 Dec 2019, Tony Gravagno wrote:

> As to MaVerick, I don't have faith that a new platform will have much
> success. Of course there is new stuff springing up all the time and having
> great success. But if MaVerick or ScarletVME or some other platform is
> under the umbrella of the MV industry then I fear it will be subject to the
> same challenges as all other MV platforms : lack of drive and initiative in
> the community, few resources for information, low-traffic forums, very
> little excitement. Sorry to rain on our parade but these Are our challenges
> - and some of the reasons why I started this thread.
>

MaVerick & ScarletDME really need enthusiastic evangelists, and that's an
exhausting task when you're mired in a peer group that doesn't care.

ScarletDME also suffers from the declaration that since the compiler falls
under the GPL, the output does too. Regardless of the validity of the
statement (I think it's bunk, but it's not a hill I have the time or
energy to die on.), it performs the intended goal of preventing any
"serious" use due to the poison pill it represents.

[Wols Lists]

On 25/12/19 17:51, geneb wrote:
> ScarletDME also suffers from the declaration that since the compiler
> falls under the GPL, the output does too. Regardless of the validity of
> the statement (I think it's bunk, but it's not a hill I have the time or
> energy to die on.), it performs the intended goal of preventing any
> "serious" use due to the poison pill it represents.

Agreed.

While I would want to keep the basic MV-DBMS under the GPL, I don't
think compiler output is covered, and I would actually want to end up
with the effect of the Mozilla Public Licence, namely if your mods can
be kept separate, then there is no licence cross-contamination.

Cheers,
Wol

[geneb]

It's been too many years since I sifted through the compiler, but as far
as I can remember, it doesn't do the equivalent of static linking, which
is what would "contaminate" the output of the compiler. You figure the
Free Pascal Compiler is also licensed under the GPL and its output isn't
considered to be GPL licensed as well. The run-time libraries are under
a modified LGPL, which permits static linking.

[Wols Lists]

On 25/12/19 18:02, geneb wrote:
> It's been too many years since I sifted through the compiler, but as far
> as I can remember, it doesn't do the equivalent of static linking, which
> is what would "contaminate" the output of the compiler. You figure the
> Free Pascal Compiler is also licensed under the GPL and its output isn't
> considered to be GPL licensed as well. The run-time libraries are under
> a modified LGPL, which permits static linking.

There are arguments that gcc "contaminates" the binaries it outputs with
its own code, but there is also an explicit exception that says compiler
output is not considered a "derivative work" of the compiler.

I'd basically do exactly the same - provided your source is clearly kept
separate from mine, then the binaries are considered as non-derivative
works for copyright purposes.

I'd also add an exception to the GPL saying that as long as you point
your recipients to an *unrelated* 3rd-pary source, you can distribute
*unmodified* binaries without triggering the "you must provide the
source on request" clause.

(And my pet hobby-horse - the GPL and software have nothing to do with
patents, therefore there would be a clause saying you agree that
software is not patentable subject matter!)

Cheers,
Wol