The future position of ObjectScript

Article

Robert Cemper · Jul 15, 2021 4m read

#Embedded Python #Languages #ObjectScript #Python #InterSystems IRIS

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.
And 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.

ObjectScript

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.

History

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.

Today

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.

Future

> 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

Marcio Jose Ped... · Jul 21, 2021

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.

3 0

Anna Golitsyna · Jul 19, 2021

Very interesting. If reading ObjectScript is ancient what can one say about pure, unadulterated MUMPS ? 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.

0 0

Robert Cemper · Jul 19, 2021

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.

4 0

C as in this: C - InterSystems Programming Tools Index - Caché & Ensemble 2018.1.5 ? I understood about the main idea of a rarely used language, yes. I was just additionally interested in the accessing DB speed since ObjectScript seems to offer a noticeable overhead.

Dmitry Maslennikov · Jul 19, 2021

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

Alexey Maslov · Jul 21, 2021

GSIZE is way faster than the analogous ObjectScript functionality

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

1 0

Anna Golitsyna · Jul 21, 2021

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.

2 0

Vic Sun · Jul 22, 2021

FYI, just a plug to avoid $zu commands whenever possible, as they're internal/deprecated and subject to change. $zu(12) can be replaced by %Library.File.NormalizeDirectory().

Here are the docs with almost all the $zu functions' modern replacements.

https://docs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=RCOS_replacements

Robert Cemper · Jul 22, 2021

you can avoid $zu(12) by

include %occFile
$$$FileMgrDir

Alexey Maslov · Jul 23, 2021

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)
f:\intersystems\cuni\mgr\
QMS>w $zu(12,"")
d:\bases\qms\

My writing was just a result of quick prototyping using the terminal. Just for curiosity, I dived into %occFile.inc 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.

Robert Cemper · Jul 23, 2021

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.

Nigel Salm · Jul 21, 2021

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.

Nigel

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.

Mikko Laitamäki · Aug 4, 2021

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.

Timothy Leavitt · Aug 6, 2021

I've found writing applications INSIDE the DB environment to be the single coolest thing about InterSystems' technology. The code itself being stored in the database and accessible through both object and relational modes (just like the actual data) makes metaprogramming a really natural part of the language.

Evgeny Shvarov · Aug 6, 2021

Interesting, @Timothy Leavitt! Do you use metaprogramming at work? Could you please share an example - and even hope we have it on the OEX?

Timothy Leavitt · Aug 16, 2021

@Evgeny Shvarov anything with CodeMode=objectgenerator, typical uses of projections, anything that works with %Dictionary.(.*Definition|Compiled.*), anything that works directly with %Library.Routine / %Library.RoutineMgr... there are examples all over the place, including throughout both of my Open Exchange projects.

https://openexchange.intersystems.com/package/Test-Coverage-Tool
https://openexchange.intersystems.com/package/apps-rest

These don't go to the level of dynamically modifying/instrumenting code, but another of my projects (a mock framework for ObjectScript, still internal to InterSystems) does.

Evgeny Shvarov · Aug 17, 2021

Though I agree on the power of generators and projections IMHO it significantly raises the complexity of solutions. And I'm not sure how popular is the usage amongst the community, we could make a poll.

Moreover, I met the opinion that some powerful features of IRIS like indirection are completely useless and dangerous (I disagree of course as a fan of indirection).

I'm 100% for the usage of powerful things if we can keep readability and maintainability.

And of course, people will use the technology immediately once see the obvious value.

Timothy Leavitt · Aug 17, 2021

@Evgeny Shvarov, the power of generators and projections is more in the creation of frameworks/tools that speed up building solutions. This includes many parts of IRIS itself, but moves into the user space for larger/more complicated applications (e.g., what we've done with AppS.REST both for REST-enabling older ObjectScript-based applications and for quickly building out new applications using IRIS and modern web technologies).

Robert Cemper · Aug 6, 2021

No doubt, that it is a great environment for what I classify as ARTISTS.
But consider the maintenance of such ARTWORK.
It is a painful to impossible exercise to find and educate someone to replace a lost ARTIST.
Think of the masterpieces of the Italian Renaissance whether in sculpture or in painting.
We just don't understand the incredible technique they used.
Most famous case: Leonardo Da Vinci's "Last Supper" in Milan.
It is broken and just a shadow is left. Up to now, nobody was able to fix it in an acceptable way

If only da Vinci had provided explicit documentation (preferably written above the painting, in Latin) about how to maintain it going forward...

Ben Spead · Aug 16, 2021

I completely agree with @Timothy Leavitt here. Besides the speed of the DB, the core value of Caché (now IRIS) for the past 2 decades that I have used it has been the ability to create just about anything I needed within an application without needing to bolt on additional tools, additional layers, additional languages, or additional dependencies. Directly access business logic on the server from the web page, directly instantiate and work against objects anywhere in your code - there is no 'throwing things over the wall' to the DB guy, or to the microservice guy, you just code what you need in ObjectScript and be done with it.
To @Robert Cemper 's point below, I really don't think it takes an Artist to be able to write and support this kind of code, just a talented developer with some good OO skills. I do think you need to be able to find Artists to support the legacy M applications which are still floating around, but it is pretty straight-forward to get the full power of the stack for new applications while avoiding modes of use which would require a "Priest" to be able to interpret it in the future.
Having recently been involved in another initiative for several months that was not DB-centric development, and having witnessed how much harder it seemed to be and more time intensive to piece together the different disparate technologies at different levels of the stack in order to make a full solution, it reminded me of why I fell in love with Caché in the first place and made me excited to get back to full stack dev in on a single integrated platform :)

Robert Cemper · Aug 3, 2021

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

Vitaliy Serdtsev · Aug 17, 2021

Don't pay attention, someone very needs an Apple iPad.

I found a very interesting article about a very ancient language, but it's not Mumps :
Banks scramble to fix old systems as IT 'cowboys' ride into sunset

Robert Cemper · Aug 17, 2021

Thanks @Vitaliy.Serdtsev !
It is hard to believe but in the area I live COBOL is still better known than anything from ISC.

Thank you for the very thoughtful article @Robert Cemper !! Definitely some good ideas to muse on ....

Sean Connelly · Aug 17, 2021

Here are some arguments for the future of ObjectScript.

Tim Berners-Lee on the Principle of Least Power:

Computer Science spent the last forty years making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. The only way to find out what a Java applet means is to set it running in front of a person.

To steal a line from Jeff Atwood:

Atwoods Law: "Any application that can be written in ObjectScript, will eventually be written in ObjectScript."

And Dudley Moore...

~~Volvos~~ ObjectScript, boxy but good

That's what is scaring me:
"Any application that can be written in ObjectScript, will eventually be written in ObjectScript."

and the reinventing of wheels will go on ....

Sean Connelly · Aug 18, 2021

~~Not sure I understand, does ObjectScript cause programmers to reinvent wheels?~~

I agree, there are many wheels that need not be built inside IRIS, but Atwoods law is not advocating for this.

Consider this premise first...

"Any backend application that is to be written in IRIS could be written in many different languages".

and now Atwoods law...

"Any (backend IRIS) application that can be written in ObjectScript, will eventually be written in ObjectScript."

In my own words, the simplest solutions mostly come with the simplest of languages.

So for me, the future of ObjectScript is ObjectScript.

Jack Huser · Sep 29, 2021

Thank you very much @Robert Cemper , I like your point of view.

José Ademar de ... · Jan 12, 2022

Despite being a junior, and having this contact with COS, and comparing with other programming languages I've seen, sometimes I find some things in COS quite difficult to do while in other languages it becomes much easier, I think is difficult to find someone that it's starting as a developer to be interested to learn COS because there are so many new technologies that are so powerful e much easier to learn.