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

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?
Because I think if you ever did, you would not talk like this.
Am I right?
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 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.

where added tools make things
more complex and less reliable, and programmers less productive.

Tools? Wha ttools?
Do yo uwant to write in machine code?
Or use a Power BASIC, or some otehr compiler?
Or an assembler?
See, you are just chaotically making statements.
The reason could be:
1) Alsheimer
2) You need the opportunity to say how good your products are.
3) You are disappointed with life and especuilly software.


This
is, I hope, a phase that they'll outgrow.

John

Look, I do no tdisagree that for example some IT departments are self-sustaining
clubs jus ttrying to prop up their own image with bloat.
I do not disagree that website creators thse days are often kids that just
want to try the latest FLASH or whatever on YOU.
And that MS creates bloatware... what once was an OS has become a purpose
in itself,, OTOH they provide a lot of free programs with tha tOS too,
from browser to video editing stuff.

Because we are workin gwith highly complex systems, lik a for example the tvideo editor,
yo uneed rather complex software to deal with all the issues.
Why not look at the (C) source of mplayer, of ffmpeg codec, it may change you 'vision' on software.
And if yo uthen write your own little program, you could use wha tyo uhave learned to
add some extra functionaily tha tactully yo ucustomers wou lappreciate otehr then having
to construct - and send single RS232 commands.

The whole world has larger databases then 500 chips in .. BASIC, think airlines
for example...


singe RS232 commands
.

Relevant Pages

  • 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. ... The art of programming is mainly to analyse a problem so you can formulate ... I wrote my first EPROM programmer with zeros and ones in machine code, ...
    (sci.electronics.design)
  • 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: 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)