As a former computer science department chair, I have long felt the system for evaluating and promoting faculty is far too dependent on quantity and fails to account adequately for quality. So I applaud the Computing Research Association best practices memo Moshe Y. Vardi mentioned in his Editor’s Letter “Incentivizing Quality and Impact in Computing Research” (May 2015). However, more specific guidelines are needed for this initiative to be effective. I would urge all computing departments to inform candidates for assistant-professor positions their submitted CVs should list no more than three publications. Candidates must also be the primary author of at least two of them, meaning they were responsible for at least 50% of the intellectual content and at least 50% of the writing. On any other publication, the candidate would be considered a secondary author; yes, some papers may have no primary author.
I would go further. Faculty being considered for tenure should be permitted to list at most 15 publications and be a secondary author on at most five of them. Full-professor candidates should be permitted to list at most 25 and be a secondary author on at most 10. Also, in either case, candidates should be required to list three recent papers for which they are primary authors and on which they are to be explicitly evaluated.
These thresholds are meant as examples, not firm proposals. What is important is departments and research organizations send a clear message to candidates that CV-padding will not help their case for promotion and tenure.
To make evaluations of papers meaningful, they should be a written part of the hiring/promotion case. That is, for each paper to be evaluated, some expert in the candidate’s field should be asked to study the subject paper and write a substantive review. Many departments will be able to handle these reviews internally. Those lacking faculty with the requisite expertise could commission reviews from outside experts, possibly in exchange for a nontrivial honorarium.
Jonathan Turner, Sarasota, FL
Author’s Response:
The Editor’s Letter in question indeed suggested leading computing-research organizations sign a statement committing to adopt the CRA memo as the basis for their own hiring and promotion practices. Such a statement can be more detailed than the CRA memo.
Moshe Y. Vardi, Editor-in-Chief
Python for Beginners Here to Stay
It was refreshing to see Python discussed as a primary teaching language by Esther Shein in her news article “Python for Beginners” (Mar. 2015). The Python experience for introductory students at my college—Washington and Lee University—has been nothing but positive. We knew when we switched from Java to Python a decade ago that the language would offer the résumé value of widespread use in industry, as well as the pedagogical value of stepwise, stress-free introduction of programming constructs, from simple algorithmic code to the use and definition of functions, objects, and classes. Minimal syntactic “pixie dust” and support for safe semantics are the most critical features of Python for novices. The language is well suited to the kinds of short programs assigned in beginning courses while appealing to students with widely different backgrounds.
Excellent APIs are available for creating easy GUI-based Python programs in introductory courses (http://home.wlu.edu/~lambertk/breezypythongui/index.html) and for teaching data structures and object-oriented programming in a systematic way (http://home.wlu.edu/~lambertk/classes/112/).
When students learn the basic principles of programming with Python in these courses, they are ready to move on to the wider world of software development involving more challenging languages like Java, C, and Erlang. But for beginners, Python is here to stay.
Kenneth Lambert, Lexington, VA
Esther Shein’s news article (Mar. 2015) downplayed the robust nature of Python, perhaps in the interests of journalistic “balance.” But the word count dedicated to critique seemed misplaced in an article that might otherwise have presented more positive examples of use. For example, the repeated reference to Python as a “scripting language” was dismissive. Python is not only useful for scripting applications or OS functions but for industrial applications with tens of thousands of LOC. I once led a development team that wrote a robust Web transaction B2B infrastructure in Python that could handle individual database files with millions of records. It is still running two decades later.
Python is strongly dynamically typed, enabling it to handle flexible runtime situations efficiently. If a programmer wants the advantages of static typing, it can be bolted on using a preprocessor like “mypy,” an experimental optional static type checker for Python. A programmer could also use Python to implement automated testing, structured documentation, and other safe-coding practices. But doing so would be useful no matter what the language, and in any case goes beyond the target audience of “beginners.”
Shriram Krishnamurthi, the Brown University professor quoted in the article, complained Python has limited support for data structures. What it does have is built-in tuple, list, set, array, and dictionary types, and queues, b-trees, ordered dictionaries, named tuples; other functions are part of the standard library. Moreover, third-party libraries exist for every other imaginable situation. For custom-mixed data structures, Python lets programmers use a class. Krishnamurthi bemoaned their “onerous syntax and tricky semantics,” which might be a reasonable criticism when a programmer goes beyond trivial cases, but for simple structures a programmer needs only the “pass” command, as in the following example:
A novice can understand this code once the instantiation at line 3 is explained. It is hardly “onerous,” as Krishnamurthi claimed. From here, put and get methods, type checking, validation, and other functions can be added in an incremental way, an approach eminently suitable for beginners.
The problem of underestimating Python may involve bringing biases from one language into another. The lack of “struct,” or static types, does not make Python any less capable. It could do the opposite. There are certainly domains where some other programming language would be preferable. But Python is the language for the 99%.
Robin Parmar, Limerick, Ireland
Comprehensive Diligence for Information Security
Security specialists must address information security as precisely and completely as possible because clever adversaries use attack methods and vulnerabilities defenders have overlooked. Security must be comprehensive, as it is no stronger than its weakest link. Building security of information should start with formal models that address all known material weaknesses and security controls and practices. Though Johannes Sametinger et al.’s review article “Security Challenges for Medical Devices” (Apr. 2015) was excellent describing many potentially mortal threats and calling for formal methods and models to achieve security, it was only one more article demonstrating the weak and deficient fundamentals of information security. It said, “Security is about protecting information and information systems from unauthorized access and use.” Authorized but malicious access and use must also be addressed. Acts not mentioned include unintended representation, taking, interference, endangerment, failure to use, and false data entry. Privacy is indeed not a fundamental element of security but a human right achieved, in part, through protection of confidentiality, possession, integrity, authenticity, availability, and utility.
Sametinger et al. also said, “Confidentiality, integrity, and availability (CIA) of information are core design and operational goals.” Possession and control, authenticity, and utility are also needed to achieve security. They said, incorrectly, confidentiality is threatened by disclosure, integrity by altering data, and availability of devices by inoperability. Confidentiality is threatened first by taking or observing. Disclosure means somebody in possession reveals information to another person. Integrity, meaning whole and sound, is not necessarily threatened by altering data. Altering data threatens information authenticity.
Moreover, the article switched from information to devices threatened by loss of availability. What about when information is unavailable or unusable? Sametinger et al. are not to blame for such oversights since these conundrums are abundant throughout the information-security literature and even in laws and regulations.
The figure here is a formal diligence model I devised for reviewing the information security of more than 200 enterprise clients (http://www.cbi.umn.edu/) that comes closer than any article I know to describing the basic elements of information security.
I challenge Sametinger et al., as well as all Communications readers, to identify any significant detail I overlooked in this model at the same level of abstraction and within normal dictionary meanings of its words.
Donn B. Parker, Los Altos, CA
Authors’ Response:
Parker mentions the “… weak and deficient fundamentals of information security.” It is not the fundamentals that are weak and deficient but their execution. Devices could be much more secure. Parker is right there are aspects of security like authorized but malicious access we have not considered. For now, though, we would be happy to avoid unauthorized access and trust our cardiologist. We agree privacy is a human right, but some security measures are needed to avoid disclosure.
Johannes Sametinger, Jerzy Rozenblit, Roman Lysecky, and Peter Ott
Join the Discussion (0)
Become a Member or Sign In to Post a Comment