<p>It may be easier to transition students who have gained proficiency in using a a command-line environment to switch to using an GUI IDE, than vice versa.  If so, starting with an editor+terminal will allow more flexibility in your later curriculum design.</p>

CC BY-SA 3.0
2017-09-01T22:25:32.687Z
2017-09-01T22:25:32.687Z
hotpaw2
<p>Go to local companies and talk to the developers.  The command-line interface is still used a great deal owing to its programmability and extensibility.  My beginning students learn about the command shell.  </p>

<p>Also, Python has command-line arguments, which make programs you create in it far more versatile.  </p>

<p>The vi editor and gedit provide very nice syntax coloring.  They also don't "spoil" the user with auto-completes early in their learning.</p>

CC BY-SA 3.0
2017-08-29T15:34:23.127Z
2017-08-29T15:34:23.127Z
ncmathsadist
<p><strong>TL;DR</strong> Those two aren't your only options. </p>

<p>The main concern is cognitive load: learning to program is difficult enough without adding incidental complexity. </p>

<p>We've seen an explosion of hybrids in the last few years with good cross-platform support: Sublime, Atom, VSCode, etc. And while you couldn't pry vim out of my cold dead hands, learning it is easy if you already know programming but would be a nightmare if you had to learn it and programming at the same time. Ditto for emacs.</p>

<p>And that also applies to IDEs like Eclipse and Visual Studio. They have their own way of doing things. They take forever to open. They are user configurable but not easily. I'll never forget the first time I opened XCode and basically said "what the hell is all of this?"</p>

<p>Have your students download vscode or atom which work reasonably well out of the box with a healthy plug-in community for growth. They're scriptable in JavaScript and themable with CSS. Unlike notepad it gives you features you actually need to program, unlike nano it uses standard keyboard shortcuts they'll already know from e.g. MS Word (Ctrl-C, Ctrl-V, Ctrl-S, etc). And unlike VS/Xcode/Eclipse it doesn't obscure <em>what</em> you're doing with a bunch of platform-specific goobledegack: you're editing text files.</p>

<h2>Edit</h2>

<p>Can't believe I forgot to mention this but...</p>

<p>They more or less made us use Komodo Edit (free version of the Komodo 'IDE') in my first programming class, which is exactly the kind of thing I'm talking about and I think it really helped. Simple, no configuration necessary, things that should be easy were easy, etc. Don't know if they still offer it or not but I'd say Atom or VSCode are better along just about every conceivable metric.</p>

CC BY-SA 3.0
2017-08-29T21:29:43.987Z
I like this answer, because is completely true. For beginners I think this hybrids are the best option. I was thinking in Visual Studio Code, that actually opens really fast and has a lots of plugins easy to install. Using this, you can focus in programming and not in configuration.
Kenny Barrera
CC BY-SA 3.0
2018-03-12T20:30:12.790Z
@KennyBarrera VS Code is probably fine, I was thinking of VS itself which is, to say the least, heavyweight.
Jared Smith
CC BY-SA 4.0
2019-02-19T03:07:35.893Z
Especially "ditto" for emacs. It's really another language. Sublime ... no problem. Acts like an editor.
42-
CC BY-SA 4.0
2017-08-28T14:14:23.703Z
2020-03-17T14:27:06.097Z
2020-03-17T14:27:06.097Z
Jared Smith
<p>Here are my thoughts on this.</p>

<h1>Editor and Terminal</h1>

<p>This is most likely the <strong>more lightweight solution</strong>. Editor and terminal often don't consume much space (or, at least, come bundled with the operating system so it doesn't really matter) and start fast.</p>

<p>Using editor and terminal can demonstrate students that writing a program can be done without using a huge IDE including a lot of tools, as it is essentially <strong>not more than writing down instructions</strong> using a <strong>normal text editor</strong> and executing them.</p>

<p>An advantage, especially for beginners, could be that it <strong>doesn't overexert the students</strong> with too much information - in contrast to IDEs that come with syntax highlighting, code style checking, automatic error correction and code suggestion.</p>

<p>It's worth noting that there are multiple "levels" of editors: When choosing the editor, one could choose between a simple text editor without any programming-related features (not even syntax highlighting), more advanced editors that have syntax highlighting, or something like <a href="https://docs.python.org/3.6/library/idle.html" rel="noreferrer">IDLE</a>, which is an IDE on the one hand, but at least in my opinion more like an advanced editor. This could help finding a compromise between a fully-featured IDE and a text editor.</p>

<h1>IDE</h1>

<p>IDEs are most likely a more <strong>heavyweight solution</strong>. Normally, they consume a lot of disk space as well as memory and have a notable startup time.</p>

<p>They can <strong>assist fixing errors</strong> by highlighting them and providing possible solutions. This is definitely an advantage in day-to-day use, however, when it comes to teaching how to find errors, one could interpret this as a disadvantage, as it's possible that students start to rely only on their IDE when searching errors and wouldn't be able to find them without any help.</p>

<p>Furthermore, IDEs can help to <strong>improve programming speed</strong> with features like autocompletion, built-in refactoring tools etc.</p>

<p>A feature that could be nice to have for beginners is that IDEs normally have a <strong>nice debugger</strong> which could be used to motivate students to debug their code when they see an error. This is something the editor/terminal combination can't achieve - even if there are command line debugging tools, they are most likely not user-friendly enough.</p>

<p>What I believe is also worth noting (inspired by <a href="https://cseducators.stackexchange.com/users/27/ben-i">Ben I.'s</a> <a href="https://cseducators.stackexchange.com/a/184/793">answer to a related question</a>, thank you) that IDEs come with <strong>integration for professional developer tools</strong> like version control systems or unit testing. I am not sure whether this is already needed in the first year of programming, but I can definitely come in handy later.</p>

CC BY-SA 3.0
2017-08-28T09:44:47.007Z
A good answer,  I would add auto-correct should be considers harmful. Though spell check, and error highlighting are not. Also my text editor has revision control.
ctrl-alt-delor
CC BY-SA 3.0
2017-08-28T17:16:02.607Z
Do you count the "idle" IDE as a heavyweight solution ?
Michel Billaud
CC BY-SA 3.0
2017-08-28T17:53:14.293Z
@MichelBillaud Good question - I think I don't. As far as I can remember, IDLE comes bundled with Python (so from the space point of view it's like the OS-builtin editor) and starts pretty fast, so it seems "lightweight" to me (at least, judging by my quite subjective criteria).
TuringTux
CC BY-SA 3.0
2017-08-28T20:06:00.407Z
I don't think that "consume a lot of disk space and memory" is really worth the consideration these days. PyCharm right now needs less memory than some single chrome tabs and requires about 500MB of disk space - both negligible even for the weakest notebooks. There are lots of other arguments that should imo be more front and center than that.
Voo
CC BY-SA 3.0
2017-08-29T07:25:42.180Z
@Voo I think that this depends a little on the machine - on my laptop, PyCharm takes considerably more time until it's usable than the standard text editor. From my experience, I think this could be relevant for school PCs as I've seen that they are often not the latest and fastest models.
TuringTux
CC BY-SA 3.0
2017-08-29T08:24:12.147Z
@Turing Startup time definitely. But my point is you only start it once and when it's running the amount of resources it needs is hardly worthy the consideration these days. If you spend several hours programming, whether the initial setup takes <1 second or 10 seconds is not that relevant.
Voo
CC BY-SA 4.0
2019-02-19T19:33:56.033Z
Another advantage of an editor is the ability to just get something "on paper" without worrying about any syntax. In using an IDE (which I do, but also use editors), I am sometimes put off by all the "errors" that are a result of just typing thoughts and structure. "Yes, IDE I know it isn't syntactically correct, but I don't care. I'll deal with that later."
Fritz Sieker
CC BY-SA 3.0
2017-08-28T08:57:40.920Z
2017-08-28T08:57:40.920Z
TuringTux
<p>Of course it depends on your overall goals. For me, however, the answer is clear: Use the most powerful IDE that I can find (Eclipse or NetBeans fit my def). </p>

<p>I started programming on primitive equipment (card punch) and came up through every level since. I don't romanticize the old way of work and I wouldn't go back. I wouldn't try to impose primitive tools on newcomers. But then, in CS1 my goal is to teach them how to program effectively. I think that is a hard enough job that I want to ease the path in every way possible - remove all obstacles to thinking about the problem and creating a solution. </p>

<p>In Eclipse, I can integrate testing. I don't need to type every character of the program. I can leave pretty-printing to the system. I can integrate useful program metrics. I can have compilation done automatically. I can search by structure, not just text. And on and on. Emacs is quite wonderful, but it has about 200 textual commands to learn. Life is short. </p>

<p>I wouldn't try to impose any less-than-the-most-powerful tool on a pro. I wouldn't on a novice either. However, if someone comes to me already a vim (say) expert, I'd let them use it, and might not even notice. But if they hand me unreadable code, I'll notice pretty quick. </p>

<p>But as I said at the top, it depends on your overall goal. For me, the overriding goal is to ease the process so that students can focus on the programming itself and the mind-expansion that comes from that. If a better tool comes along, I'll work to use that. Key punching was abominable. So was the teletype, ... </p>

<hr>

<p>Pretty printing is good because it lets me see the structure of a program without first fighting to get it into shape. Not typing close brace lets me think about what I'm trying to create, not the requirements of the language itself. Writing a test for a nonexistent feature and then having the system enter the skeleton for that feature is just marvelous. No cut, switch, paste, or mis-spell and correct. It just works. It lets me get into a flow of creation that I can't do if I'm writing just text. </p>

<p>Nor can I find a language that I can't write in Eclipse, since it isn't really an IDE, but a workbench onto which you can plug nearly any tool. Like Emacs, it has a lot of headroom (and isn't unique in that, of course). </p>

CC BY-SA 3.0
2017-08-29T01:15:04.937Z
Commercial IDEs are also an option since many provide free licenses to students, educators, and classrooms (e.g. [Jetbrains IDEs](https://www.jetbrains.com/products.html?fromMenu#type=ide)).
Thunderforge
CC BY-SA 3.0
2017-08-29T06:49:44.610Z
I too started with (hand) punched-cards, and while I wouldn't suggest going back to that, there is a potential danger that a _do-it-all-IDE_ can hide a lot of what's really happening from a new student, and produce _cut-and-paste-coders_ that don't _really_ understand what they're doing (and lead to some of the poorer questions on StackOverflow). On the flip side, systems, libraries and frameworks have got so complex that very few people _could_ every understand "everything", so a degree of "trust the black box" is necessary. Perhaps a term of no-frills _programming_ before switching to IDEs.
TripeHound
CC BY-SA 3.0
2017-08-28T12:31:54.800Z
2017-08-28T12:31:54.800Z
Buffy
<p>The real question is this: do you want to teach your students what is actually going on, or teach them which magic buttons to press in an IDE?</p>

<p>Of course for professional programming work nobody would NOT use the most functional IDE they could find for the task they were doing. But if you throw a complete beginner into the deep end of a tool like MS Visual studio, they are unlikely to have any idea what is going on, and the only way they can create a working project without wasting a lot of time is be following a "magic recipe" provided for them. Personally I don't consider that to be a university-level learning experience.</p>

<p>Of course they shouldn't be forced to use a command line "for ever," but IMO they should certainly be required to use it until they understand the relationship between classes or modules with physical files (including any required naming conventions,) how to get the individual parts connected together into a complete application, etc. </p>

<p>Those are <em>transferrable</em> skills, as is the more basic one of being able to use a command line at all. The details of using a particular IDE are <em>not</em> transferrable, unless you understand what they actually DO. The command-line-level skills are also what you need to figure out for yourself why a "new improved" IDE isn't doing what you want when you first migrate to it!</p>

<p>Related to this, also start early teaching them how to use a version control system in a simple way from the command line - not to mention "make!" </p>

<p>Actually, using vi (or vim) or emacs plus command line commands can be an efficient way of working without an IDE, since the command line commands you need often are only one key-press away!</p>

<p>In a real working environment, there is nothing more confusing than sitting down at someone else's workstation where they have configured an IDE in a completely different way from your own - that's the time when just firing up "vi" in a command window can be the <em>quickest</em> to get "real work" done!</p>

CC BY-SA 3.0
2017-08-29T07:00:58.467Z
As I comment on [Buffy's answer](https://cseducators.stackexchange.com/a/3385/1372), I think there's a lot to be said for starting at the "nuts and bolts" level, at least for a while, to try to give students a solid grounding so they have a better understanding of what the _do-it-all-IDE_ is doing for them. In a similar way to when I did "O-level" maths, and one test-paper was calculator-free (slide-rules/log-tables allowed) to prove you understood the basic concepts involved.
TripeHound
CC BY-SA 3.0
2017-08-29T16:22:33.163Z
At the same time, do you really want to bother first year students with things such classpaths (oh god), manually configuring gradle projects and whatnot? "So before we start programming, you'll now get a 4 hours introduction into technical details that are in the end irrelevant for programming but are required to get started" just doesn't sound like a great introduction. In the end even if there's no IDE, you'll still give them some basic structure that they won't understand so that they can get to the interesting parts.
Voo
CC BY-SA 3.0
2017-08-29T16:23:54.563Z
And if you do that anyhow, using an IDE doesn't seem particularly problematic from the "magic" POV. It just depends whether it actually helps or distracts from the actual programming. I certainly would think that developing Python without IDE is a great deal easier than say Java.
Voo
CC BY-SA 3.0
2017-08-29T01:44:06.867Z
2017-08-29T01:44:06.867Z
alephzero
<p>I like to ease people in. You have mentioned that this is for first year. So, yeah, easing in would really have a positive impact on the overall learning experience. </p>

<p>I would like to draw from my own experience between a GUI and command line. When I was introduced to version control, the whole thing was intimidating. I decided to go with the Github Desktop, and got an understanding of version control. Once I was okay with that, I switched to the git bash command line. Now, I use command line everywhere, and have been for years. </p>

<p>I have used this technique on many students, and the success rate has been higher. Also, most of these students (at least those who take software development seriously ) will migrate to the command line on their own when they are ready. That way, I leave the choice to them. </p>

CC BY-SA 3.0
2017-08-28T10:29:20.887Z
2017-08-28T11:59:24.750Z
2017-08-28T11:59:24.750Z
Jay
<h2>For the editor</h2>

<ul>
<li>You can use the same editor for every language.</li>
<li>You can use the same editor for every system.</li>
<li>You can use the same editor every year: I learnt emacs (and vi) in 1991, and still use them.</li>
<li><p>They are much simpler, and pupils need to learn the editor/ide at same time as the language.</p></li>
<li><p>IDEs can reinforce the separateness of your program: you program runs on an operating system and can interact with other programs. This can  be diminished by using and IDE.</p></li>
</ul>

<h2>For the IDE</h2>

<p>If the IDE provides faster feedback, then it can aid leaning and productivity. It the 1960s the interactive tty was a massive improvement in both of there. For an IDE to improve on this, it needs to take it a step further. See work of Bret Victor for where this is hopefully going. However most current IDEs do not do anything useful. With a few exceptions.</p>

<ul>
<li><p>Effel Studio — can show different views of the code: Editing view, contract view, flat view, pictorial view. This is taking “the code is the documentation to its limit”.</p></li>
<li><p>Visual Studio — has intelitype, though there is controversy as to whether this aids learning, or results in better code.</p></li>
<li><p>Eclipse — Allows you to compile code, with out it breaking because of a compilation error in one bit.</p></li>
<li><p>Most IDEs — have a run button, so run the code that you are looking at. (some editors also have this). </p></li>
<li><p>IDEs often have better code navigation. Show where used.</p></li>
<li><p>IDEs often have better re-factoring tools.</p></li>
</ul>

<h2>Summary</h2>

<p>Not all IDEs are the same. Not all editors are the same. You will have to look closely at your editor, IDE, to see if the IDE provides anything more, and does not make things too much more complex.</p>

CC BY-SA 3.0
2017-08-28T09:01:25.733Z
In my opinion, using the same software on every system is not really a sole advantage of text editors as most IDEs also support multiple operating systems. Is it possible that I've misunderstood this formulation?
TuringTux
CC BY-SA 3.0
2017-08-28T17:39:32.983Z
@TuringTux I think it's a matter of degree rather than of absolutes.  Some IDEs eg Eclipse are widely available on many platforms; others eg Visual Studio are single platform.   Even then Eclipse isn't as widely available as emacs or vi; I suspect the same would be true for eclipse vs Sublimesque text editors as well; if not individually then as an entire product class.
Dan Is Fiddling By Firelight
CC BY-SA 3.0
2017-08-28T08:42:19.427Z
2017-08-28T09:35:43.693Z
2017-08-28T09:35:43.693Z
ctrl-alt-delor
<p>Most of the IDEs that have been mentioned are <strong>more</strong> confusing than just using a basic text editor and the command line. If I were you, my plan would be:</p>

<ul>
<li>Start students with a <strong>very basic</strong> IDE.</li>
<li>Allow students to "graduate" to the command line.</li>
<li>Then allow students to further "graduate" to more advanced IDEs, which are what most of the other answers are talking about.</li>
</ul>

<p>With that in mind, you might consider using <a href="http://py.processing.org/" rel="nofollow noreferrer">Processing.py</a>, which is a very basic IDE that allows you to write Python code that uses <a href="http://processing.org" rel="nofollow noreferrer">Processing</a> to create simple animated and interactive programs.</p>

<p><a href="http://py.processing.org/tutorials/" rel="nofollow noreferrer">Here</a> are a bunch of Processing.py tutorials, and you might also check out:</p>

<ul>
<li><a href="https://cseducators.stackexchange.com/questions/2793/order-to-teach-topics-in-an-intro-programming-class/2798#2798">Order to Teach Topics in an Intro Programming Class</a></li>
<li><a href="https://cseducators.stackexchange.com/questions/19/using-processing-as-an-entry-point-in-an-introductory-course/2920#2920">Using Processing as an entry point in an Introductory Course</a></li>
<li><a href="https://cseducators.stackexchange.com/a/173/2068">https://cseducators.stackexchange.com/a/173/2068</a></li>
</ul>

<p>I would recommend starting with Processing.py for the first class, then "graduating" to using "pure Python" on the command line in the second course, and introducing more advanced IDEs towards the middle of that second course.</p>

CC BY-SA 3.0
2017-08-28T16:29:36.603Z
2017-08-29T22:10:43.190Z
2017-08-29T22:10:43.190Z
Kevin Workman
<p>I am involved in the teaching of CS1 and CS2 at the University of Oslo. We have recently transitioned from Java to Python as our introductory language. We have a strong tradition of teaching students how to use text editors and the terminal to write and run programs, in a Unix environment at our university. Recently, however, a discussion among the teaching staff has arisen about whether or not to transition to using an IDE for the teaching of first-year programming.</p>

<p>Can anyone give me their thoughts on this matter? What are the pros and what are the cons of moving to an IDE-first approach, rather than sticking with editor+terminal?</p>

CC BY-SA 3.0
2017-08-28T08:25:05.350Z
Welcome to 
Computer Science Educators. This is an interesting question. Hope to see you around here more.
ctrl-alt-delor
CC BY-SA 3.0
2017-08-28T12:01:35.793Z
This seems like a duplicate of [this question](https://cseducators.stackexchange.com/q/44/58). Can you explain the difference to me?
thesecretmaster
CC BY-SA 3.0
2017-08-28T12:21:54.643Z
@thesecretmaster That question is about teaching HTML to 11-13 year-olds, whereas this is a question about a course on the university level. It is reasonable to assume that more cognitive load is managable for university students than children, making the question about editor+terminal vs. IDE more relevant. Furthermore, HTML requires only an editor, whereas programming includes using the terminal to actually run the programs.
Henrik Hillestad Løvold
CC BY-SA 3.0
2017-08-28T19:43:38.430Z
Each student is different, and each will have vastly different needs from such a personal tool. Why not give them positive arguments for both things and let them individually choose what to use? Python was taught at my university for first years and some of us used VIM some used PyCharm and some used GEDIT.
axwr
CC BY-SA 3.0
2017-08-29T11:19:57.977Z
Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/64717/discussion-on-question-by-henrik-hillestad-lovold-ide-vs-editor-and-terminal-for).
thesecretmaster
<python><ide>
IDE vs Editor and terminal for CS1
# IDE vs Editor and terminal for CS1

(Asked by: username_0 on 2017-08-28)

I am involved in the teaching of CS1 and CS2 at the University of Oslo. We have recently transitioned from Java to Python as our introductory language. We have a strong tradition of teaching students how to use text editors and the terminal to write and run programs, in a Unix environment at our university. Recently, however, a discussion among the teaching staff has arisen about whether or not to transition to using an IDE for the teaching of first-year programming.

Can anyone give me their thoughts on this matter? What are the pros and what are the cons of moving to an IDE-first approach, rather than sticking with editor+terminal?

**Tags:** python, ide

> **Comments:**
> **username_1**: Welcome to  Computer Science Educators. This is an interesting question. Hope to see you around here more.  
> **username_2**: This seems like a duplicate of [this question](https://cseducators.stackexchange.com/q/44/58). Can you explain the difference to me?  
> **username_0**: @username_2 That question is about teaching HTML to 11-13 year-olds, whereas this is a question about a course on the university level. It is reasonable to assume that more cognitive load is managable for university students than children, making the question about editor+terminal vs. IDE more relevant. Furthermore, HTML requires only an editor, whereas programming includes using the terminal to actually run the programs.  
> **username_3**: Each student is different, and each will have vastly different needs from such a personal tool. Why not give them positive arguments for both things and let them individually choose what to use? Python was taught at my university for first years and some of us used VIM some used PyCharm and some used GEDIT.  
> **username_2**: Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/64717/discussion-on-question-by-henrik-hillestad-lovold-ide-vs-editor-and-terminal-for).  

---

## 9 answers

### Answer by username_6 on 2017-08-28. Score: 19 | Accepted answer

**TL;DR** Those two aren't your only options.

The main concern is cognitive load: learning to program is difficult enough without adding incidental complexity.

We've seen an explosion of hybrids in the last few years with good cross-platform support: Sublime, Atom, VSCode, etc. And while you couldn't pry vim out of my cold dead hands, learning it is easy if you already know programming but would be a nightmare if you had to learn it and programming at the same time. Ditto for emacs.

And that also applies to IDEs like Eclipse and Visual Studio. They have their own way of doing things. They take forever to open. They are user configurable but not easily. I'll never forget the first time I opened XCode and basically said "what the hell is all of this?"

Have your students download vscode or atom which work reasonably well out of the box with a healthy plug-in community for growth. They're scriptable in JavaScript and themable with CSS. Unlike notepad it gives you features you actually need to program, unlike nano it uses standard keyboard shortcuts they'll already know from e.g. MS Word (Ctrl-C, Ctrl-V, Ctrl-S, etc). And unlike VS/Xcode/Eclipse it doesn't obscure *what* you're doing with a bunch of platform-specific goobledegack: you're editing text files.

## Edit

Can't believe I forgot to mention this but...

They more or less made us use Komodo Edit (free version of the Komodo 'IDE') in my first programming class, which is exactly the kind of thing I'm talking about and I think it really helped. Simple, no configuration necessary, things that should be easy were easy, etc. Don't know if they still offer it or not but I'd say Atom or VSCode are better along just about every conceivable metric.

> **Comments:**
> **username_7**: I like this answer, because is completely true. For beginners I think this hybrids are the best option. I was thinking in Visual Studio Code, that actually opens really fast and has a lots of plugins easy to install. Using this, you can focus in programming and not in configuration.  
> **username_6**: @KennyBarrera VS Code is probably fine, I was thinking of VS itself which is, to say the least, heavyweight.  
> **username_8**: Especially "ditto" for emacs. It's really another language. Sublime ... no problem. Acts like an editor.  

---

### Answer by username_9 on 2017-08-28. Score: 12

Here are my thoughts on this.

# Editor and Terminal

This is most likely the **more lightweight solution**. Editor and terminal often don't consume much space (or, at least, come bundled with the operating system so it doesn't really matter) and start fast.

Using editor and terminal can demonstrate students that writing a program can be done without using a huge IDE including a lot of tools, as it is essentially **not more than writing down instructions** using a **normal text editor** and executing them.

An advantage, especially for beginners, could be that it **doesn't overexert the students** with too much information - in contrast to IDEs that come with syntax highlighting, code style checking, automatic error correction and code suggestion.

It's worth noting that there are multiple "levels" of editors: When choosing the editor, one could choose between a simple text editor without any programming-related features (not even syntax highlighting), more advanced editors that have syntax highlighting, or something like [IDLE](https://docs.python.org/3.6/library/idle.html), which is an IDE on the one hand, but at least in my opinion more like an advanced editor. This could help finding a compromise between a fully-featured IDE and a text editor.

# IDE

IDEs are most likely a more **heavyweight solution**. Normally, they consume a lot of disk space as well as memory and have a notable startup time.

They can **assist fixing errors** by highlighting them and providing possible solutions. This is definitely an advantage in day-to-day use, however, when it comes to teaching how to find errors, one could interpret this as a disadvantage, as it's possible that students start to rely only on their IDE when searching errors and wouldn't be able to find them without any help.

Furthermore, IDEs can help to **improve programming speed** with features like autocompletion, built-in refactoring tools etc.

A feature that could be nice to have for beginners is that IDEs normally have a **nice debugger** which could be used to motivate students to debug their code when they see an error. This is something the editor/terminal combination can't achieve - even if there are command line debugging tools, they are most likely not user-friendly enough.

What I believe is also worth noting (inspired by [Ben I.'s](https://cseducators.stackexchange.com/users/27/ben-i) [answer to a related question](https://cseducators.stackexchange.com/a/184/793), thank you) that IDEs come with **integration for professional developer tools** like version control systems or unit testing. I am not sure whether this is already needed in the first year of programming, but I can definitely come in handy later.

> **Comments:**
> **username_1**: A good answer,  I would add auto-correct should be considers harmful. Though spell check, and error highlighting are not. Also my text editor has revision control.  
> **username_10**: Do you count the "idle" IDE as a heavyweight solution ?  
> **username_9**: @MichelBillaud Good question - I think I don't. As far as I can remember, IDLE comes bundled with Python (so from the space point of view it's like the OS-builtin editor) and starts pretty fast, so it seems "lightweight" to me (at least, judging by my quite subjective criteria).  
> **username_11**: I don't think that "consume a lot of disk space and memory" is really worth the consideration these days. PyCharm right now needs less memory than some single chrome tabs and requires about 500MB of disk space - both negligible even for the weakest notebooks. There are lots of other arguments that should imo be more front and center than that.  
> **username_9**: @username_11 I think that this depends a little on the machine - on my laptop, PyCharm takes considerably more time until it's usable than the standard text editor. From my experience, I think this could be relevant for school PCs as I've seen that they are often not the latest and fastest models.  
> **username_11**: @Turing Startup time definitely. But my point is you only start it once and when it's running the amount of resources it needs is hardly worthy the consideration these days. If you spend several hours programming, whether the initial setup takes <1 second or 10 seconds is not that relevant.  
> **username_12**: Another advantage of an editor is the ability to just get something "on paper" without worrying about any syntax. In using an IDE (which I do, but also use editors), I am sometimes put off by all the "errors" that are a result of just typing thoughts and structure. "Yes, IDE I know it isn't syntactically correct, but I don't care. I'll deal with that later."  

---

### Answer by username_13 on 2017-08-28. Score: 11

Of course it depends on your overall goals. For me, however, the answer is clear: Use the most powerful IDE that I can find (Eclipse or NetBeans fit my def).

I started programming on primitive equipment (card punch) and came up through every level since. I don't romanticize the old way of work and I wouldn't go back. I wouldn't try to impose primitive tools on newcomers. But then, in CS1 my goal is to teach them how to program effectively. I think that is a hard enough job that I want to ease the path in every way possible - remove all obstacles to thinking about the problem and creating a solution.

In Eclipse, I can integrate testing. I don't need to type every character of the program. I can leave pretty-printing to the system. I can integrate useful program metrics. I can have compilation done automatically. I can search by structure, not just text. And on and on. Emacs is quite wonderful, but it has about 200 textual commands to learn. Life is short.

I wouldn't try to impose any less-than-the-most-powerful tool on a pro. I wouldn't on a novice either. However, if someone comes to me already a vim (say) expert, I'd let them use it, and might not even notice. But if they hand me unreadable code, I'll notice pretty quick.

But as I said at the top, it depends on your overall goal. For me, the overriding goal is to ease the process so that students can focus on the programming itself and the mind-expansion that comes from that. If a better tool comes along, I'll work to use that. Key punching was abominable. So was the teletype, ...

---

Pretty printing is good because it lets me see the structure of a program without first fighting to get it into shape. Not typing close brace lets me think about what I'm trying to create, not the requirements of the language itself. Writing a test for a nonexistent feature and then having the system enter the skeleton for that feature is just marvelous. No cut, switch, paste, or mis-spell and correct. It just works. It lets me get into a flow of creation that I can't do if I'm writing just text.

Nor can I find a language that I can't write in Eclipse, since it isn't really an IDE, but a workbench onto which you can plug nearly any tool. Like Emacs, it has a lot of headroom (and isn't unique in that, of course).

> **Comments:**
> **username_14**: Commercial IDEs are also an option since many provide free licenses to students, educators, and classrooms (e.g. [Jetbrains IDEs](https://www.jetbrains.com/products.html?fromMenu#type=ide)).  
> **username_15**: I too started with (hand) punched-cards, and while I wouldn't suggest going back to that, there is a potential danger that a _do-it-all-IDE_ can hide a lot of what's really happening from a new student, and produce _cut-and-paste-coders_ that don't _really_ understand what they're doing (and lead to some of the poorer questions on StackOverflow). On the flip side, systems, libraries and frameworks have got so complex that very few people _could_ every understand "everything", so a degree of "trust the black box" is necessary. Perhaps a term of no-frills _programming_ before switching to IDEs.  

---

### Answer by username_16 on 2017-08-29. Score: 10

The real question is this: do you want to teach your students what is actually going on, or teach them which magic buttons to press in an IDE?

Of course for professional programming work nobody would NOT use the most functional IDE they could find for the task they were doing. But if you throw a complete beginner into the deep end of a tool like MS Visual studio, they are unlikely to have any idea what is going on, and the only way they can create a working project without wasting a lot of time is be following a "magic recipe" provided for them. Personally I don't consider that to be a university-level learning experience.

Of course they shouldn't be forced to use a command line "for ever," but IMO they should certainly be required to use it until they understand the relationship between classes or modules with physical files (including any required naming conventions,) how to get the individual parts connected together into a complete application, etc.

Those are *transferrable* skills, as is the more basic one of being able to use a command line at all. The details of using a particular IDE are *not* transferrable, unless you understand what they actually DO. The command-line-level skills are also what you need to figure out for yourself why a "new improved" IDE isn't doing what you want when you first migrate to it!

Related to this, also start early teaching them how to use a version control system in a simple way from the command line - not to mention "make!"

Actually, using vi (or vim) or emacs plus command line commands can be an efficient way of working without an IDE, since the command line commands you need often are only one key-press away!

In a real working environment, there is nothing more confusing than sitting down at someone else's workstation where they have configured an IDE in a completely different way from your own - that's the time when just firing up "vi" in a command window can be the *quickest* to get "real work" done!

> **Comments:**
> **username_15**: As I comment on [username_13's answer](https://cseducators.stackexchange.com/a/3385/1372), I think there's a lot to be said for starting at the "nuts and bolts" level, at least for a while, to try to give students a solid grounding so they have a better understanding of what the _do-it-all-IDE_ is doing for them. In a similar way to when I did "O-level" maths, and one test-paper was calculator-free (slide-rules/log-tables allowed) to prove you understood the basic concepts involved.  
> **username_11**: At the same time, do you really want to bother first year students with things such classpaths (oh god), manually configuring gradle projects and whatnot? "So before we start programming, you'll now get a 4 hours introduction into technical details that are in the end irrelevant for programming but are required to get started" just doesn't sound like a great introduction. In the end even if there's no IDE, you'll still give them some basic structure that they won't understand so that they can get to the interesting parts.  
> **username_11**: And if you do that anyhow, using an IDE doesn't seem particularly problematic from the "magic" POV. It just depends whether it actually helps or distracts from the actual programming. I certainly would think that developing Python without IDE is a great deal easier than say Java.  

---

### Answer by username_17 on 2017-08-28. Score: 5

I like to ease people in. You have mentioned that this is for first year. So, yeah, easing in would really have a positive impact on the overall learning experience.

I would like to draw from my own experience between a GUI and command line. When I was introduced to version control, the whole thing was intimidating. I decided to go with the Github Desktop, and got an understanding of version control. Once I was okay with that, I switched to the git bash command line. Now, I use command line everywhere, and have been for years.

I have used this technique on many students, and the success rate has been higher. Also, most of these students (at least those who take software development seriously ) will migrate to the command line on their own when they are ready. That way, I leave the choice to them.


---

### Answer by username_1 on 2017-08-28. Score: 4

## For the editor

* You can use the same editor for every language.
* You can use the same editor for every system.
* You can use the same editor every year: I learnt emacs (and vi) in 1991, and still use them.
* They are much simpler, and pupils need to learn the editor/ide at same time as the language.
* IDEs can reinforce the separateness of your program: you program runs on an operating system and can interact with other programs. This can be diminished by using and IDE.

## For the IDE

If the IDE provides faster feedback, then it can aid leaning and productivity. It the 1960s the interactive tty was a massive improvement in both of there. For an IDE to improve on this, it needs to take it a step further. See work of Bret Victor for where this is hopefully going. However most current IDEs do not do anything useful. With a few exceptions.

* Effel Studio — can show different views of the code: Editing view, contract view, flat view, pictorial view. This is taking “the code is the documentation to its limit”.
* Visual Studio — has intelitype, though there is controversy as to whether this aids learning, or results in better code.
* Eclipse — Allows you to compile code, with out it breaking because of a compilation error in one bit.
* Most IDEs — have a run button, so run the code that you are looking at. (some editors also have this).
* IDEs often have better code navigation. Show where used.
* IDEs often have better re-factoring tools.

## Summary

Not all IDEs are the same. Not all editors are the same. You will have to look closely at your editor, IDE, to see if the IDE provides anything more, and does not make things too much more complex.

> **Comments:**
> **username_9**: In my opinion, using the same software on every system is not really a sole advantage of text editors as most IDEs also support multiple operating systems. Is it possible that I've misunderstood this formulation?  
> **username_18**: @username_9 I think it's a matter of degree rather than of absolutes.  Some IDEs eg Eclipse are widely available on many platforms; others eg Visual Studio are single platform.   Even then Eclipse isn't as widely available as emacs or vi; I suspect the same would be true for eclipse vs Sublimesque text editors as well; if not individually then as an entire product class.  

---

### Answer by username_19 on 2017-08-28. Score: 4

Most of the IDEs that have been mentioned are **more** confusing than just using a basic text editor and the command line. If I were you, my plan would be:

* Start students with a **very basic** IDE.
* Allow students to "graduate" to the command line.
* Then allow students to further "graduate" to more advanced IDEs, which are what most of the other answers are talking about.

With that in mind, you might consider using [Processing.py](http://py.processing.org/), which is a very basic IDE that allows you to write Python code that uses [Processing](http://processing.org) to create simple animated and interactive programs.

[Here](http://py.processing.org/tutorials/) are a bunch of Processing.py tutorials, and you might also check out:

* [Order to Teach Topics in an Intro Programming Class](https://cseducators.stackexchange.com/questions/2793/order-to-teach-topics-in-an-intro-programming-class/2798#2798)
* [Using Processing as an entry point in an Introductory Course](https://cseducators.stackexchange.com/questions/19/using-processing-as-an-entry-point-in-an-introductory-course/2920#2920)
* <https://cseducators.stackexchange.com/a/173/2068>

I would recommend starting with Processing.py for the first class, then "graduating" to using "pure Python" on the command line in the second course, and introducing more advanced IDEs towards the middle of that second course.


---

### Answer by username_4 on 2017-09-01. Score: 0

It may be easier to transition students who have gained proficiency in using a a command-line environment to switch to using an GUI IDE, than vice versa. If so, starting with an editor+terminal will allow more flexibility in your later curriculum design.


---

### Answer by username_5 on 2017-08-29. Score: 0

Go to local companies and talk to the developers. The command-line interface is still used a great deal owing to its programmability and extensibility. My beginning students learn about the command shell.

Also, Python has command-line arguments, which make programs you create in it far more versatile.

The vi editor and gedit provide very nice syntax coloring. They also don't "spoil" the user with auto-completes early in their learning.


---

