The basic reason to use XML::Twig as opposed to XSLT would be to do XML processing while still having access to all of Perl's power, DB access, file system integration etc... things that can be clunky to do in XSLT.
For what it's worth I have used XSLT too, and the basic programming patterns are surprisingly similar: an XPath selector triggers some code, the code has access to the XML tree. In both cases you have to pay some attention to when that code is being triggered. I prefer the XML::Twig way, to being able to use a regular programming language in the code, partly because I am used to it, but also because the XSLT XML syntax ends up being quite verbose, and leads to delimiter collisions.
XML::Twig also lets you work with "too big to fit in memory" XML, by working at sub-tree level in a nicer (IMHO) way than SAX. I am sure there are other ways these days, but the module dates back to last century, so at the time that was pretty unique.
I assume that other languages also have convenient XML libraries, so if you're more familiar with them and they work for you, then you should use them!
The lawsuit doesn't argue that Facebook actions hurt specific portfolios from their shareholders.
It claims that it hurt a typical diversified portfolio. One that FB shareholders should have, according to the Modern Portfolio Theory (MPT). It notes that the MPT is not only commonly accepted, it is in fact used to write laws and regulations: "Before the advent of MPT, “legal lists” prohibited many fiduciaries from owning common stock".
So if the MPT is indeed a cornerstone of modern economics, and modern laws, the natural conclusion is that it should be considered when looking at the fiduciary consequences of a company decision.
Facebook case shows the problem very clearly, because both of the scale of the impact of the company on the World in general, and the structure of its governance, where the majority vote holder interests are not diversified, which makes them diverge significantly from all the other shareholders interests.
As I understand it, it's a bit of legal jiu-jitsu: it takes the MPT, which so far has been used to allow more actors to invest in stocks, and so accepted readily by business and legal actors. It then uses it to extend the responsibility of companies to some externalities.
It may or may not succeed, but it doesn't seem completely insane. At the very least the discovery process could be used to show to which extend Facebook knows about features that have a clearly negative effect on society in general, and chooses to implement them anyway.
I like it. It's simple enough to add to a form from a template, and doesn't get in the way.
2 things I would like:
- customize (translate, actually) the "I am not a robot" text, since I do work for non-English customers,
- have the "redirection" be just a pop-up window. My use case for Sendfly would be for 1 page brochure sites, and I'd very much like those sites to really be 1 page. Maintaining 2 pages is a lot more work than a single one, especially if I update them very, very infrequently.
I may end up using it as is, it would improve some of those sites anyway.
Actually the descriptions of the battle I have seen do not mention archers.
Rather it looks like a militia on foot was able to defeat a cavalry-based army by choosing (and preparing) the battlefield. It seems that both armies used crossbows, and that actually the French did better with them.
tags should help, but after browsing the site, I am not sure they do.
Stackoverflow works well because it is really easy to scan only questions about the topics I am interested about. The tags are quite precise and there is general consensus on what they should be. I look at the "perl" tag, often, or at the "XML" one... voilà!
With a "soft" subject, like expats, it's harder to filter interesting questions. It doesn't naturally lead to accepted categories, and most of the info I would be interested in wouldn't fit in a single one.
So either the site stays low-volume, and I can scan all questions, and rarely find one that I am interested in. Or it becomes successful and chances are that I will miss the threads I would have liked to read.
For what it's worth I have used XSLT too, and the basic programming patterns are surprisingly similar: an XPath selector triggers some code, the code has access to the XML tree. In both cases you have to pay some attention to when that code is being triggered. I prefer the XML::Twig way, to being able to use a regular programming language in the code, partly because I am used to it, but also because the XSLT XML syntax ends up being quite verbose, and leads to delimiter collisions.
XML::Twig also lets you work with "too big to fit in memory" XML, by working at sub-tree level in a nicer (IMHO) way than SAX. I am sure there are other ways these days, but the module dates back to last century, so at the time that was pretty unique.
I assume that other languages also have convenient XML libraries, so if you're more familiar with them and they work for you, then you should use them!