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:
- A nontrivial ISV is evaluating OODBMS for a nontrivial OLTP app. Cache’ — the obvious #1 choice — isn’t even being considered, because they know so little about the product. I suggested Cache’, but they shot back a qualifying question I couldn’t answer, because I’m so out of touch with the company and product myself.
- A client of mine that’s a medical-app ISV was indeed evaluating Cache’, as they should be — but was hugely impressed that I’d heard of such an obscure product.
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.
Comments
5 Responses to “Intersystems’ stealth marketing has gotten pretty extreme”
Leave a Reply
Hello!
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: http://en.wikipedia.org/wiki/MUMPS
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
D H S Y=%Y,X=$P(“SUN^MON^TUES^WEDNES^THURS^FRI^SATUR”,”^”,Y+1)_”DAY”
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.
B-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!
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!
CAM
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.
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. 🙂
CAM
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.