Debugger status and future plans?

Community
,
81

Again though, this assumption that the masses demand good debuggers is a very matlab centric thing. It very well may be essential to attracting matlab users, but I’m honestly not sure how much julia developers care about strategically trying to entice matlab users. They’re more focused on building good things that are useful.

While features are not zero sum, the time of the developers who could make these things is zero sum and I can think of many things that would be more valuable to more people than working on debuggers but obviously, I have no say over how they spend their time.

5 Likes
82

Please please please don’t go there again. There has already been huge threads of people talking past each other, with one side saying (I’m caricaturing) debuggers are for people who don’t know how to code and the other side saying that julia has to have a state-of-the-art debugger or “nobody will use it”. Some people can’t live without debuggers, some don’t see the point. That’s a fact, let’s move past this, please.

Many people find debuggers useful. Everybody acknowledges that julia’s debugging solutions are not perfect and far from the experience provided in several IDEs, but that writing really seamless debuggers is a large, thankless work (which is particularly difficult in Julia due to intrinsic characteristics of the language) which is unlikely to happen anytime soon unless 1) somebody suddenly decides to write one 2) somebody suddenly decides to give a few thousand dollars to pay someone else to do it. In the meantime, there is a debugger that works well although with a performance hit, and solutions like infiltrator/exfiltrator that provide an alternative debugging workflow.

24 Likes
83

Let’s not lose sight of the fact that we already HAVE Julia debuggers. Not just one, several!
Are they perfect? No. But they are already useful.

7 Likes
84
  1. Several debuggers already exist, with most of the features you expect from a modern debugger, yet with some weaknesses.
  2. There is active, though long-term, work going on to improve them.
  3. There are alternative workflows and programming styles well-suited to the Julia language that alleviate some (but not all) of the need for debuggers.

Is that close to a reasonable summary?

9 Likes
85

I’m skeptical about the “but not all” point. I’d be interested to know how many people in the julia community that work on big code bases actually actively use debuggers. There are very productive people I know who are working on very big, complicated code bases that never use or even installed a debugger.

To me, that indicates rather strongly that there are code styles that make these things unnecessary (granted, changing coding practices is hard!)

86

I didn’t intend to get into a debate, rather to summarize, but I’ll just say I like debuggers for understanding code, not necessarily for debugging it.

Furthermore, some of us need debuggers specifically because we’re not master developers.

9 Likes
87

Hmm… this discussion sounds familiar :thinking:

1 Like
88

I am not sure if you are aware of this, but a lot of the progress on Julia, its standard libraries, and the package ecosystem just happens because people contribute work.

While some people work on Julia full time, the divide between “developers” and “users” is not as significant as other languages. In other words, if you really want something and it does not seem to be happening, the realistic alternative is to start coding or pay someone to do it.

Exhortations along the lines of how “Julia won’t be competitive unless you do what I ask for” pretty much fall on deaf ears.

6 Likes
89

I fully agree with mancolric.

I think my colleagues and I are one of Julia target audience. We suffer every day from the two language problem. We use mainly Matlab and Python to develop and test new algorithm. And if we are successfull these algorithm/scripts are transfered to C/C++/C# to run fast. This is really expensive! We would tremendously benefit from using Julia. We don’t know the solution when we start. We are scientists (mainly physicists), we are not programmer or computer scientists. Our approach is more try and error. But for this work we need a fast and easy debugger like in Matlab.

I think there are a lot of people and they have different use cases for Julia. And I see that it is important to understand, that everybody have other needs.
Unfortunately at the current state, I will not have a chance to convince my colleagues to even try Julia because of the debugger.

I am fully aware that Julia should be give and take. We could contribute in the form of librarys and/or algorithms and we do … unfortunately not in the Julia ecosystem.

6 Likes
90

As is often the case with these generic discussions, it’s hard to find out what people actually want when they say “julia needs a good debugger such as Matlab/Python/Java/C++/etc.”. Just saying “good debugger” doesn’t tell us anything about your actual needs and what’s wrong with the current e.g. Debugger.jl though. For example (and inspiration):

  • Is It too slow?
    • You’re debugging, that’s a different type of execution than normal, so slower run time is expected (for any language, not just julia).
  • Are you missing breakpoints?
    • Debugger.jl has those, and as far as I know, they’re also exposed via Visual Studio Code and Juno.
  • Do you want to live-inspect variables at full-speed runtime execution?
    • This also kind of works in compiled mode of Debugger.jl, but has its limitations (as with every debugger)
  • <insert your specific complaint here>
    • Well… Why didn’t you just tell us about this?

As you say yourself, everyone codes differently, so not everyone has the same perspective and experiences the same pain points. Maybe the pain points you experience aren’t actually a problem of the lack of features of the Debugger or julia itself, but because you’re wielding a fencing sword like a heavy two-handed broadsword and don’t know how to wield a fencing sword. Sure, it will do the job, but only subpar. If that’s the case, we’ll be glad to give advise on how to wield the sword, provided you can tell us what you really want to do.

Lastly, the vast majority of people on this forum aren’t computer scientists either. They’re biologists, physicists, mathematicians, astrologists, economists and many more I don’t know the occupational title of. Their backgrounds certainly don’t include a theoretical understanding of the intrinsics of the compiler or the language itself, they’ve just taken the time to understand the tool they’re trying to use. They’ve asked questions if they didn’t understand how to do something, when things didn’t work because they where coming from another language, when some behaviour didn’t make sense to them, or when they wanted to get a second opinion on whether or not their approach makes sense in julia. This forum is full of those questions, and I wouldn’t want to have it any other way. The important thing is, whenever they hit a roadblock, they talk in specifics about what doesn’t work/should work - “the debugger is not good” is not specific.

10 Likes
91

On a side-note, I think if you use the debugger in julia and think “but my code runs slow now” you shouldn’t think “I wish I was back in Matlab, where I didn’t notice the difference between debugging and not debugging and where I had to rewrite the code to make it fast and then verify that the rewrite is correct”, but should think more like “Oh nice, so once I fix this bug with a small reproducer I’m done and it’s already fast!”. That’s how I think about it anyway.

5 Likes
92

It is in the first place the startup time when using packages. Starting the Debugger in VSCode needs about 7s on my i5-8365. If i use Plots for example i have to wait for 20s.

1 Like
93

This is actually one of the areas under the most active development. It is a crucial point and a lot of work has been done (and is being done) on it. From 1.4 to 1.5 latency decreased substantially and apparently things are even better on master (see this juliacon talk which mentions this and other interesting stuff)

94

Any good write-ups on moving away from my current Matlab style of run the debugger and wait for it to break to the REPL/unit-testing style mentioned by many above for code development?

1 Like
95

This is my approach too, but I’ve never used a debugger and so don’t really miss it. I am perfectly productive (well, not always, but that’s my fault not the language :laughing:).

1 Like
96

There are books that cover more or less this approach, but I am not aware of a Julia-specific one.

IMO it just takes practice: write smaller functions and keep testing them. When debugging, narrow down to simple cases, and use invariants when applicable.

1 Like
97

How about Julian methods for good organization of the functions, tests, and main code? I am using smaller functions now but am not very happy with them all sitting lumped at the top of my script. In this way, you have to scroll all the way to the bottom of the file to get to the meat of the code. Also, the flow of the code is more obtuse than I’m used to when writing longer scripts. Testing I have mostly been doing in the REPL, but it would be better to have these documented somewhere.

98

Off topic (sorry for that):

When you split up your code into smaller functions, you will likely discover that those can sometimes be generalised further (similar procedures with just tiny changes), for this, the type system can be extremely helpful.
This is more or less the status where you are currently stuck, if I understood correclty, or at least you are reaching that point.

I’d suggest a very simple method: create your own Julia package and give it a generic name like Tools or so and dump everything in there. You will then be able to maintain those functionalities separately and isolate them into their single namespace. I am sure, the functions you export there will not only be used in a single project. Start sorting those types and function into their own files and include them in the main module.

At some point, you will end up with a large set of useful functions and should start thinking about creating multiple spin-off packages out of them.

This is at least an approach which I usually recommend to people coming from Matlab or ROOT, both are languages/frameworks which somehow encourages the users to write long functions with lots of variables and nested loop. I can assure you that this style of coding is generally a very time consuming task, not only from the development but also from the maintenance perspective (we spent so much resources in the past years to rewrite such code). One of the most crucial things is the impossibility to reuse implementations which otherwise could be useful in other peoples work either.

On topic:

I totally agree that Julia’s debugger capabilities are not comparable to those in Visual Studio (not Code), Matlab or similar, but I do not understand most of the reasonings when people are complaining about it. To me, it seems that most of the complaints about the debugger contain two orthogonal problems and both of them are real: on one hand the debugger and on the other hand bad code organisation.

Thinking that a debugger will save you time and make your life easier when you write hundreds of lines of functions with hundreds of variables is a misconception in my honest opinion. I don’t think that a debugger is the right tool debug such code, I think that refactoring, splitting it up and introducing unit tests is the right tool for this job.

To me, the debugger (in any language I have worked with so far, C, C++, C#, Java, Delphi, Python and Julia) is mostly used when understanding other people’s code, to quickly get a feeling about what’s happening in the code, where it jumps around and so on. For this purpose, a debugger can be slow and I have absolutely no complaints about the possibilities we now have in Julia.

That’s of course a personal thing and I understand that other people might have different habits. I however think, as written above, that many times these are simply “bad” habits that let people think that a (fast) debugger is required in first place.

11 Likes
99

I think this is the root of the dichotomy between both camps.

Because many community members are also library authors, it’s more likely that they will be working with a higher proportion of “first party” code. In this context, it’s much easier (arguably natural) to develop and iteratively through the REPL and/or unit tests. Being able to iteratively craft a set of focused, composable abstractions with ease is one of the best parts of Julia, after all!

However, a significant subset of the community (which, for whatever reason, is usually less vocal) primarily work with and glue together third-party libraries. For certain domains (picking DL because it’s close to home), most of the program execution won’t even occur in their own code! In this context, having to dev and add logging to or write tests for an external dependency feels like more like a workaround or patch than a happy path.

Yes, it’s possible to explore the invariants of unfamiliar code through the REPL and some basic spot tests. The hard part is creating the initial conditions to trigger said invariants/failure cases separately when one can do by just re-running the program that incidentally triggered the issue in the first place. There’s a reason Julia itself uses rr for bug reports: being able to explore the execution state (stack, local vars, global vars) at an arbitrary point of time is useful for reproducing and understanding issues when executing code out of one’s own control.

In some sense, creating the “perfect” Julia debugger is a much harder task than Python or Matlab because of how much those languages “cheat” and shell out to opaque code over FFI for anything performance-sensitive. Just being able to debug something like a conv algorithm that sits at a lower level in the stack is great (want to do the same in TensorFlow? Good luck). Misinformed claims and diatribes that trivialize the efforts put into debugging by many, many community contributors absolutely deserve to be corrected and shut down, respectively.

However (and this is going to get me in trouble) reframing questions and concerns about debugger UX as X-Y problems misses out on the opportunity to gather and quantify (real or perceived) pain points that folks new to Julia experience. For each person willing to engage on discourse about such a topic, there are at least a few more who will encounter it later and get turned off by the pushback. This dynamic is a big reason many (myself included) refuse to partake in the StackOverflow community. Julia’s discourse is generally a pretty helpful and welcoming forum, but threads like these never leave a great taste behind.

16 Likes
100

When I try to debug code containing a line like CSV.read(full_path, DataFrame) where the spreadsheet has 50k rows and 700 columns the Julia debugger inside VSCode for all purpose stops. I never had the patience to wait until it would finish. The R and Python debuggers handle this file in a couple of minutes. The R function fread() reads files much faster than CSV.read(), by a large margin. So I do not think it is an issue of compiled vs interpreter. R and Python are interpreted but call functions written in C and these functions can be very fast.