Interesting. It seems many of the concepts have been fitted nicely into traditional 2D spreadsheets via pivot tables and multiple worksheets in a document. The separation of data, formulas, and views is interesting. Not sure on my feelings on it just yet, but I realized just now that I've been doing some of that in my own spreadsheet app by way of programming special "logic cells" that contain their own API and can expose different programmatic views of a data range elsewhere in the document. I've used this pattern to achieve non-trivial slicing and dicing of a data set. The spreadsheet environment takes care of execution of different snippets of logic that I write one piece at a time.
I use my own software half as a normal spreadsheet and half as a programming/persistence/testing environment. In my pursuit to solve my own problems, I've lately been considering implementing pivot tables and whether that would give me the desired multi-dimensional nature of it or if a true dimensional expansion is necessary. On Jan 3, 2:50 pm, Rakesh <[email protected]> wrote: > Lotus Improv....too much too soon. Maybe if they released it now? > > On Mon, Jan 3, 2011 at 6:42 PM, Alexey Zinger <[email protected]> wrote: > > Indeed. That's why I said "spreadsheet-like". As an author and heavy user > > of a Java spreadsheet app, I've been thinking about the next step for it and > > extra dimensions does seem appealing. > > > Alexey > > > ------------------------------ > > *From:* ScottHK <[email protected]> > > > *To:* The Java Posse <[email protected]> > > *Sent:* Thu, December 30, 2010 9:16:26 PM > > *Subject:* [The Java Posse] Re: programming theory: Quantum physics...to > > Java....to Scala? > > > yes, spreadsheets are great. I work 1000x faster in Excel than in > > Java. > > 'declarative' programming is the best solution when it works... > > again the limitation with Excel is it can only handle a 1 or 2 > > dimensional problem. work on a list of orders,etc... it can't handle > > more than a list of data easily, relational data doesn't work. > > > On Dec 31, 2:21 am, Alexey Zinger <[email protected]> wrote: > > > I predict in 30 years we'll be doing most of the programming in > > spreadsheet-like > > > visualizations of data structures. Yes, I love me some spreadsheets. > > > > Alexey > > > > ________________________________ > > > From: ScottHK <[email protected]> > > > To: The Java Posse <[email protected]> > > > Sent: Thu, December 30, 2010 4:36:24 AM > > > Subject: [The Java Posse] programming theory: Quantum physics...to > > Java....to > > > Scala? > > > > Over the past 30 years we have been moving up from Assembly code...to > > > Scala. > > > > Do programmers need to understand quantum mechanics to program? I > > > don't think so, programmers don't need to know assembly either. > > > > In computer science history, each new language development helped us > > > do more by forcing us to do less. In the lowest level, 'the heap', > > > all data as Global and the only data type is 'byte'. So with assembly > > > languages you can do anything.. Procedural languages such as C added > > > simple data types and encouraged us to package state changes into > > > functions. Object oriented languages encouraged us to limit the > > > number of states by chunking data into objects. Ruby and Java helped > > > object oriented programming by adding a lot of 'context' to the > > > language and cutting back on boiler plate code vs C++. > > > > Now 'functional programming' further encourages us to package chunks > > > of states that go into and out of functions and reduce immutable > > > state. > > > > Is the long run, will we reduce all mutable state accessible by the > > > programmer? I'm guessing in the future I think programmers will be > > > moving abstract concepts around around in 3d and a Google App engine > > > will turn it into gigabytes of assembly code. > > > > What do people think is needed most right now for the next generation > > > of languages? All my current programming problems involve dependent > > > states...such as keeping track of the sum of a list of orders, and > > > doing this with 3 or 4 levels of dependancy. Also working with > > > vertical problems, getting a simple function result normally, but > > > having some objects reach up much higher in the dependency stack when > > > errors occur. Some of the really cool Scala features help out with > > > these types of problems, list functions like .foldLeft and .foreach > > > and take a layer of complexity out of some problems. I think us > > > human programmers can only think efficiently in 2D and the more the > > > languages takes out the multi-dimensional complexity out the more we > > > can do. > > > > -- > > > 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. > > > -- > > 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 javaposse+ > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/javaposse?hl=en. > > > -- > > 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]<javaposse%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/javaposse?hl=en. -- 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.
