Комментарии 59
1. Не вижу смысла в посте.
2. Код на Lisp достаточно хорошо читается, и никак не препятствует построению больших систем.
По моему опыту код на С++ читать гораздо труднее, учитывая что аналогичная программа написаная на Lisp будет гораздо меньше по объему(кода) + нет необходимости сборки мусора. А реальная проблема самого языка это малое количество обучающей литературы и репутация языка как исключительно академического.
2. Код на Lisp достаточно хорошо читается, и никак не препятствует построению больших систем.
По моему опыту код на С++ читать гораздо труднее, учитывая что аналогичная программа написаная на Lisp будет гораздо меньше по объему(кода) + нет необходимости сборки мусора. А реальная проблема самого языка это малое количество обучающей литературы и репутация языка как исключительно академического.
Relax and just have fun!
ps
А чтож его никто не использует? =)
ps
А чтож его никто не использует? =)
потому что пипец — понять человеку, знающему С++/C#/Java этот винегрет невозможно — поэтому мало спецов по Lisp, что влечет дороговизну разработки, что влечет отсутствие большего количества решений. но да, иногда в Lisp'е в 30 строках выражается 1000 строк C# — но понять их C#нику невозможно от того считается, что нафиг так писать.
А люди пишут программы что бы что-то с ним делать или что бы код был правильный и красивый?
да.
когда хоть раз поработаете в команде, поймете. сейчас, вряд ли.
когда хоть раз поработаете в команде, поймете. сейчас, вряд ли.
Когда вы первый раз будете отвествены за результат — тогда поймете. Сейчас, вряд ли. Очень печально заканчиваются разговоры с гендирами на тему «мы так хорошо код пишем, аж пипец».
очень аргументированно. серьезно, поработайте в команде, когда нибудь и поруководить датут.
Ага, будем устраивать каждый день митинги о нейминг конвеншину, потом полдня на эдукацию молодых, еще о перспективах рефакторинга на следющий год, да еще наверно семинар о полезности составления коментариев в 500 строк на каждый метод=)
А вот когда станет вопрос ребром кто все это оплатить, тогда вот будет веселие=)
«Крутой код» это не показатель «правильности» программы, а нужное «зло» для того, что бы все не обрушилось к чертовой матери. Роль управленца не заключается в том, что бы его команда писала хороший код, а что бы его команда сдала работающий проект вовремя.
А вот когда станет вопрос ребром кто все это оплатить, тогда вот будет веселие=)
«Крутой код» это не показатель «правильности» программы, а нужное «зло» для того, что бы все не обрушилось к чертовой матери. Роль управленца не заключается в том, что бы его команда писала хороший код, а что бы его команда сдала работающий проект вовремя.
еще раз повторяю, поработайте в команде, все ваши заблуждения мигом испорятся.
сразу поймете, что это роль менеджера проекта сдать все во время, ему вообще до фени ваш код и его качество. а вот роль team leader как раз чтобы все соблюдали naming convention, как раз о перспективах рефакторинга на следующий год и на столетие вперед и т.д.
конечно, если вы попадете в outsourcing или в команду, где одни контрактники — вот там будет алес — похуй какой код, главное вовремя.
сразу поймете, что это роль менеджера проекта сдать все во время, ему вообще до фени ваш код и его качество. а вот роль team leader как раз чтобы все соблюдали naming convention, как раз о перспективах рефакторинга на следующий год и на столетие вперед и т.д.
конечно, если вы попадете в outsourcing или в команду, где одни контрактники — вот там будет алес — похуй какой код, главное вовремя.
Lisp построен так что весь код выглядит однородно и модифицируется с минимальными усилиями. В подавляющем большинстве случаев даже сам код модифицировать не нужно, а достаточно внести изменение в используемый макрос.
а с чего вы взяли что его никто не использует?
Тут работает принцип worse is better. Поэтому он не станет mainstream языком, да и не надо.
Тут работает принцип worse is better. Поэтому он не станет mainstream языком, да и не надо.
Вопрос поставлен неправильно, если Lisp используют меньше чем Java или С# это не значит что его не используют.
Какова цель поста? Вставить тупые шуточки напротив неугодных вам комментариев?
Про шутки — ваше мнение, а комментарии настолько непонимающие суть и неправильны, что даже объяснять почему не хочется.
Читайте книжки, учитесь в унивеститетах, на курсах и все поймете.
Читайте книжки, учитесь в унивеститетах, на курсах и все поймете.
То же самое можно сказать о ваших комментариях в той теме.
Их суть сводится к следующему: попробовал писать на лиспе, получилось говно, следовательно лисп говно. Умерьте своё ЧСВ и поймёте, что причина не в лиспе.
Их суть сводится к следующему: попробовал писать на лиспе, получилось говно, следовательно лисп говно. Умерьте своё ЧСВ и поймёте, что причина не в лиспе.
Автор обливает говном комментаторов.
+
Комментаторы обливают говном автора.
=
доставляющая рекурсия
+
Комментаторы обливают говном автора.
=
доставляющая рекурсия
Посольство лора на хабрахабре?
Где тут смеяться? Кстати, пост задумывался как смешной или мне показалось?
И да, лисп — язык чуть более чем полностью состоящий из смайликов.
И да, лисп — язык чуть более чем полностью состоящий из смайликов.
Петросян?
Тем кто минусует этот пост (от меня):
Совет вам мой таков, на порно-сайты чаще идите. В лиспе у вас нужда исчезнет! =)
Совет вам мой таков, на порно-сайты чаще идите. В лиспе у вас нужда исчезнет! =)
До чего же убого выглядят хабровские лиспосрачи по сравнению с ЛОРовскими! Никаких тебе примеров кода, ссылок на бенчмарки, нецензурной брани, цитирования фрагментов статей по теории категорий, сравнений с C++, обвинений, отсылок к SICP, страшных проклятий в адрес оппонентов и фраз типа «слив засчитан» в каждом третьем комментарии.
Есть прекрасный старинный двухтомник финских авторов «Мир лиспа». К сожалению, авторов не помню, а он на даче. Крайне рекомендую всем, потому что книжки не только и не столько о Лиспе. Знаком с лиспом через emacs. Думаю, что этот язык обязательно нужно проходить на компьютерных специальностях. Это как матан — не факт, что пригодится сам по себе, но мозги отструктурирует как положено. :)
Хювёнен Э., Септянен И. «Мир Лиспа.» 2 т. 1990.
Найти в поисковике и скачать можно. Купить — вряд ли.
Много ли из сегодняшних книг можно будет читать с пользой для дела через 20 лет?
Найти в поисковике и скачать можно. Купить — вряд ли.
Много ли из сегодняшних книг можно будет читать с пользой для дела через 20 лет?
Вы несомненно правы!
В академических целях он необходим. Никто с этим и не собирался спорить…
Спор шел в совсем другом русле, что для коммерческих и бизнес штучек, он не особо приспособлен… Так получилось…
НО лиспофили этого признать не хотят=) и продолжают упорно отстаивать свой взгляд на этот мир=)
В академических целях он необходим. Никто с этим и не собирался спорить…
Спор шел в совсем другом русле, что для коммерческих и бизнес штучек, он не особо приспособлен… Так получилось…
НО лиспофили этого признать не хотят=) и продолжают упорно отстаивать свой взгляд на этот мир=)
В том двухтомнике есть один момент по поводу Лиспа, который не устареет никогда — там показано, как хорошо Лисп подходит для реализации различных парадигм программирования — без расширения базового синтаксиса. Читается как художественная литература.
Зачем спорить? Языков программирования меньше не становилось никогда. Отдельный вопрос почему функциональные языки и прежде всего Лисп не применяются более широко — особенно для задач, которые на них решаются естественнее. Тут, я думаю, academia и подкачала — преподавать их надо, чтобы потом у человека была свобода выбора. Хотя и так Лисп развивается и чувствует себя прекрасно — взять опять же Clojure. С ростом значения семантики в сети и Петером Норвигом в Гугле, у Лиспа есть все шансы на ещё более прекрасное будущее.
Зачем спорить? Языков программирования меньше не становилось никогда. Отдельный вопрос почему функциональные языки и прежде всего Лисп не применяются более широко — особенно для задач, которые на них решаются естественнее. Тут, я думаю, academia и подкачала — преподавать их надо, чтобы потом у человека была свобода выбора. Хотя и так Лисп развивается и чувствует себя прекрасно — взять опять же Clojure. С ростом значения семантики в сети и Петером Норвигом в Гугле, у Лиспа есть все шансы на ещё более прекрасное будущее.
Возможность Lisp, которые позволяют бороться со сложностью крупных систем (против которых, как уже показала практика, ООП-подход бессилен) — это возможность создания многослойных слабосвязанных систем за счет проблемно-ориентированного программирования (прежде всего на основе макросов)
В C# и C++ все то же самое, только синтаксис короче и лучше читается :(. Компоненты, объекты, шаблоны, делегаты, наследование, полиморфизм, инкапсуляция. Что такого есть в Лиспе, чего нет в C#+ и .NET или C++ и Qt? А еще в для C# и C++ есть современные среды разработки с разными полезными рефакторингами и отладчиками, удобные библиотеки «под ключ» и кроссплатформенность из коробки.
Вопрос — зачем Lisp?
P.S. Я люблю и использую Lisp + Emacs. Просто не совсем понимаю зачем это нужно если есть более современные языки с библиотеками?
Хотел бы уточнить, диспатчеризация вызовов — это перегрузка метода по русский сказано, да? И чем же она отличается от такой в любом ООП ЯП который ее поддерживает?
Ну вы меня одновременно запутали и заинтересовали. Обязательно почитаю, тем боле, я академическую ценность lisp никогда не ставил под сомнение.
Но, опять же, если функции не являются членамы класса, значит нет инкапсуляции, которая и есть основа ООП, или я не так понял?
Диспатчеризация по значению — это выбор метода не по типу параметра а по его значению? А как бы это использовать?
Все же, эта впечатляющая гибкость, если ее применять, не будет ли она слишком большим количеством гранат на единицу обезян?
Но, опять же, если функции не являются членамы класса, значит нет инкапсуляции, которая и есть основа ООП, или я не так понял?
Диспатчеризация по значению — это выбор метода не по типу параметра а по его значению? А как бы это использовать?
Все же, эта впечатляющая гибкость, если ее применять, не будет ли она слишком большим количеством гранат на единицу обезян?
Я немного знаком с CLOS. C++ и Qt дают диспатчеризацию вызовов, на мой взгляд, не хуже. Концепции 'after', 'before' и 'around' — это, насколько я понимаю, все же паттерн, и на том же Qt реализуется без дополнительных макросов в то же количество строк кода.
Если не секрет, чем метапрограммирование в C++ и Qt хуже, чем в LISP? Я редко пользуюст defmacro, поэтому, возможно, что-то упустил?
Если не секрет, чем метапрограммирование в C++ и Qt хуже, чем в LISP? Я редко пользуюст defmacro, поэтому, возможно, что-то упустил?
Давайте посмотрим пример выше (это я не в плане спора, а в плане повышения своей квалификации, бо lisp знаю намного хуже, нежели C++ или C#).
В C# есть, с C++ и Qt нету. Но это легко решается конструкцией вида
Есть как в .NET (Windows Communication Foundation) так и в C++ с Qt (advanced signals and slots).
В C# не помню, в C++ с Qt легко и непринужденно, сигнал можно обрабатывать по любому условию.
Тут надобно ваше уточнение:
1. Что значит 'добавить код'? pre- и post- операции, или изменение кода метода?
2. Специализированного для экземпляра класса или для описания класса?
В примере очень много текста :(.
Макросы как метопрограммирование несколько устарели, они были в C. Для C++ — шаблоны и moc-система Qt. Шаблоны замечательно проверяют типы, выполняются во время компиляции (на них даже тетрис сделали) и позволяют делать практически любые нетривиальные вещи. Специальный язык позволяют делать на раз-два, см. язык построения лексических выражений в boost.
Я правильно понимаю, что ы сухом остатке имеет только отсутствие поддержки mixin в C++ на уровне языка? Задача не очень часто возницающаяся и решаемая как я описал выше в несколько лишних символов.
Mixin
В C# есть, с C++ и Qt нету. Но это легко решается конструкцией вида
QString sText = ""; MyMixin( sText ).MyMethodAddedToQString();
диспатчеризация по нескольким параметрам
Есть как в .NET (Windows Communication Foundation) так и в C++ с Qt (advanced signals and slots).
диспатчеризация по значению
В C# не помню, в C++ с Qt легко и непринужденно, сигнал можно обрабатывать по любому условию.
возможность добавить какой-то код, к методу, специализированному для конкретного класса — например, для проверки значений, или конвертации значений
Тут надобно ваше уточнение:
1. Что значит 'добавить код'? pre- и post- операции, или изменение кода метода?
2. Специализированного для экземпляра класса или для описания класса?
В примере очень много текста :(.
насчет метапрограммирования — в C/C++ макросы — это простые подстановки текста
Макросы как метопрограммирование несколько устарели, они были в C. Для C++ — шаблоны и moc-система Qt. Шаблоны замечательно проверяют типы, выполняются во время компиляции (на них даже тетрис сделали) и позволяют делать практически любые нетривиальные вещи. Специальный язык позволяют делать на раз-два, см. язык построения лексических выражений в boost.
Я правильно понимаю, что ы сухом остатке имеет только отсутствие поддержки mixin в C++ на уровне языка? Задача не очень часто возницающаяся и решаемая как я описал выше в несколько лишних символов.
Я не знаток Qt, но он выше головы С++ не прыгнет
Прыгнет, к сожалению :(. Там небольшой препроцессор, который чуть-чуть расширяет язык.
но это уже получается отдельный язык
Я ждал этого утверждения :). Но ведь, согласитесь, и Lisp 60-го года выпуска тоже не имеет ни CLOS, ни библиотек — ВООБЩЕ ничего. Все, что Вам в Lisp нравится — это как бы расширения языка, «библиотеки» и «препроцессоры» в терминологии C# / C++.
Шаблоны и метапрограммирование в C++ могут решить часть задач, но это не прямая замена лисповым макросам — они не генерят исходный текст на С++, как генерят макросы лиспа
Позволю себе с Вами не согласиться. Я неплохо разбираюсь в шаблонной магией и могу со всей ответственностью заявить, что конструкция template<> как раз генерит исходник. Его даже можно посмотреть с правильными ключиками компилятора.
время компиляции увеличивается очень сильно
Не настолько. Проект на 10 миллионов строк кода будет одинакого долго компилироваться что на C++ с шаблонами, что на C#, что на Lisp.
и оно дурит на достаточно сложных грамматиках
Узкоспециализированная задача, не для языка общего назначения. Драйвер на Lisp тоже будет… э… дурить :). Для решения узкоспециализированных либо выбирается узкоспециализированный язык, либо используются другие подходы. Конкретно для создания парсеров языков по грамматике в случае C++ и C# это будет yacc/lex.
К тому же стоит не забывать, что в промышленной разработке часто используются старые компиляторы, которым становится плохо от шаблонов — у меня сейчас в поддерживаемых платформах VC6, gcc 3.3, старый сановский компилятор и т.д.
В целом согласен. Но LISP 60-го года выпуска тоже, вообщем-то, не то что сегодняшний common lisp или clojure :). Подразумевается, что при сравнивании технологий для НОВЫХ проектов мы выбираем из имеющегося широкого спектра решений. Понятное дело, что если есть какие-то специфические ограничения на выбор технологий, то от этих ограничений и нужно будет плясать. Если корпоративным стандартом является Java определенной версии, то тут даже Clojure не поможет :).
насчет добавления кода — CLOS дает возможность выполнения некоторого кода до или после (в стандартных комбинаторах) вызова основной функции, специализированной для определенного класса. Например, с его помощью можно добавить pre и post проверки к уже написанному коду (к которому даже может не быть доступа). Или, как в примере из PCL, разрешить операцию снятия денег для банковского счета с разрешенным овердрафтом, если там не хватает денег.
Вообще такие задачи принято решать паттерном «фасад обычный, штукатуреный». Но если интересует поддержка в языке, то и в C#, и в C++ с Qt такое есть. Просто используется редко. Код неудобный в поддержке получается — без поллитры дебага не разберешся где там кто постусловие поставил :(.
Ну что, мне удалось немного покритиковать утверждение
Возможность Lisp, которые позволяют бороться со сложностью крупных систем (против которых, как уже показала практика, ООП-подход бессилен) — это возможность создания многослойных слабосвязанных систем за счет проблемно-ориентированного программирования (прежде всего на основе макросов)? :)
в последние годы появились средства (в первую очередь в C#/.Net) которые позволяют упростить процесс создания ПО. Но такой гибкости языка пока ни у кого нет :-)
В целом соглашусь. Но эта гибкость не бесплатна. Она за счет крайней простоты базового синтаксиса языка. Тем не менее, практически все реально востребованные возможности есть в C# и C++, но там это на уровне синтаксиса самого языка, что значительно упрощает чтение когда. Я, наверное, уже слишком стар, но конструкции вида
(defun ido-file-extension-lessp (a b)
(let ((n (compare-strings a 0 nil b 0 nil nil))
lessp p)
(if (eq n t)
nil
(if (< n 0)
(setq n (1- (- n))
p a a b b p
lessp t)
(setq n (1- n)))
(cond
((= n 0)
lessp)
((= (aref a n) ?.)
(ido-file-extension-aux a b n lessp))
(t
(while (and (> n 2) (/= (aref a n) ?.))
(setq n (1- n)))
(if (> n 1)
(ido-file-extension-aux a b n lessp)
lessp))))))
Немного депрессивно действуют на психику :(.
Паттерн очень спорный, к сожалению. Как я уже писал, в C# и C++ с Qt такое тоже есть. Оно, конечно, удобно в текстовом рдакторе сделать хук в две строчки. Но на сложных системах приведет к проблемам с отладкой, потому как сильно добавляет связанности компонентам системы :(. Обычно такие вещи делаются через IOC-фреймворки в строго отведенных для этого местах. Handler chains и все такое :).
Вот хорошая статья на тему слабой распространенности лиспа. В частности, на примере реализации ОО для лиспа и С утверждается, что сложность задачи для последнего настолько велика, что на тот момент было всего две успешные попытки (С++ и Objective C). В то время, как реализация того же на примере Scheme требует квалификации студента 4 курса. В итого, для С++ были разработаны стандарты, написана куча книг, сертификации, публикации и т.д. А для лиспа (Scheme) никто не заморачивался, потому что это настолько просто, что нафига стараться…
Итог, мощь языка — его проклятье!
Итог, мощь языка — его проклятье!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Lisp — экзотика рулит