Re: Development time vs. runtime performance (was: Fibonacci series recursion error)

Teemu Likonen 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&

Re: Fibonacci series recursion error

Steven D'Aprano 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 category as Pascal, C, and Java. Lisp

Re: python simply not scaleable enough for google?

Vincent Manis 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 Python, and do s

Re: python simply not scaleable enough for google?

Vincent Manis 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

Re: python simply not scaleable enough for google?

Vincent Manis 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 declaration

Re: python simply not scaleable enough for google?

J Kenneth King writes: > mcherm 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 Iron >> Python implementations

Re: python simply not scaleable enough for google?

Vincent Manis 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 Lisp, so we o

Re: python simply not scaleable enough for google?

Vincent Manis 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. Python is a > p

Re: What's the perfect (OS independent) way of storing filepaths ?

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

Re: Bizarre method keyword-arg bug.

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 >> proble

Re: Bizarre method keyword-arg bug.

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 base

Re: Bizarre method keyword-arg bug.

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

Re: definition of a highlevel language?

"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 possib

Re: Article of interest: Python pros/cons for the enterprise

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 ha

Re: Article of interest: Python pros/cons for the enterprise

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.

Re: Why must implementing Python be hard unlike Scheme?

"[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, pe

Re: Why is this loop heavy code so slow in Python? Possible Project Euler spoilers

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.

Re: status of Programming by Contract (PEP 316)?

[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 di

Re: Python's "only one way to do it" philosophy isn't good?

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.

Re: Python's "only one way to do it" philosophy isn't good?

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 languag

Re: PEP 3107 and stronger typing (note: probably a newbie question)

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 questio

Re: Towards faster Python implementations - theory

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 http

Re: merits of Lisp vs Python

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

Re: merits of Lisp vs Python

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 t

Re: merits of Lisp vs Python

"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 th

Re: merits of Lisp vs Python

Paul Rubin 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 som

Re: merits of Lisp vs Python

Paul Rubin 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,