Posts tagged ‘programming languages’

Stanford CS department updates introductory courses: Java is Gone

Stanford has decided to move away from Java in their intro courses. Surprisingly, they have decided to move to JavaScript.  Philip Guo showed that most top CS departments are moving to Python.  The Stanford Daily article linked below doesn’t address any other languages considered.

The SIGCSE-Members list recently polled all of their members to talk about what they’re currently teaching.  The final spreadsheet of results is here.  Python appears 60 times, C++ 54 times, Java 84 times, and JavaScript 28 times.  I was surprised to see how common C++ is, and if Java is dying (or “showing its age,” as Eric Roberts is quoted below), it’s going out as the reigning champ.

When Java came out in 1995, the computer science faculty was excited to transition to the new language. Roberts wrote the textbooks, worked with other faculty members to restructure the course and assignments and introduced Java at Stanford in 2002. “Java had stabilized,” Roberts said. “It was clear that many universities were going in that direction. It’s 2017 now, and Java is showing its age.” According to Roberts, Java was intended early on as “the language of the Internet”. But now, more than a decade after the transition to Java, Javascript has taken its place as a web language.

Source: CS department updates introductory courses | Stanford Daily

ADDENDUM: As you see from Nick Parlante’s comment below, the JavaScript version is only an experiment.  From people I’ve talked to at Stanford, and from how I read the article quoted above (“more than a decade after the transition to Java, Javascript has taken its place”), I believe that Stanford is ending Java in CS106.  I’m leaving the title as-is for now. I’ve offered to Marty Stepp that if CS106 is still predominantly Java in one year, I will post a new blog post admitting that I was wrong.  Someone remind me in April 2018, please.

April 21, 2017 at 7:09 am 20 comments

Scientists Looking at Programmers’ Brains see more Language than Mathematics: The Neuroscience of Programming

I’m not convinced that our ability to image brains is actually telling us much about cognition yet.  I did find this result surprising, that our understanding of programming languages seems more linguistic than mathematical

Scientists are finding that there may be a deeper connection between programming languages and other languages then previously thought. Brain-imaging techniques, such as fMRI allow scientists to compare and contrast different cognitive tasks by analyzing differences in brain locations that are activated by the tasks. For people that are fluent in a second language, studies have shown distinct developmental differences in language processing regions of the brain. A new study provides new evidence that programmers are using language regions of the brain when understanding code and found little activation in other regions of the brain devoted to mathematical thinking.

Source: Scientists Begin Looking at Programmers’ Brains: The Neuroscience of Programming | Huffington Post

January 23, 2017 at 7:00 am 12 comments

Which is better for novices, C++ lambdas or iterators? New research from Andreas Stefik’s group

I needed to look up a paper on Andreas Stefik’s page the other day and came across this fascinating new paper from him:

Phillip Merlin Uesbeck, Andreas Stefik, Stefan Hanenberg, Jan Pedersen, and Patrick Daleiden. 2016. An empirical study on the impact of C++ lambdas and programmer experience. In Proceedings of the 38th International Conference on Software Engineering (ICSE ’16). ACM, New York, NY, USA, 760-771.

(You can download it for free from his publications page: http://web.cs.unlv.edu/stefika/research.html.)

Since this is Stefik, he carefully describes what his paper is saying and what it’s not saying.  For example, he and his students measured C++ lambdas vs iterators — not a particularly pleasant syntax to work with.

The results are quite interesting.  This graph is what caught my eye.  For professionals, iteration and lambdas work just about the same.  For novices, iterators blows lambdas away.  Lambda-using students took more time to complete tasks and received more compiler errors (though that might be a good thing, in terms of using the compiler to find and correct bugs).  Most interesting was how the differences disappeared with experience. Quoting from the abstract:

Finally, experienced users were more likely to complete tasks, with or without lambdas, and could do so more quickly, with experience as a factor explaining 45.7% of the variance in our sample in regard to completion time.

This is an example of my “Test, don’t trust” principle (see earlier blog post).  I was looking up Stefik’s paper because I received an email from someone who simply claimed, “And I’m using functional notation because it’s much easier for novices than procedural or object-oriented.”  That may be true, but it ought to be tested.

Cursor_and_p760-uesbeck_pdf

July 29, 2016 at 7:42 am 4 comments

How to choose programming languages for learners: Reviewing JavaScript and Ready

My Blog@CACM post for June is Five Principles for Programming Languages for Learners. The five principles I identify are:

  1. Connect to what learners know
  2. Keep cognitive load low
  3. Be honest
  4. Be generative and productive
  5. Test, don’t trust

I wrote the essay in response to Idit Harel’s influential essay American schools are teaching our kids how to code all wrong. There were many responses to Idit’s essay, on social media and in other blogs. Much of the discussion focused on text programming languages vs. drag-and-drop, blocks-based languages, which I don’t think is the most critical distinction.

In this post, I respond to two of the suggestions that came up in some of these discussions. I use the five principles to review the suggestions in a kind of heuristic evaluation.

JavaScript

If we were going to teach a professional language to students, JavaScript is attractive. It’s free and ubiquitous, available in every Web browser. There are many jobs for JavaScript programmers. Because so much is built on top of it, it’s likely to remain around for many years in a compatible form. I argue in the Blog@CACM post that there are many dimensions to “real” when it comes to programming languages. “Use by professionals” is not the most important one when we talk about learners.

I recommend considering each of these five principles before choosing a programming language like JavaScript for learners.

  1. Connect to what learners know – You could teach JavaScript as a connection to what children already know. The notation of JavaScript doesn’t look like anything that children are likely to have seen before, in contrast to Logo’s emphasis on words and sentences, Squeak eToys’ “Drive the Car,” Boxer’s simple UI boxes (what diSessa calls naive realism), and Racket/Bootstrap’s connections between algebra and S-expressions.  However, JavaScript is the language of the Web today, so one could probably relate the programming activities to Web pages. Most learners are familiar with parts of a Web page, animations in a Web page, and other Web features that JavaScript can control. That might serve as a connection point for children.
  2. Keep cognitive load low – JavaScript has a high cognitive load. I’m a JavaScript learner and am just meeting some of its weirder features. I was shocked when I first read that = is assignment, == is type-insensitive equality, and === is type sensitive equality/equivalence. So, "5"==5 is true, but "5"===5 is false. Counting the number of = and remembering what 1 vs 2 vs. 3 means is an excellent example of extraneous cognitive load. My bet is that JavaScript overwhelms children and is probably inefficient for adult learners. This means that learners are spending so much time making sense of the syntax, it takes them longer and more effort to get to the concepts (and they may lose interest before they get to the good stuff).
  3. Be honest – JavaScript is authentic, it’s real for most senses of the term.
  4. Be generative and productive – I don’t know if JavaScript would be generative and productive for students. I don’t know anyone teaching JavaScript as a way to teach significant ideas in CS or other STEM disciplines. My worry is that the cognitive load would be so overwhelming that you couldn’t get to the interdisciplinary or complex ideas. Students would spend too much effort counting = and fighting for loops.
  5. Test, don’t trustThe only study that I know comparing JavaScript to a blocks-based language had JavaScript losing. JavaScript conditionals and loop structures were far harder for students than the equivalent block-based structures.

We should experiment more with JavaScript, but I suspect that students would do better (struggle less with syntax, learn more, connect to other disciplines more) with a different syntax. If I were trying to get the advantages of JavaScript without the syntax cost, I’d try something like ClojureScript — freely available, as fast as JavaScript, as ubiquitous as JavaScript, used professionally, can be used to control Web pages like JavaScript (so connectable for learners), and with the syntactic similarities to mathematics that Racket enjoys.

Ready

Baker Franke of Code.org is promoting the essay Coding snobs are not helping our children prepare for the future as a response to Idit’s essay. The essay is about the application-building tool, Ready. Media theorist Dough Rushkoff has also been promoting Ready, What happens when anyone can code? We’re about to find out.

I disagree with Rushkoff’s description of Ready, even in the title. As the first essay by David Bennahum (a “Ready Maker and Venture Partner) points out, it’s explicitly not about using a programming language.

Our efforts at Ready, a platform that enables kids to make games, apps, whatever they want, without knowing a computer language, are designed to offer a new approach to broadening access to code literacy.

Bennahum’s essay means to be provocative — and even insulting, especially to all the teachers, developers, and researchers who have been creating successful contextualized computing education:

In this new world, learning coding is about moving away from computer languages, syntax, and academic exercises towards real world connections: game design and building projects that tie into other subjects like science and social studies… This is the inverse of how computer science has been taught, as an impersonal, disconnected, abstracted, mathematical exercise.

I can see how Rushkoff could be confused. These two quotes from the Ready team seem contradictory. It’s not clear how Ready can be both about “learning coding” and “code literacy” while also allowing kids to make “without knowing a computer language.” There is no programming language in Ready.  What is coding then? Is it just making stuff?  I agree with Rushkoff’s concerns about Ready.

True, if people don’t have to code, they may never find out how this stuff really works. They will be limited to the programming possibilities offered by the makers of the platforms, through which they assemble ready-made components into applications and other digital experiences.

Let’s consider Ready against the five principles I propose.

  1. Connect to what learners know – the components of Ready are the icons and sliders and text areas of any app or game. That part is probably recognizable to children.
  2. Keep cognitive load low – Ready is all about dragging and dropping pieces to put them together. My guess is that the cognitive load is low.
  3. Be honest – Ready is not “real” in most sense of authenticity. Yes, students build things that look like apps or games, but that’s not what motivates all students. More of Betsy DiSalvo’s “Glitch” students preferred Python over Alice (see blog post). Alice looked better (which appealed to students interested in media), but students knew that Python was closer to how professional programmers worked. Authenticity in terms of practice matters to students. No professional programmer solely drags and drops components. Programmers use programming languages.
  4. Be generative and productive – Ready completely fails this goal. There is no language, no notation. There is no tool to think with. It’s an app/game builder without any affordances for thinking about mathematics, science, economics, ecology, or any other STEM discipline. There’s a physics engine, but it’s a black box (see Hmelo and Guzdial on black box vs glass box scaffolding) — you can’t see inside it, you can’t learn from it. They build “models” with Ready (see this neurobiology example), but I have a hard time seeing the science and mathematics in what they’re building.
  5. Test, don’t trust – Ready offers us promises and quotes from experts, but no data, no results from use with students.

Ready is likely successful at helping students to make apps and games. It’s likely a bad choice for learners. I don’t see affordances in Ready for computational literacy.

June 20, 2016 at 7:46 am 22 comments

Summarizing the Research on Designing Programming Languages to be Easier to Learn: NSF CS Ed Community Meeting

I’m at the NSF STEM+Computing and Broadening Participation in Computing Community Meeting.  At our ECEP meeting on Saturday, we heard from White House Champion of Change Jane Margolis.  She did a great job of getting our states to think about how to change their state plans to emphasize diversity and equity — more on that in a future blog post.

12657757_10101604211025169_5607395108039854037_o

I moderated a panel yesterday on how to integrate computing education into schools of education.  Here’s the description of the session — again, more later on this.

Integrating Computing Education into Preservice Teacher Development Programs  

(Mark Guzdial (moderator), Leigh Ann DeLyser, Joanna Goode, Yasmin Kafai, Aman Yadav)

For computing education to become ubiquitous and sustainable in US K-12 schools, we need schools of Education to teach computing.
  • ​What should we be teaching to preservice teachers?
  • Where should we teach CS methods in preservice teacherdevelopment?
  • How do we help schools of Ed to hire and sustain faculty who focus on computing education?
Panelists will talk about how CS Ed is being integrated into their preservice teacher development programs, and about alternative models for addressing these questions.

Yesterday, our other computing education research Champion of Change, Andreas Stefik presented a summary of the empirical evidence on how to design programming languages to make them easier to learn.  Follow the link below to get to the two-page PDF pamphlet he produced for his presentation — it’s dense with information and fascinating.

This pamphlet is designed to provide an overview of recent evidence on human factors evidence in programming language design. In some cases, our intent is to dispel myths. In others, it is to provide the result of research lines.

from Programming Languages and Learning by Andreas Stefik

February 2, 2016 at 8:58 am 5 comments

ICER 2015 Report: Blocks win–Programming Language Design == UI Design

ICER 2015 at the University of Nebraska, Omaha was fantastic.  Brian Dorn did a terrific job hosting all of us.

The Doctoral Consortium went really well.  We had 20 students from US, Chile, Germany, and UK.  Below is a picture from the “Up against the wall bubble sort” where experienced students went to one side, and newer students went to the other, and the former gave advice to the latter.

 

 

icer-2015-dc-group

Georgia Tech had even more going on at ICER and RESPECT than I mentioned in my earlier blog posts (like here and here).  The GVU Center did a nice write up about all of us here.  The biggest thrill at ICER for the GT crowd was Briana Morrison receiving the Chairs Award (one of two best paper awards at ICER) for the paper that I blogged about here.  Below is the whole GT contingent at ICER (including chair Brian Dorn, GT alum).

icer_2015_group_photo

The other best paper award, the peoples’ choice John Henry Award, went to Kristin Searle and Yasmin Kafai (see paper here) about the e-textiles work with American Indians that I blogged about here.  Kristin had so many interesting insights, like the boys in her project telling her that “I don’t own” the projects they made because they felt no ownership over the programming environment they were using.

The quality of the papers was very good (you can see the list of all of them here).  My favorite paper from my review packet was presented Monday morning, Spatial Skills in Introductory Computer Programming.  Steve Cooper and Sheryl Sorby with two undergraduates at Stanford did the study that I’ve been wanting to see for ages (see blog post where I talk about it). Training an experimental group in spatial skills improved performance over a control group.  Surprisingly, SES and race differences disappeared in the experimental group!  This is an important result.

But one session blew me away — it changed how I think about blocks programming.

  • The first paper was from Thomas Price and Tiffany Barnes showing that students using blocks were able to achieve programming tasks faster than those using text, but with no difference in learning or attitudes afterwards (paper here).  This was an interesting result, but it was a limited study (short intervention, no pre-test) so it mostly supported a finding from Chris Hundhausen from years previous that graphical, direct-manipulation languages lead to faster start-up than text languages (see paper here).
  • David Weintrop presented his remarkable paper with Uri Wilensky (see paper here).  Below is the graph that changed my thinking about blocks.  David carefully developed an isomorphic test in blocks and text, and gave it to the same population.  Students did much better on the blocks-based test. MODALITY MATTERS!  Blocks and text are not equivalent. He did careful analyses at each level of the test. For example, David replicated the result that else clauses in text are really hard for novices (which I talked about here), but students perform much better in blocks-based if-else.

 

commutative-assessment-p101-weintrop_pdf__page_5_of_10_

 

  • Diana Franklin presented their paper describing fourth graders reading Scratch programs (see paper here).  I was expecting a paper on program comprehension — it wasn’t.  Instead, it was a paper about user interfaces, and how the user interface interfered or supported students exploring and coming to understand the program.

I came away from that three papers realizing that blocks programming is likely the best modality to use in elementary school programming, and perhaps even when starting to program in high school, and maybe even for end-user programmers.  But even more important, I realized that Andy Ko’s comments about programming languages as being a powerful and unusable user interface (see his blog post here) is the critical insight about programming today.  David showed us that blocks can dramatically increase readability of programs.  Diana showed us that the user interface dramatically influences the readability of the blocks.  At the novice programming level, blocks-based languages are the most promising direction today, and designing good blocks languages is as much a user interface design problem as it is a programming language design problem.

 

August 17, 2015 at 7:27 am 4 comments

Blocks and Beyond Workshop at VL/HCC: Lessons and Directions for First Programming Environments

Thursday, October 22, 2015, Atlanta, GA

A satellite workshop of the 2015 IEEE Symposium Visual Languages and Human-Centric Computing (VL/HCC) https://sites.google.com/site/vlhcc2015

Scope and Goals

Blocks programming environments represent program syntax trees as compositions of visual blocks. This family of tools includes Scratch, Code.org’s Blockly lessons, App Inventor, Snap!, Pencil Code, Looking Glass, etc. They have introduced programming and computational thinking to tens of millions, reaching people of all ages and backgrounds.

Despite their popularity, there has been remarkably little research on the usability, effectiveness, and generalizability of affordances of these environments. The goal of this workshop is to begin to distill testable hypotheses from the existing folk knowledge of blocks environments and identify research questions and partnerships that can legitimize, or discount, pieces of this knowledge. It will bring together educators and researchers who work with blocks languages and members of the broader VL/HCC community interested in this area. We seek participants with diverse expertise, including, but not limited to: design of programming environments, instruction with these environments, the learning sciences, data analytics, usability, and more.

The workshop will be a generative discussion that sets the stage for future work and collaboration. It will include participant presentations and demonstrations that frame the discussion, followed by reflection on the state of the field and smaller working-group discussion and brainstorming sessions.

Suggested Topics for Discussion

  • Who uses blocks programming environments and why?
  • Which features of blocks environments help or hinder users? How do we know? Which of these features are worth incorporating into more traditional IDEs? What helpful features are missing?
  • How can blocks environments and associated curricular materials be made more accessible to everyone, especially those with disabilities?
  • Can blocks programming appeal to a wider range of interests (e.g., by allowing connections to different types of devices, web services, data sources, etc.)?
  • What are the best ways to introduce programming to novices and to support their progression towards mastery? Do these approaches differ for for learners of computing basics and for makers?
  • What are the conceptual and practical hurdles encountered by novice users of blocks languages when they face the transition to text languages and traditional programming communities? What can be done to reduce these hurdles?
  • How can we best harness online communities to support growth through teaching, motivating, and providing inspiration and feedback?
  • What roles should collaboration play in blocks programming? How can environments support that collaboration?
  • In these environments, what data can be collected, and how can that data be analyzed to determine answers to questions like those above? How can we use data to answer larger scale questions about early experiences with programming?
  • What are the lessons learned (both positive and negative) from creating first programming environments that can be shared with future environment designers?

Submission

We invite two kinds of submissions:

  1. A 1 to 3 page position statement describing an idea or research question related to the design, teaching, or study of blocks programming environments.
  2. A paper (up to 6 pages) describing previously unpublished results involving the design, study, or pedagogy of blocks programming environments.

All submissions must be made as PDF files to the Easy Chair Blocks and Beyond workshop submission site (https://easychair.org/conferences/?conf=blocksbeyond2015). Because this workshop will be discussion-based, rather than a mini-conference, the number of presentation/demonstration slots are limited. Authors for whom presentation or demonstration is essential should indicate this in their submission.

Important Dates

  • 24 Jul. 2014: Submissions due.
  • 14 Aug. 2015: Author notification.
  • 4 Sep. 2015: Camera ready copies due.
  • 22 Oct. 2015: Workshop in Atlanta.

Organizers

  • Franklyn Turbak (chair), Wellesley College
  • David Bau, Google
  • Jeff Gray, University of Alabama
  • Caitlin Kelleher, Washington University, St. Louis
  • Josh Sheldon, MIT

Program Committee

  • Neil Brown, University of Kent
  • Dave Culyba, Carnegie Mellon University
  • Sayamindu Dasgupta, MIT
  • Deborah Fields, Utah State University
  • Neil Fraser, Google
  • Mark Friedman, Google
  • Dan Garcia, University of California, Berkeley
  • Benjamin Mako Hill, University of Washington
  • Fred Martin, University of Massachusetts Lowell
  • Paul Medlock-Walton, MIT
  • Yoshiaki Matsuzawa, Aoyama Gakuin University
  • Amon Millner, Olin College
  • Ralph Morelli, Trinity College
  • Brook Osborne, Code.org
  • Jonathan Protzenko, Microsoft Research
  • Ben Shapiro, Tufts University
  • Wolfgang Slany, Graz University of Technology
  • Daniel Wendel, MIT

June 29, 2015 at 8:00 am Leave a comment

Older Posts


Recent Posts

April 2017
M T W T F S S
« Mar    
 12
3456789
10111213141516
17181920212223
24252627282930

Feeds

Blog Stats

  • 1,378,214 hits

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

Join 4,653 other followers

CS Teaching Tips