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

301–310 of 408 posts

Re: XML is the future

#301

Post by fifticon »

anonzzzies wrote: post #146
Gigachad wrote: post #70

Earlier quoted context omitted.

There is. It's called "the market". A company that wastes too much time and money on non returning investments will not last.

Every non-startup wastes incredible amounts on fads and other inefficiencies while still lasting perfectly fine. It's just business as usual. I could probably save my current largest clients many millions/year on dev if the CTO (& his tech leads) wasn't such a fad guy; he basically pops on Twitter every morning and starts sending over 'new stuff the team should look at'. There are 1000s of applications in that compan…

I misread that as "poops on twitter every morning", but it didn't change the meaning of the paragraph..

Re: XML is the future

#302

Post by fifticon »

akudha wrote: post #263

Genuinely 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?

We ask 'does this bring joy?'

Re: XML is the future

#303

Post by jjice »

alphager wrote: post #145
devjab wrote: post #61

I worked a decade in public sector digitalisation in Denmark, where for some reason they still use a lot of SOAP and thus XML. I’m not so against XML in theory, but I hate it in practice. You’d have these completely over engineered solutions where you’d basically need to call a separate micro services for every “field” of anything. So if you wanted a name, a ssn, and, an address for a citizen you’d need to make sever…

I think "XML" is way too broad to meaningful discuss anything. XML the data format is pretty great in its basic form. Not space-efficient, but unless you're dealing with bulk data, the inefficiencies don't matter unless you're googlescale or can't spare a millisecond. The format itself doesn't absolve you from the design work of your model; your ssn example is typical of the "CEO said we have to use XML now" rush-job…

> XML Webservices are easy and consuming them from a WSDL is easy.

Maybe in theory, but I've never had a WSDL that was actually complete. In the end, it generated stubs of types and clients for me and I still had to do a lot of nonsense. The concept of a WSDL would be nice but in practice I've seen _so_ many people do them poorly and create a bad experience.

Re: XML is the future

#305

Post by afry1 »

sickcodebruh wrote: post #286

Doesn’t this strike anyone as overly cynical and just… incurious? Yes, hype and trends are obnoxious, there are individuals and organizations that reflexively seek sexy tech and apply it wrong, but isn’t this also part of how we find things that work and things that don’t? It’s easy to run through decades of tech trends and present them as the only things that dominated the industry, just like it’s easy to rattle off…

I don't know about incurious, maybe "extreme". A lot of the tools, techniques, etc. mentioned in the article aren't appropriate for ... well, most websites probably. But they do have their roles to play in large, complicated systems.

Re: XML is the future

#306

Post by papruapap »

mrighele wrote: post #253
edejong wrote: post #179

Earlier 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 I just did a "npx create-react-app text" and I got "74 vulnerabilities (69 moderate, 5 high)" 40 major security flaws in 10 years sounds almost like a bargain.

create-react-app has been discouraged to use for a couple of years now, not really sure if the React team is still supporting it.

Re: XML is the future

#307

Post by commandlinefan »

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…

> Hype after hype, fad after fad, modern after modern, refactor after refactor

And you're supposed to already know how to do it and give an accurate ~~estimate~~ prediction for how long it's going to take to do (that matches the amount of time they've already decided you have to do it). You're a _professional_ and professionals don't need time to actually learn how to do something new, they just know.

Re: XML is the future

#308

Post by throwuwu »

fifticon wrote: post #300
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…

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.

So how old does the tech need to be?

Re: XML is the future

#309

Post by jerf »

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

Letting an Erlang process crash is letting a process holding a small collection of resources, maybe a single TCP connection and several kilobytes of local state. It does not necessarily scale beyond that. Pretty much by definition, if you've got something that can run out of disk, when it runs out of disk and you nuke it, you're taking out a lot more than a single connection and a few kilobytes of state.

And "let it crash" is hardly "My service is invincible!" I'm sure any serious Erlang deployment has seen what I've seen as well, which is a sufficiently buggy process that crashes often enough that the system never gets into a stable state of handling requests. "Let it crash" is hardly license to write crap code and let the supervisor pick up the pieces. It's a great backstop, it's a shitty foundation.

Post reply on HN