Re[6]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: z00n  
Дата: 10.03.09 11:15
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Возможно. Я его поставил, ужаснулся шрифтам и снес от греха подальше.

Это под линухом? Там была экспериментальная сборка под GTK+, которую потом слили в 23.
Под windows, как не странно, 22 emacs имел отличную поддержку шрифтов.
Re[7]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: Mr.Cat  
Дата: 10.03.09 11:30
Оценка:
Здравствуйте, z00n, Вы писали:
Z>Это под линухом?

Угу. 22-я версия из репозитория archlinux. Сейчас у меня стоит и регулярно обновляется версия из cvs — там все ок.
Re[3]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: DemAS http://demas.me
Дата: 10.03.09 12:12
Оценка:
"MasterZiv" <30904@users.rsdn.ru> writes:

> Это, правда, достоинство не столько репла, сколько других особенностей

> языка.

Именно. Тот же Erlang позволяет заменять код "на лету". Но ему при этом
пофигу где этот код был создан — в среде поддерживающей REPL или нет.

То есть, я к тому, что твое объяснение достоинств REPL относится не столько
к REPL, сколько к выбранному языку программирования.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: volk  
Дата: 10.03.09 15:36
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Аноним 6 пишет:

>> В общем, Lisp vs Scheme -- это как C vs Современный Pascal.

MZ>Скорее, ровно наоборот.


MZ>CommonLisp — промышленный, развитой язык. Но большой и более сложный,

MZ>по сравнению со схемой. Схема — маленькая, элегантная и простая. Но
MZ>скорее для пром. программирования не предназначенная (хотя из меня такой
MZ>спец по схеме, что ойойой... )

Ну так я ровно это и имел ввиду.
Почему же тогда
MZ>Скорее, ровно наоборот.
Тот, кто желает, но не делает, распространяет чуму.
Re[2]: Поздравляю с неудачным стартом :)
От: volk  
Дата: 10.03.09 15:41
Оценка:
Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Поздравляю Вас с неудачным стартом.

Вообще-то старт был вполне удачный.

RD>3. REPL (мое сугубо личное мнение) это один из самых убогих подходов. Он видимо был актуален тогда, когда при продаже овец каждую овцу ставили рядом с кусочком золота (т.к. считать не умели). Но на дворе уже 2009 год.


И в 1980-м, и сейчас REPL все так же замечательно применяется в ряде математических пакетов. Чем предложите заменить?
Тот, кто желает, но не делает, распространяет чуму.
Re[2]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: volk  
Дата: 10.03.09 15:44
Оценка:
Здравствуйте, thesz, Вы писали:

V>>Если Вы только собираетесь освоить функциональный подход и выбираете язык для быстрого старта, то это сообщение будет для Вас полезным.


V>>Разнообразные фичи ФЯ здесь обсуждаться не будут.


T>Противоречие, нет?


Нет; я имел ввиду, что буду говорить в основном про технические моменты -- типа "как его готовить".
А монады-замыкания-продолжения и прочие чудеса оставляю вам, матерым хаскеллистам.
Тот, кто желает, но не делает, распространяет чуму.
Re[3]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: thesz Россия http://thesz.livejournal.com
Дата: 10.03.09 15:52
Оценка:
V>>>Если Вы только собираетесь освоить функциональный подход и выбираете язык для быстрого старта, то это сообщение будет для Вас полезным.
V>>>Разнообразные фичи ФЯ здесь обсуждаться не будут.
T>>Противоречие, нет?
V>Нет; я имел ввиду, что буду говорить в основном про технические моменты -- типа "как его готовить".
V>А монады-замыкания-продолжения и прочие чудеса оставляю вам, матерым хаскеллистам.

Я ради галочки: разговор будет вестись только о Лиспе, без сравнений с другими ЯП, так? И только технические детали, только Лиспа, так?

Исключительно ради занудства.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Поздравляю с неудачным стартом :)
От: Rtveliashvili Denys Великобритания  
Дата: 10.03.09 17:23
Оценка:
RD>>Поздравляю Вас с неудачным стартом.
V>Вообще-то старт был вполне удачный.

Кому как. Если считать что выбрасывание сходу одного из лучших инструментов разработки в пользу... э... мягко говоря не самого лучшего — удачный старт, то почему-бы и нет. В общем, это вопрос субъективный.

V>И в 1980-м, и сейчас REPL все так же замечательно применяется в ряде математических пакетов. Чем предложите заменить?


REPL позволяет выяснить, каким будет значение выражения или получить более подробную информацию о нем (тип, документация, и т.д.).
На мой вкус, все это должно быть интегрировано прямо в IDE. Пишешь себе код, и если интересно узнать что-то — жмешь shortcut. Так, кстати, сделано в Slime и (в какой-то степени) в OcaIDE.

Впрочем, я так вижу что народ к неудобствам привык (или считает это удобствами), так что ситуация врядли изменится.
Re[5]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: Rtveliashvili Denys Великобритания  
Дата: 10.03.09 17:31
Оценка:
К>В консоли REPL, например, ты можешь делать "тестовые" вычисления, такие какие тебе взбредут в голову, посмотреть результаты (а в GHCi ещё и типы), поменять решение, сделать другие тесты и т.д. до получения результата, который бы тебя удовлетворял. Плюсом является минимизация REPL именно как "loop", как ты будешь делать такое в отдельных окнах и файлах — хотелось бы посмотреть, ну и замерять накладные расходы на разные переключения окон, контекстов и т.п.

Интерсно, а кто-нибудь осилит таки поставить Slime и понять как он работает? Это не так сложно.

Там прямо в тексте программы пишешь что хочешь. И это что хочешь выполняешь. И не только выполняешь. И после всей этой возни тебе не надо вылавливать по истории REPL введенные когда-то выражения. Они у тебя уже в файле. Надо просто сохранить. Так что REPL _вообще_ не дает преимуществ по ставнению со средами вроде Slime.
Re[4]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: BulatZiganshin  
Дата: 10.03.09 17:38
Оценка:
Здравствуйте, thesz, Вы писали:

V>>>>Разнообразные фичи ФЯ здесь обсуждаться не будут.


T>Я ради галочки: разговор будет вестись только о Лиспе, без сравнений с другими ЯП, так? И только технические детали, только Лиспа, так?


в его посте — да, так и было
Люди, я люблю вас! Будьте бдительны!!!
Re[2]: Поздравляю с неудачным стартом :)
От: Аноним  
Дата: 10.03.09 20:25
Оценка:
Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>3. REPL (мое сугубо личное мнение) это один из самых убогих подходов. Он видимо был актуален тогда, когда при продаже овец каждую овцу ставили рядом с кусочком золота (т.к. считать не умели). Но на дворе уже 2009 год.


Не соглашусь, делать программу находясь прямо в ней это не забываемый опыт. Безусловно легко получить продукт который не сможет "вытащить себя за шнурки" при запуске, но заработает он быстро. И размышления при его запуске, когда каждая мысль эволюционно развивает программу и тестируется, фундаментально прочны. Да продукты так и тянет распространять в виде дампов + райнтайм. Вот например как об этих двух подходах пишет явный сторонник редактирования кода:

4.4 Philosophies for Combining S with ESS
There are two primary philosophies for using ESS. The default is that the source
code (the file ‘myfile.s’, for example) is real, and objects in S are temporary real-
izations of the source. A project is constructed by writing S language source code
for user defined functions and data objects. One or more text files containing the
code are stored in a project directory or directories. The code is read into S for
a temporary realization as an object. This approach allows for better portability,
where the user might want to use the written code and perform the same or re-
lated analyses on different versions of the S language. This approach also permits
external version control for S language source code.
The second, deprecated view, is that S objects are real. The text version of the
objects (source code, although we can’t use that term with this philosophy) is a
temporary realization of the objects. ESS is then used to edit, but not save, the
text. The text is returned to S to be saved as an object. We strongly discourage
this approach. It is a natural result of assuming that the S process will always be
the same, an assumption we are not willing to make.


На самом деле достаточно что бы было что то вроде edit(имя_редактируемого) возвращающее набранное в любимом редакторе. Комплектация есть уже везде, и в REPL она более полная чем в редакторе.

думаю Вас не смутит, что пример взят из S/R ?
Re[4]: Поздравляю с неудачным стартом :)
От: yumi  
Дата: 11.03.09 00:17
Оценка:
Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Здорово! Специально для Вас в C# сделали REPL. Кстати.. Наверное все-таки не в самом C# (т.к. это язык) а в Visual Studio? Или я неправильно понимаю?


В самом C#'е, причем тут VS вообще? Неправильно все понимаете.

RD>Судя по тону Вашего комментария, Вы считаете что REPL это круть. Всегда хотел узнать, что именно в нем вам так нравится и почему Вам не нравится та же функциональность но встроенная непосредственно в IDE? Действительно удобно copy-paste делать между текстом программы и REPL окном?


Ну не то чтобы круть, просто очень удобно, по крайней мере для меня. Где в IDE та же функциональность, я бы рад это увидеть, можешь пальцем указать? Судя по всему Вы вообще понятия не имеете, что такое REPL.

Могу рассказать свой самый частый use case. У меня обычно открыто два буфера в эмаксе, один с исходником, другой с repl'ом. Пишу в буфере с кодом какую-либо функцию, компилирую ее (функцию), затем иду в repl и пробую дергать свою функцию с разными параметрами. Пищу следующую функцию (возможно вызывающую предыдущую) и все то же самое.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[5]: Поздравляю с неудачным стартом :)
От: Lloyd Россия  
Дата: 11.03.09 00:24
Оценка:
Здравствуйте, yumi, Вы писали:

Y>Ну не то чтобы круть, просто очень удобно, по крайней мере для меня. Где в IDE та же функциональность, я бы рад это увидеть, можешь пальцем указать? Судя по всему Вы вообще понятия не имеете, что такое REPL.


В принципе, функциональность аналогичную REPL-у можно получить, заведя для этого отдельный unittest.
Будет примерно так, как ты и описываешь — в одном окошке пишешь, компилируешь, в другом — запускаешь.
Re[6]: Поздравляю с неудачным стартом :)
От: yumi  
Дата: 11.03.09 00:52
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>В принципе, функциональность аналогичную REPL-у можно получить, заведя для этого отдельный unittest.

L>Будет примерно так, как ты и описываешь — в одном окошке пишешь, компилируешь, в другом — запускаешь.

Не, аналогичную точно не получить, но что-то похожее да, согласен таким способом можно получить, для этого я обычно просто добавляю один консольный проект, добавляю референс на тестируемый и из консольного проекта дергаю нужные методы, но это все равно, слишком много телодвижений.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[6]: Поздравляю с неудачным стартом :)
От: MasterZiv СССР  
Дата: 11.03.09 06:26
Оценка:
Lloyd пишет:

> В принципе, функциональность аналогичную REPL-у можно получить, заведя

> для этого отдельный unittest.

Вообще, если искать замену, нужно вспомнить прежде всего про beanShell
явовский.
Posted via RSDN NNTP Server 2.1 beta
Re: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор верси
От: MasterZiv СССР  
Дата: 11.03.09 06:27
Оценка: 1 (1) +4
volk пишет:

> Для удобства разбиваю текст на несколько частей, которые буду

> выкладывать отдельными сообщениями.

Короче, автор, продолжай пожалуйста, а то они тут ещё 3 года будут
спорить, хорошо ли REPL или плохо.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Поздравляю с неудачным стартом :)
От: Lloyd Россия  
Дата: 11.03.09 07:04
Оценка:
Здравствуйте, yumi, Вы писали:

L>>В принципе, функциональность аналогичную REPL-у можно получить, заведя для этого отдельный unittest.

L>>Будет примерно так, как ты и описываешь — в одном окошке пишешь, компилируешь, в другом — запускаешь.

Y>Не, аналогичную точно не получить,


В чем отличие?

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


Чем это лучше unittest-а?
Re[2]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: Mr.Cat  
Дата: 11.03.09 07:26
Оценка:
Здравствуйте, MasterZiv, Вы писали:
MZ>Короче, автор, продолжай пожалуйста, а то они тут ещё 3 года будут

Вот тут согласен.
Re[8]: Поздравляю с неудачным стартом :)
От: yumi  
Дата: 11.03.09 08:54
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>>>В принципе, функциональность аналогичную REPL-у можно получить, заведя для этого отдельный unittest.

L>>>Будет примерно так, как ты и описываешь — в одном окошке пишешь, компилируешь, в другом — запускаешь.
Y>>Не, аналогичную точно не получить,

L>В чем отличие?


Да хотя бы тем, что в repl'е сохраняется environment.

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


L>Чем это лучше unittest-а?


Тут скорее, почему unittest? Цель unittest'ов ортогональна repl'у.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[5]: Поздравляю с неудачным стартом :)
От: Rtveliashvili Denys Великобритания  
Дата: 11.03.09 10:54
Оценка:
RD>>Здорово! Специально для Вас в C# сделали REPL. Кстати.. Наверное все-таки не в самом C# (т.к. это язык) а в Visual Studio? Или я неправильно понимаю?
Y>В самом C#'е, причем тут VS вообще? Неправильно все понимаете.

Аналог GHCi в Хаскере или просто запуска python без агрументов в питоне? Мрак, это еще хуже, чем я думал.
Может Вы С# код пишете в notepad? Я тоже когда-то так делал. Но не долго.

RD>>Судя по тону Вашего комментария, Вы считаете что REPL это круть. Всегда хотел узнать, что именно в нем вам так нравится и почему Вам не нравится та же функциональность но встроенная непосредственно в IDE? Действительно удобно copy-paste делать между текстом программы и REPL окном?

Y>Ну не то чтобы круть, просто очень удобно, по крайней мере для меня. Где в IDE та же функциональность, я бы рад это увидеть, можешь пальцем указать? Судя по всему Вы вообще понятия не имеете, что такое REPL.

Конечно и понятия не имею.

Y>Могу рассказать свой самый частый use case. У меня обычно открыто два буфера в эмаксе, один с исходником, другой с repl'ом. Пишу в буфере с кодом какую-либо функцию, компилирую ее (функцию), затем иду в repl и пробую дергать свою функцию с разными параметрами. Пищу следующую функцию (возможно вызывающую предыдущую) и все то же самое.


В случае с Common LISP:
1. всегда есть запущенный environment.
2. есть один буфер, в котором Вы пишете Вашу ф-цию.
3. дописали, нажали шорткат -> она ушла в environment
4. пишете (foo 1 2 3), жмете шорткат -> (foo 1 2 3) выполнилось и вы видите результат выполнения
5. не понравился результат? идете к пункту 2
Приблизительно это уже есть в Slime. Причем давно.

В случае с моим любимым Haskell это НЕ реализовано. Но могло бы быть еще удобнее, потому что язык _чистый_.
Схема была бы та же, но не надо было бы нажимать шорткаты вообще.
— импорты в редактируемом модуле и уже введенные определения это environment
— пока пишешь выражение, его тип и значение автоматически вычисляются и показываются в рядом или в status bar'е каком-то.

Но Вы очень любите REPL. Любите дальше.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.