Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I used to work at Epic, where this language is used to implement much of the leading healthcare system in the United States. Many people there encouraged me to refer to it by different names like "M," "InterSystems Caché," "Caché," or even to my surprise "C."

I'm very, very happy to not be using this language anymore. After my first year on the job, I read some JavaScript code, and I nearly wept at how comparatively beautiful it was.



Years ago at another company, we got acquired and had to port our shrink-wrap application from Oracle to Cache and support both. It was a horrible experience. The cache sales support guy bought our lunch a lot though. That's something.


Lots of people called it Caché, but I don't think anyone would dare have called it C??

I found Epic MUMPS to be remarkably readable. Lots and lots of documentation, quite consistent coding standards, and although I would have preferred to write SQL queries rather than MUMPS routines, I didn't find it that abhorrent.


As I understand it, M is the name used for the ANSI standardized version of MUMPS (ANSI X11.1-1995) and Intersystems Cache is a commercial implementation of that standard.


Why did they encourage you to refer to it by different names? In what context?


"Mumps" is a pretty awful name to use for the purposes of healthcare software. You might as well call your database system "Cancer".


There is a section called "'MUMPS' vs. 'M' naming debate" in the wikipedia article. https://en.wikipedia.org/wiki/MUMPS

"Some of the contention arose in response to strong M advocacy on the part of one commercial interest, InterSystems, whose chief executive disliked the name MUMPS and felt that it represented a serious marketing obstacle. Thus, favoring M to some extent became identified as alignment with InterSystems."


>After a year of M, JS was comparatively touchingly beautiful

That's all the convincing I'd ever need. Though having a built-in optionally-persistent B-tree-based store sounds interesting.


SQLite has been in Python for ages, and before that gdbm and friends...


Clever. By "built-in" I didn't mean just "available" as through an API to a third party library (which is a full blown DBMS in your first suggestion), I meant "integrated" as common types are (and lightweight)


They've seriously been "integrated" and "lightweight" in Python forever, though. The shelve module has existed for maybe twenty years?

SQLite will still perform better though, "heavyweight" SQL syntax notwithstanding.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: