From: Daniel Parker on 16 Jan 2006 23:08
"H. S. Lahman" <h.lahman(a)verizon.net> wrote in message
> Responding to Jacobs...
>> SQL is not an implementation. What is the difference between locking
>> yourself to SQL instead of locking yourself to Java? If you want
>> open-source, then go with PostgreSQL. What is the diff? Java ain't no
>> universal language either.
> Of course it's an implementation! It implements access to physical
That literally doesn't make sense. It's like saying that a Java interface
is an implementation because it implements access to the properties of a
> BTW, remember that I am a translationist. When I do a UML model, I don't
> care what language the transformation engine targets in the model
> implementation. (In fact, transformation engines for R-T/E typically
> target straight C from the OOA models for performance reasons.) Thus
> every 3GL (or Assembly) represents a viable alternative implementation of
> the notion of '3GL'.
I think it's fair to say that SQL has, for all its faults, been enormously
successful, to the tune of a multi-multi-billion dollar industry, and that
the UML translationist approach has not. It's been over ten years since the
translationist industry has claimed to have solved the problem of 100
percent translation, but where is it, it's niche, it's nowhere. Other
technologies have arrived, e.g. the W3C XML stack and particularly XSLT
transformation, that dwarf executable UML in application. Why do you think
that is? What do you think it is about software development that makes
executable UML marginal, and other technologies like SQL important?
From: Hasta <hasta on 17 Jan 2006 01:19
> > Well, there is an objective measure of the complexity of
> > 100000110000000000. It's the length of the smallest
> > program able to generate that string.
> > Browse for chaitin-kolmogorov complexity/randomness.
> > A fascinating subject :-)
> This is exactly what I had in mind (although I wanted to emphasize
> Martin-Loef criteria of randomness). Therefore, what is the length of
> that program in the earlier example?
> >From wikipedia: "More formally, the complexity of a string is the
> length of the string's shortest description in some fixed description
> language. The sensitivity of complexity relative to the choice of
> description language is discussed below."
> Excuse me but this is not a very practical suggestion. For finite
> object there is no mathematically sound way to establish that
> is more complex than
> Again, this is what the earler message "no *objective* measure for
> program complexity" was saying.
Well, pick up your prefered language and make it part of your definition
of complexity. You then have a very objective measure. Chaitin uses
a micro-lisp with seven statements.
With all reasonable general purpose languages (including english :-)
complexity (100000110000000000) is greater than complexity
(100000000000000000). In english, the complexity of the later is 6.
The complexity of the former is probably 11.
Of couse, the main problem of C/K complexity is that it is not
computable in general :-)
Have a nice day, Mikito.
From: Dmitry A. Kazakov on 17 Jan 2006 04:07
On Mon, 16 Jan 2006 23:13:45 +0100, Hasta wrote:
> In article <1137447794.122780.151500(a)f14g2000cwb.googlegroups.com>,
> mikharakiri_nospaum(a)yahoo.com says...
>> In general, I agree with Bruce -- there is no objective measure for
>> program complexity. What is the complexity measure of
> Well, there is an objective measure of the complexity of
> 100000110000000000. It's the length of the smallest
> program able to generate that string.
See Richard's paradox.
[ There cannot be objective measure, if no language fixed. ]
Dmitry A. Kazakov
From: Dmitry A. Kazakov on 17 Jan 2006 04:38
On 16 Jan 2006 16:43:10 -0800, Mikito Harakiri wrote:
> Perhaps I have to explain why the concept of "random" sequence is
> important in the context of this complexity discussion. It is
> considered more challenging to generate "random" sequence as compared
> to "nonrandom" one, hence intuitively random sequences are more complex
> than non-random ones.
Huh, 1111111 is exactly as random as 10101101. As a matter of fact, there
is no way to generate random sequences using a FSM. There is no way even to
test if a sequence is a realization of a random process or not. You can
only test some hypothesis H and the answer will be: the probability of H is
in the interval [a,b].
>> What does it mean for an object to be "infinite" in this context, and
>> what does it mean for an infinite object to be "complex" in this context?
> Infinite sequence of 0s and 1s versus finite one. Again, the concept of
> random infinite sequence is quite counterintuitive.
Well, randomness as a whole is counterintuitive and there is nothing to do
> You can predfix
> random sequence with million of 1s, and it would still be a random
> sequence. Once again, there is no way to define what random *finite*
> sequence is.
Egh? What is meant here under non-infinity? That the random variable ceases
to exist after N trials, or that you stop trial after N attempts?
> In layman terms, if you go to Vegas and roulete produces a
> sequence of 10 zeros in a row, you can suspect that roulete is
> defective, but there is no mathematical foundation that would support
> your belief.
Right, which does not ruin Kolmogorov concept of complexity, which fixes
the language. 10101101 looks complex, not because it inherently is, but
solely because of the language humans are using. Change the language and it
might become simple.
Dmitry A. Kazakov
From: H. S. Lahman on 17 Jan 2006 12:00
Responding to Parker...
>>>SQL is not an implementation. What is the difference between locking
>>>yourself to SQL instead of locking yourself to Java? If you want
>>>open-source, then go with PostgreSQL. What is the diff? Java ain't no
>>>universal language either.
>>Of course it's an implementation! It implements access to physical
> That literally doesn't make sense. It's like saying that a Java interface
> is an implementation because it implements access to the properties of a
> physical instantiation.
You have to step up a level in abstraction. Imagine you are a code
generator and think of it in terms of invariants and problem space
The invariant is that all physical storage needs to be accessed in some
manner. There are lots of ways to store data and lots of ways to
access. Therefore ISAM, SQL, CODSYL, and C's gets all represent
specific implementations of access to physical storage that resolve the
Similarly, for interfaces the invariant is that every popular 3GL
provides a type system that allows access to properties. But each 3GL's
type system provides different syntax. Therefore every popular 3GL is a
specific implementation of a type system interface.
>>BTW, remember that I am a translationist. When I do a UML model, I don't
>>care what language the transformation engine targets in the model
>>implementation. (In fact, transformation engines for R-T/E typically
>>target straight C from the OOA models for performance reasons.) Thus
>>every 3GL (or Assembly) represents a viable alternative implementation of
>>the notion of '3GL'.
> I think it's fair to say that SQL has, for all its faults, been enormously
> successful, to the tune of a multi-multi-billion dollar industry, and that
> the UML translationist approach has not. It's been over ten years since the
> translationist industry has claimed to have solved the problem of 100
> percent translation, but where is it, it's niche, it's nowhere. Other
> technologies have arrived, e.g. the W3C XML stack and particularly XSLT
> transformation, that dwarf executable UML in application. Why do you think
> that is? What do you think it is about software development that makes
> executable UML marginal, and other technologies like SQL important?
All the world loves a straight man. B-)
There are actually several reasons. The technology for full translation
has actually been available since the early '80s. However, the
technology had not matured enough for good optimization for _general
computing_ until the late '90s. (Note that it took a decade for C
optimization to get remotely close to the level of optimization that
FORTRAN had in '74 and the translation optimization problem is much more
[FYI, translation has already been widely accepted in niches for many
moons. The ATLAS test requirements specification language is
universally used in milaero and it is translated directly into
executables. That's a billion dollar business. 4GLs like HPVEE and
LabWindows have also been widely used for electronic system analysis and
design. However, the big translation demo lies in CRUD/USER processing.
Any time one develops an application using a RAD IDE like Access or
Delphi one is essentially using translation. That's a multi-billion
dollar niche that has been around since the '80s.]
Probably the second most important reason for translation to be just
exiting Early Adopter Stage is that using translation requires a major
sea change in the way one develops software. It is not just a matter of
pushing a button and having 3GL or Assembly code pop out the other end.
Translation affects almost every aspect of the development process
from the way one approaches problems to the way one tests. From a
Management perspective, major sea changes in the way things are done
spells RISK and that makes selling translation tough.
I think the third reason is developer resistance and NIH. Most software
developers today have literally grown up writing 3GL code. Trying to
persuade them that, of all the things a software developer does, writing
3GL code is the least important is a tough sell. (Going into a sales
presentation is like stepping back in time to the early '60s trying to
sell COBOL or FORTRAN to a bunch of BAL programmers; the arguments are
the same with only the buzzwords changing.)
A fourth reason is the lack of standardization. Until OMG's MDA effort
all translation tools were monolithic; modeling, code generation,
simulation, and testing were all done in the same tool with proprietary
repositories, AALs, and supporting tools. (Prior to UML, they each had
unique modeling notations as well.) That effectively marries the shop
to a specific vendor. In '95 Pathfinder was the first company to
provide plug & play tools that would work with other vendor's drawing
tools. MDA has changed that in the '00s so now plug & play is a reality.
A fifth reason is price. Translation tools are not cheap because they
require very fancy optimization, graphics for model animation, built-in
test harnesses, and a bunch of other support stuff. (Not to mention
cutting edge automation design.) Vendors want to recover that cost so
one has an Occam's Razor: the Early Adopter market is too small to allow
recovery through shrink-wrap pricing but the market will only grow
slowly if one uses recovery pricing.
However, I think all this is kind of beside the point. Technologies
like SQL, W3C XML stacks, and XLST transformation are just computing
space /implementations/ that a transformation engine can target. Part
of the transformation engine's optimization problem is picking the right
computing space technology for the problem in hand from those available.
IOW, apropos of the opening point, the application developer using
translation is working at a much higher level of abstraction so
SQL/XML/XLST concerns belong to a different union -- the transformation
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
Pathfinder Solutions -- Put MDA to Work