On 2009-11-10, at 07:46, Grant Edwards wrote:
> MacOS applications made the same mistake on the 68K. They
> reserved the high-end bits
At the time the 32-bit Macs were about to come on the market, I saw an internal
confidential document that estimated that at least over 80% of the applications
On 2009-11-10, at 19:07, Steven D'Aprano wrote:
> On Tue, 10 Nov 2009 16:05:01 -0800, Vincent Manis wrote:
> That is incorrect. The original Inside Mac Volume 1 (published in 1985)
> didn't look anything like a phone book. The original Macintosh's CPU (the
> Motorola
On 2009-11-10, at 22:07, Vincent Manis wrote:
> On 2009-11-10, at 19:07, Steven D'Aprano wrote:
>> In fact, in Inside Mac Vol II, Apple explicitly gives the format of
>> pointers: the low-order three bytes are the address, the high-order byte
>> is used for flags: bit
On 2009-11-11, at 14:31, Alain Ketterlin wrote:
> Terry Reedy writes:
>
>> I can imagine a day when code compiled from Python is routinely
>> time-competitive with hand-written C.
>
> Have a look at
> http://code.google.com/p/unladen-swallow/downloads/detail?name=Unladen_Swallow_PyCon.pdf&can=2&
On 2009-11-11, at 21:27, Mensanator wrote:
>> Go doesn't support inheritance, so C++ is pretty much out. C
>> is a lot closer, but still not all that close.
OK, if that's the case (I haven't read the Go documents), then Go is nothing
like Python, no matter how many or few semicolons there are in
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 hig
On 2009-11-12, at 11:36, AK Eric wrote:
> On Nov 12, 11:31 am, Terry Reedy wrote:
>> Alf P. Steinbach wrote:
>>> One reaction to >> http://preview.tinyurl.com/ProgrammingBookP3> has been that turtle
>>> graphics may be off-putting to some readers because it is associated
>>> with children's learni
On 2009-11-12, at 19:13, Peter Nilsson wrote:
> My recollection is that many children struggled with Turtle
> graphics because they had very little concept of trigonometry.
> [Why would they? Many wouldn't learn for another 2-10 years.]
> Adults tend to have even less concept since they almost neve
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
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 mode
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
deca
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 C
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 wi
On 2009-11-13, at 19:53, Paul Rubin wrote:
> "Robert P. J. Day" 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
On 2009-11-13, at 22:51, Alf P. Steinbach wrote:
> It's sort of hilarious.
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
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 opti
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
> inclu
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 imprec
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 mean
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 pu
20 matches
Mail list logo
