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.hermann@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.marco@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