[pro] Lisp and DSLs

[Daniel Weinreb]

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 at 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 at 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 at common-lisp.net
>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
>>
>
>
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20110722/efd96f91/attachment.html>