Posts tagged ‘programming languages’
C is Manly, Python is for “n00bs”: Our perception of programming languages is influenced by our gender expectations
Surprising and interesting empirical evidence that language use is mostly gender-neutral. Our expectations about gender influence how we think about programming languages. These perceptions help explain the prevalence of C and C++ in many undergraduate computing programs.
There is also a gendered perception of language hierarchy with the most “manly” at the top. One Slashdot commenter writes, “Bah, Python is for girls anyways. Everybody knows that PERL is the language of true men.” Someone else responds, “Actually, C is the language of true men…” Such views suggest that women might disproportionately use certain languages, but Ari and Leo found in their programmer surveys that knowledge of programming languages is largely equivalent between genders. Women are slightly more likely to know Excel and men are slightly more likely to know C, C#, and Ruby, but not enough to establish any gendered hierarchy.
I’m intrigued by this project and would really love to see some analysis. Do students who use Scratch recognize Sniff as being a text form of Scratch? If it doesn’t work well, is the problem in the syntax and semantics of Sniff, and maybe we could do better? Do students transfer their knowledge of Scratch into Sniff?
So if Scratch is so great why do we need Sniff? The problem is that at some point you need to move beyond Scratch. It could be that you want to tackle a different kind of problem that Scratch can’t handle well. Perhaps you’ve realised that graphical programming is a nice idea, and great way to start, but in practise its clumsy. Clicking and dragging blocks is a tedious and slow way to build large programs. It could be you need something that feels “more grown up” – the cat sprite/logo is cute, and even older children will find it fun for a while, but Scratch is designed to look and feel like a toy even though its actually very powerful. For whatever reason at some point you start to look for something “better”.
The ITICSE’14 paper referenced below is getting discussed a good bit in the CS Education community. Is it really the case that enhancing error messages doesn’t help students?
Yes, if you do an ineffective job of enhancing the error messages. I’m disappointed that the paper doesn’t even consider the prior work on how to enhance error messages in a useful way — and more importantly, what has been established as a better process. To start, the best paper award at SIGCSE’11 was on an empirical process for analyzing the effectiveness of error messages and a rubric for understanding student problems with them — a paper that isn’t even referenced in the ITICSE paper, let alone applying the rubric. That work and the work of Lewis Johnson in Proust point to the importance of bringing more knowledge to bear in creating useful error messages–by studying student intentionality, by figuring out what information they need to be successful. Andy Ko got it right when he said “Programming languages are the least usable, but most powerful human-computer interfaces ever invented.” We make them more usable by doing careful empirical work, not just tossing a bunch of data into a machine learning clustering algorithm.
I worry that titles like “Enhancing syntax error messages appears ineffectual” can stifle useful research. I already spoke to one researcher working on error messages who asked if new work is even useful, given this result. The result just comes from a bad job at enhancing error messages. Perhaps a better title would have been “An approach to enhancing syntax error messages that isn’t effective.”
Debugging is an important skill for novice programmers to acquire. Error messages help novices to locate and correct errors, but compiler messages are frequently inadequate. We have developed a system that provides enhanced error messages, including concrete examples that illustrate the kind of error that has occurred and how that kind of error could be corrected. We evaluate the effectiveness of the enhanced error messages with a controlled empirical study and find no significant effect.
Since states are making computing courses count as foreign language courses (even if that’s a bad idea), it’s worthwhile to consider what the value is of learning a foreign language. A recent Freakonomics podcast (linked below) considers the return on investment of learning a foreign language. Most intriguing is that people problem-solve differently in their non-native languages. I wonder what the implications are for programming languages? We know that people have negative transfer when their native language abilities conflict with their programming language problem-solving. Are there ways we could make the programming language better for problem-solving?
Learning a language is of course not just about making money — and you’ll hear about the other benefits. Research shows that being bilingual improves executive function and memory in kids, and may stall the onset of Alzheimer’s disease.
And as we learn from Boaz Keysar, a professor of psychology at the University of Chicago, thinking in a foreign language can affect decision-making, too — for better or worse.
Bertrand Meyer is making a similar point to Andy Ko’s argument about programming languages. Programming does matter, and the language we use also matters. Meyer’s goes on to suggest that those saying that “code doesn’t matter” may be just rationalizing that they continue to live with antiquated languages. It can’t be that the peak of human-computer programming interfaces was reached back in New Jersey in the 1970’s.
Often, you will be told that programming languages do not matter much. What actually matters more is not clear; maybe tools, maybe methodology, maybe process. It is a pretty general rule that people arguing that language does not matter are simply trying to justify their use of bad languages.
A really fun article, with videos of lots of classic Basic systems running.
Kemeny believed that these electronic brains would play an increasingly important role in everyday life, and that everyone at Dartmouth should be introduced to them. “Our vision was that every student on campus should have access to a computer, and any faculty member should be able to use a computer in the classroom whenever appropriate,” he said in a 1991 video interview. “It was as simple as that.”
Andy Ko made a fascinating claim recently, “Programming languages are the least usable, but most powerful human-computer interfaces ever invented” which he explained in a blog post. It’s a great argument, and I followed it up with a Blog@CACM post, “Programming languages are the most powerful, and least usable and learnable user interfaces.”
How would we make them better? I suggest at the end of the Blog@CACM post that the answer is to follow the HCI dictum, “Know thy users, for they are not you.”
We make programming languages today driven by theory — we aim to provide access to Turing/Von Neumann machines with a notation that has various features, e.g., type safety, security, provability, and so on. Usability is one of the goals, but typically, in a theoretical sense. Quorum is the only programming language that I know of that tested usability as part of the design process.
But what if we took Andy Ko’s argument seriously? What if we designed programming languages like we defined good user interfaces — working with specific users on their tasks? Value would become more obvious. It would be more easily adopted by a community. The languages might not be anything that the existing software development community even likes — I’ve noted before that the LiveCoders seem to really like Lisp-like languages, and as we all know, Lisp is dead.
What would our design process be? How much more usable and learnable could our programming languages become? How much easier would computing education be if the languages were more usable and learnable? I’d love it if programming language designers could put me out of a job.