Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XML is the future

bitecode.dev

Post reply on HN
Print view View original

291–300 of 408 posts

Re: XML is the future

#291

Post by sofixa »

xorcist wrote: post #248
andrewflnr wrote: post #58

Earlier quoted context omitted.

I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. But also, those are some pretty odd comparisons. For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines.

> Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines Ansible can provision virtual machines as well, and from my experience it is better suited for it too, since it doesn't save state outside the system. So there's lesser chance for it to get out of sync. It's mostly culture. People these days learn GKE or Kubernetes first, and their tutorials mention Terraform so that's…

> Ansible can provision virtual machines as well, and from my experience it is better suited for it too, since it doesn't save state outside the system. So there's lesser chance for it to get out of sync.

State serves a purposes, it's not just there for fun. Ansible will lose track of your VM if you rename it (and can barely handle you renaming it with itself), and won't delete it if you just delete it from the configuration file.

Re: XML is the future

#292

Post by edejong »

otabdeveloper4 wrote: post #280
Quarrelsome wrote: post #258

Earlier quoted context omitted.

> How does Kubernetes, microservices and front end frameworks fix that? Doesn't being in a container mean its much easier to rebuild it from zero and thus allowing security updates to be more regular?

Not really. A "container" is usually just an instance of a Linux distribution, and the work involved in updating it is roughly the same.

In the 27 minutes after you wrote your comment, our CI/CD rebuild two containers from a latest snapshot. No manual work involved.

Re: XML is the future

#293

Post by ed25519FUUU »

otabdeveloper4 wrote: post #277
gnulinux wrote: post #7

I'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…

Be thankful there are still people willing to pay you for bullshit jobs. Things will be tougher when management starts asking for real, measurable results.

Gotta make hay while the sun is shining.

Re: XML is the future

#294

Post by fnord77 »

DarkCrusader2 wrote: post #245
gnulinux wrote: post #7

I'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…

really surprised faang management doesn't see the value in addressing technical debt.

Re: XML is the future

#295

Post by steveBK123 »

edejong wrote: post #290
steveBK123 wrote: post #269

Earlier quoted context omitted.

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…

CPU/Memory: scale horizontally when needed. Monitor cost. Disk: essentially limitless. If disk of VM runs out, node will crash, new node will start. Service should keep running on other nodes meanwhile. If restarts happen too often, throughput/error rate will suffer or cost will rise. Modern mentality is "let it crash" [0]. Software has bugs. Design so it can crash and scale depending on need. [0] https://medium.com/…

This is an adequate philosophy for like.. a CRUD app, some freemium SaaS, social media, etc. Stuff with millions of users and billions of sessions, etc.

However there are industries applying these lessons in HPC / data analytics / things that touch money live .. operating on scales of users in the 10s to maybe 100s. So stuff where downtime is far more costly both in dollars and reputation.

I'm also intrigued by the constant cloud refrain of "stuff crashes all the time so just expect it to" coming from a background where I have apps that run without crash for 6 months at a time, or essentially until the next release.

I'm all for scaling, recovery, etc.. I just fail to understand why it is desirable for this to be an OR rather than an AND.

What if stuff was highly recoverable and scalable but also.. we just didn't run out of disk needlessly?

Re: XML is the future

#296

Post by andruby »

flir wrote: post #233
boffinAudio wrote: post #153

Earlier quoted context omitted.

Use what works. Ship code. Support your customers. Help them improve their lives. All other considerations are secondary. Including whether or not your peers approve of your code. Always remember: the User is king. Programmers are nothing without users, no matter what technology they apply to the situation. Sounds like you've shipped, and shipped often. GOOD!

But there are so many layers of abstraction between me and my user... (human layers, not software layers)

Do you think there are too many layers in between? Can you help reduce the number of layers?

Re: XML is the future

#297

Post by madsbuch »

Mikhail_Edoshin wrote: post #204
madsbuch wrote: post #106

Earlier quoted context omitted.

You could say the same about JSON. It is arguably closer to how and AST is represented in software as it does not posses the two dimensional notation like XML does. The unique thing about XML is that you can both have children and attributes. My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections. This is IMHO the w…

Children and attributes are different. Attributes are like fields to a record. Parent/child is a relation between records. There are clear criteria for choosing attribute vs text representation. Text is for humans; all the rest is for the computer. If we see something like this: 123 this means the text is precious and we cannot alter it, only attach some records (‘ssn’) to some character ranges. And in most cases the…

that's a long explanation on how to use various features of a notation. would it be easier to just use json?

You have many moving pieces with a complex notation, a complex domain, and potentially multiple architects..

Re: XML is the future

#298

Post by WJW »

goodpoint wrote: post #266
DarkCrusader2 wrote: post #245

Earlier quoted context omitted.

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.

Sensible for who? Companies may try to estimate costs of maintenance vs rewrite, but individuals need to make the final call and for them the benefits usually go the other way.

Maintaining some existing project is going to get you nothing if you do it right and will bring you problems if it breaks despite your best efforts. Rewriting an existing system in a new tech stack counts as exciting innovative work for promotion purposes, or at least prepares your CV for your next job hop. With salary bumps between levels being what they are in software, I'm not surprised people choose the more lucrative option.

Re: XML is the future

#299

Post by taeric »

It wouldn't shock me to find that a ton of the ideas in XML do become the future, all told. We railed against it being overly complicated, but then it seems we have slowly walked back down that path as the years go on.

Re: XML is the future

#300

Post by fifticon »

DarkCrusader2 wrote: post #245
gnulinux wrote: post #7

I'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…

news flash: You are working in exactly the same place.. it is just 5 years later :-) All that outdated technology you mention, was probably introduced as the newest-cant-live-without at some earlier time.
Post reply on HN