What IDE do you use?

I’m not sure it is yet in a super useful state for others. I am still changing it around often, and adding new behavior, so I haven’t taken the time to document it thoroughly. I can make an off-topic announcement or just DM you when it is more accessable.

Or if you want to give it a look in it’s currently obtuse form, here is a link to my current configuration of vscode-modaledit. You can import it after installing vscode-modaledit using the command ModalEdit: Import present keybindings.

2 Likes

Please give the Pluto folks examples of what constitutes horrible debugging.

1 Like

I switched to VSCode from Juno a few years ago because at the time the in-line display would become very slow making the interface unusable. This has likely been fixed, and the other day I realised @manipulate works in Juno, so may give it another shot.

In terms of debugging I use Debugger.jl in the REPL; VSCode’s graphical debugger is too simplistic. I think it’s very useful for understanding functional-style code which is everywhere in Base and very sparsely documented: I challenge anyone to figure out what any of the Base.Broadcast._* routines do without a debugger…

Pluto.jl is exciting but tried it last week and was disappointed one couldn’t redefine a variable; pretty big deal breaker. Also, one of the most exciting things about it is that it’s file format is just a .jl file, but when I tried editing it in a text editor it wouldn’t load on Pluto anymore. So I think it’s a few years away from being production ready.

1 Like

I’m sorry you had a bad time with Pluto. It is a reactive notebook, which means it tracks assignments and executes the cells in whatever order is needed (a bit like a spreadsheet). In such a system you cannot define a variable in two different cells (which would it execute first?).

I honestly don’t know what “production ready” means in such a broad context. Pluto has some limitations and warts but for what it’s worth I’m using it to solve real problems.

With respect to Juno, I believe it is in maintenance mode and new features will only be added to Julia for VSCode.

6 Likes

My dream scenario carelessly thought-through suggestion would be that you could redefine variables in Pluto, and that this would ‘invalidate’ the previous definition, perhaps with a warning and graying out of that cell, maybe strikethrough? Or something along those lines, maybe the user could configure whether redefinition/invalidation should be done or not done, with a warning or an error.

Anyway, not sure if this is a good idea, really, and maybe hard to implement.

As for me, I switch between the ordinary REPL, VS Code, and dabbling a little bit with Pluto.

1 Like

Maybe it is too hard to implement or it is not worth doing it? I express the same thought in another post Does anyone find it is a bit annoying that Pluto.jl does not let you reuse variable in different cells?. I think it is a really neat feature. It can avoid me switching between Jupyter and Pluto back and forth.

I think one of the key ideas in Pluto is that cells are not ordered, so the concept of “previous” is not applicable.

I am wondering if people complaining about this skipped the Pluto README altogether, or just want a different kind of reactive notebook?

Personally, I find the simplicity of how Pluto organizes cells into a directed graph simple and beautiful. All sorts of complicated alternative schemes are conceivable, but they would be harder to reason about and thus increase the probability of bugs (from a user perspective).

8 Likes

I mean previous in time, not in space. So that defining a variable that already is defined would invalidate the ‘previously defined’ one.

So the ‘current’ definition would be the one in the cell that is being edited (press ‘enter’ or whatever you do), and previous would be everything else.

Anyway, just an idle thought, not a strong preference on my part.

Perhaps the way Pluto reads the file is such that it cannot tell the difference, that it builds the ‘graph’ all over, for each edit? In that case I see that it wouldn’t be doable.

I believe Pluto needs to do this in order for it to make the notebooks reactive. This could just be my misunderstanding, however.

1 Like

I think there’s a gaping chasm between “reactive” and “imperative,” and attempts to form some sort of hybrid will likely end in tears.

That said, I recently wrote a talk in Pluto and enjoyed many of its features (heck, just visually it’s very appealing), but for what I was trying to present the reactivity did eventually get in the way to the point that I ended up copy/pasting everything into a RISE jupyter notebook. In my case I was making use of several features that go against the reactivity grain, like mutability (demonstrating the difference between copies and views). Eventually I decided that I just wasn’t using Pluto as intended, so I switched, but that’s not really a criticism of Pluto.

The feature of Pluto I most found missing was the ability to reveal items incrementally on the same “slide.” I think Pluto is really designed around examples where you just type things out in real time, but if the examples get even a bit complex then the typing becomes error-prone.

4 Likes

I think I understand the reactiveness in a rough sense, as in what it does, but not how it achieves it.

I probably imagined that you have a computational graph, and then when you make a new cell, it’s like a new node you try to ‘push’ into the pre-existing graph. That might not be a reasonable way to function, though.

FYI: I found this an interesting read Roben Kleene: The Era of Visual Studio Code and confirms for me that investing in VSCode as the main platform for a julia IDE (now that juno has merged with the VScode effort) is the right one.

1 Like

FWIW, some proponents of previously popular editors also believed that theirs will be the Last Editor To Rule Them All.

Maybe VS Code has some higher usage metrics and “momentum” along some dimensions than some previous ones at their peak, but all such cutoffs are somewhat arbitrary — maybe VS Code is doing well, but it is hardly an outlier considering history.

I think that a pragmatic approach works best: since VS Code is popular now, and can support an IDE that Julia needs, it makes sense to focus efforts there. But nothing lasts for ever*, so most of the tooling should be editor-agnostic.

* Except, of course, Emacs and Vim. :wink:

7 Likes

Well I didn’t say it’s going to be nr 1 forever (that 's the writer ) but certainly now and for the next few years it’s going to be the dominant editor.

Having said that, I still use RStudio, Eclipse, Visual Studio (yes the “heavy” one) and even vi on a regular basis. It all depends on the language/environment/task.

I don’t think this is something we can predict. Incidentally, that’s what a lot of Atom users thought until very recently.

Projects that rely on heavy company backing can disappear very quickly when the plug is pulled, even if they are technically FOSS: most of their users are not contributors and have no significant stake in keeping the project alive, so they just migrate to the next shiny thing.

Again, the best Julia can do to mitigate this is to keep as much functionality as possible on the Julia side, or de-facto interoperable frameworks LanguageServer, and just expose these with a thin layer.

3 Likes

I think the biggest thing vi and emacs have on VSCode is that there is a truly bare bones editor readily accessible. Sure it’s a huge pain to configure it when you start, but once you really put enough time in it’s possible to have most of the stuff in VSCode just as accessible. If VSCode code could find a way to layer extensions so that it’s just as easy to have something as bare bones as vim (a la Spacemacs/Spacevim), then I think we could guarantee VSCode would have more longevity. Until then, editing code for a couple minutes is quicker and easier in a terminal.

1 Like

It certainly is, not just on editors, also footnote 10 “It makes an interesting case study for the future of iPadOS as a platform. […]”

The text supports why VS Code by is far the most popular editor (over 50% and twice as popular as the next popular editor), and better than e.g. Emacs:

VS Code is giving indications that the era of short reigns for text editors is over. It has the potential to maintain its position as the most popular text editor for a much longer time, possibly for decades

Also interesting from the text:

Version 1.0 of the Theia IDE maintained by the Eclipse Foundation is a re-implementation of VS Code.

On Theia (I assume it supports Julia’s VS Code extension):

We believe VS Code is an excellent product. That is why Theia embraces many of the design decisions and even directly supports VS Code extensions.

The article makes some good points. I wonder whether the Electron dependence can be factored out though. When I look at the resource use of VS Code vs. Sublime Text 4, it is an order of magnitude difference. (Same project open, same files, Julia running.)
In other words VS Code can be fairly perceived as ponderous. If this is just Electron, what is the alternative? If not, I think VS Code may be in trouble, being a hog, same as Atom was (is?).

1 Like

I doubt Electron can be factored out. I looked at Theia’s Github, and it seemed also be using Electron, I guess the price to pay for these editors/IDEs to be built on JavaScript (needed for the extensions). For me however, it’s VS Code is not slow, so I’m in no hurry to check out Theia (or Sublime Text) or other, but you could.