Alexey's #3 Excel bridging the gap between static and dynamic parts is something I hadn't though of. A user of a traditional Java /C++ program has absolutely no flexibility in adapting your business logic on his own. In excel a user can take the result of my VeryComplicatedFunctionA(), use some of his own simple logic to modify/ check the result, and then feed it into VeryComplicatedFunctionB(). In Java if the user wanted to add some bounds checking,etc to an intermediate value this would require a program revision. Also in Excel the concept of state is not as clear as Java, the users will edit formulas and basically input state into the formulas.
Excel advantages for rapid development: -Results are visual = the user can test the logic very easily, the model & view are built together. -User can input/edit logic/formulas -Serialization is built-in - "Alt-S" -Excel dependencies are very simple -Dynamic programming possible for the user. Limitations: -Objects are limited to a single output, a string or a number. -Good for displaying data and calculations, not good for inputting/ editing/processing relational data or working well with SQL. -security/audit records -Brain Sturming: Right now something on the scale of a small accounting system with a few users is just a tiny bit out of the domain of Excel. If someone can think of a more advanced visualization than Excel to handle more structured data that includes all the audit records & security required of a core business application it would be a fantastic tool. Running Excel on a local machine will soon not really make sense either...perhaps something on the line of Google docs spreadsheets will move a bit further into the business information domain. I'm sure there's a lot of failed ideas out there....perhaps something about simple spreadsheets just fits into people's ability to visualize things in 2d really well, just look at continued popularity of 2d and 2.5d games versus 3d. On Jan 6, 2:39 am, Alexey <[email protected]> wrote: > 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.
