New post
Discussion
· May 20, 2020

Studio, Atelier or VSCode

#Development Environment #Studio #Caché #InterSystems IRIS #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?
Discussion (28)8
Log in or sign up to continue
Julius Kavay · May 20, 2020

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)

12 1
Julius Kavay · May 21, 2020

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.

13 0
Dmitry Maslennikov · May 21, 2020

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.

  • You installed IRIS or Caché at least, so, just a couple of more installs, to make you more productive.
  • It has the documentation.
  • Yes, you can also have multiple connections, it's a bit tricky there, but possible. As soon as you understand why you really need it.
  • You can change any colors in VSCode as you would like, just from the settings
  • VSCode has support for GIT out of the box, while in Studio there are not ways, how to do it very simple
  • You can ask any questions about using VSCode extension here, some small fixes I'm releasing quite quickly. 

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.

3 0
Ben Spead · May 21, 2020

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?   

1 0
Dmitry Maslennikov · May 21, 2020

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.

2 0
Henrique Dias · May 21, 2020

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

2 0
Renan Lourenco · May 21, 2020

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.

4 0
Dmitry Maslennikov · May 21, 2020

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.

1 0
Rubens Silva · May 23, 2020

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:

  • We use distributed development and versionment.
  • 3 of our users are Mac based due to working with tools like React-Native, so they have to use VSCode.
  • Since we're adapting from a legacy development style, for now our project has about 3200 items.
  • Our project contains lots of static files from CSP to JS even HTML files. And we are moving away from CSP because we plan on making our product a SPA.
  • We do NOT use IRIS for development and CD due to critical compability issues with Caché versions (try importing a XML generated from IRIS into Caché to see what happens).
  • We use VSCode to edit these JS and HTML files.
  • Releases are XML based and generated using a docker version of Caché.

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.

1 0
Rubens Silva · May 26, 2020

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.

0 0
Rich Taylor · Jun 1, 2020

@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:

  1. work across platforms (windows, linux, mac) OR
  2. want to easily integrate source control OR
  3. need to program in multiple languages and/or different components (docker, angular cli, ...) OR
  4. need to attract new talent OR

If any of the above is true I would recommend VSCode with the Objectscript plug-in.  Why?

  • mutli-platform (I work with a Linux desktop so this we important to me)
  • easy source control integrations
  • much more resource friendly than Eclipse which I found to be a resource hog
  • plug-ins just seem to work better.  Example the docker plugin(s) on Eclipse were a disaster.  The one I have on VSCode is great
  • Well accepted in the market

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.

5 0