December 17, 2007

Intersystems’ stealth marketing has gotten pretty extreme

Every few months I try to make contact with Intersystems. Sometimes they graciously respond, promising to schedule a briefing, which then never happens. Other times they don’t even bother. Now, on one level I can’t blame them, based on what happened at my last briefing.

And it’s not just me. Two personal data points about Intersystems’ self-defeating lack of visibility include:

I probably should stop talking about the company. While their story sounds very good in parts, I don’t have enough confidence in what I’ve heard to feel comfortable proposing them anywhere outside their flagship medical vertical market.


5 Responses to “Intersystems’ stealth marketing has gotten pretty extreme”

  1. Programmer321 on December 18th, 2007 5:22 pm


    As a programmer who had worked with Cache I can firmly say that Cache is waporware.
    The system is crap. A survivor from pre-relation, pre-everything era.
    Have you ever seen MUMPS or M language?
    Have a look:
    Scroll a few screens down.

    This is what you end up coding in if you are developing with Cache.

    There is some icing on top of it.
    There are some not terribly efficient objects.

    The objects are created via GUI and MUMPS code gets generated.
    When you go to debugging you still end up debuggin MUMPS code.

    There is some SQL. Well this SQL is still embedded in MUMPS.
    And you guess what? It feels a lot like embedding SQL in C.

    Under the hood it also gets translated into MUMPS right in-place, macro style.
    When you need to debug again – you’ve got fabulous MUMPS.

    Look at SET ^Car(“Door”,”Color”)=”BLUE”
    This is what you end up writing!

    Looks at this on wikipedia

    No joke, you end up writing this!

    They tell you – we have sql/objects but when you want efficiency go to mumps.

    Look again at this: SET ^Car(“Door”,”Color”)=”BLUE”
    It’s the only persistent datastructure they have – a tree.
    Keys are exclusively stored in form of strings.
    And concatenation of all strings in the key (“Door”,”Color”) here can not be more than a set value – I guess around 512 characters. Not Unicode characters. 8-bit characters.

    There marketing can fall very well into manager’s ears.
    But when it comes to techies it boils down to pushing it through developer’s throat by management.

    No surprise they tell no real story to people with tech brains – there’s nothing to tell!

  2. Curt Monash on December 18th, 2007 5:33 pm

    They claim to have added Java support. Why doesn’t that work for you? Did you use the product before it was in there? Was it there but inefficient?

    As for SQL — yeah, if you want to do OLTP in SQL, Cache’ isn’t your product. It’s there to do a few queries, reports, lightweight BI, and so on. (The company once told me that some of their OEMs for enterprise apps paid more to Business Objects than to Intersystems.)

    Thanks for commenting in such detail!


  3. John Bertoglio on December 21st, 2007 2:53 pm

    Some comments: First, indeed MUMPS is the basis of Cache. There are some
    stunning examples of unreadable MUMPS code out there. But most of it dates
    from an era where memory was measured in chuncks of 1024 bytes and every
    character counted. This code ran very fast (relatively, of course) on the
    machines of the day.

    Modern Cache Object Script if written with block syntax is at least as easy
    to read as any language capable of serious work. Indeed, I find it very easy
    to read. I am not certain what you mean by “special characters”. The
    language uses the standard character set one finds with most languages. The
    old “dot syntax” used for nesting can be a bit challenging at least at first
    but it can be totally eliminated. Doing this also removes the somewhat
    tricky constraints on whitespace as well.

    As far as the lack of awarness of Cache in the technical world, I agree it
    is a problem. They do advertise but it is more institutional in nature. The
    ads seem to be placed more to show the flag and support the decision of
    existing clients instead of getting new ones. On the other hand, if a new
    firm shows an interest in Cache, the reponse from the sales teams can be
    remarkable. They will come onsite, help build technolgoy demonstrations and
    provide much more support than other vendors of enterprise-level databased.
    So it is truly a mixed bag. Sometimes, Cache looks like a cross between a
    cult and and exclusive club…

    I would be more critical of InterSystems and their business model if it they
    did not have a 20+ year of profitiblity and significant annual increase in
    sales. We should all have such problems with our marketing efforts!

    As far as SQL performance goes, this needs to be taken in context. Cache SQL
    runs slower than optomized raw global access. But unless things are very
    poorly tuned, slower Cache SQL is still faster than competive SQL databases.
    With Cache SQL, you also get a fully implemented object database with
    optomized native storage for data objects. While this is not for everyone,
    Cache is the only enterprise database that includes real object support.

  4. Curt Monash on December 21st, 2007 3:31 pm

    Ironically, I was just on Slashdot, and the banner ad I was served offered to make my Java apps more valuable.

    It was from Intersystems. 🙂


  5. John Ingress on December 21st, 2007 5:02 pm

    Cache has both good and bad points:
    The good:
    – MUMPS access actually allow some very fancy stuff
    – no impedence mismatch*
    – Ensemble is amazingly simple to use
    – the same class and editor can include direct editing in XML, ObjectScript, Basc, Javascript and CSS
    – the fact tha data & code are interchangeable can be extremely powerful**
    – ObjectScript is a dynamic language, like Ruby (don’t hit me:-)
    – Intersystems is extremely responsive
    – Intersystem ECP servers are very impressive
    – sparsed arrays are actually extremely powerful and easy to use
    – some very powerful features: code generation, data population, etc.

    The bad:
    -* but true object orientation is impossible. The mismatch is still there but ignored.
    -** and hard to debug.
    – It actually execute data, which makes me wonder about security…
    – you spend most of your time getting around system bugs
    – The developing IDE is real crap
    – the debugger is the worst one of the industry
    – optimising means changing 3 lines of sql with 60 lines of M

    as for being so fast…I would like to see them try TPC benchmarks. I suspect the problem is they may not even qualify. If Intersystems managed to place in the top 10 on any TCP benchmark, the industry will start taking them seriously. They have great potential.

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.