Python vs. Lisp -- please explain

[Roy Smith]

Re: Python vs. Lisp -- please explain

Many people in this thread have said things like:[color=blue]
> Interpreted? Compiled? Scripting language?[/color]

Let me quote from the preface to "Programmin g Ruby: The Pragmatic
Programmer's Guide" by David Thomas and Andrew Hunt (aka "the pickaxe
book").

----------
In the old days, the distinction between languages was simple: they were
either compiled, like C or Fortran, or interpreted, like BASIC. Compiled
languages gave you speed and low-level access; interpreted languages were
higher-level but slower.

Times change, and things aren't that simple anymore. Some language
designers have taken to calling their creations "scripting languages." By
this, we guess they mean that their languages are interpreted and can be
used to replace batch files and shell scripts, orchestrating the behavior
of other programs and the underlying operating system. Perl, TCL, and
Python have all been called scripting languages.

What exactly *is* a scripting language? Frankly we don't know if it's a
distinction worth making.
----------

I've made several attempts to sound intelligent in this thread, and each
time, I bailed out before hitting the Post button. I keep coming back to
the conclusion that Thomas and Hunt said it better than I possibly could.

BTW, if like Python and haven't looked at Ruby, it's worth a glance. If
Python can be called similar to Lisp, then Ruby is even more so. I'm not
fond of Ruby's perlesqe syntax, but I like many of the fundamental ideas.

[igouy@yahoo.com]

Re: Python vs. Lisp -- please explain


Donn Cave wrote:[color=blue]
> In article <mailman.2231.1 140532613.27775 .python-list@python.org >,
> "Chris Mellon" <arkanes@gmail. com> wrote:
> ...[color=green]
> > They won't say Java. Ask them why Python is interpreted and Java isn't
> > and you'll have a hard time getting a decent technical answer, because
> > Python isn't all that different from Java in that regard, especially
> > pre-JIT versions of Java.[/color]
>
> For me that would be partly because I don't know that
> much about Java, honestly. Just searching at random
> for something about the subject, I cam across this -
> http://www-128.ibm.com/developerwork...ive.html?loc=j
> - which seems like it might be of some interest here.
>
> My impression from reading this is that Java actually
> can be compiled to native code, though in 2002 this
> was relatively new.
>
> Donn Cave, donn@u.washingt on.edu[/color]


Excelsior Jet ahead-of-time (AOT) compiler FAQ
"How does it work from the technical point of view?"

http://www.excelsior-usa.com/jetfaq.html#internals

[Paul Boddie]

Re: Python vs. Lisp -- please explain

Kay Schluehr wrote:[color=blue]
>
> I would say yes, it is still "proper Python" in that each RPython
> program is also a CPython program.[/color]

I suppose it depends on which direction you're coming from, in that
many Python programs just wouldn't be able to run in RPython. But then
I can understand the convenience of having a subset of Python that is
executable by CPython, but which can also be inspected and processed
for other purposes, and whose programs maintain their semantics in both
situations.

Paul

[Torsten Bronger]

Re: Python vs. Lisp -- please explain

Hallöchen!

"Paul Boddie" <paul@boddie.or g.uk> writes:
[color=blue]
> Kay Schluehr wrote:
>[color=green]
>> I would say yes, it is still "proper Python" in that each RPython
>> program is also a CPython program.[/color]
>
> I suppose it depends on which direction you're coming from, in
> that many Python programs just wouldn't be able to run in
> RPython. But then I can understand the convenience of having a
> subset of Python that is executable by CPython, but which can also
> be inspected and processed for other purposes, and whose programs
> maintain their semantics in both situations.[/color]

I'm still afraid of the following scenario: Eventually, people might
regard "RPython plus type declarations" (or something similar) as
first-class Python because it's faster and runs on more
implementations , so they try to stick to it. So effectively you
would have changed Python.

Maybe I misunderstood something because I could not follow all of
Kay's text but I think one should not change Python or create a
look-alike to allow for better implementations . The language should
fit my brain rather than an implementation.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Paul Boddie]

Re: Python vs. Lisp -- please explain

Alexander Schmolck wrote:[color=blue]
> Rocco Moretti <roccomoretti@h otpop.com> writes:
>[color=green]
> > I think it's worth pointing out that not all dynamicism is equal, when it
> > comes to difficulty in compiling to machine code.[/color]
>
> No kidding (do you have any idea how this thread started out?).[/color]

I had to remind myself.
[color=blue][color=green]
> > Lisp, like the good functional language that it is, has (primarily) immutable
> > values, and minimal side effects.[/color]
> [further nonsense snipped]
>
> Please don't spread misinformation about things about which you are clueless[1].[/color]

I don't see why you have to be quite so blunt, here. Anyway, some of
the observations made about Python, especially when any comparisons
with Lisp (once corrected) show that Python is more similar to Lisp
than previously thought, are worth considering with respect to things
like type inference and the subsequent generation of low-level code.
[color=blue]
> Footnotes:
> [1] Just as a minor illustrative detail: in python 2 out of 4 builtin
> collection types are immutable (tuples and strings; newer versions also
> have immutable and mutable sets) in CL 5 out of 5 are mutable
> (arrays/vectors/strings, hash-tables, cons cells).[/color]

Well, apart from a brief encounter with Lisp back in the microcomputer
era, I've only just got back into looking at the language, and I
suppose I'll eventually find out how the optional type declarations
mentioned occasionally in connection with Lisp actually manage to
handle the harder problems around efficient code generation. I haven't
really studied type systems or compilers in any depth, however, but
having considered the issues for a while I'd like to think that my
rating has progressed from "clueless" to "mostly clueless" by this
point.

Paul

[Ed Jensen]

Re: Python vs. Lisp -- please explain

Roy Smith <roy@panix.co m> wrote:[color=blue]
> BTW, if like Python and haven't looked at Ruby, it's worth a glance. If
> Python can be called similar to Lisp, then Ruby is even more so. I'm not
> fond of Ruby's perlesqe syntax, but I like many of the fundamental ideas.[/color]

I can't get over Ruby's ugly syntax. :(

Long live Python! :)

[dlp@itasoftware.com]

Re: Python vs. Lisp -- please explain

> Paul Rubin wrote:[color=blue]
> I think both of you are missing the point of the question, which is
> that Lisp is dynamically typed exactly the way Python is and maps to
> Python almost directly; yet good Lisp implementations are much faster
> than CPython.[/color]

But Lisp isn't dynamically typed "exactly the way Python is". Python
documents ways to manipulate the internals of objects at runtime. It
is
possible to add, change or delete methods and slots by directly
changing
the hashtable they're stored in. While CLOS does permit a certain
amount
of runtime redefinition, it is not as completely free wheeling and
unpredicatable.

[Peter Mayne]

Re: Python vs. Lisp -- please explain

Torsten Bronger wrote:[color=blue]
>[color=green][color=darkred]
>>>> Another example: is Java the bytecode, which is compiled from
>>>> Java the language, interpreted or not? Even when the HotSpot JIT
>>>> cuts in?
>>> It is partly interpreted and partly compiled. That's why it's
>>> faster than Python.[/color]
>> But Python is partly interpreted and partly compiled too[/color]
>
> It's byte-compiled for a VM, that's not the same, and you know it.[/color]

Do you mean that Python is byte-compiled for a VM, and not Java, or
vice-versa?
[color=blue]
> I agree that the distinction between interpreted and compiled
> languages is not as clear as between positiv and negative numbers,
> however, neither anybody has claimed that so far, nor it is
> necessary. It must be *practical*, i.e. a useful rule of thumb for
> decision making. If you really know all implications (pros and
> cons) of interpreted languages, it's are very useful rule in my
> opinion.[/color]

So what kind of practical decisions are you trying to make? What kind of
implications are useful to you?

PJDM

[Paul Rubin]

Re: Python vs. Lisp -- please explain

dlp@itasoftware .com writes:[color=blue]
> But Lisp isn't dynamically typed "exactly the way Python is".
> Python documents ways to manipulate the internals of objects at
> runtime. It is possible to add, change or delete methods and slots
> by directly changing the hashtable they're stored in. While CLOS
> does permit a certain amount of runtime redefinition, it is not as
> completely free wheeling and unpredicatable.[/color]

Although CLOS is now part of the Lisp standard I haven't generally
thought of it as describing the language semantics. It's more like a
library routine. Python's standard library generally doesn't provide
documented ways of mucking around with the internal structure of
library classes. CLOS (or something close to it) similarly can and
has been implemented as a Lisp macro package independent from the rest
of the Lisp system.

[Torsten Bronger]

Re: Python vs. Lisp -- please explain

Hallöchen!

Peter Mayne <Peter.Mayne@hp .com> writes:
[color=blue]
> Torsten Bronger wrote:
>[color=green][color=darkred]
>>>>> Another example: is Java the bytecode, which is compiled from
>>>>> Java the language, interpreted or not? Even when the HotSpot
>>>>> JIT cuts in?
>>>>
>>>> It is partly interpreted and partly compiled. That's why it's
>>>> faster than Python.
>>>
>>> But Python is partly interpreted and partly compiled too[/color]
>>
>> It's byte-compiled for a VM, that's not the same, and you know
>> it.[/color]
>
> Do you mean that Python is byte-compiled for a VM, and not Java,
> or vice-versa?[/color]

I mean "Python is byte-compiled for a VM".
[color=blue][color=green]
>> I agree that the distinction between interpreted and compiled
>> languages is not as clear as between positiv and negative
>> numbers, however, neither anybody has claimed that so far, nor it
>> is necessary. It must be *practical*, i.e. a useful rule of
>> thumb for decision making. If you really know all implications
>> (pros and cons) of interpreted languages, it's are very useful
>> rule in my opinion.[/color]
>
> So what kind of practical decisions are you trying to make?[/color]

Which language should I use for my project.
[color=blue]
> What kind of implications are useful to you?[/color]

Speed, ease of programming, necessity to learn/use a secondary
language, issues with distributing, portability.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Paul Boddie]

Re: Python vs. Lisp -- please explain

Torsten Bronger wrote:[color=blue]
>
> Peter Mayne <Peter.Mayne@hp .com> writes:[color=green]
> > What kind of implications are useful to you?[/color]
>
> Speed, ease of programming, necessity to learn/use a secondary
> language, issues with distributing, portability.[/color]

Indeed. Given the various convenient arguments about what "interprete d"
means (and how Python is simultaneously the same as and yet quite
different to Lisp), you'd think that the average C/C++/Lisp programmer
would have to be quite familiar with microcode to finish off a fair
number of their projects.

Paul

[Kay Schluehr]

Re: Python vs. Lisp -- please explain


Torsten Bronger wrote:[color=blue]
> Hallöchen!
>
> "Paul Boddie" <paul@boddie.or g.uk> writes:
>[color=green]
> > Kay Schluehr wrote:
> >[color=darkred]
> >> I would say yes, it is still "proper Python" in that each RPython
> >> program is also a CPython program.[/color]
> >
> > I suppose it depends on which direction you're coming from, in
> > that many Python programs just wouldn't be able to run in
> > RPython. But then I can understand the convenience of having a
> > subset of Python that is executable by CPython, but which can also
> > be inspected and processed for other purposes, and whose programs
> > maintain their semantics in both situations.[/color]
>
> I'm still afraid of the following scenario: Eventually, people might
> regard "RPython plus type declarations" (or something similar) as
> first-class Python because it's faster and runs on more
> implementations , so they try to stick to it. So effectively you
> would have changed Python.[/color]

I wonder why you believe that it would run on more platforms? This
assertion is justifiable with regard of tiny target hardware - but
else? I do think that "RPython++" could be a viable replacement for C
as a systems programming language BECAUSE it is connected closely to
Python. It is a kind of upside-down evolution: a low level language
emerges from a more high level language. We currently know only the
other side of the story. RPython would just be the common denominator
or the language interface. Gilad Bracha suggested optional type systems
for dynamic languages[1] but as it seems to me RPython would be a fine
candidate for a declarative layer, not Python.
[color=blue]
> Maybe I misunderstood something because I could not follow all of
> Kay's text but I think one should not change Python or create a
> look-alike to allow for better implementations . The language should
> fit my brain rather than an implementation.[/color]

It should first of all fit the diversity of a programmers needs. C was
never considered as a hostile brother of Python so why should it be
Pythons own son?

Kay

[Torsten Bronger]

Re: Python vs. Lisp -- please explain

Hallöchen!

"Kay Schluehr" <kay.schluehr@g mx.net> writes:
[color=blue]
> Torsten Bronger wrote:
>[color=green]
>> [...]
>>
>> I'm still afraid of the following scenario: Eventually, people
>> might regard "RPython plus type declarations" (or something
>> similar) as first-class Python because it's faster and runs on
>> more implementations , so they try to stick to it. So effectively
>> you would have changed Python.[/color]
>
> I wonder why you believe that it would run on more platforms?[/color]

I meant the following: RPython programs will run on all Python
implementations , *plus* the environments where only RPython is
possible.
[color=blue]
> This assertion is justifiable with regard of tiny target hardware
> - but else? I do think that "RPython++" could be a viable
> replacement for C as a systems programming language BECAUSE it is
> connected closely to Python.[/color]

Ah, okay. This was a vision that I didn't understand from previous
postings.
[color=blue]
> [...]
>[color=green]
>> Maybe I misunderstood something because I could not follow all of
>> Kay's text but I think one should not change Python or create a
>> look-alike to allow for better implementations . The language
>> should fit my brain rather than an implementation.[/color]
>
> It should first of all fit the diversity of a programmers needs. C
> was never considered as a hostile brother of Python so why should
> it be Pythons own son?[/color]

Because I think it would be tempting to add all necessary declations
in order to make one's code working with the fastest Python
implementation available. After all, mostly we know the types,
although currently we don't declare them. It's a purely
psychological issue: People want to create "valueable" code,
pythonistas even more so, ignoring that eventually it may turn out
that this was not a good idea. Current Python *forces* us to keep
the code as flexible as possible.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Christos Georgiou]

PyPornography was: Re: Python vs. Lisp -- please explain

On Tue, 21 Feb 2006 15:05:40 -0500, rumours say that Steve Holden
<steve@holdenwe b.com> might have written:
[color=blue]
>Chris Mellon wrote:
>[...][color=green]
>> Torstens definition isn't useful for quantifying a difference between
>> interpeted and compiled - it's a rough sort of feel-test. It's like
>> how much of a naked body you can expose before before it changes from
>> art to pornography - it's not something that is easily quantified.
>>[/color]
>[...][/color]
[color=blue]
>Possibly, but if your aim is exposing as much flesh as possible without
>being labeled pornography I think I'd conclude you were in the
>pornography business from the start, albeit masquerading as an "art dealer".[/color]

The difference between art and pornography, as I perceive it, is that you
don't have to think about it when you see pornography. You can even turn
off the audio in cinematographic/video pornography and still the message
comes through (in the vague lines of "jerk off along").

So, in pornography there's no interpretation step involved; therefore, by
pure logic, all "compiled to machine code" languages should be looked down
upon as pornographic, and Python is art. QED.


PS You (the READER) are licensed to substitute other "non compiled to
machine code" languages for Python (the PROGRAM) in the previous paragraph,
just do it outside comp.lang.pytho n (the COMPANY). We don't care what you
do late at night with *your* object of desire, whatever that may be, since
it's not Python.
--
TZOTZIOY, I speak England very best.
"Dear Paul,
please stop spamming us."
The Corinthians