Popular conceit about learning programming languages

[Dennis Lee Bieber]

Donn Cave fed this fish to the penguins on Friday 22 November 2002 
10:01 am:

> 
> Sure, but that's just the first O in OOP.  Objects have attributes,
> anyone can penetrate this mystery.  The question is, given the initial
> statement of a programming problem, like ``turn MIDI data into a
> printed score'', where do the objects come from and how do they help?
> If your grasp of Python is strongly OO, you'll find answers that you
> can explain, but you probably won't be able to explain how you found
> them.  We don't think by enumerating facts about the tools we use.
>
        Very sloppy requirements -- Are we talking a live MIDI instrument 
stream or data file; one instrument track or multiple?

        However, the courses/books I have on OO Analysis/Design (regardless of 
target programming language) tend to focus on Nouns and Verbs 
(noun->object, verb->method, and extending some what, 
adjectives->attributes).

        turn (verb) MIDI data (noun) into (accessory verb?) a printed 
(adjective? or more likely a verb) score (noun).

        So from that simple statement we have two objects already:

score

MIDI data

        In truth, I would consider the analysis faulty... the primary object 
is the NOTE, which has attributes of pitch and duration. Both the 
printed score and the MIDI data are equivalent representations of a 
stream of notes. There is the next object; the stream -- probably more 
familiar as a "track". What does a track have for attributes? Well, 
maybe an instrument (or voice), and a list of notes. I'd revise the 
definition of score now to include multiple parallel tracks.

So now I have:

SCORE (attribute: track(s), track count)
TRACK (attribute: voice; attribute: note(s))
NOTE (attribute: pitch; attribute: duration)

        No methods listed yet... I suspect the easy ones would be:

SCORE: add new track; delete track
TRACK: add note; delete note; set voice
NOTE: set(pitch, duration); get(pitch, duration)

        Little more analysis would probably give me an object for MIDI stream, 
and an object for Music printer.

        The MIDI stream object would have methods for GetEvent, SendEvent.

        The Music printer would have attributes for staves/page, notes/bar, 
etc. Methods for getting/setting those parameters, and for feeding 
voice/track and note information.

        The main processing would be a loop getting events from the MIDI 
stream and parsing them into needed score, score.track, 
score.track.note methods. At end (of file, or some manual interrupt for 
live streams) run a loop over the score object retrieving the notes and 
feeding them to the printer object.


        Now, this is a very sloppy analysis -- what do you expect for a 20 
minute effort (the OOA/OOD classes ran some 40 hours each, and seldom 
got more detailed than a calculator or ATM/bank/user configuration).

> So the first challenge may be to learn to think in Python, but then
> you need to learn to think beyond it.
>
        Whereas I prefer to "think in" the abstract, and /then/ apply 
transforms to map the abstract constructs to the target language.

-- 
 > ============================================================== <
 >   wlfraed at ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed at dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <