| Important Messages from the Instructors
Friday, December 11th, 2009
The End
This is the end of Bootcamp. You struggled with the material, you lost
sleep over problem sets, you coped with a random partner, and you tried to
justify your design in front of harsh critics. You survived and,
hopefully, you learned something. Indeed, it is my sincere hope that you
will remember this time as a harsh but productive immersion into
techniques that can help you in many situations. I hope you do, and so do
we all from the Bootcamp staff. Good luck with the rest of the MS program
and your co-ops.
The rest of the course works like this. Sometime over the weekend you will
receive your list of grades in your email. If you find that any of these
grades are wrong, please send email to Stephen Chang, who will discuss
change requests with the rest of the staff as appropriate. By Tuesday, we
will sit down and make up final grades (anonymously) and upload them into
the registrar's database by the end of the week.
Friday, December 11th, 2009
Just in case you wish to remember the 10 things you could have learned, I
have put the lecture notes from this last week on-line.
In addition, you can find two distinct solutions for problem 12-1 on line:
one
that is squeezed into the abstraction schema for itemized data definitions
(see lecture 12)
another one
that creates a wider hierarchy and makes intelligent use of abstract
classes.
Monday, December 7th, 2009
Tomorrow (Tuesday, 8 Dec 2009), Prof. Felleisen won't have office hours.
Also tomorrow, only the 3:30-5:30 drill club will take place. The second
drill club (5:30-7:30) is canceled.
Monday, December 7th, 2009
A student asks
"Assignment 12 asks us to convert the solution into complete class-oriented solution.
Does this imply that we have to implement the (listof X) also as a class?"
The answer is no. Just replace the global main function from
problem set 11 with a call to the expression
(send (new sis%) go)
Saturday, December 5th, 2009
Here is one more comment from the panel. Suppose you need a method that
switches a traffic light from one color to another:
(define traffic%
(class object%
...
;; String -> Void
;; purpose and effect: change current-state to s
(define/public (switch-to s) ...)
...)
The use of built-in data definition
String is, of course, wrong here. You must supply
a data definition that restricts the input to switch-to
appropriately:
;; A TC is one of:
;; -- "red"
;; -- "green"
;; -- "orange"
;; -- "blue"
(define traffic%
(class object%
...
;; TC -> Void
;; purpose and effect: change current-state to s
(define/public (switch-to s) ...)
...)
Otherwise a future reader will not know which strings are legitimate
inputs to switch-to and which ones aren't.
Friday, December 4th, 2009
Here are the key insights from this week's code walks:
-
You must respect the design recipe, even though we have moved on to
classes (e.g., data definitions as classes need interpretations; examples
and tests are designed before methods; random methods need different kind
of testing).
-
You must formulate two kinds of tests for imperative methods: concerning
things that change and concerning things that must remain the same. See
blog post from last week.
-
You must allocate functionality appropriately. For example, when you
discuss a tank firing shots, you should immediately imagine a function
with this kind contract:
;; Tank -> Shot
And this kind of contract tells
you to which class the method belongs. If you instead add a method to the
"state of the world" class that uses selectors/getters, you clearly missed the
point of the course, which tells you to organize your data around problem
structures and to design your functions around these data definitions.
Finally, you must implement criticisms of your code from the panels. If
you don't, we know that you failed in another key aspect, namely, the goal
of learning to communicate (which includes listening) about code.
You have one more chance to demonstrate that you can explain code and
listen to criticisms of your code.
Wednesday, December 2nd, 2009
Problem set 12 had accidentally switched the order of problems. It is fixed
now. Sorry for any inconveniences.
Tuesday, December 1st, 2009
Just to clarify, you are welcome to use local for computing
local variable bindings, e.g.,
(define/public (distance x1 y1)
(local ((define xdelta (- x1 x))
(define ydelta (- y1 y)))
(sqrt (+ (* xdelta xdelta) (* ydelta ydelta)))))
in my lecture notes.
In case you need to do so, you may initialize super-variables as follows:
(define a%
(class object%
(init-field x)
(super-new)))
(define b%
(class object%
(init-field y)
(super-new [x (some-function y)])))
This is perfectly legitimate.
Tuesday, December 1st, 2009
The lecture notes from Monday night are now available on-line.
When you design object-oriented programs in the Module language, do not
use local to define functions. Even if you succeed to process
objects in such functions, these definitions are unjustifiable and will
therefore result in huge point losses during code walks. -- You
may of course use lambda to create functions for processing
lists.
When you develop examples/tests for imperative methods in stateful
classes, you must create each test so that it stands on its own. It must
not rely on the execution of previous tests and it must not affect
subsequent tests. Here is a skeleton example:
(check-expect (local ((define o (new some-class% ...)))
(begin
(send o change-yourself)
(send o reveal-something-about-yourself)))
expected-values-possibly-lists)
And don't forget to formulate tests for the same sequence of
commands that shows that no unintended properties of the object change.
(With lists you could formulate a single test for this, but it is
acceptable to use two unit tests instead to separate the concerns.)
The topic of tail-call optimization was recently discussed by Guy Steele
on
Sun's
Fortress blog. Recall that Steele is the person who developed
Scheme and co-specified Java. His latest language, Fortress, is an attempt
to create a highly parallel successor to Fortran with modern OO features
and lessons learned from decades of language design. Enjoy!
Monday, November 30th, 2009
The 12th and last problem set has been released.
Wednesday, November 25th, 2009
I have corrected a small typo in problem 10-1.
Problem set 11 has been released.
Happy Thanksgiving!
Tuesday, November 24th, 2009
Prof. Wand writes: The working version of 10-worm-imp-wand.ss is now up on
the examples directory (Lectures/Wand). There were just a few changes
after class, which are clearly marked. You should look at these carefully
to understand what went wrong and how it was fixed.
Tuesday, November 24th, 2009
Christos asked me to respond to some questions from the drill club on the
blog. Here we go:
-
You may continue to assume the existence of built-in data definitions
such as Number, String, Boolean, and those from the Universe teachpack
(KeyEvent, MouseEvent, etc). If you happen to need sub-collections of
those, make a special-purpose data definition and use as before. --
You may even use
[Listof X] for a defined X
in your code. -- For everything else, you will need a class-base data
representation.
-
You should not need any plain functions for problem set 10, except for
local (lambda) functions in case you use a
list iterator
(e.g., map, fold, etc.). In case you need a
novel operations on lists, break the rules. (I can't think of such an
operation.)
-
You may define global constants and global graphical constants. You may
also define local fields that are constant, which is preferable.
-
You must not use any other superclasses than
object%. This
topic hasn't been covered yet, though we will do so on Monday.
-
Don't even think of changing code that we provided. So yes, this leaves
you with one global function in your program, which we provide.
Tuesday, November 24th, 2009
My notes for lecture 10 are on-line in raw
form. Read with caution, experiment especially with the list code for
Scheme/Java classes. Design an accumulator-version of length
and stress-test it, too.
For problem sets 10 and 11 (to be posted tomorrow), you must use a
class-oriented design. Packaging your functional solution in one big and
single class isn't it. You will get a 0 for that, even if your functional
solution got a perfect grade. Also, don't use other features than those
mentioned in the tutorial on Classes (see tab) and the lectures. For
example, if you need access to a field, add a selector method to the
class.
Sunday, November 22nd, 2009
Problem set 10 is a preliminary version of problem set 11. We will neither
collect nor code-walk the results.
Saturday, November 21st, 2009
While HtDC uses the ProfessorJ programming language(s) to present design
concepts in an object-oriented world, you must solve all
homework problems in the Module language using its class system and you
should solve all drill problems in this language, too.
(If you have written acceptable solution in "applicative" ProfessorJ/Java
for the drill problems, we may accept you for drill club this week.)
Friday, November 20th, 2009
Ms. Raafia found out that I had once again used DrScheme v4.2.3 (svn head)
instead of v4.2.1 to prepare the homework assignment. See corrections in
10-2.
Friday, November 20th, 2009
Several people have asked about "letter grades". At this point, it is
simply too difficult to give you an accurate estimate of your letter
grade, especially since the last three assignments carry a relatively
heavy "point weight". Recall though the general guideline for grades in
this kind of course (briefly discussed in the first lecture): the cut-of
for A-level grades is somewhere between 85% and 90%; for B-level grades it
is between 70% and 75%; for a C you will need at least 60%. Also keep in
mind that we will drop the score that affects your grade most
negatively. You may wish to design a program to determine this grade,
because it isn't necessarily the lowest score (in absolute numbers).
There will be no other discussion of final grades.
Others have sent inquiries concerning the final schedule. As you can see
from university's schedule and previous blog post, there will be 12
(twelve) homework assignments and the last code walks will take place on
December 10 and 11.
Tuesday, November 17th, 2009
An email exchange from today:
On Nov 17, 2009, at 4:38 PM, someone wrote:
Dear prof.,
The protocol review before the assignment really helped us to get
stared with the assignment. I would totally recommend this kind of
practice for all the assignments. It gives us the initial view of how
to proceed with the assignment in right direction.
Thank you.
Here is the reply:
Thanks but you realize that one goal of this course is to empower you to
develop such data representations on your own. In principle, you should
learn this at the undergraduate level and we teach this in the first year
courses and reinforce it later. If we reviewed all of these definitions you
wouldn't appreciate the difficulties and you wouldn't learn to do things on
your own.
Pain is sometimes needed to learn things, and only people who can take pain
can learn. -- Matthias
Tuesday, November 17th, 2009
Some of you have asked whether paper-and-pencil art is appropriate in lieu
of ascii art for the interaction diagram. I must admit that drawing the
diagram for the "chat room" assignment in my favorite text editor (Emacs)
took me some five to ten minutes and didn't pose any serious problem. So
here is the deal:
You are welcome to bring along a hand-drawn interaction protocol. It will
cost you one (1) point out of a total of 40 to 45 points.
Note though that if we find a violation of the interaction diagram by your
code, it will cost you a lot more one point.
Tuesday, November 17th, 2009
Last night, I demoed the state feature in universe for
monitoring the changes to the state that your client and/or server program
experiences. This feature is only available in DrScheme v4.2.2 and
up. Since your solution must run in DrScheme v4.2.1, I
recommend that you upgrade only if you encounter a mistake that you simply
cannot cope with other than using state. If you do upgrade
temporarily, you will also have to change calls to error to take one string
only. (I use the cutting edge non-released version so that someone
exercises everything all the time.)
Tuesday, November 17th, 2009
Ms. Raafia discovered another flaw in the docs for the universe teachpack,
which was eliminated quite a while back. (We release every two months, and
we build the software, including the docs, every night.) It is probably
best if you use
the online pre-release documentation
Doing so guarantees that you get to see all the fixes and you don't have to
guess what's right or wrong. (Typos, like errors, happen; it's critical
that you deal with them quickly.)
Tuesday, November 17th, 2009
My notes for lecture 9 are on-line in raw form. Read
with caution, experiment with gusto. As you will see, I skipped the
non-essential 'design2.ss' exercise. It's boxed in the lecture notes. Try
it for yourself, then read my solution.
To fit with the actual assignment schedule, I have swapped the reading
assignments for the last two weeks of the lecture schedule. Since nobody
has read anything so far anyway, this won't be an imposition.
Monday, November 16th, 2009
Ms. Pratibah and Mr. Baturalp discovered a bug in the documentation for the
universe teachpack. The text accompanying on-disconnect was
wrong. Here is the improved version:
(on-disconnect dis-expr)
dis-expr : (-> UniverseState iworld? bundle?)
tell DrScheme to invoke dis-expr every time a participating world drops its
connection to the server. The first argument is the current state of the
universe server, while the second argument is the (representation of the)
world that got disconnected. The resulting bundle usually includes this
second argument in the third field, telling drscheme not to wait for
messages from this world anymore.
Monday, November 16th, 2009
You are welcome to change your protocol (interaction diagram, message
representation, server and client data definition) if you encounter
difficulties with the chosen protocol and/or if you realize that a
change may improve your design.
The purpose of the protocol review was to ensure that you got started in
the proper direction. If you believe you can benefit from a second review,
feel free to check with a TA. It is unnecessary, however, to get the
changes approved.
Saturday, November 14th, 2009
Your solution for homework 9 should be a single file, placed into the
appropriate directory and named accordingly. You should organize your file
like this:
-
section 1 (labeled "protocol") should contain the interactions diagram in
ascii art, plus the data definitions for your server-to-client and
client-to-server messages;
-
section 2 (labeled "server") should contain all definitions for the
server code, including a function for starting up the server; and
-
section 3 (labeled "client") should contain all definitions for the
client code, including a function for starting up the client.
Use 'large letters' to label the sections so that we can use the contour
view to navigate the solution. Use at least two instances
of drscheme to run the program after you have
completed the design. (By now you should know that this sentence
means "tested without access to the network".) One drscheme runs the
server code from the above file, the others run client codes. For fun, you
may also consider running the program across the NEU/CCIS network or a
network in your apartment.
Friday, November 13th, 2009
See revised problem statement for 9.1.
A solution for problem 8.2 is now available,
and we urge you to study it carefully.
On recursion: during the last lecture, someone
stated that a program was slow because it was recursive. In response I
gave you a "lecture" on the lack of basic knowledge on the connection
between proper program design and the implementation of function
calls. Just in case it isn't clear, this lecture was directed at your
undergraduate programs in computer science not at you personally.
As you should know by now, recursion in functions exists because the data
definition is self-referential or because you had an algorithm idea
(generative recursion). Since this connection cannot possibly disappear if
we wish to design systematically, you need an explanation of recursive
function calls. You already know what to tell a recruiter who asks why you
would want to use recursion.
In order to provide you with a proper understanding of this topic, we will
insert two short lectures on the nature of function calls and recursion.
These lectures should help you overcome the wide-spread preconception that
"recursion is slow". They will also equip you with the knowledge to argue
with recruiters, just in case they don't know their basic cs history
either.
Wednesday, November 11th, 2009
FAQ 8-2: All external urls are missing urls because "the creator of a site
doesn't have control over the rest of the Web". Do keep in mind that this
could be considered an ambiguity and any non-trivial
resolution would be considered perfectly correct.
Messrs. Shah and Mehta requested a new feature for more-io.ss--stripping
unnecessary white space from href specifications--and I have added
it. This will make your program a bit more useful, but it won't affect
code walks of course.
Tuesday, November 10th, 2009
Armin Galliker discovered an error in the more-io teachpack. Specifically
the function url-html-neighbors did not analyze the entirety
of ill-formatted (non-XHTML) HTML pages. I have released a new version of
the teachpack.
Naturally, the error in the teachpack cannot affect your program
design. First, you are testing it without access to the web, and
Mr. Galliker's discovery is perfect proof of why you wish to do so.
Second, the revised teachpack simply delivers longer lists of URIs on some
occasions. This does not affect the correctness of your code nor its
design.
Tuesday, November 10th, 2009
Problem set 9 requires the design of a protocol, which consists of an
interactions diagram plus data definitions for message exchanges, server
state, and client (world) state. You must have a TA check your
paper-and-pencil for problem 9-1 by Thursday November 12,
4pm. Bring the "blessed" protocol to your code walk of problem 9-1.
If you proceed without a the blessing of a TA, we will impose a 20% penalty
on your code walk.
Monday, November 9th, 2009
I have made two minor corrections to problem 8-2. They are marked up.
Sunday, November 8th, 2009
As several of you have noticed, the example in problem 8-2 was flawed. I
have fixed it. Never mind, it was correct the first time around!
Also, when you are looking for a closed site, specify the site not its index
file. That is, use "http:foo.com/bar/" not "http:foo.com/bar/index.html"
as the starting point.
Saturday, November 7th, 2009
As several of you have noticed, the geo-code function may
produce more than one result. My response is that your program may take
the first, the last, or all of them. Indeed, you may even wish to let the
user of the code (as opposed to its designer) choose what to do.
Christos will run Felix's drill on Monday, and he will code-walk a
solution to the n queens problem to reinforce generative recursion.
Also on Monday, Stephen will post sign-up sheets for the remaining code
walks (8, 9, 10, and 11).
Some of you have inquired about the schedule for the Thanksgiving
week. The lectures will take place as normal. You will also receive a
problem set that is conceptually due on Wednesday before Thanksgiving. We
will not conduct code walks for these solutions, however. Instead, you
will receive a supplement to the homework assignment and we will code-walk
the combined solution. In other words, if you don't design properly, you
will be in trouble over Thanksgiving; if you do design properly, the
changes will be straightforward.
Friday, November 6th, 2009
Two comments on today's code walks:
-
A termination argument explains why a generative
recursive function (or nest of generative recursive functions) reaches
its termination condition for all possible inputs. It is
not a description of the termination conditions.
-
While it is technically true that a structural design
is a special case of a generative recursion, we consider
it wrong in this course to refer to a structural design
as a generative one. Unless you have a clear idea that you are going to
use a generative recursive strategy--which immediately means that you
should pay attention to termination--try structural design first.
See the following notes.
The problem of rendering expressions (a poem of a program of rendering
things for the web browser and/or text production) will come up at least
two more times this year. I therefore urge you to take the comments from
your code walk to heart and to fix it up before you move on. Here are some
hints:
-
Use a structural design, even if the problem statement uses words
that make it sound like you should use generative recursion.
-
Find the tasks in the problem statement. Design functions for those. If
they share auxiliary functions, make those global.
-
We generally recommend that you develop everything
globally, including accumulator functions. That helps you develop
examples and test cases for all of your functions. Once you have
completed the design, re-arrange your program and make things local that
deserve to be local (at least all accumulator functions).
If you do try to respond to the code-walk panels, I also urge you to go to
next week's drill club and present your revised solution.
On Monday, Felix's drill club will re-examine "generative recursion", a
topic that many of you need to revisit. He will present an alternative
solution to the "n queens" problem and demonstrate with a concrete example
how to think about problem generation.
Friday, November 6th, 2009
It is time to start reading "How to Design Classes." The book is available
from the bookstore (either classified as "CS 2510" or "CS 5010"). If they
don't have it, the NEU Repro store (around the corner) should be able to
produce additional copies. -- While we will not follow the book per se and
instead use the full PLT language with classes, the principles of the book
apply. Also, seeing the ideas in PLT and Java syntax will be beneficial
for you.
There will be class during Thanksgiving week and there will be a problem
set (part 1 of problem set 10). But, there will not be code walks for this
part of the problem set.
Wednesday, November 4th, 2009
Problem set 9 is released. I also clarified a point in problem set 7.
Tuesday, November 3rd, 2009
I posted a small (obvious) fix to problem 7-2.
Tuesday, November 3rd, 2009
Monday, November 2nd, 2009
Drill problem 31.3.1 is messed up due to a change to drscheme that happened
a couple of years after we released the book but before the latest version
of the book was released to the web. Specifically, drscheme now understands
all real numbers (and complex) as exact numbers not as
floating points (like in other languages).
If you want inexact numbers, your program must compute them (say
(sqrt 2)) or you must write them into your program. For this
drill, create an inexact coefficient in g-series like this:
(define (g-series n)
(cond
[(zero? n) empty]
[else (cons (expt #i-0.99 n) (g-series (sub1 n)))]))
(* 10e15 (apply + (g-series 1000)))
(* 10e15 (apply + (reverse (g-series 1000))))
See what these computations of the "same" sums produce.
Monday, November 2nd, 2009
Please send me your solutions to the depth problem for the Foomble
language. I have two solutions so far, and the lucky winner(s) get
to conduct a public code walk (which as you can imagine, comes with
large benefits).
Monday, November 2nd, 2009
It is time for the last partner switch. This time you may choose to work
with the partner of your choice -- as long as you have not worked with this
person before. That is, neither your current partner nor your first partner
are candidates for the third round.
By Wednesday NOON, you and your future partner must hand in a signed joint
statement to Stephen Chang. If you do not hand in such a statement at that
deadline, we will assign you a random partner. Everyone
will get notice (confirmation) about the new partner and pair number
assignment by Friday NOON latest.
Until then, you must continue to work with your current partner, and of
course, you must not work with anyone else, including your future partner.
Sunday, November 1st, 2009
The original "image-ops.ss" teachpack was developed on a newer drscheme. I
have modified it so that it now runs on drscheme v4.2.1, the required
version. Please download this new version. (Sun Nov 1 20:30)
Saturday, October 31st, 2009
See problem set 7 for small improvements (typos, language). Nothing essential changed.
I have also release problem set 8.
Thursday, October 29th, 2009
For the code walks starting tonight, please bring along an encoding of the
following Perthon program in your data representation:
(
(def T(X) ret ((? X : (T $$ "a") , (X ++ "b")) ++ "c"))
((T $$ "") ++ "d"))
)
If you have a USB stick, put it on there so that the TAs can quickly test
your submission with this example.
Wednesday, October 28th, 2009
Someone asked whether it is acceptable to produce a complete solution for
the n-queens problem first and to animate it afterward. This is a perfectly
acceptable solution (even though it may not be in the original spirit of
the question).
Wednesday, October 28th, 2009
Problem set 7 is out. I have eliminated one problem to reduce your work
load a bit. To compensate, we will inspect your code more closely than we
have in the past.
Tuesday, October 27th, 2009
Like with ISL, Java, and C, Perthon's syntax comes with names for the
various pieces. In
(def FVariable (PVariable) ret Expression)
FVariable is the name of the function, PVariable
is the function's parameters, and Expression is the
function's body.
Also, you should read
Second, the only variable names that may occur in the body of the function
are the name of the function and the name of the function's parameter
as follows:
Second, the only variable names that may occur in the body of the function
are the function name in the first position of a function call and the name
of the function's parameter.
Tuesday, October 27th, 2009
Here is a summary of the in-class 'homework problem from last night's
lecture:
Design the function db, which consumes and produces
'Foomble' expressions. Its purpose is to replace all occurrences of
parameters in lambda bodies with names that indicate how far
away the binding lambda is. Here are some examples from the
information domain:
(lambda (x) x) becomes (lambda (x) zero);
- for
(lambda (x) (lambda (y) (lambda (z) x))), the
function returns (lambda (x) (lambda (y) (lambda (z) three)));
- and for
(x (lambda (x) (lambda (y) (lambda (z) x)))), the
result is (x (lambda (x) (lambda (y) (lambda (z) three))).
Also recall last night's instructive example. In order to turn numbers
into symbols, use
;; Number -> Symbol
;; convert the given number into a symbol
(define (number->symbol n)
(cond
[(= n 0) 'zero]
[(= n 1) 'one]
[(= n 2) 'two]
[(= n 3) 'three]
[(= n 4) 'four]
[else 'etc]))
and don't nest your parameters deeper than five levels. (A real compiler
pass uses a parameterized data description and replaces symbols with
natural numbers.)
Send me your solutions before the next lecture. We will code-walk some in
public.
Saturday, October 24th, 2009
Felix would like you to know:
- The descriptions provided (for Perthon's Program, Definition,
Expression, Constant, Variable) are *not* Student Language data
definitions.
- Corollary of above: the first task *cannot* be the (trivial) act of
cut-and-pasting the provided descriptions of Perthon's Program,
Definition, Expression, Constant, Variable. Something more significant is
required.
If you believe Felix is wrong, present a justification to Professors Wand
and/or Felleisen in person, and we may just let you work with the given
definitions.
Someone asked "Is it allowed to use Vectors in Problem 2?". The answer is:
Yes, but only immutable vectors, for which you may create a teachpack
called vectors-for-isl.ss, which you may then check into SVN.
The required language for this problem is Intermediate Student Language
with Lambda.
Friday, October 23rd, 2009
Here are comments in response to the code walks for week 5:
-
In the past we have repeatedly insisted on two points, which appear to be
in contradiction to each other. On one hand, we have said that data
definitions should describe sets of values. On the other hand, we have
said that functions are first-class values, just like any other
function. Put together, the two ideas suggest that a
valid data definition may just enumerate a bunch of functions.
This is wrong, however. You should only use
clauses in data definitions for which you can formulate conditions from
(constant-time) predicates. Since it is impossible to compute whether two
functions are equal or not (in ISL+ and all other full-fledged
programming languages), your data definitions may not
enumerate function values. Instead read the book's chapter on
abstraction and learn to use the -> data collection
constructor with which you can describe function spaces.
In addition, it is also a bad idea to enumerate specific functions from a
design perspective. Just recall our discovery of foldr. We
abstracted from sum and product. If we had used
the contract "the argument must be either + or *", it would then be
impossible to use foldr with any other arguments than those
two. Now that you have seen numerous uses of fold, you
should appreciate why the proper way to abstract is to use function
spaces.
-
We deducted points from missing attributions of code to previous
partnerships. While this requirement has always been marked up in red in
problem set 5, you won't find such nice warning labels in the real
world. Instead, you will be fired if you use
code from somewhere else and don't inform your manager; if you are
running your own company and do something like this,
you will be sued and that is even more costly.
-
Also, last week's blogged solution explicitly stated that you must not
abstract out recursive or cross-function calls. Some of you did so anyway
for the X-expression problems. Don't.
-
We saw many misuses of local for mutually recursive nests of
functions. Here is the proper pattern:
(define (main-f x-changing0 x-always-same)
(local ((define (lcl-f x-changing)
... x-always-same ...
... (lcl-ggg ... x-changing ...) ...)
(define (lcl-ggg x-changing)
... x-always-same ...
... (lcl-ggg ... x-changing ...) ...
... (lcl-ggg ... x-changing ...) ...))
(lclf x-changing0)))
Note that main-f is not called from
within the local nest of functions. Why? For design reasons, it
would be impossible to re-use the
constant arguments (the ones that don't change) without always passing it
around. You can thus clarify to any reader that
x-always-same really remains the same throughout the
computation. For performance reasons, you need to understand that
every call to main-f re-creates all these
localized functions. This costs time and money. Although the primary
focus in this course is on proper design and the justification of design,
you must always develop a sense for the cost of your chosen language and
you must factor this cost into your design as appropriate. See the book's
intermezzo on local for details.
-
No program---especially world programs---should be
run from the Definitions Window. You are to write a
main function and apply it in the Interactions window to run the
program. In the future, we will deduct points if you run programs
from the Definitions Window.
-
Attend drill cub. Use the resources that we
offer. Many people have made the claim that they don't have the
time to do the drill problems because they are spending so much time on
the problem sets. Based 20 years of teaching experience, be advised that
the opposite is true. You are spending so much time on
homework problems because you don't solve the drill problems.
You may have noticed that the base score differs from week to week. Over
the next few weeks, the score will gradually increase. The increases
reflect the increased complexity of the problem sets as well as the idea
that we reward those students who can demonstrate that they learned their
lessons from previous code walks.
Saturday, October 17th, 2009
Correction on the report from code walks: The reviewers report that many of
you use undefined terms in contracts, especially
"List". They have asked for permission and have received it to
deduct 10 points for the meaningless use of "List" and similar terms.
On Monday afternoon we will post a sign-up sheet for code walk slots for
the new pairs. Please sign up by Tuesday afternoon.
Friday, October 16th, 2009
Three comments from today's code walks:
We have jointly decided that all of you need exercise in correcting code
and presenting corrected code to code walkers. We will release a revised
version of homework set 5 this evening still.
The reviewers report that many of you use undefined terms in data
definitions, such as "List" or "X". They have asked for permission and
have received it to deduct 10 points for the meaningless use of "List" and
similar terms.
All of us have observed that you are still not taking notes properly.
When Partner A is presenting, Partner B should be seated, with a copy of
the code in his or her hand, taking notes on the reviewers' comments as
they are made.
At the end of the session, both partners should be seated, and should take
notes on the reviewers' end-of-session comments.
If you don't take notes, you will walk away from the session and remember
nothing of what was said.
Again, reviewers will deduct points in the future if partners fail to take
notes.
Friday, October 16th, 2009
See updates to problem set 5 concerning
the problem statement and the re-use of code.
Most importantly, any attempt to work with your old partner is now
considered code theft, and we will prosecute it like any other form of
theft. For details, see the problem set.
Thursday, October 15th, 2009
This night you will receive an email with the name and email address of
your new partner. As of Friday 4pm, you will no longer work with your old
partner on anything. Instead, you will contact your new partner to arrange
a first meeting as soon as possible.
Homework set 5 is now available. You must work on
this homework set with your new partner. The two of you should start by
presenting to each other the solutions for problems 4.1, 4.3, and 3.4. You
should choose whatever old solution you think is the best starting
point. Do not choose the code from the partner
with the higher score, unless the score is (near-) perfect. Keep in mind
that a score reflects a combination of presentation skills, justified
design, and various other aspects. Do use the chance to practice your code
walking skills so that both of you understand the code base equally well.
The new homework set is a relatively light load compared to previous
homework sets---if you have a decent solution to the problems. Keep in
mind that when you "edit", you must have a good test suite so that you can
quickly re-establish that nothing essential changed. If things change
unexpectedly, backtrack to the last point that worked (svn is good for
that).
Tuesday, October 13th, 2009
The staff discussed the needs of the students. We decided to hold drill
clubs today (four hours worth!) and not to hold a question and
answer session. Please do take advantage of the drill clubs.
Sunday, October 11th, 2009
Problem 4.1 now comes with instructions on how to deal with the additional
teachpack. Make sure to check in your program from one computer and to
check it out on a different computer to ensure that the SVN commit works.
Also note the small addition of an emphasis to problem 2.
Saturday, October 10th, 2009
Concerning problem 4.1: Prof. Wand's class used the name "XElements"
instead of "Xexpr". Also see Prof. Wand's lecture notes. Finally, although
Prof. Wand's class did not cover the entire refinement chain of XML
representations, the material -- together with the book's file system
examples -- suffice for solving this problem.
Friday, October 9th, 2009
I have edited two of the problems for problem set 4.
Since the rule about testing auxiliary functions was obviously
misunderstood, you must supply tests for all
functions.
From now on, Christos Dimoulas will hold drill-club hours on Tuesdays from
3:30 to 5:30pm, followed by Stephen Chang's drill club from 5:30 to
7:30pm. They will both use room WVH 166.
We know that Systems will have a make-up lecture on Thursday. If you are
in Systems and you have a conflict with your code walk appointment, send
email to Stephen Chang by Tuesday NOON.
Solutions for today's code walk problems (3.2
and 3.3) are on-line again. Do not count on
getting solutions for every week.
Thursday, October 8th, 2009
Friday morning's code walks will take place in WVH 166 and the upstairs
computer lab. The TAs will post a schedule at both places and will manage
the distribution of pairs. Watch and listen for announcements.
Tuesday, October 6th, 2009
Due to ``copy and paste'' -- something that we teach you not to do --
the syllabus was messed up. In particular, it mistakenly specified a
summary session for this week when we really planned on covering Part IV
of HtDP. I have fixed and released a new syllabus.
Also in response to some questions, I have clarified problem set 3. The
additions are type set in red so that you can easily spot them.
Monday, October 5th, 2009
We have created a second drill club. Stephen will run the drill club in WVH
166 in lieu of his office hours.
Also, for some reason, a flawed version of homework set 3 made it to the
web server. Please make sure to read the released version from Sunday or
later.
Friday, October 2nd, 2009
Friday, October 2nd, 2009
Office hours: As of this week, you may no longer ask the TAs any direct
questions about the homework problems. If you need clarification, send
email to the staff mailing list (see blog); we promise prompt responses
throughout the week. You will not get any answers about code that you
wrote.
Drill club II: Also as of this coming week, Stephen's office hours on
Tuesday will be turned into a second drill club. All drill problems and
all homework problems from weeks past are legitimate topics for the drill
clubs. No questions concerning current or future homework will be
answered.
Christos's Wednesday office hours will serve for last minute questions
concerning general topics (lectures, functions in BSL or ISL, drscheme
questions, svn questions). He will not answer any questions concerning the
homework problems per se.
Wednesday, September 30th, 2009
There is no need for a new sign-up sheet. The schedule remains the same
while you are with the same partner.
Wednesday, September 30th, 2009
Professor Wand has put up the examples for his section in the usual place
(see tab). The folder has been reorganized a little, so it no longer has a
nice landing page, but it will be easier for you to find and download the
examples.
Wednesday, September 30th, 2009
Last night's lecture received the following hint concerning Problem 2.4:
I take it that what was meant was to replace
(make-editor String String)
by
(make-editor LOS1 LOS1)
where LOS is a list of 1Strings (1-character strings).
We wish to ensure that everyone is aware of this hint before the deadline.
Tuesday, September 29th, 2009
Today's office hours repeatedly brought up three questions:
-
Q: "where should we write down the answer to the questions which is
been asked in the problem set 2?" A: Write them down as comments in
the solution file for the corresponding question.
-
Q: What is non-standard about the conditions in question 2.1? A: Let's
try again:
"The design recipe demands the use of the same predicate in
both cond clauses for the main function. Why? How could you simplify the
design?"
-
Q: Should I use a list of two strings for problem 2.4? A: Of course not!
That's totally silly. Think about the string operations you had to design
for problem 1.4 and how much easier it is to define these operations
using lists (of what?).
Tuesday, September 29th, 2009
Prof. Wand sent us the following recommendation:
Bring paper and a writing implement to the code review. During the head
panelist's response you should sit down, remain quiet and take notes. If
you do not bring paper and writing implement to the review, you will have
points taken off your score.
We all full-heartedly agree with this statement.
Monday, September 28th, 2009
Remember to bring a print-out of today's drill problems for drill club. In
addition, you should either email your solutions to Felix (pnkfelix at
ccs.neu.edu) or bring them along on a memory stick. Today's password is
"heaven".
On a different note: the course now has its own mailing list, which should
make it easier to get responses than individual emails:
cs5010staff@ccs.neu.edu
The mailing list includes both instructors and the graduate TAs listed on
the course web pages.
Friday, September 25th, 2009
The head panelists requested that for problem set 2 you provide templates
for all functions via comments:
#| TEMPLATE FOR FUNCTIONS THAT PROCESS elements from DD:
(define (f an-dd)
(cond
[(alternative1? an-dd) ... (selector-1-1 an-dd) ...]
[(alternative2? an-dd) ... (selector-2-1 an-dd) ...
... (selector-2-2 an-dd) ...]
...))
|#
If you need one and the same template for several functions, writing it
down once suffices. Indeed, writing it down several times
shows that you do not understand the nature of templates.
Some comments on your code walk performance:
-
Just a reminder that we do not grade on a curve. The grades are assigned
on an absolute scale.
-
Almost half of the class received 10 or fewer points out of 20. This score
corresponds to a failing grade. That's the bad news.
-
The good news is that the worst code walk doesn't count against your final
grade and, based on our experience, that most of you will learn quickly
and improve. To improve, however, means you must sit
down and study (!= read) the materials that we provide.
-
The use of "C style braces/parentheses" issue upset one panel so much that
they deducted points. I have requested that these points are returned to
you. But, I have amended the style
sheet and you must use proper parenthesis style or
face deductions in the future.
Solutions for problem 1/2 and
problem 1/3 are now available. Study them well.
I have also put the grading guidelines for
problem 1 on line.
Friday, September 25th, 2009
See the web page on code reviews for a
general on what we look for in your presentations and how we evaluate
your 'package.'
In addition, please understand that the code review functions according to
the following pattern:
-
The panelists check out your solutions from svn (saved at midnight on the
preceding Wednesday), check whether your svn arrangements satisfy the
required protocol, run a solution, and check some basic
stylistic properties.
- Each of you gets around 10 minutes to present a program to the
panel. During this time, we will ask clarifying questions, 'pointed'
questions (hints that your code and/or your presentation of the code is
lacking), and questions to direct your presentations.
-
The remaining 10 minutes belong to the head panelist. He will diagnose
each of your code presentations (including the code) and you
must listen and remain quiet so that you hear what went
wrong. Ideally you should take notes. Discuss the diagnosis
after you leave the room.
If you have questions concerning the diagnosis or if you do not understand
how to eliminate the weaknesses that the panel diagnosed, see the teaching
assistants and the instructors during office
hours.
On an unrelated note, see
the Hollywood
principle to get an idea why we introduce you to world programming
first.
Tuesday, September 22nd, 2009
Office hours postponed!
Felleisen: today at 3:00-5:00pm instead of the regular times.
The password is "Faust!" and the code for last night's lecture will appear
here soon.
Monday, September 21st, 2009
Today's password: "good bye world"
Now that you have experienced pair programming for 20 minutes, you should
read up on it and how it benefits companies and academia alike. The
assignments page now has an
additional tab, which explains pair programming and which points to a
widely popular article on the technique. We urge you to read it,
especially if you have doubts, or if you are tempted to split the projects
after all and to just do things as you have always done them---all by yourself.
Hot of the press:
an
article in yesterday's NYT on pair programming.
The last day of classes is December 12, as defined by the registrar's
calendar.
Friday, September 18th, 2009
We have now specified how each and every SVN homework submission must be
organized. See the Assignments tab on the
left.
The "last day of classes" is a technical term in US colleges; see
NEU's
on-line calendar and find out what the last day of classes for this
year's fall semester is.
Friday, September 18th, 2009
Stephen Chang has prepared a detailed svn
demo for your off-line perusal. If your lab was a bit fast and you
have never seen anything like svn (trac, csv, etc.), we urge you to spend
15 minutes going through this worksheet carefully.
Remember: Use
svn ci -m"problem N.M"
every time you end a session.
Thursday, September 17th, 2009
Today's password: "hello world"
Once again, today's (and tomorrow's) lab is
on-line, and you should read it in
preparation of your lab sessions.
The current version of HtDP/2e refers to a function called
animate. Like all other functions, it is hyper-linked to its
(draft) documentation. By following the hyper-link, you will see that it
is just a new name for the function run-simulation. So use
the latter instead of the former if you wish to run the programs in the
Prologue.
Our current plan is to make the last day of classes the last day of
Bootcamp. See the campus calendar for details.
Wednesday, September 16th, 2009
Professor Wand's lecture notes are now available from his web page. See new
tab on the left.
Wednesday, September 16th, 2009
One of your co-students writes:
There's a neat spider service called Page2RSS that periodically scans a
given URL for updates and delivers them as an RSS feed. I was able to use
it to check the CS5010 class blog. Hopefully it will work well.
Page2RSS site: http://page2rss.com/
CS5010 class blog feed:
http://page2rss.com/rss/e6be6b5b36385e5ec4034e13ad4acc7e
If you find this service useful, fine by us. No warranties.
Tuesday, September 15th, 2009
Lab 1 is now available. You can start thinking
about it early.
Some important points concerning the course, the labs, and the web pages:
- The labs will take place in WVH 212 this Thursday and
Friday.
- Remember to get a CCIS systems account before you come to lab. See
FAQ.
- The web pages are still evolving, while we are eliminating typos and
adding a few details here and there. Check back often.
Wednesday, September 9th, 2009
Welcome to Bootcamp.
It is time to get started, and this means for you that you must begin to
study How to Design Programs/2nd edition. Notice
that we didn't use 'read' but 'study' in the preceding sentence. To study
a text book means to work through the examples (with drscheme in this
case) and to solve some of the exercises to test your knowledge. Any
other interaction with a text book is a waste of time.
|
|
