From: nmm1 on
In article <4b74affb$1(a)darkstar>, Eugene Miya <eugene(a)> wrote:
>Santa Clara Valley is truly an amazing place where you just simply run
>into people.

I was told that the drivers had that reputation when I worked in
San Jose, though I never saw it myself :-)

Nick Maclaren.
From: Morten Reistad on
In article <4b68a53b(a)darkstar>, Eugene Miya <eugene(a)> wrote:
>In article <hk8oks$afs$1(a)>, <nmm1(a)> wrote:
>>In article <4b6780bb$1(a)darkstar>, Eugene Miya <eugene(a)> wrote:

>What computer was that?
>I just got an email marvelling how much "power" is in my particular (or
>any) smart phone. The software is still somewhat broken. But out of
>time context comparisons are only amusing for history sake. Don't get me
>wrong, I highly appreciate my phone's numeric computation capabilities,
>web browsing, realtime traffic displays on maps, etc.
>Sid Fernbach, for whom one of the IEEE awards is given, started a briefly
>class classification of supercomputers, and outsiders wondered what they
>VAX, the mainframe, their IBM PC rated on his scale where a Cray 1 was a
>"Class 6" machine. Since I had Sid handy, I had a chance to ask him:
>Oh, they are "class 1/2". They barely even rate. They aren't supercomputers.
>Other friends (in and out of computing) call computers the drug
>equivalent of pot/marijuana.

Are there any firm definitions of these classes?

>When considering hearing aid or phones, I am reminded of the story of
>the acoustic kitty. And the auditory reasons for the project which tell
>me to this day why hearing aids (and phones) have their limits.
>The behind the scenes punchline not heard in public is
>"What makes you think we stopped there?"

We are seeing huge breakthroughs in audio codecs these days. Phones
audio quality may be improved.

-- mrr

From: Morten Reistad on
In article <0384a40d$0$1344$c3e8da3(a)>,
Nicholas King <ze(a)> wrote:
>On 02/10/2010 01:31 PM, Robert Myers wrote:
>> Andy Glew has said that a supercomputer is nothing but a big, multi-
>> tiered switch. That is certainly what supercomputers have come to be,
>> and I don't want to give the impression that I think even the lame
>> interconnects we get are necessarily trivial.
>I think if we look at this and Terje comment on programming being an
>exercise in caching. It seems to an ignorant outsider that HPC is all
>about communication and furthermore it seems that if the core counts
>keep going up (which I have no doubt will continue to happen) then the
>same shall apply to general purpose computing.
>Programmers are just going to have get used to the real world being more
>complex. Historically we haven't had a huge success with this.

Programming in the real world is about dealing with complexity, and
doing whatever you can to contain it. But we are forgetting the most
important tool we have for dealing with that complexity : language.

The success of languages like PHP is that they make layers of languages
to deal with that complaxity. You program the machine API in plain C,
and build another language on top.

People can handle finite amounts of code lines; and complexity correlates
directly with code lines when the project becomes more than trivial in
size. This is where programming projects explode in programmer count.

But we can address the semantics by having specialist languages. If
we are successful, and PHP is a very good example of such success, we
can break the complexity, measured at "n" into two parts, each with
an internal complaxity of sqrt(n), and get a multiplier working. PHP
is, of course, only useful within it's indended scope of integrating
web pages with business systems.

All the large projects I have seen the last 4 decades have had huge
internal semantic gaps. One example of such a gap is programming
business logic where you have to take care of database consistency
issues all the time.

Or you code a realtime system where you need to handle protocol
specifics together with the logic.

I have long advocated "surface languages" to address such complaxity.
This may mean actually designing new languages for the applications.
There is huge resistance to doing this. But I see daily the productivity
that it generates.

The asterisk extensions language, and sed/awk are examples
that even pretty ghastly languages can boost productivity radically
when they address the issue at hand directly, and manage to bury

We need more languages.

This is where the junior programmers scream foul, of course. When
they have to master language implementation and a new, initially
pretty volatile language definition.

But it is the only path I see to contain complexity.

-- mrr

From: Fred the Freshwater Catfish on

Fred the Freshwater Catfish

From: Fred the Freshwater Catfish on
Oops, sorry. Missed alt.test.

Fred the Freshwater Catfish