Hello,

It would be much easier for programmers to get their HUGE applications
working if there was NO XML crap, and NO CFG crap, and other crappy files.

I am a Delphi programmer and I don't give a RATSS ASS about XML ?!?!?

I didn't sign up for XML when I started programming with borland
pascal/turbo pascal/delphi.

This product has gone down hill with all kinds of shady language crap, that
includes DFM's and other crap, INI crap, etc.

ALL CRAP.

Replace all that crap with PASCAL code.

At least that is something that we PASCAL programmers can understand and
manipulate to our hearts content when needed !

Bye,
  Skybuck.

I can understand the XML issue, but why the hate for DFM?

"
I can understand the XML issue, but why the hate for DFM?
"

DFM is what started it ?!

Bye,
  Skybuck.

You seem uncertain. :)

Frankly, I'm glad they didn't phase out DFM and convert it to XML.

"
You seem uncertain. :)
"

It probably started with some *.CFG or something... are these *.CFG even
used anymore ?

Doesn't seem like it ?!? Could be wrong though ! ;)

"
Frankly, I'm glad they didn't phase out DFM and convert it to XML.
"

DFM is not so bad, but that's how it slowly sneaks in... DFM first, XML
later.

Bye,
  Skybuck.

Yes, I think CFG start it all first. But if you think about where it came
from... it was because the compiler is made configurable in the first
place. Don't know since when, but my first Pascal compiler was Turbo
Pascal 4 (TP4 for DOS), and its compiler is already configurable. I
didn't have the chance to know more about earlier versions, but from
computer magazines years back, TP3 compiler is already configurable too.
...Crap. This makes me want to hunt them.

Apparently, CFG is still used as a backup when DOF/XML is missing.
DOF/XML is basically a CFG plus bells & whistles settings for the IDE.
CFG holds only the relevant settings for project compilation. Loosing all
three files above can make a program broken after compilation, or even
not compilable at all. Due to e.g.: record alignment, optimization,
runtime checkings, etc.

Yes, I notice DFM is slowly extended on some Delphi versions. It may be
changed to XML later, but DFM is pretty much like Microsoft RC files
where it's still used even now - at least for non .NET programs (.NET is
crap, BTW). Like RC files, DFM is part of the actual program itself. It's
unlikely be easy to phase out. Heck... take a look at bitmap format, it's
been there since Windows 2 or even the first Windows, and it's still used
by the latest state of the art, Windows 8 kernel (Windows 8 is crap too).

Even with all these migration to DOF and XML, Delphi is still doing it
carefully - taking it easy for programmers. Compare it with Visual
Studio, where almost every version, the project configuration format
changes. Now that, is one heck of a crap.

Probably with XML is probably that it's hard to edit, fastly...

At least editing Delphi code is fast...

Problem with XML is it's too verbose... it's not "human-editing friendly"...
it's more ment for parsers.

I had a situation where editing copy & pasting lines for configuration files
might have been much faster.

Instead I had to re-build the entire project file via the GUI which kinda
sux... but maybe in the end it was better anyway... then again maybe not...

So if it was all in Delphi it would probably be much easier to edit and get
a big project file working, for big projects ;)

Meaning lot's of units... to be included.

I had to change file paths or something... just a little bit... but with xml
crap... trying a column based editing approach is simply not possible with
current editors...

Perhaps if Delphi had an XML-aware editor it might have been possible...
though that would be novelty... and kinda strange/akward... but could also
be very cool.

Bye,
  Skybuck.