Virtual Brown Bags
The Institute of Nebulous and Collaborative Intelligent Thought Evolution presents its bi- series on computing issues in the form of a virtual brown bag. Discussions take place on the slush@cc mailing list until we're tired of talking about the current topic. If you're interested in joining the discussion, go to this page
When the discussion finally dies away, feel free to unsubscribe.
The INCITE Research Group
INCITE Virtual Brown Bag: Internal and External Research
January 30, 2003
In physics and mathematics, the practitioners make a distinction between theoretical and applied practice. We could make a similar distinction between internal and external research. Both terms assume a particular area of knowledge of what is known and unknown in that area. External research is applied research. The knowledge and techniques in that area is applied to solving problems in another domain. Internal Research consists of solving those problems that are primarily theoretical and lie within that area of knowledge.
In Computing, an example of an external practice would be the application of data mining methods to discovering patterns in meteorological data. An example of an internal practice would be algorithmic or architectural improvements to the computing systems to produce a speed up in search methods that could be applied to data mining.
There are some dangers with a field becoming too external or too internal. Areas that look solely at internal problems have the danger of ceasing to be externally relevant similar to the way that jazz musicians in the 1960s began to play only for each other, almost causing jazz to become an obscure artform by the 1970s. Areas that only look at external problems cease to be a research area and become engineering areas because they only build solutions to immmediate problems and not metasolutions to classes of problems.
For the Virtual Brown Bag, we'd like to address the following:
- Do you believe your discipline or sub-area of research to be internal or external?
- Do you believe that your discipline or sub-area of research is properly situated or needs to be more internal/external?
- Where should computer scientists be looking for problems to maintain the proper balance between internal and external practices?
INCITE Virtual Brown Bag: Code Reading
March 5, 2003
Experienced programmers or even programmers who have some familiarity with writing code can easily distinguish bad code from good code. Good code is not just logically and algorithmically precise but also possesses clarity of expression and organization that permits other programmers to read,understand, and maintain the code long after the author has signed off on it.
The lessons that teach the elements of spoken and written language, native or foreign, are designed to convey the mechanics of grammar, vocabulary, syntax, and structure. They are often accompanied by readings in literature written by the influential authors in that language across the history of that language. These two learning tracks impart the skills and basic building blocks and also present students with the best examples of works so that they develop the aesthetic sense for stylistic expression. Programming languages have much of the expressive power and complexity of spoken languages. Writing in these languages has the additional mathematical constraint of algorithmic correctness and precision. Most classroom time is spent teaching the primitives of language usage but tends to overlook the stylistic and organizational techniques that can structure its expression.
Producing better programmers from a curriculum requires that students understand not only the atomic constructs and algorithms but also correct style and code organization. We propose that a class in code reading may be the solution to this.
This Virtual Brown Bag presents the following questions for discussion:
- does code have the level of expressibility that permits individual style or is all code simply reducible to a minimal and optimal set of strings and symbols that match a readability criteria?
- what are the aesthetic characteristics of good code?
- what are the skills required to be a good code reader / writer?
- who are the Shakespeares, Hemmingways, Fitzgeralds, Twains, and so on of the programming world? Obviously, we think of Knuth but who are the other role-models?
- are there benefits to reading across all the generations of programming languages?
- are there classic code fragments that everyone should know? (Like quoting Kipling or Shakespeare)
- are there readily accessible large system-level examples (programming "novels") that students should read?
- what would a class in code reading look like? What would the learning objectives be?
INCITE Virtual Brown Bag: Reconceptualizing Computer Science
August 30, 2004
In 1961, Feynman was at Caltech when he was asked to revise the freshman level course on physics. Feynman decided that the problem with the current curriculum, and indeed all similar curriculums in physics to this day, is that they began with the wrong sets of knowledge and potentially caused students to develop the wrong intuitions about physics. He reformulated his class beginning with the fundamentals - what are atoms, what is physics, what is energy, what is time and distance? what is gravitation? He taught Newtonian mechanics but follows it up immediately with relativity - which replaced the Newtonian viewpoint. In a normal curriculum, Newton would be a class after electromagnetism. Feynman took everything he knew about physics and organized it into a coherent curriculum that placed every area of study into an organized context and built on each other as they were presented.
Although the Feynman lectures were elegant in design and eloquently delivered, they were bloody hard. It wasn't just the mathematics but Feynman's requiring a high level of mental intuition and visualization from his audience. Feynman's Nobel prize work - his diagrams and his models of quantum mechanics developed out of his intuitions and models of electron motion at the quantum level. A colleague remarked that Feynman probably began by asking himself, "If I were an electron, how would I behave?" Freshmen dropped out like flies and soon there were only Feynman's colleagues and graduate students in physics in attendance, furiously scribbling down Feynman's words and taking pictures of everything they could. The resulting books - Feynman's lectures of physics - have become famous textbooks for their scope and command of physics and also for their impracticality as textbooks for physics students.
The thought experiment that I've been considering for a few years concerns our own field, nominally named "computer science" but often being more engineering than science. Knuth wrote and is writing his own textbooks to encompass the scope of algorithms in computing but those seem more like reference books than usable textbooks. Linguistics aside, the question is if we were to perform a Feynman-like act and reorganize all knowledge in computer science into a freshman-level course with the intent of producing someone ready to specialize, what would we teach? What would the curriculum look like? Can algorithms and programming be taught together? Should software engineering be an organizing context? Or, if we were to be radical and to re-engineer computer science into an actual mathematical science, what would we need to teach to produce people who can study the phenomena of computing with an experimental or empirical viewpoint at the end of the process?