Notes on two presentations by Gordon Bell ca. 1998
|
From: Eugene Miya on 23 Feb 2010 17:36 In article <3241b658-3244-4652-b104-a3784efdd2d0(a)j27g2000yqn.googlegroups.com>, Robert Myers <rbmyersusa(a)gmail.com> wrote: >On Feb 11, 9:06=A0pm, Nicholas King <z...(a)zerandconsulting.com> wrote: >> 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. > >No, "we" haven't, although, in the world according to Knuth (and his >legion admirers), the important problems are the ones he's good at. DEK is good at fundamental algorithms. He would be the first to admit those aren't enough. Every one should buy his latest selected papers book on Algorithms. The RW has always been complex. We've had to keep our models simple because memory was expensive and limited volume. In some cases spherical geometry and its adjuncts are complex. >I used to worry about this a lot. I've worried about here, and most >of the wisdom I have on the subject, such as it is, I owe to >conversations here. > >I started this thread partly because my concerns have shifted: > >1. Even *if* we knew how to be smarter about programming, I think the >field is essentially dead. The problems that have been explored have >turned out to be disappointing and/or uninteresting. So now we can >virtualize a zillion things on a desktop. What does that get us, >other than that I no longer have to build separate crash and burn >machines? > >2. I don't see any obvious or inobvious way around the communication >problem for big machines, compared to which the "memory barrier," that >scared the hell out of everybody a long time ago, is trivial. > >Eugene's advice and Terje's cleverness and insight notwithstanding, we >don't need more hotshot programmers with sharp pencils. We need a >Wiener, a Shannon, or a Turing. I don't follow. I'm not clear why we need "Wiener, a Shannon, or a Turing." Does this mean we don't need a von Neumann, or a Cray, or an Amdahl? How about Fred Brooks? He and Amdahl as still alive. Or Gordon since he's the subject line. None were programming language experts. We have learned a lot about programming languages since then. Different people see the communication problem in different ways. Knuth isn't good enough? He just gave me another check. Didn't need to. McCarthy (talked to him about Turing a bit) I occasionally drive, he's enough good enough? Having Stanford near by is handy. >None of what I've said would necessarily true of embedded >applications, like robotics, about which I know absolutely nothing, >but you don't need a zigaflop machine at LLNL for those applications. The thing about robotics is that you can't program for geometry. Movement by coordinates means either the robot will damage/destroy itself or something in the surrounding environment. Instead, you program for force first. You have to have a lot of exception handling code. -- Looking for an H-912 (container).
From: Eugene Miya on 23 Feb 2010 17:50 In article <4vrk47-e5e.ln1(a)laptop.reistad.name>, Morten Reistad <first(a)last.name> wrote: >In article <0384a40d$0$1344$c3e8da3(a)news.astraweb.com>, >Nicholas King <ze(a)zerandconsulting.com> 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, >>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. My very first wikipedia error edit was on the supercomputer page which had a quote misattributed to Cray (Ken Batcher really said it): a super turns a CPU bound problem into an I/O bound problem. It's since been completely removed. >>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 true. >doing whatever you can to contain it. But we are forgetting the most >important tool we have for dealing with that complexity : language. Sort of. As a generalization. Some languages. >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. Added late (F. Brooks). A lot of programmers can think that they can beat complexity. >But we can address the semantics by having specialist languages. > >All the large projects I have seen the last 4 decades have had huge >internal semantic gaps. ... Good observation. >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, sendmail.cf 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 >complexity. > >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. Read Jon Louis Bentley's CACM Programming Pearls column Little Languages. Your above stuff reads OK as generalities go. I think that was about 2 decades ago now. -- Looking for an H-912 (container).
From: Eugene Miya on 23 Feb 2010 18:10 In article <d1171014-351b-4b7f-8cdf-9808c2bb3dd9(a)u9g2000yqb.googlegroups.com>, Robert Myers <rbmyersusa(a)gmail.com> wrote: >On Feb 15, 9:20=A0pm, timcaff...(a)aol.com (Tim McCaffrey) wrote: >> In article <4vrk47-e5e....(a)laptop.reistad.name>, fi...(a)last.name says... >> >I have long advocated "surface languages" to address such complaxity. .... >> >We need more languages. >> >> >This is where the junior programmers scream foul, of course. Smart Bell Labs ones didn't. >> >But it is the only path I see to contain complexity. >> >> Interesting, as this is basically what, at least one, (fairly) modern compiler >> does when optimizing. The internal representation is translated into >> something more friendly to whatever optimization pass is being done, then >> the result is translated back into a more generic representation. >> >> Makes my head hurt to look at the code, but it is effective. C is commonly used as an intermediate form these days for a number of reasons including widely available compilers, optimizers (but far from the best), etc. >Maybe I am a junior programmer. New languages, without profound >insight, are academic masturbation. Not all new languages come from academia. You trying to be the Josclyn Elders of c.a.? >Compiler intermediate >representations are a different matter, but who talks about them? IF1 and IF2 from SISAL friends. Various people. -- Looking for an H-912 (container). ------------ And now a word from our sponsor ------------------ Do your users want the best web-email gateway? Don't let your customers drift off to free webmail services install your own web gateway! -- See http://netwinsite.com/sponsor/sponsor_webmail.htm ----
From: Terje Mathisen "terje.mathisen at on 23 Feb 2010 19:03 Eugene Miya wrote: > In article<4vrk47-e5e.ln1(a)laptop.reistad.name>, > Morten Reistad<first(a)last.name> wrote: >> In article<0384a40d$0$1344$c3e8da3(a)news.astraweb.com>, >> Nicholas King<ze(a)zerandconsulting.com> 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, >>> 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. > > My very first wikipedia error edit was on the supercomputer page which > had a quote misattributed to Cray (Ken Batcher really said it): a super > turns a CPU bound problem into an I/O bound problem. It's since been > completely removed. It is interesting to note that the memory wall has made all modern computers into supers according to this rule: Flops are more or less free, only getting from/to memory decides your effective speed. I guess that is one possible reason to remove the quote? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: Chris Gray on 23 Feb 2010 19:12
"Andy \"Krazy\" Glew" <ag-news(a)patten-glew.net> writes: > Again, this predated XML, but I might nowadays write it as: > > <instruction> > <encoding> 0F 1F 11dddsss</encoding> > <assembly>FOO gpr[ddd],x87fp[sss]</assembly> > <microcode> gpr_tmp := mov_x87_to_int( x87fp_sss ) ; gpr_ddd := foo( gpr_tmp ) </microcode> > <compiler-rtl> ... </compiler> > <PRM_documentation> > The foo instruction is the best new instruction since sliced bread > </PRM_documentation> > </instruction> > > Although in the example above I embedded no directly executed C or C++ > code, I can assure you that usually I do so. I think I'm missing the context for this. It's a bit like gcc's "asm" stuff, but I'm betting that's not what it is really for. > I find single assignment code oftenuseful in finding bugs. > So I might want to be able to say > > <normal_c_code> > a=b; > a=c; > <single_assignment> > a=b; > a=c; // this is a syntax error > </single_assignment> > // back to normal imperative code > </normal_c_code> Ok, so here you want to add a restriction on the normal language. I think that would be do-able. However, the next step, that of *changing* the semantics of something already in the programming language, would not be something I would want. That route could be a fast route to damnation! If you need different semantics (rather than just additional restrictions), then you need a different language. In that case, having the tools of some language system available to you is what you need. -- Chris Gray |