Is c++ only better c ?

[Stefan Ram]

What are the alternatives?

A popular data language today is »JSON«.

Some years ago, »YAML« was as popular.

Sometimes files of type ».ini« or ».csv« are used,
but - just like S-Expressions - these do not have
/one/ /single/ specification document.

The markup-language »Unotal« is being
developed, implemented and used by me.

http://www.purl.org/stefan_ram/pub/unotal_en

I am not sure what is the most appropriate newsgroup
to discuss this. Maybe »comp.lang.misc«.

 

[Juha Nieminen]

XML is primarily meant for the (easily
portable) exchange of data between programs

And XML is one of the least efficient ways of doing that, spacewise.
This is especially true with large amounts of data which have to be
transferred eg. over a network. XML is hyperverbose, often for no good
reason.

 

[Gerhard Fiedler]

And XML is one of the least efficient ways of doing that, spacewise.
This is especially true with large amounts of data which have to be
transferred eg. over a network. XML is hyperverbose, often for no good
reason.

Yes, but that's a different thing, and I think that this is what computers
are for XML is usually quite easily compressable, so for network
transfer this shouldn't be a problem.

Gerhard

 

[Juha Nieminen]

Yes, but that's a different thing, and I think that this is what computers
are for XML is usually quite easily compressable, so for network
transfer this shouldn't be a problem.

And this already presents one of the problems with XML. For efficient
transfer you have to use some unrelated format and have both ends agree
on it. You immediately destroyed one of the key "advantages" of XML.

 

[Gerhard Fiedler]

[...] since C's long-term niche is clearly with developers who need just
enough abstraction to let the same code run on target platforms with
different assembly languages.

I find often that many who use (and like) as well as many who don't use
(and sometimes hate) C don't understand this particular position of C, as
some sort of portable assembly. It clarifies a lot about why C is what it
is -- and also where it is a good choice.

Gerhard

 

[James Kanze]

(As a side note, I detest XML precisely because of that: XML
has been designed to make it easier to create programs which
read XML, at the cost of making it harder for users to write
XML.

It's not quite the same context. While XML is not without its
problems, one of the goals is to allow non-programmers to design
their own language, more or less easily. And because all of
such languages have the same basic grammar, they can all be
based on the same parser, and can all benefit from the same
smart editor tools.

(Basically XML is pre-tokenized data, which lifts the need for
the program reading XML to tokenize it.) This is the complete
reversals of what software should be all about: Software
should do as much as possible to make the life of the user as
easy as possible, not the other way around!

In the case of XML, it is the user who defines the language.

As an example of what I'm talking about, consider MathML vs.
LaTeX equations, and which one is easier for a human to
write.)

Neither are, IMHO, particularly simple. MathML will benefit
from an XML aware editor; LaTeX will need special support. In
the case of LaTeX, of course, the language has been around
awhile, and is pretty universal in mathematic circles, so
editors already have that support. The simplest way to use
MathML is probablly to write LaTeX, and pass it through a
converter. But XML is used for many other things, where there
really aren't good existing tools.

 

[James Kanze]

And XML is one of the least efficient ways of doing that,
spacewise. This is especially true with large amounts of data
which have to be transferred eg. over a network. XML is
hyperverbose, often for no good reason.

But it compresses well. I agree, and this over-verbosity is
one of the things I don't particularly care for in XML. Before
XML, each time I've needed some specialized syntax, i designed
it from scratch (usually with a vaguely lisp-like grammar,
although I'd usually put the keyword outside the parentheses,
and often used {..} for parentheses, rather than (...)). And
write a parser for it, which was good for a couple of days work.
And not have any support (e.g. auto-indent) for it in the
editor. Today, I'll do it in XML, write my DTD in a couple of
hours, and have a complete parser and editor support
immediately.

I'm not really fond of XML, however: it's not that it's better
than any possible alternatives, it's that there are no
alternatives, other than developing an entire data description
language from scratch each time around. The results are never
as good as a custom data description language would be, but a
half a day's work, compared to a week or more (generally more,
because if you define your own format, you have to document it
in detail as well). There are doubtlessly some cases where the
extra work is justified, but file size is rarely a valid
justification, given the omnipresence of gzip, bzip2, etc.

 

[Gerhard Fiedler]

And XML is one of the least efficient ways of doing that, spacewise.
This is especially true with large amounts of data which have to be
transferred eg. over a network. XML is hyperverbose, often for no good
reason.

XML is as verbose as you make it. If your XML files are too verbose, you
can't really blame the XML definition for that. It's possible to create an
XML spec for a configuration file that is not more verbose than the
standard .ini file format, for example.

<ini cfg1="value1" cfg2="value2"/>

Of course, you can also make this

<MyReallyLongRootNodeName>
<AnEvenLongerConfigurationValueName>
value1
</AnEvenLongerConfigurationValueName>
<AndAnotherStillLongerConfigurationValueName>
value2
</AndAnotherStillLongerConfigurationValueName>
</MyReallyLongRootNodeName>

Neither is required or prohibited by XML. Both are XML (well, there's the
spec line that's missing).

Gerhard

 

[Juha Nieminen]

XML is as verbose as you make it. If your XML files are too verbose, you
can't really blame the XML definition for that. It's possible to create an
XML spec for a configuration file that is not more verbose than the
standard .ini file format, for example.

<ini cfg1="value1" cfg2="value2"/>

Short and obfuscated names don't necessarily reduce the verboseness of
XML. Case in point: Just look at any MathML file.

 

[Juha Nieminen]

Neither are, IMHO, particularly simple.

I didn't ask if either one is particularly simple. I asked which one
is *simpler* for a human to write (and read).

The LaTeX equation syntax is *by far* simpler to read and write by a
human.

 

[Richard Herring]

And this already presents one of the problems with XML. For efficient
transfer you have to use some unrelated format and have both ends agree
on it. You immediately destroyed one of the key "advantages" of XML.

If bandwidth is really an issue, the compression should be happening
transparently at a lower level in the network stack. It isn't an issue
the application layer should be concerned with, so decoupling it is
surely a Good Thing.

 

[Gerhard Fiedler]

Short and obfuscated names don't necessarily reduce the verboseness of
XML. Case in point: Just look at any MathML file.

One example doesn't make a general point, good or bad. I don't know MathML,
and I don't have to. If it's a bad example, it's just a bad example. I'm
sure you won't have difficulties finding bad examples of C++ code, yet you
seem to continue using it

My general point above was that any XML file can be as succinct as an ini
file format. You can probably transform most free-form data formats into
XML without making them considerably more verbose.

Gerhard

 

[tonytech08]

I'm not really fond of XML, however: it's not that it's better
than any possible alternatives, it's that there are no
alternatives, other than developing an entire data description
language from scratch each time around.  

iMatix OpenAMQ, Apache QPid? Topical discussion on Slashdot a couple
of days ago about Microsoft participation in the binary messaging
technology.

 

[Juha Nieminen]

One example doesn't make a general point, good or bad. I don't know MathML,
and I don't have to. If it's a bad example, it's just a bad example.

Just to show a concrete example, here's an equation as written in LaTeX:

\begin{equation}
x^2+4x+4=0
\end{equation}

The same equation written in MathML:

<mrow>
<mrow>
<msup>
<mi>x</mi>
<mn>2</mn>
</msup>
<mo>+</mo>
<mrow>
<mn>4</mn>
<mo>&InvisibleTimes;</mo>
<mi>x</mi>
</mrow>
<mo>+</mo>
<mn>4</mn>
</mrow>
<mo>=</mo>
<mn>0</mn>
</mrow>

 

[Jerry Coffin]

Just to show a concrete example, here's an equation as written in LaTeX:

\begin{equation}
x^2+4x+4=0
\end{equation}

The same equation written in MathML:

[ ... elided ]

This really is a problem with MathML, not with XML in general though. If
you wanted to define a LateXML, you could easily allow a equation to
look like:

<equation>
x^2+4x+4=0
</equation>

Of course, if that was _all_ you had for the content in a file, the
overhead of an XML header would be fairly substantial, at least on a
percentage basis. I've yet to see a situation in which that was really
an issue though.

I'd characterize LaTeX as a "programmer's format", whereas MathML is a
"software Engineeer's" format. MathML is the kind of thing you could
implement reasonably well with an army of average intelligence, average
talent, etc., programmers, and still get the job done. Implementing
LaTeX at all well requires fewer programmers, but they need far more
knowledge of the subject matter, and probably better judgement to do the
job well. At the same time, if they do have the judgement and the
knowledge, LaTeX (or something similar) gives them a lot more leeway to
put their talent to use in producing a superior result.

 

[Ian Collins]

I didn't ask if either one is particularly simple. I asked which one
is *simpler* for a human to write (and read).

The LaTeX equation syntax is *by far* simpler to read and write by a
human.

The verbosity id largely irrelevant, most of the XML I deal with (which
is a lot) is generated by machines to communicate between machines or
generated by humans as source for generating other formats.

XML should not be considered in isolation, but in the context of the
tools that work with it (CSS, DOM, XSLT and friends).

 

[James Kanze]

I didn't ask if either one is particularly simple. I asked
which one is *simpler* for a human to write (and read).

So I answered the relevant question, rather than the irrelevant
one you asked.

The LaTeX equation syntax is *by far* simpler to read and
write by a human.

The point is that neither are designed to be read by a human;
they are designed to be read my a machine in order to generate
output which is read by a human. And even when writing, you're
using a machine to input and view what you are writing. Whether
one is easier or more difficult to write depends more on the
tool being used to write them than it depends on the format
itself. Potentially (although probably not in practice, at
least not yet), MathML would have the advantage here, because
its tool could leverage off the large amount of other XML tools
around.

 

[Juha Nieminen]

The point is that neither are designed to be read by a human;
they are designed to be read my a machine in order to generate
output which is read by a human.

That's like saying that the text you just wrote is not designed to be
read by a human but by a machine (for the sole reason that you are
writing it with a machine rather than pen and paper).

 

[Ian Collins]

That's like saying that the text you just wrote is not designed to be
read by a human but by a machine (for the sole reason that you are
writing it with a machine rather than pen and paper).

I thought Perl was off topic here

 

[James Kanze]

That's like saying that the text you just wrote is not
designed to be read by a human but by a machine (for the sole
reason that you are writing it with a machine rather than pen
and paper).

Yes and no.

Yes in the sense that what you are reading is NOT what I
actually typed. (I only typed a line break between paragraphs,
for example. My editor ensures that the line with is no more
than 64.)

Yes also in the sense that what I typed resulted in a sequence
of bytes, which you read through a program which renders them as
text on the screen. And what you read depends on that renderer;
if it interprets those bytes as EBCDIC, what I've written will
be pretty unreadable.

No, however, in the more important sense that what you are
reading is a very direct, one to one rendering of the bytes in
the file; each byte (or each character) in the file corresponds
to a single text character rendered on your screen or printer.
This is not the case for LaTeX or MathML or XHTML or other
markup languages. More importantly, with the possible exception
of LaTeX, you wouldn't actually type the character sequence
being transmitted, or even necessarily see it. Even with LaTeX,
I suspect that most people will use something like LyX, and
rarely look at or worry about the actual "program" that they've
written.