Robert Cemper · Jul 15 4m read

The future position of ObjectScriptContestant

I'm aware that some people might not be pleased by this article.
So I underline that this is my very personal view based on
working in this industry for more than a half-century.



If you develop in IRIS you are confronted with two major phenomena:

  • an incredibly fast and excellent designed data storage engine
  • a scripting language to work on this storage engine, actually named ObjectScript 

Storage engine 

It is a hierarchically organized storage concept and was considered as
"old-fashioned" when "relational" was the Buzzword of the season.
Though - if using its strengths - it outperformes with its slim and efficient
construction all its "Sumo"-shaped competitors.
An this is still true and unbroken since day 1.
It's amazing to me how those competitors copied over time various features
of this storage engine indirectly confirming the quality of the basic concept.


Looking at the language it is rather easy to separate the rather narrow set of language 
elements that manipulate and navigate the storage engine that has seen just a few
extensions and some polishing over decades. I call this the CORE. 
Its companions are Navigation (mostly similar to other languages)
and Cosmetics (everything to manipulate data content).

Navigation is an unavoidable structural requirement but has seen several additions
mostly for programmers' comfort. Not required but similar to newer languages.

Cosmetics is the fastest-growing field and until today its offers surprise me every
now and then. Its existence results from history where the Storage Engine was also
part of an operating system and nothing else on the HW. 


From the past, developers were used to write applications with ObjectScript.
Even InterSystems did this on large scale (Interoperability aka Ensemble,
Analytics aka DeepSee, Health*...)  ObjectScript was/is the "can all, does all"

But ObjectScript was rather a "Lonely Ranger". Attempts to have something more
popular on the market was BASIC. (Already a "dead horse" at that time.)
The chance to jump on the JavaScript wave was missed ~15 years ago.

The availability of a wide range of language adapters could  hide the dimension
of the issue for some time, But it never reached the strength that the main 
competitor showed when PL/SQL was frozen and replaced by Java. 


I see the number of qualified developers in ObjectScript shrinking over time by pure
demoscopic effects. Finding and educating developers willing to write ObjectScript
is a hard exercise that I experienced personally several times. And even if they are
bright and highly skilled it is no guaranty that they will stay with you.
Demand is still rather dramatic.

In front of this background, I see the upcoming of Embedded Python as full-size 
language at the same level as ObjectScript as a major step forward with IRIS .
Navigation and Cosmetics are covered in public and adding the CORE functionalities
doesn't require a dramatic learning step. So we see a much larger market of skilled
development resources and the isolating uniqueness of ObjectScript and 
its limitations is broken.


> With Python, I see a lot of new energy entering the world of IRIS. 
After all, a step that some competitors did quite some time ago and this
flaws of "never seen anywhere else" has been overcome.

> The paradigm: "I write it, just because it is possible" will be broken.
This releases us from a series of reinvented wheels.

> ObjectScript will still live in parallel and have a significant role in all
activities close to the storage CORE. No one (hopefully) will use it for 
business logic or mimic interfaces that are available on a much
larger scale outside already.  

> ObjectScript will shrink to a dimension that we see today for C, C**
or for code in whatever Assembly language. Existing applications
will not be affected. The way Python was integrated seems to be
a guaranty for a smooth migration without time pressure. 

> Today's ObjectScript developers will not lose their jobs nor run
out of demanding work. There are enough challenging tasks left
around database design and maintenances. 
But they could get rid of (in my eyes) unattractive tasks of
CSS styles, coloring web pages,  . . . .

> Not to forget the demanding challenge to read and understand 
existing code and interpret and communicate its content and logic.
"GolfCode" may look like fun, but it is a deadly earnest business
logic in many old traditional written applications and even some
utilities in "%SYS".

> I see today's developers as the priests of ObjectScript similar to the
Egyptian priests understanding hieroglyphs, reading "The Book of Dead"
and celebrating their miracles.

July 15th, 2021

4 0 17 622
Log in or sign up to continue

A personal note.
I attend a job interview couple of months ago and was asked to write a small application in Ensemble.
Insted of use BPL in graphical mode, I prefered to code in ObjectScript directaly. Not old fashion MUMPS GolfCase, but present camelCase, JavaScrit like structured code.
I believe the evaluator dont liked the ObjectScript beeing used that way and I was not selected.
Still wondereing what I did wrong.

Funny. The job position still open.

Very interesting. If reading ObjectScript is ancient what can one say about pure, unadulterated MUMPS smiley ? That was rhetorical, of course. I wonder how speed would fare with Python. GSIZE is way faster than the analogous ObjectScript functionality, at least for Cache 2017 that I use.

Thanks for the input. (I was waiting for it)
If someone goes for speed I'd suggest  C or Assembly Language That's where ultimate speed lives.
As long as speed is available in the cloud for a few $$$ more. It's only interesting by principles not in reality.
The key  - in my opinion - is to break the chains of a rarely known scripting language compared to others.

Nowadays I would look to Rust, which is good replacement for C, and should as fast as C.

GSIZE is way faster than the analogous ObjectScript functionality

%GSIZE is written in ObjectScript. What "analogous ObjectScript functionality" do you mean?

You are right about GSIZE. The other, slower functionality I had in mind is below:
set statement=##class(%SQL.Statement).%New()
set status=statement.%PrepareClassQuery("%SYS.GlobalQuery","Size")

 set status=statement.%Execute($zu(12,""),,GlobalName,,,FastFlag)

runs fast enough with FastFlag=1.

you can avoid $zu(12) by

include %occFile


Thanks for the good advices, guys.
Robert, you should be aware that $zu(12) (a.k.a. $$$FileMgrDir) is usually not the same as $zu(12,""): 

QMS>w $zu(12)
QMS>w $zu(12,"")

My writing was just a result of quick prototyping using the terminal. Just for curiosity, I dived into and there was no macro to get the current directory. It is possible through class method call (##class(%Library.File).NormalizeDirectory("")), while all this stuff looks like a great overkill for such a small sample.

Thank you @Alexey Maslov !
This sequence is the best illustration I could wish of "the priests know what to do"
It's nothing that the average developer of a business application needs.

Agree with you: to guess that the "kosher" way to get a current directory is to call 

set currentDir = ##class(%Library.File).NormalizeDirectory("")

one should not be a priest; being a modest monk should be quite enough.

I tend to fall somewhere in the middle. I think that python has a great future within ISC products but I also feel that there is a place for objectScript as well. I would hate to lose objectScript but I guess ill only know once I have become fluent in Python with a little bit of R and Julia and maybe some RUST and don't forget (Angular, React, Vue, Node).js The main point is that for an IRIS developer you have so many choices to use for specific use cases and I can't think of another environment that offers that flexibility with such elegance and simplicity.


I don't think ObjectScript might be lost.
It will just fade out of applications development into "specials".
Though the question. "Why to write applications INSIDE a DB environment at all?"
still remains open and unanswered.

Becasue then you dont need to think about implications and cost of database access, you can write code that fetches same  data  multiple times and  it might still perform quite fine. if you do the same over odbc or jdbc you will get blamed.  

Thanks for the DOWN VOTE, anonymous voter.
It confirms my initial suspicion that someone may dislike my projection of future