Так что либо верить более опытному товарищу, либо продолжать фантазировать.
Более опытный — это только ваши слова. Зачем мне им верить? Я использую вполне научный подход. Выдвигаю гипотезу, дальше подтверждаю ее, или опровергаю. Если сталкиваюсь с похожей ситуацией — использую полученный опыт.
Вот пример: есть гипотеза, что код на dap тяжело дебажить потому, что добрая часть логики является строкой.
Подтверждение 1.
Интерпретатор js не может связать ваш исходный код на строках с тем, что будет реально выполнено. Брейпоинт ставить в строках нет смысла. Будь это по другому, вы бы указали на использование Source Maps.
Подтверждение 2.
Не синтаксические ошибки тяжело найти. Это может быть банальная очепятка, корректная с точки зрения синтаксиса. Например для логического выражения забыл добавить логическое НЕТ, или еще что-то подобное. Что мне покажет консоль? Код работает штатно, но не корректно. В других языках такие ошибки тоже бывает трудно найти. Дебаггер в этом очень помогает, но опять же, у вас он не применим.
Подтверждение 3.
Для поиска ошибок часто используется unit тестирование. Штуки типа SOLID очень помогают в этом. У вас же сплошная простыня. Простыню покрывать тестами тяжелее, чем много отдельных компонентов.
Вы, может, не знали, но в любом андроиде есть как минимум WebView, а как правило — целый Chrome.
Это замечательно. Только в андроиде я что-то сомневаюсь, что есть:
yandex mapkit, opencv. Они уже больше 75кб весят. Шрифты и изображения тоже весят больше 75кб.
В распознавании QR не поможет, но можно воспользоваться сторонним, правда?
Конечно же можно, но размер из ваших 75кб придется вычесть.
Где вы увидели в моих постах про «самые правильные и самые лучшие решения»?
Вы воспринимаете все фразы буквально? И даже кавычки вас не смутили?))
Доказывать тут что-то вдруг требуют все, кроме меня.
Если вы пиарите что-то новое, еще раз, у вас должна быть мощная аргументация о том, что вы пиарите. Хабр это не рен.тв, где бабки заряжают воду от dvd дисков, тут не надо верить. Тут вполне мощное сообщество с довольно высокой экспертизой.
Скептицизм — это отличное качество этого сообщества. Если вы хотите, что бы ваш проект восприняли серьезно — потребуется серьезная аргументация, которая переборет этот скептицизм.
И при этом считают своим долгом меня жизни поучить.
Фитбэк — он такой. Иногда жестковытый, но чаще всего по делу. Вот пример:
C влажными фантазиями — это давайте в личку. Желательно не ко мне.
Это оборот речи))
Как раз таки 75 мегабайт классов. Кода. Вы считаете это нормальным, ок.
Большая часть объема архива — это мета данные, статика и внешние либы, а не код непосредственно приложения.
я правда им последний раз пользовался лет 5 назад, понятия не имею что там сейчас. и мне понадобятся спеки на их хттп-апи
т.е. вы не зная что нужно сделать утверждаете, что ваш код будет умещен в 75кб, просто потому что?
я могу специально для вас написать на dap приложение со всем функционалом Сберонлайна и уместить его в 75 кБ.
Очень интересно, как вы в 75кб уместите все окружение, в котором ваш dap выполняется. Так же интересно, куда вы впихнете всю статику, которой довольно много. Так же интересно, как dap поможет в распознавании QR кодов (это есть в оригинальном приложении).
Но я, признаться, рассчитывал все же на уровень повыше, чем «ниасилил, но осуждаю».
Интересно, сколько лет вы работаете инженером?
Понимаете какая штука, концентрация на проблеме и ее решение в ваших статьях и комментариях очень похоже на аргументацию и уверенность новичка. В стиле "писать мало — это круто, если не согласен — докажи мне обратное".
Для новичков так же очень свойственно создавать свои правильные и самые лучшие решения. Специалисты уровня синьор и выше, как правило сразу знают множество решений одной и той же проблемы, а выбор строят на более весомых критериях, чем объем кода, как правило это: поддерживаемость, производительность, легкость интеграции, легкость расширения, тестируемость, дороговизна для бизнеса и т.д.
Решения, используемые в вашем проекте во многом противоречат общим подходам, к которым область шла годами. Именно по этой причине вам требуется очень качественная аргументация по ним.
Если аргументация не достаточно качественная — вы получаете вбросы в комментариях.
Это Android приложение. Основную часть архива занимают скомпилированные *.so библиотеки, ассеты, ресурсы и dex файлы. Библиотеки, типа libcom.yandex.mapkit.so могут быть подключены, но это вовсе не значит, что вся функциональность из них используется, так же не значит, что все возможные объекты из каждой из библиотек создаются сразу. Так же не значит, что все ассеты подключаются и рендерятся сразу.
А слив засчитан потому, что вы понятия не имеете о чем говорите.
Сколько приложений на dap вы уже написали, чтобы так авторитетно об этом заявлять?
На вашем детище нисколько, и никогда не напишу. Я спросил вас, какую проблему решает ваш проект. Если убрать субъективщину — это уменьшение объема кода.
Уменьшение объема кода с помощью магии и dsl чаще всего приводит к серьезному удорожанию поддержки, расширения, тестирования. В редких случаях — к упрощению чтения.
Чем больше проект — тем серьезней последствия. Для бложика, или todo листа ваш проект возможно и может экономить время, но для среднего и крупного он его будет наоборот отнимать.
Здесь что, автор фактом написания статьи уже чем-то всем обязан?
Когда вы публикуете что-то новое — будьте готовы к критике, это не только на хабре происходит. Если вы не можете качественно аргументировать те, или иные решения — это печально, особенно в публичном пространстве, типа хабра.
Вам не нравится dap, а нравится php — ок, я без проблем.
php я привел по той причине, что аналогичная проблема существовала довольно длительный период, сообщество ее осознало и решило много лет назад. Ваш dap же эту проблему создает заново.
Первый мой коммент к этой статье (заминусованный гордыми экспертами) полностью отражает мое отношение к этому вопросу.
Тогда зачем вы тратили свое время на написание статьи?))
Вы понимаете, что пишете глупость?)) Объем занимаемой памяти на прямую зависит от количества создаваемых объектов и их взаимосвязей, а не от объема кода.
Следующий пример отжирает свыше 400мб, хотя это мелкий однострочник.
Мотивация — писать чище, проще, лаконичней и декларативней, без бойлерплейта и ритуалов.
Я вот прям сейчас смотрю на ваши примеры. Чище и проще — это не про них. Если подытожить: ваша мотивация — писать мало и декларативно.
За всю свою карьеру я не встречал проектов, в которых объем кода являлся проблемой. Скорее даже наоборот, иногда нужно написать больше, что бы код был поддерживаемым, тестируемым, расширяемым и производительным. Можете привести пример проекта, где критичен именно объем кода?
Что касается декларативности — это сама цель, или способ уменьшения объема кода?
А зачем в принципе нужен ваш фреймворк? В смысле какие задачи он решает прям на порядки лучше других? В прошлой статье вы написали:
dap — интересный и необычный язык реактивных правил для написания, в частности, веб-фронтендов
Круто, еще один DSL поможет людям, только вот с какими задачами?
В этой статье вы нарисовали пример, это здорово, но вот с мотивацией опять же все очень не ясно.
С apk проверил, в отличии от вас (в начале).
Более опытный — это только ваши слова. Зачем мне им верить? Я использую вполне научный подход. Выдвигаю гипотезу, дальше подтверждаю ее, или опровергаю. Если сталкиваюсь с похожей ситуацией — использую полученный опыт.
Вот пример: есть гипотеза, что код на dap тяжело дебажить потому, что добрая часть логики является строкой.
Подтверждение 1.
Интерпретатор js не может связать ваш исходный код на строках с тем, что будет реально выполнено. Брейпоинт ставить в строках нет смысла. Будь это по другому, вы бы указали на использование Source Maps.
Подтверждение 2.
Не синтаксические ошибки тяжело найти. Это может быть банальная очепятка, корректная с точки зрения синтаксиса. Например для логического выражения забыл добавить логическое НЕТ, или еще что-то подобное. Что мне покажет консоль? Код работает штатно, но не корректно. В других языках такие ошибки тоже бывает трудно найти. Дебаггер в этом очень помогает, но опять же, у вас он не применим.
Подтверждение 3.
Для поиска ошибок часто используется unit тестирование. Штуки типа SOLID очень помогают в этом. У вас же сплошная простыня. Простыню покрывать тестами тяжелее, чем много отдельных компонентов.
Если мои аргументы для вас не понятны, это очень печально.
С чего вдруг?
Ого, сильное утверждение. Правда ложное, вы следующим предложением его же опровергаете.
А что если ошибка не синтаксическая?
На php совсем не похоже. bash кстати тоже использует $ для переменных, но, на него тоже не похоже.
Нет аргументов — переходи на личности, так держать.
31, web разработкой занимаюсь с 2007-го.
Слив засчитан.
Я бы не сказал, что подобные текстовки прям простые. Один символ не на своем месте и поиск ошибки будет очень радостным.
дебаг — это про брейкпоинты.
Разве нет?
Это замечательно. Только в андроиде я что-то сомневаюсь, что есть:
yandex mapkit, opencv. Они уже больше 75кб весят. Шрифты и изображения тоже весят больше 75кб.
Конечно же можно, но размер из ваших 75кб придется вычесть.
На ваши глупости нет.
Вы воспринимаете все фразы буквально? И даже кавычки вас не смутили?))
Если вы пиарите что-то новое, еще раз, у вас должна быть мощная аргументация о том, что вы пиарите. Хабр это не рен.тв, где бабки заряжают воду от dvd дисков, тут не надо верить. Тут вполне мощное сообщество с довольно высокой экспертизой.
Скептицизм — это отличное качество этого сообщества. Если вы хотите, что бы ваш проект восприняли серьезно — потребуется серьезная аргументация, которая переборет этот скептицизм.
Фитбэк — он такой. Иногда жестковытый, но чаще всего по делу. Вот пример:
Как у вас с дебагом дела?
Это оборот речи))
Большая часть объема архива — это мета данные, статика и внешние либы, а не код непосредственно приложения.
т.е. вы не зная что нужно сделать утверждаете, что ваш код будет умещен в 75кб, просто потому что?
Очень интересно, как вы в 75кб уместите все окружение, в котором ваш dap выполняется. Так же интересно, куда вы впихнете всю статику, которой довольно много. Так же интересно, как dap поможет в распознавании QR кодов (это есть в оригинальном приложении).
А есть смысл?
Вы разархивируйте apk файл для начала, а дальше рассказывайте про свои влажные фантазии о том, что там есть и чего там нет.
Для вас по идее должен и меть.
Мне вот просто интересно, откуда вы взяли 75кб? Пальцем в небо? Или это мистическая цифра, описывающая идеальный размер кода?
Интересно, сколько лет вы работаете инженером?
Понимаете какая штука, концентрация на проблеме и ее решение в ваших статьях и комментариях очень похоже на аргументацию и уверенность новичка. В стиле "писать мало — это круто, если не согласен — докажи мне обратное".
Для новичков так же очень свойственно создавать свои правильные и самые лучшие решения. Специалисты уровня синьор и выше, как правило сразу знают множество решений одной и той же проблемы, а выбор строят на более весомых критериях, чем объем кода, как правило это: поддерживаемость, производительность, легкость интеграции, легкость расширения, тестируемость, дороговизна для бизнеса и т.д.
Решения, используемые в вашем проекте во многом противоречат общим подходам, к которым область шла годами. Именно по этой причине вам требуется очень качественная аргументация по ним.
Если аргументация не достаточно качественная — вы получаете вбросы в комментариях.
Это Android приложение. Основную часть архива занимают скомпилированные *.so библиотеки, ассеты, ресурсы и dex файлы. Библиотеки, типа libcom.yandex.mapkit.so могут быть подключены, но это вовсе не значит, что вся функциональность из них используется, так же не значит, что все возможные объекты из каждой из библиотек создаются сразу. Так же не значит, что все ассеты подключаются и рендерятся сразу.
А слив засчитан потому, что вы понятия не имеете о чем говорите.
Слив засчитан
На вашем детище нисколько, и никогда не напишу. Я спросил вас, какую проблему решает ваш проект. Если убрать субъективщину — это уменьшение объема кода.
Уменьшение объема кода с помощью магии и dsl чаще всего приводит к серьезному удорожанию поддержки, расширения, тестирования. В редких случаях — к упрощению чтения.
Чем больше проект — тем серьезней последствия. Для бложика, или todo листа ваш проект возможно и может экономить время, но для среднего и крупного он его будет наоборот отнимать.
Когда вы публикуете что-то новое — будьте готовы к критике, это не только на хабре происходит. Если вы не можете качественно аргументировать те, или иные решения — это печально, особенно в публичном пространстве, типа хабра.
php я привел по той причине, что аналогичная проблема существовала довольно длительный период, сообщество ее осознало и решило много лет назад. Ваш dap же эту проблему создает заново.
Тогда зачем вы тратили свое время на написание статьи?))
Вы понимаете, что пишете глупость?)) Объем занимаемой памяти на прямую зависит от количества создаваемых объектов и их взаимосвязей, а не от объема кода.
Следующий пример отжирает свыше 400мб, хотя это мелкий однострочник.
Вы явно не в теме))
Помесь css, псевдо-html, js и вашего dsl — это и есть комок.
Вы когда нибудь слышали про SOLID?
Именно по этой причине у вас и получается комок. Посмотрите QML на досуге, парни из Qt как раз решили эту проблему.
Ваш dsl усложняет проектирование архитектуры приложения.
Контекст вопроса был, почему вы считаете, что декларативность это способ писать чище, проще и меньше?
Чище/проще — это про SOLID, и в принципе направления по разделению кода. У вас же сплошной комок. В php например так не пишут уже лет 10.
С чего вы взяли?
Я вот прям сейчас смотрю на ваши примеры. Чище и проще — это не про них. Если подытожить: ваша мотивация — писать мало и декларативно.
За всю свою карьеру я не встречал проектов, в которых объем кода являлся проблемой. Скорее даже наоборот, иногда нужно написать больше, что бы код был поддерживаемым, тестируемым, расширяемым и производительным. Можете привести пример проекта, где критичен именно объем кода?
Что касается декларативности — это сама цель, или способ уменьшения объема кода?
А зачем в принципе нужен ваш фреймворк? В смысле какие задачи он решает прям на порядки лучше других? В прошлой статье вы написали:
Круто, еще один DSL поможет людям, только вот с какими задачами?
В этой статье вы нарисовали пример, это здорово, но вот с мотивацией опять же все очень не ясно.