Now that we have multicore and a version of effects, I’d like to hear from people what they think the most important next priorities are for OCaml.
Personally, I would like to introduce OCaml in a small scope in my workplace as a converter between file types for machine learning. However, without proper debugger support, there is just no way I can suggest it. I can’t expect any modern programmer to debug without access to a convenient, full-featured debugger. My vote would therefore be for adding proper debugger support, which means fully supporting gdb including viewing of variables.
Windows support would be second on my list and would definitely aid with OCaml’s widespread adoption, but given WSL, it’s not critical for me at this point.
I really agree that a debugger is critical in a way that a lot of other improvements are not. I think that having typed effects is also quite important because then the library environment will be able to use them, and it would nicer if we had only two “generations” of libraries : “pre-effects” and “post-effects”, and not three of them with untyped effects being in the middle.
I use python in my day job, and when I am solving a bug my boss keeps asking: Have you single stepped in the debugger yet? I absolutely hate it. Statically typed, functional programming should not be like that.
The existing time travel debugger could use some love, but for me it’s not more important than other tools issues.
The one thing I really find missing in Ocaml is ad-hoc polymorphism, which in our context seems to mean modular implicits …
I’m curious why you don’t like the idea of using a debugger to help you root out bugs. I’m somewhat in agreement that debuggers are overrated but especially now that OCaml has true parallelism “printf debugging” has its limitations.
The debugger question has already been discussed many times in this forum. My personal understanding is that:
the dev team is not opposed to improving debugger support;
doing this is not trivial;
any patch in this direction that hopes to be upsteamed should be reasonable (as in not needing a wholesale refactoring of the compiler);
there isn’t much interest in the dev team itself to work on this at the moment;
it seems there aren’t many community members with the right skills interested in working on this;
beginners seem to be more interested in this than experienced users;
resucitating ocamlearlybird may be a more realistic short-term target than better source-level debugging with gdb. On that note, it seems that work has picked up again on this project judging by the commit log.
I agree that ocamlearlybird is probably the most reasonable approach.
The fact that beginners ask for it more does not necessarily means that more advanced users would not profit a lot from it though. I think advanced users tend to get used to the status quo, because they learn all the convoluted ways to work around missing workflows very well (in that case, they become very good at printf debugging).
Ah I agree here – I didn’t mean to kick-start a whole new discussion about debugging support, my apologies. I was more just curious as to why @nobrowserdisagrees with the idea of creating a debugger, although maybe he just views ad-hoc polymorphism to be higher priority. I could also see how ad-hoc polymorphism would be quite useful for an OCaml debugger.
i think he meant that a debugger already exists (its named ocamldebug and only works with bytecode), and so its not high priority to have a debugger because we have one already.
Taking that into account “better debugging” could mean two things :
Real gdp support
Better experience with ocamldebug
As @nojb said above, real gdp support is very hard, and better ocamldebug experience is being worked on.
He also seems to think that a debugger is not a great tool, and with that I disagree.
I don’t have an opinion on the matter. Like all things, whether it is useful or not depends on a number of factors, such as the task at hand and the ability of the person using it. Debuggers may be the greatest thing since sliced bread for one person, and utterly useless and inefficient for another, and both could be right.
It’s hard to demand of a small community like ours, the depth of
features an established professional IDE like intellij provides for
hundreds of dollars.
OCaml-lsp is absolutely great. It can be improved further but it’s
really good, all things considered.
I don’t have a strong opinion, but the various things being worked on make sense to me on a “first principles” basis> I’m curious which these people appreciate more.
Modular implicits
Unboxed types
Stack allocation via modes
ocamlearlybird
Typed effects
0voters
OTOH, metaprogramming support has rough corners but is good enough; gdb does kind of work for those rare desperate moments when it makes more sense than ppx_debug-like tracing.
I guess I should amend my Cassandra-like pronouncement
Far be it from me to object to the development of any tool, especially when it is free. But that doesn’t mean I would use it, while I wish I had something like typeclasses every time I write even the tiniest bit of Ocaml.
Re “true parallelism”: I think that actually makes an interactive debugger less useful. Not that it is never useful, but the inherent lack of determinism will hurt.
I’ve expressed my strong belief that modular implicits are really, really important, so I won’t say it again. Anything related to performance and esp. memory-footprint and allocation-rates, is also really important. So: stack-allocation, unboxing.
Debuggers … of limited utility.
1996-2008 I spent basically only debugging, and 1998-2008, only commercial, production, deployed code. I worked with many other troubleshooters, and we uniformly never used debuggers. Never.
As @nobrowser says, you can’t debug concurrent code with a debugger: the perturbation of the debugger itself scares the bug off into the woods.
But even when you can elicit the bug in a debugger, it’s rare that it’s a simple process to do so; that means that the troubleshooter has to be involved in every reproduction attempt
There’s a categorization (perhaps due to Jim Gray) of bugs into “Heisenbugs” and “Bohrbugs”. The former are those that show up with some small probability, and hence require many re-runs in order to reproduce them. I’ve worked on Heisenbugs related to cache-flushing (in the circa-1997 IBM JVM) that required hundreds of re-runs in order to produce one reproduction. We would run different versions of the JVM on many different machines, all continuously under test-harnesses. I’ve debugged problems at a Large Internet Company that needed 1000 test-runs to elicit a single-digit number of reproductions. By contrast, a Bohrbug is one that manifests with high probability on a single run. E.g. “30% of the time”. Sure, for those, a debugger can help, b/c a troubleshooter can afford to spend 10 runs (under a debugger, manually stepping thru to the problem) to get 3 reproductions.
None of these situations are amenable to a debugger.
There is definitely a class of problems that debuggers are good for: those where the program is intrinsically single-threaded, and the data-structures are complex enough that a human needs to inspect them interactively. So, in short, compilers.
This doesn’t mean that debuggers are useless. I think they’re actually excellent for beginners, and also for program-understanding. I use debuggers for that in Perl and Python pretty often, actually.
It seems to me that the debugging use cases you are describing are very advanced, which make sense if you were some kind of “professional debugger”.
I think that for a lot of simple and stupid errors, but maybe hard to find in a big code base, debuggers are great. Printf works fine too, but its a bunch of code to type and then remove, and you dont have a stacktrace and the ability to inspect a variable you did not think was important, so you need to write a bit of code for that again.
All of this take time, and this time adds up.
Also I do not really understand why you focus so much on multicore stuff, most ocaml code in production is not multicore as far as i know, and even if it is it wasn’t a few years ago.
I think you should compare to other LSPs for other languages in, say,
VSCode. ocamllsp can’t solve the limitations of LSP itself, obviously.
So, browsing the docs would probably require a browser (unless it’s just
for one symbol, in which case ocamllsp does it well). Grepping requires…
I don’t think it’s part of LSP either? (It’s in VScode though).
What you’re asking is more like an intellij plugin for OCaml, which
would be nice for those who want that; but I think a lot of people (me
included) are happy with a good LSP integrated in their editor of
choice.
No. Why would I do that? I’m not interested in the gap between ocaml-lsp and hypothetical best lsp server for ocaml. I am interested in the gap between current-best-ocaml-ide and hypothetical-best-ocaml-ide.
The point I was trying to make is that in IntelliJ, finding-ref/usage is so reliable that I don’t need to browse docs / grep; I can just jump around reading the source of the libraries I pull in, and jump around goto-def / goto-usage. ocaml-lsp tends to not be as good at finding refs/usages, and thus I’m forced to use browser / grep.
Agreed; I am not arguing that everyone wants this. I would argue though that given how popular IntelliJ is for Java/Kotlin/Scala/Rust, C++ (CLion), Python (PyCharm), Ruby (RubyMine), ReShaper (dotnet?); that they are doing something right and having that level of IDE support for OCaml would be great for many.
