What editor should we recommend to novices in place of nano?

[gvwilson]

@selik wrote:

Given how valuable syntax highlighting is for reading code, I think we should suggest a more sophisticated editor than nano on the bootcamp setup instructions. Vim and emacs are too awkward for beginners. Sublime Text works on all mac, linux, and windows; and I've never heard of anyone having install troubles with it.

@gvwilson responded that Sublime Text is closed-source commercial; @gdevenyi added that it's not command-line integrated; Shreyas Cholia pointed out that it's nagware (can be used freely if you disregard the "please buy" notice). More suggestions are welcome...

[jkitzes]

From my email to discuss:

I don't think that it was ever the intention in the setup instructions to suggest that students use nano for extensive coding. In my recent bootcamps, I've gotten everyone to install/use two editors - one graphical plain text (like Textmate, Notepad++) for code writing plus nano for command line work. I basically have them use nano only for editing git commit messages, as it's of course much easier to teach than vim or emacs (and using a graphical editor there would cause additional windows to appear/disappear as the students worked).

Mostly, I just want to note that we probably can't/shouldn't drop nano entirely - although we should certainly supplement it with something else for coding. As to that else, I don't have a strong opinion.

[gdevenyi]

We could add the install of nano synatax highlighting to the bootcamp checking python script.

[scopatz]

Given how valuable syntax highlighting is for reading code, I think we should suggest a more sophisticated editor than nano on the bootcamp setup instructions.

nano does have syntax highlighting and just because it is minimal doesn't mean it lacks in sophistication. Anything that will covered in a bootcamp can be handled by nano, and a lot more. One thing that nano does that most other editors do not (which is a nice feature for bootcamps) is puts the help right on the main screen. If the problem is installing syntax highlighting files, then that is an easy fix.

[synapticarbors]

How difficult would it be for beginners to use Vim in a very naive way? MacVim/gvim have all of the menu driven options (and at least on Mac, the expected keybindings) of something like Sublime. The benefit would be then that they could hop between the command line and GUI and still be in the same environment. To use it in a simple way, are there significantly more keystrokes to remember than nano? Modal editing could be an issue. I'm not advocating for it strongly since I have little experience attempting to use it with beginners, but I feel like when I started using MacVim initially, I was able to be productive without leveraging even a fraction of the commands.

[gvwilson]

@synapticarbors Aaaaaaarrrrgghhhh no no no no no.... whimper

[wking]

On Tue, Mar 04, 2014 at 01:34:33PM -0800, Anthony Scopatz wrote:

Anything that will covered in a bootcamp can be handled by nano, and a lot more. One thing that nano does that most other editors do not (which is a nice feature for bootcamps) is puts the help right on the main screen.

+1. I'd be surprised if students spend more than 5 hours in an editor over the whole boot camp, and I don't think anything that takes longer than a minute to understand is worth the trouble ;). I'll add the syntax highlighting links to our Windows install script 1. How do we want to handle other OSes? Generalize the install script to add OS detection? Per-OS/distro install scripts? Let folks on non-Windows systems link the highlight files by hand?

[gdevenyi]

Arrrgh, and expose the unlearnedness of the instructors who can't exit VIM?!

[synapticarbors]

@gvwilson Fair enough. I thought that might be the response.

[beroe]

@jkitzes - agree 100% with your email to discuss, and that is my approach too. Nano is for quick fixes when they are ssh'd in somewhere, but otherwise a GUI will be better for teaching and coding. Also, I use VI myself but would never inflict teach it to a student.

[leszektarkowski]

There is also Geany http://www.geany.org, linux/windows, opensource. Syntax colouring, pretty fast.

[philippbayer]

What about good old gedit? Some syntax highlighting, a graphical editor, easy to use...

(Also, since atom started this discussion, I'd advise against the use of atom - it looks like it's going to be partially closed source and not free, see https://atom.io/faq )

[leszektarkowski]

@drsnuggles gedit has very old version for Windows.

[jiffyclub]

On Macs Text Wrangler is a free, closed-source editor with command-line integration (it optionally installs an edit utility that pops open TextWrangler).

Similar to @jkitzes, my strategy has not been to recommend a couple of GUI editors and fall back to nano for things like git commit messages. Our workshops are short experiences (though we hope memorable), so I've thought our choice of editors important mainly for their ability to stay out of the way.

[jkitzes]

If we consider open source to be important, the update to Textmate (Textmate 2) is GPL3 (only for Mac users).

[selik]

Despite the bootcamps being short, I think it serves our goals to suggest an editor that the students can use for life (or until they become wise enough to choose their own editors). This has the same logic as encouraging the students to bring their personal computers to the bootcamp. It may require more setup efforts initially, but over the course of the bootcamp I think it will improve the students' impressions of how pleasant the workflow we're presenting will be in practice.

Considering the students are novices, we may want to err on the side of graphical interfaces and easy installation. Is there a reason to have an editor invokable from the command line other than to edit version control commit messages? If not, then we may also want to consider teaching with a (gasp) graphical interface for git (http://git-scm.com/downloads/guis).

[scopatz]

Despite the bootcamps being short, I think it serves our goals to suggest an editor that the students can use for life (or until they become wise enough to choose their own editors).

Which is exactly why nano is great :)

[wking]

On Tue, Mar 04, 2014 at 02:51:50PM -0800, Anthony Scopatz wrote:

Which is exactly why nano is great :)

I didn't realize that you maintain a whole bunch of syntax highlighting files for Nano 1 ;). Is that because it's too painful to work with Subversion 2, or are there other reasons you don't push those back upstream to GNU Nano?

[scopatz]

@wking it is mostly laziness* and the desire to have some customization. Some of the defaults I find a little hard on the eyes and mine are softer. However, I actually have support for a bunch of formats that aren't in the mainline repo. The nano has historically been pretty quiet too. There has been an uptick in activity recently though so now would probably be a good time.

* Subversion being too painful is a great excuse though!

[karinlag]

On 04.03.2014 22:38, Joshua Adelman wrote:

How difficult would it be for beginners to use Vim in a very naive way? MacVim/gvim have all of the menu driven options (and at least on Mac, the expected keybindings) of something like Sublime. The benefit would be then that they could hop between the command line and GUI and still be in the same environment. To use it in a simple way, are there significantly more keystrokes to remember than nano? Modal editing could be an issue. I'm not advocating for it strongly since I have little experience attempting to use it with beginners, but I feel like when I started using MacVim initially, I was able to be productive without leveraging even a fraction of the commands.

Considering that the first time I used vi I managed to core dump not once, but three times, I would not recommend it for beginners.

Editors should IMO be out of the way during the bootcamp, which is why I like nano. With nano, there is really no learning required, really. If we show them something else, it should stay at the same level, i.e. be something that they do not have to learn.

Karin

Karin Lagesen

[mikej888]

There seem to be two issues being conflated here:

1-What editor do we recommend to novices 2-What do we use in boot camps

For 1, it would depend on the language the attendees will be using when they "return home". For example, if a novice was going to be coding in Java I'd mention Eclipse to them, for a novice planning to do C/C++ on Windows, then I'd suggest Visual C++. Given one of SWC's goals is to teach people to do more in less time with less pain (and adopt good practices from software development) then the popular IDE(s) for whatever language they choose should be recommended, where these exist, in preference to any text editor (sometimes it may just end up being GCC + Make + text editor).

For 2, one attendee did ask why we didn't use IDEs to which I replied it was to not complicate the setup any more than necessary and that as our code examples were quite small we could get away with an editor. Though, syntax highlighting could be useful for these small examples, I think we should remind attendees that the concepts we teach on a boot camp are more important than the specific tools we use to demonstrate those concepts (no amount of highlighting is going to compensate for cryptic function names or functions that are 300 lines long with large commented-out chunks, for example).

[apawlik]

I wonder if one of the things that should be taken into account when considering which editor to use/recommend, is why we teach the modules we teach. In particual, why do we teach command line?

I have been asked this question a number of times. My reply and rationale is that it's for a) automation and b) showing people how to use a nix environment where there is *no GUI. As to (a) I'm often told that automation can be taught with Python and R. Which is a fair point considering the kind of automation we teach people (typically manipulating files) Yes, I believe in supremacy of pipes and make, but you can write Python code for most automation we teach. So I've heard arguments that it'd be better to cut the shell module and spend more time with Python/R.

However, rationale (b) tends to convince most people that challenge the need for teaching shell. Maybe our studends now only work in GUI environment. But who knows, in a week, month, six months time they will be given a login, a password and be told to "ssh to the server" . Bazinga. Once you struggle though ssh-ing, you can't click around and Notepad++ and Sublime is not there. Oh, but there is this silly little thing they showed us at Software Carpentry bootcamp, nano! And then at least you can do a quick fix, like @beroe says.

For that reason I try to stick to command line native stuff when teaching (if you ever end up in front of the terminal, you're likely to find these things and not freak out). I just always say to people that if they are already using a different editor, they should go with it (I've actually seen some who only know vi even though their knowledge of shell is limited to "cd" and "ls"...wonder who did they learn from...)

I'm with @karinlag on not using vi at the bootcamps :-) Let alone emacs (gorgeous but "Excuse me, I've got a question, what is a 'buffer'?")

However, there is a separate question of recommending an editor for writing longer code (as per @mikej888 comment) without saying "don't try this at home".

Also, as to highlighting and teaching programming...IPynb highlights the code and we're leaning towards using the Notebooks for teaching programming, aren't we?

[wking]

On Wed, Mar 05, 2014 at 04:57:37AM -0800, Aleksandra Pawlik wrote:

it's for a) automation and b) showing people how to use a nix environment where there is *no GUI. … However, rationale (b) tends to convince most people that challenge the need for teaching shell.

To play devil's advocate, you'll probably have Python available in GUI-less environments too ;). I think the various shell languages just make filesystem manipulation and program launching easier than they would be in Python, since they were designed for that problem domain.

Wed, Mar 05, 2014 at 02:40:16AM -0800, mikej888:

There seem to be two issues being conflated here:

1-What editor do we recommend to novices 2-What do we use in boot camps

I think this issue is about what we recommend for boot camps. In @selik's initial post:

I think we should suggest a more sophisticated editor than nano on the bootcamp setup instructions.

For that, we really want to pick a single, simple editor to avoid confusion (and nano is hard to beat here). However, you can recommend whatever you like for students to look into once they get home. There are lots of rational people out there using lots of editors / IDEs, and picking the best one for a given student is something that's better left up to the student themselves ;). If we want to list our recommendations somewhere for easy reference, that would be helpful too.

[wking]

After an initial flurry of activity, this one seems to have stalled out. I'm going to close this, but feel free to reopen (or comment on the closed issue) if you have more to add about changing the suggested editor for workshops, or for assembling a list of post-workshop suggestions to guide students as they continue forward.