From mboxrd@z Thu Jan 1 00:00:00 1970 From: William Ahern To: 9fans@cse.psu.edu Subject: Re: [9fans] same functions everywhere Message-ID: <20030508183313.GA26028@wilbur.25thandClement.com> References: <6d1c7c5cd789aff4b0539ab9eed3c168@plan9.bell-labs.com> <200305081814.h48IEr525849@augusta.math.psu.edu> <20030508182121.GA28503@littlegreenmen.armory.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030508182121.GA28503@littlegreenmen.armory.com> User-Agent: Mutt/1.5.3i Date: Thu, 8 May 2003 11:33:13 -0700 Topicbox-Message-UUID: a51c67e4-eacb-11e9-9e20-41e7f4b1d025 On Thu, May 08, 2003 at 11:21:21AM -0700, root wrote: > You guys are headed down the wrong track. > > The right way to program is with small modules written in several > different languages which are meant for specific purposes. > > -Phil/CERisE yeah. and isn't this the philosophy behind Unix and Plan 9? that is, a system that defines a very generic, very abstract and yet very simple means for inter-process communication? once you're holding a huge bag of code, you've already lost the game. all the different pieces are too intertwined, regardless of how well you encapsulate or w'ever within the language. IP, pipe streams and file object namespaces are good; concerning yourself w/ how you link some language into a C library is bad. managing application complexity by building a more complex language seems a tad misguided. in this day and age, w/ all the talk going into "emergent behaviors", complex systems, etc, i'm surprised to hear people arguing for monolithic designs that specify brittle internal procedure and process, rather than simple designs that define simple interactions.