phlakaton

6 ms·

31.
by phlakaton 6mo ago
I've been here longer than you, buddy. I think you're the one that needs to leave.
32.
by phlakaton 6mo ago
But you cannot predict a priori what that deterministic output will be – and in a real-life situation you will not be operating in deterministic conditions.
33.
by phlakaton 6mo ago
> This bug is categorically distinct from hallucinations. Is it? > after using it for months you get a ‘feel’ for what kind of mistakes it makes, when to watch it more closely, when to give it more permissions or a longer leash. Do yo
34.
by phlakaton 6mo ago
I think it might be a bad thing. I'm no stranger to math or computer science, but even after staring at the front page for a minute I was ready to dismiss this as the ravings of a lunatic. It's like they had the idea of marketing
35.
by phlakaton 7mo ago
Hah! XML strikes again. :-) I understand that Spain was a participant in LexML as well... I gather they've since converted to something else?
36.
by phlakaton 7mo ago
1. The Register reports OpenAI is well ahead of Anthropic in B2B contracts. It's Anthropic playing catch-up, not OpenAI. 2. In any case, the announcement strongly suggests that customer acquisition had little to do with this. The state
37.
by phlakaton 7mo ago
I hope OpenAI realizes they cannot buy developer goodwill.
38.
by phlakaton 7mo ago
I went to a James Gosling talk where he excoriated the Emacs users in his audience for clinging to outdated technology and not using a state-of-the-art IDE. But the IDE he was hawking wasn't Eclipse. I think it was Sun Studio.
39.
by phlakaton 7mo ago
As a Mayflower descendant I would scarcely say that. But the fact that you offer cheap platitudes and tales from hundreds of years ago to justify why it's OK to consider why the current bombing and slaughter is good for our work-life b
40.
by phlakaton 7mo ago
There's no lemonade to be found here at this time. What there is to be found are a bunch of tone-deaf people who seem utterly ignorant and indifferent to the war's reality.
41.
by phlakaton 7mo ago
Please do not use the occasion of the death of thousands of Iranians in a war we launched against them as some sort of illustrative point about return to office and birth rates in the West.
42.
by phlakaton 7mo ago
1. I don't disagree that attributes have been abused – so have elements – but you yourself identified the right way to use them. Yes, you can inline attributes, but that also leads to a document that's harder to use in some cases.
43.
by phlakaton 7mo ago
I disagree on several points here: 1. I think attributes absolutely should exist. They're great for describing metadata related to the tag: e.g. element ID, language, datatype, source annotation, namespacing. They add little in complex
44.
by phlakaton 7mo ago
By "parses well" in that case I mean "can identify where the error is, and maybe even infer the missing closing tag if desirable;" i.e. error reporting and recovery. If you've ever debugged a JSON parse error where
45.
by phlakaton 7mo ago
Depends on the application, I suppose. For OP's application, pulling in XML is no trouble and gives you a much better solution for typed unions. To get better than XML, I think you're looking at something closer to a Haskell- or
46.
by phlakaton 7mo ago
Aesthetically, I consider such JSON structures degenerate. It's akin to building a ECMAScript app where every class and structure is only allowed to have one member. If you want tagged data, why not just pick a representation that does
47.
by phlakaton 7mo ago
For this application, where you might have a lot of authors and apps working with the rule data, I think schema-based validation at some level is going to be a must if you don't want to end in sorrow.
48.
by phlakaton 7mo ago
LOL, I chose a Google Sheet and CSV for my current project, and I'm very serious about it. It's a short-term solution, and it fits my needs perfectly.
49.
by phlakaton 7mo ago
I unfortunately disagree that your syntax is "stupid-simple." But it highlights an impedance mismatch between XML users and JSON users. JSON treats text as one of several equally-supported datatypes, and quotes all strings. Great
50.
by phlakaton 7mo ago
I don't dislike the decision at all, FWIW! For data interchange it's totally reasonable. But it does make JSON ill-suited for a bunch of applications that JSON has been forcefully and unfortunately applied to.
51.
by phlakaton 7mo ago
Maybe rather: how easy it was to generate rotten XML. I feel you there. The XML community, though, embraced the problem of different outputs between different producers, and assumed you'd want to enable interoperability in a Web-size
52.
by phlakaton 7mo ago
LISP, unfortunately, is only cheap within a pretty narrow bounds: when you've got a suitable environment already set up and running, and all your collaborators are happy to work with it.
53.
by phlakaton 7mo ago
I like this post, but I gotta tell you, it just makes me want to dust off and write a bunch of s-expr tools to make that ecosystem equally or more attractive for DSLs. If I do, the IRS will be the first to know about it! I'll staple an
54.
by phlakaton 7mo ago
> JSON just works. Until it doesn't: underspecified numeric types and string types; parses poorly if there's a missing bracket; no built-in comments. For many applications it's fine. I personally think it's a worse ba
55.
by phlakaton 7mo ago
That repetition of variable and name is not the most terse, though. At least with XML, the repetition in the end tag is handled for you by pretty much every XML-aware text editor.
56.
by phlakaton 7mo ago
I'm happy to use XSD for certain situations, but it has some frustrating inabilities and complexities. The impression I've got from the last 20 years is that a chunk of the XML community gave up on XSD and went to RELAX-NG instead
57.
by phlakaton 7mo ago
Some people just comment on the title. Maybe that's what happened here.
58.
by phlakaton 7mo ago
But there, as with any DSL, you are trading-off ease of expression with ease of processing (e.g. interiperability). Every embedded DSL, XML included, chooses some amount of ease of processing.
59.
by phlakaton 7mo ago
Interesting you should complain about that with a legacy technology that's almost 30 years old (or 50 years old if you count SGML). In particular, XML has gotten no more complex or slow than it was 20 years ago, when development largel
60.
by phlakaton 7mo ago
That's besides the point of this post. You're welcome to enforce such a profile on your documents, but the point of this post is the ease from throwing the whole ecosystem of out-of-the-box XML tools at it, tools which don't

More ›