Imagine first time learning interSystems after you have been a developer for more than 5yrs

It all depends on your learning style.

For me I rather learn as I am building so it was trial by fire as we were migrating from SeeBeyond eGate to InterSystems Ensemble (2014.1) at the time by a certain deadline. I learned a lot on the fly by reading the Developer Community posts, reaching out as needed, and just playing around with the code as I was building it. I also had my company by Cache Objectscript and MUMPS, at least so I can search for a Reference when figuring out syntax. 

The Learning site as a lot of good and informational courses you can take as well.

By the time I started learning ObjectScript, I had already been exposed to varying degrees to Java, javascript, PHP, C#, C++, Visual Basic, Python, and ActionScript, so to me it was different, but I was kind of used to finding my way around the quirks of a new object-oriented language.

One thing that does make it more difficult with ObjectScript in this community, though, is that so many things can be abbreviated in code, and that makes it harder for beginners to read and follow up on. For example, you might see {}.%New() or {}.%FromJSON(). It might take some time to figure out that if you want to look up further documentation on what that is, you have to look at the %Library.DynamicObject class, and that you could also use ##class(%Library.DynamicObject).%New(). Commands like set, do and for get shortened to s, d, and f. Functions like $ZDATETIME get shortened to $ZDT. We mention things like $$$ThrowStatus assuming you'll know that if you're writing a routine, you have to have #include %occStatus at the top to use that.

It's something that, once you figure it out, it's easy to understand, but those of us writing articles on here could also do a better job of writing our code samples to be readable.

LOL. We have a couple of developers who came from different disciplines: full-stack, Java back-end, etc that might have a lot to commiserate with here. 

When I was first learning COS, I came from knowing Java and C++ and what I found most useful was having the ObjectScript intrinsic function reference: https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

For some reason, I could navigate the class documentation and puzzle the rest out, but the intrinsic functions seemed a thing of their own and are very useful for basic functions BUT the syntax for the functions would throw me off and are often abbreviated ( $ZD means the same thing as $ZDATE, whut?) and once I got the hang of those, I could read the code better and things became okay. 

The other thing that helped was learning how to execute code from the Studio window (or Terminal) to try things out. 

Most annoying "feature" when i started to learn objectscript was the very strict left to right processing

e.g. if a>0 & b< 0 {} get evaluated as (((a>0) & b) <0) not as you would expect (a>0) & ( b<0)

also very strange variable casting from number to string.

e.g
set a=1
set b="7 dwarves"

w a+b

actually return 8 instead of e.g. concatted string "17 dwarves"  or a variable casting error as in other languages 
But meanwhile i love it :D

I first learned objectscript and started to learn other languages. Comparing that, objectscript is pretty easy as python. Straightforward to logic and no type declaration is mandatory. IRIS is combined the features of cache and Ensemble. I.e database with interoperability. IRIS has two versions I am not sure which one you're learning one for Health care and other for general use. Still time zone issue persists in iris let's see they can solve in future versions.  

5 yrs as full stack developer

• what language ??
• how full ??

I was Java developer for more than 15 years and for me to use arguments by reference was totally disgusting, you can use it in Java, but it's not very common, in Objectscript is the opposite, Output arguments are the rule, no the exception.

Calling instance methods using variables not declared as arguments made me feel dirty.

Keep this page bookmarked at all times and reference often, even if you think you know a command: https://docs.intersystems.com/iris20241/csp/docbook/DocBook.UI.Page.cls?...

If you can get to know all these commands intimately, you'll have a deep understand of library classes and methods and also INT and MAC code. 

I really enjoy taking things apart and breaking them down into basic components to see how they work. I found it useful to insert break statements in a confusing piece of code and run it from terminal (can also use the ObjectScript debugger from VS Code with breakpoints). Then I could write out the values at each break and reverse-engineer what the command/method must do. I also really enjoy the ability to drill down into the code and read the definition of a method. If you are curious how any method works you can just Ctrl+Click from VS Code to go to that method's definition(Ctrl+Shift+G from Studio).

Two major things: the data structures at your disposal and when and how to use them, and the fact that your code is in the database (which enables some super cool things but also makes other things harder). Another way to put this would be both "how to use (much) older/more basic language features and functions well" (as others have alluded to with the command/function references) and "how to get the most out of object-oriented programming and IRIS' unique strengths" (particularly, having object-orientedness and all your code right in the database).

Re: data structures, basically you have $listbuild lists (which are just linked lists) and the swiss army knife of sparse arrays. If you're building or working with a simple list of any sort of datatype, or with delimited strings as input/output, $listbuild lists are super helpful and more natural to work with than strings. If you're doing pretty much anything else, you want an array. For general coding and algorithms, these are simpler to use (once you know the syntax) and faster (at runtime) than the %Library.List*/Array* classes you're likely to gravitate toward. That is not *at all* to say that you should write your code all your code in .MAC routines like it's the 1990s - although, depending on the environment you're learning in, you might see some of that.

The simplest value proposition of IRIS (in my opinion) from a general development standpoint is:
Write a class (that extends %Persistent), compile it, you get a table - then you can naturally work with the same data from an object-oriented or relational perspective, whichever is most natural. Both of these models are just thin wrappers around our super fast under-the-hood data structure. Every database has one of those, but with ours (called "globals"), if you want that extra 5% performance boost you can see and work with it directly (although you shouldn't really need to).

But on top of that, your code is in the database, and that means you can interact with your own code from an object-oriented or relational perspective using classes in the %Dictionary package. This enables all sorts of amazing metaprogramming techniques that end up being more natural in ObjectScript than any other language I've worked with. (Disclaimer: I've spent way more time working in ObjectScript than any other language, so take this with a grain of salt.)

The drawback to your code being in the database is that you're probably used to it being on your filesystem, and that means you may need to think differently about source control than you usually would. If you're working through interoperability editors or with IRIS BI, you're already modifying code in the database directly, and should adopt an "embedded source control" workflow - I'd recommend https://github.com/intersystems/git-source-control for this if you're not sure where to start. If you're not using interoperability or IRIS BI, you can work more or less the way you're used to with VSCode, keeping in mind that what really matters is what's running / has been saved to the IRIS instance (rather than what's on your filesystem).

Have you just joined a team that's using ObjectScript extensively and has background in it, or are you learning on your own?

You may have already fond this in this community, maybe not: 

Caché ObjectScript Quick Reference  (aka "the Cheat Sheet")

Great topic! I can also recommend this article which proved to be handy for developers on other languages to start with ObjectScript.

Full stack developers don't actually need to learn ObjectScript to use IRIS: everything can be done in JavaScript.  Unfortunately this isn't something that is very well known or understood, which is one reason we've just released this repository which will hopefully get you started and show you what's possible using our mg-dbx-napi interface

https://github.com/robtweed/mg-showcase