в каком общем случае view.tree эффективен, а в каком частном - нет ?
Нет. В качестве наиболее эффективного формата для структурированных документов был провозглашён tree, а затем на его основе был построен view.tree, который якобы настолько же эффективен в частном случае — шаблоны компонентов.
что с "{}" что с чем то другим, сейчас максимально компактно получается, портить не хочется
Людям не нужна максимальная компактность, иногда некоторая избыточность, наоборот, помогает. Формат tree же не рассчитан как таковой на человека, а скорее на лёгкое написание однопроходного парсера.
залетай к нам в @giper_dev , подумаем вместе, может что и сделаем
Это идея имеет слабое место. Легко было бы сделать пару страниц такой фальсификации, но не целую книгу. Простой шифр подстановки можно было бы найти, а написать бессмыслицу на десятки страниц, соблюдая неизвестный тогда закон Ципфа, абсолютно нереально.
Почему-то в си-подобных языках, в том числе и в базовых фронтенд-языках JavaScript, TypeScript, используется именно скобочный синтаксис, тогда как тренд на синтаксические отступы не прижился. Мне кажется, что вашим стараниям по продвижению фреймворка мешает ваша же оголтелая субъективщина. Тем более, как я уже упоминал когда-то в комментариях, в обосновании преимуществ формата tree была логическая ошибка сведения к частному: «Если какое-то решение эффективно в общем случае, значит оно эффективно и в частном», что, разумеется, неверно.
Тем более, сравнение DSL идёт только с уже существующими решениями, хотя можно было бы рассмотреть какие-то гибридные или аналогичные решения типа языка шаблонов Angular или Vue, либо что-то типа описания интерфейсов Jetpack / Swift.
Вся странность вынесена в первые пять минут (view.tree, $-неймспейс, MAM), а выгоды накапливаются месяцами. Профиль «затраты сейчас, выигрыш потом» — худший для adoption; у React ровно обратный.
Но это как раз сильно мешает продвижению, потому что мало кто хочет тратить столько усилий на понимание формата для фреймворка, преимуществ работы с которым они ещё не поняли. Большинство разработчиков хотят словить хайп, а вы их в каких-то китайских письменах заставляете разбираться. Так у вас популярности никогда не будет.
Те слова, которые не восходят к индоевропейским и обладают сходными фонетическими и морфологическими признаками, лингвисты относят к догреческому субстрату. Среди них, например, слова с суффиксами -nthos (labýrinthos — лабиринт, hyákinthos — гиацинт), -ssos (kypárissos — кипарис), -ttos (Lykabettos — Ликавит). Кроме того, ареал топонимов на -ssos, -ttos (Knossos — Кносс, Korinthos — Коринф) на Крите и материковой Греции идеально совпадает с зоной минойского и минойско-микенского влияния. Таким образом, к минойским заимствованиям относят слова догреческого субстрата, которые относятся к семантической сфере, где доминировали минойцы, или имеют географически связаны с ареалом минойцев.
Кстати, что интересно, слово χρυσός (золото) скорее всего действительно имеет семитское происхождение (финикийское ḥarūṣ, аккадское ḫurāṣu) и греки, вероятно, заимствовали его через минойское посредничество. Но вот для множества других минойских слов семитское происхождение не выявлено, поэтому минойский язык остаётся изолированным. Есть гипотеза, что он близок к неиндоевропейским языкам Анатолии (хаттский, хурритский), но никак не к семитским.
При этом в середине XX века некоторые лингвисты (Сайрус Гордон, позже Ян Бест и Фред Ваудхёйзен) уже выдвигали идею, что язык линейного письма А — это западно-семитский язык, родственный финикийскому или угаритскому. Но эта идея была отвергнута последующими исследователями.
Дима: «может, дело в том, что DSL плохой и неудобный?»
DSL это грамотное техническое решение: пишешь меньше кода, получаешь больше. JSX тоже когда-то был таким решением, просто, очевидно, не лучшим.
Здесь вы уходите от ответа. Вас не спрашивают, хорошо или плохо было использовать DSL. Вас спрашивают: мог ли $mol быть успешнее, если бы его DSL был другим.
Дима: «выбранная Карловским стратегия продвижения… однозначно свидетельствует о том, что все проблемы… решены не будут никогда».
Да, нужен маркетолог, который бы помог это продвигать.
А что, если маркетолог предложит вам поменять какую-либо из концепций? Например, минимально предложит перейти от синтаксически значимых отступов (как в CoffeeScript, HAML, Pug) к более привычному синтаксису на основе разделителей (как в TypeScript). Насколько сильным будет сопротивление вашего комьюнити? А если это с большой вероятностью увеличит заинтересованность разработчиков?
В том и прикол, что в правильной криптосхеме даже бот будет знать только свои карты, а казино не будет знать ничьих карт до окончания игры, что никак не поможет смухлевать
Такие протоколы известны уже давно под названием Mental Poker. И там не нужен магазин как отдельная сторона. Казино вполне может самостоятельно зашифровать карты и сделать доказуемую тасовку с нулевым разглашением (zero knowledge proof shuffle). Далее карты в раздаче раскрываются каждому из игроков с помощью re-encryption mixnet, чтобы никто до окончания игры не знал карт друг друга.
Об этом СМИ будут трубить как о сенсации; весь мир вспомнит космические миссии восьмидесятых и выучит кириллические буквы Ф и Б.
Вряд ли. Думаю, что если и напишут, то, к сожалению, как об очередном космическом факапе «этих русских». Но кликбейтный заголовок «Доказано техногенное происхождение космического объекта 1998 KY26» кто-нибудь не постесняется разместить.
Вы внимательно прочитали комментарий? Anselm_nn как раз и подразумевает, что у Let's Encrypt нет никакой особой безопасности, но и что Госуслуги будут не лучше.
Ну а пользователю-то какая теперь разница: нищебродский сертификат там от LE или заверенный OV? Раньше хотя бы браузеры зелёную плашку рисовали, а теперь максимум только название компании увидеть можно, и то минимум с двух кликов. Вот только история из ковидных времён, когда Zoom Technologies перепутали с Zoom Communications, показывает, что и тут пользователи могут всё перепутать. А приложения в мобильных телефонах вообще владельца сертификата не показывают.
Это не входит в область ответственности devops.
Молятся как бы их кучка сконкатенированных ямлов не рухнула на проде из-за Норвегии?
Речь как бы про фронтенд, а в среде фронтендеров тренд этот не прижился.
Ты предлагаешь спорить с нейронкой, которая даже первую мысль не поняла?
Нет. В качестве наиболее эффективного формата для структурированных документов был провозглашён tree, а затем на его основе был построен view.tree, который якобы настолько же эффективен в частном случае — шаблоны компонентов.
Людям не нужна максимальная компактность, иногда некоторая избыточность, наоборот, помогает. Формат tree же не рассчитан как таковой на человека, а скорее на лёгкое написание однопроходного парсера.
Хабр — не место для дискуссий?
Кажется, не получится: go изначально многопоточный язык, а js-среда однопоточная.
Это идея имеет слабое место. Легко было бы сделать пару страниц такой фальсификации, но не целую книгу. Простой шифр подстановки можно было бы найти, а написать бессмыслицу на десятки страниц, соблюдая неизвестный тогда закон Ципфа, абсолютно нереально.
Почему-то в си-подобных языках, в том числе и в базовых фронтенд-языках JavaScript, TypeScript, используется именно скобочный синтаксис, тогда как тренд на синтаксические отступы не прижился. Мне кажется, что вашим стараниям по продвижению фреймворка мешает ваша же оголтелая субъективщина. Тем более, как я уже упоминал когда-то в комментариях, в обосновании преимуществ формата tree была логическая ошибка сведения к частному: «Если какое-то решение эффективно в общем случае, значит оно эффективно и в частном», что, разумеется, неверно.
Тем более, сравнение DSL идёт только с уже существующими решениями, хотя можно было бы рассмотреть какие-то гибридные или аналогичные решения типа языка шаблонов Angular или Vue, либо что-то типа описания интерфейсов Jetpack / Swift.
Но это как раз сильно мешает продвижению, потому что мало кто хочет тратить столько усилий на понимание формата для фреймворка, преимуществ работы с которым они ещё не поняли. Большинство разработчиков хотят словить хайп, а вы их в каких-то китайских письменах заставляете разбираться. Так у вас популярности никогда не будет.
Стабильности нет
Те слова, которые не восходят к индоевропейским и обладают сходными фонетическими и морфологическими признаками, лингвисты относят к догреческому субстрату. Среди них, например, слова с суффиксами -nthos (labýrinthos — лабиринт, hyákinthos — гиацинт), -ssos (kypárissos — кипарис), -ttos (Lykabettos — Ликавит). Кроме того, ареал топонимов на -ssos, -ttos (Knossos — Кносс, Korinthos — Коринф) на Крите и материковой Греции идеально совпадает с зоной минойского и минойско-микенского влияния. Таким образом, к минойским заимствованиям относят слова догреческого субстрата, которые относятся к семантической сфере, где доминировали минойцы, или имеют географически связаны с ареалом минойцев.
Кстати, что интересно, слово χρυσός (золото) скорее всего действительно имеет семитское происхождение (финикийское ḥarūṣ, аккадское ḫurāṣu) и греки, вероятно, заимствовали его через минойское посредничество. Но вот для множества других минойских слов семитское происхождение не выявлено, поэтому минойский язык остаётся изолированным. Есть гипотеза, что он близок к неиндоевропейским языкам Анатолии (хаттский, хурритский), но никак не к семитским.
При этом в середине XX века некоторые лингвисты (Сайрус Гордон, позже Ян Бест и Фред Ваудхёйзен) уже выдвигали идею, что язык линейного письма А — это западно-семитский язык, родственный финикийскому или угаритскому. Но эта идея была отвергнута последующими исследователями.
Так какую же выгоду дают синтаксически значимые отступы?
Здесь вы уходите от ответа. Вас не спрашивают, хорошо или плохо было использовать DSL. Вас спрашивают: мог ли $mol быть успешнее, если бы его DSL был другим.
А что, если маркетолог предложит вам поменять какую-либо из концепций? Например, минимально предложит перейти от синтаксически значимых отступов (как в CoffeeScript, HAML, Pug) к более привычному синтаксису на основе разделителей (как в TypeScript). Насколько сильным будет сопротивление вашего комьюнити? А если это с большой вероятностью увеличит заинтересованность разработчиков?
Неа. В этом варианте получается, что казино знает все карты.
В том и прикол, что в правильной криптосхеме даже бот будет знать только свои карты, а казино не будет знать ничьих карт до окончания игры, что никак не поможет смухлевать
Такие протоколы известны уже давно под названием Mental Poker. И там не нужен магазин как отдельная сторона. Казино вполне может самостоятельно зашифровать карты и сделать доказуемую тасовку с нулевым разглашением (zero knowledge proof shuffle). Далее карты в раздаче раскрываются каждому из игроков с помощью re-encryption mixnet, чтобы никто до окончания игры не знал карт друг друга.
Не сказали только где брать надёжный достоверный drand
Вряд ли. Думаю, что если и напишут, то, к сожалению, как об очередном космическом факапе «этих русских». Но кликбейтный заголовок «Доказано техногенное происхождение космического объекта 1998 KY26» кто-нибудь не постесняется разместить.
А что делать тем, у кого телефон без мини-джека?
Вы внимательно прочитали комментарий? Anselm_nn как раз и подразумевает, что у Let's Encrypt нет никакой особой безопасности, но и что Госуслуги будут не лучше.
Ну а пользователю-то какая теперь разница: нищебродский сертификат там от LE или заверенный OV? Раньше хотя бы браузеры зелёную плашку рисовали, а теперь максимум только название компании увидеть можно, и то минимум с двух кликов. Вот только история из ковидных времён, когда Zoom Technologies перепутали с Zoom Communications, показывает, что и тут пользователи могут всё перепутать. А приложения в мобильных телефонах вообще владельца сертификата не показывают.