Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Using The Principle of Least Power As A Razor
 In the context of the principle of least power as it applies to security I think this quote from the Structure of Authority is appropriate: "Common programming practice grants excess authority for the sake of functionality; programming principles require least authority for the sake of security." http://www.erights.org/talks/no-sep/ The obvious connection is to the authority that a programming language has, what objects is it allowed to manipulate. Cheers, Bryan Rasmussen On 2/17/06, bryan rasmussen <rasmussen.bryan@g...> wrote: > The main problem is how do we define power in this context. > > Last night I was struck by the thought that the dynamic typing is more > power argument does not fit this context in that I am familiar with > this argument as meaning that power = increase in productivity. I'm > not sure if the people arguing typing here are taking that point but > at any rate that is the only context that I am familiar with dynamic > typing leads to an increase of programming language power. > > And obviously it is absurd to argue that one should use the less > powerful solution because the less powerful solution is less > productive. The principle of least power is not arguing for a slowing > down of internet time! I realise I may be misinterpreting the dynamic > typing leads to greater power argument, but power = increase in > productivity is the only context in which I've ever seen the argument > before. > > I think there is also a real problem with the principle in that it has > been observed before that languages over time tend to grow in power. > It is a natural tendency to make a language more powerful in each > stage of its development, if your principle of what makes a language > good is going up against a natural tendency of language development I > worry about the ultimate survival of the principle. > > Of course, since we haven't decided exactly what power means in this > context can we actually decide that languages grow in power in the way > that the word must be used in this context? > > CSS is an example of a language with clearly defined powers, and their > gradual overstepping. > > CSS with the power of setting values of styling on elements is CSS > with the least power necessary for achieving its goal. > > However, in order to make various things work in Internet Explorer, it > was allowed to put script code into the css, via dynamic properties - > http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/recalc.asp > > Increasing the language in power but decreasing the ability to analyse > the stylesheet, and maybe opening the css engine up for security > holes. > > Another increase in power of CSS, the ability to place text into the > document via content: > > This makes analysis of the various components of a web application > more difficult to analyse because now we have the possibility of > putting content into what the user sees from several places. > > Increases in power generally occur when the original problem domain is > expanded or crossed. I believe that the examples of CSS I've given > here basically comply to the usage of the term power as set forth in > the principle of least power. > > > > > > > > > > > On 2/16/06, Bullard, Claude L (Len) <len.bullard@i...> wrote: > > That is my take too. As in 'wisdom of crowds' what one > > asks, 'crowds of what?', the principle isn't applicable > > without knowing the task because it is 'least power > > adequate to the job at hand'. As Jeliffe said, otherwise > > one is a troll. > > > > AJAX is probably applicable to lots of jobs only because > > there are objects around to do the heavy lifting. The > > fact of xmlhttp and loading up a bigChunk of XML, well > > that is how markup was supposed to work from before the > > web and was talked about while everyone else was arguing > > for 'thin clients', 'HTML is holy' and 'separate formatting > > from presentation'. Load balancing IS holy. The client > > gets thicker by task, the separations of formatting from > > presentation IS about reuse, and so on. It isn't that the > > ideas aren't right, they are only right sometimes and > > even then, they may start becoming wrong if practice and > > application take another direction. It's like driving > > in the left lane in right lane countries. > > > > So when I see these principles, I have some scepticism > > until 'crowds of junkyard dog experts' chew on them. If > > they stand up to that (for example, "Dare to do less" was > > debated but it stands up to abuse and is a sound principle), > > they are probably good to go. > > > > len > > > > > > From: Peter Hunsberger [mailto:peter.hunsberger@g...] > > > > On 2/16/06, Bullard, Claude L (Len) <len.bullard@i...> wrote: > > > I hate to see web architectural principles in the same > > > light as pop psychology. So if there really is a > > > deeper and clarifying principle here, one wants to be > > > able to express it in simple terms that the marketing > > > department can't screw up. > > > > Don't think there is any deep clarifying principle here. Even if > > there was, it's not one that couldn't be screwed up.... > > > > I recall the first time I encountered the Mandelbrot set: the > > algorithm looked pretty simple so I coded it up in a high level > > language I was using at the time. It had good floating point > > libraries and I figured things would work fine. The resulting program > > was probably about 200 lines of code and took like 30 minutes to > > produce a very low resolution plot. So next I turned to C. Now I got > > it down to maybe 100 lines of code and I got a better resolution graph > > in a couple of minutes but still nothing like the images that I > > wanted. Finally, I turned to 370 Assembler. I had direct access to > > the floating point registers so I could pull a couple of numerical > > manipulation tricks and I finally got something that ran in seconds > > and produced the results I wanted with probably about 40 lines of > > code. (All of these essentially fed the same graphics library). > > > > Could I base any development principles on this? Absolutely not, the > > result was completely specific to the problem at hand and I think it > > always will be. IT seems to me that finding the "least powerful" way > > to implement an algorithm, system or whatever requires as much > > analysis, modelling and experimentation as any other approach to > > matching requirements to implementation, if not more and is not > > something that can be generalized or encapsulated in a couple of pithy > > sound bites worth of "wisdom".. > > > > ----------------------------------------------------------------- > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > > initiative of OASIS <http://www.oasis-open.org> > > > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > > > To subscribe or unsubscribe from this list use the subscription > > manager: <http://www.oasis-open.org/mlmanage/index.php> > > > > > 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
