On Wed, 5 Mar 2003, Beni Cherniavsky wrote: > 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).
Simply incorrect. * spreadsheets provide you a smart cut&paste behaviour for cell addresses in formulas, so copying formulas around should "just work". * spreadsheets (following lotus 1-2-3 ?) provide "cell aliases" which are names to specific cells/blocks . In other words: variables. > > - 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. Read the docs. IIRC at least quaro-pro (4.0 for dos) and excell (5.0) and above provide similar features . > It also discourages literate programming, which is easy to do > but the documentation will then appear as part of the output of > the progam. Note that there is no problem writing "commets": simply write a "label" cell. The output *is* the program. > > * 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. My knowledge of quatro-pro and lotus is quite rusty, but I recall a "gosub" macro command (as opposed to "goto") which is intended to start a function call. > > - 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). gosub 'block_name' > > - 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? For this even a GOTO will do. > > 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). Why optimize? Do you optimize shell scripts? What you generally need to optimize is the write time, not the run time, because it will be small enough. Originally [electronic] spreadsheets allowed to automate calculations, and thus prevented many mistakes caused by typos and such. > > * 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?!? They are basically turing complete (except the obvious memory limitation). Implementing a turing machine in a spreadsheet is quite trivial. STFW for one. Yet another place where "turing-complete" is quite meaningless :-) > > * 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 "blocks". Also keep in mind that "cells" can contain various data types. They can also be made into pointers, with minimal hackery. There is a "NULL" value, for instance. > 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. OK. So maybe a spreadsheet is not the perfect Object Oriented Porgramming System (OOPS). But it can get the job done. And take a look at http://www.halfbakery.com/idea/spreadsheet_20os for a silly idea :-) -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir ================================================================= 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]
