Редактирование программ "пока они работают"? Зачем?

В последнее время я получаю больше на Lisp и языки Lispy, и я нахожу их достаточно мощными.

Одна вещь, которую я читал по сети, - это то, что вы можете писать в Lisp, Clojure и т.д., что вы можете редактировать свою программу "во время ее работы".

Возможно, мне что-то не хватает, но в чем смысл?

Конечно, это может сэкономить несколько секунд, но это все? Всякий раз, когда я вношу изменения в свою программу, я просто останавливаю ее, а затем запускаю ее снова, и она работает отлично на протяжении десятилетий.

Должна быть причина, кроме экономии времени - что это такое?

Может ли кто-нибудь дать мне хорошее исследование, которое заставит меня слюнить эту функцию?:)

С нетерпением ждем слюни!

ОТВЕТЫ

Ответ 1

Есть несколько чрезвычайно полезных вариантов использования. Один пример - в графическом интерфейсе - я видел это во время разработки GUI-приложения в режиме реального времени, поскольку он работал рядом с моим Emacs: я добавил код для новой кнопки и нажал "Cc Cc", чтобы скомпилировать эту единственную функцию, и кнопка появилась в окне! Не нужно было закрывать и снова открывать приложение. Затем я начал настраивать виджеты и манипулировать макетом, и открытое окно мгновенно перегруппировалось - кнопки перемещались, новые текстовые поля просто появлялись бы и т.д., Как только я выполнял каждое небольшое изменение, которое я сделал.

Еще один пример - отличный обзор о Clojure библиотеке OpenGL "Penumbra", где программист создает 3D-игру тетриса в режиме реального времени. Он начинает с пустого окна OpenGL рядом с его emacs. Он определяет объект куба - C-M-x - и он на экране. Выполняет команду, чтобы повернуть его, сразу же начинает вращаться. Запускает цикл, определяющий еще 5 кубов в разных местах, pop-pop-pop-pop-pop-pop они появляются. Все это мгновенно реагирует, полный инструментарий OpenGL прямо здесь, чтобы играть. Добавьте текстуру поверхности в свой куб и сразу увидите, как она появляется. Он становится гибким 3D-миром - код динамически изменяет существующий мир, а не закрывает и снова открывает трехмерный холст с каждым изменением.

Penumbra Livecoding Screencast - скачайте HD версию для лучшего опыта.

Существует также отличная презентация/скринкаст об аудио-библиотеке "Overtone" для Clojure. Библиотека представляет собой набор инструментов синтезатора, в котором у вас есть набор функций синтезатора для управления звуковой волной. Во время презентации разработчик записывает немного кода, который начинает воспроизводить тон. Затем он проводит десять секунд, записывая цикл, который воспроизводит этот звук 10 раз, но каждый раз увеличивает частоту, и снова C-M-x, и вы слышите его, ноты поднимаются выше. В течение 20 минут в режиме реального времени он получает песню. Это похоже на массу удовольствия.

Overtone Presentation Link

Другие виды использования были бы, например: веб-сканирование/интеллектуальный анализ данных - разрабатывать и совершенствовать алгоритмы для извлечения информации в реальном времени, видя данные, возвращаемые на каждом шаге; Программирование робототехники - отправка команд роботу во время его жизни; Распознавание лиц/изображений - с помощью библиотеки, такой как OpenCV, следите, чтобы ваши изменения мгновенно обновляли то, что библиотека распознает в изображении/видео, когда вы разрабатываете код; Работа математики (Clojure имеет "Incanter" для статистики); и в любой среде, где вы хотите сразу увидеть, какое влияние ваши изменения оказали на данные, с которыми вы работаете.

Итак, самый забавный аспект наличия REPL перед вами. Вещи, которые не были ощутимыми, послушными, интерактивными, начинают становиться. Дизайн графического интерфейса, 3D-графика, программное производство звука, извлечение и преобразование данных, эти вещи обычно выполнялись на расстоянии руки. Но с Clojure (и в некоторой степени с другими динамическими языками тоже) это стало действительно ощутимым и немедленным; вы видите каждое изменение, как только вы пишете код, и если что-то не работает или вы не получите результат, которого вы ожидали, вы просто измените то, что вы пропустили, и немедленно запустите его.

Clojure очень подходит для этого. Удивительно, что вы можете использовать библиотеки Java в режиме реального времени одинаково - несмотря на то, что сама Java не может! Таким образом, Overtone использует библиотеку synth Java в реальном времени, несмотря на то, что вы никогда не могли в Java, Penumbra использует привязки Java OpenGL и т.д. Это объясняется тем, что Rich Hickey разработал Clojure, чтобы он мог скомпилировать байт-код JVM "на лету". Это удивительный язык - Clojure внес огромный вклад в невероятное удовольствие и продуктивное программирование.

Ответ 2

Должна быть причина, кроме экономии времени - что это такое?

Нет, нет. Я имею в виду, что никогда не бывает: вся причина использовать компьютер вообще - это сэкономить время. Ничто не может сделать компьютер, который вы не можете сделать вручную. Это займет немного больше времени.

В этом случае я бы не уволил "несколько секунд", учитывая, что это одна из вещей, которые я делаю чаще всего, весь день, всю свою карьеру программирования. Через несколько секунд для повторной компиляции, за несколько секунд до повторного запуска, несколько секунд, чтобы восстановить состояние, которое моя программа имела в предыдущее время - даже на быстрой рабочей станции, между итерациями может быть минута. (Раньше это было намного хуже, но более быстрое аппаратное обеспечение только делало его менее ужасным, а не хорошим. Перекомпилированные файлы в целом или хуже связаны с I/O-привязкой и, возможно, никогда не совпадают со скоростью более подробной компиляции.)

В Lisp перекомпиляция одной функции в уже запущенном процессе почти мгновенная (я никогда не видел ее даже 0,1 секунды даже на моем 5-летнем ноутбуке), и перезапуск означает, что я не должны воссоздать мое состояние, даже когда что-то сигнализирует.

Здесь инструмент, который дает мне более 100-кратное ускорение одной из самых медленных и самых распространенных вещей, которые я выполняю как программист. Я не знаю, что еще вам нужно. Вероятно, мы можем придумать некоторые причины, но если этого недостаточно, я не знаю, что будет. Эм, это тоже довольно круто?: -)

(* Всякий раз, когда кто-то говорит "никогда" о чем-то, что связано с технологией, этот человек неизменно заканчивается тем, что 2 года спустя выглядит полным придурком, и, несмотря на долговечность Lisp, я не исключаюсь.)

Ответ 3

Существует маркетинговый слоган для Lisp:

С Lisp и его инкрементным методом разработки стоимость изменения программного обеспечения зависит от размера изменения, а не от размера всего программного обеспечения.

Даже если у нас есть большая программная система, стоимость (время,...) для изменения остается в зависимости от размера изменения. Если мы добавим новый метод или изменим новый метод, усилия будут по-прежнему связаны с попыткой изменить метод, поэтапно скомпилировать метод и постепенно загрузить метод.

Во многих традиционных программных средах для изменения метода может потребоваться частичная перекомпиляция, новый связанный исполняемый файл, перезагрузка, перезагрузка и т.д. Чем больше программное обеспечение, тем дольше оно требуется.

Для человека это означает, что мы, возможно, выходим из состояния потока. Эта часть производительности хороших сред Lisp: за короткое время можно внести много изменений в программную систему, как только программист чувствует себя комфортно и входит в это состояние потока. Я думаю, многие испытали это, когда работа завершается за короткое время - против времени, когда один сидит перед системой, которая не отвечает, и мы сталкиваемся с временем ожидания.

Также между нами и программой, на которой мы работаем, мало когнитивной дистанции. Например, если вы редактируете класс в пакетной среде, вы должны представить, какое влияние оказывают изменения. В Lisp вы редактируете класс и одновременно изменяете сами объекты. Это означает, что вы изменяете поведение объектов напрямую, а не новую версию их после цикла пакетного редактирования-компиляции-ссылки-запуска-теста.

В системе Lisp вы меняете класс в CAD-системе, а затем можете сразу же активировать его. Когда люди спрашивают, работает ли Lisp для больших программных групп, ответ может заключаться в том, что большая команда разработчиков программного обеспечения не нужна, если вы работаете постепенно. Проблема тогда заключалась в том, что действительно хорошие опытные разработчики программного обеспечения, знакомые с постепенным развитием, были (редко?).

Во многих приложениях существует отдельный уровень языка сценариев, иногда для оригинальных разработчиков (а не для пользователей). В Lisp это необязательно, Lisp - это собственный язык расширения.

Ответ 4

В реальном мире это в основном используется в развитии, и, как и многие другие функции, его единственная ценность сводится к путанице в правильном контексте.

  • личный просветительский просветитель для программистов *
  • Истинное непрерывное развертывание.
  • нулевые запланированные простоя Соглашения об уровне обслуживания.
  • серверы отладки.

* не гарантия.

для меня, и я подозреваю, что некоторые другие здесь реальное преимущество этой REPL driven development заключается в том, что это может быть неописуемо весело. addictive even. Иногда это может дать смысл кода. дайте ему попробовать... приходите, попробуйте, сначала REPL всегда бесплатно:)

в настоящее время одна большая ничья - непрерывное развертывание.

В настоящее время идея непрерывного развертывания заключается в том, что вы меняете одну вещь, строите все (или упаковываете ее скорее), а затем развертываете. с моделью lisp на самом деле можно отредактировать развернутый (как правило, ящик, получающий зеркало реальных сеансов клиентов), когда он находится в развертывании.

просто педантичная нота. вы фактически не редактируете запущенные классы. вы скомпилируете новую копию класса и оставьте его в известном месте (var), затем в следующий раз, когда он будет использован, будет найдена и использована новая копия. его не действительно редактирование при запуске и больше похожее на новый код вступает в силу немедленно, это уменьшает объем процесса devlopment от программ до выражений (обычно это функции).

другой точкой слюни является идея получить bennefit из исправлений безопасности без необходимости объявлять время простоя. вы можете сделать обновление без него, что стоило бы вашему SLA любого из ваших драгоценных "запланированных простоев". Если вам нужно запланировать запланированный простоя за шесть месяцев вперед, и вы получите только два часа после этого (для этих бедных душ), это может действительно заставить их слюни.
Если у вас есть реплируемый доступ к вашему запущенному приложению, поскольку он развернут (потенциально (с разрешения) на сайте клиента), вы можете подключиться к приложению во время его запуска и выполнить тесты по существующему коду в существующем контексте без остановки и подключения отладчика. вы также не получите потери скорости от отладчика. Это возможно сделать с помощью REPL, хотя, когда вы получаете там реплику, вы можете легко создать новый код (некоторые скажут, что инъекция динамических загрузчиков классов через отладчик проста), а затем исправить ситуацию. Таким образом, вы можете подключиться к работающему серверу. обнаружите, что после короткого сбоя функция не смогла повторно подключиться к базе данных, а затем снова подключить ее туда и обратно.

как и при всех конструкциях программирования, никогда не будет серебряной маркой, и это постоянное развертывание/разработка имеет интересный недостаток: программа может быть правильной в памяти и неправильной на диске. если вы скомпилируете функцию, тогда ее сломаете и сохраните, тогда будет работать только рабочая копия кода. Мне полезно знать об этом и повторно обновлять файлы сразу после их сохранения.
Это может показаться причудливым, поэтому посмотрите, как Внедрить Clojure REPL в ваше производственное приложение

Ответ 5

Я помню, что кто-то из НАСА рассказал о своем опыте. Его команда реализовала мягкое использование космического корабля еще в 70-х годах. И они эффективно модифицировали свои мягкие дистанционно на лету, когда были обнаружены некоторые ошибки.

Или представьте, что у вас есть долгий процесс, требующий нескольких дней для выполнения, и в конце он не может писать результаты из-за разрешений или другой небольшой проблемы.

Еще один пример. Вы находитесь на этапе интеграции, и вам нужно внести небольшие изменения. И снова их много. Я мечтаю о такой возможности на Java, потому что в настоящее время мне требуется 30-40 минут, чтобы перестроить и переустановить мое приложение (чтобы восстановить его снова за 10 минут).

Ответ 6

Если вы посмотрите на что-то вроде Erlang, необходимо избегать времени простоя.

Он работает на таких вещах, как телефонные коммутаторы, которые вы не можете просто отключить на несколько секунд.

Для более нормального использования, однако, это "хорошо иметь" функцию, но да, возможно, не критично.

Ответ 7

Вы видите реальные данные. Это большое преимущество. Тогда вам не нужно размышлять.

Ответ 8

Потому что вы можете?

Серьезно, просто попробуйте это время, и вы почувствуете боль, когда вернетесь на свой старый язык программирования без REPL.

Мгновенная обратная связь, простое выполнение быстрых тестов без необходимости настройки фальшивого состояния программы в вашем тестируемом устройстве. Возможность проверки состояния запущенной программы (каково значение этой переменной). Все это спасатели в реальном времени.

Ответ 9

Это в основном для разработки, где он просто хранит время.

Но вкладчики времени имеют ошеломляющее значение.

Как только вы привыкнете к этому, возвращение к старому способу похоже на то, чтобы перейти от полета к плаванию в смоле.

Ответ 10

В промышленных системах это используется для программирования ПЛК для облегчения простоев и небезопасных условий.

Это системы, которые используются на атомных электростанциях, производственных системах, сталелитейных заводах и т.д. Процесс всегда работает, постоянно, а время простоя очень дорого или небезопасно. Представьте себе систему, которая контролирует охлаждение ядерного реактора, вы не можете отключить эту систему для развертывания нового кода, вы должны иметь возможность изменять его, когда он работает.

Это похоже на ответ Erlang для систем телефонных коммутаторов.

Ответ 11

Ну, представьте, вам нужно исправить сервер и не останавливать его.

Если вы сделаете это на "типичном" языке, это будет связано с какой-то тяжелой магией. Вы должны замаскировать "за" исполняемый код. Я думаю, что это потребует исправления таблиц функций и т.д., Все в сборке и манипулировании указателями на функции. Хорошее место для ошибок.

В Lisp идея обновления без простоя встроена в модель языка. Несмотря на некоторые сложности обновления, от которых вы не можете уйти (как вы работаете с долговременным подключением), это не требует тяжелой магии скомпилированного языка.

Хотя я не потратил на это значительное время (т.е. что-нибудь полезное), я разработал прототип сервера в Common Lisp, который сделал бы хотя бы некоторое обновление в сети без простоя.

Ответ 12

Еще одна хорошая вещь, помимо модификации программы "на лету" без необходимости перезапускать все (проделав ее на протяжении десятилетий, не означает, что это лучшая вещь, правда?), заключается в том, что вы можете проверить свою программу в ее текущем состояние и возможность выяснить, что происходит.

Ответ 13

Кейси Муратори просто сделал несколько уроков о том, как это сделать с помощью C и компилятора Microsoft C/С++. Это на самом деле довольно просто, всего несколько десятков строк кода. Просмотрите видеоролики 22/24/25:

https://www.youtube.com/watch?v=WMSBRk5WG58

В игровом дизайне обоснование состоит в том, чтобы иметь возможность более быстро настраивать константы, чтобы найти эмоциональный тенор, на который вы стремитесь. Такие вещи, как чувство игры, сценарии поведения, отличные от игрока, и освещение/окружающая обстановка, выигрывают от этого.