These notes are also available in PDF.
Rebelsky, Samuel (2007). Representing Images: Points, Lines, and Beyond. Web resource
http://www.cs.grinnell.edu/~rebelsky/Courses/CS302/2007S/HOG/representing-images.html (last modified 4 February 2007; visited 4 February 2007).
Over Winter break I talked with a person who was a software engineer and they mentioned design patterns. He described them as the next step after object oriented programming. While his claim may be debatable, how much support is there in languages for design patterns and what exactly are they? Is the functional approach more easily able to make use of design patterns?
Design Patterns are a way of thinking about common programming problems. Although they were designed by the object-oriented programming community (more precisely, a group of four or so leaders of that community). In some sense, they can be implemented in any category of language, but fit most logically in the object-oriented paradigm. However, there are some claims (one of which I think you'll see in Graham) that many of the design patterns are inherently part of the functional paradigm (in the sense that you don't need to add baggage to get them).
I understand that identifying and remembering common techniques for solving programming problems can be useful. In some languages, these patterns are simply guides to programmers as they design new solutions. In other languages, such as Scheme, you can encode a design pattern in a separate procedure. What are some of the other languages that allow you to do that?
Certainly any functional language allows you to do that. I'm pretty sure that Smalltalk lets you do so. I haven't played enough with Ruby or Python, but there's a chance that they do.
Next, the map procedure looks certainly useful, for example when we are building compound structures. what are some of the disadvantages to using map and why isnt it a standard procedure is more languages if it is very useful?
Well, map does build a new structure, which some folks consider inefficient. Most languages don't have functions as first-class data types, so it doesn't really make sense to provide something like map.
Whereas defining a new function with the same name with an existing one (such as the map function redefined in the last section of the reading) makes the programmer's work easier in some cases, doesn't it allow for mistakes for large projects? For example, if a programming team is working on a large project each writing different functions, confusion can arise when one programmer redefines common scheme functions such as map that another programmer uses without the knowledge that the function has been redefined. For example: (define + -) could compromise all functions that use the + operator. Is there a reason for giving 'Schemers' this much power?
You know, I'm not completely sure why they've added that power to
the language. I expect that it's an issue of
trusting the programmer.
That is, good naming conventions will prevent overlap of names, and good
programmers will follow the conventions without having to be restricted
by the compiler. And, hey, there may be times that it's helpful to change
the behavior of a
The more I see higher-order programming the more it reminds me of the problems of the goto statement. Looking at the example, "(define drawing? (left-section list-of? list-of-points?))", I feel like one could spend a long time debugging the code if there was a problem. Checking each procedure call to see where a violation occurred could potentially become very tedious in higher-order programming as one has look throughout the program for errors instead of looking specifically at the procedure the error originates from. In this example, one would have to look at left-section, list-of?, list-of-points?, another call to left-section and list-of?, and finally point? to debug the code properly. Do you think this is a potential problem in higher-order programming? Can concise code sometimes cause more problems than it solves?
I don't really think it's any more (or any less) of a problem than nesting procedure calls or nesting data structures. In general, if each procedure is designed and implemented correctly, combining them should not be a problem. (True Schemers would claim that each procedure is small enough that it's more likely to be correct, so you won't have problems when you combine them unless your combination logic is wrong.)
The reading covers translating, varying and scaling drawings, I was curious about how you would go about creating layers with script-fu?
Because I want this stuff to be for novices, I haven't worried about layers. However, it's not all that bad. There's a new layer procedure, which you can find the details of in the Script-Fu online reference.
It was interesting to see various stages through which the idea of representing images developed and with it the transformation from imperative to functional implementation of a function. Can we design a Computer Science departpment logo using these functions, or any any logo for that matter?
Yes, I suppose you could, but you have more artistic talent than I have. It would be nice to have a curve function, though. (And yes, I do plan to get it working better over the summer.)
(xcoord scaled) = (* (xcoord pt) scale-x) (ycoord scaled) = (* (ycoord pt) scale-y)
I don't understand this. Why is this scaling? It seems just to move the x and y coordinates but each pixel is not copied by the specific times to become larger.
Yes, it does not scale a point, but it doesn't make sense to scale a point. However, if we scale all the points in a line by this way, we effectively scale the line by that amount. (Similarly, scaling all the points in a drawing scales the drawing.) I guess the reading needs to make this a bit clearer.
Script-Fu passes by value. To use script-fu to do drawing, will we encounter memory overflow very quickly?
No. Script-Fu, like every other Scheme implementation, is garbage collected. Images are also represented by pointers (or the equivalent), and passing ap ointer by value incurs very little cost.
One of the things brought up by the story of Mel is the amount of control a programmer has over the procedures that they are calling. It seems like by having pre-defined images like 'tree' you make it possible for the programmer to create images without knowing much of anything about what they're doing. So the question is, if you can generate images just by calling a few basic procedures knowing only how those work, where does the art of programming come in?
There are certainly lower-level things one can do. One might also note that not all programming has to pay attention to low-level details. But you are right, we lose some of that kind of art.
I usually create these pages
on the fly, which means that I rarely
proofread them and they may contain bad grammar and incorrect details.
It also means that I tend to update them regularly (see the history for
more details). Feel free to contact me with any suggestions for changes.
This document was generated by
Siteweaver on Sun Apr 29 11:27:48 2007.
The source to the document was last modified on Thu Feb 8 20:39:57 2007.
This document may be found at