Hacker News new | ask | show | jobs
by wcarey 1961 days ago
A wonderful use case for nano is introducing students who have never used a command line before to unix. You can teach a classroom of students to edit files in nano productively in a single 45 minute class period, which means that an introduction to programming class can move very quickly into actual programming. If your goal is to have student produce a working program on day one of class, nano is a godsend.

By then end of a semester, the students will be running into the ceiling of nano as an editor and you can tell them about other more featureful editors.

1 comments

I don't understand your argument here. You do not need to use a terminal-based editor when you work on the command line. You can run "gedit file.txt" just like you do "nano file.txt" and it will work as well. I guess this may be even easier for newcomers, wouldn't it?

Until you start editing files remotely through ssh, and then they will understand why the obvious thing (calling a graphical program from the command line) may not work as expected.

I think the point may have been that nano is a safe assumption to be on most any GNU/Linux machine where as gedit might not be and that nano has all of the commands listed on the screen for quick reference.

For example when I was taking my sysadmin class we used CENTOS which did not have gedit since it did not have a GUI. We used VI instead, but I learned nano was good for simple fixes and I did not have to google the method of saving and exiting.

For an entry to programming class, I'm not sure why you would forego a GUI though.

For context, I just got my cs degree a year ago and most of my classmates only know a terminal as that bottom pane in vscode

If you want people to get up and running quickly, either require vscode or have people program in one of those browser based IDEs

Students should be taught what the terminal is, how to use it, how to program it, and to not be afraid of it during their program. But whether it belongs in a first class or not is debatable. In a first class, students have so many other things to learn that adding on the terminal can be a bit overwhelming (typically the actual material of data structures & algorithms, but also the syntax of some language, the first time they've ever had to be so precise in writing anything down in their lives). I liked how, in the late 90s/early 00s, GT made a point of teaching you to use the terminal in the 3rd CS course (various numbers, 2130, 2230, some others). By that point, you were comfortable with programming itself so learning to use a computer properly wasn't a big addition there.

I was disappointed when I got to grad school and many of my peers didn't even know how to invoke a compiler or interpreter from the command line. If you didn't give them a common IDE, they were absolutely lost.

The need for precision is such a wonderful thing to teach young people. I start my class with the students typing in exemplar programs and discussing with each other how they think they work. It's amazing how many errors they make in that process; a good reminder of how imprecise we are by default and how unforgiving code is.
The biggest advantage of foregoing a GUI is that the experience of programming is totally modal: you're either in the shell, editing your program, or running your program. That allows students to focus on what they're doing without distraction.

A secondary advantage is that the tools are so wonderfully simple. On the first day we introduce ls, touch, nano, and cc. That's all you need to write your first program. The tool reference fits on one page. And that toolchain will do right by you for anything up to about a kiloline, and in an introductory course, that's about the biggest thing you'll write. So there's no more mussing with tooling. You can focus on algorithms and data structures.

A tertiary advantage is that it forces (and allows) the students to muck around with unix in a way that's oddly less threatening than a graphical user interface. Eventually they start rooting around in /etc and /var and /bin, and learn a whole lot about how computers are organized. So there's some serendipitous learning as well.

Our computers (intentionally) don't have mice.
This is a good thing. But what does it have to do with whether you use curses or gtk-based programs? In both cases you can use either the mouse (eww) or the keyboard.
Truth be told, I've never tried to use a gtk-based editor without a mouse. Which would you recommend? I'll try it out.
I'm not the most representative person for that... I can only suggest gvim ;)

Anyhow, just tried gedit and you can press "^S" to save the file and "^Q" to close the window, which is pretty much all that you need to start editing text files.