Monday, February 25, 2008

In praise of mandatory indentation for novice programmers

About four years ago, I created my own programming language for teaching. I'll probably write more about this language at some other time, but for now I want to focus on one feature of the language: the use of mandatory indentation. My experience with this aspect of the language has been so overwhelmingly positive that I will never again voluntarily use a language without mandatory indentation for teaching novice programmers.

Of course, sometimes the choice of language is not under my control. Even when it is, there are always many different factors that go into that choice. But no other single factor I've run across has greater significance. For example, programming language afficionados spend endless hours arguing about static vs dynamic typing, or functional vs object-oriented languages, or strict vs lazy evaluation, get the idea. Those differences can indeed be important, but more so for experienced programmers working on large projects than for novice programmers working on classroom projects. None of these differences individually comes close to the issue of indentation.

I say this with some pain, because I'm a programming languages guy myself. I've taken part in some of those arguments, and spent many hours contemplating the relative merits of many much deeper programming language properites. It hurts me to say that something so shallow as requiring a few extra spaces can have a bigger effect than, say, Hindley-Milner type inference. I wish it weren't so, but that is what my classroom experience tells me, loudly and unambiguously.

Why not mandatory indentation?

The vast majority of languages don't make indentation mandatory. Instead, they usually use explicit syntax to indicate block structure, such as { and }, or BEGIN and END. Yet, if you look at well-written programs in those languages, they are almost always indented sensibly. Furthermore, there's remarkably little disagreement as to what “sensible” indentation looks like. So why not make that sensible indentation mandatory? There are several reasons that are often put forth:

  • It's weird. Because the vast majority of languages don't use it, most programmers aren't used to the idea. Therefore, there's an initial sense of unease.
  • It messes up the scanner/parser. True, mandatory indentation is harder to deal with using traditional scanners and parsers based strictly on regular expressions and context-free grammars, respectively. But it's usually trivial to modify the scanner to keep track of indentation and issue an INDENT token when indentation increases, and one or more OUTDENT tokens when indentation decreases. The parser can then treat these tokens just like normal BEGIN/END keywords. In this approach the scanner is no longer based strictly on regular expressions, but most scanners aren't anyway (for example, when dealing with nested comments). Using the INDENT/OUTDENT tokens, the parser can still be based strictly on context-free grammars.
  • Don't try to take away my freedom! Programmers are a pretty libertarian bunch. Anytime somebody tries to impose rules that they follow 99% of the time anyway, they always focus on the 1% exceptions. For indentation, these exceptions often involve what to do with lines that are too long. So yeah, a language with mandatory indentation shoud deal gracefully with that issue. Or sometimes the exceptions involve code that is nested 20 levels deep. But these cases are almost always easy to rewrite into an equivalent but shallower structure. One place where I tend to deliberately break indentation rules is with temporary debugging output. I often leave such print statements unindented, so that they're easier to find when it's time to take them out. This is convenient, but I can certainly live without it.
  • I don't want people to be able to read my code! Maybe some people view obfuscated code as job security. As a different example, the former champion in the TopCoder programming contest, John Dethridge, was famous for never indenting. Why? Because in TopCoder, there is a “challenge” phase, where other competitors look at your code and try to find bugs. So there's an incentive to make your code hard for other competitors to understand. I remember teasing him about this once, and he said laughingly “Beware my left-justified fury!” I replied that I'd be more afraid if his fury was right justified.
  • It doesn't scale. As programs get bigger, both in lines of code and in number of programmers, you run into more mismatches in indentation. For example, you might want to move or copy a loop that was nested 5 levels deep to another location nested 3 levels deep. Or you might need to integrate code written by programmers that used different numbers of spaces per indentation level. Refactoring tools can certainly help here. But, you know, if you're the sort of programmer who would leave the indentation messed up when you moved that loop, just because your language didn't require you to fix it, then I probably don't want to work with you anyway.

What about novices?

Most of the objections above don't really apply to novices. Programming is new to them so it's all weird anyway. They have no idea what scanners and parsers are. As teachers, we already take away a lot of their freedoms anyway, and we certainly want them to care if somebody (namely us!) can read their code. And novices are usually not going to be writing large enough programs for the scaling issues to be a big problem.

Ok, but what are the benefits for novices?

  • They are already used to the idea of indentation. Both from writing outlines in English class and from nested bullet lists in the (almost) ubiquitous PowerPoint, novices already have experience with the idea of indicating grouping using indentation. This makes such languages much easier for novices to learn. In contrast, explicit markers such as curly braces or BEGIN/END keywords are something novices have much less experience with. However natural such markers might seem to us, they are not natural for novices, and are a constant source of mistakes. (Worse, a typical novice strategy for dealing with those mistakes is to randomly insert or delete braces until it compiles—a strategy Peter Lee used to call “programming by random perturbation”.)
  • Less is more. Or, put another way, smaller is better. To the novice, a fifteen-line program is less intimidating than a twenty-line program, a program that fits on one page is much easier to understand than a program that spans multiple pages. Those extra lines taken up by explict braces or BEGIN/END keywords really add up. Even if you use a style that puts a { at the end of the previous line, the } still usually goes on a line by itself. I shudder now everytime I look at a Java program and see a code fragment like
    Note that I am not advocating compressing everything into as few lines as possible (a la Perl Golf). Nor am I saying that all redundancy is bad. But in this case, the redundancy of explicit markers was hurting more than it was helping.
  • Mandatory indentation promotes good habits. I've taught plenty of novices in languages that did not require indentation. If the language doesn't require it, they won't do it, or at least not consistently. If they are using an IDE that indents for them, fine, but sometimes they need to write code in a primitive editor like Notepad, and then they just won't bother. Even if I require the final submission to be properly indented, all too often they will do all their development without indentation, and then indent the code just before turning it in (kind of like the typical novice approach to commenting). Of course, indenting after the fact means that they don't get any of the benefits from indenting their code, such as making debugging easier.

    On the other hand, if the language makes indentation mandatory, then the novice needs to keep their indentation up to date during the entire development cycle, so they will reap those benefits. Since I started using this language, I've also noticed improved indentation habits even when students switch to other languages without mandatory indentation. I can at least hope that this habit is permanent, although I have no evidence to back that up.

A surprise

I was shocked by how much the mandatory indentation seemed to help my students. I did not come into this expecting much of a change at all. I had experience with mandatory indentation in a couple of languages (most notably Haskell), and I had found it to be a pleasant way to code. Also, I had heard good things about people using Python in the classroom. However, I was by no means a convert at the time that I was designing my language.

I had two motivations for making indentation mandatory in the language. First, this language was designed to be the second language most of the students saw, and I wanted to expose them to a range of language ideas that they had not seen before. For example, their first language used static typing so I made my language use dynamic typing. Similarly, their first language did not make indentation mandatory, so I took the opposite route in my language. My second motivation was simply that I was annoyed. I was tired of students coming to me with code what was either completely unindented or, worse, randomly indented. I figured that making the compiler enforce indentation was the surest way to stop this.

Imagine my surprise when I started teaching this language and found the students picking it up faster than any language I had ever taught before. As fond as I am of the language, I'm certainly under no illusions that it's the ultimate teaching language. After carefully watching the kinds of mistakes the students were and were not making, I gradually realized that the mandatory indentation was the key to why they were doing better. This seemed to manifest itself to two ways, one obvious and one more subtle. The obvious way was that they were simply spending much less time fighting the syntax.

The more subtle way was that they appeared to be finding it easier to hold short code fragments in their head and figure out exactly what the fragment was doing. I conjecture that there may be some kind of seven-plus-or-minus-two phenomenon going on here, where adding extra lines to a code fragment in the form of explicit braces or BEGIN/END keywords pushes the code fragment above some size limit of what novices can hold in their heads. This wouldn't affect expert programmers as much, because they see beneath the braces to the chunks underneath, but novices live at the level of syntax.

Whatever the explanation, I'm now a convert to the power of mandatory indentation for novices. I've never taught Python, but I suspect those who have may have had similar experiences. If so, I'd love to hear from you.


Sean said...

Even in languages where this is not required, I still indent my code "properly".

So, when I started playing with Python, this wasn't an issue for me.

helcim said...

Actually, isn't indentation considered now a bad idea by the authors of Python themselves?

Florian said...


huh? nonsense. indentation is popular as ever.

Tac-Tics said...

As someone who has had to endure TA'ing Java for a number of years, I agree whole-heartedly. I can't count the number of times students came in with code indented so improperly I had to spend 15 minutes helping them clean it up before I got around to explaining the *real* problems with their code.

Maybe it's just the dumb students who stand out in my mind. Regardless, professors (and their graders) should really mark harshly for glaringly improper use of whitespace. Getting something to work is only half of the battle in writing good software.

The only real regrets I think anyone has when it comes to mandatory whitespace languages like Python is the issue caused by the damn TAB key and a handful of aesthetic and bikeshed topics. If there was a way to guarantee that TABs displayed as 4-characters, then I don't think there would be so much controversy over it, but since this is not the case, the language becomes sensitive to the IDE or editor you're using, and that annoys people.

James Thiele said...

expilo said...

Actually, isn't indentation considered now a bad idea by the authors of Python themselves?
No. The designer of Python, Guido Rossum, was asked once if he'd ever switch from mandatory indentation to braces he said "Not a chance."

Peter said...

I've taught intro to CS in both C++ and in Python. Python was at least an order of magnitude easier, and I'm convinced whitespace was a large part of that. You can see what the students were able to do after 8 weeks here:
Now try and imagine doing any of those projects in a C++ intro class. Or even Java.

Unknown said...

Immortalized as:
>>> from __future__ import braces
SyntaxError: not a chance (<pyshell#1>, line 1)

Unknown said...

Very interesting. At our university, for 1st year students doing C and C++, marks are awarded for using indentation in the code, which I think promotes a good programming style definitely. It's certainly helped me with novice mistakes.

Unknown said...

I love the idea of mandatory indentation, and I only teach new programmers with Python.

My objection to Python, actually, is that indentation can be a mix of tabs and spaces. It should be just tabs. One logical tab is then one logical level.

Tac-Tics said...

The problem with "just tabs" is a lot of editors use 2 spaces or 8 spaces instead of 4. Thus, you're tied into the editor.

The python style guide suggests using spaces over tabs. I follow that advice, but for a long time, I used all tabs. The choice isn't really important as long as its consistent.

Eric Holscher said...

Posted my response as a blog post here

I love your ideas though.

@peter: those projects are amazing.

matthias said...

Hi Chris --

it is fantastic to see that another PL researcher has finally gotten down to the nitty-gritty details of what matters in introductory courses.

There is a reason why TeachScheme! is pronounced "teach Scheme --- NOT" and why we designed a series of teaching languages similar to Scheme but simpler. There is a reason why we simplified DrScheme so that it is a truly, really simple IDE for novices. You don't learn to fly with a 747; you start with a little airplane. Check out our papers.

And by the way, you do save time with all these simplifications. If you do use the time to teach design recipes/strategies, students learn something that they can take along to all courses and the stuff that the Python/Oregon guy posted will look boring to you!

-- Matthias

Unknown said...

don't agree.

Syntax is just syntax, nothing more.
Programmer should concentrate on semantic and algorithms, pretty formated and readable code can be done by any ide.

Why should novice take too much attention on syntax? Will it be helpful in future? I don't think so.

Mandatory indentation is not a silver bullet, it's not helpful, it's not useful, it's just another "syntactic sugar". Imho.

Unknown said...

I prefer explicit delimiters because otherwise the line wrapping of code by various email programs, web mail, mailing list digesters, newsgroup readers, etc., often results in code that no longer works.

rgrig said...

Indentation is good. Good programmers ask compilers to report all
warnings from the beginning of a project. When you have to manage
hundreds of lines of code, and even more, it is foolish not to
use the help of a tool that is much better than you at nitty-gritty
details. Warnings are not errors, and you can hide them. Doing
so means that you'll never be able to avail of the compiler as
a detective: If you turn on warnings in the middle of the project
you are swamped with useless messages and that's just more hay on
top of your needle. So, let the compiler help you with warnings.
(Static checkers like Spec# can be seen as pushing further this
philosophy.) I do not like, however, to be forced! Simply put,
forcing people to do something is bound to be far less effective
than convincing them. (That's one of the important reasons why
democracy works better than dictatorship. Note that I don't claim
there is any link between politics and indentation---just an
overstretched analogy.)

Progress seems to be about leaving out one percent. Java is a
dumbed down version of C++.
Haskell is an even more dumbed down version of... something.
(Come on, no assignment? That must give me the right to say
"dumbed down".) Yet, the dumbed down versions seem to work
better, probably because the volume of our brains is limited.
(At least according to Dijkstra.) The best programmers in my
experience are those able to cover the last few one percents
that history left out, should the need arise. You mock assembly
programmers? Well, all good programmers I know are at least able
to read assembly. (For example, Michal Moskal, one of the guys
behind the functional language Nemerle, is quite eager to dive
in and look at MSIL. He is also very good at writing insanely
optimized C code.)

So, yes, indentation is good and explicit markers are one of those
features we'll drop. Personally, I'd prefer editors that show
the code in whatever way you prefer and version control systems
that understand code (not only text). In such a world a group
of statements would be a group of statements, not a group of characters
in-between some delimiters or with a certain indentation.

Now let me attend to some of your statements and a comment.

1. You claim that students are used to indentation from PowerPoint
but not to curly brackets. First, I must admit that I never before
thought of PowerPoint as a vehicle for teaching programming.
This looks like a horror movie poster in my mind. But let me get
over personal taste. Second, your statement just doesn't fly with
me. You mean that they are less used to parentheses from math?
Even so, don't they need to understand parentheses anyway as a
way of grouping other stuff in their program?

2. You say that students don't indent programs in Notepad. Well, me
neither. I also don't write anything longer than 10 lines in Notepad.
I've learned the hard way, by writing programs that I was unable
to read later. Somehow the lesson stuck. Whenever someone tells me
that I must do something because the alternative is worse, the
message goes thru me.

3. You say that relying on indenting makes scanning and parsing harder.
Tools are made to make our lives easier, not the other way around.
(In other words, I agree.)

4. You say that John Dethridge was obfuscating his code. Are you sure?
For example, tomek repeatedly said that writing ugly code makes
it very hard to debug under the tight time constraints and that
outweighs the benefits you'd have from obfuscating the code. Also,
I've seen John Dethridge asking Egor "What's with all those spaces?
It looks awful!" Are you sure it's not just that you can't imagine
someone finding such compact (and unindented) code readable?
People have different styles and tastes, and some look really crazy.

5. A comment gives a web-page with some really cool projects and
asks whether that is possible in C. Most probably not. But ask your
students this: "Are Python lists lists or arrays?" and count how
many "Huh?" answers you get. Somehow,
I'm much more impressed by a student that can explain how a
program works however deep I go with the questions rather than
by one that rapidly writes code that draws nice trees. I'm not
saying that these projects were bad. On the contrary, as I said,
they seem really cool. But this attitude "it's either Python or C"
is quite bad. Students should know both.

Finally, here is THE reason for using nicely indented programs with
no explicit delimiters: That is how I write pseudocode on paper.
Well, that's MY reason.

Oh, sorry, one more thing. I think that the most basic skill for
programmers is to write simple programs that WORK and hence that
should be taught first. Proper indenting sounds like an advanced
topic by comparison.

Will Duquette said...

I admit, I prefer explicit delimiters. (But then, I also prefer Tcl/Tk, which makes me nuts by most folks' standard anyway.)

But I remember many, many years ago, when I became a C programmer after having been mostly a Pascal programmer. Pascal was case-insensitive, and no matter how much I wanted to be consistent with the casing on my variable names, I never was. In C, of course, it simply wasn't an issue: if I didn't spell the name right, the code didn't compile. I much prefer the latter.

Michaelangel007 said...


For an _intro_ course, you want to teach good _habits_.

Once a person is familiar with the "rules", then they can start exploring when they do not apply in certain situations.

Tac-Tics said...

Dan, syntax does matter. It matters a lot. If it didn't, all code would be written with S-expressions.

The underlying concepts of CS are very important, and deciding between a bubblesort from a mergesort is indeed more important than deciding between tabs or spaces. But for first-year students, stick with what matters. Clean coding style is just as important as anything else.

If you write working, but unreadable code (and many students do exactly that), it makes your teacher's life miserable and it will make your coworkers miserable when they have to fix a bug in your code.

Arcane Sentiment said...

So, Chris, what is your teaching language like? What concepts are you trying to teach with it? Any other interesting features?

Unknown said...

Michael, Tac-Tics,

I agree that novices should know how to write readable good-formated code, but also they should to know to *why*.

You know, code formatting is very important aspect when you're working in team or when you're reading somebody's code(yeah, and thinking: "show me this idiot who wrote this unreadable garbage, I want to see his eyes"), but if an abstract newbie wants to work in team and understand another's code, [s]he *must* to know fundamental paradigms and algorithms. And it's more significant.

Have you ever thought about why SICP course is still used in MIT(yep, "unreadable" scheme + fundamentalism + math + paradigms + other "ugly stuff") or about why Don Knuth used abstract MIX language("unreadable" funny "assembler") in his cool books?

Imho, novice should, first of all, understand what is scopes, blocks, how interpreter/compiler works and only then(after [s]he knows what is AST, preprocessor, etc) eat all tasty sugar. In this case [s]he'll really know what the hell [s]he is doing and will know that indentation, parentheses, begin/end, etc just determine blocks. This is the key.

Good formated code is not a thing which should be learned in the university or enforced by some language, rather it's a thing that will be either automatically learned or after spending 10-60 minutes on reading few topics from any book about good-programming-style.

Unknown said...

Why I don't like mandatory indenting (as a professional programmer) is the problem of what the definition of a tab is. This is especially a problem when you have a space-tab sequence. Unix programs (generally) interpret a tab as "move to the next column which is a multiple of the tab-stop", while Windows programs (generally) interpret a tab as "move right the tab-stop number of columns. This is the same if you start in a tab-stop aligned column, but it's different if you're not. And this is not even dealing with changing the tab-stop.

Worse yet, this is an "invisible" error. You can't easily see that a space has snuck in somewhere, or that a tab has gotten replaced by spaces (or vice versa).

The only way I'd do this in production is by either outlawing tabs, or outlawing tabs anywhere except the beginning of the line (i.e. no non-tab character can come before a tab character), or some similar rule.

renoX said...

You forgot one source of trouble for meaningful indentation: the issues triggered by space and tab.

Have you tried to allow only one of those to see if it had an impact on the student learning abilities?

Chris Okasaki said...

As many people have noted, tabs can be a problem when using mandatory indentation. Of course, they're also a problem in languages that don't require indentation, but admittedly not as severe.

In my case, the language forbids tabs, and I provide modest editor support to make using spaces only easier.

Chris Okasaki said...

rgrig, thanks for your thoughtful response. You asked "Second, your statement just doesn't fly with me. You mean that they are less used to parentheses from math?"

Yes, that's exactly what I mean. They know at some intellectual level how parentheses work, but many of them haven't really internalized them, especially nested parentheses. (Don't get me started on the state of mathematics education in the US!)

Here's an example from a Discrete Math course I taught a few years ago. The students were working on a proof about factorials on the boards around the room. A subterm in the statement to be proved was "n-(k+1)". In their very first step, all but one or two of the students dropped the parentheses to get "n-k+1". As I went around the rooming, telling them that the two weren't the same, most of them didn't believe me until I forced them to plug actual numbers in.

David said...

I have read a lot of existing code while working at major software developers (Microsoft, Google, etc.) and when I see procedures with indenting 5 or 6 or more levels deep, I cringe. I have an especially vivid memory of debugging into a procedure in a shipping product where I was stepping through statements with over 80 spaces of indent in front of them - the procedure itself was 2200 lines long!

My point is: If you need such high levels of indenting you're already doing something wrong. You no longer have single-purpose functions, you no longer have code that is understandable, you certainly no longer have code you can test or get coverage on.

So I'm not really impressed by complaints that when copying code blocks from point A to point B you might have to adjust your indentation from 5 levels to 3 levels. What you really should be doing is creating smaller single-purpose functions that can be understood and tested, and then building on them.

(Plus, why isn't your text editor letting you indent/outdent code blocks as a chunk? Use better tools!)

As you mention: less is more. Languages with lighter syntax (e.g., Haskell, Python) are easier to code properly - and it is especially important that the syntax for code abstraction - that is, function definition - is light. And - that there is a light anonymous function syntax too - because coming up with a useful name for a function is frequently an additional cognitive load, contributing to the programmer's failure to break code into smaller chunks.

grant rettke said...

Chris great article.
Is it causation or correlation?
Does it apply only to students or professionals?

Chris Okasaki said...

Grant, I wish I knew. I certainly haven't done any formal experiment to try to distinguish between causation and correlation. Having said that, I do believe there's at least a little causation here.

As for students vs professionals, I've only been working with students. My experience is that they benefit a lot. My guess is that professionals would benefit also, but to a much smaller degree.

Jose Rey said...

I think that indentation is very easy to do for editors, it shouldn't be a "feature" of the language.

Novices shoud be right at home with an auto indenting editor, even in environments like scheme where highly nested syntax may be difficult to grok, environments like DrScheme help a lot to novices without limiting the experts.

There is another point in adding syntax to mark blocks: tools, you may take whatever source and reindent it to your taste with the propper tool, for example I program according to the syntax rules of my own editors (vim/emacs), I can take any code in the wild and reformat it in a matter of seconds with tools like indent(1) or perltidy.

Forcing syntax just gain a little bit of compactness, but takes a lot of flexibility, you mention something about adding debug statements, well I spend an awfull lot of time debugging and refactorizing code, things that are much easier to do without indentation restrictions, when everything is in place, you may allways reformat your code layout automatically.

Josef said...

Thanks for a very interesting post! It certainly comes as a surprise to me that your students seem to pick up indenting quickly. That made me wonder: What does the error messages look like when the students fail to indent properly? And I also wonder whether you think the quality of those error messages have anything to do with the pace the students pick proper indenting.

One of the reasons I ask is because of my experience with Haskell. Sometimes the error messages can be quite confusing of one mis-indents, even for a senior Haskell programmer.

rgrig said...

I realized that although I'm a bit against forcing indentation (my opinion being better summarized in the previous comment) I do it when teaching my wife how to program: She writes some code, gets stuck, asks me for help, and I tell her that I can't read code written like that, so I'll help her after she fixes the spacing. (And yes, I do think this is better than forcing her in the first place to indent code. Now she *experienced* one reason indentation is good: Because otherwise she won't get help from me and perhaps not even other people.)

Chris Okasaki said...


I agree with you in principle. I don't want something as simple as indentation to matter more than than a host of other properties that seem more important to me.

The catch is that I have four years of data that I can't explain any other way. It's certainly possible that I'm misinterpreting or misattributing my data, but I don't think I am. When my philosophy contradicts years of data, I have to accept, however reluctantly, that one or the other is probably wrong.

Anonymous said...

Wouldn't it be more inspiring for your students if they used Python instead of your language? The more advanced students could use their skills and create web pages with Django or using one of the (many) libraries that are out there.

Chris Okasaki said...

For some courses, I would be happy to use Python. For that particular course, however, Python would not have worked (for reasons having nothing to do with indentation).

Eric I. said...

Some people think of the eye as simply an input device. But the eye along with early visual processing is something of a computer or a pre-processor that massages visual input.

It is very good at doing certain things like grouping sub-elements into larger elements. You can get a sense of what is happening by looking at some of the perceptual "laws" in Gestalt psychology.

Indentation and appropriate use of white space are very effective at allowing you to easily group elements with less conscious processing.

When teaching people how to program, you have to be concerned with human limitations. You can't dump too much on the learners at once. You have to find a route through the material where you can add sufficiently digestible chunks.

I suspect that by using indentation rather than tokens to denote blocks of code can be very helpful in this. The eye will pick it up allowing the student to focus on the "real" (semantic) problem at hand.

And once block structures such as conditionals, loops, methods, etc. are well understood, picking up token-based block delimiters is much easier. No one is saying that students shouldn't learn that, but we're trying not to throw too much at the students too quickly.

And that's why I disagree with dan's disagreement.

Unknown said...

The language mentioned (I believe) is called Hudson and I might have been one of the recipients of it in 2003. I am currently working on my masters degree at UC San Diego and I still remember that class to this day for several reasons, although I do not have experience in large scale projects at a commercial level. First, I am incredibly particular about indentation now to the point that if it becomes too unwieldy, I find another way to do it. Therefore, my code is much easier to read and debug. Also, despite being behind in several areas compared to my colleages, that language helped me to understand programming languages in a way that almost none of the other masters students understand. My other friends getting CS degrees could (at the time) completely outdo me with C but I knew what was going on better than any of them and that still holds true for the most part. I really do think that forcing indentation as part of good coding practice really helped to focus on WHAT the language was teaching us and not HOW to do it. I fought with syntax very little in that class and it helped a great deal. Side not: Chris, thanks for a great class that outdid everyone I know at the undergrad level. I can't believe that I stumbled onto this but.

Chris Okasaki said...

Dmethodair, I'm glad to hear you're doing well. Thanks for the kind words!

Loup Vaillant said...

Did you think about going even further than mandatory indentation? I think about structured editors. With them, syntax errors are just impossible, making the whole thing even easier (hopefully).

Chris Okasaki said...

No, I never gave any thought to a structure editor. I had some experience with a structure editor many, many years ago, and it was awful. The problem was that you had to make your decisions in a particular order. For example, you couldn't say, "I know I want a loop here, but I don't know what kind of loop yet. I do know what the body should look like, so I'll fill that in first, and then come back and decide what kind of loop."

Of course, that was a long time ago, and structure editors may have improved since then.

Loup Vaillant said...

Stumbling upon this thread about the EastWest programming environment (with a structure editor), I saw this study about editing that may help building worthwhile structure editors.

The results are very interesting. Basically, the programmers follow a limited set of pattern when editing code. For instance, they tend to know what kind of loop they need beforehand. That suggest structure editors could be made even more usable than free-form text editing. They would have to follow slightly different rules than the current ones do, however (for instance in the case of infix expressions).

Unfortunately, the study is limited to Java by experienced programmers. Your case is almost the exact contrary. If you care about implementing some sort of key-logger to your student's programming environment, maybe you could collect more data to see if this study could be generalized or not. (Who knows, this could even be worth a paper :-)