Hands up who likes PHP? The role of popular programming languages in Computing Education

June 8, 2014 at 7:30 am 20 comments

I was at the NSF CS10K Evaluators meeting earlier this summer, and we got to talk about important research questions. Someone suggested the issue of learning progressions. How do students move from Scratch or Alice or Blockly to Java or C++? One of the evaluators, whose background is entirely in education and evaluation, asked, “Professional programmers don’t use Scratch and Alice?” We explained what professional programmers really do. “Then why are we teaching Scratch and Alice, especially if we don’t know how the transfer works?!?”

The tension between what languages are “useful” (read: “we use them today in industry”) and what languages are helpful for learning has always existed in CS Ed. I’ve recommended the blog below to several people this summer, including reading  the comments from the developers who push back — “Yeah, stop with Alice and teach real languages!”  I agree with the post’s author, but I see that, even in the CS10K project, the notion that we should teach what’s vocationally useful is strong.

At the NSF CS10K Evaluators meeting, I got to wondering about a different question. Most of our evaluators come from science and math education projects, where you teach the way the world is.  If you have trouble teaching students that F=ma, you better just find a new way to teach it. I told the evaluators that I hope their results inform the design of future programming languages. Computer science is a science of the artificial, I explained. If you find that mutable variables are hard to understand, we can provide programming languages without them. If the syntax of curly braces on blocks is too subtle for novices to parse (as I predict from past research findings), we can fix that, too. I got confused looks. The idea that the content and the medium could be changed is not something familiar to this audience. We have to figure out how to close that loop from the evaluators to the designers, because it’s too important an opportunity to base our language design for novices on empirical results.

It is a school’s job to churn out students who will be able to walk into a job in industry on day one and work in whatever language/paradigm is flavour du jour.
WRONG! We’re here to teach children the core concepts of Computer Science. Working on that basis to produce someone with employable skills is your job. Do you expect Chemistry students to walk out of school ready to begin work in a lab? Should we stop using Scratch as a teaching language because nobody programs with it in industry? Of course not, so please stop recommending that we should be teaching using Scala/JSON/whatever is currently flavour of the month.

via Hands up who likes PHP? | Code? Boom..

Entry filed under: Uncategorized. Tags: , , .

Engaging Women with Context in Hard Science: A Visit to SpaceX A flawed case against teaching: Scaffolding, direct instruction, and learner-centered classrooms

20 Comments Add your own

  • 1. shriramkrishnamurthi  |  June 8, 2014 at 8:15 am

    1. This is why How to Design Programs is built on a progression of languages, that let you make the leap from one stage to the next in a guided way rather than throwing you to the wolves at some point.

    2. However, the basic question also reflects a false dichotomy. Obviously people in industry don’t program in Scratch or Alice. But that is not an argument for _starting_ their education in Java or C#.

    If anything, the history of computing has shown that pretty much every seven years the dominant language changes. Given that it takes 3-4 years for academia to even start recognizing that a trend has begun (compounded by the misdirection administered by “education” representatives of certain major companies), it’s almost _guaranteed_ that the “hot” language the student learns as a first-year is becoming yesterday’s news as that student graduates four years later.

    Instead, you want to start high on pedagogy and low on industrial practice, and slowly wind down the former as you wind down the latter. We wrote about this in the “Structure” part of our 2004 paper, “The Structure and Interpretation of the Computer Science Curriculum” (http://cs.brown.edu/~sk/Publications/Papers/Published/fffk-htdp-vs-sicp-journal/).

    People who advocate for throwing students into full-blown languages either haven’t spent any time studying their user interfaces, or believe computer science is a discipline best learned through medieval methods.

    Reply
    • 2. Mark Guzdial  |  June 8, 2014 at 8:41 am

      I suspect that both of your hypotheses in your last paragraph are true. Have you looked at the prototype free response questions for the CS Principles AP exam? The pseudocode language looks a lot more like JavaScript or Processing to me than Scratch or Alice or Racket.

      Reply
      • 3. shriramkrishnamurthi  |  June 8, 2014 at 9:08 am

        «extreme nerd pedantry alert» It is also the only language I know that lets you use “ (open double quote), ” (close double quote), and ” (unslanted double quote), and even lets you use “ (open double quote) in a _closing_ position. That is either a very permissive grammar or some serious parsing mojo brought to bear.

        That, or they’re (a) writing code in a word processor and (b) not proof-reading it. I guess they really were *intent* on mimicking a newbie! «/extreme nerd pedantry alert»

        It looks like parsing double-quotes apart, it’d take about a day to support Sparkle (with its native syntax) in DrRacket…

        Reply
  • 4. Chris Thompson  |  June 8, 2014 at 9:17 am

    What does the research show that students are learning using tools like Scratch & Alice? Is there any research that shows starting with theses sorts of tools students are more likely to stay interested in CS and persist in learning more difficult topics?

    As computers become more powerful will there ever be a time when drag & drop tools are sufficient for certain classes of programs such as games? Are game designers using tools like Unity programmers?

    Interested in what this community thinks.

    Reply
    • 5. Mark Guzdial  |  June 8, 2014 at 7:26 pm

      Chris, I’ve answered questions like these in a semester length graduate course. I’ll try to give you brief answers.

      • Students learn a lot in Alice and Scratch. We know that they learn about sequencing, state, and iteration. There’s some great work in Israel in how students in Scratch learn about parallelism. There’s evidence that work in Alice better prepares students for CS1 in Java.
      • Yes, with a differential impact for women and under-represented minorities. White male students might go to CS in undergrad without a high school experience. Most women and URM students met CS in high school.
      • Maybe, but Petre and Green’s work in the 80’s on graphical languages suggest that textual languages do better for most people today, even those especially well prepared to use graphical languages (Tom Moher’s work).
      • Yes, game designers use Unity. Not clear what the question is.
      Reply
  • 6. Greg wilson  |  June 8, 2014 at 11:36 am

    Andreas Stefik and colleagues have been designing a new language (Quorum) based on feedback from usability experiments: every feature is user-tested *before* being added to the language. The results are encouraging — see http://neverworkintheory.org/2014/01/29/stefik-siebert-syntax.html for a bit of history — but the indifference shown by the programming language design community is not.

    Reply
    • 7. shriramkrishnamurthi  |  June 8, 2014 at 11:38 am

      What exactly does “indifference shown by the programming language design community” mean? What would you have liked to see that is different?

      Reply
  • 8. Austin Bart  |  June 8, 2014 at 11:53 am

    Pedagogy and Technology are both very fluent, but how flexible is content really? Yes, we can decide the ORDER of what we’ll teach, but at some point students should encounter the concept of both immutable and mutable variables. Yeah, you can get pretty far with immutable variables – learning Racket was a really fascinating experience and once I understood how I could reason about my program without reference to nasty global mutation, it was great. But sometimes even in Racket I need to define a mutable variable – if not for clarity, then for speed/memory/etc. If it doesn’t happen in the first programming course, then it’ll have to happen in the second, or third, or somewhere. I mean, unless the fundamental architecture of computers is about to change… I would think a good Computer Scientist should know both concepts before they graduate.

    We can decide that “mutable variables aren’t something a high school student needs to know”, and that’s fine. But is it a Content decision (“mutable variables aren’t something we deal with in CS”) or a Pedagogical Decision (“we have a finite amount of time to teach concepts, and mutable variables are less important than being able to write a correct program”)? Same thing if we’re using that knowledge to affect programming languages (our Technology).

    The intricacies of magnetism is something that might not be taught in high school physics, but it’s definitely a concept in physics. So just because you can provide a measuring tool to HS physics students that hides the confusing aspects of magnetism, doesn’t mean that a physicist no longer needs to learn that concept some day. There’s almost always the two options of “find a better way to teach it” or “don’t teach it until they have a better foundation to build on it”, except when you get to concepts like “f=ma” or “programs are a series of instructions” that are just too fundamental to build on.

    Still, the point is well taken – programming languages are mostly Technology, not Content! I despise Eclipse as a learning environment because it goes against most principles of Engineering for Learning.

    Reply
    • 9. Mark Guzdial  |  June 8, 2014 at 12:58 pm

      Austin, is it a goal for all high school students to become good computer scientists?

      Reply
      • 10. Austin Bart  |  June 8, 2014 at 5:58 pm

        Definitely not! My point wasn’t that high school Computer Science should prepare everyone for a career in CS, anymore than high school Physics should prepare you for a career in Physics.

        > The idea that the content and the medium could be changed is not something familiar to this audience.

        My thought here, and it might be more of a semantics thing (trying to stay within the TPCK framework), is that I was confused by how we can *change* Content. We might decide that “data mutability” is not a concept that students need to understand for a high-school level (regardless of whether they go forward or not), but that’s a question of ordering. They still need the concept of “data”, which comes before mutability and I would think is universally agreed is necessary to understand before leaving a Computer Science course. It’s a bit more obvious sometimes in Physics what the ordering is – students need to understand “momentum” before they understand the effect of “friction”. If you want to give your students a measuring instrument that’s so imprecise that they don’t NEED to measure the impact of friction on their calculations in momentum, then you’ve avoided some of the (deemed unnecessary for now) Content through Technology. If we decide to hide the concept “data mutability” with the design of our programming language, we’ve affected our Technology, not our Content.

        Our field is young enough that we don’t have the order of all the Content nailed down (although some concepts are much more solid than others), but I wouldn’t think other majors would find that confusing – but maybe they do, because things are usually more stable in other fields?

        Reply
    • 11. shriramkrishnamurthi  |  June 8, 2014 at 1:10 pm

      I don’t entirely agree with the conclusion. Along Sapir-Whorfian lines, languages do impact learning, and hence are very much a form of content. Put differently, the dichotomy between Technology and Content is not really accurate because each bleeds into the other. You mention Eclipse, which is a good example: the way a student thinks about even what a “program” is is very different in Eclipse than, say, DrRacket.

      For the past two days I’ve been getting email from a brilliant friend of mine who knows just enough CS to be dangerous (-:. His son is learning to program from Khan Academy, and the curriculum is in JavaScript. They’re trying to do something extremely simple. Quoting (and sanitizing):

      Initialize stuff
      Show stuff
      Wait for mouseclick
      do while (!quit) {
      Show more stuff
      Listen for keypress
      check keypress
      feedback
      }
      Show even more stuff
      Finish

      Trivial, right? Not in JavaScript, not at all. (And even if you think you have it nailed, depending on what computation you do in each handler, there’s even more subtlety to learn: hello, continuations.)

      So is JavaScript’s programming model Technology or Content?

      Reply
      • 12. Austin Bart  |  June 8, 2014 at 6:20 pm

        Well, the trick here is that I’m trying to stay within the TCPK framework (http://www.tpack.org/), which is not a dichotomy. The TCPK framework specifies 7 kinds of knowledge: Pedagogical, Technological, Content, Pedagogical/Technological, P/C, T/C, P/T/C. These are different lenses that let you talk about identifying what students are learning, but lines often get blurred. It’s not a partition or even a spectrum, there’s multiple membership.

        For instance, say my Content is “Understand a main loop” such as the one you specify. From the P/T sides of things, I may not want to use JavaScript because there isn’t much scaffolding in place – I have to explicitly tell the rendering engine everything to do, which means that the simplest program suddenly requires a lengthy conversation about too many things. I’d much sooner use Racket, because I can reduce the program to two or three lines and get immediate effects, and slowly add in new effects as we explore new ideas.

        But what if the Content is “Understand how to do a main loop in a client-side web language without external libraries”. JavaScript’s model is now what I have to teach, even if I have less Technological scaffolding to bring to bear. Still, a heck of a lot better than if I was teaching how to to do it in assembly – JavaScript’s Technology gives me a lot of scaffolding compared to that. And there is value in the Content there, to now be able to make a web-based interactive application (although I haven’t played with the Bootstrap racket->Javascript compiler in a long time, maybe that’s better now).

        I see a lot of blurring between our Technology and our Content. JavaScript’s programming model is Content in one conversation, and Technology in another. From the design point of view, it’s absolutely critical that we know in advance what our Content is and then decide on what Technology can do to support us.

        Reply
        • 13. Mark Guzdial  |  June 8, 2014 at 7:22 pm

          Our goal is to provide students with Computing. We don’t have to follow a JavaScript model, nor even a von Neumann model. I’m not willing to accept that Java or JavaScript language designers get to define the learning objectives. The goal is not to learn JavaScript or how you have to use data to use JavaScript.

          Reply
          • 14. Austin Bart  |  June 8, 2014 at 10:20 pm

            I’m not particularly tied to any particular models or languages, I just wanted to frame the conversation within a learning theory that might be useful for discussing these different concerns with educational experts outside of the domain. TCPK gives a way to separate the scaffolding from the content from the strategies of teaching. Within that framework, it’s relatively easy to plug in the concrete information you need for the scenarios that make the most sense.

            In the bigger conversation, I believe I understand and agree with what you mean though, about the value in letting pedagogical needs drive the development of the technology. That was the philosophy of Pascal, if I recall correctly: Dr. Wirth wanted a language with an extremely strong structure, and set out to create a language with just such a characteristic. It’s interesting to see languages where the language and feature decisions are driven in such a way; Pyret jumps into my head as a really interesting case. In this context, it’s clear to me that we need to make our technologies in service of our learning objectives.

            Reply
            • 15. Mark Guzdial  |  June 9, 2014 at 7:41 am

              The question you raised earlier is one we don’t have an answer to yet, Austin — what do we have to cover in computing. What’s at the bottom? What has to be learned to learn computing? And is there only one bottom? Sure, all Turing machines are equivalent, but that’s an abstraction over a concrete definition.

              The key point for me is that these aren’t language wars. Rather, I’m saying that we don’t have to choose among any option — we can make our own. That’s fundamentally different from science and mathematics. I don’t think TPCK covers it because it’s still about teachers learning technology. We can define the technology. We can define what’s to be learned.

              We are talking about abstraction, problem decomposition, and other ideas of computing, Josh. How they are framed and represented in the language is key to how they are learned.

              Reply
          • 16. Josh Paley  |  June 9, 2014 at 4:33 am

            “Our goal is to provide students with Computing.”

            Precisely. Which is why when a discussion about CS education degenerates to a discussion about languages instead of abstraction, problem decomposition, etc., we end up conflating the discipline with vehicles for teaching/learning the discipline.

            Reply
  • 17. gflint  |  June 9, 2014 at 11:38 am

    I have got to weigh in on this conversation. I have been teaching programming for about 30 years. I have no formal CS training, I have no formal CS teacher education (in my neck of the woods there is none, I am a converted math teacher). Everything I know is from classroom experience and, since the internet came around, from blogs like this. From that 30 years I have made some observations.

    1. Every kid in high school needs some CS. But this is where the definition of CS can get fuzzy. I count writing an If statement in Excel and finding the IP address of a computer as CS.

    2. Kids do not need programming to go on to a successful life/career.

    3. Of the kids that take programming most will be there only for one semester.

    4. How many kids hang around for a second semester all depends on how the first semester went. With Scratch/Alice/Small Basic/other fairly fun languages you will get a good percentage. With VB, Python, Java, etc you will be lucky to get 1%.

    5. Kids want to do the fun stuff with programming. They already have math to bore them stiff.

    6. Most kids think programming is about as exciting as US History or Algebra II. US History and Algebra II are not electives.

    7. Programming is hard work and the kids know it.

    8. For the very few that enjoy it, the language is totally irrelevant, they will learn it because the learning is the fun part.

    9. If we want more average, main stream kids taking programming and CS we had better be showing them some fun stuff up front. Scratch and Alice are fun. Java and Python not so much.

    10. No matter how high on the importance scale we CS educators think CS/programming is for the future it is an elective. Electives that are boring attract very few kids. Classes with few kids disappear from the curriculum no matter how important they are to the future of the US.

    As a programmer I do not like Scratch or Alice. As a programming teacher I love Scratch and Alice. Languages like these get kids in the seats and get them started on the concepts of CS/programming. From there I hope to hook some of them so we can go on to some more “real” programming with “real” languages.

    Josh has it right. Languages are irrelevant, except when trying to get kids in those seats.

    Reply
    • 18. Mark Guzdial  |  June 10, 2014 at 11:00 am

      Thanks for the list, Garth. I think we can budge #7, which I hope can change #6.

      Reply
    • 19. tkraz  |  June 20, 2014 at 3:50 pm

      Garth,

      You’ve got by a couple of years in the teaching of programming department but if you add my years of programming in the “real world” prior to teaching, it’s pretty much a tie!

      In any case, I whole heartily agree with most of your list. My continuation rate from the 1st semester to 2nd is closer to 50%, though. I have been starting with Java for the past several years. Prior to that, it was C++, before that Pascal, and before that Basic!

      I think it’s essential to make the programming assignments interesting and manageable in size and challenge (without being too easy). If students get some sense of accomplishment often (and with immediate feedback it’s always possible) they tend to stick with it longer.

      If we give them a programming foundation, they have many paths to pursue on their own. Almost any language can provide them that spark.

      Thanks for your insight and experienced viewpoint.

      Reply
    • 20. Leigh Ann DeLyser  |  July 1, 2014 at 3:10 pm

      Garth, I’m going to add to your list.

      11. Programming requires persistence. At least in most of the project-based assignments we give. Languages like Scratch and Alice help students believe that with effort they CAN reach an acceptable outcome. When students first encounter programming if they do not believe their effort will equal a useful outcome they withdraw.

      Now I’m going to multiply that times a large number of students whose academic career has been an exercise in failure or just getting by from “makeup” work. (welcome to the inner city) Using languages like scratch and alice allow us to not only shore up student’s academic skills, but also the soft skills as well.

      And before we start a debate about whether this is part of CS – I’m at a Career and Technical Education program focused on Software Engineering – so iterative development and persistence are actually part of the stated outcomes of the first course in our sequence.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Recent Posts

June 2014
M T W T F S S
« May   Jul »
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Feeds

Blog Stats

  • 1,294,189 hits

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 4,598 other followers

CS Teaching Tips


%d bloggers like this: