A Julia Interpreter and Debugger (opens in new tab)

I know how to use a debugger, at least how to set a breakpoint and step through stuff. I'm sure there are features I'm not familiar with, but I at least understand the fundamentals.

I think part of it is that for the last 5 years , every single language I've used with any kind of professional capacity (JavaScript, Haskell, Erlang, F#, Clojure, Scheme) has had a REPL, so I can quickly play with and reload code, making debuggers a bit less necessary than if I were to do a purely-compiled language.

I definitely would benefit from learning more about performance profilers though. You've given me an idea of reading material for the weekend.

> I guess I was quite lucky with some of the teachers and professors that crossed my path.

Debuggers aren't exactly self-explanatory so the role of good teachers should not be underestimated

> Turbo Pascal 5.0 Is important to note how MUCH better some debuggers are than others. Pascal was amazing, specially if you compare to C.

Good debuggers:

- Pascal - Delphi - FoxPro /VisualFoxPro (the best of all, IMHO)

Others more common debuggers (Visual Studio, Xcode, IntelliJ, maybe others I don't remember), have issues, like the amazing "feature" of show opaque values, not allow to inspect stuff or requiere extra steps.

But the worse of all? Them are SLOW. Do "step" is slow. Waiting to see if evaluating values? slow.

Python have almost good, but mostly because python allow to see a lot. GDB sucks as is, but python make it look good.

"println debugging" is a tried and true strategy. Debuggers' firehose of information can start to get really hairy when you have multiple threads of execution, for example. "println debugging" (if you have the right tools) can get you 98% of the way there and show you exactly only the relevant information.

It's not a satisfying answer really, but I use a bunch of log statements. It's definitely not as good as a debugger, but 9 times out of 10, it's sufficient.

Throughout my career, I have never met anyone who used MS tools that did not find them excellent and productivity enhancing. In fact I could probably add to MS any of the language vendors from years ago. I remember using Borlands terminal based C++ environment back in the early 90's. That's about 30 years ago and that environment is better than what I use programming on Linux today.

I have often thought that programmers posture over their tool independence to signal their excellence. Before the current generation of programmers, many programmers would proclaim how they didn't need to use higher level languages to assist them in programming because assembly language was sufficient given their reasoning powers. Today programmers proclaim they don't need types to insure data invariants as their reasoning powers are sufficient. They proclaim they don't get any value from unit testing because they can maintain correctness across all development phases using their reasoning powers alone. They proclaim they don't need automatic garbage collection because they can insure correct memory usage using their reasoning powers. They have no use for IDEs, debuggers, or profilers because they believe none of these tools could augment their reasoning powers.

Excellent programmers can indeed compensate for poor tooling through their reasoning powers alone. But if history is a guide, people who don't use the best tools, practices and technologies to produce the best work, at some point, wont produce the best work.

I've used Chrome's JS debugger, which I agree isn't so bad (though I don't really do frontend work, and I only managed to get node-inspector working once).

I've also used the Visual Studio debugger for F#, and I think I did gdb with Eclipse a couple years ago when I did C.

GDB is very useable with the TUI mode or the Emacs integration.

Go and C do not have classes either. If it's a bit comparable it would be a plus for me. I'm mainly a C++ programmer by trade by I don't enjoy it and in my free time I use mainly C with some shell glue and some Go.

I read that their focus is on scientific computing, but I feel that there is a growing effort to expand Julia's use cases. Also I think that some end user applications could gain a bit from optimized statistics or matrix operations.

I'm not sure if you're suggesting that an "OO language" is a better match for web development, but in case you love some of the OO features like inheritance of fields, you can check out https://github.com/rjplevin/Classes.jl

Multimethods are OO.

In addition to this. About Python and typing, have you tried mypy (statically typed Python)? I find the typing story quite decent since Python 3.6. I use it on every project that goes above ~1000 LOC.

http://mypy-lang.org/

I must agree Genie.jl is great!

Author of MagneticReadHead.jl here. Hit me up with any questions.

It is a a bit less polished than Debugger.jl right now.

Yup, Gallium used DWARF debug info like gdb/lldb and could debug optimized, compiled Julia code. It's named Gallium because the DWARF standard constant for the Julia language is 31 and gallium is the 31st element in the periodic table :) Unfortunately, compilers generate horrible debug info and it was very hard to get even basic stuff like knowing the values of all in-scope local variables to work reliably and making breakpointing work was very much a work in progress.

Debugger.jl on the other hand is slow, being interpreter-based, but very reliable. The down side is that it's really slow, so if you need to debug performance intensive code, you might be in trouble. In the future, the plan is to steal tech from Gallium [1] and MagneticReadHead [2] and use them to create a hybrid interpreted/compiled debugger that is as reliable as Debugger.jl is now but which can run code fast enough to debug even compute-intensive workloads effectively.

[1] https://github.com/JuliaDebug/Gallium.jl

[2] https://github.com/oxinabox/MagneticReadHead.jl

The history here is a bit as follows. Back about four years ago, I set out to write a debugger for Julia and while I was at it, I figured I might as well fix all of the other things that have always bothered me about debugging. As an example of that, it had the following features:

  - Being completely written from scratch in Julia
  - Mixed debugging between Julia and C/C++ code
  - Integration with https://github.com/mozilla/rr for time traveling debugging
  - Debugging windows programs running on a linux host under wine (and in particular even as an rr replay).
  - Zero overhead debugging by using mixed modes (DWARF based debugging generally, a much more accurate interpreter based one when possible).
  - Very precise location tracking, on an expression basis, not just a line-by-line basis
  - Multi-process debugging by riding along RPC calls, even across machine and even as separate rr recordings across machines

As you can tell from this feature list, that project was a bit over ambitious and in the end failed to be a particularly useful debugger for Julia. It was useable for a bunch of basic cases, but fairly brittle. Also, then 0.6 came around and all of Julia's internal APIs changed and porting over the entirety of Gallium would have been quite hard.

After 0.6 was released, I decided this wasn't working out for a Julia debugging story and pulled out just the interpreter and UI parts from Gallium (that package was called ASTInterpreter2.jl). This worked ok, but was lacking a bunch of features that I never got around to implementing, because the lead up to 1.0 required a whole bunch of compiler work that nobody else was available to do. This work now is based on that work from 0.6, but actually making it work nicely and paying a whole lot of attention to it that I was never able to. I'm very happy that Tim, Kristoffer and Sebastian decided to take this on, because I feel like my workload has only increased over the past year ;).

I still very much want all the ambitious features from above, and we do still have the code (and much of it is actually in use, just not for debugging) and I'm fully expecting them to make a recurrence. However, this time around, we'll start with a stable, usable system and gradually make it faster and add features, rather than building an unstable system with all the features and trying to fix it. The former approach is much better for getting usable tools out (though sometimes the latter can lead to more interesting results in a research setting). The other thing to note is that Julia is much more stable now, so it's easier to keep things running without breaking every few months.

This effort is effectively the revival of half of Gallium. At the end Gallium was a combination of two debugging techniques — it was both a "native" gdb/lldb-style compiled debugger as well as an interpreter. The native debugging was fast but indeed challenging and rather limited — most Julia code gets optimized away when it gets compiled leaving you with a rather unhelpful stack frame that's challenging to line back up with your original code. So there was also a rudimentary interpreter (the ancestor of this interpreter) for other cases.

Yes, the original attempt was a bit brittle. So this attempt addresses things from the other end and having something robust but slow. From here on, the plan is to keep adding features from Gallium that improve performance.

I wouldn't be surprised if it wasn't so much "brittle" as that Julia internals were too much of a moving target before reaching 1.0 to make it worth the effort of keeping it working between releases.

Amazingly, even packages have started to stablize. Even though a great many of them are on there own v0.x, they are both moving towards theire 1.0 releases, and being more careful about not breaking there v0.x releases.

I tried Revise and the fact that it doesn't require you to restart Julia doesn't mean that it allows you to change code on the fly. It means that you don't have to close the REPL and restart it and that you don't have to explicitly reload code. To see the effects of a change to a function invoked in a loop you have to wait for the loop to complete and return back to the REPL. This is not really SO interactive. In CL you see the effect of any change immediatly at the next iteration of the loop. What Revise does is to automatically recompile updated code by detecting changes automatically. I hope that this interpreter brings the same level of interactivity as CL. I'll try it for sure.

Just as a nudge for something not really of practical importance but something I'd like to see for other reasons: self-hosting.