Teemu Likonen tliko...@iki.fi writes:
* 2011-05-08T12:59:02Z * Steven D'Aprano wrote:
On Sun, 08 May 2011 01:44:13 -0400, Robert Brown wrote:
Python requires me to rewrite the slow bits of my program in C to get
good performance.
Python doesn't require you to re-write anything in C. If you
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
If you value runtime efficiency over development time, sure. There are
plenty of languages which have made that decision: Pascal, C, Java,
Lisp, Forth, and many more.
I don't understand why you place Lisp and Forth in the same
Vincent Manis vma...@telus.net writes:
The false statement you made is that `... Python *the language* is specified
in a way that makes executing Python programs quickly very very difficult.
I refuted it by citing several systems that implement languages with
semantics similar to those of
Vincent Manis vma...@telus.net writes:
On 2009-11-11, at 14:31, Alain Ketterlin wrote:
I'm having some trouble understanding this thread. My comments aren't
directed at Terry's or Alain's comments, but at the thread overall.
1. The statement `Python is slow' doesn't make any sense to me.
Vincent Manis vma...@telus.net writes:
My point in the earlier post about translating Python into Common Lisp or
Scheme was essentially saying `look, there's more than 30 years experience
building high-performance implementations of Lisp languages, and Python
isn't really that different from
J Kenneth King ja...@agentultra.com writes:
mcherm mch...@gmail.com writes:
I think you have a fundamental misunderstanding of the reasons why Python
is slow. Most of the slowness does NOT come from poor implementations: the
CPython implementation is extremely well-optimized; the Jython and
Vincent Manis vma...@telus.net writes:
On 2009-11-13, at 17:42, Robert Brown wrote, quoting me:
... Python *the language* is specified in a way that
makes executing Python programs quickly very very difficult.
That is untrue. I have mentioned before that optional declarations integrate
Vincent Manis vma...@telus.net writes:
On 2009-11-13, at 18:02, Robert Brown wrote:
Common Lisp and Scheme were designed by people who wanted to write
complicated systems on machines with a tiny fraction of the horsepower of
current workstations. They were carefully designed to be compiled
Stef Mientki [EMAIL PROTECTED] writes:
I (again) wonder what's the perfect way to store, OS-independent, filepaths ?
I can think of something like:
- use a relative path if drive is identical to the application (I'm still a
Windows guy)
- use some kind of OS-dependent translation table if on
Fredrik Lundh [EMAIL PROTECTED] writes:
Robert Brown wrote:
You may find the above surprising, but Common Lisp users expect the
default argument expression to be evaluated anew when needed by a
function call:
well, I'd say an argument based on Common Lisp users is a lot more
dubious
Steven D'Aprano [EMAIL PROTECTED] writes:
On Wed, 20 Aug 2008 13:09:21 -0400, Robert Brown wrote:
In any case, chances are high that Lisp's way of handling default
arguments would have been changed had it been shown to cause performance
problems.
But nobody is suggesting that it would cause
Steven D'Aprano [EMAIL PROTECTED] writes:
On Mon, 18 Aug 2008 03:20:11 -0700, Jasper wrote:
And no, the alternative /does not/ have an equivalent set of surprises
-- it's not like Python is unique in having default arguments.
That's simply not true. I would find this behaviour very
inhahe [EMAIL PROTECTED] writes:
I like to think of a language that would combine low-level and high-level
features to be used at the programmer's whim. C--, High Level Assembly, and
C++ with in-line assembly are examples, but none of them come as high-level
as Python. Other possible
Paul Rubin http://[EMAIL PROTECTED] writes:
Robert Brown [EMAIL PROTECTED] writes:
This is the approach taken by Common Lisp. Often just a few type
declarations, added to code in inner loops, results in vastly faster code.
That is just a dangerous hack of improving performance by turning
Larry Bugbee [EMAIL PROTECTED] writes:
Python's dynamic typing is just fine. But if I know the type, I want
the ability to nail it. ...local variables, arguments, return values,
etc And if I don't know or care, I'd leave it to dynamic typing.
This is the approach taken by Common Lisp.
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
I'm learning Scheme and I am amazed how easy it is to start building a
half baked Scheme implementation that somewhat works.
After knowing Python for *years* I have no idea how to actually
implement the darn thing.
Since you know Scheme, perhaps
Neil Cerutti [EMAIL PROTECTED] writes:
On 2007-09-02, Steven D'Aprano
[EMAIL PROTECTED] wrote:
A big question mark in my mind is Lisp, which according to
aficionados is just as dynamic as Python, but has native
compilers that generate code running as fast as highly
optimized C.
Lisp, as
[EMAIL PROTECTED] (Alex Martelli) writes:
DbC and allegedly rigorous compile-time typechecking (regularly too weak
due to Eiffel's covariant vs countervariant approach, btw...), based on
those empirical results, appear to be way overhyped.
My experience with writing Eiffel code was a bit
Steven D'Aprano [EMAIL PROTECTED] writes:
Graham talks about 25% of the Viaweb code base being macros. Imagine how
productive his coders would have been if the language was not quite
so minimalistic, so that they could do what they wanted without the
_lack_ of syntax getting in the way.
Paul
Stephen R Laniel [EMAIL PROTECTED] writes:
Granted, in a dynamic language we won't always (maybe won't
often) have a situation where the types are known this well
at compile time. But sometimes we will. And it would be nice
to catch these before the program even runs.
So my question is:
Neil Cerutti [EMAIL PROTECTED] writes:
On 2007-06-21, Douglas Alan [EMAIL PROTECTED] wrote:
A prime example of this is how CLOS, the Common Lisp Object System was
implemented completely as a loadable library (with the help of many
macros) into Common Lisp, which was not an OO language prior to
sturlamolden [EMAIL PROTECTED] writes:
On May 10, 7:18 pm, Terry Reedy [EMAIL PROTECTED] wrote:
CMUCL and SBCL depends on the dominance of the x86 architecture.
CMUCL and SBCL run on a variety of architectures, including x86, 64-bit x86,
PowerPC, Sparc, Alpha, and Mips. See
Paul Rubin http://[EMAIL PROTECTED] writes:
Robert Brown [EMAIL PROTECTED] writes:
Luckily, Willem Broekema has written a Python to Lisp compiler called
clpython that can be consulted to answer questions like these.
http://trac.common-lisp.net/clpython/
Does this count as a children
Paul Rubin http://[EMAIL PROTECTED] writes:
Espen Vestre [EMAIL PROTECTED] writes:
Can you redefine CLOS methods without calling CLOS functions that tell
the object system what to expect (so it can do things like update the
MRO cache)? I.e. can you redefine them by poking some random
Stephen Eilert [EMAIL PROTECTED] writes:
So, let's suppose I now want to learn LISP (I did try, on several
occasions). What I would like to do would be to replace Python and code
GUI applications. Yes, those boring business-like applications that have
to access databases and consume those
greg [EMAIL PROTECTED] writes:
From another angle, think about what a hypothetical Python-to-Lisp
translator would have to do. It couldn't just translate a + b into
(+ a b). It would have to be something like (*python-add* a b) where
*python-add* is some support function doing all the dynamic
Paul Rubin http://[EMAIL PROTECTED] writes:
For a long time Scheme had no macros, and Scheme developers who were
exceedingly familiar with Common Lisp were nonetheless willing to get
by without them. So I have to think macros aren't all THAT important.
Scheme did eventually get macros, but
27 matches
Mail list logo
