IDE vs Editor and terminal for CS1

Question

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?

Answer 1

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.

Answer 2

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, 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 answer to a related question, 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.

Answer 3

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).

Answer 4

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!

Answer 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 6

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.

Answer 7

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, which is a very basic IDE that allows you to write Python code that uses Processing to create simple animated and interactive programs.

Here are a bunch of Processing.py tutorials, and you might also check out:

• Order to Teach Topics in an Intro Programming Class
• Using Processing as an entry point in an Introductory Course
• 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 8

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.

Answer 9

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.