[ExI] ai class at stanford

[Mike Dougherty]

On Tue, Aug 23, 2011 at 8:27 PM, spike <spike66 at att.net> wrote:
>>... On Behalf Of Adrian Tymes
> 2011/8/23 spike <spike66 at att.net>:
>>> So in that loose sense, a spreadsheet with macros could be considered an
> object oriented language, ja?
>
>>...Not really, IMO.  It is possible to use the concept of objects in non-OO
> languages, and I believe what you describe is an example of such.
>
> OK cool.  I like the spreadsheet programming environment in some ways,
> because it lets you see everything that is going on.  If you think of each
> individual sheet as an interchangeable module,  the language can even be
> considered modular and top-down.  A sheet or a column of cells fits at least
> the strict definition of a user defined function and a sheet, column or even
> perhaps a single cell fits at least the strict definition of a user defined
> function.

The spreadsheet is certainly a powerful user interface, especially in
the hands of someone who actually understands and thinks in that
model.  A problem, from a programming perspective, is that the UI
(view) and the data model and the code (controller(s)) are tangled up
in each other.  Adrian mentions using a web page as the UI and the new
controller code to marshal the web interface back and forth with your
spreadsheet would probably be more of a nightmare than engineering a
cleaner model.  If you want more information on this concept, look for
the Model-View-Controller (MVC) design pattern.  It's the same
principle that tells web designers to keep the HTML, javascript, and
CSS well-separated.  The result of properly implementing this
principle is a certain elegance that makes easier practically
everything you do in the maintenance phase of the life cycle.

Excel's vba macros already treat workbooks/sheets/cells as objects.
You are already taking advantage of a cell object's "change" event,
which triggers a surprisingly complex cascade of (re)calculations.  I
think this native feature of the cell object is what makes the
spreadsheet so powerful for your application.  You are able to express
the relationship of cells in several dimensions (a sheet is 2D,
multiple sheets gives you 3D and multiple workbooks could easily
express 4D spaces if anything can easily express high-dimension
spaces)  There is so much CPU on your desktop today that you don't
even care how much inherent waste is in the cell object for all the
text/background color, number formatting, border information, etc.
Since those calculations would take you hours (days?) to do manually
you are happy to have them take only minutes - but implemented without
all the overhead you'd probably see results in seconds.  If you were
to scale your utility to hundreds of simultaneous users, it would
become worthwhile (or absolutely required) to implement those
calculations/relationships in a more succinct & efficient way.

> I am pushing this notion for a reason.  The engineering environment in which
> I work has enormous resources already in excel sheets.  An example would be
> an extremely sophisticated atmosphere model, which has evolved over the
> years, and takes into account F10.7, geomagnetic index, latitude, longitude,
> altitude, time of day, temperature, pressure, a bunch of other minor
> factors, and it works really well, but the catch is, it's a spreadsheet.
> Porting all that to any other language would be a nightmare.  That
> atmosphere model looks to me like an object.  Pressure as a function of
> yakkity yak and bla bla would be a user defined function.

Perhaps the whole model is an object.  Maybe that would be useful
metaphor for something like a genetic algorithm that has inputs to the
model as DNA and each genome instances the model and "runs" it.  In
that case you'd literally be instancing hundreds or thousands of
models per generation and you'd probably want to run a few hundred
generations.  Depending on what outcome you are looking for and how
you build the fitness evaluation, that already sounds like enough
computation to turn your computer into a effective foot warmer.

Don't let years of hype around OOP convince you it's the ideal
metaphor for code.  Humans deal with objects in the real world and we
have evolution to thank for preparing us for this environment.  It's
"natural" then to think of problems using the object mentality.  If
the only tool you have is a hammer then all your problems look like
nails.  OOP may not always the best approach.