Your opinion matters: InterSystems development environments
Happy new year! I’m Raj Singh, InterSystems’ product manager for Developer Experience and I’d love your feedback on how you use IDEs today and your thoughts for the future.
We understand you depend on a solid, intuitive and flexible IDE from InterSystems - whether you are an ObjectScript expert or new to it; whether ObjectScript is at the core of your applications, or you develop more in Java, Python, C# or Node.js. ObjectScript has proven to be a powerful and productive paradigm that gives you an edge over other platforms, and with that comes our responsibility to provide developer tools to support your work.
Our long-standing IDE, Studio, will continue to be the principal IDE for shops with the most sophisticated ObjectScript requirements, but many users will be working in an increasingly heterogeneous language environment in the future.
With the introduction of InterSystems IRIS and its deeper commitment to language “freedom of choice”, it’s time once again to take stock of InterSystems’ IDEs. Last year we paused and took a step back to study the IDE landscape and formulate a plan that would embrace our ever expanding language options – you can now do even more with Java, C#, Python and Node.js as well as ObjectScript – without forgetting that ObjectScript is as powerful as ever. In doing so we’ve become extremely excited about Visual Studio Code. Increasingly, the highest quality and most innovative developer productivity tools are being built on the that platform, and according to the 2019 Stack Overflow survey, over half of developers use Visual Studio Code already.
As we develop plans to support InterSystems development on Visual Studio Code, we’d like your input. What do you like or dislike about using Studio or Atelier today? What external tools (source control, testing, etc.) do you wish you could integrate more tightly with InterSystems IRIS? Have you tried ObjectScript development with 3rd party VS Code extensions (Serenji or vscode-objectscript)? Do you expect to be writing code in a web-based editor five years from now?
Feel free to comment below or direct message me. As always, the voice of our customers plays a major role in this important process.
Hi Raj,
I use different IDE's and combinations :
- Caché Studio without any extensions for development where i am self-employed and no other developers are involved
- Caché Studio with Serenji source control from Gerorge James for a particular customer where i am one of the developers
- Visual Studio Code with the vscode-objectscript extention from Dmitry Maslennikov for another customer where i am one of the developers.
I like Caché Studio since I use it from day 1, because it is build-in so no need to configure anything. I use the 'projects' feature a lot, and export my projects regularly as a sort of 'light' source control. (I even edit my html and js files in Studio, even when they contain no COS code at all.)
But when developing in teams a good build-in source control is essential, so that's why i also use the other options. I am still learning Visual Studio Code but it seems the way for the future.
Thanks for sharing Danny!
I'm not using IRIS yet. Having options is good, especially for those coming from other development languages and/or not primarily focused on ObjectScript. Hopefully Studio continues to be supported, even better, receives future updates.
I have no issues working in Studio. I'm primarily developing with ObjectScript and XSLT. I've also used Studio for JavaScript, CSP, and web development (mixed with ObjectScript).
I'm not using Atelier now, but used it at a few previous jobs in team environments. Linking and using it with Git was very easy. After primarily using Studio for many years, adjusting to Atelier wasn't a steep learning curve. Initially there were things I switched back to Studio for, like "Find in files". But after a few updates and getting used to it, it was comfortable, flow felt logical.
I haven't used VS Code for ObjectScript. I tried it recently as a potential replacement for UltraEdit/Studio. I found it cumbersome, no toolbars, not intuitive...for me. I suspect if I were to dive in with it, as I had to with Atelier, it would feel better.
Scott, could you give some more details about your experience with VSCode, privately directly to me or publicly here? What do you expect, and what would help you decide to use VSCode instead of Studio?
Dmitriy, I have very limited experience with VSCode, none using it with Cache coding. I looked at using it to replace UltraEdit/UEStudio and Notepad ++. I use those daily for XML, HTML file formatting, base64 decoding, file comparisons, CSS and JavaScript.
Using VSCode instead of Studio isn't an option for me at this time, team uses Studio with source hooks. If that changed, I'd be open to using it side by side with Atelier to compare. I've read many of your post and other's on using VSCode for Cache development. I assumed that path was being taken as the future of Atelier was unsure, and suggested at times that it had no future, other than support for what was already there.
When your team uses Studio with source hooks, it's even easier to move to VSCode. VSCode supports source control class hooks, and even some types of actions from menu. You can the latest beta release, to get more features.
VSCode can also be used to edit files directly on a server, almost the same way as Studio. Just at the moment it does not check any changes on the server, and uses your opened files as a source of truth.
Thanks Scott. In case I was vague on the point, but let me say that Studio will definitely be supported.
p.s. I'm an old UltraEdit user too!
Hello Raj,
I'm fine with Studio, but... what are the chances of:
* Integrated and full featured terminal with support for special characters including colors.
?
Excellent list Rubens. In fact all of these are possible with VS Code.
I'm curious what you would do with API access to the ObjectScript AST, parser and lexer?
For example, some months ago there was a discussion about how to bring functional programming to ObjectScript. I think this could be possible if we had a way to transpile functional-oriented code to pure ObjectScript.
Hi @Raj Singh !
We recently introduced a new post type - Discussion, I changed this announcement to Discussion - I think this is more relevant.
Discussion is the type of posting where you want a conversation, input, discussions on the topic.
Like: Studio is fast. My REPL cycle is very short.
Dislike:
We should offer APIs, so any tool can be integrated.
I use VSCode extension. With direct server edit it's good. Subjectively slower that Studio but now it's comparable.
Like: The interface is way more modern. Crossplatform.
Dislike: XDatas are unformatted. Only one server connection. No BPL editor.
Not really. Our IDEs don't take that much space. And REPL timings would go up.
At the moment it is possible to have multiple folders configured for each own server, and tied up with .code-workspace file. I see you already use server-side editing, so, you can just extend your file. And the link for the info, how to configure it.
Curiously, what do you expect from XData? Could you fill the issue, so, for any other ideas as well?
So workspace per server and multiple namespaces per workspace?
Filed.
Something like this, you can have many serverN folders, with own settings.json there, configured for any server.
{ "folders": [ { "name": "root", "path": ".", }, { "name": "server1", "path": "server1", }, { "uri": "isfs://server1", "name": "server1", }, { "uri": "isfs://server1?ns=%25SYS", "name": "server1 sys", }, { "name": "server2", "path": "server2", }, { "uri": "isfs://server2", "name": "server2", }, { "uri": "isfs://server2?ns=%25SYS", "name": "server2 sys", }, { "name": "server3", "path": "server3", }, { "uri": "isfs://server3", "name": "server3", }, { "uri": "isfs://server3?ns=%25SYS", "name": "server3 sys", } ], "settings": { "objectscript.serverSideEditing": true } }Studio :
Atelier :
VS Code with Dmitriy's plugin
Serenji :
I haven't tried it yet because you need to install some classes on the server side, but sound very promising for debugging.
Conclusion :
My main IDE is VSCode with Dmitriys's plugin and some times Studio for find in files, csp managment and debugging.
Yes, why not, already a lot of people do it on Jupyter Notebook.
Could you explain a bit, how would you like to see work with CSP files? For me, when you working with own local instance, you can just open csp folder in VSCode, and edit as a usual file, InterSystems will compile it automatically with the next request. I think it would be possible to add CSP editor only as part of Server-side editing feature.
Server-side search, not yet available, because, search engine not yet publicly released. I've already implemented server-side search when server-side editing enabled, and you can test it with the latest beta version of vscode-objectscript, and only with Code-Insiders version, and with flag
--enable-proposed-api daimor.vscode-objectscriptCould you add your expectations from debugging feature, as an issue here?
I've already published a beta version with support for CSP editing, It would be cool, if you could test it and give some feedback.
Hi Raj,
Just like others in the community, I use different IDE's.
I like the Caché Studio; it's fast, reliable, and useful for debugging.
My favorite IDE right now it's VSCode with the vscode-objectscript extension from Dmitry Maslennikov. To work with Docker, Github, and other extensions that make my workflow faster.
I tried to use Atelier, but comparing with others that I mentioned above, it's the last IDE for me.
Do you expect to be writing code in a web-based editor five years from now?
No, I agree with @Eduard Lebedyuk answer.
Regards,
Henrique
It is interesting that you are asking this as we have tried, for well over a year, via various mediums, at various levels within Intersystems, to get an answer as to the future of IDE's given that previous announcements and responses from WRC state that both Atelier and Studio are end-of-life.
We have never received a response even after Evgeny pinged such a request to John fried and others after some posts.
Your statements seem to indicate that Studio is not end-of-life so it would be nice to have some clarification as even WRC are saying non-critical fixes or changes will not be done. You also indicate work being done on VSCode integration, again any details would be appreciated.
The reason for wanting to know is that is difficult to commit to a particular toolset or plan changes to DevOps etc... if the future of the tools to be used is unknown, the actual answer and whether it is an individuals or companies preference is immaterial, it is simply that an answer is required but everyone has been reluctant for a long time now to commit to anything.
Coming back to your questions, we use Studio with our own version control based on StudioHooks and some use of Serenji for debugging.
We have tried Atelier but noone liked using it and we have worked in VSCode via Dmitry's plugin and have also tried the Serenji plugin both of which were generally a good experience but migration would require changes to development processes and version control.
We are likely to move to a GIT based Version control and whether this is intergrated with Studio or VSCode will likely depend on Intersystems commitment to the IDE though I suspect there would be a preference to stick with Studio as it is familiar and has integration to Cube etc... though as we continue to do more Web based development in VSCode this may change.
Not sure if it's already included, but just wanted to know if we're going to be able to view and develop business processes using BPL, or data transformations, etc...in their graphical way. If this is meant to be a real modern alternative to Studio, support all the IRIS components is a must... Otherwise we'll have to be changing from one IDE to the other... which is not practical and prone to errors.