Posts tagged ‘image of computing’
Not sure how (if?) we can see this in the US, but it sounds really good.
A sharp, witty, mind-expanding and exuberant foray into the world of logic with computer scientist Professor Dave Cliff. Following in the footsteps of the award-winning ‘The Joy of Stats’ and its sequel, ‘Tails You Win – The Science of Chance’, this film takes viewers on a new rollercoaster ride through philosophy, maths, science and technology- all of which, under the bonnet, run on logic.
Wielding the same wit and wisdom, animation and gleeful nerdery as its predecessors, this film journeys from Aristotle to Alice in Wonderland, sci-fi to supercomputers to tell the fascinating story of the quest for certainty and the fundamentals of sound reasoning itself.
Dave Cliff, professor of computer science and engineering at Bristol University, is no abstract theoretician. 15 years ago he combined logic and a bit of maths to write one of the first computer programs to outperform humans at trading stocks and shares. Giving away the software for free, he says, was not his most logical move…
With the help of 25 seven-year-olds, Professor Cliff creates, for the first time ever, a computer made entirely of children, running on nothing but logic. We also meet the world’s brainiest whizz-kids, competing at the International Olympiad of Informatics in Brisbane, Australia.
‘The Joy of Logic’ also hails logic’s all-time heroes: George Boole who moved logic beyond philosophy to mathematics; Bertrand Russell, who took 360+ pages but heroically proved that 1 + 1 = 2; Kurt Godel, who brought logic to its knees by demonstrating that some truths are unprovable; and Alan Turing, who, with what Cliff calls an ‘almost exquisite paradox’, was inspired by this huge setback to logic to conceive the computer.
Ultimately, the film asks, can humans really stay ahead? Could today\’s generation of logical computing machines be smarter than us? What does that tell us about our own brains, and just how ‘logical’ we really are…?
Ten years ago, professors in computer science departments everywhere wondered how undergraduates from a broad range of fields could be attracted to computer science (CS). We were convinced that this material would be vital for their careers, but we were up against negative stereotypes of programmers, and the prediction that most software jobs were about to be outsourced to the third world.
The tide has turned! The graph below shows annual enrollments over the past decade for the introductory computer science courses at UC Berkeley, Stanford, and the University of Washington. At each of these schools, and at colleges and universities across the nation, the introductory computer science course is now among the most popular courses on campus, and demands for advanced computer science courses are at record-breaking highs. At Stanford, where more than 90% of undergrads take computer science, English majors now take the same rigorous introductory CS course as Computer Science majors.
Dave Patterson and Ed Lazowska have written the above-linked blog post explaining why there has been such a rapid rise in enrollments in Computer Science at Berkeley, Stanford, and U. Washington. We’re seeing the same enormous rise in CS enrollments at Georgia Tech.
Beyond the intro course, we’re seeing a dramatic increase in CS minors. At places where everyone is required to take CS (e.g., Georgia Tech, Rose Hulman, Harvey Mudd), students have the option of going beyond that first course, and because the first course is tailored for them, they’re more likely to succeed at it. At Georgia Tech, we’re seeing students take more than just the required course and pursing a credential in CS, within their major. English majors (and lots of others) are seeing that computing is valuable.
Patterson and Lazowska offer two explanations (the numbering is mine):
1. So what happened? First, today’s students recognize that “computational thinking” — problem analysis and decomposition, algorithmic thinking, algorithmic expression, abstraction, modeling, stepwise fault isolation — is central to an increasingly broad array of fields.
That may be true, but I doubt it. It would be interesting and useful to survey these students, discover what majors they’re going into, and ask why they’re taking CS. (Kind of what we did across the state of Georgia in 2010.) I don’t believe that most people are aware of “computational thinking,” and even less, new students in higher-education. As evidence of this growing awareness, the authors cite a recent quote from Richard Dawkins (in 2013), “Biology nowadays is a branch of computer science.” That’s not a new position for Dawkins. In 2007 (at the depths of declining enrollment), he told Terry Gross on NPR, “Since Watson and Crick in 1953, biology has become a sort of branch of computer science.” This isn’t a sign of a recent awareness of the importance of “computational thinking.”
2. In addition to enhancing prospects within a chosen field, surely some of the reason for interest in computer science as a major or as a minor is to enhance employment opportunities after graduation.
But my gut is a bad judge of these things. We really ought to test these claims, rather than make claims without evidence. Who is taking CS now? And why? And how does it differ between these institutions?
The authors end their piece arguing for more faculty teaching more CS classes:
In higher education, the response has been sluggish at best. Computer Science is usually found in colleges of engineering — as is the case at Berkeley, MIT, Stanford, and Washington — so one indicator of accommodation is the fraction of engineering faculty in the field. Less than a fifth of the engineering faculty at these schools teach computer science courses, a fraction nearly unchanged in the last decade.
I strongly agree with the argument. The critical issue here isn’t about growing Engineering or if CS belongs in Egnineering. The critical issue is that computing is a form of literacy, not just a specialty skill, and we have to think about how to ramp up our offering of computing education so that it’s universally accessible.
I talked about this implication of our successful CS1’s for everyone in the May 2009 Communications of the ACM:
Finally, building successful, high-demand courses for non-computing majors gives us a different perspective on the current enrollment crisis. Students want these courses. Other schools on campus want to collaborate with us to build even more contextualized classes. While we still want more majors, we have an immediate need for more faculty time to develop and teach these courses that bring real computing to all students on campus.
I have a lot more that I want to think through and share about the seminar. I’m doing a series of blog posts this week on live coding to give me an opportunity to think through some of these issues.
I saw four sets of computing education research questions in live coding. These are unusual research questions for me because they’re Vygotskian and non-Constructionist.
Live coding is about performance. It’s not an easy task. The live coder has to know their programming language (syntax and semantics) and music improvisation (e.g., including listening to your collaborator and composing to match), and use all that knowledge in real-time. It’s not going to be a task that we start students with, but it may be a task that watching inspires students. Some of my research questions are about what it means to watch the performance of someone else, as opposed to being about students constructing. I’ve written before about the value of lectures, and I really do believe that students can learn from lectures. But not all students learn from lectures, and lectures work only if well-structured. Watching a live coding performance is different — it’s about changing the audience’s affect and framing with respect to coding. Can we change attitudes via a performance?
Vygotsky argued that all personal learning is first experienced at a social level. Whatever we learn must first be experienced as an interaction with others. In computing education, we think a lot about students’ first experience programming, but we don’t think much about how a student first sees code and first sees programming. How can you even consider studying a domain whose main activity you have never even seen? What is the role of that coding generating music, with cultural and creative overtones? The social experience introducing computing is important, and that may be something that live code can offer.
Here are four sets of research questions that I see:
- Making visible. In a world with lots of technology, code and programmers are mostly invisible. What does it mean for an audience to see code to generate music and programming as a live coder? It’s interesting to think about this impact for students (does it help students to think seriously about computing as something to explore in school?) and for a more general audience (how does it change adults’ experience with technology?).
- Separating program and process. Live coding makes clear the difference between the program and the executing process. On the first day, we saw performances from Alex MacLean and Thor Magnusson, and an amazing duet between Andrew Sorensen at Dagstuhl and Ben Swift at the VL/HCC conference in San Jose using their Extempore system. These performances highlighted the difference between program and process. The live coders start an execution, and music starts playing in a loop. Meanwhile, they change the program, then re-evaluate the function, which changes the process and the music produced. There is a gap between the executing process and the text of the program, which is not something that students often see.
- Code for music. How does seeing code for making music change student’s perception of what code is for? We mostly introduce programming as engineering practice in CS class, but live coding is pretty much the opposite of software engineering. Our biggest challenges in CS Ed are about getting students and teachers to even consider computer science. Could live coding get teachers to see computing as something beyond dry and engineering-ish? Who is attracted by live coding? Could it attract a different audience than we do now? Could we design the activity of live coding to be more attractive and accessible?
- Collaboration. Live coding is a collaborative practice, but very different from pair programming. Everybody codes, and everybody pays attention to what the others are doing. How does the collaboration in live coding (e.g., writing music based on other live coders’ music) change the perception of the asocial nature of programming?
I’ll end with an image that Sam Aaron showed in his talk at Dagstuhl, a note that he got from a student in his Sonic Pi class: “Thank you for making dull lifeless computers interesting and almost reality.” That captures well the potential of live coding in computing education research — that activity is interesting and the music is real.
I’m teaching a TA preparation course at Georgia Tech this semester. My students are PhD students who are learning how to be teaching assistants. In a session on dealing with classroom behavior and FERPA, I introduced peer instruction — I put scenarios up on the screen with four or five choices of responses, and the students used clickers to choose what they thought was the appropriate response. One of the scenarios was:
In a class discussion, a student starts yelling at another student: “You moron! C# is a terrible language for that! You should use C++!” What do you do?
I had a distractor that collected a surprising number of votes: “Just let it go – that’s the way CS students are.” And after the discussion period — that one still got some votes. The expectation that “That’s just the way CS students are” is surprisingly pervasive. Computer science teachers need to stand up to it, to demand change in culture and expectations.
Later in my class, the students are reading chapters of Diana Franklin’s new book.
So, you see, I was all too familiar with what my daughter was going through, but I was unprepared for the harassment to start in high school, in her programming class.I consulted with friends — female developers — and talked to my daughter about how to handle the situation in class. I suggested that she talk to you. I offered to talk to you. I offered to come talk to the class. I offered to send one of my male friends, perhaps a well-known local programmer, to go talk to the class. Finally, my daughter decided to plow through, finish the class, and avoid all her classmates. I hate to think what less-confident girls would have done in the same situation.My daughter has no interest in taking another programming class, and really, who can blame her.
A fascinating set of studies! (Follow the link below to see the description of the second one.) It reminds me of our GaComputes findings about the importance of early computing experiences for minority students. Just taking a single CS class changed the women’s definitions of what a computer scientist is. I’ve written on Blog@CACM about how under-represented minorities were more likely than majority students to have had some CS experience in middle or high school that influenced them. These studies together support the argument that having some CS in K12 will likely have a significant impact on later attitudes towards computing.
First, they asked undergraduates from the UW and Stanford University to describe computer science majors.
They found students who were not computer science majors believed computer scientists to be intelligent but with poor social skills; they also perceived them as liking science fiction and spending hours playing video games. Some participants went so far as to describe computer scientists as thin, pale (from being inside all the time), and having poor hygiene.
“We were surprised to see the extent to which students were willing to say stereotypical things, and give us very specific descriptions. One student said computer science majors play ‘World of Warcraft’ all day long. And that’s a very specific, and inaccurate, thing to say about a very large group of people,” Cheryan said.
However, women who had taken at least one computer science class were less likely to mention a stereotypical characteristic. There was no difference in men’s descriptions, whether or not they had taken a computer science class.
Doug Engelbart, visionary whose inventions led to the modern mouse, hypertext, computer-supported collaborative work, died on July 2 at age 88. Bret Victor wrote a wonderful piece about how statements about Doug’s inventions (like I just made) miss the point about what he was really trying to do. Recommended, and linked below.
If you truly want to understand NLS, you have to forget today. Forget everything you think you know about computers. Forget that you think you know what a computer is. Go back to 1962. And then read his intent.
The least important question you can ask about Engelbart is, “What did he build?” By asking that question, you put yourself in a position to admire him, to stand in awe of his achievements, to worship him as a hero. But worship isn’t useful to anyone. Not you, not him.
The most important question you can ask about Engelbart is, “What world was he trying to create?” By asking that question, you put yourself in a position to create that world yourself.
Audrey Watters’ excellent post on Learning to Code in 2012 pointed me to Jeff Atwood’s piece (linked at the bottom). I want everyone to learn code, so I am in direct contradiction to his position, “Please don’t learn to Code.” Jeff and I disagree primarily on two points, both of which are issues of definition:
- Most people who write code are not trying to create code solutions. Most people who write code are trying to find solutions or create non-code solutions. By “most people,” I do mean quantitatively and I do mean all people, not just professional programmers. We know that there are many more people who write code to accomplish some task, as compared to professional programmers. When I visited the NASA Goddard Visualization Lab last month, I met the director Horace Mitchell, who told me that everyone there writes code, whether they are computer scientists or not. They write code in order to explore their data and create effects that they couldn’t given existing visualization systems. They are trying to create great visualizations, not great code. They simply throw the code away afterward. This is a critical difference between what Jeff is describing and what I hope to see. We agree that the goal is a solution. I want everyone to have the possibility of using code to create their solution, not to create code as the solution.
- Most people who program are not and don’t want to be software developers. Most of the people that I teach (non-CS majors, high school teachers) have zero interest in becoming programmers. They don’t want to be “addicted to code.” They don’t want a career that requires them to code. They want to use coding for their own ends. Brian Dorn’s graphic designers are a great case in point. Over 80% of those who answered his surveys said “No, I am not a programmer,” but everyone who answered his surveys wrote programs of 100 lines or more. Not everyone who “programs” wants to be known as a “programmer.”
The problem is that we in computer science often have blinders on when it comes to computing — we only see people who relate to code and programming as we do, as people in our peer group and community do. There are many people who code because of what it lets them do, not because they want the resulting code.
“You should be learning to write as little code as possible. Ideally none.” And people who want to do interesting, novel things with computers should just wait until a software developer gets around to understanding what they want and coding it for them? I could not disagree more. That’s like saying that the problem with translating the Bible is that it made all that knowledge accessible to lay people, when they should have just waited for the Church to explain it to them. “Please don’t learn to code” can be interpreted as “Please leave the power of computing to us, and we’ll let you know when we’ll make some available to you.”
It assumes that more code in the world is an inherently desirable thing. In my thirty year career as a programmer, I have found this … not to be the case. Should you learn to write code? No, I can’t get behind that. You should be learning to write as little code as possible. Ideally none.
It assumes that coding is the goal. Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems. Don’t celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.