Re: Lisp development with macros faster than Python development?..

[jayessay]

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:

> I've been reading the beloved Paul Graham's "Hackers and Painters".
> He claims he developed a web app at light speed using Lisp and lots
> of macros.

That was the original "yahoo store".


> It got me curious if Lisp is inherently faster to develop complex
> apps in.

For complex applications IMO/E there is no question that it is.  But
that is due to a lot of reasons, not only macros.


> It would seem if you could create your own language in Lisp using
> macros that that would be quite an advantage

Here's the story.  It has long been known that "domain specific
languages" (DSL) are a significantly more potent means of producing
applications (or chunks of them) in their domains than any so called
"general purpose" language.  This is true even if the DSL is not a
particularly great piece of work.  There are several examples of this
that most everyone knows about (though they may not realize it), with
"regular expressions" and SQL being among the most obvious.

You can take this further to "application specific languages" (ASL)
which provide even more leverage (though even narrower focus).
Obvious examples of this sort of thing would include AutoCAD and the
"grammar languages" of LALR parser generators.

The reason these things are so much better (for what they do) than
hacking away in your general purpose language is that the abstractions
they provide are much closer to what you want to say.  They are much
more _declarative_ than procedural.  You say _what_ you want done,
instead of specifying a lot of how that will produce the what [1].

Lisp (by which I mean here Common Lisp) macros enable you to build
DSLs and ASLs directly into the base language.  This has several
advantages beyond what the DSLs/ASLs themselves bring; some obvious
ones being:

* You don't have to write lexers and parsers, that part is provided to
  you for "free" by the Lisp reader[2].  In particularly sophisticated
  cases you may need to alter the reader behavior (via the readtables)
  and/or build a code walker to analyze things.  But that would be
  several sigmas out of the norm.

* Better yet, you don't have to write backend code generators.  The
  expansion code of a macro just gets compiled by the Lisp compiler
  (typically an optimizing native code generator).

* The DSL/ASL code can be seamlessly used with the base language (and
  libraries) just like when you use proprietary class libraries you've
  built from within the base language.  Only here, you get a much
  higher level of abstraction and expressive power.  So, you can
  freely use a DSL/ASL where it applies (and get all its advantages),
  but can effortlessly move to the base language when stepping outside
  its focus.

* Better yet, in highly complex application scenarios you can have a
  number of DSLs/ASLs each bringing their own high expressive power
  and move freely among them and the base language.  This should all
  work naturally together in concert.

* Most idioms can be abstracted away and the bugs associated with them
  disappear as well.  You don't have to remember sequences of "right,
  in these cases I first have to do this, then I have to call this
  that and the next thing in this order, and finally make sure I end
  it all with this bit over here."



Their are a few standard red herings trotted out against all this.
For example, "you mean you have a different programming language for
each application!  That's awful." or some variant.

If you think about it for a moment, this is complete nonsense.  Why?
Because you need to do this anyway - building and learning a set of
class libraries for an applicaion or domain (along with all its idioms
as well) is actually much more work, more painful, and (typically)
buys you less.  The point is, you need to learn the "vocabulary" of
application or domain code whether or not you use DSLs/ASLs.  Worse,
without the DSL/ASL approach you also need to learn a number of idioms
of how to _procedurally_ make use of the resources to achieve _what_
you want.

Another red hering goes something like: "it is much harder to learn a
DSL/ASL than to simply use your base general purpose language".  Most
programmer types espousing this are really weird, because in the next
breath they will be extolling the virtues of regular expressions, or
list comprehension or some other DSL that just happens to already be
embedded in their favorite language.  Also, it makes no sense anyway -
DSLs and ASLs are exactly the kind of thing provided to lay people at
the user end of many application scenarios.  Are they really somehow
that much superior to learning these things than programmers?

Another one is "fragmentation".  This is really a kind of variant on
the first, but it is used so often that it deserves its own mention.
Basically the argument is that if you build DSLs and ASLs eventually
your base language "fragments" and you have a few dozen languages
instead.  A few seconds thoug

Re: Lisp development with macros faster than Python development?..

[jayessay]

"Terry Reedy" <[EMAIL PROTECTED]> writes:

> "jayessay" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > 1. Someone recently remarked that good Lisp macros are basically
> >   executable pseudo code.  I think that is pretty much exactly right
> >   and is a pretty good "sound bite" distillation of what it is all
> >   about.
> 
> Several years ago  I remarked that Python reads like executable pseudocode. 
> I still think that that is pretty much right.
> 
> Googling, I discovered that the creators of some thing I had never heard of 
> said the same thing about *their* language a couple of years ago.  I wish 
> web pages, like newgroup posts, were dated so one could better trace the 
> history of such usages.

In the context discussed, the idea was the pseudo code was a _direct_
match to the description of the task in the _domain_.  If your domain
is "algorithms" or some such, then I would agree Python would work as
a reasonably decent pseudo language, otherwise no.  It's too low
level.  Same with base CL.  It's too low level.

/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[jayessay]

Paul Rubin  writes:

> "Kaz Kylheku" <[EMAIL PROTECTED]> writes:
> > > Lisp just seems hopelessly old-fashioned to me these days.  A
> > > modernized version would be cool, but I think the more serious
> > > Lisp-like language designers have moved on to newer ideas.
> > 
> > What are some of their names, and what ideas are they working on?
> 
> http://caml.inria.fr
> http://www.haskell.org

Aren't these "old-fashioned" and boring as well?



/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[jayessay]

Paul Rubin  writes:

> [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 that.

Please note: GC is not part of CL's definition.  It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition.  So,
your point here is actually a category error...


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[jayessay]

"Anders J. Munch" <[EMAIL PROTECTED]> writes:

> jayessay wrote:
>   > Please note: GC is not part of CL's definition.  It is likely not part
> > of any Lisp's definition (for reasons that should be obvious), and for
> > the same reasons likely not part of any language's definition.
> 
> Really?

Really.


> So how do you write a portable program in CL, that is to run
> for unbounded lengths of time?

Make it non-consing (like for any such program in any language).  Of
course, this won't guarantee success as the implementation or OS or
... may leak or other wise cons memory even if your program doesn't.


I'm surprised there are people out there that find this interesting
let alone surprising.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[jayessay]

"Michele Simionato" <[EMAIL PROTECTED]> writes:

> Ken Tilton wrote:
> > I was not thinking about the thread issue (of which I know little). The
> > big deal for Cells is the dynamic bit:
> >
> > (let ((*dependent* me))
> >  (funcall (rule me) me))
> >
> > Then if a rule forces another cell to recalculate itself, *dependent*
> > gets rebound and (the fun part) reverts back to the original dependent
> > as soon as the scope of the let is exited.
> 
> Python 2.5 has a "with" statement (yes, the name is Lispish on purpose)
> that could be used to implement this. See
> http://www.python.org/dev/peps/pep-0343

You are mistaken.  In particular, VAR doesn't have dynamic scope.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[jayessay]

"Michele Simionato" <[EMAIL PROTECTED]> writes:

> jayessay wrote:
> > "Michele Simionato" <[EMAIL PROTECTED]> writes:
> >
> > > Ken Tilton wrote:
> > > > I was not thinking about the thread issue (of which I know little). The
> > > > big deal for Cells is the dynamic bit:
> > > >
> > > > (let ((*dependent* me))
> > > >  (funcall (rule me) me))
> > > >
> > > > Then if a rule forces another cell to recalculate itself, *dependent*
> > > > gets rebound and (the fun part) reverts back to the original dependent
> > > > as soon as the scope of the let is exited.
> > >
> > > Python 2.5 has a "with" statement (yes, the name is Lispish on purpose)
> > > that could be used to implement this. See
> > > http://www.python.org/dev/peps/pep-0343
> >
> > You are mistaken.  In particular, VAR doesn't have dynamic scope.
> >
> 
> I said "it could be used to implement this", and since in a previous
> post on mine in this
> same thread I have shown how to implement thread local variables in
> Python I figured
> out people would be able to do the exercise for themselves.

I was saying that you are mistaken in that pep-0343 could be used to
implement dynamically scoped variables.  That stands.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[jayessay]

"Michele Simionato" <[EMAIL PROTECTED]> writes:

> jayessay wrote:
> > I was saying that you are mistaken in that pep-0343 could be used to
> > implement dynamically scoped variables.  That stands.
> 
> Proof by counter example:
> 
> from __future__ import with_statement
> import threading
> 
> special = threading.local()
> 
> def getvar(name):
> return getattr(special, name)
> 
> def setvar(name, value):
> return setattr(special, name, value)
> 
> class dynamically_scoped(object):
> def __init__(self, name, value):
> self.name = name
> self.value = value
> def __context__(self):
> return self
> def __enter__(self):
> self.orig_value = getvar(self.name)
> setvar(self.name, self.value)
> def __exit__(self, Exc, msg, tb):
> setvar(self.name, self.orig_value)
> 
> if __name__ == '__main__': # test
> setvar("*x*", 1)
> print getvar("*x*") # => 1
> with dynamically_scoped("*x*", 2):
> print getvar("*x*") # => 2
> print getvar("*x*") # => 1
> 
> If you are not happy with this implementation, please clarify.

I can't get this to work at all - syntax errors (presumably you must
have 2.5?, I only have 2.4).  But anyway:

This has not so much to do with WITH as relying on a special "global"
object which you must reference specially, which keeps track (more or
less) of its attribute values, which you use as "faked up" variables.
Actually you probably need to hack this a bit more to even get that as
it doesn't appear to stack the values beyond a single level.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[jayessay]

"Michele Simionato" <[EMAIL PROTECTED]> writes:

> I was interested in a proof of concept, to show that Python can
> emulate Lisp special variables with no big effort.

OK, but the sort of "proof of concept" given here is something you can
hack up in pretty much anything.  So, I wouldn't call it especially
convincing in its effect and capability.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[jayessay]

Alexander Schmolck <[EMAIL PROTECTED]> writes:

> Ken Tilton <[EMAIL PROTECTED]> writes:
> 
> > In Common Lisp we would have:
> > 
> > (defvar *x*) ;; makes it special
> > (setf *x* 1)
> > (print *x*) ;;-> 1
> > (let ((*x* 2))
> >(print *x*)) ;; -> 2
> > (print *x*) ;; -> 1
> 
> You seem to think that conflating special variable binding and lexical
> variable binding is a feature and not a bug. What's your rationale?

And the particularly ugly, crappy, half baked python emulation is what?
A feature?  Right.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[jayessay]

Ken Tilton <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> > jayessay <[EMAIL PROTECTED]> writes:
> >
> >>"Michele Simionato" <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>>I was interested in a proof of concept, to show that Python can
> >>>emulate Lisp special variables with no big effort.
> >>
> >>OK, but the sort of "proof of concept" given here is something you can
> >> hack up in pretty much anything.
> > Care to provide e.g. a java equivalent?
> 
> I think the point is that, with the variable actually being just a
> string and with dedicated new explicit functions required as
> "accessors", well, you could hack that up in any language with
> dictionaries. It is the beginnings of an interpreter, not Python
> itself even feigning special behavior.

Exactly.  Of course this is going to be totally lost on the intended
audience...


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A critic of Guido's blog on Python's lambda

[jayessay]

Alexander Schmolck <[EMAIL PROTECTED]> writes:

> Ken Tilton <[EMAIL PROTECTED]> writes:
> 
> > Alexander Schmolck wrote:
> > > jayessay <[EMAIL PROTECTED]> writes:
> > >
> > 
> > >>"Michele Simionato" <[EMAIL PROTECTED]> writes:
> > >>
> > >>
> > >>>I was interested in a proof of concept, to show that Python can
> > >>>emulate Lisp special variables with no big effort.
> > >>
> > >>OK, but the sort of "proof of concept" given here is something you can
> > >> hack up in pretty much anything.
> > 
> > > Care to provide e.g. a java equivalent?
> > 
> > 
> > I think the point is that, with the variable actually being just a string 
> > and
> > with dedicated new explicit functions required as "accessors", well, you 
> > could
> > hack that up in any language with dictionaries. 
> 
> Great -- so can I see some code? Can't be that difficult, it takes about 10-15
> lines in python (and less in scheme).

Do you actually need the code to understand this relatively simple concept???

/Jon


-- 
'j' - a n t h o n y at romeo/charley/november com
-- 
http://mail.python.org/mailman/listinfo/python-list