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

351–360 of 408 posts

Re: XML is the future

#351

Post by BeFlatXIII »

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.

Perhaps that would be the time to transition into playing rainmaker.

Re: XML is the future

#352

Post by noisy_boy »

mcv wrote: post #140
Blaiz0r wrote: post #130

Earlier quoted context omitted.

Microservices are more an organisational thing than a recommended pattern, when a project grows and wants to hire more staff to increase its bandwidth then microservices are a great way to support that, the additional benefit is that they work great in a CI/CD setup so you can release seamlessly. GraphQL from what I can tell supports web developers rewriting their APIs when they need to instead of waiting on back-end…

Most of my projects have just a single team in charge of a single code base, so there seems to be no need for microservices at all, and yet some people keep bringing up that we should really look into microservices. My impression is that GraphQL is great if you're building an api that's going to be used by lots of different teams with different needs and the api developer doesn't know what they are. Again, with a sin…

> My impression is that GraphQL is great if you're building an api that's going to be used by lots of different teams with different needs and the api developer doesn't know what they are.

This has been my experience as well. It provides flexibility to the consumers of the API to structure things how they want and fetch only what they need. E.g. if you add a new field, there isn't any impact on existing users to make any changes since they are not specifying it in their current request anyway. To certain extent, that also helps with things being somewhat future proof because even if you knew what the users want today, you can't predict what they will want tomorrow.

Having done a bunch of REST and GraphQL APIs, the only thing I would say for GraphQL is to avoid re-inventing the wheel and use a stable third-party library to do as much heavy lifting as possible so that you can focus on the logic side of things.

Re: XML is the future

#353

Post by prabhu-yu »

I think, Python Dictionary format can represent structured data well. i.e., I need to re-present some data, I use Python dictionary format, then YAML, then JSON. Possibly never in XML as I feel the tags simply redundant, verbose, prone to missing when we are constructing with hands.

Re: XML is the future

#354

Post by mcv »

throwaway2037 wrote: post #205
mcv wrote: post #117

Earlier quoted context omitted.

Yeah, you can't jump on every hype. I started in web dev almost 20 years ago (did some Visual C++ before that). First job was everything XML. We had our open source CMS that stored all documents as XML and used XSLT to transform it into the HTML we needed. Was pretty cool, but there's always something that didn't fit that paradigm. Some coworkers went a bit overboard and used XSLT to generate the XSLT to create the H…

Did you ever try the Microsoft Visual Studio XSLT debugger from DotNet? The first time I tried it from C# was mind-blowing. Suddenly, it became possible to manage complex XSLT scripts!

Never used it. We used Eclipse.

Re: XML is the future

#355

Post by Joker_vD »

madsbuch wrote: post #168
wizofaus wrote: post #133

Earlier quoted context omitted.

> 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. Can't say I've ever thought of it that way - attributes just seemed like a simpler syntax for the common case of basic properties that were sensibly represented as strings (i.e. single, literal values). I don't think it would have made much fundamental differ…

> Can't say I've ever thought of it that way as can be seen to the comments to to my comment, there are quite a number of ideas on the ontology of the XML format. when a single screen worth of text on my phone can hold at least 3 strong convictions on how to use a format, then it is doomed to fail.

Just as an anecdote: about two years ago I had a discussion about marshalling data structures into XML and indeed, two people managed to come up with three different schemes [0]. Of course that spells doom for something that's supposed to be used as a data-exchange format.

[0] https://news.ycombinator.com/item?id=24614404#24626486

Re: XML is the future

#356

Post by vbezhenar »

flagrant_taco wrote: post #267
vbezhenar wrote: post #183

Earlier quoted context omitted.

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.

XML does not have support for schemas either. XML Schemas is a separate spec (and actually not the only one, there were few competing ones).

I'd use JSON schema over XML schema any day. And I read and wrote many XML schemas and still do sometimes. JSON schema actually built by sane people. If that required a decade, so be it.

Re: XML is the future

#357

Post by Hermitian909 »

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 have a partial solution to this I'm happy pretty happy with.

First, is that I dove farther into CS fundamentals. This has made new fads a lot easier to deal with because usually they're recycling old CS ideas. React hooks is a good example. I wrote class components for many years, adopting to hooks took me all of a day because Algebraic effects were something I understood well.

Second - I am firm about which tech I do and do not want to learn the specifics of. I understand the high level of kubernetes but will not be learning specifics.

Re: XML is the future

#358

Post by pdimitar »

mathgeek wrote: post #260
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…

Today’s beloved tech with well maintained docs is tomorrow’s institutional knowledge tech that companies rely on.

Not my observation sadly. We've got some excellent 10+ years old tech -- Golang, Rust, Elixir -- yet a lot of companies out there holds on to C#, PHP and Java with an death grip.

And I've worked with all of these. The newer stuff is better in every way except penetration (which is held back by bias and misguided evaluations of the word "safe").

Re: XML is the future

#359

Post by somat »

I recently had a project where I was munging some vendor xml so I get to have an opinion(python + lxml)

xml is not that bad. until you add namespaces. then it gets ugly real quick.

But I think the fundamental problem of xml is that it is trying to be two things. a markup language and a structured data object format. It started life as a markup language(text with interposed tags) however the lure of a well defined, human readable, flexable format proved too much and people started using it for object storage(mostly tags, never mixed tags and text)

Re: XML is the future

#360

Post by pdimitar »

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/…

It looks like you misunderstood the article. "Let it crash" in the BEAM VM world pertains to a single green thread / fiber (confusingly called "process" in Erlang).

It pertains to e.g. single database connection, single HTTP request etc. If something crashes there your APM reports it and Erlang's unique runtime continues unfazed. It's a property of the BEAM VM that no other runtime possesses.

"Let it crash" is in fact "break your app's runtime logic to many small pieces each of which is independent and an error in any single one does not impact the others".

Scaling an Erlang node is very rarely the solution unless you literally run out of system resources.

Post reply on HN