Re: LSP and subtype

On Fri, 04 Nov 2005 17:16:36 GMT, H. S. Lahman wrote:

> Responding to Kazakov...
>
>> Which changes nothing. You have timer interrupts and timer counters as the
>> inputs. It is no different to probability or fuzzines. They all are
>> examples of non-computable things which number of states is uncontable. Yet
>> all solutions we are talking about are approximations which use a finite
>> number of states. Moreover these states are different from the original
>> ones. Therefore it stays Turing.
>
> Right. But those "approximations" represent abstractions that provide
> added value beyond Turing.

No, they don't. Added value is when the set of sentences you can deduce in
the language A is larger than one in B. This is not determined by
vocabulary or meanings attached to the words. It is solely by the language
power. This is the power and weakness of computing. The weakness is that
you cannot gain anything beyond Turing. The power is that you can program
everything in a quite abstract application-independent manner. This is why
software design exists as an independent discipline.

> So you are agreeing with me. B-)

As I said before, our differences are philosophical ones. Or turn it this
way: we differ in the meanings of incomputable words, but the language we
are talking is same... (:-))

>>>BTW, UML can be translated into PC code.
>>
>> The quantifier should be "forall". "Exists" is not enough.
>
> But you have lost me here.

To make your point, you have to show that any interesting PC code can be
obtained by translation from UML. Existence of PC equivalent to UML is of
little interest because it could be trivial translation: UML -> NOOP.

>>>On the contrary, I think abstraction is hugely important. Abstraction
>>>is the reason that 3GL code is portable across different platforms. A
>>>similar benefit lies at the 4GL level across whole environments. That's
>>>why I believe defining '4GL' in terms of computing space independence is
>>>the best way to capture what is probably the most important feature.
>>
>> I see no significant difference between "platforms" and "computing spaces".
>> I thought that you meant independence on the mappings computing space ->
>> problem space. That is what we could flag as an OO philosophy. [ It seems
>> totally unrealistic to me. ]
>
> Platforms are a subset of 'computing space'. The notion of 'computing
> space', includes everything from machine instruction sets to caching
> strategies for RDBs. The notion of 'platform' is quite specific and
> only includes instruction set, OS, and peripherals.
>
> 3GLs provide a level of abstraction so that the application developer
> can be indifferent between platforms. However, the 3GL code must
> explicitly address other aspects of the overall computing environment
> that are defined locally (Java Beans, Wind River utility libraries,
> Oracle, X-Windows, caching strategies, networking protocols, etc.). The
> level of abstraction of a 4GL is such that one is indifferent between
> which of those computing space elements are actually available.

Which only means that all these elements are included in the language as
terms. This is a flawed approach because there are too many of them, which
drives the language to a niche. A true abstraction is achieved *within* the
language. This is IMO the essence of languages evolution.

> I am not sure I understand your argument here, but it seems like you are
> agreeing with me. One /can/ deal with concurrency at the 3GL level
> because one can abstract infrastructures to deal with its implementation
> in a Turing environment.

It is upside down. One cannot "deal" with concurrency. One can run a
Turing-complete thing in a concurrent environment. But you cannot describe
or implement the later. You can create anything with LEGO bricks, except
than the bricks itself, reproducing by coupling. (:-))

> So that OOA model is not inherently a computable solution; only its
> implementation in software is.

OK, but the question is in added/lost values:

1. Can any interesting computable be exhaustively described in UML?
Example: matrix inversion

2. Which incomputable solutions can be?
Example: halting problem

You cannot elude questions of this sort if you don't change the problem
space from computing to modeling. I still insist that UML is not a
language, but a tool.

>> So? It is even worse. It was:
>>
>> Customer problem <--> Mathematical problem <--> Software problem
>>
>> Now you are going to replace it with:
>>
>> Customer problem <--> Software problem
>
> Customer Problem -----------> Mathematical formulation
> | |
> | |
> V V
> OOA/D Solution Mathematical Solution
> | |
> | |
> V |
> Software Solution <---------------------+
>
> The pieces of the problem that one resolves via OOA/D can be different
> than those one resolves via mathematics. They all still have to be
> resolved in the final software, but the construction path may be quite
> different.

Ah, that good old "OO isn't mathematic", "OO ellipse is not mathematical
ellipse" etc. No, you don't get me there.

there is absolutely nothing in OO beyond mathematics!

That is precisely the follows:

1. Any OO problem/solution can be described mathematically.
2. There is no unsolvable mathematical problem which can be solved by means
of OO.

>>>>>>This cannot be done automatically.
>>>>>
>>>>>You keep saying things like this but the fact is that commercial
>>>>>transformation engines do such optimization once the nonfunctional
>>>>>requirements are defined. And the resulting code will work correctly.
>>>>>And they have been doing it for nearly two decades.
>>>>
>>>>Yes I do, because it is still unclear which functional requirements qualify
>>>>here.
>>>
>>>All the functional requirements about What the software should do
>>>qualify for the OOA model.
>>
>> Fine. Then I can take any computable problem an present it as a functional
>> requirement. It is equivalent to saying that thing is at least
>> Turing-complete. q.e.d.
>
> But being computable is a nonfunctional requirement, as in the Sears vs.
> web example above. It defines How one solves the problem, not What the
> solution must do.

That's easy. I just make one "reflection" step up. You say 1+1 is
non-functional? Fine! Let's write a calculator. Here you are, it is
functional now.

[ In discussions with MATLAB etc people, there is always someone who
finishes it with: "hey you, write a compiler it that crap." It is a dirty
trick, I admit, but it works, because it is based on the same idea of
conversion of non-functional requirements to functional ones. ]

> We will never agree over that. In my view it is axiomatic that OO vs.
> FP are fundamentally different approaches to software construction at
> every level so the languages that directly support them must necessary
> reflect their differences.

Yes, we have to disagree on this.

>> ... as well as programming languages. I didn't mean data types. I meat
>> types as abstractions. They were well known as mathematical structures like
>> groups, fields, spaces etc long before programming languages evolved.
>
> So? The reason the computing space is deterministic is because the
> whole thing is based on existing mathematics like set and graph theory.

No. Statistics and fuzzy reasoning, both are using non-crisp sets [random,
fuzzy]. A fuzzy or random graph is quite straightforward to define. The
problem is that already arithmetic is an inherently complex thing.
Hilbert's program showed it.

>> I don't see any difference between a sequence of operations and a sequence
>> of messages "I'm done." Both are sequences and both do not answer the
>> question "what did you done?" It is the same abstraction level.
>
> The difference lies in the fact that an I'm Done message implies nothing
> at all about what happens next.

As well as a return from a subprogram or an end of a rendezvous.

>>>[Note that hierarchical structure is not a problem if the algorithm
>>>doesn't change. Once one gets the solution to work, one never has to
>>>touch it again. But when requirements change and force one to
>>>reorganize the tree, modify low level services, or change low level
>>>sequences for some but not all invocation contexts, things get messy
>>>very quickly.]
>>
>> Same as with messages. Only types decomposition makes difference.
>
> Not if the messages are peer-to-peer. Then one does not need to
> reorganize the decomposition tree; one just sends the message to a
> different place.

Compare: gotos are good. If something goes wrong one just changes the
goto's label.

>>>>>It doesn't matter what is /possible/ to
>>>>>do with a 3GL type system. In the OOA/D paradigm one abstracts problem
>>>>>space entities, not functions.
>>>>
>>>>So? Rename "function" to "entity", what changes?
>>>
>>>Semantically I think it is apples and oranges. A function is always an
>>>operation and it only has one functionality. But an object abstracts a
>>>problem space entity with identity that has multiple distinct
>>>properties, only some of which (if any) are opreations. And the object
>>>may have multiple properties that are distinct operations.
>>
>> You are mixing objects and abstract types. Object or function, it is the
>> same abstraction level (2.5GL). Object does not have any operations, same
>> like a function does not possess any operands. It is the type with has! The
>> type brings both together.
>
> Where is this 2.5GL stuff coming from? Objects aren't functions. They
> are abstractions of identifiable entities in some problem space.

Function can be as identifiable as any object. Consider the function Clock.

> As
> such they have a /collection/ of properties that are intrinsic to the
> underlying entity. While objects are abstract because they are
> representative, they are not abstract types because every object
> represents a unique concrete entity.

The properties of an object are determined solely by its type. Type is the
word for "collection of properties." Instances of types are objects.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Universal grammar
    ... One times infinite equals two times ... is a "wormhole" between mathematics ruled by the basic formula ... of accompanying neuronal network computing, ... of today, however, you can never really tame language. ...
    (sci.lang)
  • Re: To understand OOP better...
    ... >>they provide a level of abstraction that is independent of the entire ... > computing environments. ... The UML could not be a 4GL until abstract action language ... >>Static vs. dynamic binding is a pure 3GL implementation issue. ...
    (comp.object)
  • Re: LSP and subtype
    ... that applies to OOA/D since one uses UML as a 4GL to do OOA/D because the level of abstraction is so much higher and one doesn't want the distraction of 3GL details. ... We have come a long was since then so that hardly anyone ever even has to think about Assembly, much less machine language anymore. ... The computing space may be enormously complex but it is still fully deterministic because it is firmly rooted in mathematical models. ...
    (comp.object)
  • Re: object system...
    ... for that you need machine language. ... But the price of abstraction is performance. ... involves the function call overhead, the cost of copying the structs around on the stack, much less efficiently crafted ASM output (since the compiler may lack most of the context from the caller), ... ... But because of the 3GL type system compromises the way one must do that is with a different mindset towards design, not OOPL programming. ...
    (comp.object)
  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)