New post
Announcement
· Oct 28, 2021

Start learning about Embedded Python!

#Embedded Python #Interoperability #ObjectScript #Python #Virtual Summit 2021 #Global Summit #InterSystems IRIS #InterSystems IRIS for Health #Learning Portal #VSCode

Welcome to day 3 of Virtual Summit 2021!  We have incredible content available to you this year and I'd just like to bring your attention to the 4(!) sessions that we have on Embedded Python.

Discussion (14)3
Log in or sign up to continue
Ben Spead · Oct 28, 2021

I just finished watching the first two videos and wow, wow, wow!!

I'll be honest, I hadn't followed the prior python interoperability work in IRIS because it always seemed to me to be more of a way to allow Python developers to get access to data and logic inside of InterSystems IRIS, and since I am already comfortable working natively inside of IRIS with ObjectScript, that didn't have any appeal to me (why would I want to learn Python in order to call into IRIS when I can already do what I need inside of IRIS?)  However, I was happy for those who already knew Python but didn't want to learn ObjectScript to have tools to reach fetch data out of IRIS, etc.

However, Embedded Python is not at all what I expected (true confession!)  With Embedded Python it looks like there is no reason for me to write Python code or work within Python in order to bring value into my IRIS-based applications running all of their business logic in ObjectScript.  I can leverage 10s of thousands of python modules (ref: https://www.quora.com/Is-there-a-comprehensive-list-of-Python-libraries) without writing a single line of Python code!  This immediately makes available all sorts of calculation, integration and translation packages which I would have had to write and maintain myself in ObjectScript or access via a more complicated self-built bridge into a Python runtime environment).  This is REALLY powerful and ATTRACTIVE to me as an ObjectScript developer, setting with an extraordinarily low bar to start using it (I only need to figure out management of .py files as part of my CICD).  I had no idea that Embedded Python would be so immediately relevant to me as an ObjectScript developer!

I think the best analogy I can come up with is the complementary power of ObjectScript and SQL which I rely on every day.  No one would want to use ObjectScript without the various ways of executing SQL from within the environment.  You could do it (iterate through objects / globals to fetch the data elements that you want) but why would you want to when you have the power and elegance of SQL to simplify data access for you?  I see Embedded Python as having the potential to be just as powerful as SQL within my ObjectScript application, but exposing *reusable logic* to me, rather than exposing *data*.  Leveraged properly, Embedded Python has the promise of drastically cutting down what I need to implement myself in ObjectScript ... if I can find a Python library that already does what I want, then I can wrap that in a couple lines of ObjectScript and start using it immediately.  That is so incredibly powerful.

Thank you @Bob Kuszewski  and team for bringing this new feature into InterSystems IRIS - I look forward to seeing how we can use it to make ObjectScript-based application development even faster than before!

4 0
Robert Cemper · Oct 29, 2021

In past, I have seen so many "re-invented wheels" on COS that were mostly kind of remakes of
existing packages or solutions. Though this is impressive from a coding point of view,
it is just a waste of energy from point of view of a project AND its maintenance.

I had similar experiences with SQL that was refused by "experienced" programmers
insisting on horrible $ORDER() / $QUERY() constructs almost un-supportable, to gain
a few microseconds of performance on a weekly report. 

The deeper reason: nobody explained it and trained them.
That's the behaviour to avoid. 

1 0
Guillaume Rongier · Nov 19, 2021

The king is dead, long live the king! is a traditional phrase that is proclaimed at the advent of a new monarch in France.

May I say: IRIS is dead, long live IRIS!

This is what I feel with the arrival of Embedded Python.

The old monarch spoke ObjectScript, he allowed us to accomplish great things but now let's stop looking back, let's move forward. Let's induct the new monarch who speaks Python. Let's stop worshipping his father and let's make room for the new generation.

That's why I think, we must stop coding in ObjectScript, we must strive to use Python, everywhere in IRIS and this without the wrapper ([language = python]).

Why be so radical?

  1. Coding in Python is to show by example and in a language that the uninitiated know and thus prove the extent of the possibilities of IRIS
  2. Coding in Python is to start answering and finding solutions to the new problems that we will encounter:
    a. How to integrate .py files in our CICD pipes
    b. How to integrate PyPI with ZPM
    c. How to elegantly expose future APIs coded on the Flash Framework with IRIS and CSP gateways
  3. Coding in Python encourages InterSystems to produce new packages in Python rather than ObjectScript.

Choosing your programming language in IRIS is a political act.

  • Coding in ObjectScript is to be conservative.
  • Coding in Python is to be liberal.

Choose your side.

2 0
Ben Spead · Nov 19, 2021

@Guillaume Rongier - an interesting (and indeed radical) take on this ;)  I agree that broader use of Python will allow gaps and new best practices to be identified more quickly, to the benefit of all.  Your suggestion of not needing to use [language = python] is thought-provoking ... have you logged an enhancement to allow a descriptor at the class level which will allow python to be assumed across the entire class without requiring the python language to be specified in each method?  

I am generally quite conservative in nature, but your 'liberal' ideas are indeed thought provoking ;) 

0 0
Guillaume Rongier · Nov 19, 2021

@Ben Spead

With Embedded Python, code can (and should?) not be stored in the databases and still be executed on the server side with the irispython interpreter.

Here is a GitHub link that demonstrates the use of embedded python with a backend on the Flask micro framework + Iris as a database.

It is true that Embedded python will change a lot of our paradigms, best practices, reflexes.

That's why we, as ObjectScript and IRIS experts, must try to use it as much as possible.

We will have to go out of our comfort zone and it is essential, it is up to us to go towards the python community because the opposite will not happen.

Regarding the [language = python] tag, I'm not saying it's useless. It can be useful in some cases.
I just think that it should not become the norm.

PS: My previous answer is indeed provocative and this is to draw attention to Embedded Python which is not a feature but a major evolution (Révolution ?).

1 0
Aleksandar Kovacevic · Dec 1, 2021

I agree with you Guillaume, Objectscript is very powerful language and more you know it, more you get to realize just how powerful it is. But this comes with a years and years of experience. This experience is harder and harder to find nowadays in the market. That is why when talking about programming languages, the world has moved on from creating proprietary languages in favor of standardized ones, exactly for that reason. If you know the language already, it will take you much less time to get up to speed.

Having Embedded Python there as a equal to Objectscript allows IRIS Data Platform to get much better attention from the developer community world-wide, exactly the one it finally deserves.
 

0 0