Lists Home |
Date Index |
On Monday 16 September 2002 15:17, Jonathan Robie wrote:
> Does he really believe that all "architecture people" are harmful, or is he
> disagreeing with some specific architectures? Does he really think that a
> software architect sits at his desk and says, "here's a useless problem
> that I know how to solve, let's have at it!" Is he saying that Microsoft is
> not interested in knowing whether they can sell the products and
> architectures they develop by pointing to problems people think are
> important to solve?
I think he's using sensational language to poke fun at the actions of a crazy
few, really :-)
> Joel asks us to adopt the following test:
> Tell me something new that I can do that I couldn't do
> before, O Astronauts, or stay up there in space and
> don't waste any more of my time.
> But sometimes it is important to do something more simply, or to do it in a
> way that makes it easier for heterogeneous programs to work together.
Sure, but I think the point is that not enough attention is paid to actually
doing new things as opposed to intellectual exercises done just to create a
new toy to play with.
> all know that a program designed for end users may succeed because it has a
> nicer GUI, even if it has less functionality than a complex rival. In the
> same way, a software architecture may succeed because it fits more smoothly
> into the way people develop software, even if it does nothing that is
> completely new.
But that would count as doing something [useful] new, that it fits in better,
as long as it really avoided some previous effort.
Case in point: I see a lot of people saying that interoperability is now
easier with XML, but I've not seen it myself. I was happily interoperating
with JPEG, ZIP, PNG, HTML, SGML, LaTeX, Unicode, CSV, TSV, S-expressions, and
file full of SQL INSERT statements before XML came along, and to tell the
truth the only one of those areas it's successfully made inroads in for me is
SGML and LaTeX; now I do my DocBook with an XSLT engine rather than Jade, and
occasionally throw together custom markup for specialist things with my own
XSLT to convert it into HTML or DocBook/XML.
But when it comes to data, most of which is tabular in my world, CSV and TSV
(tab seperated values - like CSV but without the quoting problems of commas
in values) still reign supreme. For a start, none of the other companies I
interact with ever produce XML files! They produce CSV files, mainly. I'd be
happier if they moved up to TSV rather than XML. There's less to break in a
TSV file than an XML file; a table of people with email and name can be:
or, without the header, just:
Whereas in XML there may or may not be the logical structure of a root
element with one child per row and that having one child (be it attribute or
element) per field. Should we worry if half of the 'row' elements have one
name and the other half have another? If there's a single 'metadata' element
in there that doesn't fit the expectation, what do we do? We'd really need to
agree on an industry-wide vocabulary for customer databases in XML...
But with TSV the only worry is what character encoding to use and whether the
headings map directly to your database fields or if you need a human's
internal thesaurus to map 'email' to 'RFC2822 address'. And the encoding
issue is usually trivial - default to CP1252 on a Windows machine, but keep
an eye out when importing data from foreigners. Mandating UTF-8 for TSV would
be simpler than trying to mandate an XML vocabulary; most of the people I get
data from would go "Right... um... can Excel do that?".
> >Soap + WSDL may be
> >the Hot New Thing, but it doesn't really let you do anything you couldn't
> > do before using other technologies -- if you had a reason to. All that
> > Distributed Services Nirvana the architecture astronauts are blathering
> > about was promised to us in the past, if we used DCOM, or JavaBeans, or
> > OSF DCE, or CORBA."
> XML does nothing that SGML did not, but XML has caught on in a way that
> SGML did not. I do think that XML is significant.
It's caught on in the wrong way, though. I see it more like a new government:
The same old game is played, but with new names. It hasn't made my life
easier, but it's introduced the costs of changing and a lot of promises of
greener grass, but nothing really new seems to be happening...
People like Google are starting to make SOAP interfaces available. Why didn't
they make CORBA or RMI interfaces available? Not for any technical reason;
they would all be pretty easy to set up. As far as I can tell, it was purely
because there's a general feel in the air that providing programmatic
interfaces to Web sites is a good idea. I see XML as having ridden this wave
by creating the 'XML for data' idea out of the original 'XML for documents'
idea, rather than having *created* this wave.
Can anyone confirm or deny that? It's just a theory right now, but I do see
people blindly assuming that XML has enabled or encouraged this interest in
Web services (which I consider a good idea in principal, BTW). Although I've
yet to see Web services changing my life either.
> Like all new technologies, web services is still on trial,
> but I do think
> that it is important to be able to exchange requests and data without being
> tied to one language, one operating system, or heavyweight and expensive
> specialized software systems.
XML parsers and XSLT engines aren't so lightweight :-) If you want
lightweight cheap software to build distributed systems upon, The ONC XDR is
almost certainly the way to go... there are open source implementations in C
and Python that I've wandered accross, and probably either directly there or
accessible from most other languages too (if it's available as a C library it
can leak its way into PHP, Perl, and friends without much effort). Beyond C
you tend to lose out on
And XDR libraries come with all the free Unices, since it's an integral part
of NFS and NIS. Which would make them more widely deployed than XML parsers,
I'm sure :-)
> If you want all three of these virtues, I do
> think that Soap + WSDL can do something that the other technologies he
> lists did not.
A city is like a large, complex, rabbit