Выход mocl

Я получаю ответы, которые превосходят мою способность верить.

А в чем проблема?

В опыте и здравом смысле.

Ловушка «большого проекта»

Речь не шла о больших проектах.

Если разработка «снизу-вверх» вводит уровни абстракции со своими языками,

Уровни со своими языками? У каждого уровня свой язык, серьезно?

Кстати, «слои абстракций» («иерархическое упорядочивание», как сказал Страуструп) - это общий принцип для разработки на любом языке.

то это самое «квадратично» для основной задачи превращается в худшем случае в «линейно», а чаще всего в логарифм от сложности.

Для этого соершенно нет необходимости изобретать каждому слою свой язык. Или, опять же процитирую книгу Страуструпа, «проект библиотеки - это проект языка». То есть решает разумная модульность.

Лисп весь эволюционировал именно в направление разработки «снизу-вверх»

Забавно. Си тоже так эволюционировал.

То есть хотя бы для некоторых задач Лисп - это не самый лучший выбор.

Конечно есть. Это решённые задачи. И таких задач много.

Вот просто так сразу - лучший. Вне зависимости ни от чего.

Ну я пока ничего лучшего не встречал.

Осталось доказать (или показать на примерах), что МП - это эффективный метод решения любых задач, потому что иначе 0 см. выше.

А чего тут доказывать? Разве это не самоочевидно? Лучший язык для задачи, это тот язык, который разговаривает в терминах задачи. Если языка к задаче нет, то его нужно написать. Написать его можно разными способами. Самый простой — взять язык с развитым МП. Самый развитый МП на сегодняшний день в Lisp. Вы знаете какие-то языки с более развитым и простым в освоении МП, чем МП в Lisp? Расскажите.

Статическа сильная типизация

Является ли «сатическая и сильная» типизация реальным преимуществом — большой вопрос.

богатые библиотеки

Вот это по делу. Задча Clojure — исправить это.

ИП и МП, которые есть не только в Лиспе (то, что в Лиспе они якобы самые крутые, не очень важно)

А как вы можете судить о важности/не важности МП и ИП в Lisp, если вы об этом ничего не знаете и никогда не пробовали?

То есть хотя бы для некоторых задач Лисп - это не самый лучший выбор.

Конечно есть. Это решённые задачи.

Забавная формулировка. Понтовая и туманная до бессмысленности.

осталось доказать (или показать на примерах), что МП - это эффективный метод решения любых задач, потому что иначе 0 см. выше.

А чего тут доказывать? Разве это не самоочевидно?

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

Является ли «сатическая и сильная» типизация реальным преимуществом — большой вопрос.

Ответ на этот вопрос дало время - да, является. Естественно, это проявляется только при росте размера программ.

А как вы можете судить о важности/не важности МП и ИП в Lisp, если вы об этом ничего не знаете и никогда не пробовали?

Ох ты господи. МП есть не только в Лиспе, а ИП пробовал и понимает любой, кто разбирается в shell.

как сказал Страуструп

опять же процитирую книгу Страуструпа

А с каких пор Стауструп в авторитете? Он даже для развития C++ мало чего сделал.

А с каких пор Стауструп в авторитете?

У кого? Если речь обо мне, то примерно с начала 90-х.

Он даже для развития C++ мало чего сделал.

Бида-огорчение. Расскажи мне, что сделал Грэм для развития Лиспа.

Забавная формулировка. Понтовая и туманная до бессмысленности.

Нет. Совершенно чёткая и конкретная формулировка.

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

Это так, если говорить о реализации языков «общего назначения». А мы говорим о задачах к которым приминим МП. И таких задач большинство (практически все). И чем МП удобнее, тем проще писать подобные вещи.

Ответ на этот вопрос дало время - да, является. Естественно, это проявляется только при росте размера программ.

А можно пруфов?

Ох ты господи. МП есть не только в Лиспе, а ИП пробовал и понимает любой, кто разбирается в shell.

Сравнивать МП Lisp и «ИП» shell — это тоже самое, что сравнивать cpreprocessor макросы и макросы Lisp :)

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

Это так, если говорить о реализации языков «общего назначения».

Это так, если говорить о нетривиальных DSL.

Ответ на этот вопрос дало время - да, является. Естественно, это проявляется только при росте размера программ.

А можно пруфов?

http://www.tiobe.com/content/paperinfo/tpci/index.html - посчитай проценты статически типизированных языков против динамических.

ИП пробовал и понимает любой, кто разбирается в shell.

Сравнивать МП Lisp и «ИП» shell — это тоже самое, что сравнивать cpreprocessor макросы и макросы Lisp :)

А я и не сравнивал. Естественно, разница есть, но идея та же самая. Впрочем, если ты не любишь shell, есть bpython, ipython, Ocaml REPL, да много чего. Или пока не поработал в Лиспе - не смей иметь мнение?

Ага, провинциальную шалаву спросить забыли, как правильно софт продавать. Столлман сожрал твой мозг, быдлятина?

Это так, если говорить о нетривиальных DSL.

Если говорить о DSL определяющий нетривиальные абстракции для области, то квадратно-гнездовой код и «библиотеки» вообще не решают ничего — такой подход вообще могила.

http://www.tiobe.com/content/paperinfo/tpci/index.html - посчитай проценты статически типизированных языков против динамических.

Т.е. ты полагаешь что распространённость и популярность определяет крайнюю необходимость и важность некой фичи?

Естественно, разница есть, но идея та же самая.

Разница огромна. И что бы это прочувствовать нет другого пути, как попробовать Lisp и Emacs/slime/nrepl.

Или пока не поработал в Лиспе - не смей иметь мнение?

Мнение иметь можно, но только цена мнения основанного на «не знаю, но осуждаю», «не знаю, но мнение имею» = 0.

Слышь, ты, п*зд*бол, базар фильтруй. За сим откланяюсь )

Если говорить о DSL определяющий нетривиальные абстракции для области, то квадратно-гнездовой код и «библиотеки» вообще не решают ничего

Ух ты.

Т.е. ты полагаешь что распространённость и популярность определяет крайнюю необходимость и важность некой фичи?

Что за экзальтация, откуда «крайняя необходимость»? Люди выбрали инструменты, результат налицо.

Что, ты хотел сказать о миллионах мух? А сам ты, конечно, не муха?

Или пока не поработал в Лиспе - не смей иметь мнение?

Мнение иметь можно, но только цена мнения основанного на «не знаю, но осуждаю», «не знаю, но мнение имею» = 0.

А, ну тогда конечно. Против Лиспа ничего не имею, но вижу, что его сектанты не меняются. Happy Lisping.

Ух ты.

Именно.

Что за экзальтация, откуда «крайняя необходимость»? Люди выбрали инструменты, результат налицо.

Тех, кого ты называешь «людьми» вообще ничего не выбирают. Они просто хавают.

Что, ты хотел сказать о миллионах мух? А сам ты, конечно, не муха?

Именно. Ты чётко уловил мысль. Взаимосвязи между «статической строгой типиазции» и популярностью никакой.

А, ну тогда конечно. Против Лиспа ничего не имею, но вижу, что его сектанты не меняются. Happy Lisping.

Мы ещё не начили говорить о конкретных вещах, а ты уже протёк :) Я то думал, что на много лучше всё это будет...

Мы ещё не начили говорить о конкретных вещах

После твоего высказывания о DSL это не имеет смысла. Ты понятия не имеешь, о чем говоришь.

а ты уже протёк :)

Ага, и пошел плакать в уголок.

После твоего высказывания о DSL это не имеет смысла. Ты понятия не имеешь, о чем говоришь.

Ой ли? =)

Ага, и пошел плакать в уголок.

Ты проплачься и возвращайся. Я хочу услышать от тебя о языках с лучшей чем у Lisp реализацией МП.

После твоего высказывания о DSL это не имеет смысла. Ты понятия не имеешь, о чем говоришь.

Ой ли? =)

Да.

Да.

Нет. Зачем же мне говорить о том, чего я не понимаю? Такими вещами заниматься — удел протекающих.

Хотелось бы увидеть ссылки на что нибудь аналогичное slime по возможностям

(гнуснейший самопиар) http://dmitrymatveev.co.uk/shampoo/ - все операции проводятся на живой, работающей системе

Зачем же мне говорить о том, чего я не понимаю? Такими вещами заниматься — удел протекающих.

Значит, ты такой и есть.

(гнуснейший самопиар) http://dmitrymatveev.co.uk/shampoo/ - все операции проводятся на живой, работающей системе

Не плохо, чё :) И не удивительно, ибо:

Shampoo is inspired by the awesome Common Lisp development tools SLIME and SWANK. I hope that one day Shampoo will reach the same level of coolness.

Значит, ты такой и есть.

Ты уже проплакался? Так что там насчёт МП-то?

Ты уже проплакался?

Не-а.

(гнуснейший самопиар)

Это ваша разработка?

Ну да - ведь repl существует только в lisp.

Если не считать скалу, средств разработки для которой я не видел, да - нормальный repl есть только у лиспов.

Действительно ваша. Круто, чё :)

Смаллтлк приблидзительно там же где и common lisp лисп.

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

учитывая что инструменты типа repl есть везде

Убогое есть везде, нормального нет нигде.

а усилия на перекомпиляцию проекта минимальныё

Поэтому так популярны языки с динамической типизация, ага :)

Уровни со своими языками? У каждого уровня свой язык, серьезно?

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

тебя ведь например не смутит, когда в юниксе ты в одной задаче сначала работаешь с помощью sed, а потом gawk и попутно вызывашь еще всякие grep и компанию?

Уровни со своими языками? У каждого уровня свой язык, серьезно?

в пределе возможно и такое, а что тут такого крамольного?

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

новый встроенный язык это всего навсего легко (в отличии от «библиотеки») обеспеченное средствами лиспа средство комбинации введенных операторов

Язык - это транслятор + библиотека, и, даже если транслятор бесплатен (отнюдь не случай Лиспа), библиотека будет сложной, если она решает сложную задачу. И в конце концов DSL будет просто удобным фронтендом к этой библиотеке. Выигрышу в разы по сравнению с не-DSL здесь взяться просто неоткуда.

тебя ведь например не смутит, когда в юниксе ты в одной задаче сначала работаешь с помощью sed, а потом gawk и попутно вызывашь еще всякие grep и компанию?

Затрудняюсь сказать, является ли это примером использования многих DSL или это подпрограммы shell.

И в конце концов DSL будет просто удобным фронтендом к этой библиотеке. Выигрышу в разы по сравнению с не-DSL здесь взяться просто неоткуда.

Ох, какую глупость ты сейчас сморозил :)

Хотелось бы увидеть ссылки на что нибудь аналогичное slime по возможностям,

Любая IDE?

По каким конкретно возможностям?

Затрудняюсь сказать, является ли это примером использования многих DSL или это подпрограммы shell.

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

также шел может генерировать код на себе самом и внешних языках и потом его исполнять.

получается та самая разработанная «снизу-вверх» система в которой можно решать кучу задач весьма далёких от исходной постановке 70х :)

Язык - это транслятор + библиотека, и, даже если транслятор бесплатен (отнюдь не случай Лиспа), библиотека будет сложной, если она решает сложную задачу. И в конце концов DSL будет просто удобным фронтендом к этой библиотеке. Выигрышу в разы по сравнению с не-DSL здесь взяться просто неоткуда.

ну вот эмулятор цифровых схем их SICP или пример графического языка. где там компилятор? там просто обеспечена комбинация введенных операторов. ну с некой натяжкой у эмулятора цифровых схем «пропаганатор» сойдет за интерпретатор, но у графического языка ничего такого нет.

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

Нет. Smalltalk давно застыл.

А common lisp на пике развития шахматной мысли чтоле? Единственный «lisp» который может претендовать на поддержку всяких инноваций - это clojure. Все остальныё лиспы приводят те же аргументы что 15 лет назад.

Но разве решение новой задачи, которая никогда не решалась, не есть «exploratory программирование»?

Решение новой задачи на сегодняшний момент прдполагает сложность где надо наитегрировать гору всего. Решение простеньких задачь уже когда программист сидел и ковырялся с компилятором в рамках сетапа операционки - уже в 15тилетнем прошлом. Сейчас надо стопицом билиотек, 52 альтернативныё версии и куча всего. То что «10 строчек удобно в репле эвалить» уже не о чем.

Ну это только если проект называется «Hello, World!».

Нет это только в hello world. хватает repl.

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

Согласен, но причем тут Лисп или DSL? Конвейер из функций или генераторов я могу изобразить в 20 строка Python без всякой Lisp-магии. В него можно накрутить и абстракций, и операций.

ну вот эмулятор цифровых схем их SICP или пример графического языка. где там компилятор?

Лень лезть в SICP - наверное, компилятором работает макросистема Scheme?

выхлоп eDSL в лиспе это код лиспа,

Ясное дело. Но при нетривиальном DSL и разумном проектировании этот код - набор библиотечных вызовов.

Поэтому так популярны языки с динамической типизация, ага :)

Ты про php и vb?

Лень лезть в SICP - наверное, компилятором работает макросистема Scheme?

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

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

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

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

Ну круто, чо. Правда, непонятно, что здесь Лисп-специфичного.

Ты про php и vb?

ruby, python, clojure, js, lua, ... php тоже да.

Уровни со своими языками? У каждого уровня свой язык, серьезно?

Конечно. Вот каноничный пример - http://www.computerra.ru/65749/steps/ Там целый стэк языков для разных уровней абстракции. Круто же!

Уровни со своими языками? У каждого уровня свой язык, серьезно?

Конечно. Вот каноничный пример - http://www.computerra.ru/65749/steps/

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

Ну и вот это просто умиляет:

Если посмотреть отчёты Viewpoints за разные годы, то заметно, что здесь снова и снова изобретают языки программирования, делают их всё более самодостаточными (пока что кое-где ещё остаётся код на Си, но от него постепенно избавляются) и ставят смелые эксперименты.

Ну круто, да. Работа мечты, чо уж там - изобретай себе языки и втирай о том, как изменишь «программирование, операционные системы и интернет». Почти как у Грэма.

Почти как у Грэма.

У Грэма в основном о преимуществах динамической типизации, репла и макросов.

ruby, python, clojure, js, lua, ... php тоже да.

ruby и python динамические не потому что фича - а просто потому что их авторы не осилели статический компилятор.

эмбеддед скриптование (js, lua) и шаблонизатор (php) - особый случай когда программа не должна быть законченной - то есть до момента исполнения нет целостной системы. Это trade-off а не преймущество.

А clojure динамический абы было потому что lisp. Мог бы быть статическим так же.

У Грэма понты вроде Beating the Averages.

Вот каноничный пример http://www.computerra.ru/65749/steps/

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

В основе mocl лежит идея, заключающаяся в том, что логика приложения должна быть полностью описана на Лиспе, а пользовательский интерфейс — быть «родным» для платформы.

Видимо поэтому андроидная демка по refresh() дергает лисп, который рисует интерфейс в png и сохраняет его на диск, а андроид потом это показывает?

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

Бида-огорчение. Расскажи мне, что сделал Грэм для развития Лиспа.

Почти как у Грэма.

У Грэма понты вроде Beating the Averages.

Подозреваю, максимум, что ты прочитал у Грэма — «blub paradox». И судя по всему, был сильно обугурчен и до сих пор испускаешь лучи :)

рисует интерфейс в png и сохраняет его на диск, а андроид потом это показывает

оригинальный подход :)

Ну круто, да. Работа мечты, чо уж там - изобретай себе языки и втирай о том, как изменишь «программирование, операционные системы и интернет». Почти как у Грэма.

У тебя что не пост, так все пидарасы. И Грэм; вот теперь и Алан Кэй тоже. Один Страуструп — д’Артаньян.

А common lisp на пике развития шахматной мысли чтоле? Единственный «lisp» который может претендовать на поддержку всяких инноваций - это clojure. Все остальныё лиспы приводят те же аргументы что 15 лет назад.

Да ну, на фиг этот clojure - там нет удобного ООП. Это, конечно, модно сейчас ругать ООП и восхвалять ФП, но иногда так нужно это самое «морально устаревшее» ООП, особенно в десктопном софте. Понятно, что в серверном софте приоритеты несколько другие, но далеко не все пишут серверный софт.

Интересно, и что такого по твоему есть в других языках, чего не хватает в common lisp?

Статику не надо здесь предлагать.

ruby и python динамические не потому что фича - а просто потому что их авторы не осилели статический компилятор.

Это неправда.

Python - комьюнити проект. Где то сообщество, которое сделало его статически типизированную версию с выводом типов?

Руби изначально задумывался как «лисп без скобок» - т.е. дин.типизация и метапрограммирование. Получилось в целом не очень, но это другой вопрос и к типизации никакого отношения не имеет. Напомню, что именно на нем, а не на каком-то статически типизированном мамонтовом г-не был написан rails фреймворк, ознаменовавший новую эху в разработке вебни. Прорыв на столько яркий, что кому-то даже стал нужен руби :)

эмбеддед скриптование (js, lua) и шаблонизатор (php) - особый случай когда программа не должна быть законченной

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

то есть до момента исполнения нет целостной системы. Это trade-off а не преймущество.

Это именно, что преимущество. Для целого класса систем.

А clojure динамический абы было потому что lisp.
Мог бы быть статическим так же.

Покажи хоть один пример статически типизированных лисп-макросов.

Покажи хоть один пример статически типизированных лисп-макросов.

Кстати, да. Полноценные статически типизированные макросы еще ни у кого не получились, насколько мне известно. В Nemerle - какой-то мрак в сочетании макросов с объектной моделью .NET, а в Scala нет нетипизированных макросов, без которого сама идея макросистемы не особо жизнеспособна (это к вопросу о преимуществах и недостатках статики против динамики).

Даже какую-то глупую отмазку придумали, что мол, если нужны вам макросы, то вы что-то делаете не так. Право смешно читать их :)

Макросы и динамическая типизация - вещи взаимосвязанные.

Интересно, и что такого по твоему есть в других языках, чего не хватает в common lisp?

Как не странно - юзерфрендлиевость. По уровню шума и трудноси распознавания высокоуровнвой структуры программы глазами s-выражения в топе.

Статику не надо здесь предлагать.

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

f(X) when is_integer(X) -> ....

Это просто типизация для бедняков. Очень многих вещей просто невозможно реализовать нормально - вроде полиморфных функций по типам без введения рантаймового дискриминатора. В достаточно больших программах при эволюции программы не компилятор показывает что ты что-то там забыл - а только рукописные тесты - да и 100% каверейдж нельзя сделать, и grep стал лучшим другом.