* * *

Thanks!

Crockford's thoughts on actors are really interesting. I tried to pull them apart but I didn't get very far and ended up not including them in the episode.

What he is envisioning is not exactly like Erlang but not exactly like Scheme. He said that Carl Hewitt had a lot of ideas and they were hard to unpack.

If you're interested though, I would reach out to him. He is very approachable and excited to talk to people with ideas for new ways of making things simple.

Just wanted to say your podcasts are really good. Many podcasters aim for quantity over quality; with you it’s the other way around. Thank you!

I do wish some more details about his current thoughts on actors had been included, though I can understand if they were hard to tease out. I would guess that may go back to his work on Electric Communities as E was a message passing system. Would be interested in hearing more of where his mind is on actors today.

The closest thing we have right now I think is Spritely Goblins, though that is Scheme. (Not coincidentally, one of the other Electric Communities co-founders is also a Spritely Institute co-founder: https://spritely.institute/about/)

The design of the language he is (was?) working on is here:

http://www.crockford.com/misty/

There are a few talks from a few months ago on Youtube that detail some of the rationale behind it.

Oh cool, thanks for the pointers!

I remember a meeting where a consultant from an MCP excitedly told our mutual client that the XP in the upcoming version of Windows stood for 'XML Protocol.'

More innocent times.

Scala had XML literals as part of the language!

Apparently Philip Wadler was the person who told them needed it, because the future was XML.

( Walder is big Haskell/PL person)

That's surprising! Wasn't it Philip Wadler who said "The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well."

http://harmful.cat-v.org/software/xml/

Was it far from JSX?

It was almost literally JSX (except with Scala syntax instead of Javascript, of course).

An XML literal in Scala would have been:

  // XML literals (to be dropped)
  val mails1 = for (from, to, heading, body) <- todoList yield
    <message>
      <from>{from}</from><to>{to}</to>
      <heading>{heading}</heading><body>{body}</body>
    </message>
  println(mails1)

This was replaced with "XML string interpolation", which

  // XML string interpolation
  val mails2 = for (from, to, heading, body) <- todoList yield xml"""
    <message>
      <from>${from}</from><to>${to}</to>
      <heading>${heading}</heading><body>${body}</body>
    </message>"""
  println(mails2)

VB.NET still has them. I remember doing a project with an XML database (ugh) back in college when the version with the literals was released. I was ecstatic.

ActionScript 3 as well as the E4X support in Mozilla's Browser+JS/XUL engine for a while (removed now afaik).

Around that time it was pretty nice passing around XML, as I was forced to work with VB.Net which also had an XML literal syntax on the backend and Flash/AS3 on the UI.

I had built a POC with E4X that was VERY similar to React/Redux over a decade before React, but the other browser vendors didn't have it... At the time IE and Chrome were shifting towards JSON.

The irony, to me, is how it is viewed as a bit of a mistake that they had XML in Scala. Hard to square that with how instrumental JSX was in getting some of the modern JavaScript frameworks as far as it has.

If the web spec had a JSON analog for HTML, I think you'd see a lot less love for JSX.

Maybe? Though, I suspect JSX just got lucky with when it got popular. There were plenty of mixed HTML/Script things in the past. Most of them met a lot of resistance.

I had a power strip which had "works with windows 95" on the packaging box.

This is just an example of how marketing knows nothing about the products they are marketing, or are just flat out snake oil sales. Like packing for bacon exclaiming "gluten free"

I mean... but it is? They're not wrong. Either the marketing works or it doesn't, but it's not false. If it works, then it's good marketing. If it doesn't, then the marketers don't know their market.

Ah yes, "this cereal is asbestos-free!" kind of marketing. It's on the same page with non-GMO salt.

Exactly. It doesn't really matter that the claim is technically true, it just has no bearing whatsoever on the product itself.

>This is just an example of how marketing knows nothing about the products they are marketing

Or it is a question that people who are not familiar with technology will ask frequently and makes no sense to people who are.

I use bing, and tell people to 'bing it' sometimes (instead of 'google it').

I had a family member ask "will bing work with my yahoo?"

So... I know those words individually, but... man... together, in that order... I don't know how to respond. I think I said something like "don't worry about it - it's not that big a deal" and left it at that.

Did it work with 98?

I wasn't working at the same place in 1998, so I can't verify.

The hype around Windows 95 at the time was... incredible. Midnight store openings, hours-long line waits... insanity.

> The hype around Windows 95 at the time was... incredible.

I left one job for another in 1994 simply because the new company had access to the windows Chicago beta program (and it was a 20% salary bump). But the main reason for me choosing g that org was the beta, because I had other offers with similar salary bumps at the same time.

Wow, and I thought my headphones from 1998 that said "MP3 Ready" on the package were stupid.

> I started my career during peak XML crazy and while I liked parts of it at the time, the number of things it was used for was quite insane. I had to maintain a system once where a major part of it was XSLT, when could have just been a simple imperative algo with some config settings.

Same here. XML was going to save the world! Remember XML data islands with data embedded in page source and displayed via XSLT?

The craziest thing I had to build was a tool to manage the dozens to hundreds of XML configuration files that powered our product. The tool allowed editing and deploying the files, complete with validation and even input suggestion based on associated XSD for each XML file.

I remember the XML is everywhere phase. The community that hasn't retired or passed on has largely come off of that. You can return JSON natively from XSLT 3.0 now. I've been on both sides of the love/hate fence with XML, but these days when I have the need to work with it I leave the projects really satisfied.

The best part of the XML craze was the deprecation of proprietary binary file formats. I had to work with some software that was truly awful but since it saved it's data as XML,I could skip the software entirely and work directly with the data.

Nowadays you have the same type of tools, only for YAML. Not sure if that's so much better.

Which tools are you thinking of?

The Github actions editor for example.

YAML can die in a fire

I do just like this with json. Creating api blueprints.

What are some examples of the "enormous tool stack" required for XML? I ask, because I came into software development after everyone adopted JSON. When I do need to parse XML, there was a library I could use, although I will admit that needing xpath was a bit annoying.

This was before my time, but I believe the WS-* series of specifications is an example.

> Like with the original J2EE spec, which sought to complicate the basic mechanics of connecting databases via HTML to the internet, this new avalanche of specifications under the WS-* umbrella sought to complicate the basic mechanics of making applications talk to each other over the internet. With such riveting names as WS-SecurityPolicy, WS-Trust, WS-Federation, WS-SecureConversation, and on and on ad nauseam, this monstrosity of complexity mushroomed into a cloud of impenetrable specifications in no time. All seemingly written by and for the same holders of those advanced degrees in enterprisey gibberish.

https://world.hey.com/dhh/they-re-rebuilding-the-death-star-...

The last time I worked with XML, using an external library wasn't really a great option. I ended up writing my own parser in C++. It took about a week to get all the features required for my purpose.

Honestly, if you just need a one-off transformer, VB.Net is probably one of the better options. The .Net XML library is pretty good in the box, and VB.Net has XML literal support on the top... if you just need to read, then C# is a better language imo.

VB.NET is masochism, and XML literals are a dumb, confusing, and unnecessary feature. Creating XML elements with regular code is quite easy, and at scale, you probably want templates.

If your XML is written the way people write JSON, then the stack isn't enormous. But XML is usually wrapped in layers of additional complexity. SOAP envelopes and namespaces they require, XSLT that someone invariably used to write an XML transformer, etc.

Also broken parsers. So many broken parsers. Honestly this is what keeps JSON going: the parser was simple because the language was simple, and as a result any JSON you got basically worked the same way.

Not so with XML: all the parsers were insanely complex with the namespacing and whatnot feature support and possible external URLs and everything else...and as a result however no XML library was ever adequate to interface with anything. On multiple occasions generally the best way to build XML for something was to take a working copy, and then glue text together so you would exactly replicate whatever that specific application wanted, rather then trying to use anyone's library for it.

> When I do need to parse XML, there was a library I could use, although I will admit that needing xpath was a bit annoying.

It sounds a bit like someone paved a garden path for you by that point. One of the reasons for the "enormous tool stack" wasn't just depth of tools needed ("tool X feeds tool Y which needs tool Z to process namespace A, but tool B to process namespace C, …"), but also the breadth. I recall there were at least six types of parsers to choose from with all sorts of trade-offs in memory utilization, speed, programming API: a complicated spectrum from forward-only parsers that read a node at a time very quickly but had the memory of a goldfish through to HTML DOM-like parsers that would slowly read an entire XML document all at once and take up a huge amount of memory for their XML DOM but you could query through the DOM beautifully and succinctly.

A lot of XML history was standards proliferation in the xkcd 927 way: https://xkcd.com/927/

XPath tried to unify a lot of mini-DSLs defined for different DOM-style XML parsers.

XSLT tried to unify a bunch of XML transformation/ETL DSLs.

The things XPath and XSLT were designed to replace lingered for a while after those standards were accepted.

Eventually quite a few garden paths were paved from best practices and accepted "best recommended" standards and greenfield projects start to look easy and a simple number of well-coordinated tools. But do enough legacy Enterprise work and you can find all sorts of wild, brownfield gardens full of multiple competing XML parsers using all sorts of slightly different navigation and transformation tools.

> I had to maintain a system once where a major part of it was XSLT

Every time the topic comes up I feel the need to say that I loved XSLT. It was so nice. XML frankly was kind of simple, too. It had elements and attributes and that was it. And it had xpath, which offered, among other things, a parent axis, so you could walk the node tree upwards.

In JSON you can't get to the parent from the child. And walking down a tree is unintuitive, because nodes can be of different types, and if you want to maintain the order, or use successive instances of the same things (that would have the same name) you need to use arrays, and arrays of arrays of arrays look bad. Schemas are an afterthought.

JavaScript is cool -- it has mostly eaten the world anyway. But JSON is not so good IMHO.

Here here. I would describe it something like: XML is great as a document format, but shitty as an RPC format. JSON is vice-versa. Web developers spend a lot of time with JSON as an RPC format, so they tend to put it on a pedestal. But try keeping your recipe collection structured in JSON text files and the pain will start immediately. YAML is even worse.

XSLT was (and still is) great for transforming documents. Want that recipe collection as HTML? Easy.

Yep:

- If you are describing hierarchal data, JSON is great

- If you are describing text with markup, especially extensible markup, for machine generation and consumption, XML is great.

- If you are describing a graph, neither have broadly accepted standards so you are kinda on your own.

Depending on your requirements, a recipe collection might be better in XML or in a flavor of markdown. A comprehensive data schema and software support for recipes could be challenging/limiting, compared to marked-up text.

> If you are describing a graph, neither have broadly accepted standards so you are kinda on your own

Relational databases can describe most graphs, but they rarely ever have a great text format.

And CSV for tabular data!

If only it was more standardized :-(

Markdown (like HTML) offers formatting structure, not semantic structure. Maybe you want to query for recipes that can be made in under an hour, or that contain orange as an ingredient (as opposed to merely a serving suggestion in an orange bowl). A proper XML (or even JSON or YAML) structure would enable this, Markdown does not.

You can pretty easily translate XML to Markdown using XSLT, though.

I don't think hierarchal structure is the differentiator; recipes and web pages are hierarchical and they'd still be hell in JSON. XML handles hierarchy just fine. I think the differentiator is whether your content is a document, that is, composed significantly of multiline text. Multiline text in a JSON file tends to be human-hostile, but we're all comfortable editing eg html.

JavaScript is as good as JSON. It has eaten The world jest because it was in every browser. Similarly Chrome, advertised on the biggest search engine.

I first touched XSLT in 2010. I appreciated what it could do, but it was painful to work with due to poor documentation and tooling. This has only gotten worse by comparison with alternatives.

You can still do XSLT in the browser. You can serve arbitrary XML and transform it. As an example, Atom feeds on my website (such as <https://chrismorgan.info/blog/tags/meta/feed.xml>) render just fine in all mainstream browsers, thanks to this processing instruction at the start of the file:

  <?xml-stylesheet type="text/xsl" href="/atom.xsl"?>

But working with it is not particularly fun, because XML support in browsers has been only minimally maintained for the last twenty or so years. Error handling is atrocious (e.g. largely not giving you any stack trace or equivalent, or emitting errors only to stdout), documentation is lousy, some features you’d have expected from what the specs say are simply unsupported (and not consistently across engines), and there are behavioural bugs all over the place, e.g. in Firefox loading any of my feeds that also fetch resources from other origins will occasionally just hang, and you’ll have to reload the page to get it to render; and if you reload the page, you’ll have to close and reopen the dev tools for them to continue working.

I think out of the box, browsers can only do xslt 1; but Saxon offers a JS version of their engine that does xslt 3.0 and is free (as in beer): https://www.saxonica.com/saxon-js/index.xml

It’s actually worse than XSLT 1.0 due to inconsistencies and incompletenesses. For example, Firefox doesn’t respect <xsl:output method="html">, but uses an XML parser on the transformed result regardless; and doesn’t support disable-output-escaping. I wanted these for my Atom stylesheet (for <content type="html"> and the likes; instead I had to emit serialised HTML and decode it in JavaScript, though with difficulty I could have done feature-detection to skip that step if disable-output-escaping worked).

Even perfunctory probing shows fairly serious problems in Firefox (where Chromium is consistently much better, in this specific area). I could file quite a few bugs in short order (e.g. these mentioned, bad document.contentType values, <template> not working properly), but I don’t think there’s any interest in fixing things.

(I wrote this comment as much for my own future reference as anything else. XML/HTML polyglot stuff makes things decidedly messy at times.)

> In JSON you can't get to the parent from the child. And walking down a tree is unintuitive, because nodes can be of different types

JSON only competes with XML. XSLT, XPath, and XSD are just as much an afterthought in that they are completely separate from XML and are entirely optional. The engines written around those is where the powers to walk the tree and validate come from, not XML itself. There's a wide range of tools to get the same benefits for JSON sources, and they usually handle XML and other data sources too, because it shouldn't matter. The reason the X* tools have fallen out of favor is because they're unnecessarily tied to a single type of source data.

XML might not have been so bad, if there weren't dopes pushing SOAP.