for my thoughts on what I believe is the current situation.
These days, to a great degree, we get the software we deserve. With the availability of Open Source alternatives, it's no longer necessary to wait for a supplier to deliver the value-added functionality, tools and libraries we need. Look at PHP, Ruby On Rails, Python. All thriving and active technologies because of their user communities, not because of suppliers.
So, I think it's very much like voting. If you don't vote, you're in no position to criticise the politicians you end up with. It's in our own hands now, so if Mumps remains the IT world's best kept secret, it's because of our own inaction and because, at the end of the day, we just didn't care any more. What's it to be folks?
---
Rob Tweed Company: M/Gateway Developments Ltd Registered in England: No 3220901 Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
There's a pressing need to play to our strengths and address our weaknesses.
Mumps major strength is obvious: globals.
What are its weaknesses and can we do anything about them?
Libraries: Compared to other languages (Perl, Python, etc) we are lacking libraries to do much of the standard stuff that everyone expects to be available these days: dates, maths, strings for starters. Then take a look at Perl's CPAN to see what richness of libraries they have, over 14,000 list here: http://www.cpan.org/modules/01modules.index.html
Hello World: The hello world experience needs to be much more polished. How many clicks does it take to get to hello world if you start here http://www.intersystems.com/ or here http://sourceforge.net/projects/fis-gtm/ The attrition rate along this path is probably very high.
Community: All successful technologies have a healthy community behind them. You have to work hard to nurture and build communities, they don't just happen.
Image: Most of the old school baggage (MDC, MUG etc) has evaporated. There's an opportunity to create a new cool image and evangelize it.
So that's four areas where we can start to do something.
> for my thoughts on what I believe is the current situation.
> These days, to a great degree, we get the software we deserve. With > the availability of Open Source alternatives, it's no longer necessary > to wait for a supplier to deliver the value-added functionality, tools > and libraries we need. Look at PHP, Ruby On Rails, Python. All > thriving and active technologies because of their user communities, > not because of suppliers.
> What can we do about it? Well IMHO, a good first step would be to > attend Bhaskar's meeting next month > (http://www.fidelityinfoservices.com/FNFIS/Markets/NonFinancialIndustr...) > and use this as a spring-board to begin the creation of a truly > thriving and active community of developers.
> So, I think it's very much like voting. If you don't vote, you're in > no position to criticise the politicians you end up with. It's in our > own hands now, so if Mumps remains the IT world's best kept secret, > it's because of our own inaction and because, at the end of the day, > we just didn't care any more. What's it to be folks?
> ---
> Rob Tweed > Company: M/Gateway Developments Ltd > Registered in England: No 3220901 > Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
> There's a pressing need to play to our strengths and address our > weaknesses.
> Mumps major strength is obvious: globals.
> What are its weaknesses and can we do anything about them?
> Libraries: Compared to other languages (Perl, Python, etc) we are > lacking libraries to do much of the standard stuff that everyone > expects to be available these days: dates, maths, strings for > starters. Then take a look at Perl's CPAN to see what richness of > libraries they have, over 14,000 list here:http://www.cpan.org/modules/01modules.index.html
> Hello World: The hello world experience needs to be much more > polished. How many clicks does it take to get to hello world if you > start herehttp://www.intersystems.com/or herehttp://sourceforge.net/projects/fis-gtm/ > The attrition rate along this path is probably very high.
[KSB] http://fis-gtm.com is the preferred equivalent URL for GT.M to intersystems.com. In any case, I clearly have an action item to think about making the Hello, World experience easier.
> Community: All successful technologies have a healthy community behind > them. You have to work hard to nurture and build communities, they > don't just happen.
[KSB] Agreed. By way of analogy, a healthy VistA community didn't just happen. We had to make it happen. George's and Rob's Slipstream conferences have done much to re-energize the community. We will try to do more at the GT.M+PIP Technology Exchange (http:// www.fidelityinfoservices.com/FNFIS/Markets/NonFinancialIndustries/Hea...) - note that much of what is being discussed applies to MUMPS in general, not just the GT.M implementation of MUMPS.
On Tue, 16 Sep 2008 07:30:12 -0700 (PDT), "K.S. Bhaskar"
<ksbhas...@gmail.com> wrote: >[KSB] http://fis-gtm.com is the preferred equivalent URL for GT.M to >intersystems.com. In any case, I clearly have an action item to think >about making the Hello, World experience easier.
A couple of suggestions:
Could GTM's installation be packaged up as an RPM? That would bring it into line with what people would typically expect. Also I'd suggest that there should be an installation option/step for it to create and configure a basic database.
Advanced users will, of course, want to be able to configure GT.M any which way, but, as George indicates, someone kicking the GT.M tyres needs to be able to get a basic usable working system up and running with a minimum of fuss and documentation. The fewer people fall by the wayside at the start, the better!
Rob
---
Rob Tweed Company: M/Gateway Developments Ltd Registered in England: No 3220901 Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
> Libraries: Compared to other languages (Perl, Python, etc) we are > lacking libraries to do much of the standard stuff that everyone > expects to be available these days: dates, maths, strings for > starters. Then take a look at Perl's CPAN to see what richness of > libraries they have, over 14,000 list here:http://www.cpan.org/modules/01modules.index.html
as far as libraries are concerned, lack of a standard regular expressions library is a major turn-off for anyone who wants to run a web-based service. As there are standard free libraries for this in C, it should be possible, at least in a free version of Mumps, to include.
> > Libraries: Compared to other languages (Perl, Python, etc) we are > > lacking libraries to do much of the standard stuff that everyone > > expects to be available these days: dates, maths, strings for > > starters. Then take a look at Perl's CPAN to see what richness of > > libraries they have, over 14,000 list here:http://www.cpan.org/modules/01modules.index.html
> as far as libraries are concerned, lack of a standard regular > expressions library is a major turn-off for anyone who wants to run a > web-based service. As there are standard free libraries for this in C, > it should be possible, at least in a free version of Mumps, to > include.
[KSB] While this has been, and may still be, a limitation of traditional M implementations (I don't know - GT.M is the only MUMPS I have ever used), GT.M makes it almost trivial to call standard C libraries (in fact, the top level entry into the process can be either C or M and C code and M code can freely call back and forth within the process). So, GT.M users typically just call out to the required standard library. The main advantage of including a binding with GT.M would be some syntactic simplification (calling a built-in function vs. calling an external function). The main disadvantage is that it would be the regular expression (or other function library) that we select rather than the specific one that a user has in mind.
Which FOSS regexp library did you have in mind? I would be glad to publish a short write-up on accessing it from GT.M.
Are there any other standard libraries that you would like to be able to accessing from MUMPS?
On Sep 17, 10:21 am, michael <mpzachar...@telus.net> wrote:
> > Are there any other standard libraries that you would like to be able > > to accessing from MUMPS?
> > Regards > > -- Bhaskar
> ExPat?
Are you looking specifically for ExPat or are you trying for more general XML handling? If the latter, have you looked at EWD (http:// mgateway.com)? If you specifically need ExPat, I'll take a look at it. Let me know.
> There's a pressing need to play to our strengths and address our > weaknesses.
> Mumps major strength is obvious: globals.
> What are its weaknesses and can we do anything about them?
> Libraries: Compared to other languages (Perl, Python, etc) we are > lacking libraries to do much of the standard stuff that everyone > expects to be available these days: dates, maths, strings for > starters. Then take a look at Perl's CPAN to see what richness of > libraries they have, over 14,000 list here:http://www.cpan.org/modules/01modules.index.html
> Hello World: The hello world experience needs to be much more > polished. How many clicks does it take to get to hello world if you > start herehttp://www.intersystems.com/or herehttp://sourceforge.net/projects/fis-gtm/ > The attrition rate along this path is probably very high.
> Community: All successful technologies have a healthy community behind > them. You have to work hard to nurture and build communities, they > don't just happen.
> Image: Most of the old school baggage (MDC, MUG etc) has evaporated. > There's an opportunity to create a new cool image and evangelize it.
> So that's four areas where we can start to do something.
> Regards > George
> Rob Tweed wrote: > > I wonder how many of you have described Mumps this way? If you have, > > then the time has come for you to do something about it.
> > First step, if you haven't already done so, see my blog at
> > for my thoughts on what I believe is the current situation.
> > These days, to a great degree, we get the software we deserve. With > > the availability of Open Source alternatives, it's no longer necessary > > to wait for a supplier to deliver the value-added functionality, tools > > and libraries we need. Look at PHP, Ruby On Rails, Python. All > > thriving and active technologies because of their user communities, > > not because of suppliers.
> > What can we do about it? Well IMHO, a good first step would be to > > attend Bhaskar's meeting next month > > (http://www.fidelityinfoservices.com/FNFIS/Markets/NonFinancialIndustr...) > > and use this as a spring-board to begin the creation of a truly > > thriving and active community of developers.
> > So, I think it's very much like voting. If you don't vote, you're in > > no position to criticise the politicians you end up with. It's in our > > own hands now, so if Mumps remains the IT world's best kept secret, > > it's because of our own inaction and because, at the end of the day, > > we just didn't care any more. What's it to be folks?
> > ---
> > Rob Tweed > > Company: M/Gateway Developments Ltd > > Registered in England: No 3220901 > > Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
I'm of the opinion that Image is the #1 problem we face in seeing MUMPS star rise. To extend the voting metaphor a bit, most people think "A vote for MUMPS is a vote for Andrew Jackson". As much as the "old-school baggage" has evaporated, a ton of new school baggage has been added. Call me jaded but I've seen too many non-technical pointy haired bosses make snap judgments about M simply because "It's old".
> I'm of the opinion that Image is the #1 problem we face in seeing > MUMPS star rise. To extend the voting metaphor a bit, most people > think "A vote for MUMPS is a vote for Andrew Jackson".
They should be saying "Martin Van Buren." :^)
(MVB was President on January 1, 1841, day one of the MUMPS Julian date -- the one you get with $H.)
Rob Tweed wrote: > On Tue, 16 Sep 2008 07:30:12 -0700 (PDT), "K.S. Bhaskar" > <ksbhas...@gmail.com> wrote:
>> [KSB] http://fis-gtm.com is the preferred equivalent URL for GT.M to >> intersystems.com. In any case, I clearly have an action item to think >> about making the Hello, World experience easier.
As a total newbie to MUMPS, can you point me in the direction of a good Windows version?
>I'm of the opinion that Image is the #1 problem we face in seeing >MUMPS star rise. To extend the voting metaphor a bit, most people >think "A vote for MUMPS is a vote for Andrew Jackson". As much as the >"old-school baggage" has evaporated, a ton of new school baggage has >been added. Call me jaded but I've seen too many non-technical pointy >haired bosses make snap judgments about M simply because "It's old".
>Just my 2 cents. Rain over....parade march on.
You'll probably find that very few management-level decision makers have made one jot of difference to the surge of uptake around the world of PHP, Perl, Python and Ruby. It's all been due to lots of individual "little players" getting enthused about a technology that they'd not previously encountered, but which blew their socks off compared with what they'd previously used, working on stuff in their own time, just because they can and want to.
That's what we're talking about here, not worrying about what corporate decision makers think - those attitudes will change if a thriving development community starts to appear.
As I said, it's in our hands, nobody else's. If Mumps dies, it's because we allowed it to happen. - it's our fault, not some anonymous bogey-man in the form of dim-witted business managers.
---
Rob Tweed Company: M/Gateway Developments Ltd Registered in England: No 3220901 Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
> >I'm of the opinion that Image is the #1 problem we face in seeing > >MUMPS star rise. To extend the voting metaphor a bit, most people > >think "A vote for MUMPS is a vote for Andrew Jackson". As much as the > >"old-school baggage" has evaporated, a ton of new school baggage has > >been added. Call me jaded but I've seen too many non-technical pointy > >haired bosses make snap judgments about M simply because "It's old".
> >Just my 2 cents. Rain over....parade march on.
> You'll probably find that very few management-level decision makers > have made one jot of difference to the surge of uptake around the > world of PHP, Perl, Python and Ruby. It's all been due to lots of > individual "little players" getting enthused about a technology that > they'd not previously encountered, but which blew their socks off > compared with what they'd previously used, working on stuff in their > own time, just because they can and want to.
> That's what we're talking about here, not worrying about what > corporate decision makers think - those attitudes will change if a > thriving development community starts to appear.
As a first step towards building a stronger community I've just created an IRC channel for GT.M at irc://irc.oftc.net/gtm
Please come and hang out here if you want to chat about this or any GT.M related stuff.
For anyone not familiar with IRC, you need to install an IRC client such as mIRC or Chatzilla. You can download mIRC here: http://www.mirc.com/
> As I said, it's in our hands, nobody else's. If Mumps dies, it's > because we allowed it to happen. - it's our fault, not some anonymous > bogey-man in the form of dim-witted business managers.
> ---
> Rob Tweed > Company: M/Gateway Developments Ltd > Registered in England: No 3220901 > Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
I guess the real question in the case of Mumps is "what are you trying to save"?
In one sense, the virtue of Mumps is very clear. The very tight integration between language, database and runtime-environment. The flip-side of that is the inflexibility of the tight coupling. If people don't like the language, they won't use the database (and vice- versa).
From the discussion here, it sounds like we're trying to decouple and save the database, by showing how other languages can be interfaced to it. But, then, as my colleague (an experienced Java programmer, currently experiencing the culture-shock of adapting to Mumps) put it "if I only want a persistent object database, why Mumps rather than one of the many others available?"
If it's the "integrated package" of a language + database + environment, then I think the language part has to be fixed too. Intersystems, as far as I can see, have made a go of trying to evolve the language. But is that likely to be the Mumps "standard" or is it already a fork?
phil jones
On Sep 18, 4:30 am, Rob Tweed <rtw...@mgateway.com> wrote:
> >I'm of the opinion that Image is the #1 problem we face in seeing > >MUMPS star rise. To extend the voting metaphor a bit, most people > >think "A vote for MUMPS is a vote for Andrew Jackson". As much as the > >"old-school baggage" has evaporated, a ton of new school baggage has > >been added. Call me jaded but I've seen too many non-technical pointy > >haired bosses make snap judgments about M simply because "It's old".
> >Just my 2 cents. Rain over....parade march on.
> You'll probably find that very few management-level decision makers > have made one jot of difference to the surge of uptake around the > world of PHP, Perl, Python and Ruby. It's all been due to lots of > individual "little players" getting enthused about a technology that > they'd not previously encountered, but which blew their socks off > compared with what they'd previously used, working on stuff in their > own time, just because they can and want to.
> That's what we're talking about here, not worrying about what > corporate decision makers think - those attitudes will change if a > thriving development community starts to appear.
> As I said, it's in our hands, nobody else's. If Mumps dies, it's > because we allowed it to happen. - it's our fault, not some anonymous > bogey-man in the form of dim-witted business managers.
> ---
> Rob Tweed > Company: M/Gateway Developments Ltd > Registered in England: No 3220901 > Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
On Sep 17, 10:25 am, "K.S. Bhaskar" <ksbhas...@gmail.com> wrote:
> Which FOSS regexp library did you have in mind? I would be glad to > publish a short write-up on accessing it from GT.M.
I don't have a specific one in mind, but it should be "Perl Compatible" eg. something like this : http://www.pcre.org/
Just as a matter of interest, if C and M can call into each other, does that mean that GT.M compiles down to machine code? And the db is a library? Or is there some kind of runtime environment / interpreter (which is what I assume goes on in Caché) that C programs call *in* to?
On Sep 18, 1:45 am, "Bruce M. Axtens" <bruce.axt...@gmail.com> wrote:
[KSB] <...snip...>
> As a total newbie to MUMPS, can you point me in the direction of a good > Windows version?
[KSB] There isn't a Windows version of GT.M today, but I can create a virtual machine with a hello, world example if you care to run it in a virtual machine on your Windows host. Let me know.
On Sep 18, 11:06 am, interstar <inters...@gmail.com> wrote:
> On Sep 17, 10:25 am, "K.S. Bhaskar" <ksbhas...@gmail.com> wrote:
> > Which FOSS regexp library did you have in mind? I would be glad to > > publish a short write-up on accessing it from GT.M.
> I don't have a specific one in mind, but it should be "Perl > Compatible" eg. something like this :http://www.pcre.org/
[KSB] Thanks, I'll take a look at it.
> Just as a matter of interest, if C and M can call into each other, > does that mean that GT.M compiles down to machine code? And the db is > a library? Or is there some kind of runtime environment / interpreter > (which is what I assume goes on in Caché) that C programs call *in* > to?
[KSB] GT.M compiles down to machine code. Yes, the db is packaged in a library, along with the rest of the run-time, that is called by the generated code.
> On Sep 17, 10:21 am, michael <mpzachar...@telus.net> wrote:
> > > Are there any other standard libraries that you would like to be able > > > to accessing from MUMPS?
> > > Regards > > > -- Bhaskar
> > ExPat?
> Are you looking specifically for ExPat or are you trying for more > general XML handling? If the latter, have you looked at EWD (http:// > mgateway.com)? If you specifically need ExPat, I'll take a look at > it. Let me know.
> Regards > -- Bhaskar
I just took a quick look at EWD and eXtc. When I get a spare minute I want to give the EWD virtual machine a try. I guess my intention of using ExPat with GT.M is if I wanted to create my own NXD like eXtc. This is all high-level back of the napkin kind of thinking on my part.
On Thu, 18 Sep 2008 06:29:49 -0700 (PDT), interstar
<inters...@gmail.com> wrote: >But, then, as my colleague (an experienced Java programmer, >currently experiencing the culture-shock of adapting to Mumps) put it >"if I only want a persistent object database, why Mumps rather than >one of the many others available?"
Well of course, that's Java culture influencing his question. I would ask "if all I want is to persist a bunch of name/value pairs, why would I want anything other than the simplicity of a schemaless, hierarchical database?"
In other words, why would you think you needed a persistent object database at all? If you want one, then Cache would be an obvious contender.
Why Mumps and not one of the many available free open source new kids on the block? Because they are largely untested in terms of scalability, resilience etc etc whereas Mumps is tried and tested with a long history of being a high-performance, highly scalable technology. Oh, and because we like it's immediacy, the fact you can directly access it and dig around in it interactively......etc etc
---
Rob Tweed Company: M/Gateway Developments Ltd Registered in England: No 3220901 Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
K.S. Bhaskar wrote: > [KSB] There isn't a Windows version of GT.M today, but I can create a > virtual machine with a hello, world example if you care to run it in a > virtual machine on your Windows host. Let me know.
I would like that very much. I have Virtual PC, but have other virtual machine tools as well if need be.
If you wish to start playing straight away, you can download the EWD Virtual Appliance which will run in VMWare Player:
Go to http://www.mgateway.com and click the "Enterprise Web Developer", "Download EWD" and "EWD Virtual Appliance" tabs.
The EWD Virtual Appliance comes with GT.M pre-installed and pre-configured, along with all sorts of other goodies, all for free!
Rob
On Fri, 19 Sep 2008 02:12:45 +0800, "Bruce M. Axtens"
<bruce.axt...@gmail.com> wrote: >K.S. Bhaskar wrote: >> [KSB] There isn't a Windows version of GT.M today, but I can create a >> virtual machine with a hello, world example if you care to run it in a >> virtual machine on your Windows host. Let me know.
>I would like that very much. I have Virtual PC, but have other virtual >machine tools as well if need be.
>Kind regards, >Bruce.
---
Rob Tweed Company: M/Gateway Developments Ltd Registered in England: No 3220901 Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
> Well of course, that's Java culture influencing his question. I would > ask "if all I want is to persist a bunch of name/value pairs, why > would I want anything other than the simplicity of a schemaless, > hierarchical database?"
Storing simple name/value pairs is hardly a real-life requirement. If you go any further than that you'd need a schema of some sort. If you decide to make the first level subscript of a global the 'primary key' then you have a schema. No matter if that is enforced by the database software or by convention in your project. If you go for 'raw' globals, you always end up writing your own database driver that enforces your 'schema'. If you want SQL-like queries, you have to write your own query 'compiler'. If you decide that piece 23 of the 'record' is a pointer to another global, then you have to write code that supports that. Seen it, been there, done that. If you want to solve a business problem you don't want to write code that handles all that standard stuff.
The reasons for Mumps databases to exist, are exactly what you pointed out in your (excellent) blogg: very complex, high volume, high-performance database transactions. All the healthcare systems you mentioned have complex schemas in them, probably proprietary, not open-source and not compatible with anything else.
Google, Amazon and others don't use Mumps databases, yet everybody would agree that they can serve high volumes of users with excellent performance. But it's all (relatively) simple *data*, as for the bulk of the mainstream web-sites, no need to use an awkward language with an unknown database.
Mumps will always be a niche (embedded) database product, capable of amazing things but only in very specialized circumstances. InterSystems understood that and build Cache and Ensemble on top of that engine, providing us with the ease of Object Schemas and Business Processes but still providing the raw power of globals when needed. In all my Cache/Ensemble experience we'd only have to resort to globals once in a very complex and high-performance situation.
Herman
---
Herman Slagman Placid Sky Consulting Software Architect of LSP (Dutch National Health Gateway) for CSC Computer Sciences B.V.
> > Well of course, that's Java culture influencing his question. I would > > ask "if all I want is to persist a bunch of name/value pairs, why > > would I want anything other than the simplicity of a schemaless, > > hierarchical database?"
> Storing simple name/value pairs is hardly a real-life requirement. > If you go any further than that you'd need a schema of some sort. > If you decide to make the first level subscript of a global the 'primary > key' then you have a schema. > No matter if that is enforced by the database software or by convention in > your project. > If you go for 'raw' globals, you always end up writing your own database > driver that enforces your 'schema'. > If you want SQL-like queries, you have to write your own query 'compiler'.
The Internet has changed the problem. SQL is no longer any kind of requirement. Most large scale Internet applications (think Flickr, eBay, Amazon) all provide external access to their data via some kind of api. Generally they do not use SQL as its not an appropriate or good solution.
> If you decide that piece 23 of the 'record' is a pointer to another global, > then you have to write code that supports that. > Seen it, been there, done that. > If you want to solve a business problem you don't want to write code that > handles all that standard stuff.
The Internet is big. Successful applications need to be able to scale massively. Many organisations have had to build home grown solutions because the traditional SQL based solutions just don't cut it. Google [1], is the most obvious and well known example, but they are not alone. There are projects such as Drizzle [2] which are trying to solve the problem from the other end, by cutting the fat out of SQL.
> The reasons for Mumps databases to exist, are exactly what you pointed out > in your (excellent) blogg: very complex, high volume, high-performance > database transactions.
High volume, high performance (and sometimes complex) databases are exactly the issues that every prospective Internet startup has to be prepared for. Should they be successful, they don't want to fail the way that Twitter [3] almost did.
> All the healthcare systems you mentioned have complex schemas in them, > probably proprietary, not open-source and not compatible with anything else.
VistA?
> Google, Amazon and others don't use Mumps databases, yet everybody would > agree that they can serve high volumes of users with excellent performance.
Yes, they can serve high volumes of users with excellent performance, but they only managed to do this by building their own home grown solutions. None of the incumbent RDBMS solutions could cut it. Amazon's SimpleDB virtually reinvented the Mumps database.
> But it's all (relatively) simple *data*, as for the bulk of the mainstream > web-sites, no need to use an awkward language with an unknown database.
Intuitively you would expect RDBMSs with strong and rich schemas would excel when it comes to complex databases. And yet we find that this is exactly the situations where Mumps databases, with non-rigid schemas and weak data-typing, tend to really win. Is SQL a help or a hindrance as complexity increases?
> Mumps will always be a niche (embedded) database product, capable of amazing > things but only in very specialized circumstances. > InterSystems understood that and build Cache and Ensemble on top of that > engine, providing us with the ease of Object Schemas and Business Processes > but still providing the raw power of globals when needed. > In all my Cache/Ensemble experience we'd only have to resort to globals once > in a very complex and high-performance situation.
Can you describe the problem you solved? I'd be interested in understanding the point at which the benefits of globals start to kick in?
On Fri, 19 Sep 2008 17:44:03 +0200, "Herman Slagman"
<herman_slagman@placid-dash-sky-dot-org> wrote: >Mumps will always be a niche (embedded) database product, capable of amazing >things but only in very specialized circumstances. >InterSystems understood that and build Cache and Ensemble on top of that >engine, providing us with the ease of Object Schemas and Business Processes >but still providing the raw power of globals when needed. >In all my Cache/Ensemble experience we'd only have to resort to globals once >in a very complex and high-performance situation.
I would argue that the very fact that Cache's objects and the Ensemble integration engine could be implemented by layering on top of the core Mumps database actually speaks volumes for the underlying Mumps technology. KBase SQL and more latterly PIP have demonstrated that, if required, a relational/SQL projection can be layered on top of GT.M also.
EsiObjects has shown that an alternative object projection to Cache is also possible on top of the Mumps technology.
Our own eXtc product has demonstrated that by layering an implementation of the W3C XML DOM on top of the Mumps database, you can get leading-edge Native XML Database capabilities and an environment that allows easy and high-performance XML DOM manipulation.
Our EWD product has shown how the underlying Mumps technology can be further transformed into a ground-breaking Ajax development tool.
EWD also allows a Mumps database to be very easily exposed as a set of REST services (cf Amazon simpleDB and S3).
None of these can, in any way, be described as "specialised, niche circumstances". What emerges from this is an underlying technology that is a "Swiss Army Knife" of databases. In its "raw" form it is arguably too "raw", but that raw engine provides all the basic ingredients to support all the latest modern requirements, and, crucially, support them better than the "mainstream" incumbents.
That is what has always retained my interest in Mumps as a technology, and what still excites me about it. In my own spheres of specialisation - Web/Ajax/REST/XML - I've yet to find any of the new "darling" technologies that come close to allowing me to do what I can with a Mumps engine. That's why I passionately believe that it's a technology worth keeping alive rather than rolling over and letting it die.
Cache and Ensemble are two very good, but closed-source, examples of how the underlying Mumps engine can be transformed into something that fills a set of commercial needs. But the Mumps engine can be (and already is) the basis of many more exciting things.
One word of caution, however. It's been our experience at M/Gateway that the Mumps community has been dogged for years by the "we can do that too" philosophy. That gets nobody anywhere. If we can do SQL, Objects, Web, Ajax etc just like everyone else, then, guess what... people will continue to use everyone else. If "we can do stuff demonstrably better", then that helps and gives Mumps solutions at least a fighting chance.
However. if "we can do stuff that nobody else can even dream of", *then* we have something interesting on our hands. I believe we nearly achieved that with WebLink - the Event Broker that Chris Munt invented allowed us to do the kind of things that 10 years later were badged by the mainstream as the "new" Ajax technology. I believe we have something similar in EWD, but I'm also sure that others out there could come out with equally ground-breaking technologies based on a Mumps engine. It has all the right ingredients.
---
Rob Tweed Company: M/Gateway Developments Ltd Registered in England: No 3220901 Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
