If you have people making messy spreadsheets that are hard to maintain, you might want to look at this. I have not used it myself:
http://www.modelsheetsoft.com But it's from Howard Cannon, Symbolics co-founder and main inventor of Flavors, an ancestor of CLOS. -- Dan On Fri, Jul 22, 2011 at 9:56 AM, Thomas M. Hermann < thomas.m.herm...@odonata-research.com> wrote: > (1+ *) > > I am knee-deep daily in one of those communities. Time and time again, I > request that people send me the raw text files of data as opposed to poorly > importing them into an Excel spreadsheet. Or, I'll get some spreadsheet > "analysis" that contains brittle calculations that require lots of hand > editing if you wish to update data, (select ranges, etc.). If people are > going to rely on Excel to the extent that they do, I wish they'd at least > learn VBA. > > I have a large body of lisp code that is purely an abstraction layer to > insulate me from a very poorly conceived DSL for a finite element analysis > package. Having the lisp abstraction is like a productivity accelerator. The > more I have abstracted, the more productive I am and the more time I have to > implement higher level abstractions. > > Tom > ---------------------------------------------------------------- > Thomas M. Hermann > Odonata Research LLC > http://www.odonata-research.com/ > http://www.linkedin.com/in/thomasmhermann > > > > On Fri, Jul 22, 2011 at 2:54 AM, Marco Antoniotti < > antoniotti.ma...@disco.unimib.it> wrote: > >> +1 >> >> May I also say that there are entire scientific, financial, and accounting >> communities that should be barred from using Excel? >> >> Cheers >> -- >> MA >> >> >> >> On Jul 22, 2011, at 09:14 , Daniel Pezely wrote: >> >> > ... >> >> > Lessons learned: (a few more while I'm here) >> > >> > 1. Know your audience, and build for the correct users. >> > >> > 2. Build the right tool. (I'm a systems programmer; a good stats >> person would likely have come up with a better work-flow, likely using R so >> rich reports could also be generated quickly.) >> > >> > 3. Good language design can be challenging. I would have been better >> off (perhaps) stealing SQL or XQuery's FLOWR conventions than inventing my >> own "simple" set of commands. (Syntax is another matter... as you know.) >> > >> > 4. Being adept at backquotes, comma substitution and unrolling lists is >> not necessarily enough skill to create a good, clean DSL implementation. >> But keep trying. Do your best to make one for "keeps". Then throw it >> away, anyway. It's important to not hold anything back in the first >> version. Ah, experience! (I'll likely go at this one again just for the >> fun of it.) >> > e.g., unrelated project from years ago: >> http://play.org/learning-lisp/html.lisp >> > >> > 5. Collaborate: Get input from others. My co-workers who also use >> Common Lisp were many time-zones and an ocean away, busy with looming >> deadlines of their own. However, their 10 years CL experience to my 5 (and >> their far deeper stats familiarity) would certainly have helped here. >> > >> > -Daniel >> >> -- >> Marco Antoniotti, Associate Professor tel. +39 >> - 02 64 48 79 01 >> DISCo, Università Milano Bicocca U14 2043 >> http://bimib.disco.unimib.it >> Viale Sarca 336 >> I-20126 Milan (MI) ITALY >> >> Please note that I am not checking my Spam-box anymore. >> Please do not forward this email without asking me first. >> >> >> >> >> >> >> _______________________________________________ >> pro mailing list >> pro@common-lisp.net >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro >> > > > _______________________________________________ > pro mailing list > pro@common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro > >
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro