On 2003-03-06, Tzafrir Cohen wrote: > On Wed, 5 Mar 2003, Beni Cherniavsky wrote: > > > * 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. > OK. I see you wrote a lot of strong arguments and I admit that I exaggerated somewhat :-) and also that I have only short spreadsheet experience. Still my main point is that the basic style of interaction is full of bad habits; it's like saying that you can do everything in BASIC (old style) or DOS batch files. I'm not saying spreadsheets are doomed to be evil but their reluctance to learn from advances in programming language design annoys me.
> * spreadsheets provide you a smart cut&paste behaviour for cell addresses > in formulas, so copying formulas around should "just work". > True; this solves the relocation problem, except when you link to external spreadsheets, when they are inaccesible and so can't be updated. These things start to break when you index "arrays" which frequently involves mixed relative/absolute (A$3) addresses. > * spreadsheets (following lotus 1-2-3 ?) provide "cell aliases" which are > names to specific cells/blocks . In other words: variables. > Hidden in a dialog last time I checked... > > - 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 . > That's an advance. Show me spreadsheet users who read the docs :-) (ok, I figure you do). > > 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. > That *is* the problem I was hinting at. Of course this can also be argued a feature. > > * 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. > "gosub" - Impressive :-). And you pass arguments by global values? > > - 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. > How does a goto work in the context of spreadsheets? Please explain (and also the gosub). Do you mean that you need to escape to "macros" for it or is it something natural to the normal table-of-cells work? > > 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? > No, here it's not an optimization; it's forced upon you. I was just refering to the fact that it's equivallent (more or less) to the loop unrolling operation that is originally an optimization - and optimizations are not pleasant for a human to do... > Do you optimize shell scripts? > Precisely - of course I don't but here I must and it's not more pleasant. > 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. > True. But I don't imagine maintaining anything half-big in a spreadsheet format, without a lot of bugs creeping in, largely due to the encouragement of cut-and-paste. > > * 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. > First google hit (seems to be the only relevant one in the first 10): http://cs.oregonstate.edu/~burnett/Turing/TuringMachine.html This explains that while "comercial spreadsheet languages are not Turing complete, it is possible for a language using the spreadsheet programming paradigm to be Turing complete". To examplify that it shows a language where cells can change their values during the run, which is quite untypical for spreadsheets (you need things like Solver to work around). > Yet another place where "turing-complete" is quite meaningless :-) > It's quite meaningless because everything sensible is turing-complete in very obvioous way. This only emphasizes the point of spreadsheets having difficulty to achieve this. When raising the issue of turing completeness, I'm taking the more practical approach: that things like looping, branching, recursion are implmentable with reasonable easiness. Nobody would buy unlambda, right? > > * 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. > OK, point taken. > > 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 :-) > It's not that silly! Take a look at make(1) and the number of clonesand alternatives. Take a look at Gnome's new no-apply configuration style. Dependency management is extremenly convenient. But as he says there "Ignore the silly row/column grid". -- Beni Cherniavsky <[EMAIL PROTECTED]> I'm too lazy to use GUI - why should I click all these things to get my job done? ================================================================= 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]
