I think Bennet summed up my views on the issue best. It seems to me it is not so much about whether Atom is hard to learn, but that it is a fundamentally different tool (GUI) in many respects. Nano is something that will allow them to work remotely, keep their mind centered on where they are (folder-wise) while using the shell, and edit git commit messages when there are conflicts (once configured).
So while I would not use or recommend it as the main coding environment, it seems there are essential aspects of the basic SWC syllabus which just about require the introduction of a shell-based text editor. Whether you try to introduce *both* is another question. It is also nice that the availability of linux command-line functionality in Windows 10 will make many of these issues less relevant in a couple years. -Steve _______________________________________________________________ Steven Haddock, PhD : [email protected] Monterey Bay Aquarium Research Institute 7700 Sandholdt Rd., Moss Landing, CA 95039-9644 831-775-1793 (office) 831-775-2095 (lab) 831-775-1620 (fax) * Practical Computing textbook: http://practicalcomputing.org/mbari * Scientific publications: http://www.mbari.org/haddock-lit * Report marine sightings: http://jellywatch.org * Bioluminescence Web Page: http://biolum.eemb.ucsb.edu > On Mar 30, 2017, at 06:17 , Bennet Fauber <[email protected]> wrote: > > I really do not mean to be a troll, here, but it seems to me that the > trend is to develop SWC/DC away from a coherently organized workshop > centered around the idea of creating a pipeline that is run using > scripts, invoked from a command line, and that is under version > control. That is how I interpreted the original idea; perhaps > incorrectly. > > It seems as though most lessons are now R Studio based. Some Python > lessons may be Spyder based. I'm pretty sure I seen much discussion > about GUI front-ends to Git. If I were taking a workshop with Atom, > gitk, and R Studio, I would really have to wonder why there was a > shell component at all. > > I think that in the past, one learned shell to move around, nano to > edit, then one used nano and the shell to create R or Python files, > which were run from the command line, and all of the code was under > Git control which was also run from the command line. That scheme has > an internal coherence, it builds skill upon skill, and there is a > recognizable goal. > > The lessons seem to be getting more and more independent and less and > less like parts of something bigger -- at least that's how I would see > it from a participants perspective and based on the anecdotes I have > from people who've been to recent camps. > > There have been many discussions about individual lessons and far > fewer about connections among lessons, or so is my impression. Is > optimizing each lesson separately really going to lead to a globally > optimized result? What is the result that is desired? > > I really don't want to start a firestorm, but I think it's good every > once in a while to step back and look at how the pieces fit together. > How does teaching someone the shell help them with Atom, or > vice-versa? Would it be better to just drop the shell entirely and > create a full lesson on Atom? The world does move on, and I'm just > missing the point, in which case ignore me. I'm really just trying to > give something to think about, as part of 'due diligence'. If you > think Atom is the way to go, then you're definitely on the right track > with trialing in a lesson and seeing how it plays. > > _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
