#+TITLE: First year compsci
#+AUTHOR: screwlisp
I was fortunate to have a friend starting studying computers share
their week 7 assignment with me. (I'd be interested in a variety of
people sharing these, yes you). I will make some notes about the
assignment, whose explicit theme was described as algorithms and object
oriented programming. I'm also interested in everygopher's thoughts on
introductory programming.
I'm not sharing details of the assignment, except as journalistic context
but will share what I think is a better idea.
* A clear description of the assignment 6 (ie week 7, semester 1 compsci)
** A grid of circles
The original assignment appears to have been to download and unzip a
Csharp Micro$oft Windows Forms answer template and open it in
Micro$oft Vi$ual $tudio and do this:
#+BEGIN_VERSE
Read integers rows, columns, diameter,
there being window-width and window-height,
try
if rows * diameter > window-width or columns * diameter > window-height,
then throw array_out_of_bounds
endif
for row in rows
for col in columns
get random color from a list of colors
call micro$oft_draw_circle on color, diameter, row and col
endfor
endfor
catch
if array_out_of_bounds request different bound and retry
end
#+END_VERSE
Particular context implies that exactly the above is sought.
I guess the error throwing is objecty, though I somewhat object, and
the Micro$oft drawing framework was implemented at Micro$oft using
classes.
** Rows of squares
The above, but four rows of color 1 squares are drawn, then four rows
of color 2 squares are drawn.
** ASCII lines
Read a number of rows and columns. Print - followed by columns-2 *s,
followed by -, rows times in a terminal.
There is a hint like, "define constants for..". (?).
** More ASCII lines
Like previous but the lines are all *s, but every third line is all =s.
* Some criticism
** Object orientation
Visible object orientation seems to be the errors and the large scale
drawing framework having visible seams. There is the latent point that
the reason for the visible seams in those two is that these
implementations are frequent targets of change and extension by
others. However, I don't think that comes through in the assignment.
** Algorithms
Two for loops, nested seems to be the pedogogical theory of learning
algorithms after two months of university study.
I don't agree with this and reserve the word algorithm for implementation
of functionality like Runge-Kutta integration, Winograd Fourier transforms
and so forth.
Using two for loops sometimes gets called the-naieve-approach and algorithms
get explained in terms of not doing this. Displaying a tiny grid for humans
is an odd case which the-naieve-approach is relatively great for.
* A lisp assignment for this week, and also every week.
Savvy lispusers know I'm about to say Sandewall something
something. If we remember Sandewall's 1978 example intro for lisp,
Sandewall implements a calendar application for a university to
provide their staff and students. Well, nowadays universities will
either sign contracts to Micro$oft and/or Boggle for their students
and employees so they're left basically antihelped.
Help yourself by writing your own very-long-life calendar
application. To start with, at least days with appointments and days
without appointments should be indicatable, and appointments should be
changeable.
Help others by sharing your long-life calendar. If someone else uses
your software, it is at least a minor success.
Is interapplication conjugation possible between calendar softwares?
** Explanation and possible theme hints
Wall or desk calendars, monthly, annual or weekly are ubiquitous. They
are mostly some kind of systematic grid visualisation.
However, there is clearly no one good way to do them.
Two attractive features would be a graphical calendar with some kind
of pointer cursor, or a variously dumb terminal friendly calendar
(ANSI? UTF8?). Everyone can implement one of their own, and then
amalgamate features from other peoples'.
It is up to personal context whether one uses interlisp in a web
browser, their favourite common lisp, McCLIM application frames, an
MIT CADR emulation, emacs. I know interlisp has an interesting
graphical calendar in its lispusers> directory.
A novel introduction of the expectation of learning between softwares
highlights some possible deficiencies in version control and rote system
design often taught and portrayed as received wisdom.
** Please share yours!
Let me know about your own when you make one. The best way is to tell
me in LambdaMOO or SDF commode chat during the lispy gopher climate or
zhen house zhen bonkwave (000UTC Wednesdays, 1400UTC Fridays
anonradio.net).
I'll make a gopher directory to them all similar to solderpunk's awful
fur socks.
