Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Mumps: the IT world's best kept secret?

145 views
Skip to first unread message

Rob Tweed

unread,
Sep 16, 2008, 2:24:19 AM9/16/08
to
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

http://www.outoftheslipstream.com/node/125

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/NonFinancialIndustries/Healthcare/GTM/InfoBulletins/default)
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

Web-site: http://www.mgateway.com

geo...@gj0.net

unread,
Sep 16, 2008, 4:54:39 AM9/16/08
to
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.

Regards
George

K.S. Bhaskar

unread,
Sep 16, 2008, 10:30:12 AM9/16/08
to
Comments below. Thanks, George.

-- Bhaskar

On Sep 16, 4:54 am, geo...@gj0.net wrote:
> 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

[KSB] There's even a MUMPS (GT.M) module for Perl:
http://www.cpan.org/authors/id/S/SZ/SZECK/Db-GTM-1.27.tgz

> 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/Healthcare/GTM/InfoBulletins/default)
- note that much of what is being discussed applies to MUMPS in
general, not just the GT.M implementation of MUMPS.

Rob Tweed

unread,
Sep 16, 2008, 11:14:54 AM9/16/08
to
On Tue, 16 Sep 2008 07:30:12 -0700 (PDT), "K.S. Bhaskar"
<ksbh...@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

interstar

unread,
Sep 16, 2008, 10:04:09 PM9/16/08
to
On Sep 16, 5:54 am, geo...@gj0.net wrote:

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

phil jones

K.S. Bhaskar

unread,
Sep 17, 2008, 9:25:27 AM9/17/08
to

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

Regards
-- Bhaskar

michael

unread,
Sep 17, 2008, 10:21:10 AM9/17/08
to

> Are there any other standard libraries that you would like to be able
> to accessing from MUMPS?
>
> Regards
> -- Bhaskar

ExPat?

K.S. Bhaskar

unread,
Sep 17, 2008, 3:17:10 PM9/17/08
to

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

Pete

unread,
Sep 17, 2008, 6:42:04 PM9/17/08
to
On Sep 16, 1:54 am, geo...@gj0.net wrote:
> 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
>
> >http://www.outoftheslipstream.com/node/125
>
> > 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
>
> > Web-site:http://www.mgateway.com
>
>

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.

Aaron Seidman

unread,
Sep 17, 2008, 11:18:03 PM9/17/08
to
> 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.)

Bruce M. Axtens

unread,
Sep 18, 2008, 1:45:15 AM9/18/08
to
Rob Tweed wrote:
> On Tue, 16 Sep 2008 07:30:12 -0700 (PDT), "K.S. Bhaskar"
> <ksbh...@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?

--Bruce.

bruce_axtens.vcf

Rob Tweed

unread,
Sep 18, 2008, 3:30:17 AM9/18/08
to
>
>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.

geo...@gj0.net

unread,
Sep 18, 2008, 9:20:21 AM9/18/08
to
On Sep 18, 8: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 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/

George

interstar

unread,
Sep 18, 2008, 9:29:49 AM9/18/08
to
Interesting discussion ...

Here's is a great article on how to make a popular language :
http://paulgraham.com/popular.html

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

interstar

unread,
Sep 18, 2008, 11:06:18 AM9/18/08
to

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?

phil

K.S. Bhaskar

unread,
Sep 18, 2008, 11:39:35 AM9/18/08
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.

-- Bhaskar

K.S. Bhaskar

unread,
Sep 18, 2008, 11:47:31 AM9/18/08
to
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.

-- Bhaskar

michael

unread,
Sep 18, 2008, 12:25:53 PM9/18/08
to

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.

thanks for the reply...

Michael

Rob Tweed

unread,
Sep 18, 2008, 12:28:12 PM9/18/08
to
On Thu, 18 Sep 2008 06:29:49 -0700 (PDT), interstar
<inte...@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

Bruce M. Axtens

unread,
Sep 18, 2008, 2:12:45 PM9/18/08
to
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.

bruce_axtens.vcf

Rob Tweed

unread,
Sep 19, 2008, 4:24:17 AM9/19/08
to
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

---

K.S. Bhaskar

unread,
Sep 19, 2008, 10:08:33 AM9/19/08
to
On Sep 19, 4:24 am, Rob Tweed <rtw...@mgateway.com> wrote:
> 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.comand 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!

[KSB] Rob's virtual machine is a good way to get started.

Regards
-- Bhaskar

Herman Slagman

unread,
Sep 19, 2008, 11:44:03 AM9/19/08
to
Rob,

"Rob Tweed" <rtw...@mgateway.com> schreef in bericht
news:luv4d45sakdoc1j08...@4ax.com...

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

geo...@gj0.net

unread,
Sep 19, 2008, 5:05:32 PM9/19/08
to
On Sep 19, 4:44 pm, "Herman Slagman" <herman_slagman@placid-dash-sky-
dot-org> wrote:
> Rob,
>
> "Rob Tweed" <rtw...@mgateway.com> schreef in berichtnews:luv4d45sakdoc1j08...@4ax.com...

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

George

[1] http://www.slideshare.net/george.james/googles-bigtable
[2] http://www.builderau.com.au/news/soa/Drizzle-MySQL-slims-down-on-Aker-s-diet/0,339028227,339290807,00.htm
[3] http://www.codinghorror.com/blog/archives/000838.html

Rob Tweed

unread,
Sep 20, 2008, 5:14:54 AM9/20/08
to
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.

interstar

unread,
Sep 20, 2008, 10:11:18 AM9/20/08
to
Hmmm .... when we talk about building radically new things on a Mumps
Engine, I remember I still didn't get an answer to my (possibly naive)
question. What *is* the Mumps engine?

Is it the *implementation* of the database?

Or the idea of a hierarchical database structured as globals? (Which
might have new implementations? )

Or the hierarchical database packaged with *that* particular
programming language?

Or the db, language and Object and Relation extensions that
Intersystems or someone else has packaged over it?

Or the idea of an integrated database + run-time environment (as I
blogged here http://cachetastic.blogspot.com/2008/07/ok-after-mentioning-some-bad-things.html
it seems like the best thing about Caché is that it's a "living"
platform in this sense)

Or something else?

regards

phil jones

Rob Tweed

unread,
Sep 20, 2008, 10:48:28 AM9/20/08
to
Well it's probably not a helpful answer but it can be any or all of
the things you suggest - depends on what components and/or add-on
layering you decide to use.

By way of example, EWD has been written using "raw" Mumps code and
globals for a whole bunch of reasons including platform/version
independence and performance (ie EWD can run on both GT.M and Cache
from the same code base).

That's how EWD has been *written*. For someone *using* EWD, there's
no dependence on using raw Mumps code or globals - all the "front end"
stuff is in HTML and Javascript, whilst the "back end" stuff could use
Cache Objects and class methods if you wish. or raw Mumps, or PIP's
SQL etc. Indeed you don't need to write much "back-end" code at all -
just enough to fetch, validate and save your data in your database.
How EWD is written or what it uses under the covers is irrelevant to
the user.

Some people may choose to use raw globals but some other language when
building an application or toolset. Some people may want to use an
XML layer on top of Mumps globals to produce, for example, a document
management system (a great potential use of the technology by the
way!).

So it's horses for courses. In its "raw" form of globals and Mumps
language, it's a great platform for generating other layers that then
allow abstraction from raw Mumps globals and language.

Clear as mud? ;-)

simcha

unread,
Sep 21, 2008, 2:57:45 PM9/21/08
to
On Sep 16, 9:24 am, Rob Tweed <rtw...@mgateway.com> 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
>
> http://www.outoftheslipstream.com/node/125
>
> 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
>
> Web-site:http://www.mgateway.com

Hi every budy all the oldies & goldies.
The weakness of Mumps is in it strength.
I remember sale man in DIGITAL who tried to persuade me to go to RDB ,
RSTS ETC.
The strenth of Mumps frightened the owners' look what Intersystem did
with Mumps (covered it until it's unseen). I remember years in
Intersystems were the word MUMPS was forbiden.
Remember the short exprience of IBM with Mumps, the wonderfull
consequences that Motorola achieved with a Mumps machine.
I work with Mumps from 1979 until to day. What i found out that people
choose not the best product but the best promoted product (see ADA).
To promote such a product you nead either strengh - money or something
like LINUX and again you need a promoter.
Mumps and it's dereviatives like COS/GTM etc. is wonderfull, I am able
to do things more complex and faster but comercially people want the
main stream.
One area that Mumps didn't loose yet is education, this is were people
like you and me (to distinguish from BILL GATES) can do.
Teach mumps free in high scools, also it's not a good language to
begin with - I think this is the area were we can and should invest.
Simcha

Herman Slagman

unread,
Sep 22, 2008, 10:50:49 AM9/22/08
to
Rob,

"Rob Tweed" <rtw...@mgateway.com> schreef in bericht

news:r1d9d41fvvh56h165...@4ax.com...


> On Fri, 19 Sep 2008 17:44:03 +0200, "Herman Slagman"
> <herman_slagman@placid-dash-sky-dot-org> wrote:
>

> KBase SQL, PIP, EsiObjects, eXtc, EWD

> None of these can, in any way, be described as "specialised, niche
> circumstances".

Well, I would call *building* these products a 'specialised niche
circumstance'.
*Using* them is another matter.

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

For the rest of your arguements I totally agree (for once ;-))

Herman

Herman Slagman

unread,
Sep 22, 2008, 11:22:35 AM9/22/08
to
Hi George,

<geo...@gj0.net> schreef in bericht
news:ee615a25-368a-4b9b...@r66g2000hsg.googlegroups.com...


On Sep 19, 4:44 pm, "Herman Slagman" <herman_slagman@placid-dash-sky-
dot-org> wrote:

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

I used the term SQL-like, as in: you need some kind of query-tool.
I am the last who would propagate SQL with a relational database as a
solution for complex high-performance tasks.

For the rest I'd agree with your arguements that a Mumps database is an
excellent (the best ?) tool for these tasks
I just won't recommend it for simple standard problems, then the awkwardness
of the language and the lack of schema just complicates things.

>> All the healthcare systems you mentioned have complex schemas in them,
>> probably proprietary, not open-source and not compatible with anything
>> else.

> VistA?

OK, ok, not *all* of them ;-)

> Intuitively you would expect RDBMSs with strong and rich schemas would
> excel when it comes to complex databases.

I won't ;-)

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

I'm not sure if I am allowed to say much about that.
But it had to do with 'intelligently' mapping unknown data structures to
standard dictionaries and generating code to do that.
(then you probably know which project I'm talking about ;-))

Herman

Rob Tweed

unread,
Sep 23, 2008, 8:40:04 AM9/23/08
to
By way of interest, check out
http://peepcode.com/system/uploads/2008/peepcode-023-couchdb-preview.mov

This is a (free) part of a longer presentation on couchDB from the
Apache folks. This will give you an idea of the kind of "new"
thinking that's going on with respect to SQL versus REST and JSON as
database interfaces: all stuff that could be easily grafted onto a
Mumps engine.

---

0 new messages