[9fans] XML

[9fans] XML

[ron minnich]

This one is interesting:
"The acmpolicy class implements a compiler for translating an XML policy
into their binary format and provides functionality for comparing a
current policy against a new one when changing a policy."

So, translate XML to binary to use it?

But it's a standard, right? I can't tell you how many times a day
people tell me they're doing something in XML ... "it's the standard"
-- not "A", but "THE".

Let's see:

<9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>...


well, you get my drift.

Shouldn't we move 9p to a standards-based, compliant, XML-based system
with first-class enumerated elements in which all pluggable components
are Python objects and hence first-class citizens and add a full
compiler to enable translation and XML co-processor acceleration?

Can I randomly permute the words in the previous sentence? Yes.
Is that sentence like stuff I read nowadays? Yes.
Is constant gnashing wearing off the enamel on my teeth? Yes, oh yes.

ron

Re: [9fans] XML

[W B Hacker]

ron minnich wrote:
> This one is interesting:
> "The acmpolicy class implements a compiler for translating an XML policy
> into their binary format and provides functionality for comparing a
> current policy against a new one when changing a policy."
> 
> So, translate XML to binary to use it?
> 
> But it's a standard, right? I can't tell you how many times a day
> people tell me they're doing something in XML ... "it's the standard"
> -- not "A", but "THE".
> 
> Let's see:
> 
> <9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>... 
> 
> 
> 
> well, you get my drift.
> 
> Shouldn't we move 9p to a standards-based, compliant, XML-based system
> with first-class enumerated elements in which all pluggable components
> are Python objects and hence first-class citizens and add a full
> compiler to enable translation and XML co-processor acceleration?
> 
> Can I randomly permute the words in the previous sentence? Yes.
> Is that sentence like stuff I read nowadays? Yes.
> Is constant gnashing wearing off the enamel on my teeth? Yes, oh yes.
> 
> ron
> 

Not to worry!

Sign of the times.

'Standards based' has simply replaced 'they say' as the biggest liar in the world.

Going the other way, we can now shave 3 bytes:

'progress' can be expressed as 'bloat'

Bill

Re: [9fans] XML

[Roman Shaposhnik]

On Mon, 2007-05-21 at 09:57 -0700, ron minnich wrote:
> <9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>...

  ROTFL ;-)

  Seriously, though, we all hate XML so much for all the right reasons
that we kind of forget that it can be useful. I do have a couple of 
use cases I consider XML being appropriate at. But what about you guys?
Do you remember XML being helpful on any particular occasion? I'm really
curious.

Thanks,
Roman.

Re: [9fans] XML

[W B Hacker]

Roman Shaposhnik wrote:
> On Mon, 2007-05-21 at 09:57 -0700, ron minnich wrote:
>> <9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>...
> 
>   ROTFL ;-)
> 
>   Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful.

ACK.. And ingesting tapework scollix can help one lise weight...

> I do have a couple of 
> use cases I consider XML being appropriate at. But what about you guys?
> Do you remember XML being helpful on any particular occasion? I'm really
> curious.
> 
> Thanks,
> Roman.
> 
> 

If printed out on sufficiently soft paper, yes, XML is as useful as any other 
drivel.

But few printers, laser or inkjet, can handle roll-feed, quilted and puffed or 
otherwise.

;-)

Bill

Re: [9fans] XML

[Francisco J Ballesteros]

> > Do you remember XML being helpful on any particular occasion? I'm really
> > curious.

In omero, I've found recently a place where using XML to convey the UI tree from
the UI server to the viewer would win (perhaps) wrt using a file tree.
this particular
case is when the link between the omero server and the UI viewer has a
really bad
latency. In this case, the current viewer scans the tree (one level at
a time) to see
changes and update the UI. Even when notified of subtrees that changes, it still
has to read the root of the subtree (one RPC), do the same for inner
panels (another),
and so and so and so.

However, we're still experimenting with this and I think that just
placing a "toc" file
in the root of the tree (with the equivalent of du -a) would permit
the viewer doing its
work in just two RPCs.

Of course, using a real fs instead of xml lets us use all the fs
tools, as you all know,
that's why we don't actually use xml. But since you asked, I have to
say that that's
the only place I've seriously considered using xml (or similar) to
replace a file tree.

Perhaps others have more cases where xml could be helpful.

Re: [9fans] XML

[Charles Forsyth]

> However, we're still experimenting with this and I think that just
> placing a "toc" file

i think just using s-expressions would do the trick, and be much easier to read.

Re: [9fans] XML

[erik quanstrom]

i thought the criticism of s expressions was they were hard to read.

- erik

Re: [9fans] XML

[David Leimbach]

On 5/22/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> > However, we're still experimenting with this and I think that just
> > placing a "toc" file
>
> i think just using s-expressions would do the trick, and be much easier to read.
>
>
To be completely honest, a bit of the history of xar was a joking
conversation by some friends of mine who happened to work at apple at
the time.

"Everything's better with XML, even tar".  "XAR!" which is kind of fun
to yell came out of it.

Sadly I've found it useful after all of that was said and done.  It's
really not too bad with the abominations that are extended attributes
(let's treat files as directories shall we?  And hide all the data in
key value pairs... ), Finder Info on mac os x, resource forks, etc.
It's been working Ok on FreeBSD, Linux and Mac OS X, each with their
slightly different APIs for dealing with those little nuggets of joy.

And it's been re-written a few times.  (because DOM is a horrible
waste of resources if you don't need it, SAX-like processing of the
XML posed an interesting challenge) I did compression on the XML TOC
myself to add more to the joke.

I mean when you have a table of contents in XML that's > 800 MB, you
gotta do something :-)

Anyway, it was originally just fun to work on, and probably serves
more as proof of how much XML sucks.  However Apple's adopting it in
Leopard, probably due to the use of XML.  Had we used S-expressions, I
don't think they'd have known what to do with it.

One of the leaders of the RPM project actually did something at some
point to try to use xar instead of cpio archives for a new RPM
back-end.  I'm not sure it got anywhere.  There was also a packaging
system that someone started called "xpkg".

Sometimes jokes get out of hand I guess.

Re: [9fans] XML

[erik quanstrom]

> "Everything's better with XML, even tar".  "XAR!" which is kind of fun
> to yell came out of it.

; wc -l /sys/src/cmd/tapefs/tarfs.c
    140 tarfs.c

tar is not that bad a format to use for structured data.  it's easy to implement.
you can capture data movement and fiddle with it easily. 

that being said, i'd still much rather have a filesystem-like interface.

- erik

Re: [9fans] XML

[Charles Forsyth]

> On 5/22/07, Charles Forsyth <forsyth@terzarima.net> wrote:
>> > However, we're still experimenting with this and I think that just
>> > placing a "toc" file
>>
>> i think just using s-expressions would do the trick, and be much easier to read.

i was referring specifically to nemo's application, although it's often true in general.
s-expressions can look reasonably attractive, and double-clicking works on them.
you can't say either about xml.  certainly most xml i've seen makes me think i'm dyslexic.
it also looks constipated, and two health problems in one standard is just too much.

Re: [9fans] XML

[Francisco J Ballesteros]

We're trying hard (by reading most of the tree concurrently, and using Op on the
slow link) to get o/mero fast enough not to worry about TOC. But in
any case, should we
add toc, probably just a raw list of, say, one relative path per line,
a-la-du, would suffice.

Anyway, time will say. :)

On 5/25/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> > On 5/22/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> >> > However, we're still experimenting with this and I think that just
> >> > placing a "toc" file
> >>
> >> i think just using s-expressions would do the trick, and be much easier to read.
>
> i was referring specifically to nemo's application, although it's often true in general.
> s-expressions can look reasonably attractive, and double-clicking works on them.
> you can't say either about xml.  certainly most xml i've seen makes me think i'm dyslexic.
> it also looks constipated, and two health problems in one standard is just too much.
>
>

Re: [9fans] XML

[ron minnich]

On 5/25/07, Francisco J Ballesteros <nemo@lsub.org> wrote:
> We're trying hard (by reading most of the tree concurrently, and using Op on the
> slow link) to get o/mero fast enough not to worry about TOC. But in
> any case, should we
> add toc,

I think that toc demonstrates the power of the approach, however.

I had this long running discussion on kvm devel list, trying to argue
for 9p as the interface for paravirtual devices. I think there is some
acceptance, but not total acceptance. People keep thinking that
emulation is the same as an abstraction. i.e. they argue that an
abstraction of an IRQ controller that has IRQ0-n, NMI, SMI, etc. The
abstraction is that the highest IRQ is not bounded as it is in real
life. Abstraction? Hmm. Not on my planet, anyway.

It hit me that the dom0 could export its tcp stack to dom1 as a
paravirtual device. you could bypass the silly virtual enet emulation
that way. Your /net would go right to the tcp, not via some odd
pseudo-device. That would save some delay and overhead, and, not
incidentally, would make my mp3 player smoother in dom1 ...

thanks

ron

Re: [9fans] XML

[Uriel]

On 5/25/07, ron minnich <rminnich@gmail.com> wrote:
> It hit me that the dom0 could export its tcp stack to dom1 as a
> paravirtual device. you could bypass the silly virtual enet emulation
> that way. Your /net would go right to the tcp, not via some odd
> pseudo-device. That would save some delay and overhead, and, not
> incidentally, would make my mp3 player smoother in dom1 ...

Same goes for graphics, dom0 could export a /dev/draw and /dev/cons
and you could have the hosted OS transparently in a window, even if it
had no virtual video hardware.

uriel

Re: [9fans] XML

[erik quanstrom]

On Fri May 25 14:15:01 EDT 2007, rminnich@gmail.com wrote:
> It hit me that the dom0 could export its tcp stack to dom1 as a
> paravirtual device. you could bypass the silly virtual enet emulation
> that way. Your /net would go right to the tcp, not via some odd
> pseudo-device. That would save some delay and overhead, and, not
> incidentally, would make my mp3 player smoother in dom1 ...

muxing a /net heirarchy from plan9 via 9p is certainly the most flexable
way to go.  this is a very good idea.  (i assume that you really didn't
mean importing tcp only from dom0.)

however, there are some hardware models that could be very efficient
to emulate in /a/ hypervisor.  the myricom 10gbe moves all data
by dma.  the only mmio is for commands, send descriptors (16 bytes)
and receive descriptors (8 bytes).  assuming the guest doesn't have
real pci window addresses, dom0 would only need to rewrite the
descriptors and the card could still dma directly from the guest.

it's significantly less general than the 9p way of doing things, but
it could make zero-copy sends (and zero-copy tco, if you care about
such things) doable.

i don't know enough about xen's inner workings to know if this would
work.

- erik

p.s.  perhaps the way to put generality back in is to marshal 9p between
dom0 and guests with the same trick.  use an pseudo-mmio descriptor for
the 9p "header" which points to the memory to be transfered.

Re: [9fans] XML

[Steve Simon]

> We're trying hard (by reading most of the tree concurrently, and using Op on the
> slow link) to get o/mero fast enough not to worry about TOC. But in
> any case, should we
> add toc, probably just a raw list of, say, one relative path per line,
> a-la-du, would suffice.

I am not sure I understand your application, but
couldn't you implement it with a single virtual file that the window
manager creates, and which the remote client blocks on. When the
user changes the layout the info is written to the "changes" file.

Thus the remote end can keep a cache of the window systems state
close to it by just reading a single file rather than scanning the
widget hierarchy.

-Steve

Re: [9fans] XML

[Francisco J Ballesteros]

We have something similar. When layout changes, an event is posted to /mnt/ports
but that reports that a subtree changed. At that point, we must reread
the subtree to
detect changes. Knowing the dir hierarchy in advance can speed things
up, and the
toc file could be of help.

But thanks for the idea. I'll give it a second thought.

On 5/25/07, Steve Simon <steve@quintile.net> wrote:
> > We're trying hard (by reading most of the tree concurrently, and using Op on the
> > slow link) to get o/mero fast enough not to worry about TOC. But in
> > any case, should we
> > add toc, probably just a raw list of, say, one relative path per line,
> > a-la-du, would suffice.
>
> I am not sure I understand your application, but
> couldn't you implement it with a single virtual file that the window
> manager creates, and which the remote client blocks on. When the
> user changes the layout the info is written to the "changes" file.
>
> Thus the remote end can keep a cache of the window systems state
> close to it by just reading a single file rather than scanning the
> widget hierarchy.
>
> -Steve
>

Re: [9fans] XML

[ozan s. yigit]

> i think just using s-expressions would do the trick,
> and be much easier to read.

json would probably be less of a trick.
oz

Re: [9fans] XML

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

no, i don't think so. they're about the same amount of code, and json is
less regular and more of a hack.  as js is, though i've seen worse
(java! oh, man! what were they THINKING?)

[-- Attachment #2: Type: message/rfc822, Size: 2596 bytes --]

From: "ozan s. yigit" <oz@silentrunning.ca>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] XML
Date: Fri, 25 May 2007 14:30:43 -0400
Message-ID: <E1HreYl-0006nz-4L@hex.silentrunning.ca>

> i think just using s-expressions would do the trick,
> and be much easier to read.

json would probably be less of a trick.
oz

Re: [9fans] XML

[ron minnich]

On 5/21/07, Roman Shaposhnik <rvs@sun.com> wrote:

>   Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful. I do have a couple of
> use cases I consider XML being appropriate at. But what about you guys?

It's good at what it's good for. I think the move to XML as the
universal glue is more driven because people are desperate for
something and XML is all they can see .

But it's very sad to see people talking about binary converters and
XML co-processors, or to watch 100 bytes of data contained in 3000
bytes of XML ...

ron

Re: [9fans] XML

[David Leimbach]

On 5/21/07, ron minnich <rminnich@gmail.com> wrote:
> On 5/21/07, Roman Shaposhnik <rvs@sun.com> wrote:
>
> >   Seriously, though, we all hate XML so much for all the right reasons
> > that we kind of forget that it can be useful. I do have a couple of
> > use cases I consider XML being appropriate at. But what about you guys?
>
> It's good at what it's good for. I think the move to XML as the
> universal glue is more driven because people are desperate for
> something and XML is all they can see .
>
> But it's very sad to see people talking about binary converters and
> XML co-processors, or to watch 100 bytes of data contained in 3000
> bytes of XML ...
>
> ron
>


I've actually seen FPGAs set up for XML processing... I thought that
was quite amusing :-)

Re: [9fans] XML

[erik quanstrom]

we feel the same way about iScsi hardware.

- erik

> 
> I've actually seen FPGAs set up for XML processing... I thought that
> was quite amusing :-)

Re: [9fans] XML

[lucio]

> we feel the same way about iScsi hardware.
> 
> - erik
> 
>> 
>> I've actually seen FPGAs set up for XML processing... I thought that
>> was quite amusing :-)

Then Coraid is ripe for wrapping SCSI in XML.  xSCSI anyone?

++L

Re: [9fans] XML

[erik quanstrom]

>   Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful. I do have a couple of 
> use cases I consider XML being appropriate at. But what about you guys?
> Do you remember XML being helpful on any particular occasion? I'm really
> curious.

i think a better question is, can you think of an application for xml that
can't be done more simply?

the debate over typed variables in programming languages is pretty well over.
but i think asn/1 and xml seem to show that data type definitions can get
out of control.  and that the dtd is itself a program that needs debugging.

- erik

Re: [9fans] XML

[Uriel]

On 5/21/07, erik quanstrom <quanstro@coraid.com> wrote:
> i think a better question is, can you think of an application for xml that
> can't be done more simply?

"The essence of XML is this: the problem it solves is not hard, and it
does not solve the problem well."    -- Phil Wadler, POPL 2003


> the debate over typed variables in programming languages is pretty well over.
> but i think asn/1 and xml seem to show that data type definitions can get
> out of control.  and that the dtd is itself a program that needs debugging.

If you think DTDs are out of control, you should look at XML Schema
some time... gives a new dimension to the meaning of 'megalomaniacal'.

uriel

Re: [9fans] XML

[Uriel]

On 5/21/07, Roman Shaposhnik <rvs@sun.com> wrote:
>   Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful. I do have a couple of
> use cases I consider XML being appropriate at. But what about you guys?
> Do you remember XML being helpful on any particular occasion?

No.

But XML creates jobs, so it must be good for the economy.

uriel

Re: [9fans] XML

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

I have to disagree with Uriel here:
 I was on a project that went from using a simple scheme (Item-1-Name = ;
Item-1-Price = )
to using XML. Each time I would add the feature that was desired by the
Cabal of PHBs, they would think of another XML branch that they'd like to
support for some other customer or system. Then it just went crazy: they
wanted to hire an outside `architect` when I had been adding every feature
piecemeal up until that point. Long story short, the project went over time
alotment, the `architect` was an idiot, and I was laid off because the Cabal
decided that they wanted to shift away from the bespoke app.
 I think the most fun was waiting for the 105MiB XML file to come down from
the first client to be imported; I especially loved the repeated information
within each <Item> </Item> block.
 I had asked to use either a web service or a simple CGI `API`, but no, it
we *had* to pull from the clients. Cabal of PHBs + XML - Interest in funding
design = steaming pile of manure.

On 5/21/07, Uriel <uriel99@gmail.com> wrote:
>
> On 5/21/07, Roman Shaposhnik <rvs@sun.com> wrote:
> >   Seriously, though, we all hate XML so much for all the right reasons
> > that we kind of forget that it can be useful. I do have a couple of
> > use cases I consider XML being appropriate at. But what about you guys?
> > Do you remember XML being helpful on any particular occasion?
>
> No.
>
> But XML creates jobs, so it must be good for the economy.
>
> uriel
>



-- 
"No stranger to me is this wanderer: many years ago passed he by.
Zarathustra he was called; but he hath altered.
  Then thou carriedst thine ashes into the mountains: wilt thou now
carry thy fire into the valleys? Fearest thou not the incendiary's
doom?
  Yea, I recognize Zarathustra. Pure is his eye, and no loathing
lurketh about his mouth. Goeth he not along like a dancer?"
-- The Saint, Also Sprach Zarathustra

[-- Attachment #2: Type: text/html, Size: 2383 bytes --]

Re: [9fans] XML

[Skip Tavakkolian]

>   Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful. I do have a couple of 
> use cases I consider XML being appropriate at. But what about you guys?
> Do you remember XML being helpful on any particular occasion? I'm really
> curious.

its usefulness is largely due to the critical mass of software that
now supports it.  popular browsers support DOMParser, XSLTProcessor,
etc.  other approaches -- sexpr and sexpr with embedded js for
transformations -- would be as useful.

XML's ornateness reminds me of the historical accounts of the French
aristocracy just before the revolution; wasteful opulence manifesting
itself in how people dressed: wigs, massive makeup and ridiculous
outfits.  it can't possibly last.

p.s. obviously, i'm wrong:

http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=89&articleId=9020222&intsrc=hm_topic

Re: [9fans] XML

[Jack Johnson]

On 5/21/07, Skip Tavakkolian <9nut@9netics.com> wrote:
> etc.  other approaches -- sexpr and sexpr with embedded js for
> transformations -- would be as useful.

What do you think would be the fastest/best way to implement something
like this as a proof-of-concept or stepping stone?

-Jack

Re: [9fans] XML

[Uriel]

A GSoC student is implementing a 9P client in JS, that will be a nice
first step to replace the AJAX XML crud.

uriel

On 5/21/07, Jack Johnson <knapjack@gmail.com> wrote:
> On 5/21/07, Skip Tavakkolian <9nut@9netics.com> wrote:
> > etc.  other approaches -- sexpr and sexpr with embedded js for
> > transformations -- would be as useful.
>
> What do you think would be the fastest/best way to implement something
> like this as a proof-of-concept or stepping stone?
>
> -Jack
>

Re: [9fans] XML

[Skip Tavakkolian]

>> etc.  other approaches -- sexpr and sexpr with embedded js for
>> transformations -- would be as useful.
> 
> What do you think would be the fastest/best way to implement something
> like this as a proof-of-concept or stepping stone?

not exactly plan9 related, but...

i assume the consumer will be a browser.  probably do one in
javascript.  despite its name, XMLHttpRequest can fetch anything.
check out the link below and take a look at jabberzilla sources on
code.google.com.

http://javascript.crockford.com/little.html

could just use an rc script to generate the content, probably using
this handy program: /n/sources/contrib/rsc/cgi.c

Re: [9fans] XML

[David Leimbach]

On 5/21/07, Roman Shaposhnik <rvs@sun.com> wrote:
> On Mon, 2007-05-21 at 09:57 -0700, ron minnich wrote:
> > <9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>...
>
>   ROTFL ;-)
>
>   Seriously, though, we all hate XML so much for all the right reasons
> that we kind of forget that it can be useful. I do have a couple of
> use cases I consider XML being appropriate at. But what about you guys?
> Do you remember XML being helpful on any particular occasion? I'm really
> curious.
>
> Thanks,
> Roman.
>

XHTML, on the surface, seems better thought out than plain old HTML.
That doesn't mean I like any of them though :-)

I once wrote a paper in Docbook, and was able to convert it to a PDF
via about 4 passes of XSLT processing.  Then I remembered that LaTeX
can do that a lot faster, and never went back to Docbook.  Not to
mention Docbook causes RSI faster than LaTeX from my experience with
badly hurting wrists and numbness in my fingers from all the <>\ etc.
:-)

XML has succeeded in making me accept and write more Lisp/Scheme these
days which isn't too bad for well roundedness.

Also some friends of mine and I have an XML markup based archiver for
files on various Unix like OSes called "xar".  I think it started as a
joke but it's so good at backing up resource forks, extended
attributes, and other nuances of various unixes of the day that I've
started using it for backup purposes on Mac OS X :-)

Apple even picked it up, made a bunch of changes, and gave us some
patches.  It might just end up in Leopard.

If you care:
http://code.google.com/p/xar/

It's been fun to hack on anyway.  Not that I've done much with it in a while.

About the only really neat thing, I think, about the table of contents
being in XML is that you can embed subdocuments in the archives
themselves.  Some folks started using it as a back end for packaging
systems, not sure if they ever completed.  Apple might be one of them,
but I won't ever know until that next release is out.

It's not clear to me that XML is easy for either humans or computers
to read, which is what I thought was one of its selling points.

Dave

Re: [9fans] XML

[Steve Simon]

I built a text file to described the menu interface for the LCD front panels
my employer makes.

Initialy I did this as an NDB-like file. I added the concept of a "end" keyword
to terminate a hierarchal block, and allowed a freestanding token to
imply a boolean token=true.

The DTD for this format was defined in another text file which was massaged by
a few lines of awk into an initialised table, compiled into all applications
that read the files (the format was fixed).

People didn't like it as it was not "standard XML" so when I have the chance to
rework it I went for XML and a DTD.

Personally I prefer the NDB style implementation, my compiled in spec gave much
more accurate validation than a DTD, and this was lightweight enought to be
easily be done on the embedded system.

Overall, having completed the changes a year or so ago, XML seems to have added
a load more angle brackets, quotes and poorer validation, in return for no real
reward.

But at least my files are now standard, so thats ok.

-Steve

Re: [9fans] XML

[Bakul Shah]

> Shouldn't we move 9p to a standards-based, compliant, XML-based system
> with first-class enumerated elements in which all pluggable components
> are Python objects and hence first-class citizens and add a full
> compiler to enable translation and XML co-processor acceleration?
>
> Can I randomly permute the words in the previous sentence? Yes.
> Is that sentence like stuff I read nowadays? Yes.

Can you please use XML tags for humor?  That'd make humor
recognition a purely parsing problem.  Thanks!

In a previous job I used sexprs for flinging structured data
about between nodes.  I justified their use as compiled XML.
You can guess what happened once I left....

> Is that sentence like stuff I read nowadays? Yes.
> Is constant gnashing wearing off the enamel on my teeth? Yes, oh yes.

Use of a dental nightguard is recommended.

Re: [9fans] XML

[matt]

ron minnich wrote:
> This one is interesting:
Parse error, expecting something interesting, got old discussion about 
XML being used because its fashionable.

Re: [9fans] XML

[Geoffrey Avila]

On a related note:

Somebody at Sun decided that the thing Unix needed most of all was a way 
to programmatically manipulate "init" via XML. What's worse is that a 
completely independent team at Apple committed a starkly similar atrocity 
at almost the same time.

http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html

http://developer.apple.com/macosx/launchd.html

Could someone explain this to me? Why would you do this? How could this 
possibly be a net improvement?

-GBA





>
> <9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>...
>
>
> well, you get my drift.
>
> Shouldn't we move 9p to a standards-based, compliant, XML-based system
> with first-class enumerated elements in which all pluggable components
> are Python objects and hence first-class citizens and add a full
> compiler to enable translation and XML co-processor acceleration?
>
> Can I randomly permute the words in the previous sentence? Yes.
> Is that sentence like stuff I read nowadays? Yes.
> Is constant gnashing wearing off the enamel on my teeth? Yes, oh yes.
>

Re: [9fans] XML

[Uriel]

You have no heart, programmers have families to feed! This will keep
hundreds of programmers employed for years to come.

uriel

P.S.: And be careful, you might offend the Apple and Sun fanboys in
the audience.

On 5/21/07, Geoffrey Avila <avlg@sdsc.edu> wrote:
>
>
> On a related note:
>
> Somebody at Sun decided that the thing Unix needed most of all was a way
> to programmatically manipulate "init" via XML. What's worse is that a
> completely independent team at Apple committed a starkly similar atrocity
> at almost the same time.
>
> http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html
>
> http://developer.apple.com/macosx/launchd.html
>
> Could someone explain this to me? Why would you do this? How could this
> possibly be a net improvement?
>
> -GBA
>
>
>
>
>
> >
> > <9p><request>T</request><requesttype>R</requesttype><fid><number><digit><binary>1</binary><binary>0>/binary>...
> >
> >
> > well, you get my drift.
> >
> > Shouldn't we move 9p to a standards-based, compliant, XML-based system
> > with first-class enumerated elements in which all pluggable components
> > are Python objects and hence first-class citizens and add a full
> > compiler to enable translation and XML co-processor acceleration?
> >
> > Can I randomly permute the words in the previous sentence? Yes.
> > Is that sentence like stuff I read nowadays? Yes.
> > Is constant gnashing wearing off the enamel on my teeth? Yes, oh yes.
> >
>

Re: [9fans] XML

[Geoffrey Avila]

On Mon, 21 May 2007, Uriel wrote:

> You have no heart, programmers have families to feed! This will keep
> hundreds of programmers employed for years to come.
>
> uriel
>
> P.S.: And be careful, you might offend the Apple and Sun fanboys in
> the audience.

As a self-described Apple/Sun "fanboy", I'm trying to figure out why two
normally mostly-sane companies would willfully mutilate their OS in this
particular manner. I've never heard a peep out of anyone claiming how the
problems they sought to remedy with these new methods were insurmountable
w/o spraying XML all over the place...

-GBA

Re: [9fans] XML

[Roman Shaposhnik]

On Mon, 2007-05-21 at 12:27 -0700, Geoffrey Avila wrote:
> On Mon, 21 May 2007, Uriel wrote:
> 
> > You have no heart, programmers have families to feed! This will keep
> > hundreds of programmers employed for years to come.
> >
> > uriel
> >
> > P.S.: And be careful, you might offend the Apple and Sun fanboys in
> > the audience.
> 
> As a self-described Apple/Sun "fanboy", I'm trying to figure out why two
> normally mostly-sane companies would willfully mutilate their OS in this
> particular manner. I've never heard a peep out of anyone claiming how the
> problems they sought to remedy with these new methods were insurmountable
> w/o spraying XML all over the place...

  That is one of those mysteries that just makes me sad :-(

Thanks,
Roman.

Re: [9fans] XML

[lucio]

> P.S.: And be careful, you might offend the Apple and Sun fanboys in
> the audience.

Well I was horrified when NetBSD core seemed to be following in their
footsteps.  Still am, but I have more or less been able to ignore the
issue.

++L

Re: [9fans] XML

[W B Hacker]

Geoffrey Avila wrote:
> 
> 
> On a related note:
> 
> Somebody at Sun decided that the thing Unix needed most of all was a way 
> to programmatically manipulate "init" via XML. What's worse is that a 
> completely independent team at Apple committed a starkly similar 
> atrocity at almost the same time.
> 
> http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html
> 
> http://developer.apple.com/macosx/launchd.html
> 
> Could someone explain this to me? Why would you do this? How could this 
> possibly be a net improvement?
> 
> -GBA
> 

I'll try.

This presumes you have been around dogs.

Dogs have a way of ummhh.. 'grooming' themselves that (fortunately) most humans 
could not manage alone.  Not enough flex in the back and neck.

Can't speak to motivation...

Unfortunately, there are fewer such limitations in software development.

So - the reason for many of these departures' from common sense is the same as 
that of a Northbound dog licking his Southbound end:

He does it simply because he is able to, and no one really cares to interfere.


Bill

Re: [9fans] XML

[erik quanstrom]

any such dog would need to be straddling the south pole.
there can be at most one of these dogs at any one time.

;-)

- erik

On Mon May 21 19:29:20 EDT 2007, wbh@conducive.org wrote:
> So - the reason for many of these departures' from common sense is the same as 
> that of a Northbound dog licking his Southbound end:

Re: [9fans] XML

[Wes Kussmaul]

A dog straddling the south pole would have two north-facing ends.

Bill apparently meant south-facing end.

erik quanstrom wrote:
> any such dog would need to be straddling the south pole.
> there can be at most one of these dogs at any one time.
> 
> ;-)
> 
> - erik
> 
> On Mon May 21 19:29:20 EDT 2007, wbh@conducive.org wrote:
>> So - the reason for many of these departures' from common sense is the same as 
>> that of a Northbound dog licking his Southbound end:
> 

Re: [9fans] XML

[erik quanstrom]

however, one end would be *heading* north.  the other would be
*heading* south.

- erik

Re: [9fans] XML

[Bruce Ellis]

to throw a spaniard in the works (never was good at mangling metaphors)
i use XML to store midi patches and configs.  as a human never edits
them directly (the pre-existing library does that) it was a good choice.
i considerered an ndb approach, and S-expressions, but i like what i got.

i could have invented a file format and implemented it but i chose not to.

you wouldn't want to read or write any configuration for something
with a thousand params  but programs do it fine.

brucee

On 5/23/07, erik quanstrom <quanstro@coraid.com> wrote:
> however, one end would be *heading* north.  the other would be
> *heading* south.
>
> - erik
>

Re: [9fans] XML

[Jack Johnson]

On 5/22/07, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> i use XML to store midi patches and configs.  as a human never edits
> them directly (the pre-existing library does that) it was a good choice.

I actually think this is where Sun/Apple are headed, where either
settings are configured via some automated deployment/policy process
or UI interaction and it's not expected that a human will ever have to
deal with it (though they would not be prevented from doing so).

-Jack

Re: [9fans] XML

[Lluís Batlle]

I find that most of the tree-like information I want to store in a fd
fits well on OGDL (1st layer). I think Forsyth was working on a OGDL
parser in limbo - I don't know if he finished or stopped thinking on
it.

I wrote my own in c++, and I used a j2me implementation given in the
OGDL main site - them both work fine.

2007/5/22, Bruce Ellis <bruce.ellis@gmail.com>:
> to throw a spaniard in the works (never was good at mangling metaphors)
> i use XML to store midi patches and configs.  as a human never edits
> them directly (the pre-existing library does that) it was a good choice.
> i considerered an ndb approach, and S-expressions, but i like what i got.
>
> i could have invented a file format and implemented it but i chose not to.
>
> you wouldn't want to read or write any configuration for something
> with a thousand params  but programs do it fine.
>
> brucee
>
> On 5/23/07, erik quanstrom <quanstro@coraid.com> wrote:
> > however, one end would be *heading* north.  the other would be
> > *heading* south.
> >
> > - erik
> >
>

Re: [9fans] XML

[Lluís Batlle]

Lately I've been told at work to use a library in C. Most calls have
the signature
ErrorType function(const char *xml);

I have to pass to them xmls of more than two levels deep, attributes,
and around ten elements.

When I asked why such interface to a library, claiming that it was
uncomfortable to me, the lib developer told me that in fact
xml-parameter-passing was one of the techniques he liked most, and
helped him solve a lot of problems easily.

2007/5/23, Lluís Batlle <viriketo@gmail.com>:
> I find that most of the tree-like information I want to store in a fd
> fits well on OGDL (1st layer). I think Forsyth was working on a OGDL
> parser in limbo - I don't know if he finished or stopped thinking on
> it.
>
> I wrote my own in c++, and I used a j2me implementation given in the
> OGDL main site - them both work fine.
>
> 2007/5/22, Bruce Ellis <bruce.ellis@gmail.com>:
> > to throw a spaniard in the works (never was good at mangling metaphors)
> > i use XML to store midi patches and configs.  as a human never edits
> > them directly (the pre-existing library does that) it was a good choice.
> > i considerered an ndb approach, and S-expressions, but i like what i got.
> >
> > i could have invented a file format and implemented it but i chose not to.
> >
> > you wouldn't want to read or write any configuration for something
> > with a thousand params  but programs do it fine.
> >
> > brucee
> >
> > On 5/23/07, erik quanstrom <quanstro@coraid.com> wrote:
> > > however, one end would be *heading* north.  the other would be
> > > *heading* south.
> > >
> > > - erik
> > >
> >
>

Re: [9fans] XML

[lucio]

> I have to pass to them xmls of more than two levels deep, attributes,
> and around ten elements.

Must do wonders for type and error checking.

++L

Re: [9fans] XML

[Wes Kussmaul]

Nothing on the plane of the surface of the earth at the south pole can 
head or face south. Only something orthogonal to the surface (eg the 
pole itself or perhaps a penguin's head) can point south.

wk

erik quanstrom wrote:
> however, one end would be *heading* north.  the other would be
> *heading* south.

Re: [9fans] XML

[Jack Johnson]

On 5/22/07, Wes Kussmaul <wes@authentrus.com> wrote:
> A dog straddling the south pole would have two north-facing ends.

Euphemistically, anything below the waist is the south end.
Therefore, the head is at the north end.  All male dogs retaining both
rear legs and standing could be perceived as straddling its own
southern pole.

Thus, a male dog can never have an end facing south?

-Jack

Re: [9fans] XML

[Charles Forsyth]

> Could someone explain this to me? Why would you do this? How could this 
> possibly be a net improvement?

you probably want to ask about it in one of the sun or apple groups.

[9fans] xml

[hugo rivera]

If you haven't heard of XML yet, you must be living under a rock!  -
Programming in the .NET Environment
Taken from the fortunes file. I guess I must be living under a rock,
but I don't know what xml is, or pragmatically, what is it for.
Please, understand that I'm not trying to start a flame war in here,
but I'd really appreciate if someone could explain xml to me. I've
read the wikipedia entry but doesn't help me a lot, and for the first
time in my life I saw some xml code today, in a program that I need to
use and, hopefully, understand.
I know this subject isn't plan 9 related, but 9fans is my best
resource for CS questions.

--
Hugo

Re: [9fans] xml

[Russ Cox]

On Mon, Jun 28, 2010 at 9:19 AM, hugo rivera <uair00@gmail.com> wrote:
> If you haven't heard of XML yet, you must be living under a rock!  -
> Programming in the .NET Environment
> Taken from the fortunes file. I guess I must be living under a rock,
> but I don't know what xml is, or pragmatically, what is it for.

XML is what it looks like: it's a textual markup language like HTML.
It's ill-suited for representing data structures (an XML element is an
order-dependent collection of anonymous values, while a data structure
is an order-independent collection of named values), but that hasn't
stopped a very large number of applications from using it as a data
structure serialization format.  (Just to take one example out of many,
Apple's Keynote presentation files are named .key but are actually .zip
files containing a (compressed) XML file and supporting media.)

Unlike HTML, there is not a fixed set of allowed tag names or attributes.
Each program that generates or parses XML is free to pick whatever
names it likes; raw XML doesn't even begin to make sense unless
you know the meanings assigned to the tags.  (This problem is
fundamental to any data description, not a flaw in XML, but I mention
it so you won't think you need to find the official definition of the
semantics of XML.)

Russ

Re: [9fans] xml

[Ethan Grammatikidis]

On 28 Jun 2010, at 17:19, hugo rivera wrote:

> If you haven't heard of XML yet, you must be living under a rock!  -
> Programming in the .NET Environment
> Taken from the fortunes file. I guess I must be living under a rock,
> but I don't know what xml is, or pragmatically, what is it for.
> Please, understand that I'm not trying to start a flame war in here,
> but I'd really appreciate if someone could explain xml to me. I've
> read the wikipedia entry but doesn't help me a lot, and for the first
> time in my life I saw some xml code today, in a program that I need to
> use and, hopefully, understand.
> I know this subject isn't plan 9 related, but 9fans is my best
> resource for CS questions.

Okay... here's how I understand XML: It's a format for serialising
hierarchically-structured data with arbitrary metadata.

That's the good part. The bad parts... well, here's two:

XML must be valid. It must be valid because the gods of computing,
when cyberspace was graced with their presence, found validation to be
a good idea as it would quickly tell you if your file would parse
correctly before you fed it into the slow, slow, parser. XML
validation is far slower than parsing, but the gods of computing found
validation to be a good idea, so it must be done.

XML must not contain binary data. All binary data must be uuencoded.
This is because the gods of computing suffered networks which would
pass only textual data. We remember their pain, and worshipfully deny
all means by which binary data may be packed into the same file as
textual without harm.

--
One must always specify what one's computer should do, always, before
even considering what, perhaps, the computer may be able to provide
freely, lest the computer become uppity.

Re: [9fans] xml

[Rob Pike]

"The essence of XML is this: the problem it solves is not hard, and it
does not solve the problem well." -- Phil Wadler, POPL 2003

-rob

Re: [9fans] xml

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 250 bytes --]

On Mon, Jun 28, 2010 at 11:26 AM, Rob Pike <robpike@gmail.com> wrote:

> "The essence of XML is this: the problem it solves is not hard, and it
> does not solve the problem well." -- Phil Wadler, POPL 2003
>
> -rob
>
>
I love Wadler's work.

[-- Attachment #2: Type: text/html, Size: 574 bytes --]

Re: [9fans] xml

[Rob Pike]

I should add that Russ's post is on point, Wadler's slightly off.  I
would extend it as "The essence of XML is this: the problem it solves
is not hard, it does not solve the problem well, and anyway it's not
the problem people think it solves."

-rob

Re: [9fans] xml

[erik quanstrom]

On Mon Jun 28 14:56:12 EDT 2010, robpike@gmail.com wrote:
> I should add that Russ's post is on point, Wadler's slightly off.  I
> would extend it as "The essence of XML is this: the problem it solves
> is not hard, it does not solve the problem well, and anyway it's not
> the problem people think it solves."

yet in that it does something, it does so vigorously and verbosly
and does so less vexatiously than asn.1, which does solve the
problem xml purports to solve.

- erik

Re: [9fans] xml

[Corey Thomasson]

On 28 June 2010 15:06, erik quanstrom <quanstro@labs.coraid.com> wrote:
> yet in that it does something, it does so vigorously and verbosly
> and does so less vexatiously than asn.1, which does solve the
> problem xml purports to solve.
>
> - erik
>
>

Was I supposed to hear that in my head as Hugo Weaving? Cuz' I did.

Re: [9fans] xml

[hugo rivera]

Now that I had a closer look to xml files, I think I get the main idea.
>From my point of view, xml doesn't seem so bad after all (please,
please, this is just an uninformed opinion) but perhaps in the future
I'll be able to see its defects.

--
Hugo

Re: [9fans] xml

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

On Wed, Jun 30, 2010 at 7:47 AM, hugo rivera <uair00@gmail.com> wrote:

> Now that I had a closer look to xml files, I think I get the main idea.
> From my point of view, xml doesn't seem so bad after all (please,
> please, this is just an uninformed opinion) but perhaps in the future
> I'll be able to see its defects.
>
> --
> Hugo
>
>
What XML buys you is a bunch of tools that already work for about half of
what you'd want a language tool to do.  By this I mean there's parsers
already written, and lots of libraries to examine the tags at different
levels in a hierarchy or stream of XML data.

You still have to define the meaning of each tag, attribute and tagged text.
 For validation of documents in XML there's other XML technologies like
Schemas you can use, or you could describe the valid set of tags in a DTD.

To add to the madness you can write XML files that translate XML files to
other files (possibly other XML files) in an XML defined language called
XSLT.  XSLT is a bit like writing in a functional programming language with
the worst syntax possible :-).

The reason I say "worst syntax possible" is that the amount of typing you'll
do to express something simple in XML is pretty excessive.

Eventually you'll find that the entire world became a nail for the XML
hammer and that things like SOAP, XML-RPC, are just not very good due to the
fact that sending XML documents on a wire for simple RPC calls is grossly
inefficient, and there's a lot better technology out there for these sorts
of things.

That said, XML is still here, and you kind of have to learn to play ball
with it.  I just had a discussion with a coworker about a configuration
language for a management project here at work and had to argue in XML's
defense (customers will more easily understand and be able to accept an XML
language than whatever new cute DSL we come up with).

I feel like I need a shower now.

Dave

[-- Attachment #2: Type: text/html, Size: 2517 bytes --]

Re: [9fans] xml

[ron minnich]

On Wed, Jun 30, 2010 at 11:25 AM, David Leimbach <leimy2k@gmail.com> wrote:
>
> Eventually you'll find that the entire world became a nail for the XML
> hammer and that things like SOAP, XML-RPC, are just not very good due to the
> fact that sending XML documents on a wire for simple RPC calls is grossly
> inefficient, and there's a lot better technology out there for these sorts
> of things.

as long as you don't care about the (observed) 100:1 ratio of XML glop
to data in, e.g., the Python XMLRPC stuff, it's great. Yep, I observed
that ratio when Xen made the cut to XML-RPC: 3000 bytes of RPC to send
30 bytes of data. It's impressive: gigE gets reduced to 10 Mb ethernet
in no time; XML-RPC turns the network clock back by 20 years.

Software choices have hardware consequences.

> That said,XML is still here, and you kind of have to learn to play ball
> with it.

Funny, I at first read this as "That's sad, XML is still here, ..."

Then I had to re-read it.

ron

Re: [9fans] xml

[Pietro Gagliardi]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Jun 30, 2010, at 2:43 PM, ron minnich wrote:
> as long as you don't care about the (observed) 100:1 ratio of XML glop
> to data in, e.g., the Python XMLRPC stuff, it's great. Yep, I observed
> that ratio when Xen made the cut to XML-RPC: 3000 bytes of RPC to send
> 30 bytes of data. It's impressive: gigE gets reduced to 10 Mb ethernet
> in no time; XML-RPC turns the network clock back by 20 years.

A friend on AIM who I showed this quote to suggested XML should drop
named close tags as a solution: <tag>stuff</>

"C and Ratfor programmers find BEGIN and END bulky compared to
{ and }." - bwk


[-- Attachment #2: Type: text/html, Size: 1004 bytes --]

Re: [9fans] xml

[Corey Thomasson]

On 30 June 2010 15:54, Pietro Gagliardi <pietro10@mac.com> wrote:
> A friend on AIM who I showed this quote to suggested XML should drop named
> close tags as a solution: <tag>stuff</>
> "C and Ratfor programmers find BEGIN and END bulky compared to { and }." -
> bwk
>

The </> suggestion has come up 8000 times in as many forums, to no avail.

Supposedly, the excess verbosity makes it more readable/less error-prone.

Re: [9fans] xml

[erik quanstrom]

> The </> suggestion has come up 8000 times in as many forums, to no avail.
>
> Supposedly, the excess verbosity makes it more readable/less error-prone.

to paraphrase, a sufficient amount of readable data is
as good as unreadable data.

- erik

Re: [9fans] xml

[Wes Kussmaul]

If you gathered up a bunch of old, proven data representation methods,
packaged it as XML 2.0, formed an XML 2.0 consortium and put it out
there energetically with bullet points and with a straight face, people
would buy it.

No, listen, it's true, they would. The straight face part is important
though.

http://fudili.com/

"If God had not meant them to be shorn, He would not have made them sheep."
 - Pancho Villa

--
Learn about The Authenticity Economy at

http://video.google.com/videoplay?docid=-1419344994607129684&hl=en#

Re: [9fans] xml

[Ethan Grammatikidis]

On 30 Jun 2010, at 9:53 pm, Wes Kussmaul wrote:

>
> If you gathered up a bunch of old, proven data representation
> methods, packaged it as XML 2.0, formed an XML 2.0 consortium and
> put it out there energetically with bullet points and with a
> straight face, people would buy it.
>
> No, listen, it's true, they would. The straight face part is
> important though.

Oh absolutely! You want to be successful in the computing world, pick
an idea that's been forgotten and market it. It's been done over and
over again, often to bad effect, reintroducing ideas which should
have long been buried. I do wonder if this is what the Go authors are
trying to do in a different area to xml; reintroduce good practice
under new terminology.

Perhaps there is a hard part to it: writing the idea up in such a way
as to not offend the misled sensibilities of the average sheep. Those
"misled sensibilities" are certainly a very serious problem for Go.

>
> http://fudili.com/
>
> "If God had not meant them to be shorn, He would not have made them
> sheep."
> - Pancho Villa
>
> --
> Learn about The Authenticity Economy at
> http://video.google.com/videoplay?docid=-1419344994607129684&hl=en#
>
>

Re: [9fans] xml

[Russ Cox]

> I do wonder if this is what the Go authors are trying to do in a
> different area to xml; reintroduce good practice under new terminology.

I'd like to know which good practices Go is merely reintroducing.
The concurrency model, sure, but I believe the approaches to
interfaces and name visibility are new, as is having a garbage
collected language that lets you take the address of fields
in the middle of objects.  If you know of earlier work that already
did these, I'd be interested to hear about it.

Thanks.
Russ

Re: [9fans] xml

[Bakul Shah]

On Thu, 01 Jul 2010 10:12:00 PDT Russ Cox <rsc@swtch.com>  wrote:
> > I do wonder if this is what the Go authors are trying to do in a
> > different area to xml; reintroduce good practice under new terminology.
>
> I'd like to know which good practices Go is merely reintroducing.
> The concurrency model, sure, but I believe the approaches to
> interfaces and name visibility are new, as is having a garbage
> collected language that lets you take the address of fields
> in the middle of objects.  If you know of earlier work that already
> did these, I'd be interested to hear about it.

I haven't played with go much but aren't go's interfaces much
like Haskell's type classes? The latter do seem much nicer to me.
    http://www.haskell.org/tutorial/classes.html

Apple's Obj C is now GCed so I think it will allow you to
take address of a field in the middle of an object. You can
use Bohm-Demers-Weiser conservative GC with C too!

Perhaps not the same as in go but in the same neighbourhood, no?!

Re: [9fans] xml

[Jorden M]

On Thu, Jul 1, 2010 at 1:43 PM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
> On Thu, 01 Jul 2010 10:12:00 PDT Russ Cox <rsc@swtch.com>  wrote:
>> > I do wonder if this is what the Go authors are trying to do in a
>> > different area to xml; reintroduce good practice under new terminology.
>>
>> I'd like to know which good practices Go is merely reintroducing.
>> The concurrency model, sure, but I believe the approaches to
>> interfaces and name visibility are new, as is having a garbage
>> collected language that lets you take the address of fields
>> in the middle of objects.  If you know of earlier work that already
>> did these, I'd be interested to hear about it.
>
> I haven't played with go much but aren't go's interfaces much
> like Haskell's type classes? The latter do seem much nicer to me.
>    http://www.haskell.org/tutorial/classes.html

Of the many languages that try to do type parameterization with type
classes as restrictions, they all seem to be very clunky compared to
Haskell.

`Interfaces', the way they are invariably implemented, don't cut it --
too limiting and imposing. `Templates' and `Concepts' together are
close to the Haskell way in spirit, but the execution seemed to suffer
from being bolted onto C++ and fighting with its flavor of OO. Duck
Typing isn't a solution, it's ignoration just asking for trouble.

In any case, getting a type system to be sane and please more than 90%
of the users is hard (insoluble?). Haskell is getting bigger, and you
can see some of the expansion is related to corner-cases in dealing
with the type system (multi-param type classes & fundeps, existential
types, GADTs, etc.)

>
> Apple's Obj C is now GCed so I think it will allow you to
> take address of a field in the middle of an object. You can
> use Bohm-Demers-Weiser conservative GC with C too!
>
> Perhaps not the same as in go but in the same neighbourhood, no?!
>
>

Re: [9fans] xml

[Rob Pike]

> `Interfaces', the way they are invariably implemented, don't cut it --
> too limiting and imposing.

I do not claim that Go's interfaces can match the type system of
Haskell but this sentence tells me you aren't very familiar with them.
 They are not implemented, invariably or otherwise, like any other
things called interfaces that I know.  They also don't work very much
like the same-named things in other languages.

As for limiting? Maybe. Imposing? Not at all. If anything, I'd call
them liberating.

As Russ said, there's more new in Go than many observers seem to
realize.  The language looks much more traditional than it really is.

-rob

Re: [9fans] xml

[Bakul Shah]

On Thu, 01 Jul 2010 11:49:31 PDT Rob Pike <robpike@gmail.com>  wrote:
>
> I do not claim that Go's interfaces can match the type system of
> Haskell

Given that all variables have to be explicitly typed (as far
as I can remember), I thought it would be even easier to do
something like Haskell type classes!  So if you see

	a == b

== would map to a function depending on which type clas a &
b's type belongs to. But this is all idle speculation and I
am sure I am missing something fundamental.

> As Russ said, there's more new in Go than many observers seem to
> realize.  The language looks much more traditional than it really is.

Agreed. Go seems like a very nice language. In a sense
everything has been done before but a good combination of
features can still be quite eye opening and provide a
pleasing, easy to use environment [Though I still prefer
Scheme :-)]

Re: [9fans] xml

[Jorden M]

On Thu, Jul 1, 2010 at 2:49 PM, Rob Pike <robpike@gmail.com> wrote:
>> `Interfaces', the way they are invariably implemented, don't cut it --
>> too limiting and imposing.
>
> I do not claim that Go's interfaces can match the type system of
> Haskell but this sentence tells me you aren't very familiar with them.
>  They are not implemented, invariably or otherwise, like any other
> things called interfaces that I know.  They also don't work very much
> like the same-named things in other languages.
>
> As for limiting? Maybe. Imposing? Not at all. If anything, I'd call
> them liberating.
>
> As Russ said, there's more new in Go than many observers seem to
> realize.  The language looks much more traditional than it really is.
>
> -rob
>
>

I wasn't making a particular statement about Go, as I am not that
familiar with it. Syntactically, it's eerily similar to Algol, but
obviously there's more to a language than syntax. We all know how
sweeping generalizations are.

Go's interfaces definitely cut down on coupling compared with, let's
say Java and C++, since they're fun to beat on. I am left to wonder if
the implicitness of Go interfaces causes problems until I explore the
language more. Lack of polymorphism in the interfaces seems to limit
the extent to which they can be compared to Haskell type classes, but
it seems safe to say that they are definitely a subset.  Being a bit
more general than Go is with the kinds of function types a
class/interface can specify seems incredibly useful, so, limiting,
yes. Imposing... perhaps not. But I wasn't interested in starting a
`my typesystem can beat up yours' non-discussion, just pointing out
something that seems to have a lot of functionality while still being
incredibly elegant compared to alternatives. Haskell manages to think
farther outside the box than just about everyone, and we'll need a lot
of that as the multicore roll-out continues.

In any event, these kinds of square-peg-round-hole comparisons are
always subject to the Turing-completeness reductio ad absurdum so I
guess it's best not to look too deeply.

Re: [9fans] xml

[roger peppe]

On 1 July 2010 20:34, Jorden M <jrm8005@gmail.com> wrote:
> Lack of polymorphism in the interfaces seems to limit
> the extent to which they can be compared to Haskell type classes, but
> it seems safe to say that they are definitely a subset.

it's not as safe as you think - that's not true. in some
ways, go's interfaces are more general than haskell's
type classes.

the two are pretty much orthogonal to one another, in fact.
go's interfaces are more equivalent to haskell's Type.Dynamic
except less restrictive (fromDynamic asserts a particular
type, which is like asserting a static type in go rather than
an interface type).

haskell's type classes work top down - one type identifier
always represents the same underlying type; whereas
in go each variable of interface type can hold a different
underlying type.

Re: [9fans] xml

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On Wed, Jun 30, 2010 at 3:54 PM, Pietro Gagliardi <pietro10@mac.com> wrote:

> On Jun 30, 2010, at 2:43 PM, ron minnich wrote:
>
> as long as you don't care about the (observed) 100:1 ratio of XML glop
> to data in, e.g., the Python XMLRPC stuff, it's great. Yep, I observed
> that ratio when Xen made the cut to XML-RPC: 3000 bytes of RPC to send
> 30 bytes of data. It's impressive: gigE gets reduced to 10 Mb ethernet
> in no time; XML-RPC turns the network clock back by 20 years.
>
>
> A friend on AIM who I showed this quote to suggested XML should drop named
> close tags as a solution: <tag>stuff</>
>
>
Could just go back to SGML:

<tag/stuff/


> "C and Ratfor programmers find BEGIN and END bulky compared to { and }." -
> bwk
>
>


--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
 -- Ovid

   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus

[-- Attachment #2: Type: text/html, Size: 2375 bytes --]

Re: [9fans] xml

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

> To add to the madness you can write XML files that translate XML files to
> other files (possibly other XML files) in an XML defined language called
> XSLT.  XSLT is a bit like writing in a functional programming language with
> the worst syntax possible :-).
>
> The reason I say "worst syntax possible" is that the amount of typing
> you'll do to express something simple in XML is pretty excessive.
>

You could also use XQuery, which has syntax that functional programmers are
used to, but lacks the semantic features you'd want in such a language. I
remember I asked one of the MarkLogic XQuery implementation team members
about HOF & TCO in the latest version of MarkLogic Server. I was told that
TCO isn't on the radar for them, and if you want HOF, uses strings + eval.
le sigh.

--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
 -- Ovid

   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus

[-- Attachment #2: Type: text/html, Size: 1964 bytes --]

Re: [9fans] xml

[Dean Bittner]

There are many things I don't like about xml, and most have been mentioned.

There are several ideas around xml that I like.  I self-describing aspect of xml is convenient.  The ability to represent structured data is great too, and I like to be able to edit the data in a text editor and otherwise send and store the data as text.  These ideas make data very portable and mobile for me, and I tend to need that kind of thing in my projects.

In places that I once used xml, I now use JSON.  It has the advantages I've mentioned and seems to serve me well.