Re: Overview Of New Intel Core i7(Nehalem) Processor

On Fri, 12 Jun 2009 17:20:57 GMT, Jan Panteltje
<pNaonStpealmtje@xxxxxxxxx> wrote:

On a sunny day (Fri, 12 Jun 2009 09:01:58 -0700) it happened John Larkin
<jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
<lot435d4s61nprsn4o7lca1vdvemi11gig@xxxxxxx>:


Cars and airplanes and TV sets are much more complex that they used to
be. And they work better, are more reliable, and are safer. When's the
last time you had to clean sparkplugs


Well, as discussed here, a few month back.

Complexity is useful if it's disciplined. A lot of products now,
especially software, are grossly imbalanced: more complexity than
control. I think that will change as things mature.

There was am interesting pattern when affordable plastic-packaged 7400
series TTL was introduced: there was a surge of really bad, complex,
haywire, asynchronous, overheating, noisy logic design. After a few
years, people settled down and started doing more disciplined design.
Most software is still in the asynchronous, haywire mode.

I completely fal to see your argument here.
'asynchronous' and 'haywire', et me ask a direct question, although
I think I knwo teh answere:
When is teh last time yo uwrote a big program for something
tha tdid not yet exist YOURSELF?

This, every line of it:

http://www.highlandtechnology.com/DSS/T346DS.html

And I did the product definition, the schematic design, the manual,
the test procedure, the PC-resident test/cal program, and the embedded
code. I negotiated the FPGA architecture but didn't drive the Xilinx
software myself. Zero bugs in the code. No prototype, and we shipped
the first-etch Rev A boards.


Because I think if you ever did, you would not talk like this.
Am I right?

No.


It seems so silly to time and time again insult programmers and programs
you can get the same 'expert' advice in any bar close before cloing time.

I don't like bad products, and there's tons of really bad software
around. As a science and a practice, software is immature and erratic.
Big software projects fail as often as they succeed, and seldom come
in on schedule or within budget.

Google "software project failure." If you find the results offensive,
don't blame me.








I was thinking last night that maybe we will have programming systems that
just understand normal languages, like English.

That would be great for "popular" computing. But serious (critical)
apps will still need mathematical, disciplined, unambiguous languages.
C isn't one.

See, tha tis wha tI mean, yo udo not knwo C, and yet yo uhave more opinions
about it then me, and I have used it since the eigties o na daily basis.


Then I remembered I had seen some announcement many years ago for a programming system like that.
Never heard of it again.
Then I thought "Not surprising, considering how chaotic many people think".
The art of programming is mainly to analyse a problem so you can formulate
what needs to be done step by step.
Once you know what needs to be done to do each step, then you can also write the code.
The language is highly irrelevant, you can even use machine code if you must.
I wrote my first EPROM programmer with zeros and ones in machine code, no assembler see.

Some languages encourage risk.

And so does hardware design! How many transistors have ended up in smoke in labs I dunno, but I think lot.
And houses have burned down because of bad hardware, recalls of stuf flike TVs have happened.


First there were tubes, then there were transistors, then some transistors in an integrated
chip, then 'MSI', then 'LSI', then complete micro controllers + FLASH memory,
complete FPGAs + FLASH, complete small computers with lots of RAM and all sorts of interfaces
using advanced OSses like Linux, so next will be:
Networks of these things, we are seeing the multi cores appearing like daisies in
this time of year, you liked them so much, virtualisers
running more then one highly complex OS on the same chip.
If you think it will get simpler do a check for Alzheimer perhaps.

My designs now use FPGAs, hundred megasample adc and dacs, uPs,
ethernet, 8 layer boards with BGAs, chopper amps, lasers, exotic
filters. And they are at heart better organized and certainly more
reliable than "simpler" stuff I did 20 years ago. Visually, they
certainly look more organized. They tend to work, quickly, the first
pass, too, even though they are far more complex than things we used
to do. We can now afford to throw complexity at problems and buy
predictability. Would a FIFO help? A digital filter, or a numerical
calibration and linearization routine? No problem.

So now yoy uare contradictin gyourself, as yo uwre arguing things were getting simpler.
To argue for teh sake of arguing may help your writing skills, but it does look silly.



Better parts and tools should allow you to build better organized and
more reliable products, not the reverse. Software mostly still
operates in the immature reverse mode,


Here we go again.
Why not learn to program.

I've probably written a million lines of code in my life.

John


.

Relevant Pages

  • Re: Speculative Design Hypothesis (with predictions) 2nd draft
    ... languages are human products, but that does not make them "designed". ... natural languages has nothing to do with design. ... wings and echolocation. ... Because the genetics and fossil evidence show otherwise. ...
    (talk.origins)
  • Re: Overview Of New Intel Core i7(Nehalem) Processor
    ... people settled down and started doing more disciplined design. ... apps will still need mathematical, disciplined, unambiguous languages. ... See, tha tis wha tI mean, yo udo not knwo C, and yet yo uhave more opinions ... I wrote my first EPROM programmer with zeros and ones in machine code, ...
    (sci.electronics.design)
  • Re: high level languages for synthesis
    ... languages are more distinct from their cycle-accurate cousins than ... straightforward to use a spiral design methodology using VHDL, ... implement a wide variety of other scientific algorithms. ... FPGA-targeting C-syntax HLL is somehow inherently sequential. ...
    (comp.arch.fpga)
  • Re: Speculative Design Hypothesis (with predictions) 2nd draft
    ... languages are human products, but that does not make them "designed". ... natural languages has nothing to do with design. ... evidence to point to them not being human. ... wings and echolocation. ...
    (talk.origins)
  • Re: Speculative Design Hypothesis (with predictions) 2nd draft
    ... languages are human products, but that does not make them "designed". ... natural languages has nothing to do with design. ... wings and echolocation. ... Because there's much more variation in mammalian forelimbs than in bat ...
    (talk.origins)