[
Lists Home |
Date Index |
Thread Index
]
we used to call this programming 101.
the great trio of computer science - edsgar djikstra, niklaus wirth, and
donald knuth - built on the very simple definitions of alan turing to
come up with computer langauges that were "complete" over the problem
space of a turing machine.
everything else has been complication to make life easier. "C" is
another great example of a minimal language that was complicated to make
life easier. somehow minds more ordinary than dennis ritchie felt that
by fixing c they could fix programming mistakes. my view was and is that
if finding pointer errors is beyond you, probably the so too is the
programming task - personal opinion, but you might want to correlate
this against project issues.
xml is part of a different problem space. syntax to describe something -
documents, data, process. it doesn't really matter what - but it shares
with databases the quality that it is representational, not programatic.
programs can then work on it.
so what you're describing roger seems to me is the classic modelling
process. simplify a complex scenario to get the elements and understand
them, then look at the details from the original that aren't explained
and add complexity to the model in a controlled and understood way.
hopefully then we turn the original chaos into a well understood system.
at least, like you, this is how i build large complex applications......
rick
Roger L. Costello wrote:
> Hi Folks,
>
> I observed a few days ago that XML is able to achieve virtually
> endless complexity through the use of a couple simple building blocks
> and a couple simple assembly mechanisms. (I am continuing with the
> Lego analogy)
>
> We all know that XML has its ancestry in SGML and XML is a
> simplification of SGML. So, to achieve forward progress a complicated
> technology was simplified (progress via simplification).
>
> There are other technologies which achieve great complexity with
> simple building blocks and simple rules. For example, Cellular
> Automata. I don't have enough experience to state for certain, but
> people tell me that the programming languages Lisp and Forth have
> simple building blocks and simple rules, and are able to achieve
> tremendous complexity.
>
> It is asserted that all the amazing complexity seen is nature is
> achievable by using simple components and simple rules [1].
>
> It occurs to me that in the development of a technology there are 2
> approaches:
>
> Approach 1 - Progress via Simplification
>
> With this approach the attitude is "what are the simplest collection
> of components needed to achieve all the complexity required?".
> Interestingly, this approach strives for greater complexity by
> removing complexity.
>
> I think that typically the right collection of components is not found
> on the first attempt. Typically, the first attempt produces a
> collection of components that are too complicated. So, successive
> versions of the technology result in simpler components. But these
> simple components can be assembled to produce results that are as
> complex (or more so) than the earlier components.
>
> As noted above, XML is an example of a technology that made forward
> progress by simplification (of SGML).
>
> For the past 6 months I have been putting together a demo. The first
> version of my demo was horribly complicated. Then I realized how to
> simplify it. The second version was much simpler (and more powerful)
> than the first version. But even the second version was too
> complicated. After some time I realized that it could be simplified
> still further. I went through 6 versions, each version getting
> simpler and more powerful. My current version is astonishingly
> simple. This experience humbled me (it's humbling to scrap all my
> hard work and complex code in favor of something that is simple;
> somehow complex code seems more "manly") and it opened my eyes to the
> value of progress via simplification.
>
> Approach 2 - Progress via Complexification
>
> With this second approach the attitude is "the existing functionality
> does not give users all the desired complexity, so let's add more
> functionality". Thus, greater complexity is achieved by adding more
> complexity.
>
> As I look at the next-version of some of the XML technologies it
> appears that this second approach is being taken. For example, with
> XSLT 2.0 and XPath 2.0 you are able to accomplish what was extremely
> difficult (or impossible) in 1.0. However, this enhanced complexity
> is achieved by adding more complexity to the language. I believe
> that XML Schemas 2.0 is going along the same path - more complexity by
> adding more complexity. I am not trying to "knock" any of these
> technologies. In fact, as a technology geek, I like the cool stuff
> that has been put into the 2.0 version of XSLT and XPath.
>
> But I keep thinking about the lessons I learned from my demo, and keep
> wondering if the 2.0 version of these XML technologies could have
> achieved the additional complexity by recognizing "the collection of
> components in 1.0 are wrong; they do not provide the desired
> complexity; let's scrap those components and find the right collection
> that's simple yet powerful".
>
> Perhaps for some things progress must come about by adding more
> complexity. I don't know. What do you think? /Roger
>
> [1] A New Kind of Science by Steven Wolfram.
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
