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

181–190 of 408 posts

Re: XML is the future

#181

Post by einpoklum »

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…

> 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

But it's easier to get a company to upgrade from old cruft to a commonly-used technology, of your choice and which you push, over trying to get the company to drop a new fad they've bought into ("You know, we don't really need all of those Docker images, and VMs, and Amazon Cloud services - let's just write an executable which does the thing and can be configured.")

Re: XML is the future

#182

Post by samsquire »

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…

Thanks for your comment, I enjoyed it.

I think the computer industry is in its infancy and we haven't really found the right solution to many problems, for everyone to adopt the same thing requires it to be a very good option. BSD sockets is used by everyone - it's that good.

It reminds me of xkcd #927 about standards ( https://xkcd.com/927/ )

I would like a solution to the problem where library code is changed and it breaks code that relies upon it.

I would also like an API description format that we can code against and doesn't break.

Re: XML is the future

#183

Post by vbezhenar »

yread wrote: post #125
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…

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.

Re: XML is the future

#184

Post by TeMPOraL »

CraigJPerry wrote: post #160
coldtea wrote: post #149

Earlier quoted context omitted.

> Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines. Each of such tools expands to take the role of the other (and also read email)...

Hmmm i feel like those tools naturally railroad you into a certain split of responsibilities. Sure - you could use tf’s local/remote-exec to do the stuff you’d normally do with ansible but man that would be annoying and slow going when you know you can reach for ansible. Vice versa, you could have an ansible playbook to call the cloud provider’s api and cook up some kind of approval workflow / state management but ma…

Do they integrate that well? I don't have much experience with either, and until this moment I understood them to be substitutes - but still, I thought that:

> you could have an ansible playbook to call the cloud provider’s api and cook up some kind of approval workflow / state management

Was generally what people did before Terraform, and they be reluctant to add another complex tool, significantly overlapping with the current complex tool, just to simplify a part that already works OK.

Conversely, if Terraform is really so amazing as one would believe reading HN, then some amount of "local/remoe-exec" pain seems justified if it lets you avoid bringing in Ansible with all its complexity?

All these tools cost not just storage and processing, but also brain space. A Makefile in a cron, running some shell scripts, may be more brittle than whatever cookbooks or playbooks or ${what's the name for Terraform's flavor of makefiles}, but is also might be easier to fix when something breaks.

Re: XML is the future

#185

Post by einpoklum »

sublinear wrote: post #73
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.

> as just keeping the blade sharp

Replacing weapons and keeping blades sharp is not the same thing. Now, the metaphor kind of breaks down because new weapons are sharp, but abilities with a new technology are typically not, i.e. you use new tech as somewhat of a blunt instrument until you learn the finer points of it - and until it develops and matures enough itself.

So, if you want to use "sharp blades" - don't switch technologies, but rather keep with the updates to those you already know.

Re: XML is the future

#186

Post by ChicagoDave »

I absolutely love this rant. It’s why as an application architect we get “it depends” drilled into every decision we make.

But I’d also add one of my own observations.

I believe U.S. based companies tend to look for scapegoats when building software, so they lean into packages and products.

Outside the U.S., you see much more raw architecture and principle-based design, believing that if you craft a solution based on the actual needs of the business, your outcomes will be significantly better.

Re: XML is the future

#187

Post by shocks »

ilyt wrote: post #178
shocks wrote: post #172

Earlier quoted context omitted.

Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in, viming a file, and hacking it a few times. These days, if you leave the app untouched for six months that 10 minute fix becomes 2 hours of fixing a broken docker build. :)

As an admin of PHP apps at that time I can sincerely say screw you, you're lying. PHP apps breaking because new version of PHP shat on compatibility was pretty common, and weirdly enough got more common in newer versions. You also had to keep unholy combo of php extensions (why that garbage is in app server and not app) and server config because the special little retard that designed the app decided he must do somet…

> forget about it for a few years

No version upgrade required. :D

Re: XML is the future

#188

Post by revskill »

Programmers, in reality, is like trader.

We jump on hype, just like you jump on a new coin, pump, dump happens, of course.

So, it's reality, what's future is based on usefulness to the masses (enterprises).

Re: XML is the future

#189

Post by shocks »

edejong wrote: post #179
shocks wrote: post #172

Earlier quoted context omitted.

Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in, viming a file, and hacking it a few times. These days, if you leave the app untouched for six months that 10 minute fix becomes 2 hours of fixing a broken docker build. :)

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.

If you forget about a PHP container for a few years it will /also/ have 40 new vulnerabilities. Actually, containers are worse because OS updates of core shared libraries do nothing. You have to rebuild every damn container.

Setting up monitoring for your docker containers is also a whole thing. :)

I think you’re taking my example a little too literally. My point is not that docker/k8s/whatever is bad; just that the ‘new’ adds features at the cost of simplicity.

Re: XML is the future

#190

Post by AdamCraven »

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 because a lot of engineers are learning to become better plumbers, not better engineers.

Trying new technologies means you're mostly becoming better at using someone else's APIs - this is the path to eventual burn out as the churn continues.

There is a better path - See through the hype. Ask those around you what's the downsides to this approach? And you'll often get blank stares... Why? Because they don't know either - And if they don't know the downsides, they don't really know. They are following the hype curve.

Focus on the fundamental engineering principles and asking better questions - take the bottom-up approach and the reward is you'll find teams that aren't taken by the hype curve so easily.

PS. There are a lot of good technologies that come out, but staying behind the hype curve a little helps you make better judgements over time.

Post reply on HN