On 2003-03-05, Yedidyah Bar-David wrote:
> For complex things, I usually find complex, sophisticated spreadsheets
> much less maintainable than real programs (or scripts). I have heard
> horror stories about thousands lines of macros that organizations
> depend on and noone knows what's inside them.
>
Aghh, my favourite rant (-: come to think of what level of programming
language is a spreadsheet:
* Adresses are numerical (2D is irrelevant). That's about the first
thing smart programmers stopped to do (e.g. with assemblers; stupid
ones continued it surprisingly long, e.g. BASIC until late).
- Moving/copying code adjusts the addresses. Great idea, almost as
good as a loader, except that it only works for refences inside
the same program. A linker with alphabetic names is still
missing.
- Since addresses are numerical, you have to allocate space for your
code/data by hand, and explicitly move it when you want to resize
something. Again, programmers did it automatically since they
have assemblers.
- The layout of the code is directly tied to the layout of the data,
including the layout of input and output data (although the later
can be decoupled with extra work). I can't tell you when
programmes got free of such limitations because they never occured
to them in first place...
This leaves very little freedom to arrange your code in readable
ways but who needs readability anyway, when the typical
development tool can't show more than one of line of your code at
the same time? Instead you are expected to edit your code by the
memory dump after its execution. The very ability to do so should
suprise any programmer; most of the restrictions listed here are
essential for this but that's no excuse.
It also discourages literate programming, which is easy to do
but the documentation will then appear as part of the output of
the progam.
* There is no code reuse beyond cut-and-paste, the single most
condemned by any programmer way to reuse code. This stems from the
fact that code is completely non-reentrant: a single piece of code
can't be executed twice in the same run of the program.
- You can't write a subroutine that will be called from different
places. I believe this already existed in Babbage's Analitical
Engine in the 19th century (Ada Lovelace seems to be credited with
inventing it).
[Can somebody give me a link to her Notes on the Engine, or
anything other that describes the actual design instead of
repeating in general words their role in history of computing?
That's all I found so far (and their biographies) but I can't
believe there is nothing technical on it online...]
- You can't write a loop that will execute the same code many times.
This too existed in Babbage's engine but algorithms were written
expecting such an ability long before, for example Euclid's
algorithm for finding the GCD of two numbers. How do you
implement it in a spreadsheet?
The only way to implement loops is but unrolling them - an
optimization excercise that should never be inflicted on a
programmer in his source code - but with the extra requirement to
unroll them *completely* which requires you to know the total
number of iterations beforehand (or at least an upper bound).
* Data behaves like in functional languages: the same variable can
only be computed once and the binding can't be changed during the
run of the program.
- This actually leads to some elegant paradigms in functional
languages. It's not a restriction there because you can
dynamically create distinct variables to be bound in any amount
that you need.
- Since you can't do that in spreadsheets, I can't escape the
conclusion that spreadsheets are not Turing-complete. Need I say
more?!?
* All the modern ways to structurize and modularize code and data are
absent:
- There are no data structures. If you want to treat several
variables in a related way, you can - but there is nothing to help
you. Even self-respecting assemblers allow you to declare
structs.
- There are no general-purpose pointers. The builtins allow you
to manipulate and index arrays but these are of little use since
the values of the array must be statically associated with some
fixed code.
- All variables are global. Without subroutines, there is no need
for local variables, right?
- There is no concept of publishing interfaces between parts of the
code. Without subroutines, one can't usefully expose any
interface except public data, anyway. Exposing public data is
hard because the interface will have to be by numerical addresses,
resizing the data leads inavoidably leads to change of addresses
and the linking tools only help with the relocation if the
interfacing parts are in the same sheet. See, it all comes back.
- There is no support for separate independently developed modules;
as explained above there is little such modules could do one for
another anyways and the tools scarce tools helpign the programmer
stop working accross a module boundary. You can divide your
program into multiple sheets but these are only useful as long as
*you* are working on them together. This leads to a culture of
almost zero code exchange.
* At an afterthought, an escape to some turing-complete (but
usually miserable, e.g. VB) language was provided (under the
improper name of "macros"), so that useful things would still be
achievable.
Summary: a spreadsheet is a very low-level language, certainly below
assembler and in some senses below machine code, not turing-complete,
with hostile development tools. It's quite shocking to realize that
this is/was one of the most selling kind of applications and users
are happy with it.
--
Beni Cherniavsky <[EMAIL PROTECTED]>
There is an excel spreadsheet here. Do you want to open it? y
There was a grid bug in the excel spreadsheet. The grid bug bites.
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
