Paddy3118 wrote:
> This month there was/is a 1000+ long thread called:
> "merits of Lisp vs Python"
> In comp.lang.lisp.
>
> If you followed even parts of the thread, AND previously
> used only one of the languages AND (and this is the
> crucial bit), were persuaded to have a more positive view
>
Paul Rubin wrote:
> [EMAIL PROTECTED] writes:
> > So don't (poke (random) value). That would be obvious to anyone
> > capable of writing a device driver in C or Lisp or Oberon or
>
> Similarly in C programs, don't do
>
> *random = 0;
>
> Avoiding that is easier said than done. C programs s
Paul Rubin wrote:
> [EMAIL PROTECTED] writes:
> > Even regarding interupts, I don't see a problem without a solution:
> > (with-interupts-and-garbage-collection-disabled
> >(poke destination (peek source))
>
> It's not just GC or interrupts, it's the possibility of clobbering the
> Lis
Paul Rubin wrote:
> [EMAIL PROTECTED] writes:
> > I should assume you meant Common Lisp, but there isn't really any
> > reason you couldn't
> >
> > (poke destination (peek source))
>
> That breaks the reliability of GC. I'd say you're no longer writing
> in Lisp if you use something like tha
Paul Rubin wrote:
>
> [...] There are programs you can write in C
> but not in Lisp, like device drivers that poke specific machine
> addresses.
>
I should assume you meant Common Lisp, but there isn't really any
reason you couldn't
(poke destination (peek source))
in some version of Lisp
Ken Tilton wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Code is data is code
>
> I was hoping no one would make that mistake. :) macros are all about
> code is data, but code is not data in Python* so the two words code and
> data serve to differentiate them for Pythonistas.
>
I disagree. I frequent
Ken Tilton wrote:
> Andrew Reilly wrote:
>
> > That all looks like data.
>
> No, not reverse, the part you did not understand. I do not mean what the
> code was doing, I meant that it was code.
>
Code is data is code - even in Python:
skills_table = [
{
"title": "Absolute Value",
"annotati
