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

71–80 of 408 posts

Re: XML is the future

#71

Post by hardwaresofton »

andrewflnr wrote: post #58
hardwaresofton wrote: post #17

Earlier quoted context omitted.

> Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. Here's how I stay sane -- I focus on the changes. For the technologies that you noted, here are some good questions that…

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.

> 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.

Definitely -- I'd say that these questions force the understanding of the fundamentals, because that's what you get down to ("fundamental"/irreconcilable differences).

The problem is that fundamentals can be similar, and sometimes the difference is elsewhere (UX/DX/perf for example).

> But also, those are some pretty odd comparisons.

So they are odd comparisons, in some sense -- but the point was to reflect the kind of questions someone who didn't know the answer would ask. Ansible and Terraform (and Salt/Puppet/Chef) are often presented in similar context and they're often confusing precisely because they are so close but different.

The other example (CGI vs Serverless) is situation that's somewhat more targeted towards the age discussion -- did we churn over the years for churnings' sake?

> 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.

What you've said is the usual rebuttal (and it's mostly right!), but did you know that Ansible did/does provisioning?[0] The lines aren't drawn as neatly as they seem to be.

You can build a Terraform-like experience out of Ansible, if you wanted to, and it's important to know that and why you choose a tool like Terraform instead of traveling deep into Ansible land.

All that said, if you prefer, replace "Ansible" with "Pulumi" (Full Disclosure: I'm firmly on the Pulumi side in the Terraform vs Pulumi debate).

[0]: https://docs.ansible.com/ansible/latest/collections/index_mo...

Re: XML is the future

#72

Post by emodendroket »

Seems like there is a blending here of features and technologies. Your users will probably not know or care whether you choose YAML, XML, or JSON, but they'll notice gamification features.

Re: XML is the future

#73

Post by sublinear »

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…

> it's absolutely exhausting

I'm not young, yet I don't find any of this all that bad.

Maybe I'm an outlier, but I see refactoring and learning new tools as just keeping the blade sharp. Migrating to new frameworks, tools, etc. is just superficially iterative. I've yet to see some kind of massive paradigm shift blow me away and stress me out.

Re: XML is the future

#74

Post by nologic01 »

Some thoughts of why software is so hype prone and will likely remain so, if not accelerate

* Its intrinsically easy to come up with new approaches. Thinking and writing software is a mental process, it is not limited by physical constraints and messy manufacturing.

* The scope of use contexts in society exploded. You only needed the formula-translation language when you had five whitecoats in a research lab punching instructions on a single computer. Now you have multi-billions of devices.

* The process is self-feeding. With the internet came the development of online interaction tools, techies use them more than any other segment and this creates a large coherent mass of lemmings and network effects.

* The role of bigtech (oligopolies solving their own problems to maintain / expand their dominance and abnormal profitability) which creates a collective osmosis to imitate whatever they are doing.

* There is also intrinsic redundancy and near equivalence of solutions. You only have one way to roll a concrete something on a surface: it must be round. But one can have an infinity of ways to split a workload between a client and a server machine (let alone more servers).

Most of those factors will continue for the foreseeable future so there will be no respite. E.g., Now we are firmly into AI hysteria and this again already shakes things up as it deprecates/de-emphasizes patterns that are not part of the bandwagon and puts emphasis on obscure niches that are deemed critical.

Re: XML is the future

#76

Post by Pamar »

noduerme wrote: post #19
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've watched this happen to so many coders in the land where people write code for companies that sell code . Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever , although in a new project you'll have more flexibility to pick the righ…

This is all fine but... the rest of the world is not freezed. Let's say you are happily mantaining a stable, boring ERP app for your... cigarette lighters plant.

Out of the blue, one of your main suppliers declares they will accept orders only through a REST interface starting next quarter. And that you can/must use it to track your orders, instead of sending an email to one of their employees.

One week later, you are required to provide invoices in PDF instead of just printing on paper.

And your accounting system will switch to Oracle Finance in October...

Your ERP was developed on Progress ABL, and nobody really cared to port the old code to a web-based architecture because it was just for "internal use" and Putty was fine.

Re: XML is the future

#77

Post by noduerme »

deaddodo wrote: post #43
noduerme wrote: post #19

Earlier quoted context omitted.

I've watched this happen to so many coders in the land where people write code for companies that sell code . Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever , although in a new project you'll have more flexibility to pick the righ…

Having worked at both, the latter type of company also has it's downsides. Primarily: a) the inverse is also true...you'll be working on some old technology that only your industry utilizes and isn't well optimized for modern use cases or is extremely niche; despite there being plentiful use cases to make the switch, it'll never be "in the budget", b) your payrate is generally going to be quite a bit lower than indus…

Maintaining old systems and not getting the chance to exercise your hottest take on how they should be rebuilt is often tedious as hell. But I find a lot of comfort in it. I usually find that the future road maps that stick in my head for a year or more are the ones worth a 10-year overhaul, and I like to be able to tell clients that when enough of their stack is reaching end of life, we should do this major rewrite but I already am fairly certain they won't have to do it again for another 10 years. e.g. I have yet to deploy any production code for a client running on Nodejs, but I've written enough dependable systems in it on my own free time in the last 5 years that I think I might now finally advocate for it under certain circumstances, knowing the strengths and weaknesses.

It does help - as you point out - to be in the position where the non-tech company will almost always take your advice if you tell them they need to change platforms. But the most effective way of getting yourself in that position is to prove that you exercise that option only when it truly is in their best interests.

Re: XML is the future

#78

Post by wvenable »

preommr wrote: post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

> With XML, it failed because something like JSON was much simpler.

I remember when XML was pretty new and I used this new-fangled technology called XML-RPC. XML-RPC was amazing and I was using it to connect desktop applications to web applications. If you go look it up, you'll notice that bears a striking resemblance to JSON.

But what technology actually took off for RPC in XML? SOAP. And SOAP is a nightmare of complexity and hardly works right the first time between heterogeneous systems.

It's funny how much people want to add complexity to the JSON ecosystems with the same over-engineering that killed XML in the same space. Luckily the design of JSON is such that it resists that kind of complexity and also because XML exists it takes a bit of that load.

Re: XML is the future

#79

Post by magicalhippo »

quickthrower2 wrote: post #60
preommr wrote: post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

XML can be simpler. In C# you could generate an XSD from a good XML example, then fix it up and generated typed, nested C# code. You now have a builder and validator for the stuff you send across the wire. You can sort of do the same with JSON though to be fair, in theory, and there are probably tools, but it wouldn't be as tight and then the "XSD" part I am not sure if there is a single spec to go with. Overall thou…

We use XSDs to generate JSON Schemas. The schema converter also generates code to convert JSON files to XML, so we can use our existing XML infra while we migrate.

As you say both can be used to validate input and to generate typed code.

However I find the XSD design tools better, so I expect we'll be doing the XSD first approach even after all our integrations are JSON native unless something radical changes there.

Re: XML is the future

#80

Post by bandrami »

deaddodo wrote: post #43
noduerme wrote: post #19

Earlier quoted context omitted.

I've watched this happen to so many coders in the land where people write code for companies that sell code . Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever , although in a new project you'll have more flexibility to pick the righ…

Having worked at both, the latter type of company also has it's downsides. Primarily: a) the inverse is also true...you'll be working on some old technology that only your industry utilizes and isn't well optimized for modern use cases or is extremely niche; despite there being plentiful use cases to make the switch, it'll never be "in the budget", b) your payrate is generally going to be quite a bit lower than indus…

I agree that it's dull but the fact that I still know ColdFusion 20 years later gets me a lot of work. No, it's not Silicon Valley money but it is Fairfax County money, which ain't bad.
Post reply on HN