s tim JITem, co to ma by bylo asi zajimave zkusit benchmarky oproti Pythonu a Pythonu s JITem - idealne i spotrebu pameti. Asi Shine nikdy Python nenahradi, je to trosku zombie projekt, ale muze se hodit. Treba Fedora a RHEL IMHO ted pouzivaji Luu na bootstrap, kdyz tam jeste neni Python a shelly jsou fujky fujky.
Jakože všechno volá interně, zatímco shell teoreticky všechno jako externí programy? (pominu-li různé optimalizace, které mají interní alternativy pro malou až velkou část příkazů)
Za mě to dává smysl hlavně ze dvou důvodů:
1. Rychlost - všechno se děje v jednom executable, viz výše.
2. Bezpečnost - udělat něco v shell blbuvzdorně je docela šílené - všechny argumenty by měly mít uvozovky a všechny příkazy "--" před skutečnými argumenty. Normálně se s tím lidi nepárají, ale měli by :-)
3. Případně ještě fakt, že na jakékoliv složitější manipulace shell prostě není dělaný (už jenom startswith bude přes echo-grep, o polích či mapách ani nemluvě).
Kdykoliv jsem napsal něco v shell, tak jsem od pár desítek - sto řádků přešel na Perl či jiný jazyk, Python apod. Pravda ale je, že i tam byly limity a nejeefektivnější bylo použít rovnou Java :-D .
Tak Java od v. 11 zvlada pisanie programov bez prekladu do 'class'. Rovno ako zdrojak ktory sa da spustit:
#!/usr/lib/jvm/jdk-11/bin/java --source 11
import org.w3c.dom.Document;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
import org.xml.sax.SAXException;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.transform.OutputKeys;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerException;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
import java.io.IOException;
public class JavaXmlFormatter {
public static void main(String[] args) throws TransformerException, IOException, SAXException, ParserConfigurationException {
DocumentBuilder documentBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document document = documentBuilder.parse(args[0]);
removeSpaces(document);
DOMSource source = new DOMSource(document);
Transformer transformer = TransformerFactory.newInstance().newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");
transformer.setOutputProperty(OutputKeys.DOCTYPE_PUBLIC, "yes");
transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount", "4");
transformer.transform(source, new StreamResult(System.out));
}
private static void removeSpaces(Node node) {
if (node.getNodeValue() != null) {
if (node.getNodeType() == Node.COMMENT_NODE) {
node.setNodeValue(node.getNodeValue().replaceAll("[\\t\\n ]+", " "));
} else {
node.setNodeValue(node.getNodeValue().trim());
}
}
NodeList childNodes = node.getChildNodes();
for (int i = 0; i < childNodes.getLength(); i++) {
removeSpaces(childNodes.item(i));
}
}
}
no jestli resi minimalizaci zavislosti, tak tam asi cpat Javu nebudou hele ;)
jinak jsem k tomu neco nasel proc a jak https://rpm-software-management.github.io/rpm/manual/lua.html
Tak základ Java by asi tak tragický nebyl (i když pořád to těch 100 MB+ bude?), ale hlavně start time by byl problém - Hello World sežere 300 ms real time (GraalVM asi bude lepší). Java jsem myslel obecně jako lepší volbu z hlediska efektivity vývoje, start je jediný zápor.
Díky za ten link, víceméně potvrzuje to výše. Navíc v RPM jej podle všeho používají jako "plugin", takže může snadno ovlivňovat zbylé kroky v rámci balíčku.
A s tím indexováním od jedna je to peklo a dávají před tím varování. Chápu, že je to "lidské", ale to byl Cobol taky. Všichni programátoři jsou zvyklí na nulu, a jak ukázal Python, nemají s tím problém ani ne-programátoři.