March 27, 2014
Andy Ko wrote a recent blog post with an important claim: "Programming languages are the least usable, but most powerful human-computer interfaces ever invented" (http://bit.ly/1iVxF3A). Andy argues the "powerful" part with points about expressiveness and political power. He uses HCI design heuristics to show how programming languages have poor usability. Obviously, some people can use programming languages, but too few people and with great effort.
I see Andy's argument extends to learnability. There are two ways in which programming languages have poor learnability today: in terms of expectancy-value and in terms of social cost.
Eugene Wallingford tweeted a great quote the other day:
"Think back to before you understood closures. I'm sure you couldn't even imagine it. Now imagine them away. See, you can't do that either."
Educational psychologists measure the cognitive load (http://bit.ly/1lSmG0f) of instruction, which is the effort a student makes to learn from instruction. Every computer scientist can list a bunch of things that were really hard to learn, and maybe could not even be imagined to start, like closures, recursion in your first course, list comprehensions in Python, and the type systems in Haskell or Scala.
Expectancy-value theory (http://bit.ly/1sctSGD) describes how individuals balance out the value they expect to get from their actions. Educational psychologists talk about how that expectation motivates learning (http://edcate.co/1iefV80). Students ask themselves, "Can I learn this?" and "Do I want to learn this? Is it worth it?" You do not pursue a degree in music if you do not believe you have musical ability. Even if you love art history, you might not get a degree in it if you do not think it will pay off in a career. Most of us do not learn Dvorak keyboards (http://bit.ly/1jvaFNC), even though they are provably better than Qwerty, because the perceived costs just are not worth the perceived benefit. The actual costs and benefits do not really play a role here; perception drives motivation to learn.
If you cannot imagine closures, why would you want to learn them? If our programming languages have inscrutable features (i.e., high cognitive load to learn them) with indeterminate benefits, why go to the effort? That is low learnability. If students are not convinced they can learn it and they are not convinced of the value, then they do not learn it.
I was at a workshop on CS Education recently, where a learning scientist talked about a study of physicists who did their programming in Fortran-like languages and only used arrays for all their data structures. Computer scientists in the room saw this as a challenge. How do we get these physicists to learn a better language with a better design, maybe object-oriented or functional? How do we get them to use better data structures? Then one of the other learning scientists asked, "How do we know that our way is better? Consider the possibility that we're wrong."
We computer scientists are always happy to argue about the value of one programming paradigm over another. But if you think about it from Andy Ko's usability perspective, we need to think about it for specific users and uses. How do we know that we can make life better for these Fortran-using physicists?
What if we convinced some group of these Fortran-using physicists to move to a new language with a new paradigm? Languages don't get used in a vacuum; they get used in a community. We have now cut our target physicists off from the rest of their community. They cannot share code. They cannot use others' libraries, tools, and procedures. The costs of learning a new language (with new libraries, procedures, and tools) would likely reduce productivity enormously. Maybe productivity would be greater later. Maybe. The value is uncertain and in the future, but the cost is high and immediate.
Maybe we should focus on students entering the Fortran-using physics community, and convince them to learn the new languages. Learning scientists talk about student motivation to join a "community of practice" (http://bit.ly/1kDIhFJ). Our hypothetical physics student wants to join that community. They are learning to value what the community values. Trying to teach them a new language is saying: "Here, use thisit's way better than what the people you admire use." The student response is obvious: "Why should I believe you? How do you know it's better, if it's not what my community uses?"
Communities change, and people learn. Even Fortran-using physicists change how they do what they do. The point is that we cannot impose change from the outside, especially when value is uncertain.
The answer to improving both usability and learnability of programming languages is in another HCI dictum: "Know thy users, for they are not you." We improve the usability and learnability of our programming languages by working with our users, figuring out what they want to do, and help them to do it. Then the value is clear, and the communities will adopt what they see as valuable.
April 8, 2014
As an undergraduate student studying, say, computer science, what are some of the practical benefits of working in a research lab? I can think of three off the top of my head.
At a high level, working on research is awesome because you get a chance to preview and invent the future. In classes, summer internships, and most fulltime jobs you will get after graduation, you are either studying the past or doing work that will be immediately used in the present or near future. In industry, the main priorities for junior employees such as yourself are to deliver projects with near-term value in the coming week, month, or year. Only in a research lab can you prototype high-risk ideas that are five, 10, or even 20 years ahead of the state of the art in industry.
Sure, every individual researcher gets to work on only a small, specialized part of a bigger research problem. But just getting the chance to participate is an interesting opportunity. One of the main purposes of college is to expand your intellectual horizons, and hands-on experience in a research lab is a good way to do so. The broader ideas you will be exposed to in a research lab might transfer over to your future professional life in unexpected ways, even if you do not end up working in the same subfield.
A more concrete benefit of doing research is the chance to rapidly improve your technical skills in a realistic setting outside of the classroom. I became a much better programmer and scientist throughout my three years of assisting on research projects as an undergraduate student. I had to learn new programming languages, libraries, tools, and technologies on-demand to meet project requirements. This sort of hands-on knowledge cannot easily be taught in textbooks or classes, since it requires an authentic setting where people are doing real work and not just preset exercises with known results.
If all works out, working on research will feel like a super-intensive yet satisfying lab class where you complete an innovative project that you are proud of. You will also get to practice writing up and presenting your work to an audience, which is great training for many kinds of jobs. You might also get credited as a co-author on a published research paper, which is important if you want to pursue a Ph.D. in the future. And best of all, since you are working as an apprentice, you usually get one-on-one mentorship from a more senior researcher. This sort of personalized interaction rarely happens in even the smallest and most intimate of university classes.
One final benefit is the potential for professional advancement. If you do compelling work, then your research advisor can write recommendation letters and make personal referrals for you to get either a good job in industry or admitted into graduate school. These letters and referrals are a lot more meaningful than having a high GPA or a professor mentioning that you got an A+ in their class. My own undergraduate research advisors helped to kick-start my career in significant and often unexpected ways. In contrast, professors who taught my classes don't really remember me, since I was one of hundreds of students they saw each year in large lecture halls.
(This blog post was adapted from my undergraduate researcher recruiting article at http://bit.ly/1kFMOc9.)
©2014 ACM 0001-0782/14/07
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from firstname.lastname@example.org or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2014 ACM, Inc.