[ExI] ai class at stanford

[Emlyn]

On 24 August 2011 10:26, Adrian Tymes <atymes at gmail.com> wrote:
> On Tue, Aug 23, 2011 at 5:27 PM, spike <spike66 at att.net> wrote:
>> 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.
>
> WARNING!  WARNING!
>
> You are attempting to invoke code reuse, of something that was
> never designed to be reusable.
>
> This is an easy to understand notion.  On a small scale, it is
> even good.  However, if you wind up trying to do more than
> simple projects this way, you will soon find that the overhead
> greatly exceeds the cost of just biting the bullet and porting this
> into something with simple interfaces.  Maybe have the sheets
> running on a server somewhere, with ODBC access set up.
>
> If that sounds like waaay more effort than it's worth - consider
> how much you'd be using of that.  Consider, for instance, if
> all of that was available to any other - authenticated - Web
> browser on a page that wanted to include those functions to
> calculate and display the likelihood of hurricane passage in a
> given area, to tell some mayor who knows what zip code he's
> in whether he should be ordering an evacuation, and if so in
> which direction to tell people to flee.  Would it be easier to
> ship each mayor that set of Excel sheets, or would it be
> easier to set up Web access to those sheets' functions?
>

As someone who has had to support giant messes of spreadsheets built
by engineers in my professional life (in the past, thank the FSM), let
me make this observation:

No.

Spreadsheets are fine for temporary/initial/interim solutions, but
long term, they promote crazy spaghetti code, write-only code. It's
un-analyzable, un-maintainable.

Also, code really shouldn't be considered valuable in the way Spike is
suggesting above. Either you understand what the spreadsheets are
doing, and so can do a better implementation of version 2, in a better
environment (anything really). Or, you don't understand what the
spreadsheets are doing (and I suspect there's a lot of that here), and
therefore you can't say that they actually work. If they fail silently
(as Bill K has intimated), and they are impenetrable, then you really
need to assume they are broken. So, again, you need an analysis and a
rewrite.

If you are talking about sharing stuff around a big org, then script
in proprietary files (that you probably email around) is maybe the
worst way you can do it. Instead, if it's critical stuff, why not look
at implementing the same calculations in a web app that everyone can
access? You can always just do the most important stuff first (that
probably doesn't change much), and expose the results in all sorts of
good ways, including CSV outputs and maybe a db view or something like
that which ODBC can talk to, so people can still incorporate the
results into spreadsheets.

I'm sorry if I sound intolerant, but I've got serious battlescars from
dealing with this kind of shit.

-- 
Emlyn

http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google
Buzz posts,
comments and all.
http://point7.wordpress.com - My blog
Find me on Facebook and Buzz