Slashdot Mirror

I certainly understand the frustration of dealing will overly complex systems or also a rushed language like JavaScript where variables are globals by default. Still, did you know that you can compile almost anything to JavaScript these days and have it run in the browser at near native speeds (well, only some browsers, but likely more and more). See: http://techcrunch.com/2013/12/...
"While Google is betting on Native Client to allow web apps to execute native compiled code in the browser, Mozilla is betting on its ability to run JavaScript at near-native speeds, too. While they approach this problem from very different angles, both Google, through Native Client, and Mozilla, through its Emscripten LLVM-to-JavaScript compiler, allow developers to write their code in C or C++ and then run it in the browser."

So, JavaScript is just another platform now in that sense. But it is a platform that is almost everywhere significant for substantial human interaction... And installing JavaScript software for the end-user is as easy often-times as just surfing to a web page. If people don't actually install your software, what good is it?

Does JavaScript have problems? Yes. Tons. But it also has a lot of merits.

As for gibberish -- Cantonese sounds mostly like gibberish to me, but that is because I never learned to speak it. :-)

Would I like a simpler software stack and simpler but better languages and tools? Yes. I helped fight that battle over a decade ago like with VisualWorks/Squeak and we lost to stuff like Java, PHP, and JavaScript and the associated tool chains. Squeak showed what was possible, but almost no one would install it (the Squeak licensing confusion did not help there either). See also:
http://bitworking.org/news/290...
"Regular readers are quite tired of me pointing to this video, Alan Kay: The Computer Revolution hasn't happend yet. Keynote OOPSLA 1997, but I think it's quite fundamental to understand that Alan Kay had a vision for the web, and though his understanding of the role of HTML in the world of 1996 was flawed, it seems the collective web has spent the last ten years building exactly what he described, with HTML/SVG being the display substrate and JavaScript being the code to drive that display. Ten years later we have the Lively Kernel: ..."

But the past is the past. We have to start from where we are -- and today, people live in their HTML5/CSS3/JavaScript browsers or will soon (even on phones, and especially on the emerging Firefox OS phones). I'm writing this from a US$250 Chromebook that is almost entirely just a browser as far as user experience. Any sophisticated-enough system could eventually remake the stack underneath it, like native Squeak could do. So, saying we could build on JavaScript does not mean endless perpetual complexity. Chrome OS shows how a focus on HTML/CSS/JavaScript can sometimes simplify things though from one perspective, especially user experience.

There are several issues related to complexity (inherent complexity, accidental complexity, user expectations, installability, standards, etc.). Regardless of technical merit, HTML/CSS/JavaScript/PHP won in key areas. Sure, you can create the next Squeak, and good luck with that, it is a fun project. And/or we can try to use the current widespread platform as best as we can. For me right now, that means minimizing the backend (PHP or whatever) while emphasizing the front-end (JavaScript) and ideally encoding data in useful long-term forms.

And for those who like their Smalltalk deployed as HTML/CSS/JavaScript, see:
http://amber-lang.net/
"The Amber language is deeply inspired by Smalltalk. It is designed to make client-side development faster and easier. Amber includes a live development environment with a class b

The cross-platform install process is easier with Javascript than just about anything else. That is the biggest win here -- beyond the idea of open source virtual worlds which others have done before. Perhaps that didn't used to be the case years ago, but it is now for any software that is going to quickly get mass adoption. Still, it's true that Android and iOS both try to make that easy -- if you've bought special hardware. HTML5 and related technologies like WebGL are trying to create standards for being able to use back-end engines, and Voxel.js taps into that.

Here is Alan Kay talking about why Dan Ingalls started working on the next generation of Squeak (the "Lively Kernel") in Javascript:
http://bitworking.org/news/290/JavaScript-is-the-new-Smalltalk

Still, I tried to run Voxel.js in Firefox 18 on the Mac, with having to turn on "experimental" (for my mac) WebGL support just for this, and it crashed my browser every time. Nonetheless, it's only a matter of time before good 3D support is in browsers everywhere. Personally, I'd have rather seen a well-sandboxed virtual machine as the standard in the browser (whether Java, Parrot, Lua, or anything else), but Javascript is what we got.

Actually, I've been wondering if I could run Voxel.js on top of Java running a Javascript engine that talks to a 3D backend? As a software developer, I'm willing to go through more install hassles, even if I know most people aren't.

I thought they were here to promote the worship of the Free Market Fairy. Mental eight year olds don't understand Marxism, just look at all the teabaggers who think Obama is a Marxist.

It is ironic that HTML, originally developed precisely to make it easy to mark up academic and technical information for publication, has never moved beyond the extremely bare-bones specification of heading, list, term, and paragraph tags. I would have expected some elaboration over time, but HTML seems frozen in time.

What happened, I think, is that people basically ignored HTML and went straight for word processing, a far more complex beast from a specifications point of view. For the past 20 years, we have been letting HTML languish while we attempt to come up with a document specification. ODF is the just the most recent cycle on this effort.

It is unfair of the parent to pin the blame for this on Microsoft, however. Word processing was one of the "killer apps" at the time of the birth of the web, and Word was just a niche player at the time. No, we went straight for the jugular of word processing because we all wanted to print to paper.

The OP is absolutely correct to think about revisiting HTML as a specification. What I hate about all reader-dependent formats (DOC, ODF, PDF, ...) is they force the user to completely leave the context of the web page just to view some data. The browser is the only "reader" I should need . If you can't at least embed on the page, fuggetaboutit. The gold standard is compound content with full document flow. Why oh why can't we come up with a simple way to blend content without drawing frames and putting scrollbars within scrollbars!?

Personally, I'd love to see some formality and general adoption of richer semantic markups such as the microformats hCard, hCalendar, etc. I'd also love to see some richer hierarchical markup; simple lists only take you so far! I'm imagining something with the hierarchy of XML but without the complexity of full extensibility, and all the definitional parts of a specification needed to support that (schemas).

The Atom Publishing Protocol is the perfect example of what I'm talking about: extensible, but easy to use because it comes with a well-chosen set of standard elements and attributes.

True say. In fact, you could generalise that to any post starting "In a free market..." getting +5 insightful. Funny, for all the atheism round here, how many quaintly have total faith in the Free Market Fairy. Merely depressing, on the other hand, how many use it as a stick to beat government and regulation with, failing to realise the only thing that would make a free market (if we ever saw one) free, efficient and fair is, uh, law.

Atom is both a syndication format and an API for creation, updating, and deletion of content. It's already in widespread use by Blogger.

What's been (all but) finalized is the syndication format (and rules for extending it). This allows the working group to firm up the details of the publishing API, which, for my money, is the real payoff with Atom.

A pretty good overview of the history of RSS and the motivations behind Atom is here.

I read Joe Gregorio's take on XForms a while back. XForms seems to make everything regarding forms/interactivity unnecessarily complicated. (The standard might've been simplified since then, un-RTFA etc.)

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

Bray's paper appears to express a strong preference for an XML that would work well with ?standard regex tools. In it he says, "If I use any of the perl+XML machinery, it wants me either to let it read the whole thing and build a structure in memory, or go to a callback interface." And then it adds that callback "is sufficiently non-idiomatic and awkward that I'd rather just live in regexp-land."

This, in turn, seems to be based on an article linked to in Bray and advocating the same thing.

It seems to me that to convince the larger world that this is necessary, some other options would have to be excluded. Aren't regexs of some sort going to be in v. 2 of XSLT? None of its successful implementations require loading the document into memory, and it nicely magics away the namespace kerfuffle that Gregorio's examples illustrate.

What I took away from the article was considerable amazement that one of the markup luminaries uses such low-level tools to process XML.

Aggie is an open source news aggregator. Basically, you give it the URL to your favorite RSS feeds, it downloads and parses them, and then builds a web page with the headlines. The really nice thing about it is that it supports RSS autodiscovery, so in many cases, you can simply provide the URL to the site itself, and it will find the RSS feed for you.

It does not use the GPL, but its license is considered open source by the OSI definition.

Another caveat is that it is written in C# and thus requires the .NET framework to run, so it isn't portable to other operating systems (not yet, at least). The upside is that the C# source code is fairly easy to follow, even for a dunce like me.