1. 13

This is another attempt at program editing that is not based on text.

  1.  

  2. 7

    Noticably absent from the discussion in the paper are things that “expert” programmers have to deal with: diffs, large codebases, and remote editing. This seems egregious given that one of their goals is to help both beginners and experts.

    I fear that the furor over syntax errors is much overblown. I can’t say that syntax has been a problem for me, as an “expert”, for many years.

    1. 5

      How much of a problem is syntax for beginners, for that matter? I guess it can be weird and frustrating that you need a semicolon here and not there, but is it so different from English? For 12 years or more, I had to write papers knowing you added a comma here and not there, and if you got it wrong that’s minus a point. At least the compiler is kind enough to provide feedback before turning in your assignment!

      I guess this could be an argument for a better English (good luck with that!), but the point is arbitrary syntax isn’t really insurmountable. It just feels weird when it’s made explicit instead of being given a dozen years to learn via osmosis.

      1. 5

        It isn a massive problem. I took a course on CS education, and the professor who taught it said that she structured one of her courses in two halves: the first had students do a series of programming assignments in Scratch, the second had them do the same assignments over again in Python. The first half gets them thinking computationally, and the second half puts them through the ringer of dealing with syntax. Students struggled just as much with the second half of the course as in the first.

        1. 1

          I guess the second half will be able to understand duff devices faster, if that really matters… ^_^

          1. 2

            To be clear, it was the semester that was split in half, not the student body. Every student did every assignment in both languages.

          2. 1

            I have seen people struggle just as much with the exact same problems (after not too long) even without any changes, and not only in context of programming. So it may be not about the syntax, but about not having built any reusable understanding yet.

            1. 1

              Dumb typo that I can no longer edit: the first sentence should say “It is a massive problem.”

            2. 4

              Speaking from anecdotal evidence, and also as a member of the research team who wrote this paper (though I’m not an author on this one) - syntax causes enough of a problem for beginners that people have looked for ways to mitigate those problems. (As much as people sometimes like to think academics invent the very problems they then set out to solve, and as much as that may even be somewhat true in some cases, this particular issue keeps cropping up in CS Ed research precisely because it’s been an ongoing problem).

              I’ve personally taught classes where students struggled with the placement of semicolons and issues such as matching brackets. Frame-based editing as presented in the paper isn’t the only solution to this kind of problem, of course, but so far it looks to be promising. (Time well tell if it has an actual impact in CS Ed generally speaking, of course; quite often these things don’t leave the “research” phase, for whatever reason).

              If we can allow students who struggle with syntax to make more progress, it improves their motivation. It also, generally speaking, makes learning easier by reducing cognitive load - you don’t need to worry so much both about getting the syntax right and getting the semantics right.

              I completely agree that making syntax instruction more explicit could well be another approach that reduces the syntax problem. The main drawback of that approach alone is that focussing just on syntax means there is a phase where the students aren’t actually able to write a complete program - they just know how to formally identify parts of the syntax - and this affects motivation; similar to teaching English by rote-learning of the grammar rules versus practical application (writing stories etc).

              1. 3

                I will admit that my phrasing sounds very harsh. I actually think this work is interesting and probably would help with programming pedagogy (in fact, I bet I could get my wife to try it out!). But I really wish these kinds of papers would stop claiming it could help “expert” programmers.

                Us experts live and work in systems where visual editing of the kind proposed just isn’t going to work. We search and index everything in plain text. There are huge codebases that cannot be converted to something like this. And frankly, it’s not going to compete at an efficiency level in existing huge systems even if you could convert them.

                Therein lies the rub: block/frame/structural editing is not of much use in systems not built around them. And what we have – which is a lot – is not built around them. (This does suggest that future research should be looking at bridging the interface gap.)

                Does that mean this kind of stuff is junk? No. I don’t think so. But I don’t see acknowledgement of this situation in stuff I read. That’s what rubs me the wrong way.

                1. 2

                  Fair enough. The paper is quick to point out the advantages (for “experts”) and doesn’t consider the disadvantages, which may be considerable, or at least doesn’t explore the other problems that need to be solved before a “frame-based” editing paradigm could feasibly replace a text-based one. Part of that is just because it’s not the main focus of the paper - we are CS Education researchers (though those that know me will know I have many and varied CS interests outside that particular sub-field) - and I think if you read it carefully you’ll see that it’s not actually claiming that an instant leap to frame-based editing is viable - but it’s a valid point that this paper should probably have included included at least some discussion of the other problems that would arise after making such a transition, considering it happily touts the potential benefits.

                2. 1

                  Thanks for perspective.

                3. 3

                  How much of a problem is syntax for beginners, for that matter?

                  If you believe CHI conferences, it’s a huge problem. The paper goes on at great length about how many syntax issues frame editing solves, citing the studies where it is a problem (of which there many). I’ve yet to dig into them, but really, who is in these sample groups? I wonder.

                  1. 3

                    (Apologies in advance for not actually reading all the research. So much easier to do armchair critiquing.)

                    Is there an assumption that everybody needs to learn programming in some abbreviated time frame, like two weeks? Like if I needed to learn Japanese in two weeks and found it frustrating, does that mean Japanese needs to change to be easier? After all, everybody should visit Japan and Japan should want everybody to visit (just like we want everybody to program, right) so it’s time to make some changes.

                    Like a great many people who have successfully learned programming, I don’t recall having trouble with syntax. But I wanted to learn to program. I can imagine the idiosyncrasies of computer languages to be quite frustrating if one is forced to learn programming. And by forced, I think we can include “I want to learn programming because everybody says I need to learn it.”

                    The little bits of research I’m familiar with are often motivated by the idea that in the future everybody will need to know programming. Therefore we must teach it. But are we pushing on a string? If people really needed to know programming, I doubt we’d be able to stop them from learning.

                    ECOMMENT2LONG.

                    1. 5

                      As an addendum, it seems the same “workforce readiness” experts saying stuff like “managers expect 67% of new jobs in 2025 to require some degree of programming skill” are the same as the people 30 years ago saying 67% of office jobs require “computer fluency” which was defined as knowing the keystrokes to do a mail merge in WordPerfect. And thus we had classes teaching us how to do mail merge, which were as boring and mindless as one might imagine. And here we are today, and who the fuck still does mail merge? Not 67% of the people in any office I’ve ever worked in.

                      1. 5

                        If people really needed to know programming, I doubt we’d be able to stop them from learning.

                        People need to know programming for the same reason people need to know arithmetic or how laws get made: because other people already know those things, and many of those other people are quite happy to use that information to exploit people who don’t know those things. Consider how much of an advantage payday loan sharks have over people who haven’t internalised the mechanics of compound interest, or how much of an advantage organisations with professional lobbyists have over other organisations, and compare that to how much of an advantage Google and Facebook have over people who don’t understand data-mining and automated data processing in general.

                        People really need to know programming, but it’s the kind of need that’s most obvious in retrospect, when it’s too late to do anything about.

                        1. 3

                          hmm. i’d argue two points.

                          1. there are a great many programmers who know all about semicolons, but don’t seem to know about the perils of google and facebook. presumably including all the semicolon pushers at google and facebook. so programming doesn’t seem sufficient to ward off that threat.

                          2. I know lots of people who don’t program but nevertheless won’t touch facebook. so programming doesn’t seem necessary either.

                          The point about compound interest is an interesting one, but despite many years of math education, we never really focused on how not to get cheated. Much like I know all about Bernoulli’s principle and the ideal gas law, but none of that knowledge does me much good in deciding whether the auto mechanic is telling me the truth or not.

                          If you wanted to demonstrate to somebody that facebook is dangerous, how much big data mongotensorflowgraph are you going to make them do? Because you can spend months on filesystems and network protocols and all sorts of stuff without touching any of that. If our goal really is to make people aware of the perils of facebook, starting with introductory programming seems like a really long way to get there.

                          1. 1

                            I think knowing those perils is not due to technical debt, but rather coming with the culture acquired along the way.

                            egg: Moving from remote access to computers, to personnal computer, to personnal computers consuming online services that user do not own anymore (including smartphones).

                            But those without any knowledge of the internals of these services still react to the absence of control over personnal data.

                        2. 4

                          I have a slightly unconventional way to disagree with you on this.

                          The goal of learning programming shouldn’t be to get a job programming, just like the goal of learning reading and arithmetic isn’t getting a job reading and doing arithmetic. It’s just table stakes for participating in society and being a useful citizen.

                          With that goal in mind, saying, “we’re able to teach all who want to learn” is just not good enough. We need to teach people who don’t know they need to learn, long before they can judge the question for themselves. We need to brainwash kids into learning to program the way we brainwash them into learning to read.

                          And for that level of penetration, yes syntax is absolutely a problem. The issue is not that kids need to learn all of programming in the first two weeks. The issue is that they need to make enough progress in the first two weeks to feel encouraged to continue. Too many people give up way too early today.

                          Today society dodders along with a miniscule percentage of people knowing to program, who then become a priestly over-class. If our goal is merely to maintain that status quo, yes you’re right, the great filter of syntax is irrelevant. But we should be aiming higher.


                          My qualifications: I’ve been teaching programming for over 2 years on the side. I’m up to 4 students at this point, and I’ve taught three times that number in this time. I’ve consciously tried to teach a diverse variety of students. One of my current students is over 50, for example. The above link from 2 years ago presents some early experiences in the benefits of eliminating syntax from my teaching. I should do a follow-up at some point, but bottomline: the syntax section has remained unrefuted since then, and I feel a lot more confident holding that opinion.

                          1. 4

                            I think I disagree that we are, or soon will be, at a point where knowing C or rust or whatever turns one into a techno priest overlord. Do we actually want a society where programming ability is required to participate? That sounds terrible.

                            But given that premise, yes, I can see the argument that learning should be transparent and effortless.

                            1. 1

                              Thanks for highlighting the crux of our difference.

                              Minor quibble: I want to distinguish between over-class and overlord. I’m not claiming programmers have direct power over non-programmers (by their own individual agency), but that they get the bulk of the rewards in society, and exert indirect power by their technological choices (without necessarily having individual agency over these choices).

                            2. 2

                              The issue is not that kids need to learn all of programming in the first two weeks. The issue is that they need to make enough progress in the first two weeks to feel encouraged to continue.

                              For me personally, the syntax part is exactly what provided that motivation! I took something like a 3-week after-school programming course when I was fairly young, which was not long enough to learn to do anything non-trivial, but was long enough that I felt some sense of accomplishment having learned to “speak” an esoteric formal language in a way that the computer would accept. I didn’t have any concept of what I’d want to program a computer to do anyway, so for me the motivating part was simply being able to master the syntax of how to tell a computer to perform some trivial arbitrary task, like drawing a simple spiral.

                              Two caveats: 1) I became a computer scientist later, so am probably not a representative random person (although the cause/effect here isn’t obvious), and 2) the language we used was Logo, which does have syntax, but lets you get started with a fairly small amount, and provides satisfying visual results when you get it right.

                              1. 2

                                I’d be interested in your take on my Mu link above. Mu was conceived to make functions concrete the way that Logo succeeded in making individual instructions concrete.

                                1. 2

                                  There are some interesting bits here. One thing that immediately stands out to me (though apologies if you already know this) is that the next-ingredient syntax in place of formal function parameters is how Perl traditionally does things. You don’t declare formal parameters on a subroutine, you just use shift to get the next one (behind the scenes this is because parameters are passed in a magic implicit array, and shift with no arguments pulls an argument off that implicit array, but someone writing a subroutine doesn’t need to know that).

                                  For me personally, I find keyword parameters a clearer way of matching up the caller and callee sites than positional parameters of any type, but I haven’t thought it through deeply.

                              2. 1

                                The issue is not that kids need to learn all of programming in the first two weeks. The issue is that they need to make enough progress in the first two weeks to feel encouraged to continue.

                                This exactly. Well said.

                              3. 1

                                That, and where can the average person apply programming? It’s not like an iPad has a scripting environment on tap and your silos-of-data apps eagerly exposing APIs for them.

                            3. 1

                              How much of a problem is syntax for beginners, for that matter?

                              I can’t speak for other languages, but I’ve watched some beginners learn C. I’ve also read some of the tutorials they read. One thing I’ve noticed is that syntax as such is rarely discussed, and the focus is on semantics; what they learn of syntax comes through examples, and these aren’t very thorough. At worst, no names for syntactic structures (statement, expression, block, declarator, etc.) are given. At best, some of these are mentioned by name, but the student is still left to his own devices to infer the exact form from code snippets. And they draw wrong conclusions.

                              And so we have beginners who get very confused about where to place a semicolon, or where (and how) to use the comma. You see the comma in parameter lists and declarations of multiple variables. But in other contexts it becomes the comma operator, which is something entirely different. You see semicolons after struct definitions that do not define variables, but none after function bodies or other blocks. In for loops, you may see both commas and semicolons… Even the ampersand and asterisk often end up being confusing because their syntactic role in different contexts isn’t explicitly spelled out. I think this is one of the reason many people seem to think pointers are difficult, and so they just end up inserting asterisks or ampersands until the compiler acceps the code.

                              With that type of teaching/learning we also have a large number of fairly experienced C programmers who do not understand the declarator syntax, and cannot read and write pointers to arrays or function pointers…

                              Of course none if it is hard, but there’s plenty of rules the student may have to figure out and memorize.

                              1. 1

                                How much of a problem is syntax for beginners, for that matter?

                                I would say, “it’s a hurdle”. I mean, obviously, it must be! It’s something you have to learn. It’s something many people struggle with. But I don’t think it’s a large hurdle. Our brains have a rather large portion of their mass dedicated to mastering syntax- we all master syntax of at least one language. Programming languages are simpler than natural languages, more consistent than natural languages- but also far more punishing in terms of errors.

                                Humans are good at working with syntax. I’d argue that our parsers are bad at dealing with errors, and by that I mean- they express errors in syntax badly in many cases.