4 ms·

Umm. You do realize you can set watchpoint in a command line debugger

selfhoster11 5y ago
A command line debugger is not as discoverable for a learner who doesn't know how to make it work.
watermelon0 5y ago
What are the benefits of CLI tools (including debugger) to GUI tools? From my experience, most people prefer GUI tools, and are more productive there. I understand CLI is useful for scripting, but outside of that I'd rather not deal with it.
- bodhiandphysics 5y ago
  As program complexity increases guis loose their discoverability benefits. clis often become easier to remember particularly if you have a vague idea about how to do something. Setting a breakpoint in gdb is b myfubc. Setting a conditional breakpoint is b myfunc if muvar = something. Set a conditional read watchpoint for a specific thread... rwatch myvar thread 3 if myothervar != 6
- yeputons 5y ago
  I mostly prefer CLI tools is that they're more consistent. You typically don't install a specific version of IntelliJ IDEA, but it's very common to install a specific version of Java. You hardly can specify exact configuration of a GUI tool (unless it stores its config in a file which you can blindly copy between machines), but it's always possible with CLI. For example, in my C++ course there are some strict requirements on how the code should be formatted. They're specified like this: install this specific version of clang-format on this specific Ubuntu 20.04.3 and run it with this flags having this config in this directory. Fortunately enough, installing and using clang-tidy on Windows and macOS yields exactly the same results in about 90-95% cases (the probability space is the space of all programs that students write during the year; not the space of all configurations). Of course, one can and is encouraged to attach clang-format to their favorite IDE like CLion. It's impossible to make all students use the same OS comfortably: macOS wouldn't run on non-Macs, Windows costs extra money, Linux consistently does not work on about 10% of laptops unless a specialist spends five hours messing with Wi-Fi firmware/touchpad drivers on each laptop individually. Installing Desktop Linux in a VM is terribly slow as well. However, requiring command-line only version of Linux is much better: it takes less HDD, it requires less RAM, it does not have slow GUI (as it does not have any GUI), and you don't really need to use it all the time, only when you submit the solution. Switching to web-based IDEs do not help: there are some power students who want to use their favorite vim/emacs configuration and compile locally instead of trying to catch 3G signal while commuting in a subway from the dorm to the university.
  - watermelon0 5y ago
    I think you are just pointing out that the issue here is C++ ecosystem (not saying other languages have a better one), not the CLI vs GUI. Linting/formatting with the same configuration should provide the same results on all operating systems, unless there is an issue with the tool used. Easy workaround would be to provide a Docker image with necessary tools to perform linting/formatting, which would ensure everybody can use it, and should produce the same result everywhere.
    - yeputons 5y ago
      Sure. But I'm yet to see a single language whose GUI tools are more consistent than CLI. Agda and Coq come close, because it's impossible to write either outside of their main IDE. But they're more of proof assistants, not a general purpose programming languages. Docker is a good idea, actually. Should be easier to set-up than a Linux VM. Still, it's a CLI tool.
- cerved 5y ago
  > scripting Exactly. So the flexibility and power to pretty much anything you want. Compile and test every single commit on this branch, easy. Being fast, responsive and working on remote machines is also a big plus.
  - vkou 5y ago
    An IDE highlighting your mistakes is the definition of fast and responsive. Having to wait for multiple seconds of recompilation is the very opposite of that.
    - cerved 5y ago
      FYI, you can do this in VIM/Emacs and other CLI editors You can also use CLI tools at the same time as using an IDE
      - vkou 5y ago
        > FYI, you can do this in VIM/Emacs and other CLI editors At which point, you are using an IDE, instead of running javac!
        cerved 5y ago
        I guess you could extend the definition of an IDE but then there's no GUI
touisteur 5y ago
I'm a very heavy gdb CLI user, have my own collection of batch-debug scripts (bisect stuff, fuzzing triage stuff, 'trace every change to variable x' stuff...), and... I wouldn't inflict that on a beginner. Eclipse debugging experience is OK, quite simple to start and do interesting stuff, and you can even patch/continue which as a novice will help a lot. The trick is to 'teach' debugging with the least friction possible. Evaluating the code in your head and comparing with what you observe is the underlying concept, the rest is tools, and they need to get out of the way. As for the OP, I learned java with notepad+CLI and it was terrible. So demotivating. When I discovered Eclipse, I became so happy with java and programming, 'create class', move stuff around, nice autocompletion, find class, refractor, automatic online build, correction suggestions. And I'm a 'using the mouse breaks my flow' old fart. Yes eclipse is buggy, heavy, but damn does it make a difference. It's the standard I compare any IDE to.

A command line debugger is not as discoverable for a learner who doesn't know how to make it work.

What are the benefits of CLI tools (including debugger) to GUI tools? From my experience, most people prefer GUI tools, and are more productive there. I understand CLI is useful for scripting, but outside of that I'd rather not deal with it.

bodhiandphysics 5y ago
As program complexity increases guis loose their discoverability benefits. clis often become easier to remember particularly if you have a vague idea about how to do something. Setting a breakpoint in gdb is b myfubc. Setting a conditional breakpoint is b myfunc if muvar = something. Set a conditional read watchpoint for a specific thread... rwatch myvar thread 3 if myothervar != 6
yeputons 5y ago
I mostly prefer CLI tools is that they're more consistent. You typically don't install a specific version of IntelliJ IDEA, but it's very common to install a specific version of Java. You hardly can specify exact configuration of a GUI tool (unless it stores its config in a file which you can blindly copy between machines), but it's always possible with CLI. For example, in my C++ course there are some strict requirements on how the code should be formatted. They're specified like this: install this specific version of clang-format on this specific Ubuntu 20.04.3 and run it with this flags having this config in this directory. Fortunately enough, installing and using clang-tidy on Windows and macOS yields exactly the same results in about 90-95% cases (the probability space is the space of all programs that students write during the year; not the space of all configurations). Of course, one can and is encouraged to attach clang-format to their favorite IDE like CLion. It's impossible to make all students use the same OS comfortably: macOS wouldn't run on non-Macs, Windows costs extra money, Linux consistently does not work on about 10% of laptops unless a specialist spends five hours messing with Wi-Fi firmware/touchpad drivers on each laptop individually. Installing Desktop Linux in a VM is terribly slow as well. However, requiring command-line only version of Linux is much better: it takes less HDD, it requires less RAM, it does not have slow GUI (as it does not have any GUI), and you don't really need to use it all the time, only when you submit the solution. Switching to web-based IDEs do not help: there are some power students who want to use their favorite vim/emacs configuration and compile locally instead of trying to catch 3G signal while commuting in a subway from the dorm to the university.
- watermelon0 5y ago
  I think you are just pointing out that the issue here is C++ ecosystem (not saying other languages have a better one), not the CLI vs GUI. Linting/formatting with the same configuration should provide the same results on all operating systems, unless there is an issue with the tool used. Easy workaround would be to provide a Docker image with necessary tools to perform linting/formatting, which would ensure everybody can use it, and should produce the same result everywhere.
  - yeputons 5y ago
    Sure. But I'm yet to see a single language whose GUI tools are more consistent than CLI. Agda and Coq come close, because it's impossible to write either outside of their main IDE. But they're more of proof assistants, not a general purpose programming languages. Docker is a good idea, actually. Should be easier to set-up than a Linux VM. Still, it's a CLI tool.
cerved 5y ago
> scripting Exactly. So the flexibility and power to pretty much anything you want. Compile and test every single commit on this branch, easy. Being fast, responsive and working on remote machines is also a big plus.
- vkou 5y ago
  An IDE highlighting your mistakes is the definition of fast and responsive. Having to wait for multiple seconds of recompilation is the very opposite of that.
  - cerved 5y ago
    FYI, you can do this in VIM/Emacs and other CLI editors You can also use CLI tools at the same time as using an IDE
    - vkou 5y ago
      > FYI, you can do this in VIM/Emacs and other CLI editors At which point, you are using an IDE, instead of running javac!
      - cerved 5y ago
        I guess you could extend the definition of an IDE but then there's no GUI

touisteur 5y ago

I'm a very heavy gdb CLI user, have my own collection of batch-debug scripts (bisect stuff, fuzzing triage stuff, 'trace every change to variable x' stuff...), and... I wouldn't inflict that on a beginner. Eclipse debugging experience is OK, quite simple to start and do interesting stuff, and you can even patch/continue which as a novice will help a lot. The trick is to 'teach' debugging with the least friction possible. Evaluating the code in your head and comparing with what you observe is the underlying concept, the rest is tools, and they need to get out of the way. As for the OP, I learned java with notepad+CLI and it was terrible. So demotivating. When I discovered Eclipse, I became so happy with java and programming, 'create class', move stuff around, nice autocompletion, find class, refractor, automatic online build, correction suggestions. And I'm a 'using the mouse breaks my flow' old fart. Yes eclipse is buggy, heavy, but damn does it make a difference. It's the standard I compare any IDE to.