Я хоть и не Cpp джедай, но, тем не менее, прочитал статью с интересом. Не обращайте внимания на такие вот скользкие комментарии. Как вы правильно сказали, там даже аргументации толковой нет. Специалист себя так не ведет. А вы - большой молодец! QuickJS, кстати, использует редактор Figma (скомпилированный в WASM) для своей плагин-системы.
Щас как расскажу вам тайну! Короче в Node.js есть еще приватный консоль-лог. Это process._rawDebug. Разница с console.log в том, что приватная версия не триггерит никаких асинхронных апишек. Вот например можно разницу увидеть в использовании async_hooks:
import { createHook } from 'async_hooks'
createHook({
init: () => {
console.log('oops') // <- вот тут будет max call stack size exceeded
process._rawDebug('oops') // <- тут нет
}
}).enable()
Я люблю тайпскрипт, но этот пропоузал какой-то бред, кмк. Вводить "типы как комментарии" только чтобы не компилить TS - какой-то абсурд. Либо вводить типы как типы, либо ничего не менять. Завтра фейсбук скажет - давайте синтаксис JSX введем нативно, нам так хочется.
Вот это приятный разговор. Вообще, Игорь, хотел бы выразить благодарность за усердие и статьи, хоть некоторые из них, конечно, не достаточно полны/компетентны. Но, как говорится, не ошибается тот, кто ничего не делает, поэтому еще раз спасибо и продолжайте в том же духе!
Пожалуй единственный фреймворк, который кроме "мой синтаксис лучше - это ж очевидно" приносит реальное решение реальных проблем так это Крэнк. На данный момент, это, имо, самый трезвый подход к решению веба. https://crank.js.org/blog/introducing-crank
Можно ссылки, пожалуйста? Хочу почитать, интересно.
"Проклятие знания"
Я не знаком в деталях с работой Роберта Хогарта, но помимо вашего объяснения в статье мне кажется тут можно трактовать это еще и другим образом. В статье вы пишите, грубо говоря, "не знаешь — не понимаешь". Но еще есть один любопытный эффект — это когда как раз незнание чего-либо освобождает тебя от "оков" полета мысли. То есть, грубо говоря, какие-нибудь фантастические штуки, которые выдумывают писатели (гумманитарии, в первую очередь) в книгах — возможно не пришли бы в голову как концепт технарям-ученым, которые знают область гораздо глубже. Почему? Потому что часто некоторые вещи нам могут показаться нереально сложными или вообще невозможными, но это может быть поверхностным суждением, иногда стоит попробовать "плясать от результата". Поэтому когда не-программист говорит "я хочу то-то и то-то" — иногда это может не укладываться в наш программистский мозг, но это не проблема заказчика, а проблема рамок нашего мозга.
Тот момент, когда думаешь, что заголовок статьи перевели не правильно, и что, скорее всего, в оригинале написано что-то типа "… нейтив аппс" и проверяешь:
The ultimate guide to create desktop apps for javascript entrepreneurs
Что в переводе значит:
Полное руководство по созданию приложений для javascript-предпринимателей
Диалекты регулярок, во-первых, очень похожи или часто даже практически одинаковы. Во-вторых, один раз поняв их синтаксис — вы убъете гораздо больше зайцев, чем если будете разбираться со всеми возможными апишками билдеров в разных языках и местах системы.
Про доверие — в обоих сценариях вы не пишете императивную программу с нуля и не двигаете байты в памяти. Вы все равно перепоручаете кому-то эту задачу. Только одно дело вы это поручите кому-то, кто это делает больше 30 лет (при чем не один), а другое дело вы поручите эту задачу новоиспеченному продукту от одного человека.
Вам, автор, все время хочется писать велосипеды. Которые, с вашей точки зрения, гораздо лучше. Ведь они синие и трехколесные. С трехколесного упасть сложнее, чем с двухколесного! А синий цвет — вызывает доверие по теории цветов, если я не ошибаюсь. И хорошо бы, если бы вы свои велосипеды так и преподносили остальным: с них труднее упасть и они вызывают доверие. Но вы часто пишите свои поделки с таким посылом: все велосипеды, кроме моих, это лютая шляпа. Никому не нужны двухколесные, горные и прочие другие. Есть мои и все.
Я не очень хочу уходить в дискуссию регулярок, но регулярки совсем не сложные. Их синтаксис можно выучить за то же самое время, что и синтаксис любой библиотеки, идущей им на замену. Они гораздо гибче и дают нейтив интеграцию в большинстве мест, где они уместны. А количество человеко-часов, потраченное на написание компиляторов регулярок гораздо больше, чем у альтернатив, из чего следует, что места, которые можно оптимизировать, оптимизированны в большинстве своем. Да, можно написать регулярку, которая убъет программу — есть такие вот сложные для исполнения номера. Но обычно это объясняется большой вариативностью и решить такое — не проблема регулярок конкретно, а проблема вообще.
Ваше желание упростить работу с регулярками я бы направил на создание не генератора, а дебаггера или хотя бы хайлайтера какого-то. Короче чтобы эти вот длинные регулярки не пугали, а можно было бы просто закинуть в какой-то редактор и посмотреть где там группа, где там квантификатор и прочее.
Потратив пару дней на изучение регулярок и много лет применяя их в практике я не имею ни малейшего желания:
1) зачем то что-то стороннее внедрять в свои проекты
2) учить новый синтаксис
3) доверять библиотеке парсинг (это, на секундочку, не шутки — если у вас там где то дырка в билдере, вы можете очень просто создать дыру безопасности)
4) верить, что все это будет быстрее или хотя бы на уровне регулярок
Поэтому, мне не понятно — зачем это все. Как пет-проект для саморазвития — отличная затея! Но чтобы это вот на серьезе выкладывать и говорить, что регулярки это не ок — вы серьезно?
Все, кто тут пишут про "если у них такой код — в баню такую контору" — может стоит иногда подумать, что не все в жизни может быть так прямолинейно?
Ну, то есть, есть категория задач на более практическое применение ваших знаний — например, написать какую-то ту-душку или еще что-нибудь в этом роде. Но есть и такие, где работодатель хочет "пощупать" будущего сотрудника и за другие его качества: знает ли он банальнейшую теорию (эта вот задачка решается в уме минут за 5 если вспомнить что к чему) и способен он в конце концов решать поставленные задачу вместо вот этого вот бухтения "а зачем это? да кому это нужно?". Более того, эта задача расчитана, возможно, также на то, что если ты все-таки забыл как там операторы работают и что когда присваивается (хотя ей Богу не могу себе представить человека, которому трудно это решить) — то тогда можно посмотреть как вы справляетесь с этим косяком — будете ли вы спрашивать / гуглить / ватевер. Ну, то есть, когда вам зрение проверяют на буквах, это еще не означает, что доктор долбан, потому что заставляет читать не рассказы Чехова, а какие-то никому не нужные буковки.
Мне эта задача тоже не оч, просто потому, что никакого финта ушами там делать не нужно. Вот могу подкинуть парочку тоже ориентированных на синтаксис JS:
1) В голове посчитать результат:
120 + 102 + 012 + 002 + .12 + (0,1 + 2,3)
2) Что будет в "х"?
let i
for (i = 0; i++; i < 5) {
i = i + 3
}
const x = i
Да-да, это не про солид и дядю Боба, это просто синтаксис.
Отличная работа! Сам занимаюсь многопоточными приложениями в ноде, тоже пытался решать метрики потоков, но отложилось "на потом". Поковыраюсь в вашей либе в свободное время.
Как раз сейчас создаю инфраструктуру с использованием RMQ. До этого момента вообще не имел представления как оно работает и зачем. Большое спасибо, написано все просто отлично: доступно, детально, кратко и по делу.
Я хоть и не Cpp джедай, но, тем не менее, прочитал статью с интересом. Не обращайте внимания на такие вот скользкие комментарии. Как вы правильно сказали, там даже аргументации толковой нет. Специалист себя так не ведет. А вы - большой молодец! QuickJS, кстати, использует редактор Figma (скомпилированный в WASM) для своей плагин-системы.
Щас как расскажу вам тайну!
Короче в Node.js есть еще приватный консоль-лог. Это
process._rawDebug. Разница сconsole.logв том, что приватная версия не триггерит никаких асинхронных апишек. Вот например можно разницу увидеть в использованииasync_hooks:Я люблю тайпскрипт, но этот пропоузал какой-то бред, кмк. Вводить "типы как комментарии" только чтобы не компилить TS - какой-то абсурд. Либо вводить типы как типы, либо ничего не менять. Завтра фейсбук скажет - давайте синтаксис JSX введем нативно, нам так хочется.
Не читал (по скольку знаю), но отметил, что неплохо было бы указать адрес на http://latentflip.com/loupe/ (с ваших же скриншотов)
Добавил в закладки, обязательно позже прочитаю.
Вот это приятный разговор. Вообще, Игорь, хотел бы выразить благодарность за усердие и статьи, хоть некоторые из них, конечно, не достаточно полны/компетентны. Но, как говорится, не ошибается тот, кто ничего не делает, поэтому еще раз спасибо и продолжайте в том же духе!
Пожалуй единственный фреймворк, который кроме "мой синтаксис лучше - это ж очевидно" приносит реальное решение реальных проблем так это Крэнк. На данный момент, это, имо, самый трезвый подход к решению веба. https://crank.js.org/blog/introducing-crank
Спасибо за интересный ресерч и имплементацию!
npms.io
Можно ссылки, пожалуйста? Хочу почитать, интересно.
Я не знаком в деталях с работой Роберта Хогарта, но помимо вашего объяснения в статье мне кажется тут можно трактовать это еще и другим образом. В статье вы пишите, грубо говоря, "не знаешь — не понимаешь". Но еще есть один любопытный эффект — это когда как раз незнание чего-либо освобождает тебя от "оков" полета мысли. То есть, грубо говоря, какие-нибудь фантастические штуки, которые выдумывают писатели (гумманитарии, в первую очередь) в книгах — возможно не пришли бы в голову как концепт технарям-ученым, которые знают область гораздо глубже. Почему? Потому что часто некоторые вещи нам могут показаться нереально сложными или вообще невозможными, но это может быть поверхностным суждением, иногда стоит попробовать "плясать от результата". Поэтому когда не-программист говорит "я хочу то-то и то-то" — иногда это может не укладываться в наш программистский мозг, но это не проблема заказчика, а проблема рамок нашего мозга.
Тот момент, когда думаешь, что заголовок статьи перевели не правильно, и что, скорее всего, в оригинале написано что-то типа "… нейтив аппс" и проверяешь:
Что в переводе значит:
Диалекты регулярок, во-первых, очень похожи или часто даже практически одинаковы. Во-вторых, один раз поняв их синтаксис — вы убъете гораздо больше зайцев, чем если будете разбираться со всеми возможными апишками билдеров в разных языках и местах системы.
Про доверие — в обоих сценариях вы не пишете императивную программу с нуля и не двигаете байты в памяти. Вы все равно перепоручаете кому-то эту задачу. Только одно дело вы это поручите кому-то, кто это делает больше 30 лет (при чем не один), а другое дело вы поручите эту задачу новоиспеченному продукту от одного человека.
Напомнило https://www.youtube.com/watch?v=jf9I04Oa-hU
Вам, автор, все время хочется писать велосипеды. Которые, с вашей точки зрения, гораздо лучше. Ведь они синие и трехколесные. С трехколесного упасть сложнее, чем с двухколесного! А синий цвет — вызывает доверие по теории цветов, если я не ошибаюсь. И хорошо бы, если бы вы свои велосипеды так и преподносили остальным: с них труднее упасть и они вызывают доверие. Но вы часто пишите свои поделки с таким посылом: все велосипеды, кроме моих, это лютая шляпа. Никому не нужны двухколесные, горные и прочие другие. Есть мои и все.
Я не очень хочу уходить в дискуссию регулярок, но регулярки совсем не сложные. Их синтаксис можно выучить за то же самое время, что и синтаксис любой библиотеки, идущей им на замену. Они гораздо гибче и дают нейтив интеграцию в большинстве мест, где они уместны. А количество человеко-часов, потраченное на написание компиляторов регулярок гораздо больше, чем у альтернатив, из чего следует, что места, которые можно оптимизировать, оптимизированны в большинстве своем. Да, можно написать регулярку, которая убъет программу — есть такие вот сложные для исполнения номера. Но обычно это объясняется большой вариативностью и решить такое — не проблема регулярок конкретно, а проблема вообще.
Ваше желание упростить работу с регулярками я бы направил на создание не генератора, а дебаггера или хотя бы хайлайтера какого-то. Короче чтобы эти вот длинные регулярки не пугали, а можно было бы просто закинуть в какой-то редактор и посмотреть где там группа, где там квантификатор и прочее.
Потратив пару дней на изучение регулярок и много лет применяя их в практике я не имею ни малейшего желания:
1) зачем то что-то стороннее внедрять в свои проекты
2) учить новый синтаксис
3) доверять библиотеке парсинг (это, на секундочку, не шутки — если у вас там где то дырка в билдере, вы можете очень просто создать дыру безопасности)
4) верить, что все это будет быстрее или хотя бы на уровне регулярок
Поэтому, мне не понятно — зачем это все. Как пет-проект для саморазвития — отличная затея! Но чтобы это вот на серьезе выкладывать и говорить, что регулярки это не ок — вы серьезно?
Все, кто тут пишут про "если у них такой код — в баню такую контору" — может стоит иногда подумать, что не все в жизни может быть так прямолинейно?
Ну, то есть, есть категория задач на более практическое применение ваших знаний — например, написать какую-то ту-душку или еще что-нибудь в этом роде. Но есть и такие, где работодатель хочет "пощупать" будущего сотрудника и за другие его качества: знает ли он банальнейшую теорию (эта вот задачка решается в уме минут за 5 если вспомнить что к чему) и способен он в конце концов решать поставленные задачу вместо вот этого вот бухтения "а зачем это? да кому это нужно?". Более того, эта задача расчитана, возможно, также на то, что если ты все-таки забыл как там операторы работают и что когда присваивается (хотя ей Богу не могу себе представить человека, которому трудно это решить) — то тогда можно посмотреть как вы справляетесь с этим косяком — будете ли вы спрашивать / гуглить / ватевер. Ну, то есть, когда вам зрение проверяют на буквах, это еще не означает, что доктор долбан, потому что заставляет читать не рассказы Чехова, а какие-то никому не нужные буковки.
Мне эта задача тоже не оч, просто потому, что никакого финта ушами там делать не нужно. Вот могу подкинуть парочку тоже ориентированных на синтаксис JS:
1) В голове посчитать результат:
2) Что будет в "х"?
Да-да, это не про солид и дядю Боба, это просто синтаксис.
Отличная работа! Сам занимаюсь многопоточными приложениями в ноде, тоже пытался решать метрики потоков, но отложилось "на потом". Поковыраюсь в вашей либе в свободное время.
Очень понравился канал на ютубе. Видно, что делаешь качественно и с душой. Желаю успехов!
Как раз сейчас создаю инфраструктуру с использованием RMQ. До этого момента вообще не имел представления как оно работает и зачем. Большое спасибо, написано все просто отлично: доступно, детально, кратко и по делу.
FlatBuffers, например, использует Figma для своих данных.
Ага.