Slashdot Mirror

He doesn't say "XML is S-expressions" (though the main arguer to the contrary skips around a lot without actually refuting the proposition), he says "JSON is S-expressions". If you spend about 45 seconds reading Introducing JSON, sure enough, JSON is S-expressions.

S-expressions, of the sort used in Common Lisp and Scheme, would have been a good alternative. They're simple, use a minimal number of characters, and are very easy to parse. Hell, most Comp Sci grads have written at least once such parser during their education.

This article argues the other side of that point. I'm not sure how convincing it is, but there are at least some benefits to the XML approach. Where the balance falls, I don't know.

None of these software firewalls are of any use as they can be disabled by the next exploit. What is needed is a firewall running on standalone embedded hardware. Of course with the use of RPC over HTTP and SOAP, a firewall is of limited use in this day and age.

Here is the story as presented by Paul Graham (a famous Lisp expert). Of the three languages he chooses to discuss, Java, Perl and Python, Python is considered cooler (if not more popular) than Perl and Perl cooler (if not more popular) than Java because Python is most like Lisp of the three. Unfortunately, Python is a sort of immature Lisp which may over time grow into its full Lisp-yness but why wait around when you could just be using Common Lisp today? I'm sure if you are a Lisp programmer, it is a compelling story. Unfortunately it does not ring true.

Each of the items I listed are too large and complex, and are beyond repair, but in the same respect could NEVER be recreated in a reasonable time frame.

Two questions:

1) By suggesting email "could NEVER be recreated in a reasonable timeframe" you are inferring that a reinvented email system must be complex. Why would that be? We don't have to re-invent security, authentication, encryption from scratch for use especially for email--we already have the technology and use it extensively (HTTP(S), LDAP, Kerberos, SSH, etc). What is missing in email is an elegant integration of these technologies.

2) Even if architecting a next-generation email system would take a long time, why would that be a problem? What would be a "reasonable" timeframe? Personally I don't think that a W3C-like standards body would take more than 5 years to craft a usable standard, and by the time it hit 1.0 there would already be a lot of early implementations. Sure it would take a long time to adopt, but there could be email gateways like there was between the internet and old-school nets like Fidonet, and those gateways can handle the spam and other crap before they hit any "new and improved" email servers.

When something gets as broken as email people are more motivated to fix it. There are already some interesting ideas out there that could catch on...

I think the parenthetical version and the XML version are about equal in terms of readability once you remember that any decent editor will have syntax highlighting to emphasise the text over the tags and that both versions will typically be split over multiple lines. Linebreaks don't really aid readability when you have short ending delimiters, but they do when you have longer ending delimiters.

The idea that XML is just a reinvention of s-expressions is quite popular, but this article does a decent job of explaining how they differ.

"(Some of them keep being reinvented; watching the XML fans reinvent LISP is amusing.)"

Not as amusing as you (educated as you claim) repeating this fallacy.

http://www.prescod.net/xml/sexprs.html

Because as I've pointed out for the one-billionth time. XML is not S-Expressions Now why don't you all give it a rest.

...scripting is a terrible way to handle form input. It just doesn't scale...

This is just plain wrong. The current use of forms over HTTP scales beautifully because it separates the user-agent (browser) from the application. No tightly-bound system in existence can handle the load that web applications handle [and you doubters best remember that the green-screen mainframes use request-response protocols almost exactly like HTTP].

See Roy Fielding's work on REST to understand why web applications DO scale so well. And here's a simple example of REST.

"(If you think about it, it started quite a time ago, since xml is isomorphic to sexps.)"

XML is not S-Expressions.

XML is not S-Expressions.

For all those going to say this? Read this.

To a Lisp hacker, XML is S-expressions in drag.

The one difference that I have found is relevant is that if you add static type annotations to Pyrex you get Python-level speeds.

References:

1: http://www.prescod.net/python/pyrexopt/optimizatio n.html

2: http://mail.python.org/pipermail/python-list/1999- April/001319.html (look for the words "interpreter" and "overhead")

3: http://www.python.org/pycon/dc2004/papers/1/paper. pdf

Why was this modded up? Just mindless MS bashing with no facts to back it up.

• SOAP and it's security bypassing
• More about SOAP's deliberate attempt to subvert network security

Now, granted, I did make a connection that SOAP was the only protocol for inter-device communication in .Net (it isn't). But considering Microsoft has been encouraging developers to think about making every .NET service SOAP enabled, it's hard not to wonder...

.Net, conceptually, sounds neat but Microsoft still has a single, non-networked PC mentality. I didn't even mention Linux/Apache/PHP/Java/etc becuase it's not about them being better or worse. It's about the fact that .Net was an idea pushed out as a "neat idea" without thinking through its implications.

I'd read the first things Microsoft officially published about it back when they were hot of the keyboards of the developers. .NET is a neat idea, but the security implications are scary. .NET applications are expected to exchange code and run remotely. They have a grand vision of .NET code being swapped across the planet and running on everything from your cellphone to mission critical servers. Creating a monoculture where a malicious worm can spread like wildfire before anyone can even react is a frightning thought.

Saying "Well, it's up to the developer to make it secure" is like saying "Well, it's up to the sysadmin to apply the Blaster patches". They should, but they won't.

True, XML is overkill for many many uses, but the matter of fact upside is ubiquity. I disagree in that a DTD gives you anything other than validation. Even if you have a DTD you can only validate the STRUCTURE of the XML...you still can't glean any MEANING from it. Which is why a lot of platforms simply choose to parse XML loosely with regular expressions and just treat it as a simple hierarchical format.

There are certain discrepencies between XML and S-expressions. It is true that any of these other formats "would do", and believe me, I am by no means an advocate of inappropriate, and over- use of XML, but the reality is that the proposed format is so tiny to begin with, and XML is so universally accepted, that it is practically moot whether this or that format would be "better". There are already a wealth of tools to index, mine, translate, etc. etc. XML.

Here are some links. See esp. the REST Wiki:
Adam Bosworth's Weblog: Learning to REST
Bitworking - The Well-Formed Web - REST
Debate foams over SOAP 1.2 - REST versus SOAP
How To Convert Rpc To Rest
http://www.xfront.com/ - REST Tutorial, XML et al - Roger Costello's site
ITworld.com - XML IN PRACTICE - XML, Web Services, and the REST Architecture
Mark Baker, Tech Curmudgeon - REST - Transport, transfer and coordination in HTTP
O'Reilly Network: REST vs. SOAP at Amazon [June 24, 2003]
Paul Prescod's REST Resources
Reliable delivery in HTTP - REST
REST A Web-Centric Approach to State Transition - Paul Prescod
REST could burst SOAP's bubble - Hoobler
REST Faq - Alternative to SOAP XML
REST SlideShow: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction
REST wiki - Representational State Transfer - alternative to SOAP XML
rest-discuss Message 2330 - ROP vs RPC vs OOP pt 1
Roots of REST - SOAP Debate - Paul Prescod Yahoo! Groups : rest-discuss Messages :Message 1314 of 1646
Roy T. Fielding - REST Architect
Sean McGrath BLOG - REST proponent
W3C mailing-list search service on REST
Why you should not use RPC for GET
xml-dev - Re: [xml-dev] SOAP-RPC and REST and security
XML.com: In a Lather About Security - SOAP security vs REST security
Yahoo! Groups : rest-discuss Messages : 2371-2428 of 2428

Here are some links. See esp. the REST Wiki:
Adam Bosworth's Weblog: Learning to REST
Bitworking - The Well-Formed Web - REST
Debate foams over SOAP 1.2 - REST versus SOAP
How To Convert Rpc To Rest
http://www.xfront.com/ - REST Tutorial, XML et al - Roger Costello's site
ITworld.com - XML IN PRACTICE - XML, Web Services, and the REST Architecture
Mark Baker, Tech Curmudgeon - REST - Transport, transfer and coordination in HTTP
O'Reilly Network: REST vs. SOAP at Amazon [June 24, 2003]
Paul Prescod's REST Resources
Reliable delivery in HTTP - REST
REST A Web-Centric Approach to State Transition - Paul Prescod
REST could burst SOAP's bubble - Hoobler
REST Faq - Alternative to SOAP XML
REST SlideShow: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction
REST wiki - Representational State Transfer - alternative to SOAP XML
rest-discuss Message 2330 - ROP vs RPC vs OOP pt 1
Roots of REST - SOAP Debate - Paul Prescod Yahoo! Groups : rest-discuss Messages :Message 1314 of 1646
Roy T. Fielding - REST Architect
Sean McGrath BLOG - REST proponent
W3C mailing-list search service on REST
Why you should not use RPC for GET
xml-dev - Re: [xml-dev] SOAP-RPC and REST and security
XML.com: In a Lather About Security - SOAP security vs REST security
Yahoo! Groups : rest-discuss Messages : 2371-2428 of 2428

Here are some links. See esp. the REST Wiki:
Adam Bosworth's Weblog: Learning to REST
Bitworking - The Well-Formed Web - REST
Debate foams over SOAP 1.2 - REST versus SOAP
How To Convert Rpc To Rest
http://www.xfront.com/ - REST Tutorial, XML et al - Roger Costello's site
ITworld.com - XML IN PRACTICE - XML, Web Services, and the REST Architecture
Mark Baker, Tech Curmudgeon - REST - Transport, transfer and coordination in HTTP
O'Reilly Network: REST vs. SOAP at Amazon [June 24, 2003]
Paul Prescod's REST Resources
Reliable delivery in HTTP - REST
REST A Web-Centric Approach to State Transition - Paul Prescod
REST could burst SOAP's bubble - Hoobler
REST Faq - Alternative to SOAP XML
REST SlideShow: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction
REST wiki - Representational State Transfer - alternative to SOAP XML
rest-discuss Message 2330 - ROP vs RPC vs OOP pt 1
Roots of REST - SOAP Debate - Paul Prescod Yahoo! Groups : rest-discuss Messages :Message 1314 of 1646
Roy T. Fielding - REST Architect
Sean McGrath BLOG - REST proponent
W3C mailing-list search service on REST
Why you should not use RPC for GET
xml-dev - Re: [xml-dev] SOAP-RPC and REST and security
XML.com: In a Lather About Security - SOAP security vs REST security
Yahoo! Groups : rest-discuss Messages : 2371-2428 of 2428

Here are some links. See esp. the REST Wiki:
Adam Bosworth's Weblog: Learning to REST
Bitworking - The Well-Formed Web - REST
Debate foams over SOAP 1.2 - REST versus SOAP
How To Convert Rpc To Rest
http://www.xfront.com/ - REST Tutorial, XML et al - Roger Costello's site
ITworld.com - XML IN PRACTICE - XML, Web Services, and the REST Architecture
Mark Baker, Tech Curmudgeon - REST - Transport, transfer and coordination in HTTP
O'Reilly Network: REST vs. SOAP at Amazon [June 24, 2003]
Paul Prescod's REST Resources
Reliable delivery in HTTP - REST
REST A Web-Centric Approach to State Transition - Paul Prescod
REST could burst SOAP's bubble - Hoobler
REST Faq - Alternative to SOAP XML
REST SlideShow: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction
REST wiki - Representational State Transfer - alternative to SOAP XML
rest-discuss Message 2330 - ROP vs RPC vs OOP pt 1
Roots of REST - SOAP Debate - Paul Prescod Yahoo! Groups : rest-discuss Messages :Message 1314 of 1646
Roy T. Fielding - REST Architect
Sean McGrath BLOG - REST proponent
W3C mailing-list search service on REST
Why you should not use RPC for GET
xml-dev - Re: [xml-dev] SOAP-RPC and REST and security
XML.com: In a Lather About Security - SOAP security vs REST security
Yahoo! Groups : rest-discuss Messages : 2371-2428 of 2428

RESTful web services are the services primarily in place today: they utilize existing WWW security standards, are easy to implement and debug, and are available today.

• REST Wiki
  
• Building Web Services the REST Way
  
• Paul's REST Resources
  
• REST and the Real World
  
• Second-Generation Web Services
  

SVG is similar in scope to Flash, but it is a W3 recommendation (i.e. a standard) and uses an open format.

SVG is actually much broader in scope than Flash, PDF, or other proprietary formats, as aptly pointed out by Paul Presod at SVG Open 2003.

Furthermore, the XML project of the Apache Software Founcation is hard at work on Batik, a Java-based toolkit for applications or applets that want to use images in the SVG format.

Just stick with LISP then. You do it in LISP and the others choose what they want to do it in. I assume you can do it blindfolded, gagged and all your fingers and toes behind your back, and faster too, in LISP.. Then do it!

But please spare us the stiff attitude and elitism..

Just to prove you wrong though: XML is not S-Expressions

Yeah, I'm amazed how many Perl programs don't handle error conditions well. By "don't handle well" I mean "ignore completely". When I first saw this page (it's written in Perl), some of the values were zero when they shouldn't have been. They get the data by scraping altavista, but they don't check for errors when they retreive the data. Lucky it's just a novelty site and isn't actually showing something important.

Slashdot (written in Perl) randomly gives me some some weird "formkey" error when I try to post -- that's a step up, at least it's recognizing that an error occured -- but it's caught too late, and the software tries to blame the error on me. It says I had pressed the back button (I hadn't) or I have a firewall (I have, but I don't see what that's got to do with random errors on Slashdot). Clearly an error had occured earlier, but they didn't catch it at its origin.

Also on Slashdot, when the site is under heavy load, the front page sometimes shows ads -- the same ad repeated -- between each story. I don't think that's meant to happen.

Then there's the famous story of the two high-school kids who were suspected of taking a shotgun to school because of a subtle Perl error.

That's just some anecdotal evidence, but it's representative of my personal experience with software written in Perl. I don't know if it's the language or the programmers. I suspect it's both. Some more anti-Perl material:

What's wrong with Perl by Lars Marius Garshol

Is Perl Difficult? by Paul Prescod

that the same applications of XML that drive the keening about bloat and hype seen in these comments are precisely those which are driving the specs to the wrong side of the 80/20 for XML/XSL's original goals: bringing the semantic power of SGML and DSSSL to the Web. Goals for which its purist cousins RelaxNG, REST, et. al. remain admirably suited.

The back-end curmudgeons are right, XML stinks for a universal wire format. But for loosely-coupled, message-based, semantically-rich systems it is hard to beat. And document-oriented systems which don't use XML barely deserve notice any longer.

I gently refer s-expression trolls to paul and oleg

Because its much easier to detect and locate errors with tags rather than parantheses. If I'm missing a closing bold tag in HTML its simple for a parser to detect two open bold tags with no close in between. If you're only using parens you're out of luck. See XML is not S-Expressions for more in depth analysis.

• Death of the Browser? (on Microsoft's site) and
  
• The Return of Client/Server -- or, at Least, Rich Clients
  

But first go see how Debate foams over SOAP 1.2 in the W3C working groups for XML, SOAP and Web Services.

It seems that Roy Fielding, one of the key architects of HTTP and a member of the W3C TAG (Technical Architecture Group), which essentially defines the principles of Web architecture inside the W3C, pointed out that the SOAP specification broke universally-accepted WWW protocols and would be unlikely to succeed. At the same time Fielding and others have pointed out that Web Services can easily be implemented today including all desired security and authentication by using current WWW protocols and by judicious use of what he calls a REST Architecture, a subset of the current WWW architecture.

Microsoft's plan is unlikely to work: the members of the involved working groups have realized that failure of SOAP to be consistent with WWW will doom it to failure because of the additional complexity and lack of scalability that would entail.

See also

• Paul Prescod's Home Page and especially the section "HTTP and REST" wherein he elucidates the subtleties of REST and how SOAP breaks the WWW. Prescod is one of the most vociferous and well-written supporters of the REST architectural style in the W3C working groups.
  
• A REST Tutorial for Roger Costello's brief but excellent introduction to Roy Fielding's REST and why it will be the basis for any viable Web Services architecture.
  
• Visit the REST Wiki to relax in an oasis of ideas that explains how Web Services can be implemented today in a manner
  
  • not as complex as the proprietary vendors and current and pending specifications of SOAP appear to require,
    
  • using the technology and tools you already know.

Finally, dive into the waters of the oasis and wash the SOAP off of your soul. Now pure of heart, make a pilgrimage to Tim Berners-Lee's Design Issues for the World Wide Web where you can

• re-examine the issues of the WWW,
  
• renew your commitment to doing things "the right way",
  
• revive your passion for excellence and
  
• remind yourself that indeed, sometimes "less is more."
  

Here is my take. And here is Bruce Schneier's..