Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
R. Steven French
3rd year CS major . . .
well, actually this is my second|last chance at school.
I graduated high school near the top of my class and majored
in what laypeople call 'recreational pharmecuticals'.
A little Haiku is in order:
Eating sheets of 'cid,
Now I'm shooting for grad school,
Which is more insane?
An empirical comparison of C, C++, Java, Perl, Python, Rexx,
and TCL for a search/string-processing program
This paper explores the implementation of a small program named phonecode, which encodes telephone numbers into a neumonic from a supplied dictionary. Many implementations were submitted in the languages listed above, and several metrics were used to determine valid, QUANTITATIVE comparisons between the languages. More specifically, the languages were grouped into "scripted" and "non-scripted" domains in the obvious manner.
There are many interesting results in this study, of which a sampling thereof will be discussed here. The first of these is the
resultant probabilistic models of run-times between the languages. As expected, the C/C++ family of languages tend to be faster, but only 1.22 times faster than Java and 1.29 times faster than scripted
languages (on a 80% confidence interval). Differences between script run times and Java run times are statistically insignificant.
The next interesting result involves the ratio of code to commenting. Scripting languages seem to have far less "code" and far more "comment" density than either Java, C, or C++. At the same time, scripting languages were found to being significantly smaller in size (lines of code) than the other programs.
A less empirically sound conclusion of this paper, validated by Capers Jones' Language Lists and Function Points (in the spirit of the axiom stating "the number of lines written per hour is independent of the programming language") is that development time in a scripting language takes much less time than in other languages, given the same problem, with statistically similar rates of reliability.
The summary of Luis F. Cruz, citing this paper, states that the C/C++ languages provide fast performance. This is, of course, true; however, the power of scripting languages provide near equal speed of execution while substantially reducing development time for quality software by a factor of roughly 1/2 to 1/3.
1. How do design patterns and a pattern languages differ? What is the use of each?
Pattern languages are a composition of various design patterns for the purposes of providing an abstraction for a framework to solve a generalized problems. This includes methods to enumerate possible uses and combinations of the design patterns contained within it. A key trait of successful pattern languages is the ability for the language to be generative: the language should be capable of describing not only solutions for known problems, but it should also have the capacity to describe the solutions of future problems, using its own grammar and lexicon.
Design patterns are more like atomic components which describe a commonly occurring solution, best utilized to describe more specific implementation issues. However, the pattern itself should be generic enough to solve other, unforeseen problems. A design pattern should be code agnostic: it describes a methodology to describe a possible solution within a problem space. Many of these patterns, when combined with a grammar to describe problems, constitute a pattern language.
Describe one design pattern or pattern language in your own words. Again, reference your sources. Explain what interests you about this pattern. Does it make sense to you? Can you see using it in your coding? If so, what for? If not, why not?
The Observer Pattern consists of one “observer” class and one or more “observed” classes. The observer is linked to each of the observed classes. If there is a state change in one of the observed classes, the observer is notified. Upon the notification of a change, the observer sends messages to all the observed classes in order to update them. The interesting thing about this pattern is that any updating that must be done to any involved classes is triggered from a central class with no interaction between the observed classes being necessary. This reduces the complexity and amount of code, since each class could just contain an update method that is triggered by the observer class. Further, this makes sense in the object oriented paradigm: since it is possible that the observed classes can have no knowledge of each other, it reinforces good object oriented design by minimizing unnecessary connectedness between the observed classes.
This would be of great utility in our SqueakPoint project. For example, when a user changes a template or modifies the length of some text, an observer class could notify all the components of the page of the changes, so that they could modify themselves accordingly.
Part 1: Describe a feature of Squeak that I found particularly useful.
I found code completion to be greatly helpful. There really should be a nice, obvious place to know how this (and other key commands) are invoked. Maybe there is, I just didn’t find it. Can’t remember the exact name of the message you wanted to invoke? Are you pretty sure it started with bullsh__? I can’t recall where I read it, but if you type -Q (on Windoze boxes), you can see the messages that could be invoked. Bullsh__ becomes bullshifter: or bullshackles: or bullsh1t: with: . It gives you a new message everytime you type the command, until you have exhausted them all. Using this with the method browser and the class browser greatly sped up the time it took for me to get acclimated in Squeak.
Part 2: Other useful pages from students:
Vinayak Kashyap's page on the hierachy view explains perfectly well why this is a useful tool in Squeak. I myself have begun using the heirarcy view very often, now that It was been explained by Vinayak. It makes subclassing (and using methods of the superclasses) as easy as possible.
Peter Budny's page describing the utility of the inspector should not be overlooked. In fact, it is quite possibly the most useful tool to explore morph interactions and interdependencies between each other and the world they inhabit.
Almost certainly this question will ensure you understand MVC (as a programming paradigm–not a smalltalk GUI toolkit). I won't ask you to code a PluggableTextMorph from memory. It would be useful to know what pluggable components are, how they are used. How do these "canned" buttons know what to do when they are pressed? How does a text morph know what text it is supposed to display? You should be able to answer these questions in light of the MVC philosophy.
Essentially, MVC is a fairly strict separation of objects into three main domains: the model, the view, and the controller. Of the three domains, the model is the object that provides the abstractive “model” or approximation of the system the program was designed to mimic. The “view” is simply one or more visualizations of this model, as presented to the user. The view does not have to be all inclusive: only the aspects of the system that need visual representation for a particular user need be displayed. The only internals about the model that the view need be concerned with are: what data should be displayed and, of that data, what has changed such that it should be redrawn. To effect change in the system, the user interacts with the view (more specifically, the UI or GUI) which sends messages to the controller, which updates/modifies the state of the model, which sends changed messages back to the view to update any displayed data.
In Squeak, pluggable morphs provide a standard framework to implement MVC, albeit without strict class separation. PluggableBlaBlaBlaWithModel classes are self contained widgets. The “model” is usually self, and the view and controller are also part of the class. It still emulates MVC, as there are changes, messages to store/hold model data, and the morphic framework for control, but again, they are all contained within the same class. In fact, MVC with total class separation is all but impossible in Morphic, as the view and the controller (and sometimes the model) are intimately tied to one another.
Link to this Page