[
Lists Home |
Date Index |
Thread Index
]
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@intergraph.com> 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@gmail.com]
>
> On 2/16/06, Bullard, Claude L (Len) <len.bullard@intergraph.com> 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>
>
>
|
