Ну питонутые на всю голову и что с того? Не люди что ли?...

Не нужно, есть ipython.

Ведь питон все равно слишком многословен

Да.

Гм. Немногословный язык это необходимое условие пользования REPL?

public;;{;}}}{; static}}}};{;};{{{{;; transient}}}{};}} abstract;{{{;;}}};; точно;;; try {{{{ не;;;; }}}} catch (runtimeexception лишнее) {{{;;;;;;{{;{;};}}};;; ;;};;

ТС пострадал от apl, имейте сочувствие.

не немногословный - не означает многословный

Ведь питон все равно слишком многословен

для репл?

Нет. Как по Вашему лисперы могли бы фапать на репл, если бы это имело какое-то серьезное значение?

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

что значит необходимое? какая степень «необходимости» постулируется?

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

Нет, не пользовался. Что имеется в виду под интересным?

вы в репле вообще работали?

ТС, не надо шлангом прикидываться. У необходимого условия нет степени. Речь только идет о степени многословности.

ну это _твоя_ воображаемая нужда (необходимость) мой незнакомый друг.

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

какой из этих двух аспектов ты имел ввиду?

PS при такой детальности «в степенях условий» ты спросил на удивление неаккуратно. или это ты «шлангом прикидывался»? :)

1) true

2) Чем лаконичнее язык, тем работа с repl продуктивнее.

Надеюсь, ты улавливаешь разницу с твоей дискретной продуктивностью.

Если совсем тугой, то hint: для многих питон достаточно лаконичен.

как сказали классики --- для некоторых и кобыла невеста (С)

PS удачи тебе с питуном. когда на самом деле начнешь пользоваться им в репле расскажешь об многословности :)

Автокомплит по-умолчанию включен и в ghci, например. Но это же не значит...

Лисповский стиль использования REPL подходит только для лиспа: гомоиконность же! Плюс, мрачное наследие лисп-машин в виде образа всей лисп-системы. Но и то и другое, не есть исторический ландшафт для питона.

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

Что там в пинтоне - не знаю. Давным-давно уже не писал на нем. По логике вещей, REPL должен быть в первую очередь инструментом динамического анализа (опять же, ввиду специфики). Лаконичность языка при таком режиме работы - побоку.

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

ну вот я большую часть времени провожу в репле

Опиши сценарий (сценарии) работы, плз. Очень интересно.

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

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

Плюс, мрачное наследие лисп-машин в виде образа всей лисп-системы.

Без загрузки рабочего образа repl не имеет никакого смысла, почти никакого.

Я по работе запускаю время от времени F# Interactive Console, чтобы проверить всякие вещи типа System.Uri. Но это такая фигня по сравнению с настоящим repl, который, пожалуй, есть только в лиспе да и смолтоке, если говорить об известных языках.

Еще часто запускаю консоль из scala - такая же фигня по возможностям как и F# Interactive Console. Лучше это называть просто консолью, а не repl.

смолтоке

Ну, у смаллтолка тоже мрачное наследие лисп-машин ;)

Кстати, лисп-стайл REPL есть у форта.

Мера «полноценности» REPL — не самая хорошая мера. В конце-концов, REPL это всего лишь read-eval-print loop. И нет обязательного требования, чтобы он мог изменять состояние системы.

Нет и требования, чтобы можно было изменять состояние каждого произвольного объекта в системе! Это возможно только в динамических языках.

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

REPL на уровне модулей, это в большей степени контрактно-ориентированная фигня. Т.е. всецело зависит от предметной области. Т.е. не существует виде сферической реализации в вакууме. А значит...

да все обычно... репл R

А, понятно. Я-то думал ты про питоновский ;)

Да, про форт я забыл как-то. Нужны динамика и живой образ. Подходит и для форта тоже.

REPL интересен как раз тем, что мы можем менять код, когда состояние переменных остается тем же или почти тем же (change-class), что очень удобно при отладке десктопных приложений. В том и смысл, что есть живой образ.

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

"автокомплит" vs "слишком многословен"

Не стоит забывать, что работа с кодом состоит из его ввода из файлов в мозги, и его(или патчей) вывода в обратном направлении. При этом, скорость первого канала намного выше скорости второго. Соответственно, оптимум многословности для этих задач сильно отличается. Т.е. любой язык, достаточно краткий для нецелесообразности автокомплита, будет слишком неэффективным для чтения/понимания. Это объективный недостаток тел гомо сапиенсов.

не смешиваете ли вы понятия «многословен» и «длинословен» ?

многословен vs. длинословен

Подумал. Нет разницы(кроме сложностей реализации автокомплита).

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

многословный автокомплит не представляю

дополнение module.class.member - достаточно просто, уже 3(слова и все длинные:). Дальше - можно угадывать имена аргументов по требуемым типам. Слышал, что это не просто, но не слышал, что невозможно.

это не снипет. это обычный комплит в том же репле R