Studio, Atelier or VSCode
Hi,
It can now be programmed with different development enviroments in Cache / Iris.
The question arises which is the primary IDE Intersystems prefers when it comes to new features.
We are working in a small team, should we use Atelier or VSCode in addition to Studio?
What do you use, and why?
Which Development Enviroment?
FYI in case you haven't seen: https://community.intersystems.com/post/intersystems-joins-open-source-objectscript-vs-code-effort
In my opinion the very first question is the support.
a) Studio
- it's installed (and updated) with Cache/IRIS
- if I have a question, there is WRC
b) VS-Code
- it's not installed with Cache/IRIS
- so I have to care about the installation
- where to get the suitable files (and updates)
- and I have to care about the "how to" install it
- in a case of a problem, who am I contacting?
1) the WRC? They will say, it's not our product
2) the community? Are they always (24/7) there?
The current situation with VS-Code and the COS-plugin (my very private opinion) is
1) it is assumed, that one is an experienced user of VS-Code
2) there are no installinstuctions and user manuals
ad 1):
assume, one day ISC says "VS-Code with COS plugin exists, so we can drop Studio". What should happen to all those COS-programers, how should they master VS-Code? Most of them have never ever heard about VS-Code? Keep in mind, not everybody grew up with mother's breast in one hand and an App in another !
ad 2):
yes, there are some YouTube videos. On all videos I saw, VC-Code was already installed
Do not get me wrong, I'm not again VS-Code (the truth is, I would like to use it on my Linux) and I'm not for keeping Studio until eternity (because there is no Studio for Linux).
But currently, Studio has some advantage (again, for me):
- it's installed
- I can have (and yes, I have) several connections
- I can give each connection a different (background) color
- I have the WRC (but I never had a Studio issue)
A minor addition:
For some time ( since last year ?) Studio is also available for stand-alone installation without any related Caché / IRIS Kit.
The support & documentation situation is important for the field.
So my vote: Studio for Win, Atelier for the rest
VSCode-ObjectScript offers some support by now, through the issues on GitHub. And anybody can order commercial support.
Documentation is there.
Atelier, too slow, and very fragile, and no improvements anymore, could you explain why do you like to use it?
I like it as it is based on Eclipse.
And as I used Eclipse since I wrote my first line of Java some decades back
I know where to find my buttons and switches, what fits my needs, ....
I'm not married to it. Just many years of positive experience. Why drop it for some younger tool ...
Robert, you are right - old friends and old wine are the best.
But in case you would like to try a new approach there is a whole team of CaretDev and Dmitriy Maslennikov who can help you to switch to the new supported tool like clockwork.
The big team is working on the VSCode ObjectScript plugin, so there will be always a solution for any issue.
Just to bring things in the right light
I'm a retired person but one needs some level of activity, that's the reason, why I'm here, do give answers and comments (and if the old customers need "a kind of prolonged help", I'm there too).
In early and mid seventies I programmed some so called "desktop computer", learned Cobol, IBM/360 assembler, Algol60 and Pascal as the preferred language on the university. Then, end of 1977 I met M (DEC's V4B).
Until the nineties thre were no IDEs, the first one I used was Serenji (from GeorgeJames) for MSM and Cache's Studio (with a lovely meat-chopper as the compiler icon). And there were no GitHub.
Anyway, we had great projects and great programms and fun.
The above means, I for myself do not need anything, neither Atelier nor VS-Code not even Studio but in case, I want to edit a class or routine, I prefer Studio.
During my active times, Studio was a great editor (and still it is!), sometimes I had more then one Studio open (at the same time, of course) to different Servers or different namespaces that's the reason why I requested the feature (server defined colors) some decades ago. The light red was the connection into, say a productio system, the green was into a test namespace and blue, for example was the developmet system. A short glimpse at the display, if I saw red, my brain said, "keep fingers from keyboard", if I saw blue then my brain was ready for switch off...
But I know several people working since decades with Studio only (and with the line editor before - I hope you know ^% and remember it?). Those people are (roughly) between 50 and 60 years old, worked (and still work) with whatever brand of M-Language (DTM, MSM, ISM, GT-M, Cache etc.) and never had contact to "modern" languages like java, C++, javascript, etc.
That's in my opinion the reason, why Atelier not so widespread as it deserved to be.
De facto, we have a two class society of M-programers
a) the young ones,
- they know everything about the current IDEs (Visual Studio, VS-Code, Eclipse, etc.
- they try to master (more or less) the M-World but
- their heart beats for languages as Java, Javascript, C++, Angular, Scala, etc.
- can't live without Git, GitHub, Bitbucket etc.
- they do not understand the essence/character of M-language (especially Cache/Iris)
- and think, MongoDB is the only NoSql-DB
- work few months (or one or two years) for a company, then change
- in the new company start over with another environment (Java, Angular, whatever)
- many are, I use to say, single-threaded: one project at time only
- etc.
b) and the old ones
- they grew up with the M-language
- they understand the power of M as a unity (language and database)
- most of them never used Git (and similar sites) for version control
- some of them never used a version control at all!
- most of them work with Windows (but this has historical reason)
- a few years before retirement there's no incentive to change to new IDEs
The real problem is not which IDE is in use, the real problem is to get people for M-programming, who then use an IDE. There are, I think, more old(er) then young M-Programer. I know for companies, they search for M-Programers but have dufficulties to find one.
That said, at the end of the day, you have to raise interesse for M-Language and M-Database. So you will need another means and not just a new IDE.
Maybe I'm wrong, but it's like comparing the M-Language and M-Database with a dinner by a start chef.
Nobody asks for the IDE they was in use, nobody asks for the pots and stoves they was in use.
After you leave the restaurant, the only thing that remains is, was the dinner good, were you satisfied.
Same goes the M-Language, does it can all things I need, will I be happy with it.
And yes, my answer is a big yes, definitive.
Julius! Thank you very much for such a story, very touching. And for the prompt opinion.
And thank you for sharing your fantastically rich experience with Dev community where we all benefit a lot from your knowledge and direct feedback!
And I remember the meat-chopper too :)
If you have read the article provided above, and maybe would saw the webinar by Raj Singh very recently, where he said, that VSCode will have support through WRC quite soon when we'll reach the stable version 1.0.
Studio as well as Atelier, will not get any big improvements anymore, just only to keep it working with the newest version. While VSCode is in active development and will get a lot of new features, which will not be available in Studio.
I have a follow-up question about the coloration Dmitriy. Any of the developers on my team may need to connect to anywhere from 50-60 shared servers for development, testing and production, and years ago we simplified access by having our change control system auto-generate windows registry keys so that developers can simply import the file and their cube's Server Manager will automatically list all applicable Studio server connections for that application. For Studio, server-specific background coloration is stored in the Windows Registry so we auto-color each of the servers according to their type (no color for dev, test is yellow background and production is a red background). We have found this to be extremely helpful in preventing accidental checking out of source in non-development environments (we use serverside source control hooks exclusively).
Eventually we'll be moving to VSCode (once server-side workflows are complete) and I would very much like to create an equivalent solution where a developer can easily and quickly build out a catalog of servers to connect to from VSCode by generating the required json connection files on our change control application so developers can just import them into their local environments. Will it be possible to include color along with the JSON that includes the server connection details? Or is the color config stored somewhere apart from your plug-in in VSCode?
I have this in my settings.json file
"workbench.colorCustomizations": { "activityBar.background": "#0079c9", "activityBar.activeBackground": "#0079c9", "activityBar.activeBorder": "#ff80cc", "activityBar.foreground": "#e7e7e7", "activityBar.inactiveForeground": "#e7e7e799", "activityBarBadge.background": "#ff80cc", "activityBarBadge.foreground": "#15202b", "titleBar.activeBackground": "#005a96", "titleBar.inactiveBackground": "#005a9699", "titleBar.activeForeground": "#e7e7e7", "titleBar.inactiveForeground": "#e7e7e799", "statusBar.background": "#005a96", "statusBarItem.hoverBackground": "#0079c9", "statusBar.foreground": "#e7e7e7", "statusBar.border": "#005a96", "titleBar.border": "#005a96" },This is not a part of this extension, it's just goes from VSCode itself, and marketplace can offer some extensions which can help with easy configuration of it.
As to your task, the same task will be much easier to implement in VSCode.
Hi, @Ben Spead,
I'm using a plugin to change the color of each one of my workspaces. The plugin's easy to use and helps me a lot, avoiding mistakes editing in the wrong workspace.
Peacock
https://marketplace.visualstudio.com/items?itemName=johnpapa.vscode-peacock
The plugin creates the configuration inside the .vscode folder in a JSON file.
{"objectscript.conn.ns": "IRISMONITOR",
"objectscript.conn.port": 52773,
"objectscript.conn.active": true,
"objectscript.format": {
"commandCase": "word",
"functionCase": "word"
},
"objectscript.export.addCategory": true,
"workbench.colorCustomizations": {
"activityBar.background": "#88d7ea",
"activityBar.activeBorder": "#de41bf",
"activityBar.foreground": "#15202b",
"activityBar.inactiveForeground": "#15202b99",
"activityBarBadge.background": "#de41bf",
"activityBarBadge.foreground": "#e7e7e7",
"titleBar.activeBackground": "#5dc9e2",
"titleBar.inactiveBackground": "#5dc9e299",
"titleBar.activeForeground": "#15202b",
"titleBar.inactiveForeground": "#15202b99",
"statusBar.background": "#5dc9e2",
"statusBarItem.hoverBackground": "#32bbda",
"statusBar.foreground": "#15202b",
"activityBar.activeBackground": "#88d7ea",
"statusBar.border": "#5dc9e2",
"titleBar.border": "#5dc9e2"
},
"peacock.color": "#5dc9e2"
}
HTH
How to configure VSCode-ObejctScript in the InterSystems official documentation
Recording of the webinar when I give an introduction to VSCode-ObjectScript
Recording of tech talk webinar made by InterSystems PM Raj Singh, available here by registration
And register for my the next webinar where I'm going to speak about working with Git in VSCode
I vote for VSCode for the one major reason, I am a macOS user tired of carrying a VM for Studio. Other than that, I love how light and versatile VSCode is and so far I have a really great experience playing around with InterSystem IRIS/Docker/GitHub, and before I could even notice I am easily 90% of the time there.
Having said that, I am yet to see VSCode getting close to Studio in terms of features, which is still deep in my heart. For that reason my VM still follows me around.
I rather not talk about Atelier as I really did not enjoy the experience.
Hi @Renan Lourenco. Yes VS Code is way behind Studio in features today, but Studio has a head start of many decades! We'll get there...
No doubt about it, @Raj Singh
I'm counting on that!
I'm on Mac.
And I'm on Git and commit to GitHub.
And I like Docker.
VSCode works on Mac, has Git out-of-the-box and I can install Docker and ObjectScript plugin.
With VSCode and Docker have 0 (zero) time to set up the environment to develop for InterSystems IRIS with ObjectScript or any other language.
My vote is for VSCode.
To be honest... I'm using all at the same time:
Develop: VSCode
Debug: Studio
Synchronize code from server: Atellier
I have some problems to synchronize code from server to local code in VSCode, so I trust in Atellier.
What kind of issues in synchronization did you face?
If it has just Export
And what do you miss about debugging in VSCode.
You know that you always can ask me if you have any issues. ))
Do you remember, that Atelier has no future at all?
It's great that so much feedback comes together.
An advertised advantage of Atelier is the SCM functionality. How does this look like with VSCode? Is there a manual or examples? Are there differences between VSCode and Atelier?
Unfortunately, we have no experience with this yet.
VSCode itself has support for git out of the box. So, with VSCode-ObjectScript, when you just starting to use it, you can export source code from your server, and you can send it to git.
Join me the next week on the webinar, where I'm going to speak about using git in VSCode. Also, you can look at the recording of the recent webinar from Raj Singh
And in VSCode marketplace you can find extensions for many others SCM.
@Armin Gayl we'll soon have a lot of news regarding source code management in VS Code. Of course, out of the box you can use any client-side SCM you want, with git being the obvious choice since it's built-in to the product. We're working hard on server-side SCM as well, which you will see in beta this summer.
I try to use Studio whenever possible because it feels "faster" for me. This is mostly because it also feels more "native" as well.
I usually fallback to VSCode when I can't but I still find the UX lacking (obviously, it's not a dedicated tool after all).
However this is not the only obstacle: the Atelier API as oposed to Studio feels really slow when I use my instance locally.
Think about it: I have the files locally, so I still have to execute HTTPs request to my own machine even though I could simply use the file system to import these files, having a network layer in this case only introduces a bottleneck.
Also, the Atelier API doesn't seems to be optimized to handle large projects (more than 5000 items) which in turn reflects to the VSCode extension.
Here's an use case from my company:
To be honest, the only thing we use from this poll is Studio, otherwise we had to create our own tool to fit our needs.
By SPA you mean single-page application, yes?
Will your product also be a progressive web app? Will you use a framework like React or Angular or Vue?
Yes, we are on the road for making it a SPA (single page application) using React.
In the short term, we probably won't make it a PWA though since we also have developers with enough knowledge to create mobile applications using React-Native (me included).
Since you mentioned libraries and framework, I'll go a bit further and provide you a history background about why we are using React after dropping Angular:
Several years ago we initially used Angular 1.5 to create partial SPA applications embedded to our legacy CSP application, however as the demands increased we noticed that Angular introduced a spike in the learning curve messing up with our development speed as several domain specific languages had to be researched to fill these demands, including knowledge for advanced usage/creation of directives, really deep understanding of scope and its cycles. A complete mess.
We considered using Angular 2 at that time, but we dropped the idea as we noticed Angular 2 getting close to the component-based approach just like React and since our experiences with Angular were not the best along with the effort put from learning the 1.5 version becoming useless, we started to move to React.
Sadly VueJS was a late player at that time although I do recognize its efforts to use the best both from each worlds.
Thanks for the insights @Rubens Silva. I'm a fan of React also, and I'm planning to try our Vue.js as well.
Guys! Thank you very much for such detailed feedback! Last week plugin hit more than 5000 installs of VSCode ObectScript plugin!
@Armin Gayl The answer depends a lot on background. If you are a team experienced with Cache then you are probably already comfortable with Studio. Studio is stable and works well with InterSystems products. If you are primarily a Windows environment, working primarily with Cache/IRIS classes and objectscript, staying with this IDE is fine.
On the other hand if you:
If any of the above is true I would recommend VSCode with the Objectscript plug-in. Why?
Let my delve into point 4 above and the previous last bullet point as I think this gets overlooked or considered unimportant to the IDE question because "they have to learn a new language (objectscript) anyway". My opinion is that the issue of learning a new language is really overstated. Any programmer today can't even get out of bed without knowing several development languages. The real problem is HOW you work with those languages. In other words the IDE. If you can bring in someone that is already familiar with how to work with the IDE and the general workflow, which is similar regardless of language, then you remove one barrier to entry. Now it becomes learning just another scripting language with is a process that new developers are used to.
VSCode is quite popular and is trending up. I participated in a Hackathon with InterSystems several months ago. In the end there were 70 teams that submitted projects. Figure an average of 3 people on a team as a rough estimate. Every single developer that we interacted with was using VSCode. This, along with some great templates from @Evgeny Shvarov , made it easy for them to get working with IRIS. In fact something like 12 teams used IRIS including the second place team (the first place team's solution was related to a process where they were forbidden by law from storing any data).
So that's my $0.02. I would stay with Studio if that is your comfort zone and work primarily within InterSystems technology. If not go with Visual Studio Code. I would not consider Eclipse for many of the reasons others have stated and because it is really resource heavy.