I'm sick of Excel. I don't have the XP version yet, but I don't think it will fix my dislikes. I don't like the structure of the program in the sense of the 'model' it uses to allow work, i.e. the spreadsheet. I don't like the general structure. I don't like the scripting language much. There is a lot more I don't like. But why be obsessive and pessimistic?I want to create the next killer app for desktop computing. The spreadsheet is an outdated representation. It was a killer app of its era, it was a generalised, automated beancounters paradise, it was and is a good idea. However it is no longer making the most of the resources we now have, It is an outdated idiom. Users are more savvy, they don't need something which looks like a book and constrains what can be achieved to that structure. This idiom is short of scope and doesn't offer what sophisticated quantitative users need and want.I am convinced there is a niche (or rather a gaping canyon) for a new quantitative tool. I've got plenty of ideas, and I intend to go for it. I intend to set up an open-source project in a matter of months. But first I want to broaden my perspective on what can be achieved, so I'm asking (begging) all you expert quanty users out there to tell me: What you want. What you need. How you like it. What you don't want. What you don't need. What you hate.Think big, think whacky, think way out. Between us we can change the world.

By the way, don't worry I know that there are lots of open source spreadsheet clones out there (GNumeric etc etc), but that isn't the solution because they are clones.

Sounds interesting, I'm thinking on it.For one all interfaces should be wide open, no hurdles for creating add-ins or modules or whatever you call them. And the interfaces should be clean clean clean, and real OO. And there better be real database connectivity. And you should be able to handle batch jobs, because I'm always trying to automate filling these guys smoothly on an ad hoc basis. And the reporting should be for real, i.e. separation of calculation format and report format.

I've never used Excel much, but I've always thought a huge downside with Excel spreadsheets is version control - you send a trader a spreadsheet with your latest pricing model, she changes something, emails it to someone else, and so on. Soon you're supporting a dozen versions (or trying to).Is this a real problem still, or have people developed ways around it?

MGHiggins >> a huge downside with Excel spreadsheets is version control I agree versioning can get out of hand with this stuff. In my view this is because Excel (and other similar tools) are more or less a scripting language for quants (quant sounds so pretentious in this context, but what else?). I mean that if I want to quickly do some sys admin type tasks I use Perl/Python/Ruby, likewise if I want to quickly make up a report or suss a calculation I use Excel; if I want to do a full system I use something else in both cases. The problem is that this is the theory, but in fact most big things start as small things and grow like snowballs, which I think is kind of good because it is like XP, design by trying and use. Therefore one ends up with a large thing with flaky internals. This is a problem also for those languages, but can be mitigated by having an open import system with modular 'scripts' (I now use 'scripts' to cover quant scripts too). I would hope to accomplish this within the new system, unlike Excel where one rapidly fgets bogged down with long names (e.g. C:\dustbin\zoiks.xls!SomeSheet!A233:B254) which are not very movable.You are also right that it would be wise to include some kind of versioning smoothly into the 'script' items. Thanks.

one thing I would like is the ability to turn a string of sheet calculations into a functionWhat I mean is suppose I have a bunch of parameters eg spot, vol, r,d,T,K etc and then I do a bunch of calcs in a lot of cells and then up at the end with a value (eg the call price...)I would like a routine that takes my final value and backtracks to the original input cells andcreates a script language function that would reproduce my chain. (or even better a C/C++ function). This would be even better if an easy way of incorporating looping was included. (at that point I could give up on programming...)

Cekpet just messaged me this link. Ouch, competition. And it looks good. But still I think there is room for two, and I have some different ideas.MJ << Don't worry that is in the pipeline (mentally). I have the same feeling. I have a plan to incorporate looping, and much more general programming structures into the system. As for the transfer from 'celling' to scripting I have some ideas as well. First I plan to make the UI much closer to logical, sequential thinking than to beancounting so I think the gap will be smaller. Then the way I plan to package calculations will naturally fall over into scripting. Actually my goal is to enable a two way transfer, so that you can construct a 'QuantScript' that does something, and then turn it into a script; on the flip side you would be able to import a script (with some limits I guess) and turn it into a script which you can see on screen and play with, essentially animating the process.One interesting point you and SmartQuant make is that of language. C++ is ideal from many perspectives, and exporting C++ code would be a useful feature. Alternatively I think C++ unsuited to creating a macro language, as SmartQuant have, in some ways. One possibility would be to write the interface and 'glue' in Java, using something like BeanShell (i.e. interpreted Java) as a macro language, and only core functionality requiring speed via JNI in C++.

More challenging would be the problem of enabling the reuse of Excel solutions. One could read them in OK, but parsing them to turn them (reasonably) into QuantScripts could be tough.

I had a look at SmartQuant in more depth, and I think there is no conflict. It seems more focused on integrating to the trading system directly, and providing something which is geared only to finance users, not something flexible for all users.

One thing which is always a pain in Excel, and which could easily be fixed in a new product, is the process of reading and writing data to and from files. The Excel import facility is feeble, and unnecessarily so. Likewise the ability to define arbitrary output formats would be very useful. In my experience Excel is the workhorse (or ass/donkey) of many admin/reporting departments, and rather an obstinate mule.

Simplicio,From the sounds of it the tool you're dreaming of has little to do with Excel. Your best bet is probably to completely forget about Excel or spreadsheets and build your list of features (wish list) from scratch. When that's done, take the results and ask yourself if it resembles anything out there, both from a quantitative tools/visual interface point of view - if there is it may turn out to be something else than a spreadsheet application. If there isn't, then your design may very well be the next killer-app (at least as far as quants are concerned ) You seem to want to turn Excel into something it was never meant to be.P.S. For a different take on the spreadsheet paradigm, take a loo at: DaDispand its quant sibling.

This sounds cool, I've been thinking of doing something to a lesser extent in Octave.Octave is a MatLab clone that works reasonably well; plus it's free software. It might be possible to extend it by writing an open derivatives/quant library in its language, and maybe add a nice financial interface to it (since the source code is avail). Matlab already has a derivatives library (HJM model, trees etc) but it is not free. It's internal language is compatible with the standard "dot M" matlab language many are familiar with, and it already has a really nice library (although far from complete like Matlab)

QuoteOriginally posted by: mjone thing I would like is the ability to turn a string of sheet calculations into a functionWhat I mean is suppose I have a bunch of parameters eg spot, vol, r,d,T,K etc and then I do a bunch of calcs in a lot of cells and then up at the end with a value (eg the call price...)I would like a routine that takes my final value and backtracks to the original input cells andcreates a script language function that would reproduce my chain. (or even better a C/C++ function). There has been some interest of late in this area in the haskell community, (atleast one paper) in the domain of functional programming and i have gone through atleast one paper which talks about Defining financial derivatives as a combinatorial library, and i think this is quite the way to go, once you have the actively-traded ones defined in a functional language and the way a contract gets grown it automatically yields itself to a nomad..yets. A meta-language within a language.

QuoteOriginally posted by: akimonThis sounds cool, I've been thinking of doing something to a lesser extent in Octave.Octave is a MatLab clone that works reasonably well; plus it's free software. It might be possible to extend it by writing an open derivatives/quant library in its language, and maybe add a nice financial interface to it (since the source code is avail). Matlab already hasI think GNU R is the way to go for now, it kicks - sass!!, R is based on the S programming language and is itself a "functional language"

Simplicio, have you worked with scripts/forms in database software? I don't do much programming, but I've set up my recordkeeping in Paradox, which is essentially an orphaned database management system. It beats hell out of spreadsheeting for interative stuff and is tidier (I think) for modifying display. If I programmed enough that my skills were not always deteriorating, I would probably also look into C++ programming packages that include decent amounts of pre-programmed functions and macros as well as reasonable short-cutting for setting up displays and interfaces.