sturlamolden wrote:
On 20 Nov, 11:12, Robin Becker ro...@reportlab.com wrote:
Presumably that means they could potentially run in parallel on the 10 cpu
machines of the future.
I'm not so clear on whether the threadless tasklets will run on separate cpus.
You can make a user-space
On Fri, 20 Nov 2009 09:51:49 -0800, sturlamolden wrote:
You can make a user-space scheduler and run a 10 tasklets on a
threadpool. But there is a GIL in stackless as well.
Nobody wants 10 OS threads, not with Python, not with Go, not with
C.
Also note that Windows has native
In article mailman.224.1257933469.2873.python-l...@python.org,
Robert P. J. Day rpj...@crashcourse.ca wrote:
http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1
thoughts?
Haven't seen this elsewhere in the thread:
Aahz wrote:
In article mailman.224.1257933469.2873.python-l...@python.org,
Robert P. J. Day rpj...@crashcourse.ca wrote:
http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1
thoughts?
Haven't seen this elsewhere in the thread:
On 20 Nov, 11:12, Robin Becker ro...@reportlab.com wrote:
Presumably that means they could potentially run in parallel on the 10 cpu
machines of the future.
I'm not so clear on whether the threadless tasklets will run on separate cpus.
You can make a user-space scheduler and run a 10
In article de86d30e-c9c1-4d30-9e62-d043b78ea...@a31g2000yqn.googlegroups.com,
sturlamolden sturlamol...@yahoo.no wrote:
Also note that Windows has native support for taskelets, regardless
of language. They are called fibers (as opposed to threads) and are
created using the CreateFiber system
Because `language is slow' is meaningless.
Yes. Everyone knows java is faster than Python right?
But look here:
http://gaejava.appspot.com/
(you might want to run it a couple times to see what
it does when it is 'warm'). I don't think this is
a biased test -- I think the author expected to
On 20 Nov, 22:45, a...@pythoncraft.com (Aahz) wrote:
Are you advocating a high-fiber diet?
Only if you are a ruminant.
No really...
Windows has user-space threads natively. But you must reserve some
stack space for them (from virtual memory), which mainly makes them
useful on 64 bit systems.
On 18 Nov, 00:31, Terry Reedy tjre...@udel.edu wrote:
The
problem for the future is the switch to multiple cores for further speedups.
The GIL is not a big problem for scientists. Scientists are not so
dependent on threads as the Java/webdeveloper crowd:
- We are used to running multiple
On 18 Nov, 00:24, greg g...@cosc.canterbury.ac.nz wrote:
NumPy, for example, is *extremely* flexible. Someone put
in the effort, once, to write it and make it fast -- and
now an endless variety of programs can be written very easily
in Python to make use of it.
I'm quite sure David
I don't think Python and Go address the same set of programmer
desires. For example, Go has a static type system. Some programmers
find static type systems to be useless or undesirable. Others find
them extremely helpful and want to use them them. If you're a
programmer who wants a
On Tue, Nov 17, 2009 at 10:48 PM, Aaron Watters aaron.watt...@gmail.com wrote:
I don't think Python and Go address the same set of programmer
desires. For example, Go has a static type system. Some programmers
find static type systems to be useless or undesirable. Others find
them
On 17 Nov, 14:48, Aaron Watters aaron.watt...@gmail.com wrote:
... and I still have an issue with the whole Python is slow
meme. The reason NASA doesn't build a faster Python is because
Python *when augmented with FORTRAN libraries that have been
tested and optimized for decades and are
Language L is (in)efficient. No! Only implementations are (in)efficient
I am reminded of a personal anecdote. It happened about 20 years ago
but is still fresh and this thread reminds me of it.
I was attending some workshop on theoretical computer science.
I gave a talk on Haskell.
I showed
David Cournapeau courn...@gmail.com writes:
On Tue, Nov 17, 2009 at 10:48 PM, Aaron Watters aaron.watt...@gmail.com
wrote:
I don't think Python and Go address the same set of programmer
desires. For example, Go has a static type system. Some programmers
find static type systems to be
On Wed, Nov 18, 2009 at 5:48 AM, Paul Rubin
http://phr...@nospam.invalid wrote:
What about Git? Some people prefer it.
Git is an interesting example, because it both really pushes
performance into its core structure and reasonably complete
implementations exist in other languages. In
David Cournapeau wrote:
It is a bit odd to dismiss python is slow by saying that you can
extend it with fortran. One of the most significant point of python
IMO is its readability, even for people not familiar with it, and
that's important when doing scientific work. Relying on a lot of
David Cournapeau wrote:
On Tue, Nov 17, 2009 at 10:48 PM, Aaron Watters aaron.watt...@gmail.com wrote:
I don't think Python and Go address the same set of programmer
desires. For example, Go has a static type system. Some programmers
find static type systems to be useless or undesirable.
David Cournapeau wrote:
It is often claimed that optimization should be done after having
found the hotspot, but that does not always apply
It's more that if you *do* have a hotspot, you had better
find it and direct your efforts there first. E.g. if there is
a hotspot taking 99% of the time,
On Wednesday 18 November 2009, Terry Reedy wrote:
Python today is at least 100x as fast as 1.4 (my first version) was
in its time. Which is to say, Python today is as fast as C was
then
on the same hardware? That must have been a very buggy C compiler.
Or was it a C interpreter?
--
On Wed, Nov 18, 2009 at 8:31 AM, Terry Reedy tjre...@udel.edu wrote:
David Cournapeau wrote:
On Tue, Nov 17, 2009 at 10:48 PM, Aaron Watters aaron.watt...@gmail.com
wrote:
I don't think Python and Go address the same set of programmer
desires. For example, Go has a static type system.
On Tue, Nov 17, 2009 at 8:41 AM, Rustom Mody rustompm...@gmail.com wrote:
Language L is (in)efficient. No! Only implementations are (in)efficient
I am reminded of a personal anecdote. It happened about 20 years ago
but is still fresh and this thread reminds me of it.
I was attending some
On Tue, 17 Nov 2009 22:11:42 +0530, Rustom Mody wrote:
Language L is (in)efficient. No! Only implementations are
(in)efficient
I am reminded of a personal anecdote. It happened about 20 years ago
but is still fresh and this thread reminds me of it.
I was attending some workshop on
On 14 Nov, 02:42, Robert Brown bbr...@speakeasy.net wrote:
If you want to know why Python *the language* is slow, look at the Lisp code
CLPython generates and at the code implementing the run time. Simple
operations end up being very expensive.
You can also see this by looking at the C that
On 16 Nov, 05:51, sturlamolden sturlamol...@yahoo.no wrote:
NASA can find money to build a space telescope and put it in orbit.
They don't find money to create a faster Python, which they use for
analyzing the data.
Is the analysis in Python really what slows it all down?
Google is a
sturlamolden sturlamol...@yahoo.no writes:
Python is a very clean language held back from widespread use by slow
implementations. If Python ran faster, Go would be unnecessary.
Google is a multi-billion dollar business. They are using Python
extensively. Yes I know about Unladen
greg wrote:
John Nagle wrote:
Take a good look at Shed Skin. ...
You give up some flexibility; a variable can have only one primitive type
in its life, or it can be a class object. That's enough to simplify the
type analysis to the point that most types can be nailed down before the
On 15 Nov, 09:30, Terry Reedy tjre...@udel.edu wrote:
greg wrote:
[Shed Skin]
These restrictions mean that it isn't really quite
Python, though.
Python code that only uses a subset of features very much *is* Python
code. The author of ShedSkin makes no claim that is compiles all Python
In article m2d43kemvs@roger-vivier.bibliotech.com,
Robert Brown bbr...@speakeasy.net wrote:
It's hard to refute your assertion. You're claiming that some future
hypothetical Python implementation will have excellent performance via a JIT.
On top of that you say that you're willing to change
f...@mauve.rahul.net (Edward A. Falk) writes:
If you change the Python language to address the semantic problems
Willem lists in his post and also add optional type declarations,
then Python becomes closer to Common Lisp, which we know can be
executed efficiently, within the same ballpark as C
Paul Boddie wrote:
On 15 Nov, 09:30, Terry Reedy tjre...@udel.edu wrote:
greg wrote:
[Shed Skin]
These restrictions mean that it isn't really quite
Python, though.
Python code that only uses a subset of features very much *is* Python
code. The author of ShedSkin makes no claim that is
On 16 Nov, 05:09, John Nagle na...@animats.com wrote:
Python is a very clean language held back from widespread use by slow
implementations. If Python ran faster, Go would be unnecessary.
That boggles me.
NASA can find money to build a space telescope and put it in orbit.
They don't
On 16 Nov, 05:09, John Nagle na...@animats.com wrote:
Python is a very clean language held back from widespread use by slow
implementations.
Python is clean, minimalistic, and beautiful.
Python don't have bloat like special syntax for XML or SQL databases
(cf C#) or queues (Go).
Most
On 2009-11-13, at 23:20, Robert Brown wrote, quoting me:
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
On 12 Nov, 18:33, J Kenneth King ja...@agentultra.com wrote:
Where Python might get hit *as a language* is that the Python programmer
has to drop into C to implement optimized data-structures for dealing
with the kind of IO that would slow down the Python interpreter. That's
why we have
sturlamolden sturlamol...@yahoo.no writes:
With Cython we can get Python to run at the speed of C just by
adding in optional type declarations for critical variables (most need
not be declared).
I think there are other semantic differences too. For general
thoughts on such differences (Cython
On 2009-11-13, at 23:39, Robert Brown wrote, quoting me:
Common Lisp blends together features of previous Lisps, which were designed to
be executed efficiently. Operating systems were written in these variants.
Execution speed was important. The Common Lisp standardization committee
included
* Vincent Manis:
On 2009-11-13, at 22:51, Alf P. Steinbach wrote:
It's sort of hilarious. g
It really is, see below.
So no, it's not a language that is slow, it's of course only concrete
implementations that may have slowness flavoring. And no, not really, they
don't, because it's just
On 2009-11-14, at 00:22, Alf P. Steinbach wrote, in response to my earlier post.
Anyways, it's a good example of focusing on irrelevant and meaningless
precision plus at the same time utilizing imprecision, higgedly-piggedly as
it suits one's argument. Mixing hard precise logic with
On 12 Nov, 18:32, Alf P. Steinbach al...@start.no wrote:
Of course Python is slow: if you want speed, pay for it by complexity.
Python is slow is really a misconception. Python is used for
scientific computing at HPC centres around the world. NumPy's
predecessor numarray was made by NASA for
* sturlamolden:
On 12 Nov, 18:32, Alf P. Steinbach al...@start.no wrote:
Of course Python is slow: if you want speed, pay for it by complexity.
Python is slow is really a misconception.
Sorry, no, I don't think so.
But we can't know that without ESP powers.
Which seem to be in short
On 12 Nov, 18:32, Alf P. Steinbach al...@start.no wrote:
Hm, this seems religious.
Of course Python is slow: if you want speed, pay for it by complexity.
Not really. The speed problems of Python can to a large extent be
attributed to a sub-optimal VM.
Perl tends to be much faster than
* Vincent Manis:
On 2009-11-14, at 00:22, Alf P. Steinbach wrote, in response to my earlier post.
Anyways, it's a good example of focusing on irrelevant and meaningless
precision plus at the same time utilizing imprecision, higgedly-piggedly
as it suits one's argument. Mixing hard precise
* sturlamolden:
On 12 Nov, 18:32, Alf P. Steinbach al...@start.no wrote:
Hm, this seems religious.
Of course Python is slow: if you want speed, pay for it by complexity.
Not really. The speed problems of Python can to a large extent be
attributed to a sub-optimal VM.
Perl tends to be much
On 2009-11-14, at 01:11, Alf P. Steinbach wrote:
OK, now we've reached a total breakdown in communication, Alf. You appear
to take exception to distinguishing between a language and its
implementation.
Not at all.
But that doesn't mean that making that distinction is always meaningful.
On 14 Nov, 09:47, Alf P. Steinbach al...@start.no wrote:
Python is slow is really a misconception.
Sorry, no, I don't think so.
No, i really think a lot of the conveived slowness in Python comes
from bad programming practices. Sure we can deomstrate that C or
LuaJIT is faster by orders of
Vincent Manis schreef:
On 2009-11-14, at 01:11, Alf P. Steinbach wrote:
OK, now we've reached a total breakdown in communication, Alf. You appear
to take exception to distinguishing between a language and its
implementation.
Not at all.
But that doesn't mean that making that distinction is
* Vincent Manis:
On 2009-11-14, at 01:11, Alf P. Steinbach wrote:
OK, now we've reached a total breakdown in communication, Alf. You appear
to take exception to distinguishing between a language and its implementation.
Not at all.
But that doesn't mean that making that distinction is always
Vincent Manis schreef:
I notice you've weakened your claim. Now we're down to `hard to execute
quickly'. That I would agree with you on, in that building an efficient
Python system would be a lot of work. However, my claim is that that work
is engineering, not research: most of the bits and
sturlamolden sturlamol...@yahoo.no writes:
Python on a better VM (LuaJIT, Parrot, LLVM, several
JavaScript) will easily outperform CPython by orders of magnitide.
Maybe Python semantics make it more difficult to optimize than those
other languages. For example, in
a = foo.bar(1)
b =
On 2009-11-14, David Robinow drobi...@gmail.com wrote:
On Fri, Nov 13, 2009 at 3:32 PM, Paul Rubin
http://phr...@nospam.invalid wrote:
... ?This is Usenet so
please stick with Usenet practices. ?If you want a web forum there are
plenty of them out there.
Actually this is
sturlamolden wrote:
- For the few cases where a graphics program really need C, we can
always resort to using ctypes, f2py or Cython. Gluing Python with C or
Fortran is very easy using these tools. That is much better than
keeping it all in C++.
In case anyone thinks resorting to C or Fortran
In article mailman.270.1257970526.2873.python-l...@python.org,
Terry Reedy tjre...@udel.edu wrote:
I can imagine a day when code compiled from Python is routinely
time-competitive with hand-written C.
I can't. Too much about the language is dynamic. The untyped variables
alone are a killer.
Willem Broekema wrote:
It might have gotten a bit better, but the central message still
stands: Python has made design choices that make efficient compilation
hard.
OK, let me try this again. My assertion is that with some combination of
JITting,
reorganization of the Python runtime, and
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
This whole thread has now proceeded to bore me senseless. I'm going to respond
once with a restatement of what I originally said. Then I'm going to drop it,
and
never respond to the thread again. Much of what's below has been said by others
as well; I'm taking no credit for it, just trying to
On Fri, 13 Nov 2009 18:25:59 -0800, Vincent Manis wrote:
On 2009-11-13, at 15:32, Paul Rubin wrote:
This is Usenet so
please stick with Usenet practices.
Er, this is NOT Usenet.
Actually it is. I'm posting to comp.lang.python.
1. I haven't, to the best of my recollection, made a Usenet
Steven D'Aprano wrote:
On Wed, 11 Nov 2009 16:38:50 -0800, Vincent Manis 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
On Saturday 14 November 2009 18:42:07 Vincent Manis wrote:
3. Very clearly CPython can be improved. I don't take most benchmarks
very seriously, but we know that CPython interprets bytecode, and
thus suffers relative to systems that compile into native code, and
likely to some other
John Nagle wrote:
Steven D'Aprano wrote:
Take a good look at Shed Skin. One guy has been able to build a system
that compiles Python to C++, without requiring the user to add
annotations about types.
In *only* compiles a subset of Python, as does Cython. Both cannot
(currently) do
John Nagle wrote:
Take a good look at Shed Skin. ...
You give up some flexibility; a variable can have only one primitive type
in its life, or it can be a class object. That's enough to simplify the
type analysis to the point that most types can be nailed down before the
program is run.
Steven D'Aprano wrote:
Vincent, could you please fix your mail client, or news
client, so that it follows the standard for mail and news
(that is, it has a hard-break after 68 or 72 characters?
This seems an awfully curmudgeonly reply, given that
word-wrapping is also client-controllable.
On Fri, 13 Nov 2009 04:48:59 -0600, Tim Chase wrote:
There might be some stand-alone news-readers that aren't smart enough to
support word-wrapping/line-breaking, in which case, join the 80's and
upgrade to one that does.
Of course I can change my software. That fixes the problem for me. Or
On Nov 11, 3:15 pm, Terry Reedy tjre...@udel.edu wrote:
Robert P. J. Day wrote:
I can imagine a day when code compiled from Python is routinely
time-competitive with hand-written C.
That time is now, in many cases.
I still stand by my strategy published in Unix World
ages ago: get it working
On Fri, Nov 13, 2009 at 12:19 AM, Steven D'Aprano
st...@remove-this-cybersource.com.au wrote:
On Thu, 12 Nov 2009 22:20:11 -0800, Vincent Manis wrote:
When I was approximately 5, everybody knew that higher level languages
were too slow for high-speed numeric computation (I actually didn't
Aaron Watters wrote:
On Nov 11, 3:15 pm, Terry Reedy tjre...@udel.edu wrote:
Robert P. J. Day wrote:
I can imagine a day when code compiled from Python is routinely
time-competitive with hand-written C.
That time is now, in many cases.
By routinely, I meant ***ROUTINELY***, as in
C become
Tim Chase python.l...@tim.thechases.com writes:
Or even just pipe to
your text editor of choice: vi, emacs, ed, cat, and even Notepad
has a wrap long lines sort of setting or does the right thing
by default (okay, so cat relies on your console to do the
wrapping, but it does wrap).
No, auto
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
On 2009-11-13, at 12:46, Brian J Mingus wrote:
You're joking, right? Try purchasing a computer manufactured in this
millennium. Monitors are much wider than 72 characters nowadays, old timer.
I have already agreed to make my postings VT100-friendly. Oh, wait, the VT-100,
or at least some
On 2009-11-13, at 15:32, Paul Rubin wrote:
This is Usenet so
please stick with Usenet practices.
Er, this is NOT Usenet.
1. I haven't, to the best of my recollection, made a Usenet post in this
millennium.
2. I haven't fired up a copy of rn or any other news reader in at least 2
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
well with dynamic languages. Apart from CL
On Fri, Nov 13, 2009 at 3:32 PM, Paul Rubin
http://phr...@nospam.invalid wrote:
... This is Usenet so
please stick with Usenet practices. If you want a web forum there are
plenty of them out there.
Actually this is python-list@python.org
I don't use usenet and I have no intention to stick
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 efficiently, which
is not the case with
Vincent Manis vma...@telus.net writes:
3. I'm on the python-list mailing list, reading this with Apple's
Mail application, which actually doesn't have convenient ways of
enforcing `Usenet practices' regarding message format.
Oh, I see. Damn gateway.
Stephen asked me to wrap my posts. I'm
Robert P. J. Day rpj...@crashcourse.ca writes:
http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1
thoughts?
I'd bet it's not just about multicore scaling and general efficiency,
but also the suitability of the language itself for large, complex
On 2009-11-13, at 19:53, Paul Rubin wrote:
Robert P. J. Day rpj...@crashcourse.ca writes:
http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1
thoughts?
I'd bet it's not just about multicore scaling and general efficiency,
but also the suitability of
* Rami Chowdhury:
On Thu, 12 Nov 2009 12:02:11 -0800, Alf P. Steinbach al...@start.no
wrote:
I think that was in the part you *snipped* here. Just fill in the
mentioned qualifications and weasel words.
OK, sure. I don't think they're weasel words, because I find them
useful, but I think I
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
On 2009-11-13, at 22:51, Alf P. Steinbach wrote:
It's sort of hilarious. g
It really is, see below.
So no, it's not a language that is slow, it's of course only concrete
implementations that may have slowness flavoring. And no, not really, they
don't, because it's just particular aspects
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
On 14 Nov, 08:39, Robert Brown bbr...@speakeasy.net wrote:
Using Python 3 annotations, one can imagine a Python compiler that does the
appropriate thing (shown in the comments) with the following code.
I can imagine a lot too, but we're talking about Python as it's specified
*today*. The
On Nov 11, 3:57 am, Robert P. J. Day rpj...@crashcourse.ca wrote:
http://groups.google.com/group/unladen-swallow/browse_thread/thread/4...
thoughts?
Google's already given us its thoughts:
http://developers.slashdot.org/story/09/11/11/0210212/Go-Googles-New-Open-Source-Programming-Language
On Nov 11, 7:38 pm, Vincent Manis vma...@telus.net wrote:
1. The statement `Python is slow' doesn't make any sense to me.
Python is a programming language; it is implementations that have
speed or lack thereof.
[...]
2. A skilled programmer could build an implementation that compiled
On Nov 12, 10:07 am, mcherm mch...@gmail.com wrote:
On Nov 11, 7:38 pm, Vincent Manis vma...@telus.net wrote:
1. The statement `Python is slow' doesn't make any sense to me.
Python is a programming language; it is implementations that have
speed or lack thereof.
[...]
2. A skilled
On Thu, 12 Nov 2009 08:35:23 -0800, Joel Davis wrote:
obviously the GIL is a major reason it's so slow.
No such obviously about it.
There have been attempts to remove the GIL, and they lead to CPython
becoming *slower*, not faster, for the still common case of single-core
processors.
And
* Steven D'Aprano:
On Thu, 12 Nov 2009 08:35:23 -0800, Joel Davis wrote:
obviously the GIL is a major reason it's so slow.
http://en.wikipedia.org/wiki/Global_Interpreter_Lock
Uh oh...
No such obviously about it.
There have been attempts to remove the GIL, and they lead to CPython
mcherm mch...@gmail.com writes:
On Nov 11, 7:38 pm, Vincent Manis vma...@telus.net wrote:
1. The statement `Python is slow' doesn't make any sense to me.
Python is a programming language; it is implementations that have
speed or lack thereof.
[...]
2. A skilled programmer could build an
On Thu, 12 Nov 2009 09:32:28 -0800, Alf P. Steinbach al...@start.no
wrote:
This also seems religious. It's like in Norway it became illegal to
market lemon soda, since umpteen years ago it's soda with lemon
flavoring. This has to do with the *origin* of the citric acid, whether
natural
* Rami Chowdhury:
On Thu, 12 Nov 2009 09:32:28 -0800, Alf P. Steinbach al...@start.no
wrote:
This also seems religious. It's like in Norway it became illegal to
market lemon soda, since umpteen years ago it's soda with lemon
flavoring. This has to do with the *origin* of the citric acid,
On Thu, 12 Nov 2009 11:24:18 -0800, Alf P. Steinbach al...@start.no
wrote:
* Rami Chowdhury:
On Thu, 12 Nov 2009 09:32:28 -0800, Alf P. Steinbach al...@start.no
wrote:
This also seems religious. It's like in Norway it became illegal to
market lemon soda, since umpteen years ago it's
* Rami Chowdhury:
On Thu, 12 Nov 2009 11:24:18 -0800, Alf P. Steinbach al...@start.no
wrote:
* Rami Chowdhury:
On Thu, 12 Nov 2009 09:32:28 -0800, Alf P. Steinbach al...@start.no
wrote:
This also seems religious. It's like in Norway it became illegal to
market lemon soda, since umpteen
On Thu, 12 Nov 2009 12:02:11 -0800, Alf P. Steinbach al...@start.no
wrote:
I think that was in the part you *snipped* here. Just fill in the
mentioned qualifications and weasel words.
OK, sure. I don't think they're weasel words, because I find them useful,
but I think I see where you're
On Thu, Nov 12, 2009 at 2:24 PM, Alf P. Steinbach al...@start.no wrote:
You'll also find it impossible to rigorously define dynamic language in a
general way so that that definition excludes C++. g
So, to anyone who understands what one is talking about, interpreted, or
e.g. slow language
On Thu, 12 Nov 2009 12:44:00 -0800, Benjamin Kaplan
benjamin.kap...@case.edu wrote:
Some one could even write an
interpreter for C++ if they wanted to.
Someone has (http://root.cern.ch/drupal/content/cint)!
--
Rami Chowdhury
Never attribute to malice that which can be attributed to
On Thu, 12 Nov 2009 21:02:11 +0100, Alf P. Steinbach wrote:
Specifically, I reacted to the statement that it is sheer nonsense to
talk about the speed of an implementation, made in response to
someone upthread, in the context of Google finding CPython overall too
slow.
It is quite slow.
When I was approximately 5, everybody knew that higher level languages were too
slow for high-speed numeric computation (I actually didn't know that then, I
was too busy watching Bill and Ben the Flowerpot Men), and therefore assembly
languages were mandatory. Then IBM developed Fortran, and
On Thu, 12 Nov 2009 22:20:11 -0800, Vincent Manis wrote:
When I was approximately 5, everybody knew that higher level languages were
too slow for high-speed numeric computation (I actually didn't know that
then, I was too busy watching Bill and Ben the Flowerpot Men), and therefore
On 2009-11-12, at 23:19, Steven D'Aprano wrote:
On Thu, 12 Nov 2009 22:20:11 -0800, Vincent Manis wrote:
Vincent, could you please fix your mail client, or news client, so
that it follows the standard for mail and news (that is, it has a
hard-break after 68 or 72 characters?
My apologies.
1 - 100 of 106 matches
Mail list logo
