I just asked "How do I change my password in InterSystems Server Manager in VSCode?"

It gave me three answers: the first one was outdated, the second one was a bad idea, and the third was the right one.

This is old enough to post a spoiler now - I got down to 35 with the *i trick; what's the 34-character solution?
 

Class ascii.ascii
{

ClassMethod ascii()
{
 f i=32:1:126{w:$t(+6)'[$c(i) *i}
}

}

(but the solution is dependent on compilation flags - not sure if that invalidates it)

38 characters for me. :)

I got a question from an intern having trouble writing out to a specific file using %Stream.FileCharacter, and thought I'd see how DC AI would do: https://community.intersystems.com/ask-dc-ai?question_id=150746

Not bad! Not quite the way I recommended, so it's just a reminder to give the DC better input. ;)

Thank you for the writeup @Shuheng Liu!

Not much to add other than the same pointer.

I strongly relate to this. Zen was a huge part of what sold me on InterSystems tech 15 years ago when I started here as an intern - for all the reasons you've described - and if I want to throw together a really quick POC that just has results of a class query shown in a table, with maybe some basic interactions with the data, I might still use it.

That said, for my team's work and even for my own personal projects, I've found the combination of isc.rest and isc.ipm.js to be *almost* as quick as Zen. With something like Angular with an IRIS back-end (consisting of a bunch of %Persistent classes), you need to write:
1. REST APIs for all your basic CRUD operations, queries, and business logic
2. Client code to call all those REST APIs
3. Client code for all the models used in those REST APIs
4. The actual UI

Suppose you want to make a simple change to one of your models - say, adding a property to a class and making it available in the UI. With Angular, this probably means changes at all four levels; with Zen, you get to skip 1-3 entirely. That's compelling. An inevitable side effect of this is that your application's API surface (and therefore attack surface) is enormous and near-impossible to fully enumerate. It is possible to secure a Zen UI, but much easier to shoot yourself in the foot.

isc.rest makes (1) super easy - add a parent class to your %Persistent class and do a few easy parameter/method overrides to get CRUD and queries basically for free, and write a bit of XML if you want to do fancier things to expose business logic or class queries. This provides enough metadata to generate an OpenAPI spec, which can then be used to automate (2) and (3) with the help of openapi-generator. So while you can't skip 1-3 entirely, this toolset makes it all significantly faster.

You might want to submit that here: https://community.intersystems.com/post/3rd-intersystems-ideas-contest

I like this in combination with a global mapped to %ALL that has:
^SYS("ConfigDatabaseOverride","BAR")="^^:ds:BARCONFIG"

So prior to references to the possibly-mapped global, you'd look to see if there's an override for the current namespace, and if there is, use it.

This is wicked cool! Thank you for sharing.

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?

I tried out GPT 3.5 for ObjectScript a while back just for fun, and it came up with some really plausible-looking hallucinations with class names that don't exist, but sound like they could. GPT4 is probably better, but I still find it likely that a beginner to intermediate developer would end up getting confused about why the output doesn't work.

I have a lot of opinions about good programming patterns in ObjectScript (especially in intermediate-to-advanced areas), and I doubt there's enough publicly-available good ObjectScript code in existence to serve as training input.