Learning about a command-line debugger and command-line profiling tools would be helpful for those that find themselves in the past. IDEA and Visual Studio have had these things integrated for decades. I find the likelihood of knowing how to use a debugger or profiler is inversely proportional to the amount of time someone spends in the terminal. It's astonishing how many developers rely on logging/print statements f…
The quality of debuggers varies hugely, especially since different languages support different debugging features (e.g., conditions vs exceptions vs neither). Logging works pretty much the same everywhere.
Learning about a command-line debugger and command-line profiling tools would be helpful for those that find themselves in the past. IDEA and Visual Studio have had these things integrated for decades. I find the likelihood of knowing how to use a debugger or profiler is inversely proportional to the amount of time someone spends in the terminal. It's astonishing how many developers rely on logging/print statements f…
Logging and print statements are phenomenally useful debugging aids. I think people get too caught up in what a debugger can give them and forget how much value you can get out of logging as well. I'm perfectly happy to fire up LLDB and step through a program, but my go-to first step is frequently to add logs, and one of the reasons is that it's often just plain faster. It's kinda like the binary search of debugging:…
Logging is also less likely to disturb the rest of the program, in my experience (JS). If I want to figure out in what order a set of things executes, I could just add some `console.log('hello')`, `console.log('helloooo')`, `console.log('does this even get called?')`, etc's around and see how they get spat out, or I could add a bunch of breakpoints, mess with the ordering of the event loop, and spend a bunch of extra time manually stepping around.
Learning about a command-line debugger and command-line profiling tools would be helpful for those that find themselves in the past. IDEA and Visual Studio have had these things integrated for decades. I find the likelihood of knowing how to use a debugger or profiler is inversely proportional to the amount of time someone spends in the terminal. It's astonishing how many developers rely on logging/print statements f…
> It's astonishing how many developers rely on logging/print statements for debugging. One reason is that you don't switch contexts if you insert a print statement in your code. I personally find that to be the least distracting way to debug.
In something like VSCode (/any other IDE) you can just hit a keybinding or click the little button just to the left of the line to add a breakpoint; all the runtime info is shown in the sidebar and the debug console is shown where your terminal normally is; and the process to run is often the same as the process to debug. So context switching isn't as big of a deal. But still, print statements definitely have their place.
At my school there is a 2 unit class that you must take along with the intro DS&A course that teaches bash, vim, git, testing, etc. It was definitely the class that helped me the most in my internship and also made me a Vim user. http://ieng6.ucsd.edu/~cs15x/
Oof, the main memory I associate with this class was not realizing there was a midterm and therefore not showing up for the midterm.
Still passed though, and with an A somehow. Thank you, guardian angel TA!
I still remember my first week of engineering school (1997). Before the actual classes started, we had an intensive UNIX week. I loved it. It seemed like the real deal to me. I was already using linux at the time, but for the first time I was properly taught things by experts, and not computer magazines. What was my hobby was suddenly becoming something serious and respected. So much has changed since then but I'm glad that to this day I'm still using the same commands and tools.
> these skills are strongly underrated by universities and students alike. Universities believe their focus should be on timeless principles, and expect that students will supplement their instruction as needed. For example, teaching students the Bourne Again shell isn't useful on Windows, and declining in importance in macOS. Same logic applies to editors, but even more wildly varied. Rather than build 20 courses, o…
It takes no great skill to teach any undergraduate CS class. If you’re talking about skills that are still going to be useful in 50 years, Unix scripting is probably one of the strongest competitors. More critically, the basic model of piping commands through a set of simple programs is extremely powerful and widely applicable.
Perhaps my experience was atypical, but freshman year included a course on proofs of correctness, starting from propositional logic and ending with LTL (comparable in concept to the system Lamport published as TLA+). Upper level course often included a hands-on section on PROMELA. These are not something I would expect a rando practitioner to know about or teach, and only rarely put into practice (albeit to good effect -- amazon uses TLA+ to formally verify their AWS services: lamport.azurewebsites.net/tla/formal-methods-amazon.pdf).
And that's really the value of an undergraduate degree: learning stuff industry hasn't yet widely adopted from the people who helped invent it.
Learning about a command-line debugger and command-line profiling tools would be helpful for those that find themselves in the past. IDEA and Visual Studio have had these things integrated for decades. I find the likelihood of knowing how to use a debugger or profiler is inversely proportional to the amount of time someone spends in the terminal. It's astonishing how many developers rely on logging/print statements f…
Ruby has a great debugging story.
You just type "binding.pry" wherever you'd like to stop the application and in your terminal, it will open a Ruby shell where you can access the program state at that point in your code.
Over the years, we (@anishathalye, @jjgo, @jonhoo) have helped teach several classes at MIT, and over and over we have seen that many students have limited knowledge of the tools available to them. Computers were built to automate manual tasks, yet students often perform repetitive tasks by hand or fail to take full advantage of powerful tools such as version control and text editors. Common examples include holding…
Since you mention scrolling using key repeat - it truly is painful to watch someone do it on default settings. And there are usually better ways to do that sort of thing. But sometimes, there is no substitute: going to the right spot in the middle of a word/line, moving around a page, browser title bars, etc. Here's the kicker though: most keyboard repeat rate settings around have a maximum that is pretty much unusab…
Personally this is what I choose to use the mouse for - even in Vim. A scroll wheel is nicely intuitive for descending a buffer.
I took a Unix half credit course randomly where you basically did bash scripting, a huge bunch of command line tools and then eventually use all that to build your own linux distribution. I swear I learned more in the half credit class, and way more if you try to count it as useful information, than 90% of my other CS courses. Edit: And since this got some traction, here is the current version of the class: https://w…
We had a very similar course at Penn State, as well. It's among three courses that I learned the absolute most from, and have had a huge amount of applicability to my life and career.
Learning about a command-line debugger and command-line profiling tools would be helpful for those that find themselves in the past. IDEA and Visual Studio have had these things integrated for decades. I find the likelihood of knowing how to use a debugger or profiler is inversely proportional to the amount of time someone spends in the terminal. It's astonishing how many developers rely on logging/print statements f…
Ruby has a great debugging story. You just type "binding.pry" wherever you'd like to stop the application and in your terminal, it will open a Ruby shell where you can access the program state at that point in your code. https://github.com/pry/pry
If I sorted debuggers I've used by how great they are, they would all be better than that ruby debugger, including visual basic 3 for windows 3.1.