9 ms·
This quote is funny: Douglas: The first time I saw JavaScript when it was first announced in 1995, I thought it was the stupidest thing I’d ever seen. And
by adamgordonbell 4y ago
This quote is funny:
Douglas: The first time I saw JavaScript when it was first announced in 1995, I thought it was the stupidest thing I’d ever seen. And partly why I thought that was because they were lying about what it was.
A bigger more interesting thing though is how his company failed, in part, because they used hand-rolled JSON for messaging.
Douglas: And some of our customers were confused and said, “Well, where’s the enormous tool stack that you need in order to manage all of that?”
“There isn’t one, because it’s not necessary”, and they just could not understand that. They assumed there wasn’t one because we hadn’t gotten around to writing it. They couldn’t accept that it wasn’t necessary.
Adam: It’s like you had an electric car and they were like, “Well, where do we put the gas in?”
Douglas: It was very much like that, very much like that. There were some people who said, “Oh, we just committed to XML, sorry, we can’t do anything that isn’t XML.”
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.
Anyhow, hope you like the episode!
- justin66 4y agoI really respect that you provide transcripts. It's terribly important for accessibility and for getting what people have said into the various search engines. I was sad to hear that Crockford is not aiming to be the author of "the next language" anymore, but I wonder how sincere that really is. His thoughts on actor-based languages are interesting.
- adamgordonbell 4y agoThanks! 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.
- hestefisk 4y agoJust 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!
- ryukafalz 4y agoI 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/ https://spritely.institute/about/)
- meepmorp 4y agoI 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.
- adamgordonbell 4y agoScala 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)
- tuukkah 4y agoWas it far from JSX?
- chimeracoder 4y agoIt 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)
- bryik 4y agoThat'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/ http://harmful.cat-v.org/software/xml/
- orthoxerox 4y agoVB.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.
- fatnoah 4y ago> 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.
- mgr86 4y agoI 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.
- wvenable 4y agoThe 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.
- ssdspoimdsjvv 4y agoNowadays you have the same type of tools, only for YAML. Not sure if that's so much better.
- pyuser583 4y agoWhich tools are you thinking of?
- ssdspoimdsjvv 4y ago
- Seanny123 4y agoWhat 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.
- bryik 4y agoThis 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-of-complexity-4fb5d08d https://world.hey.com/dhh/they-re-rebuilding-the-death-star-...
- sgtnoodle 4y agoThe 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.
- tracker1 4y agoHonestly, 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.
- Kwpolska 4y agoVB.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.
- bambax 4y ago> 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.
- krzyk 4y agoJavaScript 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.
- stickfigure 4y agoI 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.
- dwaite 4y agoYep: - 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.
- gweinberg 4y agoXML might not have been so bad, if there weren't dopes pushing SOAP.