#+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.