22
$\begingroup$

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?

$\endgroup$
  • 5
    $\begingroup$ Welcome to Computer Science Educators. This is an interesting question. Hope to see you around here more. $\endgroup$ – ctrl-alt-delor Aug 28 '17 at 8:25
  • 1
    $\begingroup$ This seems like a duplicate of this question. Can you explain the difference to me? $\endgroup$ – thesecretmaster Aug 28 '17 at 12:01
  • 2
    $\begingroup$ @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. $\endgroup$ – Henrik Hillestad Løvold Aug 28 '17 at 12:21
  • 1
    $\begingroup$ 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. $\endgroup$ – Scheme Aug 28 '17 at 19:43
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$ – thesecretmaster Aug 29 '17 at 11:19
15
$\begingroup$

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 atom which works reasonably well out of the box with a healthy plug-in community for growth. It's scriptable in JavaScript and themeable 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: 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 arn better along just about every conceivable metric.

$\endgroup$
  • 1
    $\begingroup$ 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. $\endgroup$ – Kenny Barrera Aug 29 '17 at 21:29
  • $\begingroup$ @KennyBarrera VS Code is probably fine, I was thinking of VS itself which is, to say the least, heavyweight. $\endgroup$ – Jared Smith Mar 12 '18 at 20:30
  • 1
    $\begingroup$ Especially "ditto" for emacs. It's really another language. Sublime ... no problem. Acts like an editor. $\endgroup$ – 42- Feb 19 at 3:07
11
$\begingroup$

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.

$\endgroup$
  • 2
    $\begingroup$ 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. $\endgroup$ – ctrl-alt-delor Aug 28 '17 at 9:44
  • $\begingroup$ Do you count the "idle" IDE as a heavyweight solution ? $\endgroup$ – Michel Billaud Aug 28 '17 at 17:16
  • 2
    $\begingroup$ @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). $\endgroup$ – TuringTux Aug 28 '17 at 17:53
  • 2
    $\begingroup$ 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. $\endgroup$ – Voo Aug 28 '17 at 20:06
  • 1
    $\begingroup$ @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. $\endgroup$ – Voo Aug 29 '17 at 8:24
11
$\begingroup$

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

$\endgroup$
  • 1
    $\begingroup$ Commercial IDEs are also an option since many provide free licenses to students, educators, and classrooms (e.g. Jetbrains IDEs). $\endgroup$ – Thunderforge Aug 29 '17 at 1:15
  • 7
    $\begingroup$ 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. $\endgroup$ – TripeHound Aug 29 '17 at 6:49
9
$\begingroup$

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!

$\endgroup$
  • 1
    $\begingroup$ As I comment on Buffy's answer, 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. $\endgroup$ – TripeHound Aug 29 '17 at 7:00
  • $\begingroup$ 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. $\endgroup$ – Voo Aug 29 '17 at 16:22
  • $\begingroup$ 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. $\endgroup$ – Voo Aug 29 '17 at 16:23
5
$\begingroup$

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.

$\endgroup$
4
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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? $\endgroup$ – TuringTux Aug 28 '17 at 9:01
  • 2
    $\begingroup$ @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. $\endgroup$ – Dan Neely Aug 28 '17 at 17:39
3
$\begingroup$

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:

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.

$\endgroup$
0
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

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.

$\endgroup$

protected by thesecretmaster Aug 28 '17 at 12:54

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.