From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <463D98DB.9080404@conducive.org> Date: Sun, 6 May 2007 16:59:07 +0800 From: W B Hacker User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] speaking of kenc References: <2d40d3bd22669001e2af9d4cbef5accd@proxima.alt.za> In-Reply-To: <2d40d3bd22669001e2af9d4cbef5accd@proxima.alt.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 5d160eda-ead2-11e9-9d60-3106f5b1d025 lucio@proxima.alt.za wrote: >>> That C and not assembler ought to be the target language, no matter >>> the application. That assembler is deprecated in favour of C. >> If that ever comes to pass, I'm going back to a wire-wrap tool. >> > I don't see why. I did post the sum-total of assembler coding in the > Plan 9 source directory, libraries and kernel code excluded. Has that > sent you back to the wire-wrap tool yet? No - I am not advocating 'shedding' C - just opposed to mandating it or 'settling' for it to the exclusion of other tools. Absent machine code or asm, there are things that would *have to* be done physically in mask, wire-bonding, or conductor paths. > > Nobody said that C had to be the highest common denominator, only that > it should be the lowest, instead of asm. > Ok - let's say if not C as-we-know-it, then something so close in 'span' as to be functionally the same. 'D' is close, few others are (check the speed alone). A frustration is that the very things that most need a bullet-proof implemntation - kernel and device drivers - are the hardest to get right at any usable speed in anything OTHER THAN C. Yet - despite long-available tools anto prevent it we are still seeing 'buffer overrun...' security holes - and in new code, not just overlooked legacy code. 'D' - whatever else is good or bad about it - at least closes that one off a bit better. >> There *can be no* one-size fits-all final answers unless and until all progress >> is to be called off and stagnation and decline to the death are mandated from >> on-high. >> > That is a view from an uncommon position. It so happens that our > brain can "evolve" much more rapidly than any other organism, with > mutations occurring on a very small timescale. But that perspective > is unique to that particular condition. And one can philosophise on > how useful this continuous mutation really is. > >> Not even for biologicals with billion+ year history. >> > Ever wondered how old the nearest amoeba is? From his point of view, > we're just a passing phase :-) LOL! But that amoeba is not the same as his remotest ancestor, either, if only w/r salinity, temperature, mineral and dissolved gas level adaptation. > >> 'adapt or die' may have long cycle, but it is an unforgiving one. > > As you go higher in evolutionary complexity, this becomes more > important, but it's an artifact, not a natural principle. It stems > from organic complexity that is more dependent on active conditions. > The ability to deal with environmental change without need to mutate > seems to me to be more powerful than the ability to mutate at the > slightest whim. > Point. Though radiodurens is far older than we are, and better traveled it seems.. > C is one such paradigm. Consider that early versions of Windows (up > to 3.1, perhaps) were written in Pascal; at the time that was > Microsoft's bet for the future. C took over from Pascal and only > Microsoft can document the pain and gain of moving to it. Well - if we have to start talking trash, let's pick a better-grade of trash than WinWOES. That's the software equivalent of the feces of common housefly - found nearly everywhere, but not welcome in MY coffee cup! ;-) > That C is > still around today, one dares say _despite_ interference from various > well-meaning committees, speaks volume to the genius of its inventors. Partially, yes. But google a bit and find those inventors have publically expressed mixed feelings about that measure of 'success' at one time or another. The huge code base can be as stifling to improvement as it is useful. Inertia cuts both ways. > I don't think it was blind luck, I think it was genius. That > something may eventually supersede C is unarguable, but I think it > will take a very large paradigm shift to make that possible or > necessary. > > ++L > > ACK. It is already 'necessary' in my view, or at the least 'worth attempting' with greater effort. And that if only to reduce debug labor - and time spent on it. Look at Boeing's rationale for insisting on Ada - and mind - I have no great love for Ada - but the numbers - and the short Sunstrand retraining cycle are eye openers. When a language becomes as ubiquitous as C has, you have to take cognizance of the fact that this means a lot more less-skilled coders have come on board, then either modify the language so they are less likely to screw it up - or change the toolset altogether and restrict 'C use to the very best coders or at least the closest scrutiny. The *bucks* involved in debugging - or even managing - large team efforts in 'C' are getting very serious - especially on projects where time is of the essence. 'Too soon we forget' that C as used in Unix/Linux/Plan9 has had a *very* long and oft painful devel cycle to get here. And we are still fixing old work. So 'genius'? At the time, perhaps. By by now, perhaps as much a product of widely available libs and examples, dogged determination and 'many eyes, many hands'. Not to mention LESSER availability of alternatives. To an extent that is akin to WinWOES pushing out other options merely by displacement. C is not going to 'go away' any time soon - but neither is it necessarily as good a tool for the next 10-20 years as it was the last. Bill