On Jan 5, 1:14 pm, Cédric Beust ♔ <[email protected]> wrote: > On Wed, Jan 5, 2011 at 10:00 AM, Alexey Zinger <[email protected]>wrote: > > > This isn't Excel, but in my own spreadsheet, I do have a feature that turns > > on dependencies in the entire spreadsheet. Been thinking about highlighting > > those for a single cell at a time as well. But even with Excel, it wouldn't > > be terribly difficult to analyze its contents with one of many Excel-reading > > libraries out-there and spit out a report. Could even develop tools like > > findbugs to do some automated code analysis or best practices adherence > > checks. But really, Excel is just a red herring of a tangent in all this. > > I brought up spreadsheets not in the context of Excel specifically, but as a > > general model of computing that can be used with other programming > > languages, environments, and usage patterns. > > Could you expand a bit, then? > > Because from a theoretical standpoint, a spreadsheet is just a bunch of > cells that interact with each other in a two dimensional space. I hardly see > anything interesting there... > > -- > Cédric
Broadly speaking, the interesting bits about spreadsheets come in the following areas: 1. declarative style programming The spreadsheet engine can take care of all the dependencies and possibly optimizations (indexing, parallelism, JIT, etc.), leaving the author of a document only with the task of supplying data and relatively fine-grained data inter-relationships. Spreadsheets also encourage immutability (generally data gets fed into specific points, but from there on, functions act without side-effects or state). So much of the functional and parallelism thinking applies. 2. a new relationship between data and algorithms Similar to what Smalltalk did with the concept of "images", a spreadsheet document can be thought of a stateful program. The value of a spreadsheet can come from the data it contains, the functionality encoded in it, or both. There are many ways of looking at this paradigm. A document with standardized structure of inputs and outputs, but unspecified algorithms otherwise can be viewed as an implementation of an API. Since it can also contain state within it, it can be thought of as a self-contained object in the more traditional OOP way of thinking (so some other program can read, mutate, delete, or replicate a document without caring about its implementation details). And so on. 3. bridging the gap between static and dynamic parts of a system Traditionally, we have systems that are built and then deployed. The parts that remain unchanged are the logic and the parts that mutate are state. This works well in many applications, but can be very difficult with systems that see fine-grained or frequently changing rules/business logic. Sometimes those parts are shuffled into clever configuration schemes that live in the purgatory between logic and state. Inevitably, such solutions run into many problems that plague roll-your-own solutions, namely tool support and lack of standardization. Some of these challenges will never go away due to the very nature of the problem (unique logic), but some can be helped. If you employ a method of development and distribution of code that uses something like a spreadsheet, the documents can serve as encapsulations of these fluid parts of the system with an easy way to unit test and prototype and deploy. These are just off the top of my head from a few years of tinkering with my own software and seeing some of the challenges of more traditional approaches. Spreadsheets are not a panacea, but neither is any one tool or approach. Mainly, I feel like Excel seems to have found a well deserved niche in the business world and has come to dominate the very concept of spreadsheet computing, making many developers gloss over this field of exploration. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
