Posts tagged ‘Java’
An Ebook for Java AP CS Review: Guest Blog Post from Barbara Ericson
My research partner, co-author, and wife, Barbara Ericson, has been building an ebook (like the ones we’ve been making for AP CSP, as mentioned here and here) for students studying Advanced Placement (AP) CS Level A. We wanted to write a blog post about it, to help more AP CS A students and teachers find it. She kindly wrote this blog post on the ebooks
I started creating a free interactive ebook for the Advanced Placement (AP) Computer Science (CS) A course in 2014. See http://tinyurl.com/JavaReview-new. The AP CSA course is intended to be equivalent to a first course for computer science majors at the college level. It covers programming fundamentals (variables, strings, conditionals, loops), one and two dimensional arrays, lists, recursion, searching, sorting, and object-oriented programming in Java.
The AP CSA ebook was originally intended to be used as a review for the AP CSA exam. I had created a web-site that thousands of students were using to take practice multiple-choice exams, but that web-site couldn’t handle the load and kept crashing. Our team at Georgia Tech was creating a free interactive ebook for Advanced Placement Computer Science Principles (CSP) course on the Runestone platform. The Runestone platform was easily handling thousands of learners per day, so I moved the multiple choice questions into a new interactive ebook for AP CSA. I also added a short description of each topic on the AP CSA exam and several practice exams.
Over the years, my team of undergraduate and high school students and I have added more content to the Java Review ebook and thousands of learners have used it. It includes text, pictures, videos, executable and modifiable Java code, multiple-choice questions, fill-in-the-blank problems, mixed-up code problems (Parsons problems), clickable area problems, short answer questions, drag and drop questions, timed exams, and links to other practice sites such as CodingBat (https://codingbat.com/java) and the Java Tutor (http://pythontutor.com/java.html#mode=edit). It also includes free response (write code) questions from past exams.
Fill-in-the-blank problems ask a user to type in the answer to a question and the answer is checked against a regular expression. See https://tinyurl.com/fillInBlankEx. Mixed-up code problems (Parsons problems) provide the correct code to solve a problem, but the code is broken into code blocks and mixed up. The learner must drag the blocks into the correct order. See https://tinyurl.com/ParsonsEx. I studied Parsons problems for my dissertation and invented two types of adaptation to modify the difficulty of Parsons problems to keep learners challenged, but not frustrated. Clickable area questions ask learners to click on either lines of code or table elements to answer a question. See https://tinyurl.com/clickableEx. Short answer questions allow users to type in text in response to a question. See https://tinyurl.com/shortAnsEx. Drag and drop questions allow the learner to drag a definition to a concept. See https://tinyurl.com/y68cxmpw. Timed exams give the learner practice a set amount of time to finish an exam. It shows the questions in the exam one at a time and doesn’t give the learner feedback about the correctness of the answer until after the exam. See https://tinyurl.com/timedEx.
I am currently analyzing the log file data from both the AP CSA and CSP ebooks. Learners typically attempt to answer the practice type questions, but don’t always run the example code or watch the videos. In an observation study I ran as part of my dissertation work, teachers said that they didn’t run the code if the got the related practice question correct. They also didn’t always watch the videos, especially if the video content was also in the text. Usage of the ebook tends to drop from the first chapter to the last instructional chapter, but increases again in the practice exam chapters at the end of the ebook. Usage also drops across the instructional material in a chapter and then increases again in the practice item subchapters near the end of each chapter.
Beryl Hoffman, an Associate Professor of Computer Science at Elms College and a member of the Mobile CSP team, has been creating a new AP CSA ebook based on my AP CSA ebook, but revised to match the changes to the AP CSA course for 2019-20202. See https://tinyurl.com/csawesome. One of the reasons for creating this new ebook is to help Mobile CSP teaches prepare to teach CSA. The Mobile CSP team is piloting this book currently with CSP teachers.
Stanford is NOT switching from Java to JavaScript: I was mistaken
Last April, I wrote a blog post saying that Stanford was abandoning Java for JavaScript in their intro course (see post here). The post was initiated by an article in the Stanford Daily. The post caused quite an uproar, way more than I expected. More than one Stanford faculty member reached out to me about it. In particular, Marty Stepp told me that I was definitely wrong, that Stanford would mostly be teaching Java in a year. I promised that if I was wrong a year later, I would write another post correcting my first post.
It’s been a year, and I was wrong. Stanford is NOT abandoning Java for JavaScript.
I’m glad I was wrong, but it has nothing to do with Java or JavaScript.
I heard about the possible switch to JavaScript several months before from a Stanford faculty member. When I saw the Stanford Daily article, I thought it was okay to talk about it. Marty told me at the time that I was wrong, and that the article was ill informed. Still another Stanford faculty member wrote me about the tensions over this issue.
A lesson I learned from Mike Lach and others involved in the NGSS roll out is that all curricular decisions are political decisions. A framework might be based on scientific expertise, but what is actually taught is about choice and vision — different opinions of how we interpret where we are now and what we want in the future. If you haven’t heard about the politics of curricular choices before, I highly recommend Schoolhouse Politics.
I am not at Stanford, so I don’t know how curricular decisions have been made and were made here. I based my post on talking with some Stanford faculty and reading the Stanford Daily article. I predicted that the forces pushing for JavaScript would end up changing the curriculum. They didn’t (or haven’t so far). The Stanford lecturers are excellent, and they are the ones actually teaching those classes. I’m glad that they get to continue teaching the classes the way that they think is most valuable.
Below is what Marty wrote me about the courses at Stanford, and a link to the Stanford course offerings, showing that Stanford is still primarily a Java house:
This calendar year our CS1 Java course is still quite clearly the dominant course. Nick Parlante is also teaching two smaller experimental offerings of a Python class in our winter and spring quarters. There may be another experimental JavaScript and/or Python course on the books for fall, but it certainly will not be the main class; the CS1 in Java will continue to be so throughout all of the next academic year. Currently no plan is under way to change that, though we certainly are open to evolving our courses in the long term like any other school would be. I would like to note that the state of intro at Stanford is exactly as was described to you by myself and others 10 months ago.
Why do so few schools try LiveCode? We let industry dictate our tools
I’m an old HyperCard programmer, so I like LiveCode. LiveCode does very well on the five principles I suggest for picking an educational programming language. The language is highly readable, and was actually designed drawing on research on how novices best understand programming. It’s easy to put together something that looks authentic and that runs on virtually any platform — much easier than Python, Java, Scratch, Blockly, or any of the other top five most popular teaching languages. Authenticity is often engaging for students.
The LiveCode folks have just put together a web page (linked below) describing some of the reasons why teachers should consider LiveCode. But in general, we don’t. Why not? I have two guesses:
- There is no community of practice. There isn’t a visible community of teachers using LiveCode. There isn’t an obvious industry call for more LiveCode programmers.
- We in computing education are mostly driven by surface-level interpretations of industry needs. It isn’t obvious that it must be so, or even that it should be so. But the same forces that killed Pascal and promoted Python, Java, and C++ as our intro languages prevent LiveCode from getting adopted.
I think LiveCode, Smalltalk, and Lisp are all excellent pedagogical programming languages, but our teaching decisions in secondary and post-secondary CS education are rarely based on what will engage students, be easier to learn, or lead to transferable knowledge. Instead, we tend to make decisions on what obviously looks like what current professionals do. It binds us to normative practices. We’re stuck in apprenticeship as our teaching perspective, and can’t consider social reform or developmental perspectives.
Better Exam Results, Better Real Life Outcomes, More Fun!
Over a third of Scottish schools are now teaching using LiveCode. They are doing this because they have proven results showing that using LiveCode results in more students remaining engaged, reaching good grades, and continuing in the direction of a coding career.
Source: Education | LiveCode
Stanford CS department updates introductory courses: Java is Gone
See update here: Stanford is NOT switching from Java to JavaScript: I was mistaken
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.
Python is the most popular intro language: But what about CS Principles?
Philip Guo did an analysis of what top CS departments teach in their introductory courses (see link below) and found that Python now tops Java. MATLAB tops C and C++ (though not if these are combined), and Scheme and Scratch are near the bottom.
Philip’s analysis did include CS0 and CS1 courses, which points to a problem for adoption of CS Principles as an Advanced Placement exam. Scratch is the only one of the popular CS Principles languages now used in the CSP Pilots that is also being used in CS departments. Other CSP popular languages include App Inventor, Alice, Processing, JavaScript, and Snap!. Those don’t appear in Philip’s results to any significant degree.
It’s reasonable to say that an AP will only succeed (e.g., students will take it) if they can get credit or placement for the exam in college or university. Typically, colleges and universities give credit for courses that are currently taught. Will we see colleges and universities start teaching CS Principles? Will they give credit for a course that they don’t teach? For languages they don’t teach? Maybe we’ll see more of an influx of CSP languages and courses into colleges and universities. I predict that we won’t.
Scratch is the only visual, blocks-based language that made this list. It’s one of the most popular languages of this genre, which include related projects such as Alice, App Inventor, Etoys, Kodu, StarLogo, and TouchDevelop. The creators of these sorts of languages focus mostly on K-12 education, which might explain why they haven’t gotten as much adoption at the university level.
The best Bret Victor video yet: “We don’t know anything about computing.”
The punchline for computing education comes in the last 5 minutes, but the previous 27 minutes are well worth watching. Bret is critiquing the same mindset I was reporting on when I said that Lisp and Smalltalk are now dead in undergraduate computer science. “We don’t know what we’re doing” is the most important phrase for computer scientists to say to ourselves and to our students. I enjoy the flash and style of Bret’s previous videos, but I love the message of this video. The details (with copious references) can be found on his website.
The BlueJ Blackbox now available: large scale programming education data collection
Neil Brown announced this at ICER last week. The new version of BlueJ now anonymously logs user actions onto a server for analysis by researchers. I just signed up to get access to the site. I have a couple of ideas for research projects using these data. It’s pretty exciting: Big data comes to computing education research!
We have begun a data collection project, called Blackbox, to record the actions of BlueJ users. We’re inviting all the BlueJ users (with the latest version, 3.1.0, onwards) to take part. About 2 months in to the project, we already have 25,000 users who have agreed to take part, with 1,000 sending us data each day. Based on current estimates, I expect that in November 2013 we should see around 5,000 users sending data each day, with a total of over 100,000 users. Rather than hoarding the data, we are making this data available to other computing education researchers for use in their own research, so that we can all benefit from this project.
via Blackbox: large scale programming education data collection | Academic Computing.
Seeking Java-based Intro CS Classes for Experiment
From Leigh Ann Sudol-DeLyser (leighannsudol@gmail.com):
I am looking for faculty who are able to help me find subjects for my final study of my PhD thesis. I have built an online pedagogical IDE which uses problem knowledge to give students feedback about algorithmic components as they are writing code for simple array algorithms.
I am looking for faculty who are willing to assign a 5-problem sequence as a part of a homework assignment or final exam review in a CS1 course in Java. The 5 problems consist of writing code to find the sum of an array of integers, the maximum number in an array of integers, counting the number of values in a range of integers, and completing an indexOf method for an array of integers. These problems are similar to ones you might find in a system like CodingBat where students are given a method header and asked to implement code for the interior of a single method.
If you are willing to help me graduate (please!) send me your name, the university you teach at, and the number of students in your class and I will contact you with login codes for the students and further directions. I am looking for classes of all sizes from all types of colleges and universities. Please forward to your CS1 instructors where applicable.
Learning about Learning (even CS), from Singing in the Choir
Earlier this year, I talked about Seymour Papert’s encouragement to challenge yourself as a learner, in order to gain insight into learning and teaching. I used my first-time experiences working on a play as an example.
I was in my first choir for a only year when our first child was born. I was 28 when I first started trying to figure out if I was a bass or tenor (and even learn what those terms meant). Three children and 20 years later, our children can get themselves to and from church on their own. In September, I again joined our church choir. I am pretty close to a complete novice–I have hardly even had to read a bass clef in the last two decades.
Singing in the choir has the most unwritten, folklore knowledge of any activity I’ve ever been involved with. We will be singing something, and I can tell that what we sang was not what was in the music. “Oh, yeah. We do it differently,” someone will explain. Everyone just remembers so many pieces and how this choir sings them. Sometimes we are given pieces like the one pictured above. It’s just words with chords and some hand-written notes on the photocopy. We sing in harmony for this (I sing bass). As the choir director says when he hands out pieces like this, “You all know this one.” And on average, he’s right. My wife has been singing in the choir for 13 years now, and that’s about average. People measure their time in this choir in decades. The harmony for songs like this were worked out years and years ago, and just about everyone does know it. There are few new people each year — “new” includes even those 3 years in. (Puts the “long” four years of undergraduate in new perspective for me.) The choir does help the newcomers. One of the most senior bass singers gives me hand gestures to help me figure out when next phrase is going up or down in pitch. But the gap between “novice+help” and “average” is still enormous.
Lave and Wenger in their book “Situated Learning” talk about learning situations like these. The choir is a community of practice. There are people who are central to the practice, and there are novices like me. There is a learning path that leads novices into the center.
The choir is an unusual community of practice in that physical positioning in the choir is the opposite of position with respect to the community. The newbies (like me) are put in the center of our section. That helps us to hear where we need to be when singing. The more experienced people are on the outside. The most experienced person in the choir, who may also be the eldest, tends to sit on the sidelines, rather than stand with the rest of the choir. He nails every note, with perfect pitch and timing.
Being a novice in the choir is enormous cognitive overload. As we sing each piece, I am reading the music (which I’m not too good at) to figure out what I’m singing and where we’re going. I am watching the conductor to make sure that my timing is right and matches everyone else. I am listening intently to the others in my section to check my pitch (especially important for when there is no music!). Most choir members have sung these pieces for ages and have memorized their phrasing, so they really just watch the director to get synchronized.
When the director introduces a new piece of music with, “Now this one has some tricky parts,” I groan to myself. It’s “tricky” for the average choir members — those who read the music and who have lots of experience. It’s “tricky” for those with literacy and fluency. For me, still struggling with the notation, it takes me awhile to get each piece, to understand how our harmony will blend with the other parts.
I think often about my students learning Java while I am in choir. In my class, I introduce “tricky” ideas like walking a tree or network, both iteratively and recursively, and they are still struggling with type declarations and public static void main. I noticed last year that many of my students’ questions were answered by me just helping them use the right language to ask their question correctly. How hard it must be for them to listen to me in lecture, read the programs we’re studying, and still try to get the “tricky” big picture of operations over dynamic data structures–when they still struggle with what the words mean in the programs.
Unlike working on the play, singing in the choir doesn’t take an enormous time investment — we rehearse for two hours one night, and an hour before mass. I’m having a lot of fun, and hope to stick with it long enough to move out of the newbie class. What’s motivating me to stick with it is enjoyment of the music and of becoming part of the community. There’s another good lesson for computer science classes looking to improve retention. Retention is about enjoying the content and enjoying the community you’re joining.
Why we ought to teach Java: Computing education and social practice
We’re re-examining/reconstructing our reading list for the qualifying examination for our PhD in Human-Centered Computing. One of the papers I’ve had the chance to read (and re-read — it’s a dense piece) is by James Greeno, Allan Collins, and Lauren Resnick, three top-notch education researchers.
Greeno, J., Collins, A., & Resnick, L. (1996) ‘Cognition and learning,’ in Berliner, D. & Calfee, R. (eds.), Handbook of Educational Psychology, Macmillan, New York: 15-46.
They contrast three views of education, which are paradigm shifts in the Kuhnian sense. It’s not that one is better than the other. One looks at different things than the other, creates different theory, leads to predictions about entirely different things. The first was behaviorist/empiricist — learning was observed responses to stimuli. Behaviorism explains a lot, and can lead to strong predictions. The second is the cognitive/rationalist view, the view of learning as have knowledge structures in the brain. This was the view started by Piaget, and it has had the greatest impact on schools. The third view is the “situative/pragmatist-sociohistoric.”
A third perspective on knowing focuses on the way knowledge is distributed in the world among individuals, the tools, artifacts, and books that they use, and the communities and practices in which they participate. The situative view of knowing, involving attunements to constraints and affordances of activity systems, suggests a fundamental change in the way that instructional tasks are analyzed. The change is away from analyses of component subtasks to analyses of the regularities of successful activity…When knowing is viewed as practices of communities and abilities of individuals to participate in those practices, then learning is the strengthening of those practices and participatory abilities.
This is the perspective described in Lave & Wenger’s classic Situated learning: Legitimate peripheral participation (also on our HCC reading list). The situative view is most powerful in describing learning in naturalistic settings, from apprenticeship to life-long learning (e.g., how professionals get better at what they do). An important difference between the situative and the cognitive is in defining “what’s worth knowing.” The situative is focused on learning how to participate in a community of practice, to be part of the discourse and activities of a group of people who work towards similar sets of goals in similar ways.
Computer science education is feeling the tension between the cognitive and the situative today. I see it in the discussion about Greenfoot. We CS educators talk about our foundational concepts, and we talk about learning the tools of our community. We say that “We don’t teach languages, we teach concepts,” but then we talk about our courses as “the C course” and “the Java course.” Once, the community of practice in computing was mathematics and electrical engineering. That’s what people knew and talked about, and that’s what we now call our foundational concepts. Today, there is a huge community of computing professionals and scientists with lots of activities and tools. They have a practice and an on-going discussion. Knowing the common knowledge and practices in use in computing today is not vocational — it’s about being able to communicate with others in the practice. Java is the the most common language in the discourse of computing education today. No computer science undergraduate is educated without knowing it. This fact has nothing to do with what languages best make evident the concepts of computing. This has everything to do with being part of a community.
What we teach in our Media Computation data structures book when we teach about simulations in Java is absolutely harder than when I taught similar content in Squeak. But it’s harder, in part, because we’re dealing with how to make this work around the strong typing in Java, and we’re making sure that students understand interfaces. Those are worth knowing, too. Strong typing and interfaces are part of what the community of practice of computing values and talks about today. Students are not well-educated if they cannot be part of that conversation (even if only to say that they don’t like the existing practices!).
As a computing educator, I have a responsibility to stay informed about the activities of computing — in part, that’s what Stroustrup is arguing when he says that professors ought to be building software. I have a whole collection of recent computing books on my shelf that I’m still working through. There are books on Ruby and Lua, Django and script.acul.ous. Are these the right ones? I don’t know. They’re my best guess, and once I read up on them, I’ll have a better sense of whether I think they’re worthwhile. I should be able to talk about the best ideas in tools used by practitioners in my community, the community that I work in and that my students will work in–and importantly, critique them. Part of my job, in the Lave & Wenger sense, is to exemplify the center of the community of practice for my students. To do that, I have to be able to speak the language in that community of practice.
I’m not arguing that Java is a great language, and I’ll continue arguing that Java is a poor beginner’s language. But our students do need to know Java, because Java exemplifies the current ideas and practice of our community. Our students are not well-educated if they can’t participate in that discourse. That’s why it is important for us as computing educators to learn how to teach Java and how to motivate the learning of Java. Not teaching them Java is not an option. Not teaching them Java leaves them uneducated. Not teaching Java only means that our students will be at a disadvantage. Our students don’t win because we refuse to play the game.
An argument from the cognitive perspective (the one I grew up in) is that students who have a strong set of concepts, who understand the core of their field well, can easily teach themselves the current tools and practices of the community. That may be true. What we know about transfer suggests that it’s true. I want to believe that’s true, but I realize that I’m crossing paradigms. I do recognize that the knowledge of the language and tools don’t come for free. Yes, Ruby is like Smalltalk — but just because I know Smalltalk, doesn’t imply that I know Ruby. Just because I know English and Latin and French, doesn’t mean that I know Spanish. It might be easier for me to learn a related language. But I still have to do the work to learn it.
All the tools and languages in common practice in computing today have important ideas embedded in them from some smart people — and maybe some less-important ideas from some not-so-smart people. But they are the ideas that our community is talking about. I’m not a fan of strong typing, but I realize that my students need to know what it’s about, because there are reasons why it’s part of our dialogue today. E.D. Hirsch writes books about “cultural literacy” and has made up long lists of the vocabulary that children need to know at various ages. One can critique Hirsch’s approach for being uninformed by the cognitive. Students need to know the concepts and have the knowledge structures to think about these ideas appropriately, not just know the words. But a focus just on the concepts leaves one open to a reasonable situative criticism. Our students must also be able to talk to the practitioners in our community.
We absolutely need to create better computing education. Java is a poor beginner’s language. We have to continue to critique and develop our practices. Our students are going to join this community, and that involves not just having a set of powerful knowledge structures. It means knowing the language and common practices of this community. Java is important to learn for the situative learning goal. The goal of an education in computing is a set of concepts and the fluency in the languages and practices of the community.
How are students learning programming in a post-Basic world?
The value of Basic being described in this piece is the same argument that, I think the ACM Java Task Force was making about Java. Their point isn’t that Java (or Basic) is a great language. The point is that having a lingua franca, a language that you could count on being everywhere, that there was lots of educational support for, is a cultural advantage for developing more computer scientists. It’s a real cost today that Basic (or something else to take its place) is not omnipresent today.
“I have never received as much hate mail as I got for that article, not even for my infamous attacks on Star Wars,” Brin recalled recently. “It was almost entirely from people who missed the point, with all the rage directed at Basic. Let me be clear that I am not defending Basic. It was a primitive line-coding program, but everyone had it. Textbooks had exercises written in Basic, and teachers could count on a large fraction of their students being able to perform those assignments.”
“I am not defending Basic,” says writer David Brin, who talked about the death of the programming language in a 2006 Salon.com article. “It was a primitive line-coding program, but everyone had it.”
Today, the top one-tenth of one percent of students “will go to summer camp and learn programming, but the rest may never know that the dots comprising their screens are positioned by logic, math and human-written code,” Brin complains.
via How are students learning programming in a post-Basic world? – Computerworld.
Millions more to benefit from Greenfoot
I’m about to start teaching Greenfoot in my data structures class (the one where we introduce data structures in explaining how the wildebeest’s charge over the ridge in Disney’s The Lion King) — I’m a big fan, and am glad to hear that they’re providing more support for teachers. They just announced support for using Microsoft Kinect with Greenfoot, demoed at SIGCSE 2011.
Millions of young people are expected to benefit from a University of Kent-established international teacher training network for Greenfoot, a free-to-download software tool that teaches computer programming to pupils from 14 years upwards.
Free and available for download at www.greenfoot.org, Greenfoot was designed by members of the University’s Computing Education Research Group and colleagues at La Trobe University in Melbourne to engage pupils through an interactive environment which enables them to easily create games and simulations. To date, more than a million pupils around the world have been able to experiment with creating games and animations, with more than 250,000 active users currently developing their knowledge and expertise.
With well over one thousand institutions also using the software for their computer science teaching, the design team has increased its support for teachers by establishing seven new international hubs that will offer face-to-face workshops, training and discussions.
via Millions more to benefit from Greenfoot – Research – University of Kent.
New Myro Languages
Doug Blank just sent out this report on where the IPRE robot education technology Myro was going — the movement into new languages and platforms is pretty exciting!
This is a note to let you know the status of three new versions of Myro,
the API to interact with the Fluke and Scribbler. For more information on
any of these projects, please feel free to use this mailing list.
1) Myro in C++. This project has been developed at the University of
Tennessee at Knoxville, by Bruce MacLennan, John Hoare, and others. Mayro
in C++ is ready to use. For more information, please see:
http://wiki.roboteducation.org/Myro_in_CPlusPlus
2) Myro in Java. This project is underway at DePauw University by Doug
Harms. Myro in Java is under development and ready for testers. For more
information, please see:
http://wiki.roboteducation.org/Myro_in_Java
3) Myro in the Pyjama Project. Pyjama is a new scripting environment for
Python, Ruby, Scheme, and more. This is the latest version of Myro from
the IPRE. Pyjama is designed to run very easily on multiple platforms, and
with multiple languages. Pyjama is under development and ready for
testers. Form more information, please see:
The pages at http://wiki.roboteducation.org/ will begin to change to
reflect these exciting developments and alternatives.
I invite users and developer of all of these systems to further describe
the projects, and provide additional details.
-Doug
Predictions on Future CS1 Languages
A recent article in InfoWorld on up-and-coming languages got me thinking about the future of CS1 languages. They went on at some length about Python, which I think most people consider to be the up-and-coming CS1 language.
There seems to be two sorts of people who love Python: those who hate brackets, and scientists. The former helped create the language by building a version of Perl that is easier to read and not as chock-full of opening and closing brackets as a C descendant. Fast-forward several years, and the solution was good enough to be the first language available on Googles AppEngine — a clear indication Python has the kind of structure that makes it easy to scale in the cloud, one of the biggest challenges for enterprise-grade computing.Python’s popularity in scientific labs is a bit hard to explain, given that, unlike Stephen Wolframs Mathematica for mathematicians, the language never offered any data structures or elements explicitly tuned to meet the needs of scientists. Python creator Guido von Rossum believes Python caught on in the labs because “scientists often need to improvise when trying to interpret results, so they are drawn to dynamic languages which allow them to work very quickly and see results almost immediately.”
via 7 programming languages on the rise | Developer World – InfoWorld.
There have only really been three “CS1 languages,” the way that I’m using the term: Pascal, C++, and Java. All three programming languages were used in a large (over 50%) percentage of CS1 (intro CS for CS majors in post-secondary education in the US, and AP in high school) classes. All three were AP CS languages.
Pascal at one point was probably in over 80-90% CS1 courses. Not everyone jumped immediately to C++, but C++ was in the majority of CS1 classes. I know that because, when our Java MediaComp book came out, our publisher said that Java had just pulled even with C++ in terms of percent of the market — that means C++ had to have been in lots of classes. Java is the dominant language in CS1 classes today, but it’s declining. Python’s market share is rapidly growing, 40% per year the last three years. While it’s not clear that the new AP CS nor the AP CS Level A would ever adopt Python, Python might still gain the plurality of all CS1 languages. I doubt that any language will ever gain more than 30-40% of the CS1 market again — there are (and will be) too many options for CS1 languages, and too many entrenched interests. Faculty will stick with one, and may skip a plurality, e.g., I’ve talked to teachers at schools where they stuck with C++ but now are switching to Python.
I have two specific predictions to make about future CS1 languages, based on observations of the last three and the likely fourth.
- All future CS1 languages will be in common use in industry.
- No language will gain a plurality of CS1 courses unless it existed at the time of the last transition.
The transition from Pascal to C++ led to the greatest spike in AP CS Level A tests taken in Georgia. Until 2010, that was largest number of AP CS exams taken in Georgia. The transition from C++ to Java had nowhere near that kind of impact on the test numbers in Georgia. What might have led to so much more interest in the Pascal -> C++ transition? Pascal was a language that was not (perceived to be) common in industry, while C++ was. I don’t think that people perceived such a huge difference between C++ and Java. I believe that the sense that C++ was vocationally useful, was approved of by industry, had a huge positive impact on student interest in the test.
In this blog, we have often touched on the tension between vocational and academic interests in computer science classes. Vocational most often wins, especially in the majority schools. The elite schools might play with BYOB Scratch in their intro courses (but notice — even at Harvard and Berkeley, it’s for the non-majors, not for those who will major in CS), and community colleges might use Alice to ease the transition into programming, but the vast majority of schools in the middle value industry-approval too much to adopt a pedagogical language for their CS majors.
The implication of the first prediction is that, if Scratch or Alice are ever adopted for the new AP CS, only schools on the edges of the distribution will give CS major credit for it, because most schools will not adopt a CS1 language that isn’t useful for programming in industry. That isn’t necessarily a bad thing for the new AP CS — to succeed, schools must agree to give some credit for it, not necessarily CS major. Another implication is, if my prediction holds true, Scheme will never gain a plurality in CS1 courses.
The second implication is based on an observation of the timing of the four languages. Each existed as the previous was adopted for the AP CS Level A, which is a reasonable point at which to claim that the language had reached plurality. C++ existed (since 1983) when the AP CS Level A was started in Pascal (1988, I think). C++ was adopted in 2001, and Java came out in 1995. AP CS Level A shifted to Java in 2003, and Python 1.0 came out in 1989, with Python 2.0 (the one receiving the most interest) in 2000. It takes a lot of time to develop that industry use, and to build up the sense that the new language may be worth the pain in shifting.
The implication is that, whatever the next CS1 language will be (after Python), it exists today, as Python reaches plurality. Maybe Ruby, or Scala –more likely Ruby, given the greater industry penetration. Any language that we might invent for CS1 must wait for the next iteration. Scratch, Alice, and Kodu are unlikely to ever become CS1 languages, because it is unlikely that industry will adopt them. Few professional programmers will get their jobs due to their expertise in Scratch, Alice, or Kodu. That absolutely should not matter to CS1 instructors. But it does.
Revisited: My Students Know Far Less
Beth Simon made an excellent recommendation after my report on my first Peer Instruction lesson: Was it really a bad question that students misinterpreted? Why not ask the students? You would expect that students would most likely give me the answer on this survey that they thought I wanted. This was the first slide of the day.
Here’s the distribution of responses:
I did several more “clicker” questions today in lecture, and I’m getting a better sense of what works and what doesn’t work. (Something that doesn’t work: My <expletive deleted> Lenovo TabletPC that refused to wake up at the start of class, requiring me to reboot, and losing 10 minutes of lecture! ARGH!) I asked students to write in a piece of code today (rewrite a FOR loop as a WHILE loop). The answers were actually pretty good, but the writing took a long time. I won’t do that often.
One of the general insights I’m getting is about the large variance in the class. Here’s another question I asked in class (before the Java nitpickers let loose — we’re using DrJava, they’ve seen that code works fine without semi-colons, and in fact, we had just done these three lines verbatim with variable “fred” instead of “mabel”):
And the responses:
Most of the class grokked this one, but 5 of the 22 students who responded (some told me after class that they didn’t even respond) are pretty confused. That’s over 20%.
I chatted with several of the students after class today. They’re very confused, despite having read the first two chapters of the book (they claim) and taken the quiz. (I’m using out-of-class Video Quizzes, where students watch a videotape of me using Java, then answer questions about it.) My main insight into their confusion: After only one semester of CS classes, reading code is not an automatized skill. That’s not surprising, but it’s not something that I’d thought much about. The students told me that they’re metaphorically “sounding out” the code. They’ve thinking through what’s a method (and translating that into a MATLAB or Python “function”) and what’s a class and what’s valid Java syntax with semi-colons. That’s taking them time, and sometimes, they’re responding before they’re really confident about what they read.
Peer Instruction is taking me extra time: To get the slides onto Ubiquitous Presenter, to only present from my TabletPC, to write questions and insert them into slides, and to take time from lecture (for students to answer, to discuss, to respond again). I still think it’s worthwhile, and I plan to continue trying it.
Computing Ed Research - Guzdial's Take 
Recent Comments