Re: Should Inline be private in the private part of a package spec?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 22 Aug 2012 15:12:41 +0200, Georg Bauhaus wrote:

> On 22.08.12 09:32, Dmitry A. Kazakov wrote:
>> On Tue, 21 Aug 2012 23:35:35 +0200, Pascal Obry wrote:
>> 
>>> Dmitry,
>>>
>>>> The problem of transformation XML documents does not exist. I don't see why
>>>> data exchange needs that. I don't see why any transformations would be
>>>> necessary between systems.
>>>
>>> You don't see why because you seem to try hard to deny XML any benefit.
>> 
>> It is not a hard try. Yes, I have an opinion on XML because in my job
>> (automation systems and embedded) XML became a real plague. I asked others
>> to put up a practical case where XML might be useful, technically useful,
>> rather than per popularity vote or legacy. Nobody proposed any.
>> 
>>> Exchanging structured data is an important point.
>> 
>> It is an important problem, yes, but XML is poor for that. XML
>> 
>> 1. is extremely inefficient
> 
> As always, the question is inefficient for what and for whom.

For the network and the peers. The measures for both can be easily
provided.

>> 2. fails to capture the structure (e.g. recursive, interlinked structures)
> 
> ?

Take Containers.Doubly_Linked_Lists as an example. The closure object of a
list is the structure in question.

>> 3. lacks even basic data types (everything is string, not even weakly
>> typed)
> 
> ?

Compare XML to Ada or C. The latter languages have elementary data types
which can be used in algebraic operations constructing new types.

>> 6. requires complex, resource consuming, vulnerable infrastructure like
>> parsers
> 
> Yes, there are cases where such parsers are needed, and even more
> of such things. For example, if you run Google.

Remember that the case in question is "exchanging structured data," not
running Google.
 
>> 7. is not redundant and at the same time absolutely permissive (requires
>> complex validation of itself)
> 
> Another set of unqualified word ({"redundant", ... })

http://en.wikipedia.org/wiki/Redundancy_%28engineering%29

You could argue that redundancy is not required for a layer running over a
safe transmission channel, but then what is the purpose of the abundance of
XML's syntactic excesses? You cannot have both.

>>> Before XML we were
>>> using many format and we had to write parsers for all those formats in
>>> every languages. Now with XML (and the corresponding xsd, or wsdl) it is
>>> possible to parse (and *validate*) any data set coming from any
>>> applications.
>> 
>> And it is still so with XML, because XML considered for data exchange is
>> not of the application level.
> 
> You don't have to write parser infrastructure when you
> can use XML.

1. I don't need parser if I don't use XML.

2. I need to write the application layer serializing and deserializing
object in any case.

3. Serialization is much simpler without XML. See Ada.Streams.

>> It is just a very ugly
> 
> What does "ugly" mean, technically?

Technically ugly means inefficient.

>> and unsafe
> 
> Another claim. XML may have been called robust (in that the
> brackets are named, e.g., not overloaded). Has it ever been
> called safe?

Safety could be against

1. intentional misuse

2. unintentional errors

>> The application level is still to
>> develop and XML is no relief, it just complicates things.
> 
> A problem that XML-based setups solve is when they greatly
> simplify the combinatorial explosion of some ad-hoc variety
> of mutually semi-compatible ways of exchanging data.

Huh, XML indeed simplifies combinatorial explosion in many possible
meanings of this word. There is a multitudes of XML representations,
equivalent or almost equivalent variants which make versioning and
validation difficult, at best. There is a multitude of XML tools to buy, to
validate, to train personnel, to maintain, to scrape. There is a multitude
of network traffic, disk space, CPU time lost due to XML. Most of mentioned
is more than O(n). Some could be O(exp n). So, yes, combinatorial
explosion, shit hitting the fan...

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