In this episode, hear about the InterSystems ObjectScript extension in Visual Studio Code that allows developers to easily connect to their InterSystems IRIS instances and write ObjectScript in a familiar and lightweight environment. Product Manager Raj Singh joins Zack Krowiak to discuss this topic in detail!
For more information about Data Points, visit https://datapoints.intersystems.com.
Derek Robinson 00:00:02 Welcome to Data Points, a podcast by InterSystems Learning Services. Make sure to subscribe to the podcast on your favorite podcast app. Links can be found at datapoints.intersystems.com. I'm Derek Robinson. And on today's episode, you'll hear an interview between Zack Krowiak and Raj Singh about the ObjectScript extension in Visual Studio Code.
Derek Robinson 00:00:39 Welcome to Episode 15 of Data Points by InterSystems Learning Services. If you caught our last episode, you heard about the Experience Labs that we held during Virtual Summit. If any of those caught your interest, be on the lookout — we're converting those labs into exercises that will be available in our learning catalog. So you can head over to learning.intersystems.com to check it out. In today's episode, my colleague Zack Krowiak will interview Product Manager Raj Singh. Raj is a Product Manager for the Developer Experience here at InterSystems. And one topic that falls squarely into that area is the ObjectScript extension for Visual Studio Code. This extension allows developers to work seamlessly in a familiar, free, and lightweight IDE like VS Code. So without further ado, here's Zack's interview with Raj.
Zack Krowiak 00:01:27 All right. Raj Singh, welcome to the podcast. Thank you so much for joining us.
Raj Singh 00:01:31 Thanks for having me.
Zack Krowiak 00:01:33 Yeah, so let's get started. So could you start by talking a little bit about how this project evolved from an open-source project, with Dmitriy, to a community collaboration with InterSystems?
Raj Singh 00:01:43 Yeah, so it was, this is pretty much a new process for InterSystems. We dipped our toes in the water earlier in 2019 with some open-source releases around iKnow and some other smaller things, less visible, but tackling an IDE, which is something all of our developers touch almost every day, if not multiple times a day, was a big commitment. A lot went into that decision, but that was partly mitigated by the fact that the ObjectScript extension that Dmitriy Maslennikov had already launched, had already shown a lot of popularity. There was hundreds of installs. People were using it every day. So from that perspective, it wasn't too scary. But just from a process perspective, we bank our reputation on sterling customer support and reliability, and so those kinds of things are easier to achieve when you have more control. So going to embracing open-source introduced a lot of degrees of freedom that we didn't know if we could be comfortable with. So we went into this with a good amount of research that showed that Visual Studio Code was a really solid platform. Very popular. Developers were coming to it in droves — first development platform to garner over 50% usage rate across the whole developer ecosystem, that I've ever seen, in years and decades, probably. So there are a lot of strong signs pointing to Visual Studio Code being a terrific platform to build upon. And then we had some of those signals that the ObjectScript extension that Dmitriy had created was also a good place for us to start. And so we went into the spring with the decision to try this out, and we would see how it would go in terms of our culture fitting in with the community culture, and having that collaboration process work well. You can't know until you try it out.
Zack Krowiak 00:04:03 Wow. That's great. Thank you. And yeah, you mentioned support a
little bit there, and how this presents a unique opportunity and challenge for supporting a product because it is open source. Could you talk a little bit more about that, and how getting support for this extension works?
Raj Singh 00:04:17 Yeah. And this will be a bit confusing for us and probably a little confusing for customers, at least at first, but this there's going to be a new model for this. First of all, for
those of you who may be long-term customers, you can always do what you've always done.
Call in to WRC, talk to your favorite rep, and really get help through whatever problems you're having. But we'd also like you to consider first going to GitHub Issues and starting your support journey there. First of all, because if you're having a problem, somebody else probably is having the same problem. So you can probably get a lot of insight just immediately, in the middle of the night or whatever. You might even solve it on your own. Secondly, if you're having a problem, somebody else, even if they haven't reported an issue, is probably having the problem today or might have it in a month, and you can pay it forward and help somebody else out down the road by keeping your journey around fixing your issue in the public. So that is a lot of reasons why we should start with GitHub Issues whenever you have a problem. You definitely want to put enhancement requests on GitHub Issues, because that is where they're going to be triaged. This is a community project in the open completely. And so the project management committee, which is going to review all the enhancement requests and figure out whether or not to work on them, that's all going to happen in the open, and only things that are on GitHub Issues are going to be considered.
Zack Krowiak 00:06:04 Right. Thank you. So you go to GitHub to both put support requests and also provide your feedback, and that's all through the same streamlined approach?
Raj Singh 00:06:15 Yeah. For those of you who are GitHub veterans, you'll get that pretty easily, but for those of you who are new to it, it may feel a little bit foreign at first, but you should quickly get comfortable with it. So issues is maybe a little bit of a misnomer; it's a place to start a discussion on a particular topic. And then as that topic evolves, it could go from a bug report to an enhancement request if you filed it wrong in the first place, or it could go the other way. The important thing is that if there's some friction in your experience, if there's some problem you're having, or something you just want to say, is great. You always go to a single place, GitHub Issues.
Zack Krowiak 00:07:04 Right. Thank you for that. And yeah, I know you also mentioned before that you can actually access that the link to the GitHub right from VS Code, if you just go to the
extensions page. So could you talk a little bit…I'm curious a lot about the different elements
of the extension, or really extensions, now — I think there is now like four extensions that are
part of a bundle. In particular I'm interested in the language server. Could you talk a little bit more about that? What's the language server's role in this ObjectScript extension bundle?
Raj Singh 00:07:35 Yeah, so the language server is really what differentiates this from what
it was six months ago. The language server is a little piece of software that sits on your
computer, on the same computer as Visual Studio Code itself. But it's a separate executable. It's a separate little process running, and it mediates communication between your IDE and your IRIS or Caché server. And what it's doing is, as you type, every single character you type, it's going and figuring out on the back end in the database, whether there's some information it can provide to make your coding experience better. So what we see, what that means, is that if you want to do code completion, variable completion, get some documentation on a built-in class, or one that you've one that you've written yourself and have already compiled to the server, all that rich information comes through the language server, constantly being in communication with the server and knowing the whole class, the whole code base that's already in the server, and how basically the language interacts with the database. So the language server is…otherwise you would have to have all the smarts right in the extension. And A, first reason why that doesn't work well is that we can't ship your code inside the extension, so that wouldn't work well. And B, it's not an extensible way to do things. It would create a huge extension for you to work with. And it would have to be versioned for, it would have to be specific for every database version. So having a language server allows us to do amazing syntax coloring. It allows us to have your coding experience tailored directly to whatever version of IRIS or Caché you're using. So whatever classes exist on that instance of the server will be exposed to your programming environment through the language server. And in the future, it will allow you to even have languages within languages within languages colored perfectly. So if you're writing SQL inside an ObjectScript routine, those will be colored separately. You might be writing a Python routine inside of an ObjectScript class that will…the Python will be colored with Python syntax, the ObjectScript will be ObjectScript. All those things will be mediated through the language server.
Zack Krowiak 00:10:20 Wow. That sounds like it's going to be a massive boost to productivity, and just making your experience as a developer so much smoother insofar as you can just see the whole code base that you're working with. And all of those, like nested syntax, colorings, as you were talking about. so, I'm curious about a couple things. First of all, if I'm coming from the days of Atelier, can I still use Atelier? Or is Atelier being deprecated?
Raj Singh 00:10:51 Atelier is definitely being deprecated or sunset. It really, VS Code already does more than you can do at the Atelier, so there really is no reason for Atelier users to stay on that platform. The VS Code environment has been so successful. We've surpassed the Atelier functionality sooner than we expected. And so the official message is definitely, if you have been using Atelier, it's time to move; it's time to migrate as quickly as possible. And we've been giving that message to people who have asked, and we haven't had any pushback. So people who have tried out both are so happy to move on from that.
Zack Krowiak 00:11:37 Right. And I can say just as a user myself, the difference between the challenges of even just installing Atelier, on my version of Eclipse versus VS Code, it's night
and day getting VS Code up and running, and my IDE was, you know, a matter of two buttons,
and it was running. Now on the other side of things, what about Studio? Is that going to be sticking around?
Raj Singh 00:11:59 Studio will definitely be sticking around for a very long time. First of all, Studio just does things that the VS Code ObjectScript extension doesn't do, and may never do. All the low-code editors for the Interoperability/Ensemble products, just don't exist on Visual Studio Code yet. There are a lot of wizards in Studio that people have grown very used to, which the VS Code platform just works on a different metaphor. So I don't even know if we can bring, we definitely can't bring them in the same form to VS Code. We may be able to replicate them in the model that VS Code likes a little bit, and we'll continue to do that with code templates and things like that, but they're going to be different platforms for the foreseeable future, and they're going to have different strengths and weaknesses. And I think people who have grown accustomed to Studio will continue to use it for certain things. And they'll probably end up in a mixed environment, where I expect over the next couple of years, more and more mainstream ObjectScript development will probably be on VS Code, and Studio will still be there for custom…I don't want to say esoteric, but some more special-purpose needs.
Zack Krowiak 00:13:23 Right. So if you're working with wizards or some of those more kind of,
as you said, obscure needs that Studio offers, that's the way to go, but for your development work and your kind of regular coding, VS Code is going to do everything you need it to do. So one thing I was excitedly watching was the gradual release of the product. I remember getting to around Version 0.9, which seemed to have all the functionality. And then, that was in, I think, early September, before Version 1.0 came out in October. Could you talk a little bit about what changed between those versions?
Raj Singh 00:14:06 Well, the big change was the language server, which I just talked about. That took the product from kind of a toy to being a real production-quality thing. I don't want to denigrate it too much; it wasn't a toy, but the syntax coloring wasn't perfect. There were things that weren't colored right. There was very little inline documentation. Like I said, you don't want to build all the documentation for all the classes available, built-in classes in IRIS, into the extension. So there are a lot of things that were very limited. So getting the language server in there was the biggest change. And then there was so more testing going from 0.9 to 1.0. Throughout the summer, we expanded the user base, and InterSystems getting involved in the project attracted a lot more beta testers to it, gave them the confidence in it that they were willing to devote some time to it. So I would say the second biggest change from 0.9 to 1.0 is hardening the whole thing, having many more eyes on the product and tons of bug fixes and little tweaks and enhancements. And then the third big thing is the introduction of the server manager extension, which lets you…we changed the idea of how you configure your access to service in 0.9. In previous versions, you pretty much had one server that you could access. And if you wanted to access…you only had one server per project you could access. If you wanted to access a different server, start another project. 1.0 allows you to have multiple servers, multiple IRIS servers or Caché servers, hooked up to the same project and also allow you to use server-side source control instead of only client-side source control. So a host of new features, I would group them all under moving into the enterprise-level feature set. And so it definitely works the same. Most of it works exactly the same as 0.9, but much deeper and it'll take you a lot further. You won't max out on your ability to do your projects.
Zack Krowiak 00:16:28 Great. Yeah. There's so many things I've experienced there, but there's
still the things you're describing. I'm still excited to dig deeper in and try some of that out.
Raj Singh 00:16:37 Oh, I forgot the big one big one, which is encrypted password storage.
Prior to 1.0, you couldn't store your password encrypted. You could only use it for development environments. Cause you either had to store that password in plain text for your server, for your database server, or you had to type it in every time you connect it, which is a right pain.
Zack Krowiak 00:16:57 Yeah. That's a big one. Yeah, so what's next for VS Code, ObjectScript? What's the future hold?
Raj Singh 00:17:06 Well, I think this winter is going to be less big splashy features and more making it rock solid. We're going to, I think with 1.0 coming out, that will attract a lot more users to the product. And when you get a lot more people, you'll find some of the dark
corners, some things that don't work as well. So we'll spend a lot of time making it solid and
dependable. And then we're going to begin to look at some small new features and some
big new features. Somebody we're talking to this week during the Virtual Summit, our annual user conference, brought up the issue of code refactoring, which I think is a must-have. It's one of my favorite features of an IDE, which decades ago, when I started being a programmer, got me off at text editors, and to use a real IDE is…the idea that you can change a variable name, that the IDE would allow you to change a variable name, and it would change it everywhere it appeared in your project, or change a class method signature and change it everywhere it appeared in your project…those kinds of mass refactoring things are huge productivity boosts, so we need to get more of that in there. I think we're going to greatly expand the number of code snippets, which is VS Code's term for templating out boilerplate code. So that there's stuff you write all the time. And you don't want to type it in every time from the simplest thing like for loops or if/then statements to whole class signatures. If you're doing a REST implementation, there's a bunch of stuff that is boilerplate that you just need in there all at once. If you're extending a class, there's a bunch of boilerplate stuff. So we'll be taking a close look at what are the most useful things. And once again, jump on GitHub Issues and request your favorite boilerplate code templates. And we will work on building as much of those as we can.
Zack Krowiak 00:19:16 Right. Thank you. So, one last question I'm just wondering about…this is an open-source project. Does that mean that if I see a feature, I can theoretically do a pull request and try and develop myself? Are you encouraging users to do that as well if they have the time and motivation?
Raj Singh 00:19:33 Yeah, definitely. That would be great. That is the ideal state of any open-
source project, to have a huge, thriving developer community. And don't be intimidated. This is another great thing about the VS Code platform over Eclipse. You can get into programming for it very easily. So for example, writing extension is hard. It involves TypeScript programming; and understanding the whole code base can be very complicated, but as I mentioned, the boilerplate code, that is something which is done simply through writing a single JSON file, and you can even do user-specific code templates. So you can create your own little JSON file that works in VS Code without even submitting it to the main open-source project for inclusion in the whole product. And we have a document available in the GitHub Repo called contributing.md that shows you how to set up your Visual Studio Code environment for development instead of just use. But yeah, it's pretty easy to get started and there are steps to get you…dip your toes in the water and get you more and more involved in being a code contributor. And then on the governance side, we've set up a process for accepting those types of contributions, and having you become more and more a part of the project. You can get involved as much or as little as you want to be in the development side of this thing.
Zack Krowiak 00:21:10 Great. So yeah, the future looks like tightening it up in the short term, making sure that we address any support cases as they come, of course, invariably with any new technology, and then a little further down the line, adding some of those features like code refactoring. Raj Singh, thank you so much for joining us today. It's been a pleasure speaking with you.
Raj Singh 00:21:32 Yeah, thanks. I can't wait to see what people do with this platform, not just from a user perspective, but this is a product for developers and by developers. And I hope to have a lot of developers join us on making it better.
Derek Robinson 00:21:50 So thanks again to Raj and Zack for having that conversation about VS
Code. The extension is definitely a great breakthrough for making development on InterSystems technologies easier and more intuitive. So we encourage you to check that out if you haven't already. That'll do it for Episode 15, and we'll see you next time on Data Points.
It's Global Summit time! In this episode, Senior Instructional Designer Michelle Spisak and Technical Online Course Developer Adam Coppola join the podcast to talk...
This episode features the first part of our interview with senior clinical advisor for interoperability at InterSystems, Russ Leftwich. In our discussion, Russ tells...
In this episode, hear from Jeff Fried — the director of product management for data platforms at InterSystems — about InterSystems being named a...