Hi, I’ve only just started reading this thread and I think that Bennet and Erik kind of hit the nail on the head - I too thought SWC/DC were about concepts of good programming practice, version control, testing, analysis and things like that. But there seems to be a real shift towards pushing specific tools and stacks over the past year or so.
For example, version control is not just Git, there are other alternatives out there and even within Git, there are multiple platform options for it yet Github seems to be pushed a lot (possibly to exclusion of others). Yes, we need to use something as a tool to let people try and learn but it should be an option as to what the tool is, possibly where they work there is a different system for a specific reason, which could alienate people and cause them to switch off. Similarly is there really a need to discuss the text editor? I mean is it that hard a thing to be flexible - I have run courses (SWC and otherwise) where there has been a range of editors and not really had any major problem, the point is that people should use something that does the job, so if they can use nano, vi, emacs, notepad, whatever then let them use it as long as they can put stuff in. I think Bennet makes a good point with the “why is there a shell component” commentary - atom is not a command line editor, and for a lot of people, some of the systems they use won’t have an X-windows or similar capabilities and will only be able to ssh into the command line - now I realise there are extensions to Atom which allow this to happen but its another hurdle another thing to install when most have a text editor in place - which is more important during these courses - the content or the tool? For large systems, like HPC or cluster resources most will use a command line interface and even with smaller systems the command line can be quicker and more convenient (and less distracting), so having more steps and other tools can be an issue - it may not be what they have and they may not be allowed/willing to install/use other tools. So showing how to do what we are teaching with familiar tools would be better than getting them to install and learn another “editor”. And one small note - “beautiful interface” is ambiguous as a benefit as these things differ across the world and individuals. I know this has been a bit of a rant - but there seems to be a growing disconnect between the ideas of helping people gain basic (and not so basic) skills in software development practices and the reality where there is a lot of advocacy or pushing towards certain toolsets for given tasks which have a range of tools. When we get to the point of saying use this editor or this tool and not something else (particular for text editors) then there is something wrong, we can show alternatives but realise that people can use other tools just as well, we should show benefits not just say use this. Regards, Alistair. ----------------------------------------------- Alistair Grant EPCC Rm 2403 0131-650-5028 ----------------------------------------------- Thought to be thought about: Be more concerned with your character than your reputation, because your character is what you really are, while your reputation is merely what others think you are. (John Wooden) On 30/03/2017, 14:54, "Erik Bray" <[email protected]> wrote: >On Thu, Mar 30, 2017 at 3:17 PM, 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. > >I sort of agree with this. I have no idea even what Atom is and I >ain't gonna learn it just so I can teach it. Some might have said >that about "git" once as well, but as least git is an actual useful >skill to learn, whereas sitting someone in an editor more complex than >notepad is just a massive distraction. > > >> On Thu, Mar 30, 2017 at 8:19 AM, Tracy Teal <[email protected]> wrote: >>> Also +1 to Noam's suggestion >>> >>> On Thu, Mar 30, 2017 at 4:59 AM, Ethan White <[email protected]> >>>wrote: >>>> >>>> I support this change in concept and agree with Noam that it should >>>>only >>>> be undertaken broadly following experimentation to make sure it works >>>>more >>>> effectively than the current approach and to iron out any >>>>unanticipated >>>> issues. >>>> >>>> Ethan >>>> On 03/30/2017 07:13 AM, Noam Ross wrote: >>>> >>>> I support this, but I think the appropriate approach is to gather >>>> evidence. Many (most?) changes to lessons and methods start as >>>>experiments >>>> by instructors, so I think a set of instructors should produce the >>>>following >>>> for an upcoming workshop, which other instructors can try out: >>>> >>>> - A fork of the workshop webpage with install instructions >>>> - A fork of the shell lesson >>>> - A fork of the git lesson >>>> >>>> Then, following some reports from instructors after a few workshops >>>>and a >>>> few inevitable tweaks, we can see if this merits widespread adoption. >>>> >>>> I agree with Tracy that command-line editor skills are potentially >>>>useful >>>> for many learners, but I think (without real evidence) that (a) >>>>learning a >>>> simple command line editor like nano is a low barrier *once one is >>>>familiar >>>> with the shell and the notion of a text editor already*, so people >>>>using >>>> remote machines will be much of the way there under this approach, >>>>and (b) >>>> the overall gain in improved workshop flow may be more important. A >>>> command-line editor may be one of the things one "demos" in a >>>>workshop where >>>> learners have a question or one anticipates that some have immediate >>>>remote >>>> computing needs. >>>> >>>> On Thu, Mar 30, 2017 at 5:58 AM Raniere Silva <[email protected]> >>>>wrote: >>>>> >>>>> Hi all, >>>>> >>>>> today at the workshop, >>>>> one of the our Windows learners asked me why after quit nano the >>>>> previous command weren't available when scroll the window up. >>>>> The learner was very annoyed to not be able to see the history. >>>>> >>>>> I would like to motion to change nano with Atom as the >>>>> recommended/default >>>>> text editor for our workshops. I don't want to start yet another >>>>>flame >>>>> war, >>>>> we already had lots and lots of discussion about this, >>>>> so I will summarise the benefits and drawback of my proposal. >>>>> I will ask that before suggest another text editor instead of Atom, >>>>> stop and think that the text editor will benefit novice learners >>>>> instead of just make your life easy as instructor because you use X >>>>>on >>>>> your daily work. (I don't use Atom!) >>>>> >>>>> # Benefits >>>>> >>>>> - Is open source. >>>>> - (Just) works in Windows, Mac and Linux. >>>>> - Easy to install in Windows, Mac and Linux. >>>>> - "All versions" are available to Windows, Mac and Linux. >>>>> >>>>> Some software, e.g. Skype, works in Windows, Mac and Linux but >>>>> different versions are available to different OS. >>>>> - Configure PATH to be accessible from Git Bash. >>>>> >>>>> No need for extra configuration or our script to fix PATH. >>>>> - Well mantained and supported. >>>>> - Syntax highlight out of the box (AFAIK). >>>>> - Lots of plugins for learners that decide to keep using Atom. >>>>> >>>>> AFAIK there is a plugin that allow learners to use Atom >>>>> to edit remote files, e.g. on clusters. >>>>> - Beautiful interface. >>>>> >>>>> # Drawback >>>>> >>>>> - Learners and instructions will need to switch windows. >>>>> >>>>> # (My own) conclusions >>>>> >>>>> Replace nano with Atom will avoid many of the our issues during the >>>>> workshop, such as "we will use nano but if you don't have nano you >>>>>can >>>>> use X", and reduce the volunteer work that we need to maintain the >>>>> quality of our workshops. The price that we will need to pay is >>>>>switch >>>>> windows during the workshop. >>>>> >>>>> Thanks, >>>>> Raniere >>>>> _______________________________________________ >>>>> Discuss mailing list >>>>> [email protected] >>>>> http://lists.software-carpentry.org/listinfo/discuss >>>> >>>> >>> >>> >>> _______________________________________________ >>> Discuss mailing list >>> [email protected] >>> http://lists.software-carpentry.org/listinfo/discuss >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/listinfo/discuss >_______________________________________________ >Discuss mailing list >[email protected] >http://lists.software-carpentry.org/listinfo/discuss -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
