Improvements to IDE discussion in episode 01-run-quit.md

[rodrigolece]

This PR addresses issue #591 which points out that the wording of the first paragraph in the lesson can be confusing.

I disagree with @jdinklo because I do not think that we can say JupyterLab is an IDE but I tried to clarify the wording to say that we can either run and IDE, a text editor, or in this case we use JupyterLab to run Python interactively.

[vahtras]

Actually, Jupyter describes themselves as an interactive development environment, which is not an IDE (integrated development environment). So my view is that we these three main categories of tools: text editors, IDE:s and interactive environments (Jupyter, IPython, bpython, REPL), but that the border lines are not always crystal clear. Even vim can be made to look like an IDE with appropriate plugins to produce split windows with file managers, command-line shells in addition to being a code editor.

[rodrigolece]

Thank you both for your input! And so prompt :)

I agree with @vahtras , I think that there are so many nuances to this discussion because all of the possible extensions and configurations. My working definitions, leaving plugins aside would be:

• Text editor: used to write plain text and save it. You would run the text file from the terminal. Indeed, because I'm thinking no extensions I'm thinking Atom, Visual Studio Code, vim, etc.
• IDE: an application that often has multiple windows, one for writing text, but also a REPL, a debugger, a pane for figures. I'm thinking the Matlab IDE or RStudio, and I understand that PyCharm and Spyder fall in this category though I've never used either of them. The file is normally run all at once, similar to running the script like you do with the text editor.
• What @vahtras call an interactive development environment (I didn't know the terminology, thanks!). I guess the main difference here is the interactivity of the environment, this is much closer to running Python from the REPL right? Sure, JupyterLab has extensions for debuggers, etc, but it is quite different in its basic nature to both the IDEs and text editors.

My intension is not to add any more confusion and impose my own view of the world so I agree that we might still be able to simplify the phrasing. My idea of adding examples is that maybe people have heard the names or even used them but they don't necessarily know the difference between IDE and text editor. But perhaps from this discussion it is best to leave the examples out?

[HobnobMancer]

I think it's a good idea to introduce (albeit briefly) the different environments where code can be written and executed. Plus, examples might help learners to select the right environment for their work post-workshop. I also agree that bringing this up in the lesson might help reduce confusion for people who have frequently heard terms like IDE, VSCode, PyCharm, etc. being thrown about without any explanation.

Maybe the suggested addition could be expanded a little? For example, a couple of generic points could be added to explain what IDEs are and why we teach using JupyterLab/Notebook instead of other widely used tools for software development - linking back to an excellent point made in issue #591. Maybe something along the lines of:

To run Python, we are going to use the Jupyter Notebook via JupyterLab for the remainder of this workshop. There are other ways of creating and running code. Many software developers use an integrated development environment (IDE) (such as PyCharm) which include tools to support software development, or a text editor (for example Visual Studio Code) to create and edit their Python programs. After writing their program, software developers often use the IDE or the command line to execute their program. Alternatively, JupyterLab will let us run Python interactively so that the result of a command is returned after its execution, which has several advantages:

• You can easily type, edit ...

[alee]

Thank you all for the discussion here! I've opened another PR for this at #630 if you don't mind taking a look and having a quick thumbs up or not if the new language and changes are OK. I cherry-picked your commit @rodrigolece as these changes were committed to your main gh-pages branch instead of a feature-branch which isn't conducive to subsequent changes.

Closing this PR in favor of #630 please continue any other discussion there. We need to start closing out all of our open PRs in preparation for the upcoming Workbench lesson transition