Lambda the Ultimate

I was being facetious...

I haven't given up double-meanings for Lent, but recently I understood how difficult it is to successfully convey a single meaning in a blog comment or email - so now I take the plain text at face value.

And I still have a sense of wonder that this is happening in a mainstream language :-)

spreadsheet programming paradigm in lisp:
http://www.cliki.net/Cells

...constraint programming in Oz to me.

I'd do away with spreadsheet programming entirely. Anytime someone creates a spreadsheet they should have created a database. So write your spreadsheet programs in SQL, and get the advantages of a real database (multiple users, real time updates, select only the data you want to display...)

Now a spreadsheet is a great DISPLAY tool for your database. If you have a lot of numbers, a spreadsheet is a great way to put them on paper, and drag-and-drop cells to a table is going to be easier for managers than learning SQL, particularly when they are not doing the same query.

There are many applications where a full-blown database is simply far too heavyweight. Not all spreadsheet users create large or complex tables. Spreadsheets provide a mix of easy programming, dynamic calculations, simple definition of GUI-like features, and easy data visualization that makes them the right solution for many applications (particularly those involving users who are not programmers). They're not going away anytime soon...

You are partially correct. Spreadsheets are more lightweight, and many tasks are light enough that you don't need a full database. However even for simple tasks, the ability to re-arrange the data based on a different query would be highly useful if only the user knew how to do this.

Many companies have processes built around various spreadsheets, that make the entire process more cumbersome. However they do not realize that there even is a problem - it works, and is more like the paper they used to shuffle that they don't think that the computer provides a better way.

Part of the solution is to intigrate the spreadsheet with the database so that when users create a spreadsheet the system does the grunt work. However a large part is to get people to recognize that they should call in an expert (assuming they do not want to become an expert - a good idea for many people who have skills that I as a programmer lack - let experts do what they are experts in)

Web pages are taking over many of the things that I used to see people do with a spreadsheet. (expense reports and time cards used to be done on a spreadsheet in many companies - both are cases where the data had to be copied to some other format[s] so that it could intigrate with the rest of the processes)

I agree that a spreadsheet is a great data visualization tool. The solution is teach users to populate the cells from the database.

I'm not arguing that spreadsheets are bad. Only that they are abused - often there is a better tool.

I've been fan of Anders' work since Turbo Pascal, and I really enjoy writing client apps with the VS.NET environment. It's got the snappy-response quality that made BP and Delphi so much fun to use.

Spreadsheets I think also satisfy that want for instant gratification. Whereas an environment like VS is a great way to do GUI-centric programming, spreadsheets are great for data-centric programming. You're also always working with live data, which is more natural for some tasks.

Think about all the different perspectives you take when working on a programming project. There's the code view, GUI view, database view, filesystem view, revision control view, module-dependency view, debugging view, visualization view, documentation view ... it seems like to be successful you have to somehow integrate all those views.

I don't know how I got talking about IDEs... I guess the point is that I sometimes wish I had a (live?) spreadsheet view of my running program, and vice-versa.

As far as I know, sql doesn't operate on sets. That is one of the complaints from C. J. Date.

You may want to look at AQuery: Query Language for Ordered Data. This is an extension to SQL which deals with times series. Since data is ordered, functions can access values from other 'rows' (moving averages, etc.).