OPML Is Underrated

Re:OPML Is Underrated by thechao on Saturday February 10, 2024 @11:01AM (#39327140)

My day job combines assembly and XSL (GPU dev work can be weird). I have a soft spot for XSL; but, at this point, the combination of Python 3's performance story (concurrency, threading, multiprocessing), ElementTree, and itertools... I just don't see it anymore. Especially since any new hire has Python experience due to the current ML summer. I've been porting all my XSL to Python, and I couldn't be happier.

[ Parent | on HN ]

Re:OPML Is Underrated by riedel on Saturday February 10, 2024 @11:19AM (#39327337)

I still find it hard to write transformations nicely in normal programming languages. I actually even used it to transform structured formats and always am quite happy (using [0]). Also generated spreadsheets and docs (actually via markdown and pandoc) just 2 days ago. xsltproc is for me the awk/sed of structured.

[0] http://www.ananas.org/xi/

[ Parent | on HN ]

Re:OPML Is Underrated by billywhizz on Saturday February 10, 2024 @11:07AM (#39327206)

yeah, making XML/XSLT fast is definitely a hard problem. still in pretty wide use in enterprise systems where correctness and interop are bigger priorities. i did quite a lot of work with shipping api's recently and you would be surprised how many of them are still XML and even SOAP based.

i'm intrigued by the combination of Assembly and XSL - any pointers to what you use those for?

[ Parent | on HN ]

Re:OPML Is Underrated by thechao on Saturday February 10, 2024 @11:37AM (#39327557)

Hardware specs are written in docbook in a lot of places. On the flip side, new HW won't have good C compilers for a while.

[ Parent | on HN ]

Re:OPML Is Underrated by fijiaarone on Saturday February 10, 2024 @11:30AM (#39327459)

Now that computers have more than 640kb of memory, it’s much easier to parse a document tree into a data structure and output exactly what you want.

[ Parent | on HN ]