Наивысшая производительность цикла разработки и исполнения это причина популярности Java

> На java можно создавать замечательные вещи.

Можно. Но накладно.

> Если бы Лисп стал действительно массовым, то тогда появился бы точно такой же "лиспо-быдло-кодер"... ;)

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

>> На java можно создавать замечательные вещи.

>Можно. Но накладно.

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

> Беда в том, что Лисп, как и Юникс, очень тщательно подбирает себе друзей. В нем любая кривая программа автоматически становится неработоспособной, и именно по этой причине он не становится настолько массовым.

На счет Юникса уже не актуально, потому как и школьник может сейчас поставить на свой домашний компьютер линукс. Что касается кривых программ, то, пожалуй, их количество в линуксе будет даже больше, чем было бы где-то еще (imho). Конечно, есть много очень хороших и качественных программ, но количество поделок просто огромно...

> нас тут давно убедили, один лиспер с толпой макросов заменяет хорошо спаянный коллектив из пяти быдлокодеров.

А можно подробнее?

> Привносимая языком программирования сложность часто мала по сравнению со сложностью самой решаемой задачи.

Это зависит от сложности задачи и выбранного языка для ее решения. Например, "Hello, world" на Лиспе написать проще, чем на Яве.

> В этом смысле лисп не многим лучше той же java.

Но и не хуже.

> На счет Юникса уже не актуально, потому как и школьник может сейчас поставить на свой домашний компьютер линукс.

> Что касается кривых программ, то, пожалуй, их количество в линуксе будет даже больше, чем было бы где-то еще (imho).

Linux Is Not UniX (C) ;-)

> А можно подробнее?

4.1, 4.4 ;-)

>> А можно подробнее?

> 4.1

Да ладно, мы на LOR или где?

> 4.4

Этого совсем не понял

>> 4.4

> Этого совсем не понял

Фразу о Лиспе уже забыли? Или еще одну сделаем?

> Фразу о Лиспе уже забыли?

Помню. Но доказательств с участием лиспера, макросов и быдлокодеров там не помню.

> Или еще одну сделаем?

Не стоит. Вряд ли мы достигнем тех высот :)

> Помню. Но доказательств с участием лиспера, макросов и быдлокодеров там не помню.

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

Косвенно мои выводы подтвердил Бугмакер, который, судя по всему, пишет системы на целевом C с использованием эффективной кодогенерации на Лиспе. Собсно, если заменить С на Яву, то можно достичь того же результата.

> Не стоит. Вряд ли мы достигнем тех высот :)

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

> Там был пример, как многотысячестроковая формальная грамматика сворачивалась в объеме на один-два порядка за счет использования макросов.

Наверное, я что-то упустил. Но не верю я в выигрыши на порядок... сокращение текста ("нажатий на клавиши") - да. Общая трудоемкость - нет.

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

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

> многотысячестроковая формальная грамматика сворачивалась в объеме на один-два порядка за счет использования макросов

Какого языка? Чтобы я знал, что искать в том гигафлейме.

> Общая трудоемкость - нет.

Ну, я там тоже вначале дискуссии высказывал гипотезу, что трудоемкость задачи -- величина инвариантная. От языка просто зависит, чем больше занят программист -- думает или тупо стучит по клавишам. Как известно, "человек должен думать, а машина -- работать" (С). В этом смысле Лисп оказывается перспективнее. Хотя в Яве ту же проблему решают с помощью IDE-костылей, которые заменяют макрогенерацию кодогенерацией, а динамическую адаптацию -- рефакторингом.

> Но не верю я в выигрыши на порядок... сокращение текста ("нажатий на клавиши") - да.

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

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

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

С другой стороны, "на слабо фраеров ловят" (С) ;-)

> Какого языка?

Кажется, я использовал подмножество лексем то ли Python то ли SQL, в реале мне это нужно для PL/SQL.

> Чтобы я знал, что искать в том гигафлейме.

Вот для этого и нужна вика на ЛОРе. Чтобы хоть какие-то элементы дискуссии фиксировать.

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

Еще от него зависит, насколько легко написать код, который потом хренпоймешь.

> С другой стороны, "на слабо фраеров ловят" (С) ;-)

"Всё яд, и всё лекарство" (c). Вообще, провокация как метод развития творческих способностей и обучения - рулит.

>Кажется, я использовал подмножество лексем то ли Python то ли SQL, в реале мне это нужно для PL/SQL.

Вы сейчас о чем? Линком киньте :)

> Еще от него зависит, насколько легко написать код, который потом хренпоймешь.

Особенно, если он потом начинает самосовершенствоваться :-).

Вообще, чего убило в Лиспе, так это парадигма, что "самая лучшая программа -- самая короткая". Не самая простая, не самая регулярная, не самая концептуально-минималистичная, не самая оптимальная по быстродействию, а именно короткая. Потому что а) в такой программе очень тяжело забыть начало прежде, чем напишешь конец и б) меньше вероятность сделать ошибки. То есть, если программу можно сделать на две строки короче, пусть даже хитро извращенным способом, то это лучше сделать. А для тех, у кого проблемы с памятью и IQ рекомендуется такое хорошее и проверенное временем средство, как комментарии к коду. :-)

> Вы сейчас о чем? Линком киньте :)

http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1617637 http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1623715

И вообще, там в свое время, если топик развернуть, то проявлялось основное преимущество Явы в виде OoME :-).

>>Принявший же и постигший истинный свет Его подобен прямой и отточенной стреле

>Маленькая железная головка и перья в заднице.
...
>tailgunner

Ой! Уж лучше жабобыдлокодером ..... :)

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

ну да. вспоминается легендарное:

while(*d++ = *c++);

> А для тех, у кого проблемы с памятью и IQ

А у кого нет? :/

> while(*d++ = *c++);

Ну и рядом, как я уже сказал -- на человеческом языке можно дать комменты для особо одаренных :-).

>> А для тех, у кого проблемы с памятью и IQ

> А у кого нет? :/

А они могут комментарии не читать.

>>> А для тех, у кого проблемы с памятью и IQ

>> А у кого нет? :/

>А они могут комментарии не читать.

Я имел в виду - "А у кого же их нет, этих проблем? Они у всех есть." Ну у меня точно есть :D

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

а где искать условия задач?

> а где искать условия задач?

в гигафлейме "Фраза о Лиспе", где-то в 2-3-й тысяче постов :)

> нет это не FUD.Сколько там у LiveJournal серверков? Побольше сотни, подозреваю, а вот тут forum.ixbt.com люди с перлом мучаются, поэтому скриптовые языки не масштабируемы.

За перл говорить не буду ибо не в теме. Насколько я понял, под масштабируемостью ты понимаешь загрузку всех ядер? Тогда скажу за РОР. Сейчас рабочий сервачок РОР - это связка nginx + mongrel_cluster. Последний представляет собой связку отдельных процессов которые отрабатывают Руби. Тоесть могут работать на отдельных ядрах. Все в порядке у Руби(скриптового языка) с масштабируемостью или я что-то пропустил?

> http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1617637

Это же надо, я такой мега-флейм пропустил...

/me заинтересовался лиспом. Решил освежить память, и как следствие сейчас исполняется команда "sudo apt-get install cmucl" :)

P.S. Для нашей узкой предметной области мне нужно изобрести свой язык. Вернее, его первая версия уже существует, но она довольно-таки проста. Вот, когда пойдет следующая версия с привлечением чего-то более сложного (что-то типа параметризуемой под-модели динамических уравнений внутри более общей модели уравнений), то могут пригодиться шаблоны и готовые решения, реализованные в Лиспе. Конечно, на уровне идей. Поэтому давно хотел посмотреть, что появилось новенького. В общем, спасибо за общение! :)

Есть прикольное видеопособие dsl-in-lisp.mov. Поищи в "Фразе..." ссылку

>> а где искать условия задач?

> в гигафлейме "Фраза о Лиспе", где-то в 2-3-й тысяче постов :)

Спокойно! У нас все ходы записаны :-).

Вот центровая задача -- о лабиринте (network, DSL, AI):

http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1618155

В принципе, для быстрого сравнения достаточно ее. А незадолго до нее задача на каталог ресурсов:

http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1607849 (легкий вариант, контейнеры)

http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1607849 (тяжелый вариант, ORM, DBMS)

Ну и моя техническая задача -- считалка (лексический анализатор, контейнеры):

http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1623405

и уточнение

http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1623715

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

Дык это ж ынтерпрайз серверсайд Жава :) Она не может вынести такой концентрации нас, убогих ндоучек :-P

> Общая трудоемкость - нет.

Именно общая трудоёмкость уменьшается. В первую очередь за счёт большей адекватности языка прикладной задаче. В упомянутом здесь мегафлейме в питоньей версии проги каталогизации файлов тебе понадобилось определять класс, который в лисповой просто-напросто не понадобился, т.е. питон навязал неподходящий в этом часном случае ООП, и вместо того, чтобы выразить решение на языке, пришлось сначала определять объект, а при помощи объекта уже само решение. Т.е. даже на такой крошечной задаче, без всяких макросов и других сверхъестественных, трудоёмкость решения на лиспе уже уменьшилась вдвое. В ucw можно определить компонент, фактически объект. В противоположнось этому в джанге для подобной надобности есть нагромождение конфигов, шаблонов, шаблоньих тегов, и протчая и протчая, из-за того что навязываемая питоном реализация ООП неполноценна и недостаточна для решения данной задачи, и приходится йузать более левые методы. И тут уже разница в трудоёмкости только при разработке в разы, а при суппорте ваще неимоврна. А уж с применением макросов, всяких дслей и прочего, даже оценка разницы в общей трудоёмкости в один-два порядка может быть сильно занижена...

лор это не энтерпрайз, лор это хэндмейд.

> упомянутом здесь мегафлейме в питоньей версии проги каталогизации файлов тебе понадобилось определять класс, который в лисповой просто-напросто не понадобился

Не мне. red_vasiliy мне, конечно, тезка, но это не я. Мне, кстати не особо понравилось его решение - он не "конкурсное", не вылизанное.

Ну, твое отношение к Питону я знаю...

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

Блин... 2 порядка - это 100 раз. Ты сам-то в это веришь? "Ох уж мне эти сказки, ох уж мне эти сказочники" (c)

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

java как платформа - энтерпрайз. лор как форум точно не энтерпрайз.

разделяемсссс

> Не мне. red_vasiliy мне, конечно, тезка, но это не я

Аха, извиняй, обознатушки.

> Мне, кстати не особо понравилось его решение - он не "конкурсное", не вылизанное.

Другого тем не менее не было.

> Блин... 2 порядка - это 100 раз. Ты сам-то в это веришь? "Ох уж мне эти сказки, ох уж мне эти сказочники" (c)

В том треде была сцылко на статью где описывалось ос+набор системного и прикладного ПО для неё, написатое полностью на лиспе. Там приводился расклад по объёму кода в сравнении с другими осами. А факт, что выродить строчку на лиспе проще чем на многих других наречиях, мы уже вроде выяснили.

> Другого тем не менее не было.

:/

>> Блин... 2 порядка - это 100 раз. Ты сам-то в это веришь? "Ох уж мне эти сказки, ох уж мне эти сказочники" (c)

> В том треде была сцылко на статью где описывалось ос+набор системного и прикладного ПО для неё, написатое полностью на лиспе.

Это доказывает _только_ факт, что на Лиспе можно написать ОС для Лисп-машины. А подробного анализа функциональности той ОС (GeneraOS?) дано не было.

> А факт, что выродить строчку на лиспе проще чем на многих других наречиях, мы уже вроде выяснили.

Я не стану спорить, где проще выродить строчку... и не стану спорить, строчку на каком языке проще понять. Ты назвал цифру - 100 раз. Итак, веришь ли ты, что использование Лисп повышает производительность труда программиста в 100 раз?

> Это доказывает _только_ факт, что на Лиспе можно написать ОС для Лисп-машины. А подробного анализа функциональности той ОС (GeneraOS?) дано не было.

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

> Ты назвал цифру - 100 раз. Итак, веришь ли ты, что использование Лисп повышает производительность труда программиста в 100 раз?

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

> Не помню, были ли ссылки изнутра этой статьи на интересующие тебя подробности, но думаю при желании эти подробности можно было найти.

Вот и я не припомню ссылок. Но я немного читал об ОС для Лисп-машин. Там нет ничего такого, чего не было бы в современных системах. Это косвенно опровергает гипотезу о снижении трудоемкости в 100 раз (по крайней мере, для ОС) - если бы так, то уж что-нибудь эдакое они бы замутили :)

> Да, я верю что существуют задачи, решение которых на лиспе менее трудоёмко в 100 и более раз.

Извини, но твое "Да, я верю" напоминает "Верую, ибо нелепо" :D. Список задач - в студию (лучше тех, с которыми ты сталкивался).

> Но я немного читал об ОС для Лисп-машин. Там нет ничего такого, чего не было бы в современных системах.

Само собой. Если бы понадобилось что-то ещё, оно бы непременно появилось И в лисповых И в "классических" осах.

> Это косвенно опровергает гипотезу о снижении трудоемкости в 100 раз (по крайней мере, для ОС)

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

> Извини, но твое "Да, я верю" напоминает "Верую, ибо нелепо" :D

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

> Список задач - в студию (лучше тех, с которыми ты сталкивался).

Например упомянутая мной здесь джанга vs ucw. Кое-что было упомянуто также в "фразе о лиспе".

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

AFAIK, они все закрытые. Открытая ОС на Лисп так никуда и не продвинулась. Так что сравнить объем кода трудновато :(

>> Список задач - в студию (лучше тех, с которыми ты сталкивался).

> Например упомянутая мной здесь джанга vs ucw

Мне бы хотелось, чтобы ты прямо сказал: "UCW повышает производительность программиста в 100 раз по сравнению с Django". Или хотя бы что он повышает твою личную производительность в 100 раз.

>Весь цымес в соотношении объёмов кода.

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

http://ertos.nicta.com.au/research/l4.verified/ http://coyotos.org/

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

CoyotOS пишется на BitC, который ооочень похож на Лисп :-P Только ничего у них не получится.

не надо путать вид синтаксиса с Operational Denotational etc семантиками. у них всё очень низкоуровнево, и заточено под верификацию.

> не надо путать вид синтаксиса с Operational Denotational etc семантиками

А я путаю? :-P

"BitC is conceptually derived in various measure from Standard ML, Scheme, and C" - такой вот странный родственничек есть у Лиспа :D

> у них всё очень низкоуровнево, и заточено под верификацию.

Ликбез не нужен, спасибо ;)

> AFAIK, они все закрытые. Открытая ОС на Лисп так никуда и не продвинулась. Так что сравнить объем кода трудновато :(

Найди ту статью да почитай, там всё уже сравнено

> Мне бы хотелось, чтобы ты прямо сказал: "UCW повышает производительность программиста в 100 раз по сравнению с Django". Или хотя бы что он повышает твою личную производительность в 100 раз.

Дык я вроде прямо и сказал. На единицу сложности задачи он повышает в N раз, где N (существенно) больше единицы. Соответственно при достаточно сложной задаче будет повышать в 100, 300, и более раз. Чё не так?

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

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

ну может я че то путаю ... зато L4 на с++ писан.

>родственничек есть у Лиспа :D

может там от схемы только синтаксис ? ;)

> Дык я вроде прямо и сказал. На единицу сложности задачи он повышает в N раз, где N (существенно) больше единицы. Соответственно при достаточно сложной задаче будет повышать в 100, 300, и более раз. Чё не так?

Хотелось получить человеческую фразу, а не наукообразный канцелярит :)

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