(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
