Я недавно задумался, что если какая-то внеземная цивилизация появилась на планете, где гравитация сильно ниже чем у нас. То ведь им гораздо проще начать осваивать космос, покорять другие планеты. Трудозатраты на вывод полезного груза сильно меньше, чем у нас.
Думаю вы правы. Я в большом городе живу и смог попасть на прием к офтальмологу с нужным профилем и заказать призматические очки. Если вам важно цены сравнить - линзы у меня в очках: Extesa 1.67 UV TECH IRON. За очки я где-то 700-750 долларов отдал.
Но ключевой момент - надо знать к кому попасть. А с этим была проблема целый год. Я ведь к офтальмологам и неврологам не в поликлинику по месту жительства ходил - а к специалистам с опытом в хорошие частные клиники.
Ваша история - ещё более драматичная иллюстрация той же системной проблемы. Три года - это даже больше моего года, и с куда более конкретным симптомом: тройное изображение светофора - это не «буквы иногда подпрыгивают», это воспроизводимая, понятная жалоба. И всё равно «всё в норме».
Сразу подчеркну - что я не врач, а скорее инженерный подход применил к поиску решения и описал его в статье. Но на основе моего опыта: ваш случай - отличная иллюстрация статьи.
Наклон головы - это компенсаторный механизм, мозг нашёл способ «обмануть» систему, изменив геометрию. То, что вы натренировались удерживать сведение при ночной езде - это тоже компенсация, но уже мышечная. По сути вы годами делаете то, что призмы делают за вас оптически.
Теперь про ваш главный вопрос. Призмы - это именно компенсация, а не коррекция. Они не исправляют положение глаз, как брекеты исправляют зубы. Они сдвигают изображение так, чтобы мышцам не приходилось тратить усилие на совмещение. Снял очки - всё вернулось как было.
Но есть нюанс. Тренировки на синоптофоре - это уже ближе к «брекетам», хотя и с оговорками. Они увеличивают фузионный резерв - то есть расширяют тот самый «бак мопеда» из статьи. Но тут надо смотреть, а по какой оси нужна компенсация. Если по горизонтали - то ее легко прокачать. А если по вертикали - то практически невозможно. Но все равно это позволит без постоянного надрыва мозга использовать глаза.
У вас, судя по описанию, резервы и так неплохие (раз натренировались держать сведение) - возможно, синоптофор даст ещё запас.
Но все равно призматические очки кардинально снизят нагрузку на мозг. Вы себя просто комфортнее будете чувствовать.
Переоцениваете вы меня. Мне до openclaw далеко. Я только-только учусь структурировать мысли - решил по этому поводу статью написать. А "товарищ майор" - это мем, не принимайте близко к сердцу :)
Если бы комментарии писал ИИ - он бы не признался, что у него есть сложности с другими языками, типа Haskell. У него слишком высоки репутационные риски. Кто им будет пользоваться - после таких заявлений?
Спасибо за объяснение! Вы как раз подтверждаете мою мысль — для вас это «всё просто», и я верю. Но в вашем объяснении уже есть «монада», «bind», «>>=», «unsafePerformIO» и «упаковка значений». Для обычного разработчика, который хочет напечатать строку в консоль, это пять новых концепций до первого результата. В Gleam это io.println("hello") — и готово.
Scala не рассматривал, честно. Она мощная, но для side-проекта мне был важен минимальный порог входа. Gleam можно выучить за выходные — у Scala порог существенно выше, особенно если до этого не был в JVM-мире.
Да для примера. Но мне кажется, тут не нарушение DRY, а два разных уровня абстракции. is_premium — это предикат. premium_group — это результат применения предиката к конкретному набору. Они не дублируют друг друга — они на разных этажах.
Да, разворачивается именно так. И вы правы — для строки x.trim().uppercase().append("!") читается лучше. Но в этом и суть: method chaining работает, пока все методы принадлежат одному объекту. Как только нужно протащить данные через функции из разных модулей — parse_request, потом handle_input, потом response.build — методы кончаются, а пайп продолжает работать.
В Gleam нет методов и нет this — функции принадлежат модулям, а не данным. Поэтому string.trim(x) вместо x.trim(). Пайп компенсирует отсутствие методов — и делает это универсально, потому что работает с любой функцией, а не только с методами одного типа.
Кстати, ваша идея про разветвление после filter — это по сути то, что в ФП делается через let. Не промежуточные переменные в императивном смысле, а именованные привязки:
let filtered = items |> list.filter(is_active)
let group_a = filtered |> list.filter(is_premium)
let group_b = filtered |> list.filter(fn(x) { !is_premium(x) })
Пайп не пытается заменить всё — он для линейных цепочек. Когда поток разветвляется — let и отдельные пайпы.
Про Rust — согласен, что он мощнее как язык. Но для моей задачи (голосовой навык, FSM, Redis, конкурентные сессии) его сила избыточна, а BEAM под капотом Gleam даёт модель конкурентности, которой в Rust нет из коробки — лёгкие процессы, изоляция ошибок, supervision trees. Это не про синтаксис, а про рантайм.
Про Go — я в основном занимаюсь архитектурой, кода пишу мало. Go в нашем стеке — не мой личный выбор, а стандарт, который выбирает компания. И его выбирают именно за то, за что вы его критикуете — он простой, предсказуемый, любой новый разработчик входит в проект за короткий срок. Для команд в 10-50 человек это перевешивает элегантность. Отвращение к Go я понимаю, сам в статье написал про бесконечные «if err != nil» — но архитектурные решения принимаются не по ощущениям одного человека, а по стоимости поддержки для всей команды.
Дебаг. Встроенное ключевое слово echo — вставляешь в любое место пайпа, оно пропускает значение через себя и печатает в stderr с указанием файла и строки:
[1, 2, 3]
|> list.map(fn(x) { x + 1 })
|> echo
|> list.map(fn(x) { x * 2 })
Билд-тул предупредит, если забудете убрать перед публикацией. Есть ещё io.debug — делает то же самое, но без метаданных.
Боевое логирование. Пакет logging — обёртка над Erlang logger. Уровни, форматирование, всё стандартно. Есть glimt — более продвинутый, со структурированным JSON-выводом и контекстами.
Я недавно задумался, что если какая-то внеземная цивилизация появилась на планете, где гравитация сильно ниже чем у нас. То ведь им гораздо проще начать осваивать космос, покорять другие планеты. Трудозатраты на вывод полезного груза сильно меньше, чем у нас.
Да. Кажется что МКС где-то высоко и далеко, а фактически 400 с небольшим километров над нами. Не сильно и далеко.
Выборка слишком маленькая. Мог и стресс в полете повлиять на удлинение теломер.
Все живое на Земле столько лет вместе с ней развивалось и эволюционировало. Поэтому тут все закономерно.
У меня такой же вопрос возник. А не могли ли пациента стукнуть хорошенько перед лечением, чтобы лечение он выдержал?
Думаю вы правы. Я в большом городе живу и смог попасть на прием к офтальмологу с нужным профилем и заказать призматические очки. Если вам важно цены сравнить - линзы у меня в очках: Extesa 1.67 UV TECH IRON. За очки я где-то 700-750 долларов отдал.
Но ключевой момент - надо знать к кому попасть. А с этим была проблема целый год. Я ведь к офтальмологам и неврологам не в поликлинику по месту жительства ходил - а к специалистам с опытом в хорошие частные клиники.
Ваша история - ещё более драматичная иллюстрация той же системной проблемы. Три года - это даже больше моего года, и с куда более конкретным симптомом: тройное изображение светофора - это не «буквы иногда подпрыгивают», это воспроизводимая, понятная жалоба. И всё равно «всё в норме».
Сразу подчеркну - что я не врач, а скорее инженерный подход применил к поиску решения и описал его в статье. Но на основе моего опыта: ваш случай - отличная иллюстрация статьи.
Наклон головы - это компенсаторный механизм, мозг нашёл способ «обмануть» систему, изменив геометрию. То, что вы натренировались удерживать сведение при ночной езде - это тоже компенсация, но уже мышечная. По сути вы годами делаете то, что призмы делают за вас оптически.
Теперь про ваш главный вопрос. Призмы - это именно компенсация, а не коррекция. Они не исправляют положение глаз, как брекеты исправляют зубы. Они сдвигают изображение так, чтобы мышцам не приходилось тратить усилие на совмещение. Снял очки - всё вернулось как было.
Но есть нюанс. Тренировки на синоптофоре - это уже ближе к «брекетам», хотя и с оговорками. Они увеличивают фузионный резерв - то есть расширяют тот самый «бак мопеда» из статьи. Но тут надо смотреть, а по какой оси нужна компенсация. Если по горизонтали - то ее легко прокачать. А если по вертикали - то практически невозможно. Но все равно это позволит без постоянного надрыва мозга использовать глаза.
У вас, судя по описанию, резервы и так неплохие (раз натренировались держать сведение) - возможно, синоптофор даст ещё запас.
Но все равно призматические очки кардинально снизят нагрузку на мозг. Вы себя просто комфортнее будете чувствовать.
Потому что на длинные тире закончились токены :)
Тут я пас - фронтенд не моя специализация. Но идея у вас звучит как интересная тема для отдельной статьи.
Переоцениваете вы меня. Мне до openclaw далеко. Я только-только учусь структурировать мысли - решил по этому поводу статью написать. А "товарищ майор" - это мем, не принимайте близко к сердцу :)
Если бы комментарии писал ИИ - он бы не признался, что у него есть сложности с другими языками, типа Haskell. У него слишком высоки репутационные риски. Кто им будет пользоваться - после таких заявлений?
Так точно, товарищ майор))
Спасибо за объяснение! Вы как раз подтверждаете мою мысль — для вас это «всё просто», и я верю. Но в вашем объяснении уже есть «монада», «bind», «>>=», «unsafePerformIO» и «упаковка значений». Для обычного разработчика, который хочет напечатать строку в консоль, это пять новых концепций до первого результата. В Gleam это
io.println("hello")— и готово.Scala не рассматривал, честно. Она мощная, но для side-проекта мне был важен минимальный порог входа. Gleam можно выучить за выходные — у Scala порог существенно выше, особенно если до этого не был в JVM-мире.
Да для примера. Но мне кажется, тут не нарушение DRY, а два разных уровня абстракции.
is_premium— это предикат.premium_group— это результат применения предиката к конкретному набору. Они не дублируют друг друга — они на разных этажах.Да, разворачивается именно так. И вы правы — для строки
x.trim().uppercase().append("!")читается лучше. Но в этом и суть: method chaining работает, пока все методы принадлежат одному объекту. Как только нужно протащить данные через функции из разных модулей —parse_request, потомhandle_input, потомresponse.build— методы кончаются, а пайп продолжает работать.В Gleam нет методов и нет
this— функции принадлежат модулям, а не данным. Поэтомуstring.trim(x)вместоx.trim(). Пайп компенсирует отсутствие методов — и делает это универсально, потому что работает с любой функцией, а не только с методами одного типа.Кстати, ваша идея про разветвление после filter — это по сути то, что в ФП делается через
let. Не промежуточные переменные в императивном смысле, а именованные привязки:Пайп не пытается заменить всё — он для линейных цепочек. Когда поток разветвляется — let и отдельные пайпы.
Интересная ниша — язык как инструмент доказательства, а не только разработки. С Lean не работал. Ждем от вас статью про него))
Про Rust — согласен, что он мощнее как язык. Но для моей задачи (голосовой навык, FSM, Redis, конкурентные сессии) его сила избыточна, а BEAM под капотом Gleam даёт модель конкурентности, которой в Rust нет из коробки — лёгкие процессы, изоляция ошибок, supervision trees. Это не про синтаксис, а про рантайм.
Про Go — я в основном занимаюсь архитектурой, кода пишу мало. Go в нашем стеке — не мой личный выбор, а стандарт, который выбирает компания. И его выбирают именно за то, за что вы его критикуете — он простой, предсказуемый, любой новый разработчик входит в проект за короткий срок. Для команд в 10-50 человек это перевешивает элегантность. Отвращение к Go я понимаю, сам в статье написал про бесконечные «if err != nil» — но архитектурные решения принимаются не по ощущениям одного человека, а по стоимости поддержки для всей команды.
Спасибо! Постараюсь подготовить интересный материал.
Логирование в Gleam можно условно разделить так:
Дебаг. Встроенное ключевое слово
echo— вставляешь в любое место пайпа, оно пропускает значение через себя и печатает в stderr с указанием файла и строки:Билд-тул предупредит, если забудете убрать перед публикацией. Есть ещё
io.debug— делает то же самое, но без метаданных.Боевое логирование. Пакет
logging— обёртка над Erlang logger. Уровни, форматирование, всё стандартно. Естьglimt— более продвинутый, со структурированным JSON-выводом и контекстами.