Live data from Hacker News

XML is the future

bitecode.dev

201–210 of 408 posts

Re: XML is the future

#201
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 such a fear for this, that things i invest time/energy into today will be obsolete in half a year, and my time would be essentially "wasted".

As others say, learning the fundamentals will, and trying to get some more general skill out of every tech fad.

(although, full rewrite every 6 months is excessive imo)

Re: XML is the future

#202
Reminds me of this old skit article about Docker, "It's the future":

https://web.archive.org/web/20160817120102/https://circleci....

Discussion here: https://news.ycombinator.com/item?id=12303075

The single greatest thing about minimalism is the ease of replacement and maintainability in comparison with maximalism, to my humble experience.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." ― Antoine de Saint-Exupéry

Re: XML is the future

#203

Earlier quoted context omitted.

A better comparison would perhaps be “ansible” vs “puppet” vs “chef”. I wrote everything in shell, then puppet, then chef, then ansible. Doing literally the same thing. Because fads.

Taking this comment in good faith, because HN... Do you really not see any difference between Ansible and a shell script? Even just the move between shell and bash/csh/tcsh/zsh whatever else can make a marked difference in productivity and ergonomics.

> Do you really not see any difference between Ansible and a shell script?

Surely they do, but how much those differences matter depends on where those tools sit in relation to what you're trying to achieve.

For example, I could write essays about the differences between bash and PowerShell, and about differences in productivity their various facets create, in both abstract and concrete terms. However, when my task is not about shell scripting per se, and the script plays only a minor role in the solution ("oh, but we can make the button launch a script that launches X"), and my main concern about that stage is to convince the team to use Bash and/or PWSH instead of making Python a dependency in the project - then bash and PWSH are really the same thing to me - any difference in productivity for that use case is dominated by one's familiarity with the tool, and none of it matters anyway if my co-worker succeeds slotting in Python for that use case.

Similarly, there are many differences between bare shell scripts and Ansible, and there are differences between Ansible and Puppet and Chef too. But they're also close to each other, so if your use case doesn't hinge on those differences, you can be excused for wondering why can't we just keep using a Makefile for this.

Re: XML is the future

#204

XML is very much misunderstood. The hype that surrounded it was for a good reason, because XML is somewhat unique as a concept. There was nothing like it and still isn’t. It is not a data format or something like that. It is a notation tool. Normally you invent some syntax and parse it to get what is called “abstract syntax tree” (AST). With XML you work directly with an AST. Parsing from text is convenient because y…

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 these records need more fields, so we add attrbiutes:

    ... the first day of that year ...
This is the usual case in markup: we need the computer to do something with the text and use the records as a guide.

But a notational case is different. With notational case we still need the computer to do something, but not about a particular piece of text. (This is actually the general case while text-handling is a specific one.) In this case we can command it directly:

    
      
      
    
There is no text in these records, but we still use notational tools: 1) node type, 2) composition, 3) ordering, 4) naming/referencing. In this case we put everything into attributes.

We can have a notational piece with markup parts or a markup part with notational parts, but each has a clear purpose. There is also a third specific case: we want to switch to another notation and in this case we write it as text inside an XML element.

SVG is a good example. All data go into attributes, text inside elements appears only when 1) it is a part of the drawing, or 2) we are switching to another notation:

    
    
      
       
        ...
      
      
      ... ... ...
      
      
    

Re: XML is the future

#205
post #117
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…

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!

Re: XML is the future

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

I’ve been in that camp the last 20 years, and even yearned for a paradigm shift or two. But I have to say, the coming shift from formal languages, type systems and somewhat predictable failure modes to… “prompt engineering” has me a bit worried

Re: XML is the future

#207

Any interaction I've had with XML has been a negative experience. Can someone explain to me how JSON is not superior in every way?

I'll give just one obvious one: XML is far more resilient against syntax errors. Miss a closing tag in XML and a clever parser might even be able to infer it. With JSON, you know you're missing a brace at the end, but you have no idea where it should go.

Re: XML is the future

#208
post #187
post #178

Earlier quoted context omitted.

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

Haha yeah I can say, with the same sincerity, that I get occasional calls about fixing PHP apps that I built 2007-2013. They've been running (without upgrades) on some forgotten server in a multinational corporation.

I tell them that they should let their compliance department know, that the version of PHP isn't even supported, and I list some of the thousand security fixes that they aren't using.

I usually end up VPN/FTP:ing into a forgotten era to add the fixes and I definitely don't want to go back.

Re: XML is the future

#209

Earlier quoted context omitted.

A better comparison would perhaps be “ansible” vs “puppet” vs “chef”. I wrote everything in shell, then puppet, then chef, then ansible. Doing literally the same thing. Because fads.

Taking this comment in good faith, because HN... Do you really not see any difference between Ansible and a shell script? Even just the move between shell and bash/csh/tcsh/zsh whatever else can make a marked difference in productivity and ergonomics.

I mean, yeah? Ansible has roles, collections and a great inventory system. There's a lot of extra steps if you want to use a shell script instead, to i.e. install Docker on multiple hosts running different OS versions. I don't really like Ansible, but I think it's quite good for provisioning. It's also super easy to write filters and plugins for extra functionality.
Post reply on HN