Intersystems Caché -- Gateway to hell



  • Almost two years ago I started a new employment (in healthcare). It was soon revealed that the language and database of choice was Caché from Intersystems, which is Mumps-based (somehow). I was a little intrigued that I had never heard of it before, since the resident databaseadministrator described it as the Final Answer To All Problems.

    I worked through the tutorial, thinking that it would "open up" and give away all these amazing features.


    It didn't took me long to realise how wrong he was.

    I can't comment on Mumps in general but my absolutly biggest beef with Caché is that all code is stored in the database. All code. Let it sink in for a while... Yes, that's right, you have to use a special application to edit your code. This means no easy backups (you have to either backup the whole database or make an 'export' of your project to XML), no version management system (CVS, Subversion), no auto documentation tools, no analysis tools, no nothing... I can't really tell you how much this sucks. The IDE, Intersystems Studio, is pretty much just a texteditor which highlights syntax errors in red. Thats it. When I complained about Studio a sales representant told me that "we're not a tools company, we're a database company" and then, in the next sentence as an answer to my question about the possibility to use other tools: "no". Go figure.
     
    The programming language has been slightly redesigned in later versions to something called 'Caché Objectscript'. This is a lame attempt to add OO concepts to a basically dead language. It's not enough to add something called 'class' and then be done. No exception handling, no encapsulation, no typing, and so on. Worst part is that the class is 'compiled' into something which is basically Mumps-based. Yes, thats right. You write in one language which compiles into more or less the same language. Smells like a macro-language if you ask me.

    Problem is that if a runtime programming error occurs the error refer to the compiled code (!) and usually with a message like: "Error 8002 on line 142 in procedure WTFISGOINGON.inc" (or something to this effect). But it's not line 142 in your code! This is like coding in Java and having the VM point you to the bytecode when something goes wrong... With the error message "it's wrong".

    And it doesn't stop there. Remember how popular it was in the end of the 90's to embedd programming languages in HTML-pages? ASP, PHP, and so on? Ofcourse Caché must have its own version, Caché Objectscript Pages or CSP. These are actually stored as regular files, probably because Intersystems use a mod for Apache to handle them. On execution these are compiled to Caché Objectscript classes... Yes, that's right, to something which in turn is compiled to yet another form. Where do you think errors refer?

    Ohh, yes... Did I tell you that the documentation absolutely sucks?
    They have some documentation available similar to javadoc, but where
    the JDK tells you what you need (and usually more) their version is
    amazingly sparse. Once I tried to call a static method in a class and
    got errors however I did it. Turned out that that particular class
    wasn't converted to the new OO system and that you needed to use the
    old calling method, but this information was nowhere to be found (it
    didn't differ one bit from other classes I used).


    I could go on here...

    In my subjective not so humble opinion, Caché and its related technologies is one really large WTF. The funniest thing is how the newsletter and other propaganda makes you think of a sect or something. Everything is sooo great and so much faster than everything else. Yeah, right...

    These days I have switched to Java, J2EE and Postgresql. I can't say J2EE is the greatest thing since sliced bread, but it's heaven compared to Caché.

    (Hopefully I have mentioned Caché, Caché Objectscript and Intersystems enough to rank this post high in search enginges. Let the truth be heard!)



  • Fun fact: caché means hidden in french. Maybe they were referring to the documentation... ?



  • @Eolianne said:

    Fun fact: caché means hidden in french. Maybe they were referring to the documentation... ?




    And mumps is the name of a disease. Combined, it's a hidden disease.



  • You write in one language which compiles into more or less the same language. Smells like a macro-language if you ask me.



    Eehmm, what about the original C++ compiler then?



  • Naturally, MUMPS has a $WTF function:

    http://www.jacquardsystems.com/Examples/function/wtfit.htm



  • I think you might've started in the job after I resigned :) I did a
    stint for 6 months at a certain hospital, where they used Cache-based
    software to run the emergency department.



    All I can say is, you were too fair on Cache, CSP, the tools, the
    language and so on - that was a nightmare six months I never want to go
    through again. That was the nastiest software development (or is that
    DBA'ing :/) I've ever had to suffer through.



    I even had the 'pleasure' of going to one of the sales spiels on the
    'new' Cache with all its OO features and so on ... a hideous
    combination of sales lies^H^H^H mixed in with some hard-coded coding
    demos (we all tried these demos later and none of them worked with the
    CD's we were given, upon asking the sales guy, "Oh yes, mine is a
    custom installation, all of this is fairly new grumble murmur run -
    despite being touted as features of the release on the CD).



    They seem to have gelled all of the bad things of proprietary software
    environments with all of the lessons learned of how not to run large
    scale projects. Then they have the hide to go and boast about their
    database technology.... hmm, reminded me of working on PICK on an old
    Sequoia mainframe, except I preferred PICK, at least it worked. I still
    run cold at the mention of CSP's.



  • Well, in my original rant, I was trying to be discrete.  Now, I feel empowered; yes, my current job entails dealing with Caché, which is truly a WTF on top of a WTF, as noted above.

    To compound my problems, I'm currently just a lowly "analyst" (whatever TF that means), dealing with a package built by a fourth party, on top of Caché.  In theory, I'm not responsible for 'development' on this POS, just supporting it for my users, and trying to figure out how to query it for reporting purposes.  Intersys likes the term "post-relational" to indicate just how cool Caché/M[umps] is ... In my experience, so far anyway, their implementation of SQL for querying (the only way to do it without writing Caché-specific code) ... sucks. Oh, yeah, good luck trying to find any sort of querying tool that can give you a useful execution plan; "Query tuning? What's that? Caché is sooooooo much smarter than you, you don't need to worry about it." Meantime, queries on extremely small tables (~ 16k rows) with a couple of relatively simple joins take MINUTES to run.  Where's the blazing speed that the zealots like to preach about? (Should I mention that this pile of crap is supposed to be happy on low-end hardware, but in my case is running on a quad-processor machine?)

    Oh, yeah, since I have to deal with a totally different company for our app, I'm technically not supposed to be even looking at the back side, other than in the simplest of "select * from some_bizarrely_named_table_because_everyhing_is_pretending_to_be_an_object_pretending_to_be_a_table" ways. Our vendor, who shall remain nameless, is even more clue-challenged than Intersys. (Of course, I'm not allowed at the code, but the number of bizarre bugs, glitches, general weirdness and WTF-inspiring bits of interface design makes me want to get my hands on whatever stuff their QA guys are smoking. It must make all of this sh*te easier to deal with.)

    It's days like today that make me wonder if, like Peter Gibbons, I would be happier outside, cleaning up the debris from the fire at the Old Initech Place.

    -- :-?

    (damn, I hope this posts right. Oh, yeah, since no one's said it in this thread yet, THE REAL WTF IS THE FORUM SOFTWARE. Hey, here's a WTF: Alex, see if you can hack phpBB to talk to Caché, that would be fun...)



  • I have to agree, you've had me rolling on the floor from this thread. I've been dealing with their "experts" after having inherited some of the epic issues with the Caché systems. The requirements are pretty ridiculous, they were telling us that we need 12 processors, we also need 2 full arrays in the SAN for their application to work properly. When the question as to why we need to isolate their application and database when we have the same set up for our Oracle databases, they couldn't give us a satisfactory answer. There's a WTF for you, having to buy nearly $750,000 in hardware just to get their Crappé developed application/DB to work.



  • We've had quite the opposite experience having gone from Oracle to Cache', we got to cut the hardware we were using by almost half. Wonder what's different about your set up.



  • I just got a link to this book from O'Reilly, and I can't believe someone actually would do this...  its about tying a C# frontend onto a Cache database.


    WTF??



  • Totally awesome.



  • The worst thing is, it seems to be endorsed by IBM, Sun and HP! http://intersystems.com/cache/testimonials/endorsements.html



  • WTF is a "post-relational" database?



  • @GalacticCowboy said:

    WTF is a "post-relational" database?

    Marketing-ese for an object-esque layer built on top of a heirarchichal database.  And Intersystems' CEO didn't like the connotations associated with the underlying language's original name, MUMPS...



  • This is the greatest, and most true thing I have ever read. It is now my gospel.



  • Doesn't surprise me that all of you work at hospitals (MUMPS was developed at a hospital, hence the name ;) ). Caché itself is known to have quite a good performance and not for it's ease of use. Well... i think most of the WTF feel comes from the fact that MUMPS was written in the late 60s. Maybe it's just too old for our eyes ;). Or maybe the old quote is still true:

    "MUMPS is an awful language with one godlike feature." (the "^" for referencing a database node)



  • Caché, where have you been?

    <FONT color=#ff0000>"Gateway to Hell"</FONT>, indeed.

    <FONT face="Courier New" color=#800080><FONT color=#ff0000>C:</FONT>      67
    <FONT color=#ff0000>a:</FONT>      97
    <FONT color=#ff0000>c:</FONT>      99
    <FONT color=#ff0000>h:</FONT>     104
    <FONT color=#ff0000>e:</FONT>     101
    <FONT color=#ff0000>d:</FONT>     100
    <FONT color=#ff0000>b:</FONT>      98
    </FONT>

    <FONT face="Courier New"><FONT color=#800080>TOTAL: </FONT><FONT color=#ff0000>666</FONT></FONT>

    <FONT face="Courier New" color=#000000 size=2>perl -e "$total=0; foreach $c (split(//,qq(Cachedb))) { print qq($c: ).ord($c).qq(\n); $total += ord($c); } print qq(TOTAL: $total\n);"</FONT>



  • Apparently Intersystems has created another database called Ensemble, which is supposedly used at places like Verizon, U.S. Cellular,  and other Ma Bell companies for billing. That would explain the WTF is this on my bills every month.

     

    666? Is it coincidence that the 6 is also the ^ key? I think not. :)



  • What you're talking is completely WTF.

    Do you know other DBMS without impedance mistmatching? Do you know other DBMS allowing either object, SQL or direct data access to the SAME data?

    Do your know other language for multidimensinal data than M(UMPS)? Use Cache' Basic if you don't like M language for some reason.

    Let's return to conventional RDBMS and forget about all cool OO-stuff you learned with Java or C++. Get the REAL WTF of meanless tables and unlimited JOINs, deal with SQL-access only and stupid SQL synatax, cover it with WTF stored procedures, add the WTF business object layer for thouse logic that cannot be implemented with stored procedures, produce WTF object-relational mapper for that WTF business layer to access that WTF tables and finally add the greatest WTF in database world - XML data for thouse information that still does not fit into flat tables. Ah no! Also use LINQ - poor reinvention of what allready was in dBase or FoxPro for years.

    Continue to do all that useless work just to cover dummy tables with your cool OO-applications and never return to Cache'.



  • I worked in MUMPS (the language Cache evolved from) for several years in the early nineties and am now in the Java world.  Although I don't miss the language itself much (except from a sick, twisted sense of nostalgia), I do miss some of its features.

    The thing I miss most about it is the hierarchical database backing it.  What takes multiple tables and cross-ref tables in a relational database can be done inside a single database structure (called a Global) in MUMPS.  Also, it is trivial (and runtime fast) to create any number of indices into a Global by putting your indexed data into the hierarchical keys.  So data search and retrieval can be incredibly fast and efficient.

    Another nice feature is the intimate relationship between the language and the database.  First, variables are also hierarchical and can contain data in the keys.  This means that you never have to write a sort - simply setting Var("DEF") = 1 and Var("ABC") = 2 will give you data sorted on the keys.  Second, you can set entire database structures into local memory with one operation.  Suppose you have a database record ^PATIENT("Data", 12345) and you want to fetch it.  You say SET PATIENT = ^PATIENT("Data", 12345), and now the PATIENT local variable contains the entire record.  No Object/Relational Mapping necessary.

    There are, of course, downsides.  The following is a valid line of MUMPS code:

    A       B:C  D E F G=H:I:J K:L M N O,P Q:R  S T=UVW X YZ

    It means "Line is labelled A.  Breakpoint if C is true.  Do the E subroutine.  For G=H to J, incrementing by I. If L is true, kill (unset) the M variable.  Create new variables O and P.  If R is true, quit.  Set the T variable = the UVW variable.  Execute the contents of the YZ variable as if it contains valid MUMPS code."  I remember showing some code to a college friend when I'd been working with it for a few months, and he asked why my printer was spewing line noise.

    Another downside is certainly the self-contained environment.  However, it *is* possible to use external tools if you're clever.  When I worked for a company using MUMPS on Vaxen, I wrote a routine that would import/export source code so I could edit it in TPU/Eve.  At my next MUMPS job, we integrated with a third-party source-control system.

    And it is certainly very easy to write completely unmaintainable code in MUMPS.  Of course, as we see here all too frequently, that's true in most languages.  And as in any other language, a competent, disciplined programmer can write very clear maintainable code.  However, since much of the early MUMPS code was written by doctors with little or no programming training (recall that it was developed at Massacusetts General Hospital), much of the older code out there is pretty bad.

    I can't really speak about Cache's object system because I left the MUMPS world before it really got going.  I do know that Cache is a bastardization of the original language and that Intersystems is, well, um, I'll try to avoid libel by just saying "not the greatest company in the world."



  •  Actually, Cache reminds me of a really fucked up version of ... Cold Fusion. Same obscure idiotic ideas (Scripting Language inside Web Pages with really retarded processing, and error output)

     I mean, having to type #CSP:WTF() any time I want to do something is just annoying, and then there's the fact that they tied it onto a database engine.

     They're clearly trying to do way, way too much, and in the end they do all three horribly.

     First, they're Web Server Sucks (and their documentation sucks, otherwise I'd have switched it over to the Apache Web Server I have running on my dev machine))

    Then they have their programming language (which sucks, give me a good clean language that was designed to be human readable at all times like C#, PHP, Java or JavaScript when well written.)

     Then there is the database, which clearly sucks based on the programming language. There's no way to see the tables (it's a class, which doesn't make sense, because the idea behind a table is that it represents a single object, not a collection of objects. The data is the collection of objects. Then there's this Obj(ect)Id that I guess is what the damn tables should really be indexed on, but its a "imaginary" field the same way Sqrt(-1) is an imaginary number. So you have these tables, that you can't really see, and you have data, which is like no where. No way to access it. It's the ultimate system for holding data captive. THERE IS NO ESCAPE for your data.

     I'm sure there are some companies (I'm not going to name names) that love this shitty system, because the healthcare industry is intensely competitive (Prime Competition for my firm are other firms in the area, we've crushed the Indians (India) cause their support sucks, and they can't program their way out of a paper bag. (Great way to piss off clients.)

     Then there's another company (the Vendor that supplies the Billing System we switched to, is why we switched from a Firebird/MySql/MSSQL backed multiple software system) to this. So far it seems like their programmers aren't worth a shit, but I think it's because they are stuck dealing with Cache.

     I'm sure at the head of the company is another moron like Bill Gates who bought the software, before realizing that there was massive room for improvement (DOS,) and can't program his way out of a paper bag...

     Though this is supposed to be a rant about the Hidden Disease called Cache and its dead 60s technology, Mumps. Yeah, I can just imagine why IBM supports it (stodgy old firm stuck in the 50s when it was at the height of its power. I'm sure the executives love pretending they are living in the good old days before the PC Revolution that started hammering nails in their coffin.)

     We can't neglect Sun, hey, wait, that makes for 2/3 dying companies, what was the third, HP. another stodgy old firm that has seen better days (back when electronic typewriters were all the rage) that's 3/3 dying companies.

     Makes you wonder if Cache Mumps - Hidden Disease - Old Companyitis



  •  @GalacticCowboy said:

    WTF is a "post-relational" database?

    No, WTF is "Worse than failure"



  •  This thread has a special pace in my heart.  It is because of this thread that I don't work for Intersystems (I was about to accept a job offer from them and then I read this thread and started digging more into MUMPS and asked my hiring manager to give it to me straight if I was to be supporting MUMPS).  

    That being said, how many times are we going to bump this thread?  I mean, it's only 3 years old with at least 3 bumps from deadness already.  



  • @tster said:

    That being said, how many times are we going to bump this thread?  I mean, it's only 3 years old with at least 3 bumps from deadness already.  
    Not until it's good and ready.  Jesus, you want to kill it before its third birthday!  



  • @belgariontheking said:

    @tster said:

    That being said, how many times are we going to bump this thread?  I mean, it's only 3 years old with at least 3 bumps from deadness already.  
    Not until it's good and ready.  Jesus, you want to kill it before its third birthday!  

    I believe that abortion should be legal through the 15th trimester.


  •  As far as when this thread is going to die, when Mumps is no longer mentioned, and when Cache is finally updated in such a way that it is easily connected to whatever web servers, languages, and database back ends you want it connected to.

     

    Anyway, I got another chapter in the Cache Saga

     Finally making heads or tails out of Cache (I still hate it), but I am beginning to understand it (As far as understanding it goes).

     The problem is now, I'm trying to get it to work with Apache, on a dev machine, running windows, and instead of recognizing the fact that the Network Administrators should be the ones handling network security, with the providers of the Database primarily concerned about making sure that there are security settings that can be applied to allow limited access for users (as decided by the developers/users/network managers/support personnel) Intersystems decided to embed that in their software.

     So I'm running into this error that while it is briefly mentioned in their documentation (I hate their documentation (or undocumentation)) doesn't make any sense, because it shouldn't be handled by them. It's all good and well that they are security conscious, but I swear they hired 60 year old programmers, and cocaine addicts as security specialists (very paranoid) or maybe Conspiracy Theorists, and when explaining all the caveats they wanted covered, failed to explain that it should still allow for Cache to be tied into another Webserver easily, with minimal fuss.

    Hidden Disease - Yeah, it's probably what causes postal workers to go postal, and programmers to leave for careers in fields far far away from computers.



  • @TomCo said:

    Caché, where have you been?

    <font color="#ff0000">"Gateway to Hell"</font>, indeed.

    <font color="#800080" face="Courier New"><font color="#ff0000">C:</font>      67
    <font color="#ff0000">a:</font>      97
    <font color="#ff0000">c:</font>      99
    <font color="#ff0000">h:</font>     104
    <font color="#ff0000">e:</font>     101
    <font color="#ff0000">d:</font>     100
    <font color="#ff0000">b:</font>      98
    </font>

    <font face="Courier New"><font color="#800080">TOTAL: </font><font color="#ff0000">666</font></font>

    <font size="2" color="#000000" face="Courier New">perl -e "$total=0; foreach $c (split(//,qq(Cachedb))) { print qq($c: ).ord($c).qq(\n); $total += ord($c); } print qq(TOTAL: $total\n);"</font>

     

     Lol and you wrote it in Perl code in all its WTF syntax!  Maybe Mumps code doesn't look so bad by comparison:

     

    set string="Cachedb",sum=0 for i=1:1:$length(string) set c=$extract(string,i),a=$ascii(c) write c_": "_a,! set sum=sum+a if i=$length(string) write !,"Total: "_sum

    C: 67
    a: 97
    c: 99
    h: 104
    e: 101
    d: 100
    b: 98
     
    Total: 666


     

     




  • I could understand if all of these rants were dated in 2006 as Cache and Intersystems have come on a long way since then, but it sounds to me if some people on this forum are as out of date as they are telling us that Cache is.

    It's not perfect but if you actually know what your'e doing (as with most languages) then you can produce some pretty damn sexy stuff (quickly). And dont be fooled into believing that database access is slow via SQL or any other means. Its like s**t off a shovel.

    I've been working with Mumps/Cache for the last 20 years and have seen so many happy users, especially the ones that have been converted from an Oracle database. I've not yet met a programmer who doesnt respect its qualities.

    Oh well, we are all entitled to an opinion I suppose. 

     





  • @menta said:

    Filed under: simple.wikipedia.org
    ... >_<



  •  Menta, I promise you that I have never worked for Intersystems or Cache ???.

     I have however always worked for companies that are customers of Intersystems and users of Cache.

     Just to set the record straight.



  • @jim40031 said:

     Menta, I promise you that I have never worked for Intersystems or Cache ???.
    Pay no attention to the troll. 'Round here, we just tie him up in the basement and let the rats take care of 'em.



  • @belgariontheking said:

    @jim40031 said:

     Menta, I promise you that I have never worked for Intersystems or Cache ???.
    Pay no attention to the troll. 'Round here, we just tie him up in the basement and let the rats take care of 'em.

     

    Ok, thanks, I'll ignore him.



  • @gaius said:

    You write in one language which compiles into more or less the same language. Smells like a macro-language if you ask me.



    Eehmm, what about the original C++ compiler then?

    As I understand it, the original C++ compiler was not intended as a final product, but rather just an interesting stop in the path to a final product.

    In any event, just because someone previously did a WTF and then went on to do amazing things doesn't mean that the WTF wasn't a WTF.

    Disclaimer: I've never actually used the original C++ compiler, and I am not aware of knowing anyone who has.



  • @jim40031 said:

    I've been working with Mumps/Cache for the last 20 years

    And this is the main reason you think Caché is a good idea to begin with. After a sufficient number of years have passed, you'll either love or hate to death the tools you're using, especially if they are the only ones you're working with. Just look at the Mainframe users: some love it, some hate it to death. You'll find plenty of users that prefer ISPF or even TSO over shiny GUIs, and some of these can actually justify their decisions. Even then, while there are those who prefer the 3270 terminal, you won't find anyone advocating the use of SNA or other defunct propietary protocol over TCP/IP; most 3270 users have some kind of TN3270 client instead.

    However, MUMPS is ugly, and the only ones that still defend it are the old timers that either built it, or had MUMPS as their first language. Most devs for the 70's and later decades have either learned FORTRAN, COBOL, Perl, C, Java or VB (ugh) as their main language. In fact, C made such an impact in language standards that most popular languages follow some variation on the C or Perl syntax. Even VB's syntax was kind of matched to C#'s syntax (compare VB6 to VB.NET) which is itself derived from C++/Java.

    Last time I checked, MUMPS "killer feature" is also one of its worst weaknesses: persistant arrays. It's bad enough to use arrays these days (most sane high-level languages have some kind of Vector/Collection/Map implementation), but arrays that actually are stored to disk are even worse; a small bug might trash everything. Oh, and unless those arrays use some kind of transactions, you're also risking dirty reads/writes and whatever. Granted, MUMPS wouldn't be the only one without transactions; the early MySQL versions used to boast about not needing any "steeeenkin' transacshuns"... since then most of the "real RDBMS" features have been added to the InnoDB Engine. I wonder how Mumps/Caché would manage that.

    Anyway... just search MUMPS in the Main Articles, and you'll find out why this language is feared amongst TDWTF readers. In fact, here you go. And another one.



  • @tster said:

     This thread has a special [s]pace in my heart.  It is because of this thread that I don't work for Intersystems (I was about to accept a job offer from them and then I read this thread and started digging more into MUMPS and asked my hiring manager to give it to me straight if I was to be supporting MUMPS).  

    Returning back after more than 6 years (!) and finding this response to my thread brings almost tears to my eyes, or at least unspeakable joy! It was actually my intention from the start that it could benefit someone.

    Good for you!

    @tster said:

    That being said, how many times are we going to bump this thread?  I mean, it's only 3 years old with at least 3 bumps from deadness already.  

     

    Answer: we will continue to bump it as long as Mumps is alive.

    It's not without satisfaction that I notice that this thread/page is the first result on both Google and Bing when searching for "intersystems cache sucks" (it seems to be high up in the results when just googling for "intersystems cache" as well, but these days you can't trust Google to give you consistent results).

    Having, since the original post, becomed both older and hopefully a little wiser, I would like to make a follow-up comment.

    The Internet is full of technology bashing: you can for every programming language under the sun easily find people that for some reason venomously dislike it and advocate something else. But this isn't like your ordinary Microsoft bashing. Most technologies, strange and cumbersome as they may be, still fall within some structure or form common to some other similar technologies. Like, a language syntax may be non-standard, but the source code is still stored in files and passed through a compiler or interpreter to transform into an executable form. Just like most other languages.

    Unfortunately, Mumps, Caché and the related technologies are so different from anything invented in the last 30-40 years that it simply doesn't fit. A mind-set impedance mismatch it you like. A true living fossil...

    To be fair, I haven't looked at Caché since the original post was written (wild horses couldn't make me). That said, I have a hard time imaging that Caché and Intersystems has managed to make significant progress in the meanwhile.

    The thing that disturbs me immensely about Caché is that it's allowed to continue to find its way into critical processes (and I'm thinking directly on health care here). Having a 40 year old dinosaur in the organization process block diagram just can't be good for progress, it just can't... And that is said knowing perfectly well that the latest buzzword technologies seldom manages to fulfill the promises. Still, there are many standard technological concepts that we take completely for granted today, but which have been developed in just the last 20-30 years.

    If Mumps would live on to support running legacy software - fine, but to continue to market it as a valid and modern solution for any problem is frankly dishonest. Computer science has learned and matured enormously since Mumps was conceived - please use this fact when planning new systems!

     

    For other articles on MUMPS, please see A Case of the MUMPS and MUMPS-Madness - they may bring additional facts and opionions on the subject. IMO these stand out from other articles on this site being that they are technology focused rather than product/company/person focused.

     

     



  • @lToro said:

    The programming language has been slightly redesigned in later versions to something called 'Caché Objectscript'. This is a lame attempt to add OO concepts to a basically dead language. It's not enough to add something called 'class' and then be done. No exception handling, no encapsulation, no typing, and so on.

    This is a typical marketing approach, just like Progress: "The Openedge Database is a relational database (with some growing Object capabilities). It was formerly known as the Progress RDBMS.". Complete vaporware.



  • @lToro said:

    The thing that disturbs me immensely about Caché is that it's allowed to continue to find its way into critical processes (and I'm thinking directly on health care here). Having a 40 year old dinosaur in the organization process block diagram just can't be good for progress, it just can't

    So when you go into a hospital and the anesthetist offers you the 40-year old anesthetic or the new one that's only been tried on one patient before you, which one do you choose?



  • @Qwerty said:

    @lToro said:
    The thing that disturbs me immensely about Caché is that it's allowed to continue to find its way into critical processes (and I'm thinking directly on health care here). Having a 40 year old dinosaur in the organization process block diagram just can't be good for progress, it just can't

    So when you go into a hospital and the anesthetist offers you the 40-year old anesthetic or the new one that's only been tried on one patient before you, which one do you choose?

    Wrong forum to ask that, some people here are still using Messenger for IM



  • A while back some guy or possibly a bunch of them built something called a silicon chip. I've heard from various friends that this silicon chip thing,although now quite old, is actually pretty good. My thinking is that Cache may even resemble this silicon chip one way or another.....Fast, ReUseable, OLD, Reliable and possibly even invented way before people actually realised all of the possibilities that it could be used for.



  • @jim40031 said:

    A while back some guy or possibly a bunch of them built something called a silicon chip. I've heard from various friends that this silicon chip thing,although now quite old, is actually pretty good. My thinking is that Cache may even resemble this silicon chip one way or another.....Fast, ReUseable, OLD, Reliable and possibly even invented way before people actually realised all of the possibilities that it could be used for.

    In recent years, much research has been devoted to the exploration of Boolean logic; nevertheless, few have deployed the development of lambda calculus. Such a hypothesis at first glance seems unexpected but is derived from known results. In this paper, we disconfirm the construction of object-oriented languages, which embodies the unfortunate principles of artificial intelligence. We use pseudorandom epistemologies to prove that the foremost extensible algorithm for the synthesis of virtual machines is optimal. Read more about this.



  • You know, a college buddy of mine is currently working for Intersystems. I'll point him at this thread, see if he can clear up whether or not a lot of these problems still exist.

    I know that Intersystems recently came out with a new code editor, which does much more than highlight syntax errors.



  • I assume your college buddy was too depressed to comment.

    I can advise that the new code editor (2012) is an improvement over the older (2008) in that the syntax highlighting is no longer so slow that it grinds your system to a halt.

    However, it still can highlight code which is perfectly valid and compiles fine, and fail to highlight code which is wrong and will not compile.

    Some of the problems I can think of off the top of my head:

    1. Lack of built in functions
    2. Built in functions are not robust enough e.g. EscapeHtml does not escape all characters used in XSS attacked
    3. Intersystems have resolved 1 of the 4 support queries I have logged with them
    4. Unpleasant behaviour like
    • open file stream
    • write to file stream
    • save file stream
    • open file stream in new process and intermittently find file stream is empty (but put a pause in the process and it works...)
    1. Really slow queries when compared with any variant of SQL I have used, data I expect in sub seconds can take minutes!
    2. Compilation does not always work first time despite what studio reports. (record so far is 3 compiles in a row before a single cls compiled successfully)
    3. Errors report lines in the compiled code not the code that was actually written
    4. Documentation is not well indexed and does not sort by relevance to the query


  • You realize this thread is a YEAR OLD right?



  • @blakeyrat said:

    You realize this thread is a YEAR OLD right?

    2006 is a year ago?



  • @Ben L. said:

    @blakeyrat said:
    You realize this thread is a YEAR OLD right?
    2006 is a year ago?

    Dude that replyed to it was replying to post from mid 2012.



  • Whatever. Point is, Tez, is sounds like you have some valid Cache WTFs, you should post a new thread where more people will be able to read them.



  •  @blakeyrat said:

    Whatever. Point is, Tez, is sounds like you have some valid Cache WTFs, you should post a new thread where more people will be able to read them.

    What is it with thread necrophilia here?  It seems that threads hang around longer here than in (insert witty place where threads hang around).



  • @drurowin said:

    (insert witty place where threads hang around).

    Richard Stallman's tattered underwear!



  • @morbiuswilters said:

    @drurowin said:
    (insert witty place where threads hang around).

    Richard Stallman's tattered underwear!

    TIL Richard Stallman wears underwear.


Log in to reply