Vlákno názorů k článku Jazyk Shine: funkce, datové typy a práce s řetězci od atarist - s tim JITem, co to ma by bylo...
-
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.
