This issue is with Plots.jl, not Juno. Plots.jl can’t handle multiple windows (or multiple current backends). Makie on the other hand can IIRC.
2 Likes
For my uses, it could also use a good data viewer (like Stata’s, in a new window and not painfully slow like RStudio’s). This is a non-trivial thing to implement, though.
I’ve found the new Jupyter Lab console mode super helpful, and I’d recommend it to people who want an IDE that can show datasets easily.
2 Likes
Interesting. How are you liking Jupyter Lab? Would you recommend it for Julia (over Atom/VSCode)?
I like it because of its console mode.
In Stata, the place where you insert commands is always at the bottom, and you can scroll to see your output while always being able to write in the REPL. Jupyter Lab’s console mode does this. This also means that I can print a big dataset, then scroll up to look at it, and write commands the whole time, which is almost as good as having a data viewer in a new window.
This workflow also means I can work with R, Julia, and Stata in the same way, more or less.
I just sublime text to write everything.
2 Likes
I said what I think is needed.
Never said how it should be done.
You’re making assumption that I said it must be Julia dedicated while in fact in my answer I gave Spyder as an example one could use with its Plug In system which should allow using any language.
For instant, it seems JupyterLab is going in the right direction and it supports Julia so the issue might be solved on its own.
What I said is users need the ease of use and the integration MATLAB IDE gives in Julia.
How to achieve that, well I guess there are many ways and many people much better than me on figuring our how it should be done.
This is the kind of workflow that I hate. I don’t like having to use another text editor to actually write code because the MATLAB/RStudio editor is wonky (but otherwise good IDEs). The hope of building on Atom/VSCode (or Sublime) would be to get a full-featured text editor + IDE like what JetBrains makes with its IntelliJ + collection. I think that’s the level we should be striving for.
Some of the comments here are bizarre though. They want a debugger. A debugger does exist in Juno, but I agree it’s not good enough. So the offered solution is to rebuild an entire IDE from scratch? How would that improve the debugger faster than just… improving the debugger?
Jupyter Lab is definitely an interesting option that will be nice to have over time. It’s very good with showing you large datasets in its CSV viewer, and it has its own big developer support so all Julia has to do is keep IJulia updated (and maybe add some extensions as needed). IMO it’s not that fantastic of an actual IDE though. For one, the text editing controls are very very basic. But I think most importantly, its “IDE features”, in the sense of Java-based cross-document viewing, are very primitive if there at all. Then again, MATLAB and RStudio are pretty terrible at these as well.
So I think that we have a few good options coming up.
- Juno and VSCode extensions are building strongly featured code development IDEs, along the lines of Eclipse, IntelliJ, PyCharm, etc. Their main strength is their ability to handle large code bases. Errors lets you quickly jump between modules/packages/files, let you update files in separate packages and iterate through debugging. While they have added features like plot windows to take on the workflow of MATLAB/RStudio, they are not as well-developed in the “scientific user IDE” side as they are on the “code developer IDE” side.
- Jupyter Lab is starting from the notebook side and building strong “code developer IDE” tools, making it look a lot like MATLAB/RStudio with its core being its interaction with plotting and data, along with its server and collaboration usage. Where it doesn’t shine is large integrated projects. It’s still best on “scripts” instead of “code bases”, for similar reasons to Jupyter Notebooks.
Juno and VSCode are really quite strong in the code development domains, and keep pushing to add more features to make it have all of the scientific scripter features. Jupyter Lab is really spending a lot of development time on scientific scripter issues so I’m not sure it ever really wants to become something like IntelliJ/Eclipse, or whether it would have the dev support to do so. In the end, both of these domains are very necessary to cover, with one end more useful in package development and the other more useful in actually doing science.
I think that both sides should continue to iterate on what they’re doing best. I think Juno will be the best editor I’ve used for package development in short time, after Gallium gets an update so that Juno breakpointing doesn’t require your cursor (yes, Juno has debugging and will stop at where you clicked if you want it to, so that’s a form of breakpointing). If it can make working via SSH better, then it will be the king of tough workflows, better than Eclipse/IntelliJ were. I don’t know if it has the developer resources to build a full interactive “spreadsheet editing” like RStudio/MATLAB do, but that’s the kind of stuff Jupyter Lab devs are working on, and I expect that to keep improving.
What I don’t see in here is a need to start and build a text editor from scratch to support Julia IDE development. I think that in 2018 if the resources had to be re-built, Spyder would’ve used Atom/VSCode, and MATLAB/RStudio would have built on top of Jupyter Lab. They have legacy to keep them going, but they have limitations they haven’t been able to solve with 10+ years of development, and they have taken large amounts of developer resources to get to where they are.
4 Likes
I have been a Matlab user for years, and when I started using Julia I thought that I would miss terribly the ability to place breakpoints and inspect running code. It turned out to be an unnecessary concern. I am getting by just fine. My hypothesis? I believe it has to do with the QUALITY of the PROGRAMMING LANGUAGE. Julia is so much superior to Matlab that I usually manage to write bug-free code with few or no iterations. That does not mean that I would not use a nice debugger if it was easy to do in some IDE, but its lack is not a dealbreaker.
8 Likes
10 years ago i used the visual studio debugger and thought it was amazing. Now a days, I program with Julia, and I am quite happy without a debugger. Even for extremely complicated code, I am actually very happy with using print statements to do debugging if I have to. Never tried out Julia’s debugger. Someday, I might start using it, but I love the adventure of debugging my programs the hard way, I just never felt like I needed a debugger here. When I switched from Visual Studio for the first time some years ago, and did Fortran programming, then I was disappointed that such a nice tool like VS doesnt exist for gfortran. But since then I have grown and not felt the need for such things. Now I only use vim with i3wm for text editing, and it’s perfect.
1 Like
Well, it seems that some of us will never want to grow.
My impression was that you have over many posts over a long period of time communicated the opinion that building on Atom/VSCode is not the right way to go, and that we need something like Spyder, or alternatively Spyder itself. I’m sorry if I have misunderstood you.
As a former Spyder user, I don’t understand the enthusiasm over Spyder. Has there been very great progress in development over the past couple of years?
That’s a remarkably similar narrative to what my experiences have been, except:
I still find that sort of pattern rather annoying, I’d still like to have some sort of debugger, but I also don’t want it to be something that’s married to a visual IDE, I want to just use vim and the console, I find everything else to be an annoyance.
It’s worth mentioning that although Revise.jl is in no way a debugger, it does kind of fill that role in some ways by making it very easy to modify code and immediately run it.
1 Like
What I do is with i3 window manager there are multiple terminals open with various vim for source files and additional terminals with different version of Julia running on them. So I can edit in vim and simultaneously test example code in different julia environments. If you choose to, you could also load the debugger in another terminal to test out your code and walk through it.
Editors like atom essentially try to emulate my setup, which I do natively with unix-like OS.
That’s definitely on the roadmap. 
For code exploration and finding control flow bugs etc. I find that ASTInterpreter2.jl works pretty well. It does have a terminal interface (similar to gdb I think, but it’s been ages since I last used that), and one could of course use it in Juno if so inclined.
That’s impressive 
My own code, unfortunately, still falls far short of that goal.
Like, recently getting InexactErrors for specifying Matrix{T}() when I should have written of Matrix{Complex{T}}(). Breakpoints would have saved me a lot of time figuring that out, and I don’t see how the quality of the language could save me from mental lapses like that.
But even much more so, when the problem is not in the code, but in the algorithm.
2 Likes
This really seems quite orthogonal to a debugger.
perhaps it’s the orthogonal complement
1 Like
Yeah, but it’s still pretty effective for “run, alter, check-if-its-working loops”. You’re right, it’s not a debugger at all, it’s just another tool for helping me to easily fix things that I screw up.
1 Like
I won’t say that I’m happy without a debugger, but unless the debugger can attach to arbitrary processes and then be able to step through them, I’ve found that I usually need to debug via conditional logging code with the ability to have easy printing (to the log).
When we started with Julia, there wasn’t really good logging support, and using the printf macros not very good at all, so I ended up having to come up with my own literal strings with formatted interpolated values, and another person added logging support (very similar to what is now available in Julia).
On the contrary.
I’m aware that in our time the most invested language for UI is JavaScript hence it is only natural the best UI oriented applications will be built on this technology and Atom / VS Code are great demonstration of that.
What I’m afraid is that since those tools are mostly used by programmers the vector of developing IDE (In the sense of experience) which is optimized for Scientific Programming will be left alone.
For instant having a good variable display capabilities, good UI for exploring figures (Visualizations), integration with debugger, profiler, command line, etc… are crucial for Scientific Programming in my opinion.
I really don’t care about the technology driver, be it Spyder (Which seems to be optimized towards Scientific programming use case), Atom / VS Code or Jupyter Lab (Which is also seems to be customized towards that).
Any of this (Or those I even not aware of) will be welcomed.
I’ve defined
# debug() = false
debug() = true
and then filled my code with
debug() && @show something_hopefully_related_to_the_problem
This is really convenient with revise. You can turn all debugging on and off via redifining the debug function, as well as quickly add and remove the show statements.
Revise makes the “debug via printing” strategy much easier.
3 Likes