It’s perplexity.ai. I like it because it doesn’t require an account and because it can search the internet. It’s like microsoft’s bing but slightly less cringe.
It’s a proxy for a number of LLMs of choice, prompts anonymised before they’re sent. A bit like how their search engine is anonymised Bing, or how their maps are anonymised Apple Maps. I’m happy with the service!
The answer is not real. The tool, on the other hand, is called Perplexity. It “understands” your question, searches the web, and gives you a summary, citing all the relevant sources.
It’s not a waste of time… it’s a waste of space. But it does allow you to “enforce” some schema. Which, very few people use that way and so, as a data store using JSON works better.
Or… we could go back to old school records where you store structs with certain defined lengths in a file.
You know what? XML isn’t looking so bad now.
If you want to break the AI ask instead what regex you should use to parse HTML.
We slowly need to interface with an app at work that uses fixed-width too. It does not sound that bad if you hear it but it sucks to figure out where you are missing whitespace when most fields are not used and therefore all whitespace. Oh, and of course there are a lot of fields, also are aligned/formatted differently based on their type and has thin/no/wrong documentation. And I have yet to find a simple but decent “debugger”.
Don’t drink the JSON coolaid. XML is fine. Better, in many cases, because XML files actually support comments.
In the modern programming world, XML is just JSON before JSON was cool. There was a whole hype about XML for a few years, which is why old programming tools are full of XML.
It’s funny but sad to see the JSON ecosystem scramble to invent all of the features that XML already had. Even ActivityPub runs on “external entities but stored as general purpose strings”, and don’t get me started on the incompatible, incomplete standards for describing a JSON schema.
It’s not just XML either, now there’s cap’n proto and protobuf and bson which are all just ASN.1 but “cool”.
<span style="color:#323232;">{ "key": "six",
</span><span style="color:#323232;"> "value": 6,
</span><span style="color:#323232;"> "comment": "6 is a bad number. Use five." }
</span>
Please don’t. If you need something like json but with comments, then use YAML or TOML. Those formats are designed to be human-readable by default, json is better suited for interchanging information between different pieces of software. And if you really need comments inside JSON, then find a parser that supports // or /* */ syntax.
IMHO: XML is a file format, JSON is a data transfer format. Reinventing things like RSS or SVG to use JSON wouldn’t be helpful, but using XML to communicate between your app’s frontend and backend wouldn’t be either.
Most web frameworks contain code to exchange JSON over XMLHttpRequest for a reason. XML is and always has been a data transfer format as well as a file format. JSON is, too. The amount of config.jsons I’ve had to mess with…
but using XML to communicate between your app’s frontend and backend wouldn’t be either
I don’t see why not? The entrypoint of web frontends is sent as HTML already. I guess that’s based on SGML, XML’s weird and broken cousin. Outputting XML is just a matter of configuring whatever model serialiser from JSON to XML.
There are a few good arguments against XML, but those also work against JSON.
Of course you can use XML that way, but it is unnecessarily verbose and complex because you have to make decisions, like, whether to store things as attributes or as nested elements.
I stand by my statement that if you’re saving things to a file you should probably use XML, if you’re transferring data over a network you should probably use JSON.
Of course you can use XML that way, but it is unnecessarily verbose and complex because you have to make decisions, like, whether to store things as attributes or as nested elements.
That’s a rather annoying shortcoming of XML, I agree. Then again, the choice is pretty inconsequential and the XSD for your data exchange format will lift any ambiguity anyway.
The choice between XML and JSON are a matter of preference, nothing more. XML is much more powerful than JSON and it’s usually a better choice in my opinion, but if you’re writing your applications well, you may as well be sending your data as pixels in a PNG because your serialiser/deserialiser should be dealing with the file format anyway.
XSDs are far from perfect, but waaay more powerful than json schema.
XSLT has its problems, but completely transforming a document to a completely different structure with just a bit of text is awesome. I had to rewrite a relatively simple XSLT in Java and it was something like 10 times more lines.
XSD and XSLT files alone can replace half the JSON applications I’ve seen. I can see why it’s easier to take the barebones JSON notation and reinvent the wheel, but those tiny programs are the “Excel+VBA” of web applications.
I was reverse engineering fucking around with the LBX file format for our Brother label printer’s software at work, because I wanted to generate labels programmatically, and they’re zipped XML too. Terrible format, LBX, really annoying to work with. The parser in Brother P-Touch Editor is really picky too. A string is 1 character longer or shorter than the length you defined in an attribute earlier in the XML? “I’ve never seen this file format in my life,” says P-Touch Editor.
EDIT: And with more complicated strings (like ones havingnumbers or symbols - just regular-ass ASCII symbols, mind you) there will be tens of <stringItem>, because apparently numbers and letters don’t even work the same. Even line breaks have their own <stringItem>. And if the number of these <stringItem> and their charLen don’t match what’s actually in pt:data, it won’t open the file.
I hate writing and reading xml compared to json, I don’t really care if one is slightly leaner than the other. If your concern is the size or speed you should probably be rethinking how you serialize the data anyway (orotobuff/DB)
I mean we have a generation that thinks XML is bloated & JSON is superior but they are about the same which is the point. The non-plaintext-readable formats are suprior along a lot of metrics but harder to debug & ultimately less common.
XML has its strengths as a markdown format. My own formatted text format ETML is based on XML, as I could recycle old HTML conventions (still has stylesheet as an option), and I can store multiple text blocks in an XML file. It’s not something my main choice of human readable format SDL excels at, which itself has its own issues (I’m writing my own extensions/refinements for it by the name XDL, with hexadecimal numbers, ISO dates, etc.).