чой-то мне шлея под хвост попала и решил прикрутить к своей прожке возможность сохранять данные в хмл.. глянул имеющиеся либы и в итоге возник Вопрос == НАФИГА КОЗЕ БОЯНъ??? либы акиСЬ кривоваты, но дело даже не в этом.. 1. выходной файл получается больше по размеру, нежель акий-нть замшелый ини. 2. очевидные тормоза на операциях поиск/замена/удаления. === кроч, sqlite есмь явно убер-вариант в отличие от вундервафля-хмл. ЗЫ.. Друзья, акие Вы примеры могли б привести, где бы хмл действительно стал бы полезен???
xml полезен тогда, когда нужен не просто plain list данных типа a1 = value, a2 = value , а когда нужно описывать сложные структуры данных с именованными полями . Например, деревья там удобнее описывать, чем в ini . Сериализованные данные тоже. Плюс в кровавом ынтерпрайзе иногда практикуют части xml подписывать . Xml аналог json , просто многословнее, с практической точки зрения.
XML хорошо подходит для описания UI с дата байндингами и тд (WPF, FXML и тд)... лучше него на мой взгляд для этого подходит только QML... --- Сообщение объединено, 7 янв 2019 --- и да, я знаю, что это свойственно очень многих членам васм сообщества, мыслить типа "я не использую технологию - значит технология гуано"... но это далеко не так... если технология не применима или не удобна в ваших руткитах, это не значит, что технология никому не нужна... --- Сообщение объединено, 7 янв 2019 --- не надо уподобляться Инде, ну если вы канеш не один из его виртуалов, каких на этом форуме штуки три как минимум...
окошки сейчас легко делаются во всяких графических редакторах и хмл там напрямую и трогать не требуется + описание окошка не такое здоровое, тч размер выходного хмл не критичен. мы же говорим о ситуациях, когда выходные данные могут быть метры и метры, ежель не гиги. И тогда акий толк от хмл??? подавляющее кол-во современных ой-ти фреймворков действительно являются вопиющим излишеством == качество кодов не улучшается, зато на дисках свободного места не найдёшь от глючной и тормознутой блоутвары
Rel, С одной стороны да, локаль на FXML менять удобно, но зоопарк из технологий утомляет. После D3.js чего-то не хочется вспоминать UI на java c FXML. А своя хеш-мапа в каждом языке есть, что бы нужный json собрать.
q2e74, да, на лине зоопарк прям всеми фибрами Безобразия ощущаешь == акая-нть вшивая тулза на пару-другую килов может за собой такой поезд зависимостей притащить.. особенно доставляет, когда начинаются конфликты между этими зависимостями --- Сообщение объединено, 7 янв 2019 --- вообще, слово "технологии" слишком громко звучит == в основном имеют место быть "обёртки" на старые решения с целью повышения удобства разработки. А в итоге и разрабы топнут в этих "технологиях" и юзвери
Ну это не только на лине, так везде. Разработчики такого софта любят потыкать в других пальцем и укорительно покричать, что они изобретают очередной лисапед. Каждый новый уровень абстракции решает одни проблемы и добавляет новые. Уже не первый раз наблюдаем новые "фреймворки" и "языки программирования", которые "должны решить все наши проблемы", а на деле потом всё возвращается на круги своя: все эти фреймворки и языки программирования начинают распухать и обрастать костылями и дикими синтаксическими конструкциями. И вместо решения тривиальной задачи видим кучу различных абстрактных нагромождений, зато с "модными и современными штучками". У нас как-то на работе один человек зарядил какую-то длинную речь про абстракции, ну я предложил ему заплатить абстрактную зарплату . --- Сообщение объединено, 8 янв 2019 --- UbIvItS, а вообще используйте лучше JSON. Парсер для него выйдет где-то в полторы тысячи строк кода на Си.
а что кто то говорит о гигабайтах xml? речь идет о формате, который удобно читать и писать человеку... большие данные сериализуются в бинарщину или csv, если это в основном текстовые данные... --- Сообщение объединено, 8 янв 2019 --- в статически типизированных языках хеш-мапа для представления json не может быть реализована эффективно, тк значения могут быть одного из восьми разных типов... нужно что? абстракция для их представления, как одного вариантного типа...
+++++++++++++++++++++++..++++ не-не, Спасибо == sqlite вполне рулит тему так и сикуль вполне представим в текстовом виде + явный бонус скорости для большого аутпута. --- Сообщение объединено, 8 янв 2019 --- частенько имеет место быть ситуация, когда легче запустить легаси софтинку под виртуалкой и не сношать себе мозг с новомодными изысками
В кложуре код пишешь почти jsonом. Вместо полутора тысяч строк - одна или две. Конечно это ценой полуторотысячной структуры {:keyword1 value1 :keyword2 value2} и еще 250 строками кода на джаве для кейворда. А если еще все импорты посчитать... обвес не маленький, но вроде все шустро.
путать лисп с джейсоном - плохой тон, мистер... и да, кложура (как и лисп/схема) динамически типизированная... ну переведи этот фрагмент кода в "сикуль", что получится: Код (Text): <VBox xmlns:fx="http://javafx.com/fxml"> <Label fx:id="label1" text="Button not clicked"/> <Button fx:id="button1" text="Click me!" onAction="reactToClick()"/> <fx:script> function reactToClick() { label1.setText("Button clicked"); } </fx:script> </VBox>
Rel, я не путаю, просто Ritch Hickey не писал что-то похожее на лисп и хаскель. Эти ассоциации сильно уводят от понимания языка. Весь язык, это две основные персистентные структуры [] и {} из которых AST собирают, аля лисп. Структуры, с отключаемой(есть в языке инструменты) иммутабельностью и подключаемой ленивостью. Жирный по объему, но удобный динамичный полиморфизм функций, defmulti (позволяет полиморфизм по вейлу кейворда) и его быстрое, но кастрированное подобие defprotocol. Макросы defmacro. Остальное для удобства по мелочи. Эти штуки в clojure-master/src/jvm/clojure/lang как *.java лежат. Вот такой вот динамический язык, с опорой на джаваклассы. Без рефлекшенов и магии с байткодом. Rel, я не хочу сказать, что ты не прав. Прав, но ... мы в равной степени, но с разными знаками, сильно предвзяты к этому языку. Я не знаю Ocaml, но думаю, он гораздо, гораздо сложнее кложуры. Кложура просто разгружает мозги.
