From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: forsyth@terzarima.net, 9fans@cse.psu.edu Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel From: dbailey27@ameritech.net In-Reply-To: <757a63de546942340d005e0e4fcc471e@terzarima.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-rahzlhhsjvyzwuvpuvxfehhtxc" Date: Mon, 1 Mar 2004 03:46:01 -0500 Topicbox-Message-UUID: 06523f06-eacd-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-rahzlhhsjvyzwuvpuvxfehhtxc Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Nice --upas-rahzlhhsjvyzwuvpuvxfehhtxc Content-Type: message/rfc822 Content-Disposition: inline X-Apparently-To: dbailey27@ameritech.net via web80506.mail.yahoo.com; Mon, 01 Mar 2004 00:20:15 -0800 Return-Path: <9fans-admin@cse.psu.edu> Received: from mx1-milwwi.milwwi.ameritech.net (65.43.19.28) by mta825.mail.sc5.yahoo.com with SMTP; Mon, 01 Mar 2004 00:20:14 -0800 X-Originating-IP: [130.203.4.6] Received: from mail.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mx1-milwwi.milwwi.ameritech.net (8.12.10/8.12.10) with ESMTP id i218KC2d026323 for ; Mon, 1 Mar 2004 02:20:13 -0600 (CST) Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id BDB7719E40; Mon, 1 Mar 2004 03:20:08 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id EE77B19CA6; Mon, 1 Mar 2004 03:20:05 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id EBCF419E3E; Mon, 1 Mar 2004 03:19:41 -0500 (EST) Received: from lavoro.terzarima.net (spc1-york1-5-0-cust44.leed.broadband.ntl.com [80.0.45.44]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 5B73E19E36 for <9fans@cse.psu.edu>; Mon, 1 Mar 2004 03:19:40 -0500 (EST) Message-ID: <757a63de546942340d005e0e4fcc471e@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel From: Charles Forsyth In-Reply-To: <000901c3ff18$950fe250$26fea8c0@SOMA> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Mon, 1 Mar 2004 08:19:16 0000 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu X-Spam-Status: No, hits=2.6 required=5.0 tests=RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Level: ** >>i think it was rob, but i'm not sure, who said: > linear is programming is hard enough, but > concurrent programming is beyond the > 'average' programmer. actually, i'd say that programming generally is hard enough, and not just for the average programmer, and concurrent programming is just a special case within that. more seriously, some things are more clearly expressed and more easily implemented using concurrent processes or perhaps coroutines, so concurrency ought to be taught, and learned, and well. in contrast to the quote above, in an ancient usenet article, in the context of concurrent programming, i am reasonably certain that rob made the observation that as a discipline, we can learn. he used the example of fork(), which was considered `difficult' when it first appeared, compared to existing notions such as `jobs', but after being studied and taught in advanced programming for a time, it become familiar enough that it was suitable to be taught/used much earlier. that seems to me to be a better quote to use. i'd say from my experience that unless people insist on pronouncing themselves `full' and incapable of accepting any new ideas, which certainly does happen, they can typically learn. (otherwise, they end up saying things such as ``in every other X i've ever seen i could always do Y in this particular way''.) i think in many ways concurrent programming is more general than (say) object-oriented programming, and certainly the language constructions can be much simpler than some object-oriented ones. in other words: if you're capable of understanding `finalised virtual hyperstationary factory class', remembering the Java class hierarchy, and all the details of the Java Media Framework, you are (a) a better man than i am (b) capable of filling your mind with large chunks of complexity, so concurrent programming should be simple by comparison. go for it. ps. i made up the hyperstationary, but then again, it's probably a design pattern. --upas-rahzlhhsjvyzwuvpuvxfehhtxc--