Never heard such a good argument for why we should all be replaced by AI.
XML is the future
261–270 of 408 posts
Re: XML is the future
#262XML has been around for long enough that a lot of people have developed a tacit understanding of it, it's not reasonable in all cases (I once went to war with an 8000 line build.xml file - fuck everything about that), but for simple cases it's an easy to parse hierarchical format that most people who need to can get a handle on. But there's one vestigial artefact that irks me. Why can't I just do this? Validation and…
why not go further, why can't we just write > although now that ="foo" business seems too noisy. how about > also, those angle brackets are too pointy, let's swap them to something more pleasant (tree (leaf :colour green) (leaf :colour yellow))
i dont have eyes so id prefer
enum Color { green, yellow };
struct Leaf { Color color; };
std::vector tree = {
{ .color = green },
{ .color = yellow },
};
Re: XML is the future
#263Genuinely curious, not being sarcastic or cute here. With hype everywhere, and job ads filled with buzzwords and acronyms, how does one choose what to learn? Something that is sane, that is joyful to work with, that will be around for at least a few years, but also puts food on the table?
I suppose SQL is going to be around for a while? Any other recommendations?
Re: XML is the future
#264It's interesting to consider the hype around XML and MongoDB. But it's also crucial to remember that each tool has its pros and cons and we need to choose wisely based on our project's needs. Hype isn't always a reliable indicator of utility ...
Re: XML is the future
#265XML has been around for long enough that a lot of people have developed a tacit understanding of it, it's not reasonable in all cases (I once went to war with an 8000 line build.xml file - fuck everything about that), but for simple cases it's an easy to parse hierarchical format that most people who need to can get a handle on. But there's one vestigial artefact that irks me. Why can't I just do this? Validation and…
Simplification from SGML was a core design objective for XML, and this kind of fairly harmless syntax options was mostly exterminated as a cognitive and implementation cost.
Re: XML is the future
#266I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…
I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead…
Maintaining old stuff is way more sensible than rewriting everything every few years. Companies tend to measure costs of maintenance vs rewrite.
Edit: there's always a tradeoff but I wrote "every few years". Cobol is an odd example. Many banks have been going back to Cobol because they found it less expensive than the alternatives and are there is an influx of new graduates learning the language right now.
Re: XML is the future
#267Earlier quoted context omitted.
I still can't believe that we (as a profession) kinda traded away schemas, namespaces, comments, sanity and well defined dates basically because some kids were too cool to write out closing tags. My early 20s teammate now closes blocks with } //for in his JS. That's even worse than XML!
JSON has schemas. Namespaces are simple, just add something like "namespace": "mynamespace" if you really need it. Comments are not really needed for machine readable formats and many JSON parsers allow comments if you need it for configs, so that's hardly an issue. Well defined dates are strings in ISO8601 format. It's not standardized with JSON, but not an issue I encounter on practice.
JSON itself doesn't have support for scheme of comments as far as I'm aware. Both are supported by individual rolls building on top of JSON rather than those features being part of the JSON spec.
Whether that stiffener matters to someone is up them, but that difference is what many comments on this thread are pointing out with regards to us having spent a decade rebuild many features of XML back into JSON.
Re: XML is the future
#268Fantastic article. I was on the isomorphic JavaScript hype train for a couple of years with Meteor.js and that really burned me. Now I can't stand JavaScript and I like Elixir and Python.
Re: XML is the future
#269Earlier quoted context omitted.
In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.
> In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, How does Kubernetes, microservices and front end frameworks fix that? They don't. In fact, as someone who works at the more modern end of these things, I'd suspect that "no meaningful monitoring" probably correlates quite well with cloud era microservices thingies. But we can't blame the tools, that space is just younger and by nat…
As a "not a cloud guy" who only recently got heavily exposed to it.. I found the state of the art / CloudOps attitudes towards monitoring astonishingly Stone Age.
Yeah observability is great, but no one I've seen in cloud manages to launch with it. So in place of SRE org with full observability stack, they launch with effectively nothing.
Strong attitudes of "we don't measure hardware metrics like cpu/memory/disk, we measure customer facing stuff like throughput/error rates etc". Sounds good, but what do you think happens to those if you run out of disk bro? Pretty sure the running out of disk happens first. Imagine if you could like.. catch it?
Re: XML is the future
#270I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…
Have you ever considered a different portion of the tech sector? I work in embedded systems and this couldn’t be further from the truth. Things rarely change (because it took someone smart banging their head against a wall for a week to make it work) and if they do, they’re usually addressing real needs in the systems programming community. I see each change less as a fad and more as an additional tool in the tool belt.
Take for example Rust, which is gaining traction in parts of systems programming. It addresses the direct need to stop overflowing buffers, create more strong typing, write less code to accomplish the same thing, and others. Accordingly, a lot of systems programmers are optimistic and excited about it. But everyone in the field knows C, and acknowledges C isn’t going anywhere. There are tasks for which C is better suited right now, and will be for a very long time. There’s no push to rewrite all programs in Rust. Sure, some are pushing for it, but it’s not a “this year is Rust, next year is ” dynamic. It’s a “this is where we want to go, but it’s going to take us many years to get there” type shift.