Re: Spreadsheets, HTTP::Recorder and interactivity

I believe what I've just described amounts to a whole paradigm shift in programming, . . .

Only if you discount at least a decade of testing methodologies. Recording scripts is the primary way of testing GUIs.

The reason why spreadsheets are more popular than Perl isn't the interactivity - it's the simplicity. This is the reason why I haven't finished my simplified version of Quicken and gotten my family's books off of a spreadsheet. It just takes too damn long to write the infrastructure a spreadsheet gives you. Once you do that, adding new features is a lot easier. But, getting to that point requires more tuits than I have right now.

That said, spreadsheets don't have the same raw power as a well-written infrastructure, in any language. Plus, you can't run your spreadsheet in a batch mode. Remember - 99.999999% of all data manipulations are handled in a batch mode because they need to be. (Credit card transactions, for instance.) That's the entire point of computers - to do the repeatable tasks so that humans don't have to. They are tools - nothing more.

Meditate a little more on the topic, focusing on where your impetus comes from and how that relates to the general tasks of computing. Remember that the largest consumer of computing power for a very long time was the financial industry.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re: Spreadsheets, HTTP::Recorder and interactivity

Replies are listed 'Best First'.
Re^2: Spreadsheets, HTTP::Recorder and interactivity by tilly (Archbishop) on Jul 01, 2004 at 16:16 UTC
Plus, you can't run your spreadsheet in a batch mode. Correction. You actually can run a spreadsheet in batch mode by driving it using ActiveX. You can do this from Perl using Win32::OLE. There are limitations to the approach, but it can be a useful approach.	[reply]
Re^3: Spreadsheets, HTTP::Recorder and interactivity by dragonchild (Archbishop) on Jul 01, 2004 at 17:46 UTC
Absolutely true. However, I will still maintain that a spreadsheet wasn't meant to be batched. If it was, then they are nothing more than extremely simplistic versions of Access. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^4: Spreadsheets, HTTP::Recorder and interactivity by tilly (Archbishop) on Jul 01, 2004 at 19:01 UTC
We are close to being in perfect agreement. No, spreadsheets were not meant to be batched, which is part of the reasons that attempting to use them in batch processing runs into problems. However I'd also maintain that Access, and applications used in Access, are also not meant to be batched. As a sample indication of why, consider the tendancy for issues to cause a pop-up to appear which practically demands human intervention. (You can get around that with Win32::GUI, but layering hacks on hacks like that is again fragile.)	[reply]
Re^2: Spreadsheets, HTTP::Recorder and interactivity by zby (Vicar) on Jul 01, 2004 at 14:48 UTC
The reason why spreadsheets are more popular than Perl isn't the interactivity - it's the simplicity I argue that it is the interactivity that makes spreadsheet manipulations simple. With a program you need to understand the whole, with interactive manipulation you need to understand only the atomic actions. I don't say that the technique I described was not used before - I made an example with the shell history myself, another one I was aware of was Emacs macros, and neniro mentnioned Exel macrocs can be saved as VB as well. I just believe it is very powerfull and is underused, and we will see it applied everywhere and perhaps the words 'paradigm shift' were a bit grandiose, but I think it is new as a general approach to automation.	[reply]
Re^3: Spreadsheets, HTTP::Recorder and interactivity by tilly (Archbishop) on Jul 01, 2004 at 16:27 UTC
Two comments immediately come to mind. First, this programming technique is indeed a fast way to solve certain kinds of repeated interaction problems, but leads to fragile systems. They tend to be poorly laid out, hard to understand, have lots of things that can go wrong that aren't handled, and so on. You should recognize this description if you've ever dealt with critical business processes that got started as a glorified spreadsheet from a non-programmer. Those drawbacks aren't a big problem for testing suites. But they are if you're maintaining production systems. Second, my personal reaction to anyone who is excitedly talks about the next big paradigm shift is to label them as someone who likely doesn't know what they are talking about, and almost certainly doesn't understand Kuhn. Put simply, a paradigm worth discarding at the drop of a hat wasn't worth owning, and the paradigm that you discarded the first one for probably isn't either. Paradigm shifts are not good things, they're very expensive messes that sometimes become unavoidable. The value that is perceived in them could not arise but for the far less visible effects of people working within good paradigms before and after the shift. If the second comment puzzles you, read The Structure of Scientific Revolutions by Thomas Kuhn. Again if necessary.	[reply]
Re^4: Spreadsheets, HTTP::Recorder and interactivity by zby (Vicar) on Jul 01, 2004 at 16:46 UTC
To the first I answer Worse Is Better. You might think you can design a system top down - but in reality successfull systems are usually built incrementally. It's all about short feedback loop. And you can refactor it later if it really builds up to something big. To the secont I've allready appologised for using a bit grandiose words. Should I delete them? I think not it would make your comment out in void and at least they are not misleading like a wrong code. Update: Is the meaning of term 'paradigm shift' restricted to what Kuhn related by this term? I am not sure. Look for example at ParadigmShift for a more liberal definition.	[reply]
Re^5: Spreadsheets, HTTP::Recorder and interactivity by dragonchild (Archbishop) on Jul 01, 2004 at 18:01 UTC
Re^5: Spreadsheets, HTTP::Recorder and interactivity by tilly (Archbishop) on Jul 01, 2004 at 18:48 UTC
Re^6: Spreadsheets, HTTP::Recorder and interactivity by zby (Vicar) on Jul 01, 2004 at 19:50 UTC
Re^3: Spreadsheets, HTTP::Recorder and interactivity by dragonchild (Archbishop) on Jul 01, 2004 at 15:07 UTC
You're not meditating on the topic. You're blasting a response as quick as you can type. Excel is just a application, written in some language. That language could even be Perl, for all you know! It is simple to use and simple to extend. It was designed to be simple in the simple case and powerful in the complex case. Perl is a language. IT IS NOT AN APPLICATION. People use programming languages when the existing applications are either too simple, too heavy, or otherwise unsuited for their needs. Please meditate on why you are insisting on comparing apples and Porsches. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^4: Spreadsheets, HTTP::Recorder and interactivity by zby (Vicar) on Jul 01, 2004 at 15:25 UTC
I use perl and Excel for data manipulation and I compare them as a tool for data manipulation.	[reply]
Re^5: Spreadsheets, HTTP::Recorder and interactivity by dragonchild (Archbishop) on Jul 01, 2004 at 15:48 UTC
Re^6: Spreadsheets, HTTP::Recorder and interactivity by zby (Vicar) on Jul 01, 2004 at 16:34 UTC