они не сохранят культуру, а просто станут отдельной локальной веткой. Чтобы оставаться живым источником, всё равно придётся взаимодействовать с основной популяцией: учиться, читать, спорить.
Так и остальная группа тоже не сохранит. Культура вообще передается только при живом общении. Как говорил один мой коллега: "Яблоки рождаются от яблони, а физики от физиков", это о важности научных школ. Но то же и всех остальных школ касается. И вот мы уже видим, как сначала учителя заменил гугл, а теперь уже LLM заменяет и сам гугл. Культура уже теряется.
Отличная статья, сформулировано то, что я сам пытался для себя сформулировать. Тут есть еще один аспект -- ИИ является слепком не самого нашего общества, а слепком интернета, в основном, плюс еще некоторого количества книг, то есть материального воплощения культуры. То есть уже является слепком слепка. И проблема возникла еще до появления LLM. Вы знаете, что далеко не все цвета, которые может различать глаз, раскладываются в RGB? Есть целая палитра, в основном, голубые и пурпурные цвета, которые никакой монитор не может отобразить. Дети, познающие мир через компьютер, никогда их не видели и даже не подозревают о существовании таких цветов. Точно так же есть целый пласт культуры, передающейся лично, не фиксируемой в книгах и не попадающей в интернет. Как раз всё то, что относится к методам и подходам, личному примеру, навыкам. В интернет попадает выжимка, результаты, а не то, как к ним приходишь, все неудачные попытки отбрасываются и не записываются. И результаты уже давно видны, молодежь не понимает, как браться за задачи, кроме типовых.
Мне кажется, спасти ситуацию могут "новые амиши" -- сообщество тех, кто принципиально не пользуется LLM, интернет используют как справочник, много общаются между собой напрямую и обсуждают решение своих задач и проблем.
Оно будет допиливаться, конечно. Но вопрос в том, когда именно выяснится, что код нуждается в допиливании и какого масштаба катастрофа привлечет к этому внимание.
В других языках скобок не сильно меньше, просто они расставлены по-другому. Визуально вид лиспового кода может напугать новичка, конечно, но если рельно начинаешь с ним работать, то сразу понимаешь, насколько это удобно. Любой вызов функции, например, это выражение в скобках, где первое это имя (на самом деле не совсем имя, но для простоты можем считать так) функции и остальные элементы -- ее параметры. Например (sin x) -- это аналог sin(x) в C или Питоне (кстати, подсчитайте количество скобок там и тут). А вот сложение нескольких чисел: (+ a b c), аналогом в C будет a+b+c. Да, тут на пару скобок меньше. Зато для сложных выражений надо в памяти держать приоритеты операторов или, омг, тоже добавить скобки. А теперь смотрите -- в Лисп и sin и + это одно и то же, просто вызов функции, работа с ними абсолютно одинакова. Если у вас есть список чисел в переменной x и вы хотите получить их сумму, вы просто пишете: (apply #'+ x) -- подставить список значений x в функцию +, в C или Питоне для этого придется писать цикл. И вот таких трюков в Лиспе множество, многие из них возможны благодаря "скобочному синтаксису".
А теперь о главном, зачем в Лисп скобки. Скобками обозначаются списки, то есть (+ a b c)это просто список из символа + и символов a, b, c. Его можно сформировать программно и выполнить через eval, например. То есть код, сама выполняемая программа, может создаваться "на лету", программно, поскольку это просто список из символов, чисел и других списков. И вот эта концепция "код как данные" делает Лисп на две головы выше остальных языков программирования, позволяет (безопасно и удобно) писать само-модифицирующиеся программы, создавать DSL -- специализированные мини-языки для прикладных задач, да и просто многократно сокращает количество кода, который нужно писать руками, ревьюить и поддерживать. При этом большинство Лиспов это компиляторы, то есть вы можете создать код программно, превратить его в машинные инструкции и вызывать его, прямо на лету, во время исполнения программы.
Лисп сильно недооценен, сейчас это, по сути, самый развитый язык программирования на планете. Просто порог вхождения высокий и новички его боятся из-за непривычных концепций и синтаксиса.
Есть один маленький нюанс, о котором надо помнить: как минимум FF вызывает коллбэки блобов (как минимум, при загрузке файлов) не в основном потоке, так что могут быть ситуации гонки и весьма неочевидные глюки, связанные с этим. Хорошая практика -- в коллбэке загрузки файла вызывать setTimeout и уже в его коллбэке уже выполнять код.
А, убунта, это многое объясняет) Ок, я сформулирую тезис по-другому: в случае с crontab можно обойтись одним файлом, причем большинство так и делает, потому что это удобно. В случае с systemd придется иметь дело с россыпью файлов, по синтаксису которых придется вдумчиво читать маны.
Скрипт/параметры, как это ни назови, удобнее не станет. Зачем пихать bash -c? Ну вот автору статьи пришлось это сделать, видимо, альтернатива в виде уже ДВУХ файлов даже ему показалась отвратительной)
В докер-контейнере нет системы инициализации, там первый процесс, он же рабочий. И это отлично. Но иногда процесс запуска демона не очень тривиален и одним простым CMD тут не отделаешься. В случае init всё просто, внутри докер-контейнера можно просто делать service start и дальше бесконечный скрипт со sleep/check. В случае, если у программы уже нет init, а есть только systemd, то ты попал.
Кому-то очевидный, но мне нет. В crontab вообще нет синтаксиса, по сути, там по-дефолту в шапке в комментариях описан весь синтаксис, помещается.
Несколько crontab может быть только у разных юзеров, но для юзеров квотирование делается отдельно, это не является проблемой. Для root crontab один.
Ну а bash -c это просто вишенка на торте. Развесистый, многострочный скрипт, в котором под самую важную часть отдана одна строка [facepalm.jpg]
А про "запускать в docker в принципе не надо" -- если для вас это аргумент, то вы так же должны принять аргумент, что systemd в системе запускать в принципе не надо, тот же уровень аргументации.
Всё это хорошо, но подумайте вот о чем -- вместо одной (!) строки в crontab теперь нужно писать целый файл с неочевидным синтаксисом и CamelCase директивами вида ExecCondition. Кто это придумал?! При этом в самом файле мы видим, омг, bash -c со всеми вытекающими, то есть однострочный bash-код, прямо как в crontab. Но в crontab это простительно, там все директивы однострочные, но тут-то целый файл в нашем распоряжении!
Когда вы редактируете crontab, у вас перед глазами сразу все задачи, выполняемые по расписанию, вы видите, когда что запускается и можете распланировать тяжелые задачи так, чтобы они не мешали друг другу. В случае systemd у вас россыпь файлов в каждый из которых нужно заглянуть отдельно, чтобы понять, что когда запустится.
Ну и, конечно, тот, кто не пытался заставить systemd (а от него уже многие приложения зависят) работать в docker-контейнете, тот еще не начинал ненавидеть systemd по-настоящему.
Как я понял, там есть какой-то электронный блок, который обрабатывает датчики и потом посылает пакет по пропиетарной шине на управляющий комп. Подключите логический анализатор с записью к шине, потом (самая приятная часть работы) просто играете в болулинг, записывая на бумажке сколько кеглей сбито каждым броском. Под конец рабочего дня, усталые, но довольные, снимаете запись логического анализатора и ищете повторяющиеся пакеты (или какая-то часть в них будет повторяться) и сверяете с бумажными записями о количестве кеглей. Если найдете совпадение, то есть, скажем, для трех кеглей 7-й байт в пакете всегда был 3, а для 2-х кеглей 2, то всё, задача решена. Ставите на шину простое устройство, которое только слушает, оно ловит пакеты, выбирает 7-й байт и шлет пуши в телефон клиента. Но, разумеется, для отладки и тестирования нужно будет еще 2-3 дня поиграть всей командой!
Изначально этот проект с летающей водокачкой выглядел спорно. Вряд ли Starship вообще сможет выйти на орбиту и пережить возвращение, это я как заядлый игрок в KPS говорю :)
Проблема с помойками в том, что сами по себе они только разрастаются. Через некоторое время и AI станет уже бессилен. И он сам же приложит к этому свою металлическую руку :)
Еще, наверное, многие не знают, что команда
rmможет удалять данные :)Так и остальная группа тоже не сохранит. Культура вообще передается только при живом общении. Как говорил один мой коллега: "Яблоки рождаются от яблони, а физики от физиков", это о важности научных школ. Но то же и всех остальных школ касается. И вот мы уже видим, как сначала учителя заменил гугл, а теперь уже LLM заменяет и сам гугл. Культура уже теряется.
Отличная статья, сформулировано то, что я сам пытался для себя сформулировать. Тут есть еще один аспект -- ИИ является слепком не самого нашего общества, а слепком интернета, в основном, плюс еще некоторого количества книг, то есть материального воплощения культуры. То есть уже является слепком слепка. И проблема возникла еще до появления LLM. Вы знаете, что далеко не все цвета, которые может различать глаз, раскладываются в RGB? Есть целая палитра, в основном, голубые и пурпурные цвета, которые никакой монитор не может отобразить. Дети, познающие мир через компьютер, никогда их не видели и даже не подозревают о существовании таких цветов. Точно так же есть целый пласт культуры, передающейся лично, не фиксируемой в книгах и не попадающей в интернет. Как раз всё то, что относится к методам и подходам, личному примеру, навыкам. В интернет попадает выжимка, результаты, а не то, как к ним приходишь, все неудачные попытки отбрасываются и не записываются. И результаты уже давно видны, молодежь не понимает, как браться за задачи, кроме типовых.
Мне кажется, спасти ситуацию могут "новые амиши" -- сообщество тех, кто принципиально не пользуется LLM, интернет используют как справочник, много общаются между собой напрямую и обсуждают решение своих задач и проблем.
Оно будет допиливаться, конечно. Но вопрос в том, когда именно выяснится, что код нуждается в допиливании и какого масштаба катастрофа привлечет к этому внимание.
Да, всё, в чем ты не разбираешься, нейронка делает хорошо. Но вот то, в чем ты что-нибудь понимаешь, она всегда делает плохо)
Зачитывался в детстве Снеговым. Но это, по сути, фэнтези, замаскированное под НФ)
В других языках скобок не сильно меньше, просто они расставлены по-другому. Визуально вид лиспового кода может напугать новичка, конечно, но если рельно начинаешь с ним работать, то сразу понимаешь, насколько это удобно. Любой вызов функции, например, это выражение в скобках, где первое это имя (на самом деле не совсем имя, но для простоты можем считать так) функции и остальные элементы -- ее параметры. Например
(sin x)-- это аналогsin(x)в C или Питоне (кстати, подсчитайте количество скобок там и тут). А вот сложение нескольких чисел:(+ a b c), аналогом в C будетa+b+c. Да, тут на пару скобок меньше. Зато для сложных выражений надо в памяти держать приоритеты операторов или, омг, тоже добавить скобки. А теперь смотрите -- в Лисп иsinи+это одно и то же, просто вызов функции, работа с ними абсолютно одинакова. Если у вас есть список чисел в переменнойxи вы хотите получить их сумму, вы просто пишете:(apply #'+ x)-- подставить список значенийxв функцию+, в C или Питоне для этого придется писать цикл. И вот таких трюков в Лиспе множество, многие из них возможны благодаря "скобочному синтаксису".А теперь о главном, зачем в Лисп скобки. Скобками обозначаются списки, то есть
(+ a b c)это просто список из символа+и символовa,b,c. Его можно сформировать программно и выполнить черезeval, например. То есть код, сама выполняемая программа, может создаваться "на лету", программно, поскольку это просто список из символов, чисел и других списков. И вот эта концепция "код как данные" делает Лисп на две головы выше остальных языков программирования, позволяет (безопасно и удобно) писать само-модифицирующиеся программы, создавать DSL -- специализированные мини-языки для прикладных задач, да и просто многократно сокращает количество кода, который нужно писать руками, ревьюить и поддерживать. При этом большинство Лиспов это компиляторы, то есть вы можете создать код программно, превратить его в машинные инструкции и вызывать его, прямо на лету, во время исполнения программы.Лисп сильно недооценен, сейчас это, по сути, самый развитый язык программирования на планете. Просто порог вхождения высокий и новички его боятся из-за непривычных концепций и синтаксиса.
А вот это уже настолько религиозно-фанатичный, по сути, аргумент, что я, пожалуй, не рискну возражать))
Не нужно говорить за всех. И, тем более, не нужно за всех решать.
Есть один маленький нюанс, о котором надо помнить: как минимум FF вызывает коллбэки блобов (как минимум, при загрузке файлов) не в основном потоке, так что могут быть ситуации гонки и весьма неочевидные глюки, связанные с этим. Хорошая практика -- в коллбэке загрузки файла вызывать
setTimeoutи уже в его коллбэке уже выполнять код.Вкусовщина, это прекрасно, пока чью-то вкусовщину не пытаются навязать другим. Увы, с systemd (а также с rust) происходит именно это.
А, убунта, это многое объясняет) Ок, я сформулирую тезис по-другому: в случае с crontab можно обойтись одним файлом, причем большинство так и делает, потому что это удобно. В случае с systemd придется иметь дело с россыпью файлов, по синтаксису которых придется вдумчиво читать маны.
Скрипт/параметры, как это ни назови, удобнее не станет. Зачем пихать bash -c? Ну вот автору статьи пришлось это сделать, видимо, альтернатива в виде уже ДВУХ файлов даже ему показалась отвратительной)
В докер-контейнере нет системы инициализации, там первый процесс, он же рабочий. И это отлично. Но иногда процесс запуска демона не очень тривиален и одним простым CMD тут не отделаешься. В случае init всё просто, внутри докер-контейнера можно просто делать service start и дальше бесконечный скрипт со sleep/check. В случае, если у программы уже нет init, а есть только systemd, то ты попал.
Кому-то очевидный, но мне нет. В crontab вообще нет синтаксиса, по сути, там по-дефолту в шапке в комментариях описан весь синтаксис, помещается.
Несколько crontab может быть только у разных юзеров, но для юзеров квотирование делается отдельно, это не является проблемой. Для root crontab один.
Ну а bash -c это просто вишенка на торте. Развесистый, многострочный скрипт, в котором под самую важную часть отдана одна строка [facepalm.jpg]
А про "запускать в docker в принципе не надо" -- если для вас это аргумент, то вы так же должны принять аргумент, что systemd в системе запускать в принципе не надо, тот же уровень аргументации.
Я сталкивался с 1C, например.
[systemd hater mode on]
Всё это хорошо, но подумайте вот о чем -- вместо одной (!) строки в crontab теперь нужно писать целый файл с неочевидным синтаксисом и CamelCase директивами вида
ExecCondition. Кто это придумал?! При этом в самом файле мы видим, омг,bash -cсо всеми вытекающими, то есть однострочный bash-код, прямо как в crontab. Но в crontab это простительно, там все директивы однострочные, но тут-то целый файл в нашем распоряжении!Когда вы редактируете crontab, у вас перед глазами сразу все задачи, выполняемые по расписанию, вы видите, когда что запускается и можете распланировать тяжелые задачи так, чтобы они не мешали друг другу. В случае systemd у вас россыпь файлов в каждый из которых нужно заглянуть отдельно, чтобы понять, что когда запустится.
Ну и, конечно, тот, кто не пытался заставить systemd (а от него уже многие приложения зависят) работать в docker-контейнете, тот еще не начинал ненавидеть systemd по-настоящему.
[systemd hater mode off]
А считывать данные как? Ставить датчик Холла под каждую ячейку?
Как я понял, там есть какой-то электронный блок, который обрабатывает датчики и потом посылает пакет по пропиетарной шине на управляющий комп. Подключите логический анализатор с записью к шине, потом (самая приятная часть работы) просто играете в болулинг, записывая на бумажке сколько кеглей сбито каждым броском. Под конец рабочего дня, усталые, но довольные, снимаете запись логического анализатора и ищете повторяющиеся пакеты (или какая-то часть в них будет повторяться) и сверяете с бумажными записями о количестве кеглей. Если найдете совпадение, то есть, скажем, для трех кеглей 7-й байт в пакете всегда был 3, а для 2-х кеглей 2, то всё, задача решена. Ставите на шину простое устройство, которое только слушает, оно ловит пакеты, выбирает 7-й байт и шлет пуши в телефон клиента. Но, разумеется, для отладки и тестирования нужно будет еще 2-3 дня поиграть всей командой!
Суборбитальный полет и орбитальный это очень большая разница, в том числе по нагрузкам. Он развалился даже на суборбитальном.
Изначально этот проект с летающей водокачкой выглядел спорно. Вряд ли Starship вообще сможет выйти на орбиту и пережить возвращение, это я как заядлый игрок в KPS говорю :)
Проблема с помойками в том, что сами по себе они только разрастаются. Через некоторое время и AI станет уже бессилен. И он сам же приложит к этому свою металлическую руку :)