Independent contractors
Also, the subject of my post is innovation, I’m only talking about people who innovate.
I do miss the freedom of grad school!
Just to be clear, I definitely still spend most of my time developing and fixing my own things. Emacs through cygwin + ssh is pretty good.
Part of it is me being stubborn. I’m complaining that I don’t get to use the tools that I want in the ways that I want, anymore.
Part of it is that while it isn’t really that bad, it’s precisely because those problems seem so unnecessary – inflicted upon us by IT – that I’m complaining. Seems like it should be easy to fix.
Given the choice to magically fix something, these problems probably wouldn’t make the list. I’d much rather have Julia’s compilation be multithreaded, for example. Or maybe have LLVM’s loop vectorizer suddenly start tiling/improve and integrate polly. More work on precompilation.
It’s just that all the cool things that could lead to real quality-of-life-improving changes are much easier said than done; they would require a lot of real work.
The IT situation feels frustrating because it feels like it’s a rare situation that should actually be easier done than said. On there end, it could be as simply as letting me bring a linux laptop to work to do my OSS development on!
On the other hand, we hear about data breaches at major corporations all the time. It is absolutely imperative that IT take security seriously.
I also understand that from the developer’s perspectives, who put all this great work into the Emacs, VS Code, Atom/Juno, Vim, and Jupyter plugins/libraries, none of the problems I’m complaining about are there fault, or happen on there ends!
So what use is it for them to sit there and read my complaints about it? Especially if, all things considered, my situation is pretty good and I’m just being greedy.
@kevbonham Some things get in the way of emac’s keybindings. I haven’t tried tmax, but I remember encountering problems with screen. Maybe I ought to try playing with vim, which works well with those tools.
Maybe something like this can come in handy for people who prefer a linux solution, but are on windows:
FWIW JuliaPro is a lot more sane than it used to be. You used to have basic Julia packages throwing breaking changes out every few months, with brand new features to boot, so you’d be mad. Also the update length was longer. Nowadays, with Pumas and Flux as part of JuliaPro, you can expect anything statistics, ML, or differential equations to pretty much get a monthly update or so. So it’s never that far behind, and quite well tested.
Also, things don’t update as much: as a matter of maitanance I just updated half of the JuliaDiffEq repos to have Project.toml files, which means that half of them didn’t get an update since v1.1 came out a year ago. And that’s not that uncommon.
Juno does quite well these days. uber-juno is a one click install on most OSs if you do a standard Julia installation. On Windows it literally just works. Also, it does things like automatically sets the number of cores for multithreading: ask a standard Windows user to set an environment variable and… be sad. But Juno and JuliaPro fixed these issues. It also has a bunch of display features that VS Code doesn’t have which are necessary for analyzing difficult simulations. Those displays are actually better than things I’ve seen in other languages. I am sure the rest of Julia will adopt treeviews sooner or later, but until then I cannot recommend other IDE systems for most serious simulation work because the data viz is just so far ahead in Juno. Like Atom or not, that’s a pretty massive advantage.
What the future will be like is unsure, but Juno is more than a good option for most users today, and by far preferred for real data analysis and simulation work until other systems catch up. You can code anywhere, but the viz is the biz.
5 Likes
Can you be more specific what you mean by that? I’m just not sure what you are referring to.
2 Likes
Inline display (at each evaluated line) of complex datastructures that are navigable in a tree fashion.
1 Like
Ah, ok! I had thought for a moment that this was referring to something tabular data related.
I think they are finalizing an inline webview API for VS Code, at which point we could probably add something similar.
2 Likes
To inspect simulation results in Atom, I get:
in VS Code I get:
I think we can objectively say that the Juno printout is the nicest you can get right now (and you can change it to REPL shows if you want, so it’s at least the same). That doesn’t mean that VS Code can’t get there, but at least right now it’s difficult for me to tell a new user that the second photo is the easier way to understand Julia outputs than the first. I hope that will improve, and I really would like to see more IDEs make use of Treeviews.jl, but as it stands this is the real-world difference we see between Juno/JuliaPro and all of the alternatives, and until that changes, this will continue to be the first thing that users point out in every workshop where we show a few different IDEs.
(FWIW, even things like MATLAB and RStudio don’t have this feature, so it really is just a Juno-only invention. But once you’re used to it, it really is hard to go back).
Another thing I find missing in VS Code is Weave.jl integration. Atom has a Weave plugin that works really well that makes it easy to run the inline Julia code and double check the results without having to actually weave the script. It would be nice to see that in other IDEs as well.
Another display feature that’s missing is TableViews integration. In Juno, you view tables like:
In VS Code, you view tables like:
Sure you get the REPL printout, but a nice scroll-able display is next level.
So VS Code is a great IDE, but it really doesn’t reach that next level because of these missing pieces. However, I can see it continuing to improve, and I like what I see. I’d put it above RStudio or MATLAB already, but not quite at Atom.
7 Likes
I have been thinking is something like Juno possible in Vscode. Vscode seems to be faster and from what I can gather is preferred to Atom by a higher proportion of ppl (finger in the air).
But I agree that Juno is nicer with the inline output which I find really useful.
2 Likes
I commented to a colleague (new julia user) the other day who appeared to be using vscode for python, but Juno for Julia, that vscode worked for Julia as well. His comment was that the display support of results in vscode was not as nice as in Juno and that alone warranted installing and using Juno instead.
3 Likes
Agreed, these inline tree views are nice. I think as soon as VS Code gets the inline webview for the code editor we should be able to add something similar.
We do support Weave in VS Code: the syntax highlighter and the full language server all work on julia markdown files, and you can get a preview generated by Weave.jl inside VS Code and export julia markdown files into lots of other formats. Once VS Code adds the inline webview, we should be able to get a more RStudio RNotebook like experience.
A grid view for tabular data is built into the extension (no need for TableViews.jl). The function is called vscodedisplay (instead of showtable).
In general, we are more restricted in VS Code in terms of UI by the API that VS Code provides. But, there is an upside to that: it is fast because the VSC devs are super careful to only expose APIs that don’t allow extensions to slow things down 
I do think there are a number of things that VS Code has going for itself right now that also make it appealing choices for a large audience: a) our setup story is super stable (zero installation, all xcopy, no dependency on the state of your .julia folder at all), b) the whole remote features in VS Code in my mind are really killer (take a look at the remote SSH and VS Online extensions), c) of course the general speed of VS Code and d) some of the features in the language server (if it doesn’t crash ).
We also lack behind in a number of additional areas beside the tree view. Minimally the debugger, but I’m sure there are others.
I think at this point the situation is that VS Code and Juno both have their strength and weaknesses, and which one is better for any individual really depends on personal preferences and what features one values.
12 Likes
I can really relate to that!
That is mostly my impression from big corporate IT departments.
although you seem to have it even a little bit harder then me…
I am sorry to hear this — hope things will work out eventually.
To be clear: my remark was about
- corporate IT environments breaking free software,
- people complaining about this with the implicit expectation of getting this fixed by the community.
Since it looks like you are being very proactive and going after these problems yourself, this does not apply to you.
I have had my fair share of restrictive environments (central banks can be even worse than your typical paranoid/incompetent corporate IT setup). I know it is frustrating.
I just think that focusing too much on solving these problems (in place of IT departments) is not the best allocation resources from people who contribute to free software. Instead, these are best solved by entities like Julia Computing. The implicit assumption here is that the Julia is useful these companies, so they should be prepared to pay for this.
4 Likes
For those in very restricted environments: you could give Visual Studio Online a shot. It allows you to spin up a compute environment in the cloud, and then you can run VS Code entirely in the browser to interact with it. Even the julia extension works flawlessly with that setup as far as I can tell, so you can run a REPL etc. all on the server that way. I would think that as long as you can browse the web and they give you a reasonably recent browser, things might work.
5 Likes
The main thing I’m missing here is actually a little more basic. Could you add the Ctrl+Enter usage to VS Code? The lack of that annoyed me quite a bit yesterday when generating the figures, and that should be a very quick fix (Shift+Enter runs a line and moves you to the next, the counter part to Ctrl+Enter which runs and leaves you there. VS Code flips the Shift+Enter to Ctrl+Enter but I couldn’t find the “run and leave me there” one. It seems VS Code requires that you highlight lines in order to do this instead of just having it available.). Also, running sequentially in VS Code requires that you Ctrl+Enter through every line of a function/block, instead of doing functions/blocks as a single Ctrl+Enter. This is minor stuff that could probably get fixed up quickly though.
(Ctrl+Enter type of usage is useful for quickly running the same line a bunch of times to generate random outputs or timings.)
One thing that popped up also is that the VS Code Julia extension documentation is linked from the website, and the docs are blank:
https://www.julia-vscode.org/docs/dev/
That’s good to hear! Add it to the README? It doesn’t show up in the features list, so I am not sure how people are supposed to find that command.
VS Code really also needs to change their default theme. It has no contrast and has weirdly pastel colors showing up for a lot of Julia stuff. It’s kind of funny that if you search VS Code themes, one of the first things that pops up tells you to install the default Atom theme and that it’s the most popular VS Code theme. People using Atom tend to just leave the default theme because it’s pretty good, so I’m not surprised. VS Code should really just make their default be One Dark Pro and then the “first look” will be infinitely better.
Anyways, it’s close and has potential, so I’m sure these little details can get ironed out. The theme one will require VS Code’s general governance just understanding that they really really need to change the global default.
1 Like
Even though VS Code + julia extension is missing some features of Juno right now I think VS Code is the way to go and the community should invest more in it.
Why do I think this?
- speed. Code completion/analysis in Atom is just too slow. VS code has good speed.
- ubiquity/popularity: VS Code has been voted most popular editor/IDE for the last two years in dev surveys (I think it was stack overflow). The fact that it supports many languages makes it nice to standardise on one tool rather than learning many IDEs especially for for multi language projects. The fact that it also supports remote development is crucial for developing/debugging on cloud machines.
- Microsoft is invested heavily in it: They are continually improving it with new features like remote development for Azure: Visual studio online is basically VS code running in a browser with a server component for configuring/saving your runtime environment on Azure. This makes developing in the cloud (Azure) and from different locations trivial. This could be also be huge for setting up julia data science/ML dev environments in the cloud really quickly and simply.
- Facebook is now standardising all of its development on VS code. That is just going make it even more popular and going to ensure more features/bugfixes.
Basically VS code is the new vim/emacs but web based and more disciplined in terms of extensions.
9 Likes
Should we be concerned about the possility of atom being abandoned since more users are moving to vscode?
1 Like
I don’t use Atom currently, but I like having it available and don’t want to use VSCode.
Also, I’d rather use an actual vim than a web-based emacs… the web-based version is last resort, it shouldn’t be considered a default replacement for such things.
I actually asked about where Juno stands as an Atom specific tool or really a set of tools that happens to be on Atom right now. I was told that it’s not a dedicated Atom tool and that the modular tools are really what’s important. Basically, if VSCode can support all the features and tools it sounds like it might end up being the “new” Juno. This is one of the benefits of focusing on tools instead of an IDE. It’s more robust against aging software that becomes less supported.
1 Like
That’s fine. Vim and emacs are there for those who prefer it and I don’t expect long time users to switch. The editor wars have been raging for decades and will continue on with no resolution 
But in terms of (search) popularity VS code beats vim/emacs/atom and in fact it’s the only one that’s growing. https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F07zh7,%2Fm%2F01yp0m,%2Fm%2F0134xwrk,%2Fm%2F0_x5x3g
So clearly VS code has the momentum and the others don’t.
4 Likes