In the replies is a mention of Revise. If you use this workflow with pertinent Revise lines in your ~/.julia/config/startup.jl file, debugging becomes easier. I set up a simple 'package, ’ for each project using julia generate. Most of mine involve data analysis with DataFrames and CSV. So in the directory myproject, I have an analysis.jl and a src sub-directory. All the functions go in the src/myproject.jl file. So write the function defintion for foo() there. Run foo() inside analysis.jl which will display to the REPL from VS Code. For debugging, just comment out the relevant foo() lines in src/myproject.jl or use show() and println(). From time to time I use Infiltrator as well inside the foo() definition in src/myproject.jl This works well for me, and I hope it helps you.
@tue: I just released a new release that addresses many of your concerns and feature wishes. You can now make it pause on error. Run multiline scripts while in debug mode etc. Step into also works now. I also fixed various other overlapping issues, so the experience is much nicer. Would love your feedback 
I tested out the new version, but I could not get the expression evaluator to work.
Working more with C, I’ve adopted the stance that the tooling around a programming language is more important than the language itself
I find this to be true as well. I really like Julia as a programming language, but I find that the tools I need to use it are simply not mature enough. So after a bit more than a week of testing out Julia again I am abandoning this project and will convert the Fortran code to another language. Thanks for all the replies and help I got while testing this out.
Just out of curiosity, have you tried using an AI to debug for you? I find I rarely debug in a classical workflow myself any more (either lots of print statements or using a debugger), as AIs tend to be quite good at hunting down the cause of bugs. I’ve had several bugs diagnosed by AIs that probably would have taken me much much longer to figure out, simply because they are very good at looking at diffs across many packages overtime to understand what caused a new bug to appear, along with writing a bunch of test scripts to isolate and reproduce bugs. I may have to then give them guidance on how to best fix the bug, but it is rare they can’t find the source of a bug themselves.
I mention this because if I were investigating porting code to new languages these days, the tool I would most care about working well with the language would be AIs.
I am assuming OP totally ignored my reply. But you describe this much more in detail. I share your observation and these days I don’t bother to debug myself.
Still, the effectiveness of using GenAI to debug would be amplified with good tooling, be it profilers, debuggers, sanitizers, testing frameworks… I am personally against using GenAI for many reasons. I’d like to highlight that programming, IMO, is a way to build understanding about the problem at hand. If we assume that you are almost always interpreting your code wrong and the computer is almost always interpreting your code right, debugging is an every better way to build understanding about the underlying problem, since bugs make it easy for you to identify a mismatch between your mental model of the problem and the reality of the problem. You spend more time reading your code than the compiler does. The point of programming is that the machine is here to help you understand the problem. The way to get better at your craft, by and large, is to hone your comprehension skills. Articles such as Things unlearned really resonate with me. Plus, why strip yourself of all the joy you can get when things finally click inside your head, the joy of discovery?
Sorry I had actually read your reply, but it was several days ago now and I forgot about it!
One more thing. Using print statements vs using a debugger is a false dichotomy IMO. You reach for the debugger only if:
- you know how to use it effectively
- it can easily give you more information about the state of the program compared to print statements, and, most importantly,
- it is performant enough so it doesn’t considerably slow you down and break your workflow and concentration
If you haven’t worked in an environment where the tooling is good enough, it’s easy to dismiss the need of having such tooling itself
I agree with what you say for when one is learning to program, and learning how to design algorithms / implement methods in programming languages. Without significant experience and knowledge, you will not be able to properly supervise an AI, plan effectively with it, or properly review code it generates. You need to build that base competency.
I think, however, that once one is sufficiently sophisticated in their experience / knowledge, using an AI is not much different than having a dedicated (competent but not perfect) junior programmer who works for you. You still need to carefully review what they do, and to really help them plan out more involved tasks, but you can let them work on tasks on their own in between planning and review. The end result of this approach, in my experience so far, is code that I do not think differs much from what I would write myself (but in taking a substantially longer amount of time on my own).
In any case, perhaps this isn’t the place for such a discussion as this is getting a bit off topic now for the thread.
A shame that you reached that conclusion @tue. Julia is a beautiful language with an active community and I for my part like to believe that the tools surrounding it are getting better by the day
But I will take your criticism at heart and look at how we can push this further. Thanks for the honesty.
Your suggestion to use AI for debugging is probably a good one, but for me that is not a replacement for a proper debugging environment, and if a language is requiring me to use this then that is not a language for me. Personally I find that ai does not really contribute much to my development. It is only when I am learning a new framework or building something standard that AI provides reasonable answers, but for specialized tasks or HPC it is more a distraction than a help in my experience.
As I said, I really love Julia as a language and it is with sadness that I once again have to abandon Julia. Hopefully your work will help transform Julia into something that I can one day develop in.
Not sure if that’s the case or not, but it’s totally feasible there is such a selection effect!
Before switching to Julia, I mostly wrote Python, and barely used a debugger ever (heavily used it in C++ before that though).
Switched to Julia, and naturally didn’t miss a debugger much Executing line by line and/or adding focused prints have generally been enough for me.
How long do you think it takes before your programming and reasoning skills deteriorate to the point where you can no longer effectively review the code?
I fear it won’t take very long at all for me. And for new programmers, I don’t see how they will ever get to that point.
In the end you outsource the entire problem to the machine, because why not? Perhaps you even forget why you wanted to solve it in the first place.
That’s probably how assembler programmers felt the first time Fortran appeared.
The lack of a good debugging story is also a major downside of Julia for me. I also like Julia a lot, working on some big packages for it.
And I heavily use the REPL, Revise, etc. But being able to just attach a debugger and inspect the state of the program, then step through it, is sooo much better than some of the alternatives…
In fact I am also spoiled by working with an obscure math programming language, GAP, which has something called a break loop, which is a bit like “Infiltrate on every error” – with a full feature prompt where you can do everything, including viewing variables, modifying them, or resuming the program after the error.
I understand why all these things are much harder in Julia (it’s a downside of running compiled code), and I cope, but I totally get the frustration.
And no offense to the people who are hard at work on Debugger.jl, VS Code, the JetBrains IDE plugin etc., but I found them unusable for heavy duty code; I can’t wait 5 minutes each time I step over a function call.
In Julia I do miss the ease of line by line execution that I have in Matlab.
I completely agree that the lack of a robust debugger is a major sore point in the tooling around the Julia language. But I would point out that it is possible to combine Infiltrator and Debugger: Set a breakpoint with Infiltrator, and then in the resulting REPL, make an @enter call. This doesn’t cover the full use case of a proper debugger, but it goes a long way.
Julia is indeed, and unfortunately, pretty rough around the tooling edges, but I wonder if you wouldn’t end up better off by exploring some alternative workflows and debugging techniques, rather than abandoning the attempt because it doesn’t support the exact workflow that you’re used to. I would generally still consider Julia an excellent choice for porting Fortran code. Yes, the Debugger isn’t in great shape, but conversely there are a lot of interactive workflows that Julia enables, that just aren’t possible in Fortran. What did you have in mind as “another language”?