[toronto-lisp] Fwd: [tpm] [Fwd: The Upcoming Dynamic Language Smack Down]

[Vish Singh]

I see, the questions are essentially jumping-off points to talk about
various topics.

I particularly like the point about memory images. I was struggling to
think about something Lisp-specific to say regarding huge codebases,
especially since my Lisp code tends to be pretty compact. In fact, we
were talking about SBCL's save-lisp-and-die functionality at the last
meeting.

Certainly Lisp can interface to SQL databases, and that's a good topic
to bring up. However, every language can do that, and I'm sure Andre
(Erlang) will bring up Mnesia, their distributed database. That's a
very strong point in favour of Erlang's ability to handle data. I
wonder if the Lisp world has something similar, that integrates very
tightly with Lisp.

I have not heard of this before, but it sounds quite powerful:
http://common-lisp.net/project/elephant/

On Thu, Dec 9, 2010 at 10:46 PM, Christopher Browne <cbbrowne at gmail.com> wrote:
> On Thu, Dec 9, 2010 at 9:40 PM, Vish Singh <vishvajitsingh at gmail.com> wrote:
>> That is one unlikely montage :)
>>
>> Yes, I agreed to do the panel. I've been to a couple of GTALUG
>> meetings before and I think it will be a lot of fun, talking about
>> Lisp and also learning about the other languages being presented.
>> Also, it may draw more people into our club.
>>
>> If anyone would like to provide suggestions for how to reply to the
>> points above, they would be quite welcome. Most of them seem
>> straightforward, but I don't know quite what I'd say about "large
>> volumes of code" or "huge amounts of data".
>
> Note that I'm the one to blame for virtually all of the questions!  :-).
>
> For "large code" I'd point at 4 Common Lisp answers, implementation
> dependent, but commonly available strategies:
> a) Tree shakers can shatter off unused code and construct loadable binaries.
> b) Bytecode compiled code is compact & quick to load
> c) Code compiled to machine code is less compact, but more heavily optimized
> d) Memory images can be dumped for fast reload  (clisp -M, anyone?)
>
> For "huge data" I suggest thinking about how you do equivalents to
> database access.  There certainly are libraries allowing access to
> DBMSes and DBM-ish stuff.  If there are other answers commonly used
> for serializing objects, that's good to comment on.
>
> The questions were intended to be pretty open ended.  Don't worry
> about perfect answers everywhere - there's not going to be time to
> explain every little detail, not with 7 people on the panel.  Your
> share of the time isn't a LONG time.
>
> Rather, having generally credible answers can encourage people to dig further.
> --
> http://linuxfinances.info/info/linuxdistributions.html
>