Попробую объяснить, почему совершенного reflection/serialization/metaprogramming/etc.
framework'а для плюсов не будет никогда ;-(
Я долгое время был болен идеей создания Framework'а для С++ с поддержкой
удобной сериализации, reflection, расширяемого синтаксиса, метапрограммирования (например,
произвольной генерации proxy-классов и пр.) и прочей фигни в C++, с сохранением
темплейтов и пр. (Сам я много писал на C++, последние годы по работе пишу в основном
под .NET — C#/VB.NET). Много смотрел в сторону BOOST. Некоторый интерес представляет
и "quasireflection" в Qt, на котором построены signal-slots, QSA и пр. Достаточно быстро
убедился что и то, и другое, и прочие существующие решения не предлагают всего необходимого
для подобного "супер-мега-framework"'а. По сему я решил заняться кодогенерацией на основе
трансформаций AST (Abstract Syntax Tree). Посмотрев ANTLR и пр., я подумал, что лучше
(относительно) хорошего компилятора тяжёлый синтаксис C++ никто не распарсит, решил
использовать GCCXML.
С GCCXML история достаточно интересная -- это патч для GCC, который дампит наиболее
интересную информацию из AST в виде XML. Разработчики GCC активно сопротивляются
поползновениям по поводу включения таких фич в мейнстримный GCC, т.к. боятся, что
нехорошие коммерческие дяди начнут использовать GCC в качестве халявного frontend'а для
своих коммерческих компилеров, и GPL тут не поможет — никто ни с кем не линкуется,
просто подцепляется XML из GCC. Как следствие подобной политики, GCCXML существует
как отдельный продукт.
Далее была задача — как всё-таки обрабатывать эти самые деревья. Использовать DOM или
какие-либо иерархические структуры, написанные на тех же плюсах, всё-таки не очень удобно —
поэтому я решил использовать что-то специализированное. Сначала я попробовал XSLT.
Больших успехов я не добился, но неожиданно для себя обнаружил, что на этом языке,
лишённом даже таких простых вещей, как присваивание и циклы (кроме итераций по
nodeset'ам вроде <xsl:for-each>), можно сделать достаточно многое, используя
элементарную рекурсию. Это меня постепенно подтолкнуло к изучению языка Scheme.
Я достаточно быстро загорелся идеей создания ну-просто-сверх-очень-всесторонне-полезного
трансформера AST и кодогенератора C++ на Scheme, использующего пакеты
SXML/SXPath/etc. ( http://okmij.org/ftp/Scheme/xml.html ).
В Схеме меня привлекли две вещи — очень удобная обработка деревьев и списков,
как нельзя лучше подходящая для моей задачи, а также символьные выражения, которые
в очень многих случаях в десятки раз проще, чем XML, подходят для различных декларативных
языков (в данном случае я собирался использовать эту декларативность для компактного
описания трансформаций — например, формирования proxy-классов, кода для каких-нибудь
binding'ов и пр.) Также меня очень порадовал функциональный стиль программирования,
хорошо подходящий для "деревообработки".
Через достаточно непродолжительное время я для себя неожиданно обнаружил, что Схема,
оказывается, годится не только для "перелопачивания деревьев". Оказывается, можно
на полном серьёзе на подобных языках писать чуть ли не серьёзные приложения. Взять
хотя бы тот же SCSH ( http://www.scsh.net/ ) — заменитель Unix-shell'а. При программировании
можно использовать "гигиенические макросы" — название, ммм, неблагозвучное, но
это в ряде случаев существенно более удобный инструмент metaprogramming'а,
чем C++'ные templates, и Схему на Схеме генерить проще, чем C++ — ведь программа
по своей структуре — тот же список, состоящий из cons cells.
В то же время у Схемы есть ряд проблем — стандарт задаёт очень небольшой набор фичей,
к которым не относятся, например, объектно-ориентированное программирование.
В результате у каждой реализации свои классы, свои модули/неймспейсы
и т.д. В принципе юзабельно, но "корявовато". Как возможное решение, прежде чем
возвращаться к написанию ну-просто-сверх-очень-... трансформера, я решил глянуть
Common Lisp, язык, вроде бы похожий на Схему, в некоторых отношениях вроде бы
несколько менее элегантный, зато хорошо стандартизованный (стандартная библиотека
вроде как ни в чём не уступает C++'ной).
В результате я посмотрел на Common Lisp, и быстро понял, что на самом деле C++'у
никакие костыли не помогут, т.к. это не Лисп Почему именно — можно почитать можно
в целом ряде мест, например, тут -- http://www.gigamonkeys.com/book/introduction-why-lisp.html
(не говоря уже про товарища Грэхэма и пр.) Мощный компилируемый язык, с лучшей
поддержкой метапрограммирования и DSL, ох**тельной объектной системой (CLOS),
лексическими замыканиями, интерактивным стилем разработки (REPL), GC, развитой
системой исключений и т.д. и т.п. Проблема у этого языка одна: Лисп есть могучий
усилитель мысли, и тем, у кого мысли, как правило, отсутствует, он ничем не поможет
(т.к. нечего усиливать). Так что если человек собирается всю жизнь зарабатывать себе
на хлеб, таская контролы мышкой по формам, подобный инструмент пользы не принесёт.
С этим связана и сравнительно низкая распространённость языка и его странная репутация
(якобы медленный/трудный/нечитабельный/только AI/чисто академический/непригодный для
реальных приложений/интерпретируемый/чисто функциональный/без поддержки ОО/прочий БРЕД),
из-за которой я, ёлки-палки, столько лет программировал (и до сих пор программирую
по долгу службы) на всякой [ерунде].
Как следствие, мне стало ясно, почему C++'у не светит радикальное улучшение в области
того же метапрограммирования, расширяемых компиляторов и пр. Когда люди начинают
углублённо заниматься подобными вещами, пытаясь усовершенствовать язык, они неминуемо
обнаруживают, что нечто гораздо более _простое_ и удобное уже изобретено до них,
и нызывается оно Лиспом.
Возникает вопрос -- если Лисп столь удобен, то почему же вещи типа Java, C#, C++,
Delphi используются гораздо более широко?.. Наиболее полный ответ на данный вопрос
дан Станиславом Лемом в произведении "О выгодности дракона" ("Звёздные дневники
Ийона Тихого") — http://lib.ru/LEM/lemitdr.txt, описывающий планету, на которой
жил, казалось бы, всесторонне вредный Дракон (занимал территорию, жрал туристов,
вонял и т.д.), от которого, тем не менее, не спешили избавиться:
"Если бы не дракон, для кого мы производили
бы трубопроводы, которыми в него качают мучной отвар? А ведь это — и
металлургические комбинаты, и трубопрокатные станы, и сварочные автоматы,
и транспортные средства, и так далее. Дракон имеет реальные потребности.
Ну, теперь понимаете? Производство должно на кого-то работать!
Промышленники не производили бы ничего, если бы готовый продукт
приходилось выбрасывать в море. Реальный потребитель — Другое дело. Дракон
— это громадный, необычайно емкий заграничный рынок, с колоссальным
спросом..."
Точно такая же ситуация оформилась в IT — если заменить дракона — миллионные армии не
желающих чему-либо учиться квазипрограммеров, ваяющих формочки и не желающих
слышать не то что про Лисп, но и даже про те же элементарные Design Patterns,
несколькими defmacro, то погибнет целая развитая индустрия по производству красивых
и удобных средств "разработки" для тех, кто в действительности по просту не умеет
программировать и, вместо того чтобы честно махать на улице метлой, протирает до дыр
ни в чём неповинные мышиные коврики.
"Благодаря" этому дракону мне лично приходится (надеюсь, только до поры-до времени)
писать не только на Лиспе, но и на шарпе, плюсах и дельфях. Делаю я это с отвращением,
но в то же время заметил, что, когда знаешь Лисп, на "inferior" языках программировать
становится в некоторой степени проще. Объясняется это тем фактом, что вещи, витающие
у тех же плюсовиков где-то между сознанием и подсознанием и затем посредством весьма
тернистого пути преобразующиеся в код, могут быть явно оформлены на Лиспе в виде
символьных выражений -- просто запиши свою мысль, а затем расставь где надо скобки.
Благодаря этому складывается гораздо более чёткое представление о сущностях типа
лексических замыканий и комбинаций методов, бледным отражением которых являются
паттерны проектирования. Более того, Лисп учит реально работать с теми же closures —
да, их добавили в C# 2.0 (+ они уже давно есть в JavaScript), но, скорее всего, большинство
шарповиков будет их юзать лишь для эвент хендлеров, т.к. о более серьёзных применениях
они и не подозревают.
Я уже не говорю о том, что, когда я работаю в супер-пупер-рюшечном VS .NET 2003, мне
до зубной боли не хватает элементарного Emacs+SLIME с его REPL'ом -- Command Window,
мягко скажем, не дотягивает. У меня начинают болеть пальцы при наборе пропертей
и тому подобной хрени (до чего удобны CLOS accessors!). Меня бесит, что там, где
я мог бы написать одну грёбанную функцию с keyword arguments, я должен писать класс
или кучу дурацких оверлоадов. Я это говорю, как профессиональный .NET программер
с далеко не самой низкой зарплатой среди присутствующих (судя по местным опросам;
воздержусь от конкретной цифры).
В общем и целом могу сказать следующее. У тех, кто сейчас пишет на плюсах, под .NET,
Java, Delphi и пр., есть только два пути не тратить почём зря своё время:
1. Смириться. Не пытайтесь расширить свою среду. У этих расширений есть потолок, и
не очень высокий. Кропайте методы, пишите message maps, не нравится — используйте
Qt/moc и пр. Не тратьте зря время на создание радикальных расширений. Да, работа
так и останется нудной, но что ж поделаешь, жрать-то надо. Создание крутых фреймворков
вместо реальной работы — хороший способ срыва проектов. И т.д., и т.п.
2. Учиться. Если у Вас есть немного свободного времени, потратьте его часть на изучение
языков, которые заставляют человека _думать по другому_. Изучите Lisp, Prolog, Haskell,
SML, Smalltalk, Erlang (особое внимание стоит уделить Common Lisp'у, как языку
расширяемому и наиболее практичному). Не давайте мозгам заржаветь, учитесь мыслить шире.
Для начала, это поможет Вам стать хорошим программистом, даже если на хлеб себе вы будете
зарабатывать, программируя на других языках. Все мейнстримные языки построены,
как правило, по принципу "те же яйца, вид сбоку". Осознайте, что мир на самом деле
не сошёлся на лежащем в их основе наборе стандартных парадигм.
Прошу прощения, если вышеприведённое чем-то напоминает поток сознания, писалось
всё урывками. Nevertheless I hope you'll find it useful
Здравствуйте, <Аноним>, Вы писали:
А> [ skipped — много всего про Common Lisp ]
Немного offtopic, но все же...
Неужели CL — настолько замечательный и почти-для-всего-подходящий язык? В частности (если сравнивать с C++):
1. Позволяет ли он (теоретически, если бы были необходимые библиотеки) безпроблемно запрограммировать приложения, которые сейчас пишут на C++ или на C#/VB/Java/Delphi (имеется в виду mainstream, а не экзотика вроде real-time)?
2. (Вроде бы) известно, что CL поддерживает много чего, что не поддерживает C++. А наоборот? Верно ли, что все, что поддерживает C++ (исключая низкоуровневое вроде прямого доступа к памяти), поддерживается в CL? Т.е., является ли прогматика CL надмножеством прагматики С++? ("Прагматика" здесь используется в смысле определения, данного в http://it.kgsu.ru/Lisp/lisp0088.html.)
pvgoran wrote:
> А> [ skipped — много всего про Common Lisp ] > Немного offtopic, но все же... > Неужели CL — настолько замечательный и почти-для-всего-подходящий > язык? В частности (если сравнивать с C++): > 1. Позволяет ли он (теоретически, если бы были необходимые библиотеки) > безпроблемно запрограммировать приложения, которые сейчас пишут на C++ > или на C#/VB/Java/Delphi (имеется в виду mainstream, а не экзотика > вроде real-time)?
Позволяет. Хотя в нем должен быть GC
> 2. (Вроде бы) известно, что CL поддерживает много чего, что не > поддерживает C++. А наоборот? Верно ли, что все, что поддерживает C++ > (исключая низкоуровневое вроде прямого доступа к памяти), > поддерживается в CL?
Нет, хотя при желании достижимо.
Вообще, в CL мне не понравилось полное отсутствие нормального синтаксиса
(LISP=Lots of Incredibly Silly Paranthesis) и нестатическая типизация.
ЗЫ: Губанова бы с его "звезданутым" подсчетом скобок натравить на Lisp.
Он ТААААКОГО бы оверхеда насчитал....
Что будут стоить тысячи слов,
Когда важна будет крепость руки?
И вот ты стоишь на берегу
И думаешь: плыть или не плыть?
В.Цой
Выделим акценты?
Мне понравился пост уважаемого Аноним-а. Как небольшое литературное произведение. Но, спустя небольшое время, из всего текста больше всего внимание стали привлекать вот эти два абзаца:
А>Точно такая же ситуация оформилась в IT — если заменить дракона — миллионные армии не А>желающих чему-либо учиться квазипрограммеров, ваяющих формочки и не желающих А>слышать не то что про Лисп, но и даже про те же элементарные Design Patterns, А>несколькими defmacro, то погибнет целая развитая индустрия по производству красивых А>и удобных средств "разработки" для тех, кто в действительности по просту не умеет А>программировать и, вместо того чтобы честно махать на улице метлой, протирает до дыр А>ни в чём неповинные мышиные коврики.
А>2. Учиться. Если у Вас есть немного свободного времени, потратьте его часть на изучение А>языков, которые заставляют человека _думать по другому_. Изучите Lisp, Prolog, Haskell, А>SML, Smalltalk, Erlang (особое внимание стоит уделить Common Lisp'у, как языку А>расширяемому и наиболее практичному). Не давайте мозгам заржаветь, учитесь мыслить шире. А>Для начала, это поможет Вам стать хорошим программистом, даже если на хлеб себе вы будете А>зарабатывать, программируя на других языках. Все мейнстримные языки построены, А>как правило, по принципу "те же яйца, вид сбоку". Осознайте, что мир на самом деле А>не сошёлся на лежащем в их основе наборе стандартных парадигм.
Если отвлечься от удачно поданного жизнеописания автора и сконцентрироваться на том, что написано выше, то лично у меня по поводу данного поста возникает совсем другое мнение. Если сказать жестко, то это напоминает заявление "просветленного": "Я поднялся над суетой, мне открылся другой мир, взгляните на все моими глазами, работайте над собой и вы увидите то же, что и я". Имхо, проблема в том, что эти слова относятся не только к программированию -- это вообще из области веры и религии. Но не из области приземленной инженерии.
Плотник и стоитель
Представим себе плотника, который виртуозно владеет своей профессией. Насколько, что с помощью одного лишь топора и без единого гвоздя может построить баньку или небольшую часовеньку. Если собрать нескольких таких же плотников, то они, опять же без единого гвоздя, возведут трехглавую деревянную церьковь, которая простоит лет двести-триста. А если дать им больше времени, то они и семиглавую церьковь поставят. И опять без единого гвоздя.
Они мастера своего дела. Они потратили большую часть жизни для достижения такого мастерства. Они безусловно являются "сливками", "элитой" своей профессии. О некоторых из них сложат легенды. А многих будут впоминать из поколения в поколение. Сотни начинающих плотников будут мечтать достичь такого же уровня, но только единицам самых трудолюбивых и таланливых удастся этого достичь. Собственно, чего ходить вокруг да около -- я сам очень хотел бы достичь таких же профессиональных высот.
Но, уважаемый читатель, не смущает ли тебя что-нибудь? Лично меня уже смущает. Смущает то, что все это очень далеко от реальной жизни. Потому, что миллионам людей нужно где-то жить. Им нужны дома, много домов, много больших домов. Которые нужно построить быстро, дешево и качественно.
Сможет ли талантливый плотник, пусть даже с десятком не менее талантливых помошников, посторить многоэтажный многоквартирный дом? А железнодорожный мост? А автомобильный завод? Нет. Потому, что размер имеет значение. Потому, что объем (даже не сложность, а простой объем) задачи полностью нивелирует разницу в профессиональном уровне матерого плотника и начинающего строителя. И объем требует, чтобы строителей было много. А раз много, значит их средний проффессиональный уровень будет невысоким. Значит нужно их снабдить такими инструментами и технологиями, которые позволят при невысоком среднем уровне получать гарантированный результат.
И такими инструментами и технологиями как раз является мейнстрим. Причем не только в программировании, но это сейчас не важно. Важно то, что Lisp, как Prolog, как Smalltalk и иже с ними не стали мейнстримом. И не станут. Просто потому, что они не пригодны для массового потребления. Это штучный инструмент для штучных задач, который нужен штучным исполнителям.
Меняем инструмент?
Понятно, что любая технология рано или поздно сталкивается с пределом своих возможностей. Хотя можно переформулировать и чуть по другому: рано или поздно основная масса пользователей технологии уже не сможет получать от технологии новые возможности. Имхо, это именно то, что сейчас происходит с C++. Основная масса С++ программистов уже не знает, что еще полезного из C++ можно получить (рефлекшена нет, сборки мусора нет, стандартной сериализации нет, втроенного контроля за выходом из пределов массивов нет и т.д. и т.п.). Хотя некоторые индивидумы (типа Александреску и boost-овцев) постоянно показывают, что C++ еще рано списывать на свалку.
Так вот вопрос состоит в том, что же делать: пытаться улучшить свой инструмент и при этом сохранить команду, проекты и огромные объемы готового, отлаженного и работающего кода. Или сделать в своей жизни крутой разворот и воспользоваться Lisp (Smalltalk, Prolog, нужное вписать)? Для кого-то второй вариант окажется гораздо проще и предпочтительнее, но таких не может быть много. Просто потому, что спрос на штучный товар всегда был и будет так же штучным.
А кто-то пойдет по пути усовершенствования существующего инструмента (грабельки начнет изобретать, костыли мастерить). Кто-то сериализацию сделает, кто-то рефлекшен, кто-то удобные стредства для распределенных вычислений, кто-то организует все так, чтобы один и тот же велосипед дважды не изобретали, кто-то это будет популяризировать. И тогда, через несколько лет, мы оглянемся и скажем: "Ба, а ведь это уже совсем другой язык, совсем другая технология! А мы и не заметили".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
>> А> [ skipped — много всего про Common Lisp ] >> Немного offtopic, но все же... >> Неужели CL — настолько замечательный и почти-для-всего-подходящий >> язык? В частности (если сравнивать с C++): >> 1. Позволяет ли он (теоретически, если бы были необходимые библиотеки) >> безпроблемно запрограммировать приложения, которые сейчас пишут на C++ >> или на C#/VB/Java/Delphi (имеется в виду mainstream, а не экзотика >> вроде real-time)?
C>Позволяет. Хотя в нем должен быть GC
Не понял?? В смысле — "запрограммировать все можно, но вообще в языке есть недостаток — нет GC"? Или что-то другое?
>> 2. (Вроде бы) известно, что CL поддерживает много чего, что не >> поддерживает C++. А наоборот? Верно ли, что все, что поддерживает C++ >> (исключая низкоуровневое вроде прямого доступа к памяти), >> поддерживается в CL?
C>Нет, хотя при желании достижимо.
Т.е. можно добавить/реализовать средствами языка?
C>Вообще, в CL мне не понравилось полное отсутствие нормального синтаксиса C>(LISP=Lots of Incredibly Silly Paranthesis) и нестатическая типизация.
А, т.е. статической типизации там нет? Тогда, похоже, тезис о том, что "CL почти-во-всем лучше C++" неверен (т.к. IMHO статическая типизация — мощный и необходимый инструмент, и если его уже нет в языке, я не представляю, как его можно было бы реализовать средствами языка).
C>ЗЫ: Губанова бы с его "звезданутым" подсчетом скобок натравить на Lisp. C>Он ТААААКОГО бы оверхеда насчитал....
pvgoran wrote:
>>> 1. Позволяет ли он (теоретически, если бы были необходимые библиотеки) >>> безпроблемно запрограммировать приложения, которые сейчас пишут на C++ >>> или на C#/VB/Java/Delphi (имеется в виду mainstream, а не экзотика >>> вроде real-time)? > C>Позволяет. Хотя в нем должен быть GC > Не понял?? В смысле — "запрограммировать все можно, но вообще в языке > есть недостаток — нет GC"? Или что-то другое?
Это я ночью писал В Лиспе используется GC со всеми вытекающими
последствиями.
>>> 2. (Вроде бы) известно, что CL поддерживает много чего, что не >>> поддерживает C++. А наоборот? Верно ли, что все, что поддерживает C++ >>> (исключая низкоуровневое вроде прямого доступа к памяти), >>> поддерживается в CL? > C>Нет, хотя при желании достижимо. > Т.е. можно добавить/реализовать средствами языка?
Чисто средствами языка — нет, а если подключить внешнюю библиотеку на С,
то можно сделать достаточно приличный интерфейс к памяти.
> C>Вообще, в CL мне не понравилось полное отсутствие нормального > синтаксиса > C>(LISP=Lots of Incredibly Silly Paranthesis) и нестатическая типизация. > А, т.е. статической типизации там нет?
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, Cyberax, Вы писали:
>>> А> [ skipped — много всего про Common Lisp ] >>> Немного offtopic, но все же... >>> Неужели CL — настолько замечательный и почти-для-всего-подходящий >>> язык? В частности (если сравнивать с C++): >>> 1. Позволяет ли он (теоретически, если бы были необходимые библиотеки) >>> безпроблемно запрограммировать приложения, которые сейчас пишут на C++ >>> или на C#/VB/Java/Delphi (имеется в виду mainstream, а не экзотика >>> вроде real-time)?
C>>Позволяет. Хотя в нем должен быть GC P>Не понял?? В смысле — "запрограммировать все можно, но вообще в языке есть недостаток — нет GC"? Или что-то другое?
Лисп обзавёлся GC первым из всех языков программирования. При наличии
библиотек запрограммировать можно всё, что пишется на мейнстримных языках,
причём в десятки раз быстрее. Единственная проблема Лиспа — собственно
с наличием _некоторых_ библиотек, если говорить точнее, open-source
библиотек. Меня собственно несколько напрягает отсутствие проверенных
жизнью _open-source_ GUI библиотек. Если есть возможность купить коммерческий
Лисп — Lispworks или Allegro (особенно, если софт пишется под Винду или Мак) —
то проблем никаких (CAPI и Common Windows соответственно), а так — Cells-Gtk,
McCLIM — вроде мощные либы, но, увы, не очень хорошо документированные,
альфа/бета и не шибко проверенные временем. С другой стороны,
есть RDNZL, FOIL и пр., которые позволяют легко взаимодействовать
с .NET или Java, так что желающие могут делать GUI в том же Visual Studio,
а "мясо" писать на Лиспе. That said, с написание web-приложений проблем
существенно меньше, и писать их гораздо проще, чем под тот же ASP.NET
(за примером отсылаю к Practical Common Lisp — http://www.gigamonkeys.com/book/ —
там описано создание Shoutcast-сервера с возможностью браузить mp3
через веб — на основе данных из их id3 тегов).
>>> 2. (Вроде бы) известно, что CL поддерживает много чего, что не >>> поддерживает C++. А наоборот? Верно ли, что все, что поддерживает C++ >>> (исключая низкоуровневое вроде прямого доступа к памяти), >>> поддерживается в CL?
C>>Нет, хотя при желании достижимо. P>Т.е. можно добавить/реализовать средствами языка?
Разумеется.
C>>Вообще, в CL мне не понравилось полное отсутствие нормального синтаксиса C>>(LISP=Lots of Incredibly Silly Paranthesis) и нестатическая типизация. P>А, т.е. статической типизации там нет? Тогда, похоже, тезис о том, что "CL почти-во-всем лучше C++" P> неверен (т.к. IMHO статическая типизация — мощный и необходимый инструмент, и если его уже нет в языке, P> я не представляю, как его можно было бы реализовать средствами языка).
От строгой статической типизации имхо хоть (весьма небольшая) польза, быть может, и есть,
но вреда гораздо больше — т.к., как минимум, приходится писать [очень много] лишнего кода.
В Лиспе можно декларить типы, просто эти объявления не являются обязательными и
служат, прежде всего, для оптимизации критических по производительности участков
кода (хотя, как минимум, SBCL и CMUCL поддерживают compile-time type checking/type inference).
На самом деле, благодаря интерактивному стилю разработки (написал мелкую функцию --
тут же её скомпилил по Ctrl-C-C — протестировал в REPL) подавляющее большинство
ошибок, которые в тех же C# и Java, допустим, могут быть обнаружены компилятором,
а также тех, которые этими компиляторами не обнаруживаются, уничтожаются "в зародыше".
Не говоря уже о том, что хорошие юнит-тесты также помогают свести проблему на нет.
В общем и целом, не стоит писать лишние тышши строк кода только за тем, чтобы
компилер обнаружил ошибку, которую и так через 5 секунд увидишь в окне REPL.
Да, кстати, если Вы не представляете, как вещи, подобные статической
типизации, _добавляются_ средствами языка, Вы даже близко не представляете Лисп,
и я советовал бы этот пробел восполнить Тут основной, мм, нюанс в том,
что на Лиспе можно по десятку (очень полезных) компилеров или интерпретеров
на дню писать
C>>ЗЫ: Губанова бы с его "звезданутым" подсчетом скобок натравить на Lisp. C>>Он ТААААКОГО бы оверхеда насчитал.... P>
Почитайте вот это http://bc.tech.coop/blog/040128.html
Symbolics Genera LispM — ОС Лисп-машин Symbolics — порядка 460000 строк.
Сюда входит, как минимум, ядро и базовый софт ОС, GUI, Lisp runtime,
компиляторы Лиспа, C, Паскаля и Фортрана. Сравните с миллионами строк
ядра линуха и многими десятками миллионов строк кода в винде (безо
всяких компиляторов!..). При этом на Лисп-машинах поддерживалась максимальная
степень интеграции приложений, которая COM'ам/OLE и .NET'ам и не снилась...
Вот вам и избыточность.
Re[3]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 09:20
Оценка:
К сожалению, в отношении строительства тут уместна гораздо более
прозаическая параллель. Чтобы построить здание, можно напрячь
мильён рабов, пихающих и таскающих плиты, и сотнями под ними гибнущих,
как это было в случае с пирамидами, а можно особо не заморачиваться
и подогнать подъёмный кран...
Более того, и для "простых трудяг" может найтись применение в Lisp world.
Ведь символьные выражения по своей сути проще, чем тот же XML. Поэтому
серьёзные программеры могут создавать Domain Specific Language,
нацеленный на конкретную задачу, а трудяги — использовать его как инструмент
разработки. Хорошо сделанный язык может быть тривиальным в освоении
(денёк потратишь, чтобы изучить). Для "особо одарённых", в крайнем случае,
можно быстро сляпать "визуальный билдер", дающий на выходе какой-либо
специфический DSL в виде s-expressions. Хотя, думается мне, "потребность
в визуальности" — часто легко преодолеваемый психологический момент.
По поводу превращения C++ в новый язык — это Lisp можно легко превратить
в новый язык (причём он при этом так и останется Lisp'ом). А плюсы
в серьёз "научить" чему то новому — едва ли на много проще, чем
научить ишака читать Коран
Вообще, есть два варианта развития событий:
1) плюсы дорастут до Лиспа — как я уже сказал, это маловероятно,
раньше ишаки научатся читать, а коровы — разговаривать;
2) Лисповские FFI разовьются в достаточной степени, чтобы пользоваться
существующими наработками на других языках (которые затем можно не спеша
и не напрягаясь постепенно переписать на Лиспе). Для Java и .NET подобные вещи уже есть,
коммерческие Лиспы вполне работают с COM, сами плюсы на очереди
(http://www.alphageeksinc.com/cgi-bin/lispnyc.cgi?FetterFfi — финансируется
Google; не считая того, что для Аллегро "клей" уже может генерить SWIG)
Re[3]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 10:05
Оценка:
Ещё хочу добавить — нет, господа, я не хочу сказать, что
я умнее большинства здесь присутствующих или что я достиг
каких-то аоблачных высот. Напротив, я хотел бы подчеркнуть,
что, скорее всего, Лисп вполне доступен большинству людей,
читающих это сообщение. Вся его "сложность" — в непривычности.
Если начинать знакомство с программированием с Лиспа, то C++/С#/Java
будут казаться такими же непривычными. В то же время язык стоит
того, чтобы его изучить. Попробуйте — поймёте сами.
Люди, которых бы я действительно назвал "быдлокодерами" — это
те, кто научился каким-то максимально примитивным вещам вроде
распихивания компонентов и контролов по формочкам и написания
ультракриовой смеси из плюсов/шарпов/паскаля/бейсика/etc и SQL,
неизвестно, почему и как работающей, и больше ничего в принципе
знать не желает. Я думаю, большинство таких людей даже не заморачиваются
чтением форумов вроде RSDN. Если же Вы хотя бы имеете представление
о каких-то основах программирования, об ООП, каких-то базовых вещах,
и хотите знать больше — Лисп Вы вполне осилите.
Здравствуйте, <Аноним>, Вы писали:
C>>>Вообще, в CL мне не понравилось полное отсутствие нормального синтаксиса C>>>(LISP=Lots of Incredibly Silly Paranthesis) и нестатическая типизация. P>>А, т.е. статической типизации там нет? Тогда, похоже, тезис о том, что "CL почти-во-всем лучше C++" P>> неверен (т.к. IMHO статическая типизация — мощный и необходимый инструмент, и если его уже нет в языке, P>> я не представляю, как его можно было бы реализовать средствами языка).
А>От строгой статической типизации имхо хоть (весьма небольшая) польза, быть может, и есть,
Лично мне очень нравится возможность делать что-то вроде того, что описано здесь
, подобные конструкции напрямую поддерживаются таким "не-mainstream" языком, как OCaml'ом — по-моему, достаточно показательно...
А>но вреда гораздо больше — т.к., как минимум, приходится писать [очень много] лишнего кода.
А в Lisp'е приходится писать много лишних скобок...
А>В Лиспе можно декларить типы, просто эти объявления не являются обязательными и А>служат, прежде всего, для оптимизации критических по производительности участков А>кода (хотя, как минимум, SBCL и CMUCL поддерживают compile-time type checking/type inference).
SBCL и CMUCL — это реализации CL, т.е. type checking/inference там, наверное, реализованы в компиляторе/интерпретаторе, а не средствами языка?
А>На самом деле, благодаря интерактивному стилю разработки (написал мелкую функцию -- А>тут же её скомпилил по Ctrl-C-C — протестировал в REPL) подавляющее большинство А>ошибок, которые в тех же C# и Java, допустим, могут быть обнаружены компилятором, А>а также тех, которые этими компиляторами не обнаруживаются, уничтожаются "в зародыше". А>Не говоря уже о том, что хорошие юнит-тесты также помогают свести проблему на нет. А>В общем и целом, не стоит писать лишние тышши строк кода только за тем, чтобы А>компилер обнаружил ошибку, которую и так через 5 секунд увидишь в окне REPL.
Да, наверное, отловить ошибки при написании программы так тоже можно (если есть привычка работать соответствующим образом). Но, например, в примере, приведенном выше (про communicator'ы
), шла речь в о том, что компилятор обнаружит ошибку после внесения изменений в уже написанный код. Здесь, конечно, должны помочь unit test'ы, но насколько хорошо они помогут — непонятно...
А>Да, кстати, если Вы не представляете, как вещи, подобные статической А>типизации, _добавляются_ средствами языка, Вы даже близко не представляете Лисп, А>и я советовал бы этот пробел восполнить Тут основной, мм, нюанс в том, А>что на Лиспе можно по десятку (очень полезных) компилеров или интерпретеров А>на дню писать
Т.е. рецепт такой — берем CL и пишем на нем интерпретатор/компилятор все того же CL, но с проверкой типов? Интересная идея...
C>>>ЗЫ: Губанова бы с его "звезданутым" подсчетом скобок натравить на Lisp. C>>>Он ТААААКОГО бы оверхеда насчитал.... P>>
А>Почитайте вот это А>http://bc.tech.coop/blog/040128.html А>Symbolics Genera LispM — ОС Лисп-машин Symbolics — порядка 460000 строк. А>Сюда входит, как минимум, ядро и базовый софт ОС, GUI, Lisp runtime, А>компиляторы Лиспа, C, Паскаля и Фортрана. Сравните с миллионами строк А>ядра линуха и многими десятками миллионов строк кода в винде (безо А>всяких компиляторов!..). При этом на Лисп-машинах поддерживалась максимальная А>степень интеграции приложений, которая COM'ам/OLE и .NET'ам и не снилась... А>Вот вам и избыточность.
Это не "нам" избыточность, а Губанову.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[7]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 10:37
Оценка:
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, <Аноним>, Вы писали:
C>>>>Вообще, в CL мне не понравилось полное отсутствие нормального синтаксиса C>>>>(LISP=Lots of Incredibly Silly Paranthesis) и нестатическая типизация. P>>>А, т.е. статической типизации там нет? Тогда, похоже, тезис о том, что "CL почти-во-всем лучше C++" P>>> неверен (т.к. IMHO статическая типизация — мощный и необходимый инструмент, и если его уже нет в языке, P>>> я не представляю, как его можно было бы реализовать средствами языка).
А>>От строгой статической типизации имхо хоть (весьма небольшая) польза, быть может, и есть, P>Лично мне очень нравится возможность делать что-то вроде того, что описано здесь
, подобные конструкции напрямую поддерживаются таким "не-mainstream" языком, как OCaml'ом — по-моему, достаточно показательно...
А>>но вреда гораздо больше — т.к., как минимум, приходится писать [очень много] лишнего кода. P>А в Lisp'е приходится писать много лишних скобок...
Большинство этих скобок пишет IDE (напр., Emacs+SLIME или LispWorks/Allegro) по комбинации клавиш.
Поверьте мне, никого из лисперов скобки не напрягают. При изучении языка они перестают напрягать
эдак через неделю, а при практическом применении — появляется возрастающее недоумение, как люди
без них живут? Ведь эти самые скобки позволяют, собственно, практически полностью исключить из языка
парсер, и не напрягаясь безо всякой лишней работы писать готовый (и понятный!) AST, что и делает
язык бесконечно расширяемым.
А>>В Лиспе можно декларить типы, просто эти объявления не являются обязательными и А>>служат, прежде всего, для оптимизации критических по производительности участков А>>кода (хотя, как минимум, SBCL и CMUCL поддерживают compile-time type checking/type inference). P>SBCL и CMUCL — это реализации CL, т.е. type checking/inference там, наверное, реализованы в компиляторе/интерпретаторе, а не средствами языка?
На самом деле, практически всё, что реализовано в компиляторе, реализовано там по
следующим причинам:
1) оно полезно;
2) оно предусмотрено стандартом;
3) требуется высокая производительность (оптимизации на уровне генерации объектного кода).
Вообще же в Лиспе фактически весь язык — это, можно сказать, библиотека. Логическое ядро
минимально. Синтаксис более, чем тривиален и единообразен. Даже объектная подсистема CLOS
в своё время была создана средствами языка, и позже была включена в компиляторы из соображений
производительности и стандартизации.
А>>На самом деле, благодаря интерактивному стилю разработки (написал мелкую функцию -- А>>тут же её скомпилил по Ctrl-C-C — протестировал в REPL) подавляющее большинство А>>ошибок, которые в тех же C# и Java, допустим, могут быть обнаружены компилятором, А>>а также тех, которые этими компиляторами не обнаруживаются, уничтожаются "в зародыше". А>>Не говоря уже о том, что хорошие юнит-тесты также помогают свести проблему на нет. А>>В общем и целом, не стоит писать лишние тышши строк кода только за тем, чтобы А>>компилер обнаружил ошибку, которую и так через 5 секунд увидишь в окне REPL. P>Да, наверное, отловить ошибки при написании программы так тоже можно P>(если есть привычка работать соответствующим образом).
Это очень важная и полезная привычка — interactive development. Попробуйте — понравится.
P>Но, например, в примере, приведенном выше P>(про communicator'ы
), P>шла речь в о том, что компилятор обнаружит ошибку после внесения изменений P>в уже написанный код. Здесь, конечно, должны помочь unit test'ы, но насколько хорошо они помогут — непонятно...
Объём *читабельного* кода, необходимого для решения той или иной задачи, в Лиспе в
99% случаев многократно меньше, чем в случае "мейнстримовых" языков. Как следствие,
и ошибки в нём обнаруживаются существенно проще. Посему банальные юнит-тесты и
ассерты где надо вполне спасают. Тем более, что для *значений* в Лиспе используется
строгая типизация, строка в символ, список или число сама собой не заcoerce'ится, если ей
не прикажешь.
А>>Да, кстати, если Вы не представляете, как вещи, подобные статической А>>типизации, _добавляются_ средствами языка, Вы даже близко не представляете Лисп, А>>и я советовал бы этот пробел восполнить Тут основной, мм, нюанс в том, А>>что на Лиспе можно по десятку (очень полезных) компилеров или интерпретеров А>>на дню писать P>Т.е. рецепт такой — берем CL и пишем на нем интерпретатор/компилятор все того же CL, но с проверкой типов? Интересная идея...
Здесь я имел в виду саму возможность. Большинство лисперов вполне обходятся
без compile-time проверки типов.
C>>>>ЗЫ: Губанова бы с его "звезданутым" подсчетом скобок натравить на Lisp. C>>>>Он ТААААКОГО бы оверхеда насчитал.... P>>>
А>>Почитайте вот это А>>http://bc.tech.coop/blog/040128.html А>>Symbolics Genera LispM — ОС Лисп-машин Symbolics — порядка 460000 строк. А>>Сюда входит, как минимум, ядро и базовый софт ОС, GUI, Lisp runtime, А>>компиляторы Лиспа, C, Паскаля и Фортрана. Сравните с миллионами строк А>>ядра линуха и многими десятками миллионов строк кода в винде (безо А>>всяких компиляторов!..). При этом на Лисп-машинах поддерживалась максимальная А>>степень интеграции приложений, которая COM'ам/OLE и .NET'ам и не снилась... А>>Вот вам и избыточность.
P>Это не "нам" избыточность, а Губанову.
Здравствуйте, <Аноним>, Вы писали:
P>>SBCL и CMUCL — это реализации CL, т.е. type checking/inference там, наверное, реализованы в компиляторе/интерпретаторе, а не средствами языка?
А>На самом деле, практически всё, что реализовано в компиляторе, реализовано там по А>следующим причинам: А>1) оно полезно; А>2) оно предусмотрено стандартом; А>3) требуется высокая производительность (оптимизации на уровне генерации объектного кода). А>Вообще же в Лиспе фактически весь язык — это, можно сказать, библиотека. Логическое ядро А>минимально. Синтаксис более, чем тривиален и единообразен. Даже объектная подсистема CLOS А>в своё время была создана средствами языка, и позже была включена в компиляторы из соображений А>производительности и стандартизации.
Я вообще-то спрашивал про проверку типов при компиляции... Именно ее можно добавить в "голый" (== стандартный) CL, не переписывая компилятор (а, например, взяв какую-нибудь third-party библиотеку?
А>>>На самом деле, благодаря интерактивному стилю разработки (написал мелкую функцию -- А>>>тут же её скомпилил по Ctrl-C-C — протестировал в REPL) подавляющее большинство А>>>ошибок, которые в тех же C# и Java, допустим, могут быть обнаружены компилятором, А>>>а также тех, которые этими компиляторами не обнаруживаются, уничтожаются "в зародыше". А>>>Не говоря уже о том, что хорошие юнит-тесты также помогают свести проблему на нет. А>>>В общем и целом, не стоит писать лишние тышши строк кода только за тем, чтобы А>>>компилер обнаружил ошибку, которую и так через 5 секунд увидишь в окне REPL. P>>Да, наверное, отловить ошибки при написании программы так тоже можно P>>(если есть привычка работать соответствующим образом).
А>Это очень важная и полезная привычка — interactive development. Попробуйте — понравится.
Было бы, где пробовать... Мой нынешний инструмент — C++ — вроде бы не позволяет (т.к., насколько я понимаю, предполагается активное использование REPL).
P>>Но, например, в примере, приведенном выше P>>(про communicator'ы
), P>>шла речь в о том, что компилятор обнаружит ошибку после внесения изменений P>>в уже написанный код. Здесь, конечно, должны помочь unit test'ы, но насколько хорошо они помогут — непонятно...
А>Объём *читабельного* кода, необходимого для решения той или иной задачи, в Лиспе в А>99% случаев многократно меньше, чем в случае "мейнстримовых" языков. Как следствие, А>и ошибки в нём обнаруживаются существенно проще. Посему банальные юнит-тесты и А>ассерты где надо вполне спасают.
Ладно, пусть для Лиспа объемы кода меньше. Но этот аргумент не масштабируем . Он лишь означает, что "банальные юнит-тесты и ассерты" перестают "спасать" несколько позже (для несколько более сложных программ), чем обычно.
А>Тем более, что для *значений* в Лиспе используется А>строгая типизация, строка в символ, список или число сама собой не заcoerce'ится, если ей А>не прикажешь.
Ну, это (как и assert'ы) выявляет ошибки при исполнении. А мне хотелось бы при компиляции...
P>>Т.е. рецепт такой — берем CL и пишем на нем интерпретатор/компилятор все того же CL, но с проверкой типов? Интересная идея...
А>Здесь я имел в виду саму возможность. Большинство лисперов вполне обходятся А>без compile-time проверки типов.
В получается аргумент типа "статическая проверка типа не нужна, потому что в общем-то можно без нее обойтись, и большинство (лисперов) обходится". Но ровно то же самое можно сказать про Лисп в целом! Так что ценность его IMHO сомнительна...
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, <Аноним>, Вы писали:
P>>>SBCL и CMUCL — это реализации CL, т.е. type checking/inference там, наверное, реализованы в компиляторе/интерпретаторе, а не средствами языка?
А>>На самом деле, практически всё, что реализовано в компиляторе, реализовано там по А>>следующим причинам: А>>1) оно полезно; А>>2) оно предусмотрено стандартом; А>>3) требуется высокая производительность (оптимизации на уровне генерации объектного кода). А>>Вообще же в Лиспе фактически весь язык — это, можно сказать, библиотека. Логическое ядро А>>минимально. Синтаксис более, чем тривиален и единообразен. Даже объектная подсистема CLOS А>>в своё время была создана средствами языка, и позже была включена в компиляторы из соображений А>>производительности и стандартизации.
P>Я вообще-то спрашивал про проверку типов при компиляции... Именно ее можно добавить в "голый" P> (== стандартный) CL, не переписывая компилятор (а, например, взяв какую-нибудь third-party библиотеку?
Подобная либа есть -- http://www.cliki.net/TypeL
Но ей не очень пользуются, в силу того, что для большинства применений
проще обойтись без подобных изысков (я имею в виду строгую типизацию).
А>>>>На самом деле, благодаря интерактивному стилю разработки (написал мелкую функцию -- А>>>>тут же её скомпилил по Ctrl-C-C — протестировал в REPL) подавляющее большинство А>>>>ошибок, которые в тех же C# и Java, допустим, могут быть обнаружены компилятором, А>>>>а также тех, которые этими компиляторами не обнаруживаются, уничтожаются "в зародыше". А>>>>Не говоря уже о том, что хорошие юнит-тесты также помогают свести проблему на нет. А>>>>В общем и целом, не стоит писать лишние тышши строк кода только за тем, чтобы А>>>>компилер обнаружил ошибку, которую и так через 5 секунд увидишь в окне REPL. P>>>Да, наверное, отловить ошибки при написании программы так тоже можно P>>>(если есть привычка работать соответствующим образом).
А>>Это очень важная и полезная привычка — interactive development. Попробуйте — понравится.
P>Было бы, где пробовать... Мой нынешний инструмент — C++ — вроде бы не позволяет P>(т.к., насколько я понимаю, предполагается активное использование REPL).
Я имел в виду попробовать вместе с Lisp'ом. Для плюсов нечто отдалённо подобное
в CERN'е изобрели, но мне, признаться, на это изобретение смотреть страшновато...
Можно сорок раз Лисп выучить успеть, прежде чем в этом разберёшься.
P>>>Но, например, в примере, приведенном выше P>>>(про communicator'ы
), P>>>шла речь в о том, что компилятор обнаружит ошибку после внесения изменений P>>>в уже написанный код. Здесь, конечно, должны помочь unit test'ы, но насколько хорошо они помогут — непонятно...
А>>Объём *читабельного* кода, необходимого для решения той или иной задачи, в Лиспе в А>>99% случаев многократно меньше, чем в случае "мейнстримовых" языков. Как следствие, А>>и ошибки в нём обнаруживаются существенно проще. Посему банальные юнит-тесты и А>>ассерты где надо вполне спасают.
P>Ладно, пусть для Лиспа объемы кода меньше. Но этот аргумент не масштабируем . P>Он лишь означает, что "банальные юнит-тесты и ассерты" перестают "спасать" несколько позже (для несколько более сложных программ), чем обычно.
А>>Тем более, что для *значений* в Лиспе используется А>>строгая типизация, строка в символ, список или число сама собой не заcoerce'ится, если ей А>>не прикажешь.
P>Ну, это (как и assert'ы) выявляет ошибки при исполнении. А мне хотелось бы при компиляции...
P>>>Т.е. рецепт такой — берем CL и пишем на нем интерпретатор/компилятор все того же CL, но с проверкой типов? Интересная идея...
А>>Здесь я имел в виду саму возможность. Большинство лисперов вполне обходятся А>>без compile-time проверки типов.
P>В получается аргумент типа "статическая проверка типа не нужна, потому что в общем-то можно P> без нее обойтись, и большинство (лисперов) обходится". Но ровно то же самое можно сказать про Лисп в целом! P>Так что ценность его IMHO сомнительна...
Я хотел сказать только одно -- недостатки строгой типизации многократно перевешивают те
преимущества, которые она даёт. Да, небольшое количество ошибок, которые могли бы быть
пойманы компилятором, перекочёвывают в run time. Но это происходит на фоне существенного
упрощения кода, и многократного уменьшения общего количества ошибок. Я хочу сказать,
что победа над некоторыми ошибками, достигаемая строгой типизацией, является Пирровой,
и неудобства, ей причиняемые, перевешивают её преимущества.
Вообще, я не надеюсь здесь доказать, что Лисп лучше других языков. Я лишь хотел бы, чтобы
люди заинтересовались языком, и убедились в этом сами
wrote:
> P>В получается аргумент типа "статическая проверка типа не нужна, > потому что в общем-то можно > P> без нее обойтись, и большинство (лисперов) обходится". Но ровно то > же самое можно сказать про Лисп в целом! > P>Так что ценность его IMHO сомнительна... > Я хотел сказать только одно -- недостатки строгой типизации > многократно перевешивают те > преимущества, которые она даёт. Да, небольшое количество ошибок, > которые могли бы быть > пойманы компилятором, перекочёвывают в run time. Но это происходит на > фоне существенного > упрощения кода, и многократного уменьшения общего количества ошибок.
Это больше напоминает рекламный памфлет. Тут большинство людей пробовали
какой-либо язык с динамической типизацией, но почему-то до сих пор пишут
на С++.
Существенного упрощения кода на Лиспе тоже не наблюдается — код того же
Emacs'а читается ничуть не лучше, чем код jEdit'а или Eclipse.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[11]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 13:57
Оценка:
Здравствуйте, Cyberax, Вы писали:
C> wrote:
>> P>В получается аргумент типа "статическая проверка типа не нужна, >> потому что в общем-то можно >> P> без нее обойтись, и большинство (лисперов) обходится". Но ровно то >> же самое можно сказать про Лисп в целом! >> P>Так что ценность его IMHO сомнительна... >> Я хотел сказать только одно -- недостатки строгой типизации >> многократно перевешивают те >> преимущества, которые она даёт. Да, небольшое количество ошибок, >> которые могли бы быть >> пойманы компилятором, перекочёвывают в run time. Но это происходит на >> фоне существенного >> упрощения кода, и многократного уменьшения общего количества ошибок.
C>Это больше напоминает рекламный памфлет. Тут большинство людей пробовали C>какой-либо язык с динамической типизацией, но почему-то до сих пор пишут C>на С++.
Динамическая типизация — далеко не единственное свойство Лиспа.
По поводу компактности кода — http://bc.tech.coop/blog/040128.html
C>Существенного упрощения кода на Лиспе тоже не наблюдается — код того же C>Emacs'а читается ничуть не лучше, чем код jEdit'а или Eclipse.
Emacs написан на Emacs lisp'е, не самой удачной реализации морально устаревшего
диалекта (фундаментальная проблема — dynamic scoping вместо lexical scoping,
т.е. в столь древних диалектах ещё не было тех же closures)
Здравствуйте, <Аноним>, Вы писали:
P>>Я вообще-то спрашивал про проверку типов при компиляции... Именно ее можно добавить в "голый" P>> (== стандартный) CL, не переписывая компилятор (а, например, взяв какую-нибудь third-party библиотеку?
А>Подобная либа есть -- http://www.cliki.net/TypeL
Посмотрел, впечатлился. Правда, моих знаний не хватило, чтобы понять, будет ли оно работать при компиляции.
А вообще — я так понимаю, чтобы такая библиотека работала в реальных приложениях, нужно описать типы библиотечных функций. Невеселая перспективка... (если только это уже не сделано и не хранится где-то в удобном формате).
А>>>Это очень важная и полезная привычка — interactive development. Попробуйте — понравится.
P>>Было бы, где пробовать... Мой нынешний инструмент — C++ — вроде бы не позволяет P>>(т.к., насколько я понимаю, предполагается активное использование REPL).
А>Я имел в виду попробовать вместе с Lisp'ом. Для плюсов нечто отдалённо подобное А>в CERN'е изобрели, но мне, признаться, на это изобретение смотреть страшновато... А>Можно сорок раз Лисп выучить успеть, прежде чем в этом разберёшься.
Вот тут-то и сказывается декларируемое отсутствие (доступных и документированных) GUI-библиотек. Т.к., во-первых, было бы интересно попробовать сделать именно GUI, и во-вторых, именно в области GUI концентрируются мои сомнения насчет применимости интерактивной разработки и unit test'ов.
А>Я хотел сказать только одно -- недостатки строгой типизации многократно перевешивают те А>преимущества, которые она даёт. Да, небольшое количество ошибок, которые могли бы быть А>пойманы компилятором, перекочёвывают в run time. Но это происходит на фоне существенного А>упрощения кода, и многократного уменьшения общего количества ошибок. Я хочу сказать, А>что победа над некоторыми ошибками, достигаемая строгой типизацией, является Пирровой, А>и неудобства, ей причиняемые, перевешивают её преимущества.
Вот это уже более понятно... Хотя и не-особенно-легко-проверяемо.
А>Вообще, я не надеюсь здесь доказать, что Лисп лучше других языков. Я лишь хотел бы, чтобы А>люди заинтересовались языком, и убедились в этом сами
wrote:
> C>Это больше напоминает рекламный памфлет. Тут большинство людей > пробовали > C>какой-либо язык с динамической типизацией, но почему-то до сих пор > пишут > C>на С++. > Динамическая типизация — далеко не единственное свойство Лиспа.
SLOC for the Symbolics Genera Lisp Machine (an OS that was arguably
far superior to Linux)
Ха. Хахахаха.
Конечно, Лисп будет компактнее кода на чистом С — я в этом не
сомневаюсь. Но вот будет ли он компактнее кода на С++ — это уже
сомнительно.
Еще более сомнительно будет ли Лисп компактнее кода на Python'е или
Ruby. И при этом синтаксис у Питона — очень приятный.
> C>Существенного упрощения кода на Лиспе тоже не наблюдается — код того же > C>Emacs'а читается ничуть не лучше, чем код jEdit'а или Eclipse. > Emacs написан на Emacs lisp'е, не самой удачной реализации морально > устаревшего > диалекта (фундаментальная проблема — dynamic scoping вместо lexical > scoping, > т.е. в столь древних диалектах ещё не было тех же closures)
Не думаю, что нескольок новых фич сильно улучшили бы код.
pvgoran wrote:
> Посмотрел, впечатлился. Правда, моих знаний не хватило, чтобы понять, > будет ли оно работать *при компиляции*. > А вообще — я так понимаю, чтобы такая библиотека работала в реальных > приложениях, нужно описать типы библиотечных функций. Невеселая > перспективка... (если только это уже не сделано и не хранится где-то в > удобном формате).
И не надейся. Если в С++ каждый придумывает свои библиотеки, то в Lisp
каждый придумывает свои подъязыки.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[13]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 14:55
Оценка:
Ув. тов. Cyberax!
Ваши представления о языке Lisp настолько же адекватны, насколько
адекватны "нижессылаемые на" представления о нашей Великой Родине. http://transformation.ru/russia/?show=1
Я понимаю, что существенно проще принять распространённый стереотип,
чем самостоятельно поинтересоваться сутью вопроса. Я не буду пытаться
Вас переубедить. Я лишь надеюсь, что среди читателей этих сообщений
найдутся люди, готовые подвергнуть стереотип сомнению.
Здравствуйте, Cyberax, Вы писали:
C> wrote:
>> C>Это больше напоминает рекламный памфлет. Тут большинство людей >> пробовали >> C>какой-либо язык с динамической типизацией, но почему-то до сих пор >> пишут >> C>на С++. >> Динамическая типизация — далеко не единственное свойство Лиспа.
C>Другое свойство — куча скобок.
>> По поводу компактности кода — >> http://bc.tech.coop/blog/040128.html
C>
SLOC for the Symbolics Genera Lisp Machine (an OS that was arguably
C>far superior to Linux)
C>Ха. Хахахаха.
C>Конечно, Лисп будет компактнее кода на чистом С — я в этом не C>сомневаюсь. Но вот будет ли он компактнее кода на С++ — это уже C>сомнительно.
C>Еще более сомнительно будет ли Лисп компактнее кода на Python'е или C>Ruby. И при этом синтаксис у Питона — очень приятный.
>> C>Существенного упрощения кода на Лиспе тоже не наблюдается — код того же >> C>Emacs'а читается ничуть не лучше, чем код jEdit'а или Eclipse. >> Emacs написан на Emacs lisp'е, не самой удачной реализации морально >> устаревшего >> диалекта (фундаментальная проблема — dynamic scoping вместо lexical >> scoping, >> т.е. в столь древних диалектах ещё не было тех же closures)
C>Не думаю, что нескольок новых фич сильно улучшили бы код.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Re[11]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 15:03
Оценка:
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, <Аноним>, Вы писали:
P>>>Я вообще-то спрашивал про проверку типов при компиляции... Именно ее можно добавить в "голый" P>>> (== стандартный) CL, не переписывая компилятор (а, например, взяв какую-нибудь third-party библиотеку?
А>>Подобная либа есть -- http://www.cliki.net/TypeL
P>Посмотрел, впечатлился. Правда, моих знаний не хватило, чтобы понять, будет ли оно работать при компиляции.
В принципе, ничего не мешает подобной вещи быть компилируемой.
P>А вообще — я так понимаю, чтобы такая библиотека работала в реальных приложениях, P> нужно описать типы библиотечных функций. Невеселая перспективка... P>(если только это уже не сделано и не хранится где-то в удобном формате).
В детали либы не вглядывался, но, думается мне, это не обязательно.
А>>>>Это очень важная и полезная привычка — interactive development. Попробуйте — понравится.
P>>>Было бы, где пробовать... Мой нынешний инструмент — C++ — вроде бы не позволяет P>>>(т.к., насколько я понимаю, предполагается активное использование REPL).
А>>Я имел в виду попробовать вместе с Lisp'ом. Для плюсов нечто отдалённо подобное А>>в CERN'е изобрели, но мне, признаться, на это изобретение смотреть страшновато... А>>Можно сорок раз Лисп выучить успеть, прежде чем в этом разберёшься.
P>Вот тут-то и сказывается декларируемое отсутствие (доступных и документированных) GUI-библиотек. P>Т.к., во-первых, было бы интересно попробовать сделать именно GUI, и во-вторых, P>именно в области GUI концентрируются мои сомнения насчет применимости P>интерактивной разработки и unit test'ов.
GUI есть -- пожалуйста, CommonWindows/CAPI, или open-source, пусть менее документированные Cells-Gtk,
McCLIM (для "попробовать" последние два, думаю, также подойдут).
А>>Я хотел сказать только одно -- недостатки строгой типизации многократно перевешивают те А>>преимущества, которые она даёт. Да, небольшое количество ошибок, которые могли бы быть А>>пойманы компилятором, перекочёвывают в run time. Но это происходит на фоне существенного А>>упрощения кода, и многократного уменьшения общего количества ошибок. Я хочу сказать, А>>что победа над некоторыми ошибками, достигаемая строгой типизацией, является Пирровой, А>>и неудобства, ей причиняемые, перевешивают её преимущества.
P>Вот это уже более понятно... Хотя и не-особенно-легко-проверяемо.
Проверить проще всего, попробовав.
А>>Вообще, я не надеюсь здесь доказать, что Лисп лучше других языков. Я лишь хотел бы, чтобы А>>люди заинтересовались языком, и убедились в этом сами
P>Эх... Для этого с ним поработать надо, а лень.
Ну, будем надеяться, что не всем настолько лень. Хотя Lisp на самом деле -- хорошая инвестиция
времени для ленивого человека, т.к. этот язык безжалостно изничтожает тонны рутины.
Почему именно — можно почитать можно
приводит пример решения задачи,
Тут основной, мм, нюанс в том,
. Он лишь означает, что "банальные юнит-тесты и ассерты" перестают "спасать" несколько позже (для несколько более сложных программ), чем обычно.