Попробую объяснить, почему совершенного 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 на самом деле -- хорошая инвестиция
времени для ленивого человека, т.к. этот язык безжалостно изничтожает тонны рутины.
wrote:
> Ваши представления о языке Lisp настолько же адекватны, насколько > адекватны "нижессылаемые на" представления о нашей Великой Родине. > http://transformation.ru/russia/?show=1
Не надо дискуссию в сторону уводить.
> Я понимаю, что существенно проще принять распространённый стереотип, > чем самостоятельно поинтересоваться сутью вопроса.
А вы думаете я не интересовался сутью вопроса? Я писал на Лиспе (для
AutoCADа), немного писал на GNU CLIPSе, потом смотрел в сторону Лиспа,
когда искал встраиваемый язык для своего приложения (в итоге остановился
на Питоне). Так что смею вас заверить, о состоянии дела в Лиспе я знаю
не понаслышке.
Здравствуйте, Cyberax, Вы писали:
C>Еще более сомнительно будет ли Лисп компактнее кода на Python'е или C>Ruby. И при этом синтаксис у Питона — очень приятный.
Даешь Lisp с синтаксисом Питона!
Кстати, я, кажется, где-то видел что-то вроде Lisp-подобного языка, который избавили от большой части скобок (заменили отступами).
>> C>Существенного упрощения кода на Лиспе тоже не наблюдается — код того же >> C>Emacs'а читается ничуть не лучше, чем код jEdit'а или Eclipse. >> Emacs написан на Emacs lisp'е, не самой удачной реализации морально >> устаревшего >> диалекта (фундаментальная проблема — dynamic scoping вместо lexical >> scoping, >> т.е. в столь древних диалектах ещё не было тех же closures)
C>Не думаю, что нескольок новых фич сильно улучшили бы код.
IMHO это вполне возможно. Например, мне очень не хватает closures в С++, и мне думается, что они вполне могли бы заметно поднять качество кода во многих случаях.
Здравствуйте, pvgoran, Вы писали:
P>IMHO это вполне возможно. Например, мне очень не хватает closures в С++, и мне думается, что они вполне могли бы заметно поднять качество кода во многих случаях.
boost::function<> не устраивает по религиозным причинам?
Re[15]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 17:20
Оценка:
Здравствуйте, Cyberax, Вы писали:
C> wrote:
>> Ваши представления о языке Lisp настолько же адекватны, насколько >> адекватны "нижессылаемые на" представления о нашей Великой Родине. >> http://transformation.ru/russia/?show=1
C>Не надо дискуссию в сторону уводить.
Я не пытаюсь её увести в сторону. Попробуйте какому-нибудь программеру
на VB6 объяснить по-человечески, зачем вообще нужны темплейты в C++,
что даёт STL, Boost Libraries. Думаете, это у Вас легко получится?
Не уверен. Может быть, конечно, я просто плохой "объяснятель"...
>> Я понимаю, что существенно проще принять распространённый стереотип, >> чем самостоятельно поинтересоваться сутью вопроса.
C>А вы думаете я не интересовался сутью вопроса? Я писал на Лиспе (для C>AutoCADа),
Сравните GW-BASIC и VB.NET... Разницу ощущаете?
C>немного писал на GNU CLIPSе,
Судя по всему, совсем немного... Иначе бы хотя бы стёб по поводу скобок
исключили в пользу более серьёзных аргументов. Тем более что называется
сей продукт несколько по-другому
C>потом смотрел в сторону Лиспа, C>когда искал встраиваемый язык для своего приложения (в итоге остановился C>на Питоне). Так что смею вас заверить, о состоянии дела в Лиспе я знаю C>не понаслышке.
Ну, положем, на уровне среднестатистического CS student'а в штатах, которого
насильно пичкали Схемой в отрыве от реальной действительности... Это ещё похуже.
Для полноценной картины нужно более существенное знакомство со стандартом
Common Lisp, а не только _расплывчатое_ представление о "Лиспе вообще".
Re[14]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 17:32
Оценка:
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, Cyberax, Вы писали:
C>>Еще более сомнительно будет ли Лисп компактнее кода на Python'е или C>>Ruby. И при этом синтаксис у Питона — очень приятный.
P>Даешь Lisp с синтаксисом Питона!
P>Кстати, я, кажется, где-то видел что-то вроде Lisp-подобного языка, который избавили от большой части скобок (заменили отступами).
На счёт отступов — не знаю, а так — Dylan http://www.gwydiondylan.org/
Но он не прижился, скобки-то удобнее.
>>> C>Существенного упрощения кода на Лиспе тоже не наблюдается — код того же >>> C>Emacs'а читается ничуть не лучше, чем код jEdit'а или Eclipse. >>> Emacs написан на Emacs lisp'е, не самой удачной реализации морально >>> устаревшего >>> диалекта (фундаментальная проблема — dynamic scoping вместо lexical >>> scoping, >>> т.е. в столь древних диалектах ещё не было тех же closures)
C>>Не думаю, что нескольок новых фич сильно улучшили бы код.
Dynamic scoping vs lexical scoping — это не несколько новых фич...
Это, вообще говоря, радикальное отличие. Представляете, если бы все
переменные были глобальными?.. Это, плюс возможность их временного
изменения через let (подобно local в Perl'е) с автоматическим
последующим восстановлением, и есть dynamic scoping. В Common Lisp'е
модель "local" поддерживается для глобальных переменных, а для
остальных используется лексическая область видимости (как и в
других языках). Отличие состоит от тех же плюсов здесь состоит в том,
что могут создаваться лексические замыкания.
P>IMHO это вполне возможно. Например, мне очень не хватает closures в С++, P>и мне думается, что они вполне могли бы заметно поднять качество кода во многих случаях.
Ну, это даже Microsoft осознаёт, в C# 2.0 их добавили.
Re[15]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 17:33
Оценка:
Здравствуйте, jedi, Вы писали:
J>Здравствуйте, pvgoran, Вы писали:
P>>IMHO это вполне возможно. Например, мне очень не хватает closures в С++, и мне думается, что они вполне могли бы заметно поднять качество кода во многих случаях.
J>boost::function<> не устраивает по религиозным причинам?
Ну, в купе с boost::lambda оно, может быть, уже очень издали похоже
на правду, но вот только синтаксис уже другой, и сообщения об ошибках
на 20 страниц...
wrote:
> C>Не надо дискуссию в сторону уводить. > Я не пытаюсь её увести в сторону. Попробуйте какому-нибудь программеру > на VB6 объяснить по-человечески, зачем вообще нужны темплейты в C++, > что даёт STL, Boost Libraries. Думаете, это у Вас легко получится? > Не уверен. Может быть, конечно, я просто плохой "объяснятель"...
Так не надо считать, что тут у всех уровень как у VB6 по отношению к Лиспу.
> C>А вы думаете я не интересовался сутью вопроса? Я писал на Лиспе (для > C>AutoCADа), > Сравните GW-BASIC и VB.NET... Разницу ощущаете?
Да я знаю, что там он устарел и все такое.
> C>немного писал на GNU CLIPSе, > Судя по всему, совсем немного... Иначе бы хотя бы стёб по поводу скобок > исключили в пользу более серьёзных аргументов. Тем более что называется > сей продукт несколько по-другому
Полгода писал. Поимел очень много счастливых моментов, отлаживая код:
"Какого ^*$#^*#&^$ в этом списке 5 элементов, какой *$(#&#$ его
изменял???". Особенно классно отлаживать чужой код с DSLем (как водится,
не задокументированным — а где вы видели код с точной документацией???),
причем c ошибками (а куда без них, родимых) и в реализации DSL, _И_ в
скриптах на этом DSL. Спасибо, больше мне такого метапрограммного
счастья не надо.
После этого я пересел на Java/C#, а потом на С++. Вот тут мне темплейты
в С++ и понравились — они ОГРАНИЧЕНЫ в функциональности, поэтому их
часто намного легче использовать, чем прямое редактирование AST.
При этом код был всего примерно в 1Мб. Теперь я понимаю, почему программ
больших 10^6 LOC на Лиспе почти нет.
> C>потом смотрел в сторону Лиспа, > C>когда искал встраиваемый язык для своего приложения (в итоге > остановился > C>на Питоне). Так что смею вас заверить, о состоянии дела в Лиспе я знаю > C>не понаслышке. > Ну, положем, на уровне среднестатистического CS student'а в штатах, > которого > насильно пичкали Схемой в отрыве от реальной действительности... Это > ещё похуже.
Вот на Схему не наезжайте — она мне намного больше нравится. Хороший
минималистичный язык, для внутренних скриптов идеально подходит.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[17]: Metaprogramming et al
От:
Аноним
Дата:
10.07.05 18:51
Оценка:
Здравствуйте, Cyberax, Вы писали:
C> wrote:
>> C>Не надо дискуссию в сторону уводить. >> Я не пытаюсь её увести в сторону. Попробуйте какому-нибудь программеру >> на VB6 объяснить по-человечески, зачем вообще нужны темплейты в C++, >> что даёт STL, Boost Libraries. Думаете, это у Вас легко получится? >> Не уверен. Может быть, конечно, я просто плохой "объяснятель"...
C>Так не надо считать, что тут у всех уровень как у VB6 по отношению к Лиспу.
>> C>А вы думаете я не интересовался сутью вопроса? Я писал на Лиспе (для >> C>AutoCADа), >> Сравните GW-BASIC и VB.NET... Разницу ощущаете?
C>Да я знаю, что там он устарел и все такое.
Я имею в виду удобство разработки — время/стоимость/etc.
>> C>немного писал на GNU CLIPSе, >> Судя по всему, совсем немного... Иначе бы хотя бы стёб по поводу скобок >> исключили в пользу более серьёзных аргументов. Тем более что называется >> сей продукт несколько по-другому
C>Полгода писал. Поимел очень много счастливых моментов, отлаживая код: C>"Какого ^*$#^*#&^$ в этом списке 5 элементов, какой *$(#&#$ его C>изменял???". Особенно классно отлаживать чужой код с DSLем (как водится, C>не задокументированным — а где вы видели код с точной документацией???), C>причем c ошибками (а куда без них, родимых) и в реализации DSL, _И_ в C>скриптах на этом DSL. Спасибо, больше мне такого метапрограммного C>счастья не надо.
Да, на Лиспе тоже можно писать [хреновый] код. Особенно, если пытаться
писать в Сишном стиле:
(if something
(progn
(setf a b)
(setf c d))
(progn
(setf var1 (+ var2 var3))
(setf elki palki)
(setf somelist (nconc somelist anotherlist))))
и так далее в том же духе (собственно, насколько я могу судить, на
Автолиспе так код обычно и пишется). Стиль тоже надо соблюдать. См., например, http://www.norvig.com/paip.html
C>После этого я пересел на Java/C#, а потом на С++. Вот тут мне темплейты C>в С++ и понравились — они ОГРАНИЧЕНЫ в функциональности, поэтому их C>часто намного легче использовать, чем прямое редактирование AST.
Может быть это конечно и дело вкуса, я не один год с плюсовыми темплейтами
работаю... Но думается мне, что тут дело в попытке использовать Lisp
в "чисто императивном" режиме.
C>При этом код был всего примерно в 1Мб. Теперь я понимаю, почему программ C>больших 10^6 LOC на Лиспе почти нет.
1 MLoc на CL для большинства задач (даже весьма серьёзных) просто не
нужен. Надо гораздо меньше.
>> C>потом смотрел в сторону Лиспа, >> C>когда искал встраиваемый язык для своего приложения (в итоге >> остановился >> C>на Питоне). Так что смею вас заверить, о состоянии дела в Лиспе я знаю >> C>не понаслышке. >> Ну, положем, на уровне среднестатистического CS student'а в штатах, >> которого >> насильно пичкали Схемой в отрыве от реальной действительности... Это >> ещё похуже.
C>Вот на Схему не наезжайте — она мне намного больше нравится. Хороший C>минималистичный язык, для внутренних скриптов идеально подходит.
Да я не наезжаю. Я просто хочу сказать, что мериканским студиозусам её так
преподносят, что они потом всю жизнь ненавидят Лисп вообще и Схему в частности.
Что, увы, способствует снижению рейтинга языка.
Cyberax,
>> C>Вообще, в CL мне не понравилось полное отсутствие нормального >> синтаксиса >> C>(LISP=Lots of Incredibly Silly Paranthesis)
Это не проблема. Достаточно найти правильный редактор/вьюер, который
(F1 a1 (F2 b1 (F3 c1 c2 c3)) a3 a4)
показывает в виде
F1
a1
F2
b1
F3
c1
c2
c3
a3
a4
Ну или в более свёрнутом виде
F a1
F2 b1
F3 c1 c2 c3
a3 a4
И гладкое погружение в Лисп гарантировано!
xxx: Сам давно писал для автокада — тогда и пришла мне в голову эта хотелка, там редактор конечно подсвечивает и пары скобок и т.д. и т.п. но всё равно трудно.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, pvgoran, Вы писали:
А>>но вреда гораздо больше — т.к., как минимум, приходится писать [очень много] лишнего кода. P>А в Lisp'е приходится писать много лишних скобок...
C>>>>ЗЫ: Губанова бы с его "звезданутым" подсчетом скобок натравить на Lisp. C>>>>Он ТААААКОГО бы оверхеда насчитал.... P>>>
Да что вы к этим скобкам првязались? В нормальной IDE (например в том же XEmacs)
это легко правится (к стати на скриншоте как раз код который это делает). А зулененькая
подсветка автоматически парные скобки подсевечивает . После месяца на лиспе их уже не
замечаешь. Их потом в C++ очень не хватает
А вообще язык — супер. Я правда не гуру в нем, только на уровне в "Xemacs че подкрутить"...
а до CLOS и проч все руки не дойдут (XEmacs lisp ИМХО самый кривой из всех лиспов,
а ведь и то такого монстра наваяли, а что можно былоб на CL наварганить ).
E>И объем требует, чтобы строителей было много. А раз много, значит их средний проффессиональный уровень будет невысоким. Значит нужно их снабдить такими инструментами и технологиями, которые позволят при невысоком среднем уровне получать гарантированный результат.
Это очень печально. И то что это так совсем не означает, что это хорошо. Хочется как раз быть просветлённым мастером, а не тупым подмастерьей, занимающим 398459-е место с краю в 835709-ой шеренге.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Аноним, Вы писали:
А>От строгой статической типизации имхо хоть (весьма небольшая) польза, быть может, и есть, А>но вреда гораздо больше — т.к., как минимум, приходится писать [очень много] лишнего кода.
Это еще почему (вопрос про вред и про лишний код)? Глядя, например, на код OCaml-а сложно сказать какая там типизация — статическая или нет. Лишнего кода — мизер.
Здравствуйте, Аноним, Вы писали:
А>Попробую объяснить, почему совершенного reflection/serialization/metaprogramming/etc. А>framework'а для плюсов не будет никогда ;-(
Прочитав это предложение, хотел спросить — пробовал ли ты Лисп
Здравствуйте, Cyberax, Вы писали:
C>Вообще, в CL мне не понравилось полное отсутствие нормального синтаксиса C>(LISP=Lots of Incredibly Silly Paranthesis) и нестатическая типизация.
C>ЗЫ: Губанова бы с его "звезданутым" подсчетом скобок натравить на Lisp. C>Он ТААААКОГО бы оверхеда насчитал....
Здравствуйте, <Аноним>, Вы писали:
А>Ув. тов. Cyberax! А>Ваши представления о языке Lisp настолько же адекватны, насколько А>адекватны "нижессылаемые на" представления о нашей Великой Родине. А>http://transformation.ru/russia/?show=1 А>Я понимаю, что существенно проще принять распространённый стереотип, А>чем самостоятельно поинтересоваться сутью вопроса. Я не буду пытаться А>Вас переубедить. Я лишь надеюсь, что среди читателей этих сообщений А>найдутся люди, готовые подвергнуть стереотип сомнению.
Обсуждение личных особенностей собеседника — в мусорку.
wrote:
> C>Да я знаю, что там он устарел и все такое. > Я имею в виду удобство разработки — время/стоимость/etc.
Писать на нем, кстати, было вполне удобно.
> Да, на Лиспе тоже можно писать [хреновый] код. Особенно, если пытаться > писать в Сишном стиле:
Нормальный там стиль, вполне в духе Лиспа — со своим DSLем и т.п.
Кстати, писалось это на CLISPEе.
> C>После этого я пересел на Java/C#, а потом на С++. Вот тут мне темплейты > C>в С++ и понравились — они ОГРАНИЧЕНЫ в функциональности, поэтому их > C>часто намного легче использовать, чем прямое редактирование AST. > Может быть это конечно и дело вкуса, я не один год с плюсовыми темплейтами > работаю... Но думается мне, что тут дело в попытке использовать Lisp > в "чисто императивном" режиме.
Нет, тут дело в слишком низкоуровневых макросах в Лиспе. С++ные шаблоны
работают над _типами_, а не над кодом, в отличие от Лиспа. Поэтому
шаблоны и удобно использовать — но даже они очень часто из-за misuse'а
становятся крайне запутанными и непонятными.
> C>При этом код был всего примерно в 1Мб. Теперь я понимаю, почему > программ > C>больших 10^6 LOC на Лиспе почти нет. > 1 MLoc на CL для большинства задач (даже весьма серьёзных) просто не > нужен. Надо гораздо меньше.
Для Python'а я знаю систему в 2*10^6 LOC, для Lisp'а я не видел ни одной
даже в 1 миллион LOC. При этом разница по строкам в Питоне и Лиспе будет
весьма небольшой.
Здравствуйте, eao197, Вы писали:
E> Представим себе плотника, который виртуозно владеет своей профессией. Насколько, что с помощью одного лишь топора и без единого гвоздя может построить баньку или небольшую часовеньку. Если собрать нескольких таких же плотников, то они, опять же без единого гвоздя, возведут трехглавую деревянную церьковь, которая простоит лет двести-триста. А если дать им больше времени, то они и семиглавую церьковь поставят. И опять без единого гвоздя.
А с чего ты взял, что "без гвоздей" — это именно Лисп, а не С++?
E>Потому, что объем (даже не сложность, а простой объем) задачи полностью нивелирует разницу в профессиональном уровне матерого плотника и начинающего строителя.
чушь. читаем классиков — Брукса, например. Или хотя бы Сполски.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, eao197, Вы писали:
E>> Представим себе плотника, который виртуозно владеет своей профессией. Насколько, что с помощью одного лишь топора и без единого гвоздя может построить баньку или небольшую часовеньку. Если собрать нескольких таких же плотников, то они, опять же без единого гвоздя, возведут трехглавую деревянную церьковь, которая простоит лет двести-триста. А если дать им больше времени, то они и семиглавую церьковь поставят. И опять без единого гвоздя.
Д>А с чего ты взял, что "без гвоздей" — это именно Лисп, а не С++?
Фокус в том, что на место "без гвоздей" можно поставить любой язык.
Только практика показала, что языки, которые требуют серьезной смены сознания (я сталкивался с Lisp и Prolog, чуть-чуть Smalltalk), широкого применения не получают. Вероятно из-за того, что далеко не все хотят менять свое сознание. И имеют на это право.
E>>Потому, что объем (даже не сложность, а простой объем) задачи полностью нивелирует разницу в профессиональном уровне матерого плотника и начинающего строителя.
Д>чушь. читаем классиков — Брукса, например. Или хотя бы Сполски.
Что именно? Что именно чушь? Что именно читаем (хотя бы конкретную главу, а лучше цитату)?
А Сполски уже классик?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>И объем требует, чтобы строителей было много. А раз много, значит их средний проффессиональный уровень будет невысоким. Значит нужно их снабдить такими инструментами и технологиями, которые позволят при невысоком среднем уровне получать гарантированный результат.
IT>Это очень печально. И то что это так совсем не означает, что это хорошо. Хочется как раз быть просветлённым мастером, а не тупым подмастерьей, занимающим 398459-е место с краю в 835709-ой шеренге.
У кого есть такое желание и достаточно трудолюбия -- тому это доступно. Требуется лишь терпение и время.
Смысл моего возражения был несколько иной. Да и не лишним будет напомнить, что "Metaprogramming et al" появился сначала в "C/C++" в ответ на предложение замутить очень амбициозный велосипедный прожект, который якобы должен был убрать часть недостатков C++.
Я исхожу из того, что Lisp не получил такого широкого распространения, как мейнстримовые языки и технологии. Для меня главной причиной этого является как раз "заумность" Lisp-а, которая отталкивает от него начинающих, да и не только программистов. А раз так, то какую ответственность на себя должен брать лидер проекта, который говорит своей команде -- берем Lisp и делаем проект на нем? Особенно, если в этой команде кроме него никто Lisp-а не знает. Сейчас приходится много думать, прежде чем принимать решения о старте новых проектов на C++ -- языке, гораздо более доступном (в плане средств разработки, готовых библиотек, книг и документации). И не маловажными факторами против C++ являются его сложность и высокие требования к квалификации членов команды. Я сам сталкиваюсь с тем, что сейчас проще найти Java и C# программистов, чем C++. Поэтому начинать проект на C++ и держать в уме такой фактор риска, как сложность замены выбывающих по разным причинам участников команды, уже тяжело. А теперь попробуем заменить C++ на Lisp. Ситуация по этим параметрам ухудшается на порядок, если не больше.
Ну и еще один фактор, который лично меня смущает в этой теме. Имхо, здесь слишком часто делаются голословные утверждения о том, что Lisp лучше, Lisp понятнее, на Lisp-е требуется меньше строк и т.д. Сразу вспоминается американская пословица: "Если ты такой умный, то почему ты не миллионер"?
Если Lisp так хорош, да еще и появился бог знает когда, да еще и развивался в лучшую сторону все это время, то почему мы работаем с C/C++, Java, C#, Perl, VB? Почему, если язык так хорош, уважаемый Аноним сетует
на недостаток Open Source библиотек (в то время как для C++, Java, Perl, Python, Ruby, не в курсе про VB и C#, их просто не счесть) /можно еще раз обратиться к статистике, приведенной Олегом БачинымRe[4]: Объем синтаксиса C#, Delphi 7, Java 2, ... (48 Kb)
/? Может все-таки не все так ладно в "датском короллевстве"?
И давайте не будем вспоминать про "миллионов мух, которые не могут ошибаться". В идустрии разработки ПО этих мух действительно миллионы, но они нуждаются в инструментах, которыми они в состоянии воспользоваться. И выигрывает тот, кто такие инструменты предлагает.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Только практика показала, что языки, которые требуют серьезной смены сознания (я сталкивался с Lisp и Prolog, чуть-чуть Smalltalk), широкого применения не получают. Вероятно из-за того, что далеко не все хотят менять свое сознание. И имеют на это право.
А его (создание) автор и не просит менять... Речь идет лишь о расширении сознания. ФЛП вообще, и Lisp с Prolog'ом в частности — эдакий ЛСД для закостенелого структурно-ООП'шного сознания. Потому как грокнуть вносимые в новое поколение языков фичи иначе не получится. По ширине не пройдет
Здравствуйте, eao197, Вы писали:
Д>>А с чего ты взял, что "без гвоздей" — это именно Лисп, а не С++?
E>Фокус в том, что на место "без гвоздей" можно поставить любой язык.
Разоблачаем фокус — аналогия про плотника не годится для сравнения Лиспа и С++.
E>Если Lisp так хорош, да еще и появился бог знает когда, да еще и развивался в лучшую сторону все это время, то почему мы работаем с C/C++, Java, C#, Perl, VB?
Потому что массы предпочитают то, что проще.
E>И не маловажными факторами против C++ являются его сложность и высокие требования к квалификации членов команды. Я сам сталкиваюсь с тем, что сейчас проще найти Java и C# программистов, чем C++.
Так ведь все технологии развиваются до уровня Лиспа. Вводится GC, closures, метапрограммирование. Соответственно, и требования будут расти всё равно.
И так пока не получится Лисп, ну или Dylan, если синтаксис вложенных списков не нравится.
Здравствуйте, eao197, Вы писали:
E>Только практика показала, что языки, которые требуют серьезной смены сознания (я сталкивался с Lisp и Prolog, чуть-чуть Smalltalk), широкого применения не получают. Вероятно из-за того, что далеко не все хотят менять свое сознание. И имеют на это право.
Необразованные мужики тоже имели право махать топором, а по праздникам бухать и бороться.
Но их не спрашивали, потому что глупые и ничего не понимают. Ввели образование обязательное. Не насильно, но так, что образованный имел больше возможностей.
В результате имеем множество гораздо более умных людей, чем были крестьяне 200-300 лет назад. Которые изобрели компьютеры, интернет, и вообще продвинулись вперёд. Личное развитие никогда не было во вред, как в масштабах одной личности, так и в масштабах страны.
Здравствуйте, eao197, Вы писали:
E>Я исхожу из того, что Lisp не получил такого широкого распространения, как мейнстримовые языки и технологии. Для меня главной причиной этого является как раз "заумность" Lisp-а, которая отталкивает от него начинающих, да и не только программистов.
По своему опыту: в свое время с потока 2-го курса, курс ФЛП (Prolog + Lisp) "оттолкнул" человека 2-3... C/C++ "оттолкнул" гораздо большее кол-во. Заумностью там и близкр не пахнет. Такая формализация нам может только сниться. В свое время, помниться, мы — молодые и зеленые — офигивали от осознания того, что все "навароты", оказывается, можно выразить лишь "одними скобками".
Здравствуйте, jedi, Вы писали:
J>Здравствуйте, pvgoran, Вы писали:
P>>IMHO это вполне возможно. Например, мне очень не хватает closures в С++, и мне думается, что они вполне могли бы заметно поднять качество кода во многих случаях.
J>boost::function<> не устраивает по религиозным причинам?
Причем здесь религия... Я использую и ценю boost::function+boost::lambda, но по сравнению с "нормальными" closures это вещь достаточно ограниченная и очень многословная. А уж как "удобно" их отлаживать (и в compile-time, и в runtime)...
Здравствуйте, <Аноним>, Вы писали:
А>>>Подобная либа есть -- http://www.cliki.net/TypeL
P>>Посмотрел, впечатлился. Правда, моих знаний не хватило, чтобы понять, будет ли оно работать при компиляции.
А>В принципе, ничего не мешает подобной вещи быть компилируемой.
Т.е. есть возможность "навешать" на компиляцию какие-нибудь hook'и, которые проследят за всем чем надо?
P>>А вообще — я так понимаю, чтобы такая библиотека работала в реальных приложениях, P>> нужно описать типы библиотечных функций. Невеселая перспективка... P>>(если только это уже не сделано и не хранится где-то в удобном формате).
А>В детали либы не вглядывался, но, думается мне, это не обязательно.
В общем-то да... Type inference с этим, наверное, может справиться для большинства библиотечных функций.
А>GUI есть -- пожалуйста, CommonWindows/CAPI, или open-source, пусть менее документированные Cells-Gtk, А>McCLIM (для "попробовать" последние два, думаю, также подойдут).
Посмотрю...
А>>>Я хочу сказать, А>>>что победа над некоторыми ошибками, достигаемая строгой типизацией, является Пирровой, А>>>и неудобства, ей причиняемые, перевешивают её преимущества.
P>>Вот это уже более понятно... Хотя и не-особенно-легко-проверяемо.
А>Проверить проще всего, попробовав.
Здравствуйте, Кодёнок, Вы писали:
E>>Если Lisp так хорош, да еще и появился бог знает когда, да еще и развивался в лучшую сторону все это время, то почему мы работаем с C/C++, Java, C#, Perl, VB?
Кё>Потому что массы предпочитают то, что проще.
Вот именно. И это "медицинский факт".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Аноним, Вы писали:
А>2. Учиться. Если у Вас есть немного свободного времени, потратьте его часть на изучение А>языков, которые заставляют человека _думать по другому_. Изучите Lisp, Prolog, Haskell, А>SML, Smalltalk, Erlang (особое внимание стоит уделить Common Lisp'у, как языку А>расширяемому и наиболее практичному). Не давайте мозгам заржаветь, учитесь мыслить шире. А>Для начала, это поможет Вам стать хорошим программистом, даже если на хлеб себе вы будете А>зарабатывать, программируя на других языках. Все мейнстримные языки построены, А>как правило, по принципу "те же яйца, вид сбоку". Осознайте, что мир на самом деле А>не сошёлся на лежащем в их основе наборе стандартных парадигм.
Какую реализацию Lisp-а под Win посоветуете ? Желательно наличие возможности вызова внешних функций написанных на С++.
Здравствуйте, bkat, Вы писали:
B>Интересный топик. B>Только вот перенос его в философию программирования B>сделал невозможным участие анонима в обсуждении...
Я тут — но в данный момент я занят. Позже изложу
некоторые мысли, а пока работать надо
З.Ы. Анонимно писал, т.к. было лениво регистрироваться.
Здравствуйте, eao197, Вы писали:
E>>>Потому, что объем (даже не сложность, а простой объем) задачи полностью нивелирует разницу в профессиональном уровне матерого плотника и начинающего строителя.
Д>>чушь. читаем классиков — Брукса, например. Или хотя бы Сполски.
E>Что именно? Что именно чушь? Что именно читаем (хотя бы конкретную главу, а лучше цитату)?
Книги нет сейчас рядом, поэтому точно не скажу. Можно поискать в той главе, в которой рассматривается организация рубочих групп. "Операционная бригада", вроде бы — но могу и ошибаться. А чушь была в слове "нивелирует" — разница в производительности между "матерым" программистом и начинающим составляет разы или даже порядки, и чем объемнее задача, тем больше становится разница (за исключением тех случаев, когда задача легко и четко разбивается на части)
E>А Сполски уже классик?
Ну я и написал "хотя бы Сполски", если нет под рукой классиков
Здравствуйте, pvgoran, Вы писали:
P>Т.е. есть возможность "навешать" на компиляцию какие-нибудь hook'и, которые проследят за всем чем надо?
Ну так макрос по сути — этьо обычная функция, преобразующая AST->AST. Ничто не мешает ей использовать любые доступные алгоритмы для анализа этого самого AST (в том числе и алгоритмы проверки типов).
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, pvgoran, Вы писали:
P>>Т.е. есть возможность "навешать" на компиляцию какие-нибудь hook'и, которые проследят за всем чем надо?
WF>Ну так макрос по сути — этьо обычная функция, преобразующая AST->AST. Ничто не мешает ей использовать любые доступные алгоритмы для анализа этого самого AST (в том числе и алгоритмы проверки типов).
Вопрос был, можно ли заставить систему делать это при компиляции, а не при выполнении.
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, WFrag, Вы писали:
WF>>Здравствуйте, pvgoran, Вы писали:
P>>>Т.е. есть возможность "навешать" на компиляцию какие-нибудь hook'и, которые проследят за всем чем надо?
WF>>Ну так макрос по сути — этьо обычная функция, преобразующая AST->AST. Ничто не мешает ей использовать любые доступные алгоритмы для анализа этого самого AST (в том числе и алгоритмы проверки типов).
P>Вопрос был, можно ли заставить систему делать это при компиляции, а не при выполнении.
Тебе и говорят, что компиляция от выполнения по сути процессов не отличаются, т.е. там выполняются примерно теже действия, просто в одном случае это функции defun, а в другом макросы лиспа defmacro (не путать с сишными макросами), теже самые функции, только развёртывающиеся не в рантайме (хотя есть интерпретаторы в которых разворот макросов идёт в рантайме, но это отдельная история)
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, WFrag, Вы писали:
WF>>Здравствуйте, pvgoran, Вы писали:
P>>>Т.е. есть возможность "навешать" на компиляцию какие-нибудь hook'и, которые проследят за всем чем надо?
WF>>Ну так макрос по сути — этьо обычная функция, преобразующая AST->AST. Ничто не мешает ей использовать любые доступные алгоритмы для анализа этого самого AST (в том числе и алгоритмы проверки типов).
P>Вопрос был, можно ли заставить систему делать это при компиляции, а не при выполнении.
И ещё — здесь проявляется одна из особенностей лиспа, где код=данные, т.е. над кодом можно выполнять все действия, которые можно выполнять над данными.
Здравствуйте, Курилка, Вы писали:
WF>>>Ну так макрос по сути — этьо обычная функция, преобразующая AST->AST. Ничто не мешает ей использовать любые доступные алгоритмы для анализа этого самого AST (в том числе и алгоритмы проверки типов).
P>>Вопрос был, можно ли заставить систему делать это при компиляции, а не при выполнении.
К>Тебе и говорят, что компиляция от выполнения по сути процессов не отличаются, т.е. там выполняются примерно теже действия, просто в одном случае это функции defun, а в другом макросы лиспа defmacro (не путать с сишными макросами), теже самые функции, только развёртывающиеся не в рантайме (хотя есть интерпретаторы в которых разворот макросов идёт в рантайме, но это отдельная история)
Да, действительно, тут я затупил... Если уж тело функции (которое есть аргумент defun) обрабатывается при компиляции, то скорее всего можно делать то же самое и с аргументом какого-нибудь deftypel.
Кстати, а подобные трюки (преобразования кода/AST) не мешают отладчику понять, какой исходный код соответствует данному исполняемому коду?
Здравствуйте, pvgoran, Вы писали:
P>Кстати, а подобные трюки (преобразования кода/AST) не мешают отладчику понять, какой исходный код соответствует данному исполняемому коду?
Извини, не могу понять, в чём вопрос? По сути у тебя получается рекурсия, в нормальных условиях конечная (и скорее всего ограничивающаяся 1 уровнем), т.е. макрос у тебя может генерировать или другой макрос или код, который и даёт нам итоговый бинарник. Думаю, что можно маркосы зациклить, но в данном случае программист — сам себе злобный буратино, хотя может быть это и обрабатывается какими-либо компиляторами (т.е. честно признаюсь — не ставил такой задачи и проверять желания особо нет )
Получается, что если отвечать на твой вопрос, то у нас есть 2 вида "функций" — 1) просто функции, т.е. уже содержащие итоговый код; 2) функции, которые нужно дальше "разворачивать", чтобы получать функцию с итоговым кодом, т.е. это макросы.
Надеюсь, что сильно не наврал
Да интересная дискуссия, даже зарегился на RSDN, чтоб сюда запостить.
С Лиспом я знаком года 2-3, с тех пор как плотно начал юзать емакс, но именно CL, ну и схемой, заинтересовался только в конце прошлого года. Сначала прочитал, правда не до конца, первый том "Мир Лиспа", как то мне не очень понравилось и я забил, так что не советую вам её читать, очень скучно плюс только в том, что про Common Lisp это единственная книга на русском. Потом, когда появилась в инете Practical Common Lisp, и я его прочитал, да ещё открыл для себя SLIME, всё стало намного интереснее. Язык ИМХО самый навороченный из всех, и причина этому именно макросы в сочетании с простым представлением программ и данных. Чего стоят те же макросы loop & format.
Вы тут обсуждали отсутствие стат. типизации, я вспомнил про declare, хотя это не совсем то, но во первых она выдаёт варнинги при компляции, если при вызове указан не тот тип + ускоряет выполнение, не то что вам нужно? Только конечно это не распространяется на стандартные функции. Я написал небольшой макрос, который делает возможным быстрое объявлении функций, с заданным типом аргументов.
(defun test (b a)
(declare (string b) (integer a))
(format t "~a have ~d apples." b a))
я могу писать так:
(defun-declare-type test ((string b) (integer a))
(format t "~a have ~d apples." b a))
И при создании функции, с не правильным типом второго аргумента в вызове test:
(defun-declare-type test2 ((string a) )
(test "ABC" a))
Выдаётся варнинг:
In: DEFUN-DECLARE-TYPE TEST2
; (TEST "AA" A)
; ==>
; A
; Warning: Result is a BASE-STRING, not a (VALUES &OPTIONAL INTEGER &REST T).
;
; Compilation unit finished.
; 1 warning
совсем маленькое улучшение, но оно показывает, как легко в язык добавляются новые конструкции, причём по нажатию М-. или во время отладки я всёравно попадаю на определения этой функции.
Можно привести пример посложнее из PCL, макрос генерирует класс бинарных данных:
Уже сложнее, но зато получается очень хорошая абстракция, не говоря уже об уменьшении объёма кода.
И именно благодаря столь-удачному подходу к макропрограммированию CL можно ИМХО назвать самым мощным ЯП общего применения.
Ещё мне очень нравиться скорость выполнения, с учётом дин. типизации.
Я как-то переписывал одну вычислительную программку с Python — на CL, так вот при использовании компиляторов CMUCL или SBCL скорость выполнения возросла в 4-5 раз, при примерно одинаковом количестве кода. В CL можно было бы сделать оптимизацию, и тогда бы скорость наверное возросла ещё в несколько раз, но мне было лень.
Ну и конечно REPL + инкрементальная компиляция очень сильно облегчает (можно сказать делает более увлекательным что-ли ) написание и тестирование программ.
Тем кому не нравятся скобки могу ответить, что нужно юзать структурное кодирование, парные скобки вставляются автоматически, и с помощью С-М- комбинаций можно легко передвигаться по сколь-угодно сложным спискам. То есть скобки здесь это огромны плюс.
Вот напримерпример есть функция:
Курсор стоит на место каре, хочу я добавить let к этому выражению,
нажимаю два раза С-M-U(ctrl-alt-u), курсор переноситься на два уровне вверх, т.е. перед скобкой, стоящей перед плюсом. потом нажимаю M-1 ( скобки автоматом добавляются как в начале так и в конце:
При таком подходе намного реже требуется пользоваться стрелками, потомучто мы работаем не с последовательностью знаков, а с вложенными списками и лисп-символами, т.е. над более высокими абстракциями. к тому же префикс C-M- для удобства можно заменить просто на C-.
Можно говорить очень много об отдельных мегафичах CL, таких как например CLOS, но это отдельные и очень объёмные темы.
Так что всё-таки всем советую прочитать хотя-бы Practical Common Lisp, чтобы понять все преимущества Лиспа.
Ну и напоследок хочу сказать что мне не нравиться. Так как стандарт создавался почти 20 лет назад, а он основывался на намного более ранних разработках, в нём присутствует достаточное количество небольших несогласованностей, как например порядок аргументов в функциях доступа к n-ому элементу массива и списка, или невнятные названия некоторых стандартных функций, или атавизмов, как ключ &aux в определении функций. Но в принципе это не играет особой роли при разработке.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, pvgoran, Вы писали:
P>>Кстати, а подобные трюки (преобразования кода/AST) не мешают отладчику понять, какой исходный код соответствует данному исполняемому коду?
К>Извини, не могу понять, в чём вопрос? По сути у тебя получается рекурсия, в нормальных условиях конечная (и скорее всего ограничивающаяся 1 уровнем), т.е. макрос у тебя может генерировать или другой макрос или код, который и даёт нам итоговый бинарник. Думаю, что можно маркосы зациклить, но в данном случае программист — сам себе злобный буратино, хотя может быть это и обрабатывается какими-либо компиляторами (т.е. честно признаюсь — не ставил такой задачи и проверять желания особо нет ) К>Получается, что если отвечать на твой вопрос, то у нас есть 2 вида "функций" — 1) просто функции, т.е. уже содержащие итоговый код; 2) функции, которые нужно дальше "разворачивать", чтобы получать функцию с итоговым кодом, т.е. это макросы. К>Надеюсь, что сильно не наврал
Во время компиляции в CL макросы ПОЛНОСТЬ рекурсивно разворачиваются до примитивов очень низкого уровня.
Вот пример подсчёт кубов чисел до тридцати больших 1000:
(loop for i upto 30 for q = (expt i 3) when (> q 100) summing q)
Здравствуйте, Курилка, Вы писали:
P>>Кстати, а подобные трюки (преобразования кода/AST) не мешают отладчику понять, какой исходный код соответствует данному исполняемому коду?
К>Извини, не могу понять, в чём вопрос? По сути у тебя получается рекурсия, в нормальных условиях конечная (и скорее всего ограничивающаяся 1 уровнем), т.е. макрос у тебя может генерировать или другой макрос или код, который и даёт нам итоговый бинарник. Думаю, что можно маркосы зациклить, но в данном случае программист — сам себе злобный буратино, хотя может быть это и обрабатывается какими-либо компиляторами (т.е. честно признаюсь — не ставил такой задачи и проверять желания особо нет )
Рекурсия макросов не предполагалась.
К>Получается, что если отвечать на твой вопрос, то у нас есть 2 вида "функций" — 1) просто функции, т.е. уже содержащие итоговый код; 2) функции, которые нужно дальше "разворачивать", чтобы получать функцию с итоговым кодом, т.е. это макросы.
Ну, во втором случае речь идет скорее о "вызовах" макросов.
Пример, иллюстрирующий вопрос:
(defmacro (my-transform code) .......)
(my-transform
(if (= x y)
(- x y)
666
)
)
(Сразу скажу — синтаксис defmacro не знаю.)
my-transform, допустим, добавляет в преобразуемый код вызовы, выводящие на экран названия (процедуры) перед каждым вызовом процедуры.
Так вот, получится ли в данном примере пройтись отладчиком по исходному коду, который внутри вызова my-transform?
Здравствуйте, pvgoran, Вы писали:
C>>Вообще, в CL мне не понравилось полное отсутствие нормального синтаксиса C>>(LISP=Lots of Incredibly Silly Paranthesis) и нестатическая типизация. P>А, т.е. статической типизации там нет? Тогда, похоже, тезис о том, что "CL почти-во-всем лучше C++" неверен (т.к. IMHO статическая типизация — мощный и необходимый инструмент, и если его уже нет в языке, я не представляю, как его можно было бы реализовать средствами языка).
Статической типизации в языке нет, но эффективная разница со статически типизированным языком очень невелика на самом деле. Там есть возможность давать аннотации типов и существует несколько статических тайпчекеров. Хотите примеров — почитайте пост в этой ветке http://www.rsdn.ru/Forum/Message.aspx?mid=1266445&only=1
Наличие динамической типизации совсем не означает, что не может быть выполнена статическая проверка типов, что нельзя давать переменным аннотации типов, и что компилятор не определяет типы и не использует эту информацию для кодогенерации. Как я говорил, эффективная разница между статически и современными динамически типизированными языками в наше время очень невелика — мы уже не в 70-х годах двадцатого столетия, и технологии компиляции шагнули далеко вперед. Подробнее в ссылках — повторяться неохота, тему уже обсуждали раз двадцать.
Здравствуйте, fionbio, Вы писали:
F>З.Ы. Анонимно писал, т.к. было лениво регистрироваться.
Зря. Но ничего, я тебе оценочку еще и сюда поставил, чтобы в профиль попала.
P>(Сразу скажу — синтаксис defmacro не знаю.)
P>my-transform, допустим, добавляет в преобразуемый код вызовы, выводящие на экран названия (процедуры) перед каждым вызовом процедуры.
P>Так вот, получится ли в данном примере пройтись отладчиком по исходному коду, который внутри вызова my-transform?
Нажимаю на М-. по названию функции — курсор переходит в начало:
(defun-print-name summ-2 (a b)
(+ a b))
Правда иногда SlLIME глючит, но не часто и вместо перехода к определению, просто печатает функциию в окне.
ЗЫ: отладчик соотвественно подвсечивает то что надо
Здравствуйте, _Obelisk_, Вы писали:
_O_>Какую реализацию Lisp-а под Win посоветуете ? Желательно наличие возможности вызова внешних функций написанных на С++.
P.S. Он юникодный, кстати. В наше время, когда от 90% windows-юзеров имеют NT-систему (2000 или XP), видеть проблемы с кодировками довольно-таки странно
CP>Во время компиляции в CL макросы ПОЛНОСТЬ рекурсивно разворачиваются до примитивов очень низкого уровня.
А я спорил с этим чтоли? Я говорил просто про код, т.е. текстовое представление, т.е. всё развёртывание происходит в компиляторе, но программер-то видит лишь текст только. А вот про ПОЛНОСТЬЮ имхо стандарт не гарантирует этого и тот же Грэхэм утверждает что есть интерпретаторы развёртывающие макросы в рантайме, хотя это и убого по производительности, но ничему по сути не противоречит.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, CrazyPit, Вы писали:
CP>>Да интересная дискуссия, даже зарегился на RSDN, чтоб сюда запостить.
E>
E>А скажи, CrazyPit, проекты какого объема тобой на Lisp-е пишутся? Как долго проект живет/развивается/сопровождается? Какова численность команды?
Список опсорсных проектов можно посмотреть например здесь. Ну а здесь например коммерческие проекты. У меня самого пока ещё нет достаточной практики, пишу сейчас одну программулину для себя. Может попозже возьму что-нить на заказ написать попробовать на лиспе, только проблема в том, что я в основном занимаюсь вебом. А там — perl, php, для питона то долго хостинг искать а для лиспа только если свой сервак...
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, CrazyPit, Вы писали:
CP>>Во время компиляции в CL макросы ПОЛНОСТЬ рекурсивно разворачиваются до примитивов очень низкого уровня.
К>А я спорил с этим чтоли?
Простите, недопонял.
K> Я говорил просто про код, т.е. текстовое представление, т.е. всё развёртывание происходит в компиляторе, но программер-то видит лишь текст только. А вот про ПОЛНОСТЬЮ имхо стандарт не гарантирует этого и тот же Грэхэм утверждает что есть интерпретаторы развёртывающие макросы в рантайме, хотя это и убого по производительности, но ничему по сути не противоречит.
Интересно. А какие реализации разварачиваю в рантайме?
Здравствуйте, CrazyPit, Вы писали:
E>>А скажи, CrazyPit, проекты какого объема тобой на Lisp-е пишутся? Как долго проект живет/развивается/сопровождается? Какова численность команды?
CP>Список опсорсных проектов можно посмотреть например здесь. Ну а здесь например коммерческие проекты. У меня самого пока ещё нет достаточной практики, пишу сейчас одну программулину для себя. Может попозже возьму что-нить на заказ написать попробовать на лиспе, только проблема в том, что я в основном занимаюсь вебом. А там — perl, php, для питона то долго хостинг искать а для лиспа только если свой сервак...
Вообще-то я спрашивал именно про собственные проекты.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, CrazyPit, Вы писали:
CP>Здравствуйте, Курилка, Вы писали:
K>> Я говорил просто про код, т.е. текстовое представление, т.е. всё развёртывание происходит в компиляторе, но программер-то видит лишь текст только. А вот про ПОЛНОСТЬЮ имхо стандарт не гарантирует этого и тот же Грэхэм утверждает что есть интерпретаторы развёртывающие макросы в рантайме, хотя это и убого по производительности, но ничему по сути не противоречит.
CP>Интересно. А какие реализации разварачиваю в рантайме?
Насколько мне помнится, упоминание таких вариантов было в On Lisp, если честно — не вижу особой целесообразности такого.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, CrazyPit, Вы писали:
E>>>А скажи, CrazyPit, проекты какого объема тобой на Lisp-е пишутся? Как долго проект живет/развивается/сопровождается? Какова численность команды?
CP>>Список опсорсных проектов можно посмотреть например здесь. Ну а здесь например коммерческие проекты. У меня самого пока ещё нет достаточной практики, пишу сейчас одну программулину для себя. Может попозже возьму что-нить на заказ написать попробовать на лиспе, только проблема в том, что я в основном занимаюсь вебом. А там — perl, php, для питона то долго хостинг искать а для лиспа только если свой сервак...
E>Вообще-то я спрашивал именно про собственные проекты.
Ну через несколько месяцев могу рассказать и о своих, только они врят-ли будут большими, я студент и работаю пока на себя.
Здравствуйте, CrazyPit, Вы писали:
CP>Нажимаю на М-. по названию функции — курсор переходит в начало: CP>(defun-print-name summ-2 (a b) CP> (+ a b))
А что делает команда M-.?
CP>Правда иногда SlLIME глючит, но не часто и вместо перехода к определению, просто печатает функциию в окне. CP>ЗЫ: отладчик соотвественно подвсечивает то что надо
Здравствуйте, CrazyPit, Вы писали:
E>>Вообще-то я спрашивал именно про собственные проекты.
CP>Ну через несколько месяцев могу рассказать и о своих, только они врят-ли будут большими, я студент и работаю пока на себя.
Понятно. Только, имхо, после такого интересного изложения собственных впечатлений от Lisp было бы здорово прочитать что-то типа:
Наша команда из такого-то количества человек в течении последних N лет занимается развитием продукта, объем которого превышает столько-то тысяч строк. За это время было выпущено столько-то основных версии и столько-то обновлений. За это время нашу команду покинули столько-то человек и пришло столько-то человек. Никто из вновь прибывших никаких проблем с изучением ранее написанного кода не встретил.
Собственно к чему это я. Да просто довелось видеть несколько систем, написанных на Prolog-е, которые активно развивались командами из одного человека в каждой. Т.е. два проекта -- два разработчика. И все было хорошо, пока эти разработчики не вынуждены были покинуть проекты по разным причинам. После чего один проект просто закрылся. А второй был полностью переписан на C++ (причем за тот же срок). Переписан из-за того, что даже если бы кто-то изучил в достаточной степени Prolog, то разобраться в том объеме Prolog-вского кода было просто не реально.
Просто я боюсь, что проекты на Lisp-е будут хорошо выполняться до тех пор, пока их делает небольшая группа увлеченных Lisp-ом разработчиков. Как только эта ситуация нарушается, проект, каким бы успешным и важным он не был, загибается или переписывается: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02367.html
Собственно, ситуация с C++ становится практически такой же
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, pvgoran, Вы писали:
P>Здравствуйте, CrazyPit, Вы писали:
CP>>Нажимаю на М-. по названию функции — курсор переходит в начало: CP>>(defun-print-name summ-2 (a b) CP>> (+ a b))
P>А что делает команда M-.?
Переходит на определение функции по названию (по умолч. то что под курсором)
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, CrazyPit, Вы писали:
E>>>Вообще-то я спрашивал именно про собственные проекты.
CP>>Ну через несколько месяцев могу рассказать и о своих, только они врят-ли будут большими, я студент и работаю пока на себя.
E>Понятно. Только, имхо, после такого интересного изложения собственных впечатлений от Lisp было бы здорово прочитать что-то типа: E>Наша команда из такого-то количества человек в течении последних N лет занимается развитием продукта, объем которого превышает столько-то тысяч строк. За это время было выпущено столько-то основных версии и столько-то обновлений. За это время нашу команду покинули столько-то человек и пришло столько-то человек. Никто из вновь прибывших никаких проблем с изучением ранее написанного кода не встретил.
Мне бы тоже очень хотелось, чтобы было побольше таких отзывов. Ибо я бы не отказался работать в конторе которая ведёт разрабоки на лиспе.
E>Собственно к чему это я. Да просто довелось видеть несколько систем, написанных на Prolog-е, которые активно развивались командами из одного человека в каждой. Т.е. два проекта -- два разработчика. И все было хорошо, пока эти разработчики не вынуждены были покинуть проекты по разным причинам. После чего один проект просто закрылся. А второй был полностью переписан на C++ (причем за тот же срок). Переписан из-за того, что даже если бы кто-то изучил в достаточной степени Prolog, то разобраться в том объеме Prolog-вского кода было просто не реально.
E>Просто я боюсь, что проекты на Lisp-е будут хорошо выполняться до тех пор, пока их делает небольшая группа увлеченных Lisp-ом разработчиков. Как только эта ситуация нарушается, проект, каким бы успешным и важным он не был, загибается или переписывается: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02367.html
E>Собственно, ситуация с C++ становится практически такой же
А с Lispом ситуация наоборот. За послении несколько лет интерес к нему постоянно возростает. К тому-же появились очень эфективные (близкие к быстродействию С++) опенсорсные(что очень важно ибо лиценция на тот же franzовский CL достаточно дорога) компиляторы. Говорят, что на западе появился спрос на лисп-программистов. Я надеюсь что за Lisp только укрепит свои позиции в будующем (возможно в прошлом лисп сильно обогнал своё время, и его врямя наступает только сейчас). И один из главных козырей это DSL, но об этом здесь уже писали.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, CrazyPit, Вы писали:
E>>>Вообще-то я спрашивал именно про собственные проекты.
CP>>Ну через несколько месяцев могу рассказать и о своих, только они врят-ли будут большими, я студент и работаю пока на себя.
E>Понятно. Только, имхо, после такого интересного изложения собственных впечатлений от Lisp было бы здорово прочитать что-то типа:
E>Наша команда из такого-то количества человек в течении последних N лет занимается развитием продукта, объем которого превышает столько-то тысяч строк. За это время было выпущено столько-то основных версии и столько-то обновлений. За это время нашу команду покинули столько-то человек и пришло столько-то человек. Никто из вновь прибывших никаких проблем с изучением ранее написанного кода не встретил.
Есть дядька такой — Пол Грэхэм. Вот он очнь интересно на этот вопрос отвечал. Написал он не много ни мало — yahoo shops. У него на сайте много чего написано о применении Лиспа. Например, вот: http://www.paulgraham.com/avg.html
What were the results of this experiment? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.
Здравствуйте, Gaperton, Вы писали:
G>Есть дядька такой — Пол Грэхэм. Вот он очнь интересно на этот вопрос отвечал. Написал он не много ни мало — yahoo shops. У него на сайте много чего написано о применении Лиспа. Например, вот: G>http://www.paulgraham.com/avg.html G>
G>What were the results of this experiment? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.
Только что прочел. И мне вот это понравилось:
In January 2003, Yahoo released a new version of the editor written in C++ and Perl. It's hard to say whether the program is no longer written in Lisp, though, because to translate this program into C++ they literally had to write a Lisp interpreter: the source files of all the page-generating templates are still, as far as I know, Lisp code. (See Greenspun's Tenth Rule.)
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, _Obelisk_, Вы писали:
_O_>>Какую реализацию Lisp-а под Win посоветуете ? Желательно наличие возможности вызова внешних функций написанных на С++.
Кё>Из бесплатных только CLISP знаю. http://clisp.cons.org/
Кё>P.S. Он юникодный, кстати. В наше время, когда от 90% windows-юзеров имеют NT-систему (2000 или XP), видеть проблемы с кодировками довольно-таки странно
E>>Наша команда из такого-то количества человек в течении последних N лет занимается развитием продукта, объем которого превышает столько-то тысяч строк. За это время было выпущено столько-то основных версии и столько-то обновлений. За это время нашу команду покинули столько-то человек и пришло столько-то человек. Никто из вновь прибывших никаких проблем с изучением ранее написанного кода не встретил.
G>Есть дядька такой — Пол Грэхэм. Вот он очнь интересно на этот вопрос отвечал. Написал он не много ни мало — yahoo shops. У него на сайте много чего написано о применении Лиспа. Например, вот: G>http://www.paulgraham.com/avg.html G>
G>What were the results of this experiment? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.
ты вобще ссылку открывал в сообщении на которое отвечаешь?
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, Кодёнок, Вы писали:
Кё>>Здравствуйте, _Obelisk_, Вы писали:
_O_>>>Какую реализацию Lisp-а под Win посоветуете ? Желательно наличие возможности вызова внешних функций написанных на С++.
Кё>>Из бесплатных только CLISP знаю. http://clisp.cons.org/
Кё>>P.S. Он юникодный, кстати. В наше время, когда от 90% windows-юзеров имеют NT-систему (2000 или XP), видеть проблемы с кодировками довольно-таки странно
_O_>Это я видел, хотелось бы не под cygwin.
Gaperton wrote:
> Есть дядька такой — Пол Грэхэм. Вот он очнь интересно на этот вопрос > отвечал. Написал он не много ни мало — yahoo shops. У него на сайте > много чего написано о применении Лиспа. Например, вот: > http://www.paulgraham.com/avg.html > What were the results of this experiment? Somewhat surprisingly, it > worked. We eventually had many competitors, on the order of twenty to > thirty of them, but none of their software could compete with ours. We > had a wysiwyg online store builder that ran on the server and yet felt > like a desktop application. Our competitors had cgi scripts. And we > were always far ahead of them in features. Sometimes, in desperation, > competitors would try to introduce features that we didn't have. But > with Lisp our development cycle was so fast that we could sometimes > duplicate a new feature within a day or two of a competitor announcing > it in a press release. By the time journalists covering the press > release got round to calling us, we would have the new feature too.
Да, ребята _для_ _того_ _времени_ придумали классный подход к
веб-дизайну — оно было намного лучше CGI (хуже которых что-то сложно
придумать).
Но потом пришла Java и обогнала их по фичам (Cocoon — публикация в XML,
JSP/Servlets+Struts — в создании шаблонов, Tapestry — в "компонентном"
программировании), а всякие Zope'ы/RubyOnRails/PHP обошли их по удобству
использования.
В итоге Yahoo был вынужден переписать их движок на С++ — видимо код
совсем перестал быть поддерживаемым. Я лично на себе тоже подобное
испытал поддерживая чужой код — это было хуже правки глюков в
Boost.Spirit'е под VC6
Здравствуйте, eao197, Вы писали:
E> И объем требует, чтобы строителей было много. А раз много, значит их средний проффессиональный уровень будет невысоким. Значит нужно их снабдить такими инструментами и технологиями, которые позволят при невысоком среднем уровне получать гарантированный результат.
Здесь есть два момента:
1) Вы почему-то пытаетесь выставить Лисп ужасно сложным в обращении и изучении. Неправда. Изучать С++ и программировать на нем существенно сложнее чем на Lisp. И ничего — пишут на С++ дофига.
2) При низком среднем уровне хорошего результата получить невозможно в любом случае. И на С++ — в большей степени, чем на Лисп.
E>И такими инструментами и технологиями как раз является мейнстрим. Причем не только в программировании, но это сейчас не важно. Важно то, что Lisp, как Prolog, как Smalltalk и иже с ними не стали мейнстримом. И не станут.
Вот вы тут упрекали анонима в "религиозности"... А почему вы решили, что это всем так важно? Полу Грэхэму, например, не важно. И мне тоже совершенно все равно, является-ли мой язык "мэйнстримом" и насколько он популярен, и знаете что, мнение участников форума на эту тему для меня еще менее важно. Касательно языков мне интересны другие вещи. Хороша ли поддержка. Есть ли сообщество разработчиков. Как часто выходят maintenance releases. Как с библиотеками и инструментальными средствами. Вы знаете, что у Лиспа с этим более чем все в порядке?
E>Просто потому, что они не пригодны для массового потребления. Это штучный инструмент для штучных задач, который нужен штучным исполнителям.
Это вообще к инженерии не относится. Это, как вы сказали, вопросы "веры и религии".
1) Исполнителям все равно, какие инструменты вы используете, им нужен результат.
2) Вы не можете знать, насколько Prolog, Lisp, и Smalltalk "непригодны для массового потребления". Чтобы это стало ясно, я попрошу вас говорить аргументировано — назвать основания. В таком духе: я хорошо владею [Prolog,Lisp, Smalltalk], и могу заявить, что для массового потребления он не подходит поэтому, поэтому и поэтому. Валяйте. Ответ "я Пастернака не читал, но осуждаю" не канает.
E>Меняем инструмент?
E>Так вот вопрос состоит в том, что же делать: пытаться улучшить свой инструмент и при этом сохранить команду, проекты и огромные объемы готового, отлаженного и работающего кода. Или сделать в своей жизни крутой разворот и воспользоваться Lisp (Smalltalk, Prolog, нужное вписать)? Для кого-то второй вариант окажется гораздо проще и предпочтительнее, но таких не может быть много. Просто потому, что спрос на штучный товар всегда был и будет так же штучным.
Вопрос ставите некорректно.
1) Старый код никто не будет выбрасывать даже в случае перевода перспективных разработок на новый инструмент.
2) Старый код не получает никаких преимуществ он развития языка, на котором он написан — этот код уже отлажен, готов, и работает.
3) Штучный товар или не штучный — вообще здесь не причем. Можете сверлить бетонные стены ручной дрелью, а можете делать в ней дырки перфоратором — клиент ничего кроме дырки в стене не увидит, а перфоратор из дрели вы не сделаете, даже если вы к ручной дрели прикрутите моторчик. А вот сколько дырок вы будете делать вашим инструментом (насчет штучности) — это сугубо ваше решение, инструмент тут не причем.
E>А кто-то пойдет по пути усовершенствования существующего инструмента (грабельки начнет изобретать, костыли мастерить). Кто-то сериализацию сделает, кто-то рефлекшен, кто-то удобные стредства для распределенных вычислений, кто-то организует все так, чтобы один и тот же велосипед дважды не изобретали, кто-то это будет популяризировать. И тогда, через несколько лет, мы оглянемся и скажем: "Ба, а ведь это уже совсем другой язык, совсем другая технология! А мы и не заметили".
Да ради бога. Вот тут, например, недавно в форуме были попытки расширить язык С++ новыми модными фичами, которые были штатными еще в старом добром Algol 68 (что характерно — участники форума "декларативного программирования" рыдали, глядя на эту сцену, а кое кто даже принимал деятельное участие ). Вам Аноним про что написал? Он как раз пытался вытворить над С++ что-то подобное, а тут вдруг выяснил, что уже 40 лет как есть оказывается такой язык — Lisp. В принципе может оно и нафиг не нужно, с С++ ковыряться, а? Зачем? Аноним проникся бессмысленностью и суетностью процесса изготовления костылей, с чем поспешил с вами поделиться.
А вы его в религиозные проповедники записываете — не выделывайся мол, наши деды на костылях ходили, все на них ходят, и ты ходи, и не смущай тут народ. Через пару лет, мол, изобретут костыли такие специальные, на которых можно будет бегом бегать. Смешно.
Здравствуйте, Cyberax, Вы писали:
C>В итоге Yahoo был вынужден переписать их движок на С++ — видимо код C>совсем перестал быть поддерживаемым. Я лично на себе тоже подобное C>испытал поддерживая чужой код — это было хуже правки глюков в C>Boost.Spirit'е под VC6
Все гораздо проще. Это называется — в Yahoo съэкономили на программистах ...
(a) The reason they rewrote it was entirely that the
current engineers didn't understand Lisp and were too
afraid to learn it.
Менеджмент Yahoo благодаря своим талантливым действиям попал в ситуацию, что не осталось ни одного инженера, знакомого со старой системой. И систему начали переписывать. Знакомо, знакомо.
Язык здесь, собственно, ни при чем. Что касается сложности Лиспа — это первый язык в целом ряде американских универов, например MIT. И ничего, никто его учить не боится. В целом, нанять Лисп-программистом в Штатах не проблема. Если конечно задаться целью.
Здравствуйте, eao197, Вы писали:
E>Только что прочел. И мне вот это понравилось: E>
E>In January 2003, Yahoo released a new version of the editor written in C++ and Perl. It's hard to say whether the program is no longer written in Lisp, though, because to translate this program into C++ they literally had to write a Lisp interpreter: the source files of all the page-generating templates are still, as far as I know, Lisp code. (See Greenspun's Tenth Rule.)
> (a) The reason they rewrote it was entirely that the
> current engineers didn't understand Lisp and were too
> afraid to learn it.
>
> (b) The resulting program is a new world's record case
> of Greenspun's Tenth Rule. The Yahoo Store Editor called
> compile at runtime on s-expressions made on the fly.
> To translate this into C++ they literally had to write a
> Lisp interpreter.
>
This is an interesting state of affairs. We have engineers that are afraid
to learn lisp, but are not afraid to use a mock-lisp interpreter written in
C++. I'm not sure whether to laugh or to cry.
И я совершенно согласен с автором этого сообщения. Более идиотского решения, чем описано здесь, придумать сложно.
Gaperton wrote:
> Все гораздо проще. Это называется — в Yahoo съэкономили на > программистах ...
Вы уверены, что все так просто?
> (a) The reason they rewrote it was entirely that the > current engineers didn't understand Lisp and were too > afraid to learn it. > Менеджмент Yahoo благодаря своим талантливым действиям попал в > ситуацию, что не осталось ни одного инженера, знакомого со старой > системой. И систему начали переписывать. Знакомо, знакомо.
А куда сам Грэхем сбежал? Побоялся поддерживать систему? Знакомо, знакомо.
> Язык здесь, собственно, ни при чем. Что касается сложности Лиспа — это > первый язык в целом ряде американских универов, например MIT. И > ничего, никто его учить не боится. В целом, нанять Лисп-программистом > в Штатах не проблема. Если конечно задаться целью.
Так не сложность _языка_ составляет проблему, а сложность
программирования на нем. Самый простой язык — это вообще ассемблер. Все
команды вида: xxx arg1,arg2[,arg3] и еще немного ключевых слов.
Gaperton wrote:
> This is an interesting state of affairs. We have engineers that are afraid > to learn lisp, but are not afraid to use a mock-lisp interpreter > written in > C++. I'm not sure whether to laugh or to cry. > И я совершенно согласен с автором этого сообщения. Более идиотского > решения, чем описано здесь, придумать сложно.
Возможно сыграла роль инерция мышления (у нас уже были шаблоны на Лиспе
— пусть и остаются) или какие-то другие факторы (например, желание
сохранить уже готовый функционал в шаблонах). Тут сложно сказать не зная
структуры проекта.
Gaperton wrote:
> А вы его в религиозные проповедники записываете — не выделывайся мол, > наши деды на костылях ходили, все на них ходят, и ты ходи, и не смущай > тут народ. Через пару лет, мол, изобретут костыли такие специальные, > на которых можно будет бегом бегать. Смешно.
А вы уверены, что Лисповцы не ходят на своих особенных "скобковых"
костылях? Мне вот почему-то именно так кажется.
Здравствуйте, Gaperton, Вы писали:
G>This is an interesting state of affairs. We have engineers that are afraid G>to learn lisp, but are not afraid to use a mock-lisp interpreter written in G>C++. I'm not sure whether to laugh or to cry.
G>И я совершенно согласен с автором этого сообщения. Более идиотского решения, чем описано здесь, придумать сложно.
И я согласен. Но проблема в том, что такое будет случаться сплошь и рядом. Если уж Yahoo не смогло нанять нужного количества Lisp разработчиков для сопровождения системы, то что уж говорить про СНГ?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
. И поэтому я воспринял как своего рода рецепт: "Ребята, не страдайте фигней на C++, не изобретайте велосипедов и костылей, начните программировать на Lisp-е". Поэтому я и ответил так, как думаю -- в настоящий момент, для большинства команд, ведущих разработку на C++, смена языка реализации на Lisp просто не реальна. И постарался объяснить, почему я так думаю.
Так же, хочу сказать, что после перемещения данной темы в "Философию программирования", мой пост потерял значительную часть своего смысла. Здесь я начинаю казаться ярым противником Lisp-а. Это не так. Я не знаю lisp-а, когда-то имел начальные знания о нем, и никогда ничего на Lisp-е не писал. Поэтому не могу сказать про него ничего плохого, за исключением, имхо, write-only синтаксиса. Вот против чего я возражаю -- так это против того, что Lisp является серьезной альтернативой для большинства современных C++ проектов.
E>>И такими инструментами и технологиями как раз является мейнстрим. Причем не только в программировании, но это сейчас не важно. Важно то, что Lisp, как Prolog, как Smalltalk и иже с ними не стали мейнстримом. И не станут.
G>Вот вы тут упрекали анонима в "религиозности"... А почему вы решили, что это всем так важно? Полу Грэхэму, например, не важно.
Пол Грэхэм продолжает писать Yahoo Shop? Или после его ухода проект был переписан потому, что никому Lisp не был интересен и нужен?
Так вот моя точка зрения в том, что мейнстримовые языки и технологии обещают хоть какую-то гарантию того, что проект будет продолжен без особых усилий даже после того, как его покинут отцы-основатели.
G> И мне тоже совершенно все равно, является-ли мой язык "мэйнстримом" и насколько он популярен, и знаете что, мнение участников форума на эту тему для меня еще менее важно.
Тем не менее на мое сообщение ты отреагировал.
G> Касательно языков мне интересны другие вещи. Хороша ли поддержка. Есть ли сообщество разработчиков. Как часто выходят maintenance releases. Как с библиотеками и инструментальными средствами. Вы знаете, что у Лиспа с этим более чем все в порядке?
.
G>1) Исполнителям все равно, какие инструменты вы используете, им нужен результат.
Именно так, до тех пор, пока покупатель не заинтересован в покупке всей технологии целиком, включая исходные тексты.
Так же проблемы с малораспространнеными технологиями появляются и у исполнителя, когда оказывается неким заменить выбывающих разработчиков.
G>2) Вы не можете знать, насколько Prolog, Lisp, и Smalltalk "непригодны для массового потребления". Чтобы это стало ясно, я попрошу вас говорить аргументировано — назвать основания. В таком духе: я хорошо владею [Prolog,Lisp, Smalltalk], и могу заявить, что для массового потребления он не подходит поэтому, поэтому и поэтому. Валяйте. Ответ "я Пастернака не читал, но осуждаю" не канает.
Я могу заявить, что изучал в университете Prolog и уже тогда понял, что крайне тяжело разобраться в чужой прологовской программе. Еще свои мысли можно сформулировать и записать, а вот понять, что именно хотел сделать другой автор и почему от так сделал -- вот это для меня была проблема. Собственно, в этом я убедился, когда на моих глазах умерло два прологовских проекта из-за того, что их разработчики были вынуждены занятся другими вещами.
А ответ "я Пастернака не читал, но осуждаю" здесь может-таки быть уместным, поскольку у меня нет ни одного знакомого программиста, который бы что-то писал на Lisp-е. Так что даже впечатление о языке из первых уст я не могу получить иначе, как в Интернете. И что, в таких условиях можно браться за выполнение коммерческих проектов на Lisp-е?
G>2) Старый код не получает никаких преимуществ он развития языка, на котором он написан — этот код уже отлажен, готов, и работает.
Нет, он получает главное преимущество -- продолжает работать. И может использоваться повторно.
G>3) Штучный товар или не штучный — вообще здесь не причем. Можете сверлить бетонные стены ручной дрелью, а можете делать в ней дырки перфоратором — клиент ничего кроме дырки в стене не увидит, а перфоратор из дрели вы не сделаете, даже если вы к ручной дрели прикрутите моторчик. А вот сколько дырок вы будете делать вашим инструментом (насчет штучности) — это сугубо ваше решение, инструмент тут не причем.
Причем, если вопрос встанет о том, как много дрелей/перфораторов я смогу приобрести и во сколько рабочих рук я смогу их отдать. И здесь уже лучше сравнивать не с ручной дрелью (поскольку это больше смахивает на ассемблер), сколько на перфораторы разной мощности и производительности. И здесь не факт что приобретение 50-ти супер-пупер Boshe перфораторов будет выгоднее приобретения и технического обслуживания 75-ти более простых и дешевых DWT. Тем более, что заранее сложно сказать, что пользователи этого инструмента будут очень толковыми, аккуратными и не вороватыми.
G>А вы его в религиозные проповедники записываете — не выделывайся мол, наши деды на костылях ходили, все на них ходят, и ты ходи, и не смущай тут народ. Через пару лет, мол, изобретут костыли такие специальные, на которых можно будет бегом бегать. Смешно.
Может быть. Только, имхо, серебрянной пули не существует. Достоинства Lisp-а наверняка нивелируются какими-то его недостаками. Если бы это было не так, то все бы давно на Lisp-е программировали. А поскольку это не произошло, значит Lisp -- такие же костыли. Может быть чуть удобнее, и бегать в них можно прямо сейчас. А в C++ этого чуть подождать придется (если повезет ).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
>> Все гораздо проще. Это называется — в Yahoo съэкономили на >> программистах ... C>Вы уверены, что все так просто?
В общем — да. Это единственная причина для столь идиотского поступка. Когда решают нечто переписать, делают это совсем не транслируя код автоматом из одного языка в другой. Переписывают потихоньку, подсистему за подсистемой, не сворачивая поддержки старой системы.
>> (a) The reason they rewrote it was entirely that the >> current engineers didn't understand Lisp and were too >> afraid to learn it. >> Менеджмент Yahoo благодаря своим талантливым действиям попал в >> ситуацию, что не осталось ни одного инженера, знакомого со старой >> системой. И систему начали переписывать. Знакомо, знакомо.
C>А куда сам Грэхем сбежал? Побоялся поддерживать систему? Знакомо, знакомо.
Знакомо? "Побоялся" — нет такого слова, когда речь идет о наемной работе. Никого вам на "слабо" взять не получится. Это называется по другому — "мало заплатили". Ну, заплатят еще больше за переписывание.
>> Язык здесь, собственно, ни при чем. Что касается сложности Лиспа — это >> первый язык в целом ряде американских универов, например MIT. И >> ничего, никто его учить не боится. В целом, нанять Лисп-программистом >> в Штатах не проблема. Если конечно задаться целью.
C>Так не сложность _языка_ составляет проблему, а сложность C>программирования на нем.
Там ясно было сказано что составляет проблему — "очень боятся его изучать".
C>Самый простой язык — это вообще ассемблер. Все C>команды вида: xxx arg1,arg2[,arg3] и еще немного ключевых слов.
Gaperton wrote:
>>> Все гораздо проще. Это называется — в Yahoo съэкономили на >>> программистах ... > C>Вы уверены, что все так просто? > В общем — да. Это единственная причина для столь идиотского поступка. > Когда решают нечто переписать, делают это совсем не транслируя код > автоматом из одного языка в другой.
Так вроде бы никто и не транслировал — просто ее переписали.
> Переписывают потихоньку, подсистему за подсистемой, не сворачивая > поддержки старой системы.
Я что-то не помню, чтобы Яху когда-то останавливался. Значит поддержка
старой системы на время переписывания все-таки была.
А то что переписывали по подсистемами — так про это сам Грэхем сказал.
Сначала переписали ядро, но отсавили для совместимости старые шаблоны.
> C>А куда сам Грэхем сбежал? Побоялся поддерживать систему? Знакомо, > знакомо. > Знакомо? "Побоялся" — нет такого слова, когда речь идет о наемной > работе. Никого вам на "слабо" взять не получится. Это называется по > другому — "мало заплатили".
Это называется: "Меня не уволят, пока эта система будет использоваться —
ведь никто кроме меня ее не понимает". И это говорит далеко не в пользу
автора системы.
> Ну, заплатят еще больше за переписывание.
Иногда это имеет смысл.
> C>Так не сложность _языка_ составляет проблему, а сложность > C>программирования на нем. > Там ясно было сказано что составляет проблему — "очень боятся его > изучать".
Незнаю бояться ли, скорее просто не хотят. И я их понимаю, ведь любимый
стиль всех Лиспоидов — это придумать свой DSL, в котором фиг потом
разберешься.
> C>Самый простой язык — это вообще ассемблер. Все > C>команды вида: xxx arg1,arg2[,arg3] и еще немного ключевых слов. > Лисп проще в использовании, чем "modern С++".
ИМХО, ничуть не проще. Я уже рассказал о своем опыте поддержки Лисп-системы.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton
E> Поэтому я и ответил так, как думаю -- в настоящий момент, для большинства команд, ведущих разработку на C++, смена языка реализации на Lisp просто не реальна. И постарался объяснить, почему я так думаю.
Для текущего проекта смена языка реализации нереальна, это и так всем понятно. Для новых проектов это вполне может иметь смысл, почему нет? Это первое, и второе — кто-то заставляет сразу писать на незнакомой платформе критичный проект? Боже упаси. Стратегия перехода на новую платформу предполагает существенно более сложный сценарий, и это, как я думал, не является предметом дискуссии.
Но если говорить о смене платформы — то и это вполне возможно. Только начинать надо с микропрототипов для proof of the concept. А потом (если все в порядке) с маленьких некритичных проектов. Потом (если итоги их внедрения и экстплуатации положительны), внедрять новую платформу шире, с учетом накопленного опыта. Только осторожно, никакой спешки, риски надо контроллировать.
Замечу, это все совершенно не является темой письма Анонима на мой взгляд. То есть, ИМХО вы возражаете ему не по существу.
E>Так же, хочу сказать, что после перемещения данной темы в "Философию программирования", мой пост потерял значительную часть своего смысла.
Ок, поправка принята. Учту.
E>Вот против чего я возражаю -- так это против того, что Lisp является серьезной альтернативой для большинства современных C++ проектов.
Ну что же, я именно так вас и понял
E>>>И такими инструментами и технологиями как раз является мейнстрим. Причем не только в программировании, но это сейчас не важно. Важно то, что Lisp, как Prolog, как Smalltalk и иже с ними не стали мейнстримом. И не станут.
G>>Вот вы тут упрекали анонима в "религиозности"... А почему вы решили, что это всем так важно? Полу Грэхэму, например, не важно.
E>Пол Грэхэм продолжает писать Yahoo Shop? Или после его ухода проект был переписан потому, что никому Lisp не был интересен и нужен?
Нет, после его ухода Yahoo был переписан потому, что не осталось инженеров знакомых с системой, и менеджеры Yahoo приняли (глупое) решение сменить платформу. Это вторая их ошибка — первая была в том, что они позволили уйти ключевым специалистам. Yahoo не первый, и не последний — такая история происходит много где, и язык здесь не причем. Вот, например, как было у нас? Стоило нашему CTO не подумавши объявить, что мы сворачиваем UNIX разработки и переводим весь софт на Windows, как компания в течении месяца потеряла лучших специалистов по соответствующим системам, они сменили работу, поставив компанию в интересную позу. Следует ли из этого, что UNIX — плохая серверная платформа?
E>Так вот моя точка зрения в том, что мейнстримовые языки и технологии обещают хоть какую-то гарантию того, что проект будет продолжен без особых усилий даже после того, как его покинут отцы-основатели.
Эта гарантия мнимая. Современный софт по своему устройству существенно сложнее языков и платформ, на которых он написан. При потере ключевых специалистов высока вероятность, что его придется переписать, независимо от языка.
G>> И мне тоже совершенно все равно, является-ли мой язык "мэйнстримом" и насколько он популярен, и знаете что, мнение участников форума на эту тему для меня еще менее важно. E>Тем не менее на мое сообщение ты отреагировал.
Но спорить с тобой насчет популярности не буду. :-P
G>> Касательно языков мне интересны другие вещи. Хороша ли поддержка. Есть ли сообщество разработчиков. Как часто выходят maintenance releases. Как с библиотеками и инструментальными средствами. Вы знаете, что у Лиспа с этим более чем все в порядке?
E>Правда? А вот инициатор этой темы, Re[2]: Metaprogramming et al
Пардон? Ему не вполне хватает open-sourceных гуевыхбиблиотек хорошего качества, при этом он заметил, что с платными либами все в порядке. Много у нас таких либов под C#? Впрочем, Гуй я на Lisp писать бы наверное не стал, для этого и "обычные" языки неплохо подходят. Если, конечно, не говорить о С++ .
G>>1) Исполнителям все равно, какие инструменты вы используете, им нужен результат.
E>Именно так, до тех пор, пока покупатель не заинтересован в покупке всей технологии целиком, включая исходные тексты.
С этим соглашусь. Но тогда о выборе языка вообще речи не идет, и говорить вообще не о чем, не так ли? E>Так же проблемы с малораспространнеными технологиями появляются и у исполнителя, когда оказывается неким заменить выбывающих разработчиков.
Да, это может стать проблемой. Но опять же — научится платформе проще, чем разобраться в написанном на нем приложении. Эта проблема не является showstopper-ом, и в любом случае рещается управлением кадрами.
G>>2) Вы не можете знать, насколько Prolog, Lisp, и Smalltalk "непригодны для массового потребления". Чтобы это стало ясно, я попрошу вас говорить аргументировано — назвать основания. В таком духе: я хорошо владею [Prolog,Lisp, Smalltalk], и могу заявить, что для массового потребления он не подходит поэтому, поэтому и поэтому. Валяйте. Ответ "я Пастернака не читал, но осуждаю" не канает.
E>Я могу заявить, что изучал в университете Prolog и уже тогда понял, что крайне тяжело разобраться в чужой прологовской программе. Еще свои мысли можно сформулировать и записать, а вот понять, что именно хотел сделать другой автор и почему от так сделал -- вот это для меня была проблема. E>Собственно, в этом я убедился, когда на моих глазах умерло два прологовских проекта из-за того, что их разработчики были вынуждены занятся другими вещами
Ну и что? Сколько надо изучать С++, чтобы уметь разбираться в коде, написаном с применением boost и вывертов в духе modern C++? Не зная при этом ни одного похожего языка, и будучи незнакомым с ОО (вы ведь на момент изучения Prolog не были знакомы с декларативными языками, так)? Годика два? А если этот код еще и написан плохо?
В случае с Lisp этот срок поменьше — через несколько месяцев плотной работы (полный рабочий день) в команде со знающими людьми все будет в порядке.
E>А ответ "я Пастернака не читал, но осуждаю" здесь может-таки быть уместным, поскольку у меня нет ни одного знакомого программиста, который бы что-то писал на Lisp-е. Так что даже впечатление о языке из первых уст я не могу получить иначе, как в Интернете. И что, в таких условиях можно браться за выполнение коммерческих проектов на Lisp-е?
Нет конечно, но никто вам не предлагает так делать. Даже упомянутый Аноним, кстати. Процедуру опроборования новой технологии я описал в начале письма. И так надо поступать с любой технологией, не только с Лисп.
G>>2) Старый код не получает никаких преимуществ он развития языка, на котором он написан — этот код уже отлажен, готов, и работает. E>Нет, он получает главное преимущество -- продолжает работать. И может использоваться повторно.
Он и без этого продолжит работать гораздо вернее и ничего ему не мешает быть использованным повторно.
G>>3) Штучный товар или не штучный — вообще здесь не причем. Можете сверлить бетонные стены ручной дрелью, а можете делать в ней дырки перфоратором — клиент ничего кроме дырки в стене не увидит, а перфоратор из дрели вы не сделаете, даже если вы к ручной дрели прикрутите моторчик. А вот сколько дырок вы будете делать вашим инструментом (насчет штучности) — это сугубо ваше решение, инструмент тут не причем.
E>Причем, если вопрос встанет о том, как много дрелей/перфораторов я смогу приобрести и во сколько рабочих рук я смогу их отдать. И здесь уже лучше сравнивать не с ручной дрелью (поскольку это больше смахивает на ассемблер), сколько на перфораторы разной мощности и производительности. И здесь не факт что приобретение 50-ти супер-пупер Boshe перфораторов будет выгоднее приобретения и технического обслуживания 75-ти более простых и дешевых DWT. Тем более, что заранее сложно сказать, что пользователи этого инструмента будут очень толковыми, аккуратными и не вороватыми.
В общем, да, Lisp в руках индусов страшнее промышленного перфоратора, если вы об этом . Но они и с С++ управляются так, что живые мертвым завидуют. Видите-ли, Лисп на самом деле прост в использовании . Люди в американских универах вполне успешно и без проблем ему обучаются. Что нельзя сказать о С++ — вот уж его кому попало в руки давать нельзя точно. Но ведь дают, и ничего.
G>>А вы его в религиозные проповедники записываете — не выделывайся мол, наши деды на костылях ходили, все на них ходят, и ты ходи, и не смущай тут народ. Через пару лет, мол, изобретут костыли такие специальные, на которых можно будет бегом бегать. Смешно.
E>Может быть. Только, имхо, серебрянной пули не существует. Достоинства Lisp-а наверняка нивелируются какими-то его недостаками. Если бы это было не так, то все бы давно на Lisp-е программировали. А поскольку это не произошло, значит Lisp -- такие же костыли. Может быть чуть удобнее, и бегать в них можно прямо сейчас.
Угу . Грабли везде есть, кто ж спорит-то. Лисп — это, знаете-ли, уникальный костыль-трансформер — звоните сейчас и получите 5% скидку.
E> А в C++ этого чуть подождать придется (если повезет ).
Лучше не надо. С++ — и без возможности бега на костылях переусложнен донельзя .
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>This is an interesting state of affairs. We have engineers that are afraid G>>to learn lisp, but are not afraid to use a mock-lisp interpreter written in G>>C++. I'm not sure whether to laugh or to cry.
G>>И я совершенно согласен с автором этого сообщения. Более идиотского решения, чем описано здесь, придумать сложно.
E>И я согласен. Но проблема в том, что такое будет случаться сплошь и рядом. Если уж Yahoo не смогло нанять нужного количества Lisp разработчиков для сопровождения системы, то что уж говорить про СНГ?
В общем, да, стоит признать это проблемой. Как с ней бороться, это другой вопрос, но риски выше, по-любому.
Здравствуйте, Gaperton, Вы писали:
E>>И я согласен. Но проблема в том, что такое будет случаться сплошь и рядом. Если уж Yahoo не смогло нанять нужного количества Lisp разработчиков для сопровождения системы, то что уж говорить про СНГ? G>В общем, да, стоит признать это проблемой. Как с ней бороться, это другой вопрос, но риски выше, по-любому.
Этот вопрос можно решить, если
1. популязировать лисп на ресурсах рунета.
2. Выложить где-нибудь в свободном доступе какую-нибудь популистскую книжку типа Practical Common Lisp на русском, тогда ИМХО количество программеров в СНГ, разбирающихся в Лиспе возрастёт на несколько сотен или даже тысяч.
Здравствуйте, pvgoran, Вы писали:
P>А, т.е. статической типизации там нет? Тогда, похоже, тезис о том, что "CL почти-во-всем лучше C++" неверен (т.к. IMHO статическая типизация — мощный и необходимый инструмент, и если его уже нет в языке, я не представляю, как его можно было бы реализовать средствами языка).
Если интересует статическая типизация и одновременно ФЯ и метопрограммирование, то наверно стоит обратить внимание на Ocaml. Там и мощьный препроцессор есть который плюсовое метапрограммирование сделает как котенка. И отличные средства обобщенного программирования (что забавно шаблонов там нема, но плюсы отдыхают по полной прграмме). И статическая типобезопасность такая, что даже Шарп с Явой отдыхают. В прочем свои проблемы там тоже есть. Язык далек от идеальной красоты.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Но потом пришла Java и обогнала их по фичам (Cocoon — публикация в XML, C>JSP/Servlets+Struts — в создании шаблонов, Tapestry — в "компонентном" C>программировании), а всякие Zope'ы/RubyOnRails/PHP обошли их по удобству C>использования.
C>В итоге Yahoo был вынужден переписать их движок на С++
Звучит как полный бред. Java, Zope'ы/RubyOnRails/PHP обошли Лисп и именно по этому движок переписали на С++. Что же не на асме, то? Было бы еще логичнее.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
E>> Поэтому я и ответил так, как думаю -- в настоящий момент, для большинства команд, ведущих разработку на C++, смена языка реализации на Lisp просто не реальна. И постарался объяснить, почему я так думаю. G>Для текущего проекта смена языка реализации нереальна, это и так всем понятно. Для новых проектов это вполне может иметь смысл, почему нет? Это первое, и второе — кто-то заставляет сразу писать на незнакомой платформе критичный проект? Боже упаси. Стратегия перехода на новую платформу предполагает существенно более сложный сценарий, и это, как я думал, не является предметом дискуссии.
Вот здесь и кроется основное несовпадение наших мнений. Вот ты говоришь: "Для новых проектов это вполне может иметь смысл, почему нет?" Но у меня есть вопрос: "А почему да?"
Мало того, что у меня вообще есть бОльшие сомнения на счет целесообразности смены C++ на что-то другое. Так еще и есть бОльшие сомнения, что переход на Lisp приведет к упрощению, удешевлению и повышению качества разработки. При этом я исхожу из двух статистических фактов:
— язык Lisp менее распространен, чем C++/Java/C#/Python/Ruby. В качестве доказательства используем количество проектов на этих языках на SourceForge.net: Re[4]: Объем синтаксиса C#, Delphi 7, Java 2, ... (48 Kb)
;
— для языка Lisp гораздо меньше готовых специалистов. А так же гораздо меньше доступных в продаже книг, по которым этих специалистов можно готовить.
Ну и добавить сюда можно еще и небольшую реплику по поводу следующего абзаца:
G>Но если говорить о смене платформы — то и это вполне возможно. Только начинать надо с микропрототипов для proof of the concept. А потом (если все в порядке) с маленьких некритичных проектов. Потом (если итоги их внедрения и экстплуатации положительны), внедрять новую платформу шире, с учетом накопленного опыта. Только осторожно, никакой спешки, риски надо контроллировать.
Имхо, когда компания выпускает несколько упешных продуктов и в живет за счет их тиражирования (в той или иной мере), то такой плавный переход на новую технологию может сильно затянуться. Я представляю для своих условий этот процесс и думаю, что только переход на создание новых продуктов сразу на Lisp стал бы возможен не раньше, чем через два-три года. А ведь остался бы багаж существующих проектов на C++/Java -- переписывать их на Lisp точно бы никто не стал. Даже при выходе следующей major версии какого-то продукта не факт, что оказалось бы дешевле делать ее с нуля на Lisp. А включение унаследованного C++/Java кода через какие-то переходники в Lisp код так же не кажется мне хорошим решением.
Так что для меня бОльшой и открытый вопрос: стоит ли сейчас вкладываться в постепенное освоение Lisp-а с тем, чтобы через несколько лет сделать его основной технологией разработки. Пока мне кажется более предпочтительным вкладываться в около-C++-ные технологии. В тот же boost, например.
По ходу остальных комментариев, я в большей степени с тобой согласен. Есть пара мелких дополнений.
E>>Пол Грэхэм продолжает писать Yahoo Shop? Или после его ухода проект был переписан потому, что никому Lisp не был интересен и нужен?
G>Нет, после его ухода Yahoo был переписан потому, что не осталось инженеров знакомых с системой, и менеджеры Yahoo приняли (глупое) решение сменить платформу. Это вторая их ошибка — первая была в том, что они позволили уйти ключевым специалистам. Yahoo не первый, и не последний — такая история происходит много где, и язык здесь не причем.
Здесь сложно сказать, что повлияло на решение Грэхэм-а. Так же не понятно, выиграла или проиграла Yahoo от своего решения -- время покажет. Только вот то, что Yahoo не захотело продолжать развитие проекта (который не закрыт, нужно заметить) средтствами Lisp, выглядит как тревожный симптом.
E>>Так вот моя точка зрения в том, что мейнстримовые языки и технологии обещают хоть какую-то гарантию того, что проект будет продолжен без особых усилий даже после того, как его покинут отцы-основатели.
G>Эта гарантия мнимая. Современный софт по своему устройству существенно сложнее языков и платформ, на которых он написан. При потере ключевых специалистов высока вероятность, что его придется переписать, независимо от языка.
Тем не менее, она срабатывает. Бывают же случаи, когда основной разработчик не уходит совсем, а переходит на другой проект или на руководящую должность. Поэтому он остается доступен для того, чтобы объяснить тонкости системы. Важно то, что с мейнстримом гораздо меньше технических препятствий для смены поколений разработчиков -- просто готовых специалистов по мейнстримовым технологиям больше.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>А вы уверены, что Лисповцы не ходят на своих особенных "скобковых" C>костылях? Мне вот почему-то именно так кажется.
Ну зачем к скобкам то цепляться? Это уже губановщина какая-то получается. Главное — фичи языка, а не синтаксис. Тем более что скобка — это не begin, всего лишь один символ. Ее написать нетрудно.
Здравствуйте, eao197, Вы писали:
E>И я согласен. Но проблема в том, что такое будет случаться сплошь и рядом. Если уж Yahoo не смогло нанять нужного количества Lisp разработчиков для сопровождения системы, то что уж говорить про СНГ?
Не смогло или не захотело — это еще вопрос. Слишком часто у менеджмента возникает желание вместо одного хорошего программиста взять двух, но подешевле
Здравствуйте, eao197, Вы писали:
E>Собственно к чему это я. Да просто довелось видеть несколько систем, написанных на Prolog-е, которые активно развивались командами из одного человека в каждой. Т.е. два проекта -- два разработчика. И все было хорошо, пока эти разработчики не вынуждены были покинуть проекты по разным причинам. После чего один проект просто закрылся. А второй был полностью переписан на C++ (причем за тот же срок). Переписан из-за того, что даже если бы кто-то изучил в достаточной степени Prolog, то разобраться в том объеме Prolog-вского кода было просто не реально.
E>Собственно, ситуация с C++ становится практически такой же
Ты всё время рассуждаешь в стиле "обстоятельства не в нашу пользу, мы вынуждены выбирать другое". Речь ведь не идёт о том, чтобы вдруг все сразу взяли и перешли на Лисп, когда для него нет ни разработчиков, ни программ в ВУЗах, почти ничего существенного. Я абсолютно согласен, что начинать новый проект на Лиспе для большинства команд сейчас вообще не вариант.
На С++/STL тоже не сразу стали писать. Огромное количество опенсорс-проектов до сих пор пишется на Си, в стиле "эмуляции С++" и начинаются новые, но С++ занимает всё больше места.
Главная идея такая, что дальнейшее развитие самых популярных языков (С++, C#, Java) в конце концов сделает из них Лисп
Здравствуйте, _Obelisk_, Вы писали:
Кё>>Из бесплатных только CLISP знаю. http://clisp.cons.org/
Кё>>P.S. Он юникодный, кстати. В наше время, когда от 90% windows-юзеров имеют NT-систему (2000 или XP), видеть проблемы с кодировками довольно-таки странно
_O_>Это я видел, хотелось бы не под cygwin.
Он НЕ требует cygwin. Там есть чисто Win32-версия.
Здравствуйте, Gaperton, Вы писали:
G>Вот тут, например, недавно в форуме были попытки расширить язык С++ новыми модными фичами, которые были штатными еще в старом добром Algol 68
CPL родил BCPL.
BCPL родил C.
C родил C++.
C++ родил C#.
В CPL (середина 1960-х) были функции высшего порядка (closures) и параметрический полиморфизм(generics).
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, eao197, Вы писали:
Кё>На С++/STL тоже не сразу стали писать. Огромное количество опенсорс-проектов до сих пор пишется на Си, в стиле "эмуляции С++" и начинаются новые, но С++ занимает всё больше места.
Кё>Главная идея такая, что дальнейшее развитие самых популярных языков (С++, C#, Java) в конце концов сделает из них Лисп
Я что-то не вижу что остальные языки превращаются в лисп, да и сам лисп многое перенял из других языков, например ОО.
Вообще у лиспа та же проблема что и у Forth, слишком легко менять язык до неузнаваемости(и не совместимости).
И вообще тут сильно восхищаются лиспом, но почему то не показывают его красоту на конкретных примерах, небольших программок, я пока не вижу ничего, что давало бы гигантские преимущества по сравнению с другими языками.
Здравствуйте, VladD2, Вы писали:
C>>В итоге Yahoo был вынужден переписать их движок на С++
VD>Звучит как полный бред. Java, Zope'ы/RubyOnRails/PHP обошли Лисп и именно по этому движок переписали на С++. Что же не на асме, то? Было бы еще логичнее.
Не у всех же аллергия на C++
Вообще не понятно что именно этот движок делает.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, eao197, Вы писали:
E>>Я могу заявить, что изучал в университете Prolog и уже тогда понял, что крайне тяжело разобраться в чужой прологовской программе.
Т>А уж разобраться в чужой C++ программе — вообще за гранью человеческих возможностей.
Предлагаю и в твоем, и в моем утверждения поставить жирное ИМХО.
Поскольку я видел не много Prolog-овских программ. И делаю вывод на основании небольшой выборки.
В тоже время я видел и писал много C++ программ. В нормальных C++ программах нет проблем с восприятием. И таких программ тоже, к счастью, не мало.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Кодёнок, Вы писали:
Кё>Ты всё время рассуждаешь в стиле "обстоятельства не в нашу пользу, мы вынуждены выбирать другое". Речь ведь не идёт о том, чтобы вдруг все сразу взяли и перешли на Лисп, когда для него нет ни разработчиков, ни программ в ВУЗах, почти ничего существенного. Я абсолютно согласен, что начинать новый проект на Лиспе для большинства команд сейчас вообще не вариант.
Ну да, потому что проекты нужно делать здесь и сейчас. Я программированием на хлеб зарабатываю, поэтому разные резкие пируеты, вроде смены языка и технологии, могут пагубно сказаться благосостоянии моей семьи.
Кё>На С++/STL тоже не сразу стали писать.
Сразу-сразу. Как только появились доступные реализации STL, так и стали. Даже прикручивали STL к тем компиляторам, в которых его изначально не было. В Watcom C++ 10, например.
Кё>Главная идея такая, что дальнейшее развитие самых популярных языков (С++, C#, Java) в конце концов сделает из них Лисп
Я сомневаюсь, что это произойдет.
И сомневаюсь, что это целесообразно.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
mihoshi,
M>Здравствуйте, VladD2, Вы писали:
VD>>что забавно шаблонов там нема, но плюсы отдыхают по полной прграмме
M> А что такое, например, параметризуемые модули, как не шаблоны?
На мой взгляд параметрический полиморфизм наиболее полный аналог шаблонов:
'a list <=> template <class T> list
('a * 'b * 'c) <=> template <class T1, class T2, class T3> tuple
('a->'a) <=> template <class TR, class T1> function <TR(*)(T1)>
('a->'b)->('c->'a)->'c->'b <=> template < ... > JAW_DROPPINGLY_BIG_BUNCH_OF_CODE
L.C.R. wrote: > Cyberax, > >> > C>Вообще, в CL мне не понравилось полное отсутствие нормального >> > синтаксиса >> > C>(LISP=Lots of Incredibly Silly Paranthesis) > > Это не проблема. Достаточно найти правильный редактор/вьюер, который > > (F1 a1 (F2 b1 (F3 c1 c2 c3)) a3 a4) > > > показывает в виде > > F1 > a1 > F2 > b1 > F3 > c1 > c2 > c3 > a3 > a4 > > > Ну или в более свёрнутом виде > > F a1 > F2 b1 > F3 c1 c2 c3 > a3 a4 > > > > И гладкое погружение в Лисп гарантировано! > > xxx: Сам давно писал для автокада — тогда и пришла мне в голову эта > хотелка, там редактор конечно подсвечивает и пары скобок и т.д. и т.п. > но всё равно трудно.
Vim примерно так и делает (если Enter ставить), но скобки оставляет.
Поищите/напишите plugin к нему — это не вопрос. Или, если Вы любитель
Emacs — поищите/напишите к нему mode.
{} Т>В CPL (середина 1960-х) были функции высшего порядка (closures) и параметрический полиморфизм(generics).
Что такое closures и когда (зачем) они нужны?
Здравствуйте, KHeLeKRoN, Вы писали:
KHL>Здравствуйте, Трурль, Вы писали:
KHL>{} Т>>В CPL (середина 1960-х) были функции высшего порядка (closures) и параметрический полиморфизм(generics). KHL>Что такое closures и когда (зачем) они нужны?
Глянь хотябы в википедию. На русский язык обычно переводят как "замыкание".
raskin,
>> Ну или в более свёрнутом виде >> >> F a1 >> F2 b1 >> F3 c1 c2 c3 >> a3 a4 >>
R>Vim примерно так и делает (если Enter ставить), но скобки оставляет. R>Поищите/напишите plugin к нему — это не вопрос. Или, если Вы любитель R>Emacs — поищите/напишите к нему mode.
Я как раз любитель Вима.
Моя рекомендация относится исключительно к новичкам (в Лиспе), которым в Лиспе нравится всё, кроме скобок. Но как следует из вышестоящих постов, по мере просветления скобки оказываются больше помогают, ежели мешают. А профи вообще оказывается без них вообще жить не могут.
Так что для новичка (я как раз он самый!) есть несколько путей:
1. Написать плагин для Вима, который делает скобки невидимыми.
2. Ускорить просветление
3. Пойти путём других функциональных языков — все дороги всё равно ведут в Рим.
FR wrote: > > Я что-то не вижу что остальные языки превращаются в лисп, да и сам лисп > многое перенял из других языков, например ОО.
Но при этом, как я помню, первым включил в официальный стандарт объекты.
VladD2 wrote:
> C>Но потом пришла Java и обогнала их по фичам (Cocoon — публикация в XML, > C>JSP/Servlets+Struts — в создании шаблонов, Tapestry — в "компонентном" > C>программировании), а всякие Zope'ы/RubyOnRails/PHP обошли их по > удобству > C>использования. > C>В итоге Yahoo был вынужден переписать их движок на С++ > Звучит как полный бред. Java, Zope'ы/RubyOnRails/PHP обошли Лисп *и > именно по этому* движок переписали на С++. Что же не на асме, то? Было > бы еще логичнее.
Нет, просто движок на Лиспе потерял свою уникальную черту — поддержку
самого быстрого цикла разработки. Вот менеджеры и решили, что вместо
того, чтобы искать по всему USA программистов на Лиспе — они лучше
перепишут все на С++ с использованием старых наработок.
Дарней wrote:
> C>А вы уверены, что Лисповцы не ходят на своих особенных "скобковых" > C>костылях? Мне вот почему-то именно так кажется. > Ну зачем к скобкам то цепляться? Это уже губановщина какая-то > получается. Главное — фичи языка, а не синтаксис.
Тогда все переходим на APL
> Тем более что скобка — это не begin, всего лишь один символ. Ее > написать нетрудно.
Читать трудно — синтаксис у Лиспа почти write-only получается. В
точности как в Перле.
Трурль wrote:
> E>Я могу заявить, что изучал в университете Prolog и уже тогда понял, > что крайне тяжело разобраться в чужой прологовской программе. > А уж разобраться в чужой C++ программе — вообще за гранью человеческих > возможностей.
Сложности возникают только тогда, когда по полной программе шаблонное
метапрограммирование используется. А остальной код обычно вполне
прилично читается, даже если был написан плохим программистом.
Здравствуйте, Cyberax, Вы писали:
C>Трурль wrote:
>> E>Я могу заявить, что изучал в университете Prolog и уже тогда понял, >> что крайне тяжело разобраться в чужой прологовской программе. >> А уж разобраться в чужой C++ программе — вообще за гранью человеческих >> возможностей.
C>Сложности возникают только тогда, когда по полной программе шаблонное C>метапрограммирование используется. А остальной код обычно вполне C>прилично читается, даже если был написан плохим программистом.
А причина, имхо, в том, что средства языка (плюсов) используются не по их назначению, в отличие от того, что макросы лиспа изначально подразумаевают такие назначения. Имхо плюсы, верней их шаблоны по сути есть ФЯ времени компиляции, хотя очень убогий с т. зр. ФЯ и жестокий для понимания, Александреску, думаю, неплохо это (возможности плюсов как ФЯ времени компиляции) продемонстрировал.
L.C.R. wrote:
> Моя рекомендация относится исключительно к новичкам (в Лиспе), которым > в Лиспе нравится всё, кроме скобок. Но как следует из вышестоящих > постов, по мере просветления скобки оказываются больше помогают, ежели > мешают. А профи вообще оказывается без них вообще жить не могут. > Так что для новичка (я как раз он самый!) есть несколько путей: > 1. Написать плагин для Вима, который делает скобки невидимыми. > 2. Ускорить просветление
Мне как человеку, испорченному тлетворным влиянием Java и C# еще нужно:
3. _Автокомплит_!!! Причем не тупо по словам, а контекстно-зависимо как
в IDEA. В Vim я такого не нашел.
4. Навигация по коду, code assist.
5. Рефакторинг.
Даже для С++ часть этого сделана в виде VisualAssist'а.
Здравствуйте, Трурль, Вы писали:
E>>Я могу заявить, что изучал в университете Prolog и уже тогда понял, что крайне тяжело разобраться в чужой прологовской программе.
Т>А уж разобраться в чужой C++ программе — вообще за гранью человеческих возможностей.
Все как раз наоборот. И в этом, возможно, и кроется причина непопулярности Lisp и иже с ними.
Почитай Tao of Unix Programming. Одно из правил, упоминаемых там — "Давать mechanizm, но не навязывать policy". Т.е. дать инструмент, накладывающий минимальные ограничения на способ использования. Но там же указан и недостаток этого принципа — если пользователю дать возможность выбора policy, то это значит, что ему придется выбирать policy.
А для этого нужно нетривальное умение не только думать, но и координировать свои решения с другими программмистами.
Что сейчас является мейнстримом? "Толстые" и "негибкие" языки, которые навязывают программитсу некоторый общий стиль программирования. Да, как только программисту нужно что-то, что не укладывается в hard-coded policy, начинаются проблемы. Но, как правило, общее policy способствует созданию более предсказуемого и поддерживаемого кода. Гораздо проще понять код, в котором, скажем, классы реализованы одним способом, чем тот, в котором это сделано десятком различных способов.
Cyberax wrote: > L.C.R. wrote: > >> Моя рекомендация относится исключительно к новичкам (в Лиспе), которым >> в Лиспе нравится всё, кроме скобок. Но как следует из вышестоящих >> постов, по мере просветления скобки оказываются больше помогают, ежели >> мешают. А профи вообще оказывается без них вообще жить не могут. >> Так что для новичка (я как раз он самый!) есть несколько путей: >> 1. Написать плагин для Вима, который делает скобки невидимыми. >> 2. Ускорить просветление > > Мне как человеку, испорченному тлетворным влиянием Java и C# еще нужно: > 3. _Автокомплит_!!! Причем не тупо по словам, а контекстно-зависимо как > в IDEA. В Vim я такого не нашел. > 4. Навигация по коду, code assist. > 5. Рефакторинг.
А вот тут, конечно, всех быстро затопчут поклонники Emacs. Так как у них
Lisp родственен IDE. Потому как всюду (для Java, Pascal, C#) чуть ли не
куски компиляторов этому учат. А vim — не приспособлен хорошо к одному
языку, скорее сносно ко всем.
Здравствуйте, eao197, Вы писали:
E>>>Я могу заявить, что изучал в университете Prolog и уже тогда понял, что крайне тяжело разобраться в чужой прологовской программе.
Т>>А уж разобраться в чужой C++ программе — вообще за гранью человеческих возможностей.
E>Предлагаю и в твоем, и в моем утверждения поставить жирное ИМХО.
Здравствуйте, raskin, Вы писали:
R>Cyberax wrote: >> Мне как человеку, испорченному тлетворным влиянием Java и C# еще нужно: >> 3. _Автокомплит_!!! Причем не тупо по словам, а контекстно-зависимо как >> в IDEA. В Vim я такого не нашел. >> 4. Навигация по коду, code assist. >> 5. Рефакторинг.
R>А вот тут, конечно, всех быстро затопчут поклонники Emacs. Так как у них R>Lisp родственен IDE. Потому как всюду (для Java, Pascal, C#) чуть ли не R>куски компиляторов этому учат. А vim — не приспособлен хорошо к одному R>языку, скорее сносно ко всем.
Ну для C++ вполне сносная поддержка, интеграция с gdb, ctags и всё такое. Так что здесь — нормально.
Для Lisp — — особенно рефакторинг. Поиск и замена с регэкспами помогает, но заменой увы — не является .
Возможно для Емакса с этими адвансед штучками дела обстоят получше... Знающие люди е?
Курилка wrote:
> C>Сложности возникают только тогда, когда по полной программе шаблонное > C>метапрограммирование используется. А остальной код обычно вполне > C>прилично читается, даже если был написан плохим программистом. > А причина, имхо, в том, что средства языка (плюсов) используются не по > их назначению, в отличие от того, что макросы лиспа изначально > подразумаевают такие назначения.
Однако макросы слишком уж сложны — в них легко можно допустить ошибку,
которую потом фиг найдешь (преобразуется код немного не так, как надо в
каком-нибудь редком крайнем случае — и ищи потом эту багу).
> Имхо плюсы, верней их шаблоны по сути есть ФЯ времени компиляции, хотя > очень убогий с т. зр. ФЯ и жестокий для понимания,
Да, он достаточно убогий. Немного улучшений к нему можно было бы
добавить — тогда он станет вполне нормальным.
ИМХО, _ОГРОМНЫЙ_ плюс С++ных шаблонов — это то что они работают над
_типами_, а не над кодом непосредственно.
raskin wrote:
>> Мне как человеку, испорченному тлетворным влиянием Java и C# еще нужно: >> 3. _Автокомплит_!!! Причем не тупо по словам, а контекстно-зависимо как >> в IDEA. В Vim я такого не нашел. >> 4. Навигация по коду, code assist. >> 5. Рефакторинг. > А вот тут, конечно, всех быстро затопчут поклонники Emacs.Так как у них > Lisp родственен IDE.
Он там внутри IDE — отстойный, очень уж диалект древний. Вдобавок,
слишком уж мне сам Emacs не нравится — а для новичков он вообще шедевр
user unfriendy интерфейса.
Cyberax wrote: > raskin wrote: > >> > Мне как человеку, испорченному тлетворным влиянием Java и C# еще нужно: >> > 3. _Автокомплит_!!! Причем не тупо по словам, а контекстно-зависимо как >> > в IDEA. В Vim я такого не нашел. >> > 4. Навигация по коду, code assist. >> > 5. Рефакторинг. >> А вот тут, конечно, всех быстро затопчут поклонники Emacs.Так как у них >> Lisp родственен IDE. > > Он там внутри IDE — отстойный, очень уж диалект древний. Вдобавок, > слишком уж мне сам Emacs не нравится — а для новичков он вообще шедевр > user unfriendy интерфейса.
Не отрицаю ни того, ни другого. Потому я и пользуюсь ViM. Но
неадекватность диалекта не препятствует появлению более/менее
универсального средства. Просто любой LISP стремятся встроить как в IDE
в Emacs — вне зависимости от диалекта, всё к родственным душам податься.
А user-unfriendly — да, я тоже всё не соберусь пересесть, быть может,
под него. Но в XEmacs нормальные меню — для новичков и ненадолго, а
когда их не хватит — всё будет уже привычно.
Здравствуйте, raskin, Вы писали:
R>Cyberax wrote: >> raskin wrote: >> >>> > Мне как человеку, испорченному тлетворным влиянием Java и C# еще нужно: >>> > 3. _Автокомплит_!!! Причем не тупо по словам, а контекстно-зависимо как >>> > в IDEA. В Vim я такого не нашел. >>> > 4. Навигация по коду, code assist. >>> > 5. Рефакторинг. >>> А вот тут, конечно, всех быстро затопчут поклонники Emacs.Так как у них >>> Lisp родственен IDE. >> >> Он там внутри IDE — отстойный, очень уж диалект древний. Вдобавок, >> слишком уж мне сам Emacs не нравится — а для новичков он вообще шедевр >> user unfriendy интерфейса. R>Не отрицаю ни того, ни другого. Потому я и пользуюсь ViM. Но R>неадекватность диалекта не препятствует появлению более/менее R>универсального средства. Просто любой LISP стремятся встроить как в IDE R>в Emacs — вне зависимости от диалекта, всё к родственным душам податься. R>А user-unfriendly — да, я тоже всё не соберусь пересесть, быть может, R>под него. Но в XEmacs нормальные меню — для новичков и ненадолго, а R>когда их не хватит — всё будет уже привычно.
Хотя на самом деле Emacs+SLIME — всё что надо содержит. Autocomplete,
navigation, etc. Даже presentations недавно экспериментальные добавили
(не то, что вы подумали). По поводу рефакторинга — какой именно рефакторинг
интересует? В Лиспе рефакторинг нужен несколько иной, чем в Java/C#/C++.
raskin wrote:
>> Он там внутри IDE — отстойный, очень уж диалект древний. Вдобавок, >> слишком уж мне сам Emacs не нравится — а для новичков он вообще шедевр >> user unfriendy интерфейса. > Не отрицаю ни того, ни другого. Потому я и пользуюсь ViM. Но > неадекватность диалекта не препятствует появлению более/менее > универсального средства. Просто любой LISP стремятся встроить как в IDE > в Emacs — вне зависимости от диалекта, всё к родственным душам податься.
Ну так как результат — нормальной IDE для Lisp'а нет.
> Но в XEmacs нормальные меню — для новичков и ненадолго, а > когда их не хватит — всё будет уже привычно.
Агащаз. Я помню, пытался с налету разобраться с XEmacs'ом еще в 90-е
года. Не получилось — даже менюшки ничем не помогли, пришлось 150
страничный мануал читать.
Cyberax wrote: > raskin wrote: > >> > Он там внутри IDE — отстойный, очень уж диалект древний. Вдобавок, >> > слишком уж мне сам Emacs не нравится — а для новичков он вообще шедевр >> > user unfriendy интерфейса. >> Не отрицаю ни того, ни другого. Потому я и пользуюсь ViM. Но >> неадекватность диалекта не препятствует появлению более/менее >> универсального средства. Просто любой LISP стремятся встроить как в IDE >> в Emacs — вне зависимости от диалекта, всё к родственным душам податься. > > Ну так как результат — нормальной IDE для Lisp'а нет.
OpenSource — если Emacs не считать. Из коммерческих, причём free for
personal use, непрерывно упоминают LispWorks. > >> Но в XEmacs нормальные меню — для новичков и ненадолго, а >> когда их не хватит — всё будет уже привычно. > > Агащаз. Я помню, пытался с налету разобраться с XEmacs'ом еще в 90-е > года. Не получилось — даже менюшки ничем не помогли, пришлось 150 > страничный мануал читать.
А что надо было? Сейчас я посмотрел — на поверхности меню 90% того, что
я использую наизусть в ViM.
Здравствуйте, FR, Вы писали:
FR>Не у всех же аллергия на C++
Причем тут алергия? Надо быть полным идиотом чтобы в следствии того что Лисп был обойден скажем Явой переписать код на С++. Ну, с какого боку тут взялся С++?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Нет, просто движок на Лиспе потерял свою уникальную черту — поддержку C>самого быстрого цикла разработки. Вот менеджеры и решили, что вместо C>того, чтобы искать по всему USA программистов на Лиспе — они лучше C>перепишут все на С++ с использованием старых наработок.
Ты действительно не видишь алогизма в своих размышлениях? Если для них быстрый цикл был важен, то почему они не сменили язык на тот который обладает более быстрым циклом? Это ведь полная бессмыслица исходя из этих сообрежения выбрать С++. Уж у него то цикл только длиннее.
Сдается мне, что причина была банальнее. К управлению проектом пришел фанат плюсов который нашел фатальный недостаток в продутке. Ну, вы знаете какой.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> C>Нет, просто движок на Лиспе потерял свою уникальную черту — поддержку > C>самого быстрого цикла разработки. Вот менеджеры и решили, что вместо > C>того, чтобы искать по всему USA программистов на Лиспе — они лучше > C>перепишут все на С++ с использованием старых наработок. > Ты действительно не видишь алогизма в своих размышлениях? Если для них > быстрый цикл был важен, то почему они не сменили язык на тот который > обладает более быстрым циклом? Это ведь полная бессмыслица исходя из > этих сообрежения выбрать С++. Уж у него то цикл только длиннее.
Почему же? Все логично — уровень гибкости существующих шаблонов им
оказался достаточен, и гнаться за новыми фичами стало ненужно.
Здравствуйте, Cyberax, Вы писали:
C>raskin wrote:
>>> Он там внутри IDE — отстойный, очень уж диалект древний. Вдобавок, >>> слишком уж мне сам Emacs не нравится — а для новичков он вообще шедевр >>> user unfriendy интерфейса. >> Не отрицаю ни того, ни другого. Потому я и пользуюсь ViM. Но >> неадекватность диалекта не препятствует появлению более/менее >> универсального средства. Просто любой LISP стремятся встроить как в IDE >> в Emacs — вне зависимости от диалекта, всё к родственным душам податься.
C>Ну так как результат — нормальной IDE для Lisp'а нет.
Но всё-таки emacs+SLIME вполне тянет на нормальную IDE, автокомплит вполне контекстозависимый (зависит от пакета) и очень удобный + стандартный автокомплит по словам. Подсказка к функциям. Простенький броузер класоов. Интеграция с документацией. Xref — можно быстро узнать какие функции вызвает данная функция и какие функции вызывают её, какие функции изменяют голбальную переменную и.т.д.. Навигация по коду. Раскрытие макросов на-лету. Интеграция с дебугером + "инспектор" объектов. И конечно очень удобное редактирование S-exprов. Плюс ещё много всяких удобных фич.
И кстати вот хороший пример lisp-программы. При всех своих наворотах и поддержке большинства реализаций Common Lisp SLIME — это всего 17,5К строк Common Lisp кода и 12K строк Emacs Lisp кода, всего около мегабайта сорцов.
Здравствуйте, Cyberax, Вы писали:
C>Почему же? Все логично — уровень гибкости существующих шаблонов им C>оказался достаточен, и гнаться за новыми фичами стало ненужно.
Логично, это "Я выбрал новый BMW, потому что он всех обогнал".
А "Я выбрал Фольксваген, потому что новый BMW всех обогнал" — нелогично. У вас так и получается, выбрали С++ потому что (???) Java, php всех обогнали
Здравствуйте, CrazyPit, Вы писали:
CP>Да интересная дискуссия, даже зарегился на RSDN, чтоб сюда запостить. CP>С Лиспом я знаком года 2-3, с тех пор как плотно начал юзать емакс, но именно CL, ну и схемой, заинтересовался только в конце прошлого года. Сначала прочитал, правда не до конца, первый том "Мир Лиспа", как то мне не очень понравилось и я забил, так что не советую вам её читать, очень скучно плюс только в том, что про Common Lisp это единственная книга на русском. Потом, когда появилась в инете Practical Common Lisp, и я его прочитал, да ещё открыл для себя SLIME, всё стало намного интереснее. Язык ИМХО самый навороченный из всех, и причина этому именно макросы в сочетании с простым представлением программ и данных. Чего стоят те же макросы loop & format.
Заинтересованный, я полез в инет и добыл: emacs-21.3, slime-1.2.1, Allegro CL 6.2, clisp-2.33.2
Пытался подружить парочку emacs + slim. Максимум, что мне удалось, это вызов консоли Аллегро по M-x slime. Но, думаю, эффект должен быть немного другой. Не поделишься ли опытом настройки?
Здравствуйте, Кодёнок, Вы писали:
Кё>Логично, это "Я выбрал новый BMW, потому что он всех обогнал".
Кё>А "Я выбрал Фольксваген, потому что новый BMW всех обогнал" — нелогично. У вас так и получается, выбрали С++ потому что (???) Java, php всех обогнали
Сдается мне, что когда в разговоре появляется С++, то для очень многих логично только то, что хвалит С++.
... << RSDN@Home 1.2.0 alpha rev. 549>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, CrazyPit, Вы писали:
CP>>Да интересная дискуссия, даже зарегился на RSDN, чтоб сюда запостить. CP>>С Лиспом я знаком года 2-3, с тех пор как плотно начал юзать емакс, но именно CL, ну и схемой, заинтересовался только в конце прошлого года. Сначала прочитал, правда не до конца, первый том "Мир Лиспа", как то мне не очень понравилось и я забил, так что не советую вам её читать, очень скучно плюс только в том, что про Common Lisp это единственная книга на русском. Потом, когда появилась в инете Practical Common Lisp, и я его прочитал, да ещё открыл для себя SLIME, всё стало намного интереснее. Язык ИМХО самый навороченный из всех, и причина этому именно макросы в сочетании с простым представлением программ и данных. Чего стоят те же макросы loop & format.
СТ>Заинтересованный, я полез в инет и добыл: emacs-21.3, slime-1.2.1, Allegro CL 6.2, clisp-2.33.2 СТ>Пытался подружить парочку emacs + slim. Максимум, что мне удалось, это вызов консоли Аллегро по M-x slime. Но, думаю, эффект должен быть немного другой. Не поделишься ли опытом настройки?
Ну вопервых при редактировании лиспа должен стоять slime-mode(M-x slime-mode) у меня это автоматически настроено. Потом лучше чтобы был отключен ILisp, но у тебя он скорее всего не установлен.
Вот часть моих емаксовских конфигов, относящихся к Common Lisp:
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, CrazyPit, Вы писали:
CP>>Да интересная дискуссия, даже зарегился на RSDN, чтоб сюда запостить. CP>>С Лиспом я знаком года 2-3, с тех пор как плотно начал юзать емакс, но именно CL, ну и схемой, заинтересовался только в конце прошлого года. Сначала прочитал, правда не до конца, первый том "Мир Лиспа", как то мне не очень понравилось и я забил, так что не советую вам её читать, очень скучно плюс только в том, что про Common Lisp это единственная книга на русском. Потом, когда появилась в инете Practical Common Lisp, и я его прочитал, да ещё открыл для себя SLIME, всё стало намного интереснее. Язык ИМХО самый навороченный из всех, и причина этому именно макросы в сочетании с простым представлением программ и данных. Чего стоят те же макросы loop & format.
СТ>Заинтересованный, я полез в инет и добыл: emacs-21.3, slime-1.2.1, Allegro CL 6.2, clisp-2.33.2 СТ>Пытался подружить парочку emacs + slim. Максимум, что мне удалось, это вызов консоли Аллегро по M-x slime. CT>Но, думаю, эффект должен быть немного другой. Не поделишься ли опытом настройки?
У тебя всё это дело, я так понял, на линуксе (или ином *nix клоне)?
Я к нему так и не привык, поэтому хочу настроить виндовую версию. Вижу в этом твоем конфиге закомменченные Allegro CL и clisp. Не работают? А тот, что текущий — это некий стандартный лисп (если есть такой)?
CP>ЗЫ: обязательно прочитай всё доку по SLIME. И ещё поиищи статьи на cliki.net по slime и редактированию лиспа в Emacs
Тридцать раз прочитал те четыре коротеньких абзаца про getting SLIME up and running. Не помогло. К тому же долго искал мифический файл .emacs. Оказалось, что home directory под виндой — это корень диска С.
cliki.net на момент написания был совсем как мертвый. Ошибка 502.
Здравствуйте, fionbio, Вы писали:
F>Здравствуйте, Сергей Туленцев, Вы писали:
F>http://www.gigamonkeys.com/book/ F>Тут всё что надо in order to get started про SLIME написано, рекомендую.
Эт я нашел в самую первую очередь. Но только там рассказывается про Lisp in a Box пакет, который под винду пока не работает. А переходить на линукс не хочецца.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Сергей Туленцев, Вы писали:
СТ>>Заинтересованный, я полез в инет и добыл: emacs-21.3, slime-1.2.1, Allegro CL 6.2, clisp-2.33.2
E>Эка, народ как пробрало! E>А давайте через два месяца у тех, кто с Lisp-ом благодоря этому топику познакомился, спросим: как оно, вообще?
Обязательно расскажу.
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, CrazyPit, Вы писали:
CP>>Да интересная дискуссия, даже зарегился на RSDN, чтоб сюда запостить. CP>>С Лиспом я знаком года 2-3, с тех пор как плотно начал юзать емакс, но именно CL, ну и схемой, заинтересовался только в конце прошлого года. Сначала прочитал, правда не до конца, первый том "Мир Лиспа", как то мне не очень понравилось и я забил, так что не советую вам её читать, очень скучно плюс только в том, что про Common Lisp это единственная книга на русском. Потом, когда появилась в инете Practical Common Lisp, и я его прочитал, да ещё открыл для себя SLIME, всё стало намного интереснее. Язык ИМХО самый навороченный из всех, и причина этому именно макросы в сочетании с простым представлением программ и данных. Чего стоят те же макросы loop & format.
СТ>Заинтересованный, я полез в инет и добыл: emacs-21.3, slime-1.2.1, Allegro CL 6.2, clisp-2.33.2 СТ>Пытался подружить парочку emacs + slim. Максимум, что мне удалось, это вызов консоли Аллегро по M-x slime. Но, думаю, эффект должен быть немного другой. Не поделишься ли опытом настройки?
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, fionbio, Вы писали:
F>>Здравствуйте, Сергей Туленцев, Вы писали:
F>>http://www.gigamonkeys.com/book/ F>>Тут всё что надо in order to get started про SLIME написано, рекомендую. СТ>Эт я нашел в самую первую очередь. Но только там рассказывается про Lisp in a Box пакет, который под винду пока не работает. А переходить на линукс не хочецца.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
E>>> Поэтому я и ответил так, как думаю -- в настоящий момент, для большинства команд, ведущих разработку на C++, смена языка реализации на Lisp просто не реальна. И постарался объяснить, почему я так думаю. G>>Для текущего проекта смена языка реализации нереальна, это и так всем понятно. Для новых проектов это вполне может иметь смысл, почему нет? Это первое, и второе — кто-то заставляет сразу писать на незнакомой платформе критичный проект? Боже упаси. Стратегия перехода на новую платформу предполагает существенно более сложный сценарий, и это, как я думал, не является предметом дискуссии.
E>Вот здесь и кроется основное несовпадение наших мнений. Вот ты говоришь: "Для новых проектов это вполне может иметь смысл, почему нет?" Но у меня есть вопрос: "А почему да?"
Ответ на этот вопрос один — потому, что средство Х (предположительно) позволяет тебе вести разработку с меньшими затратами. Выяснить, так ли это на самом деле для тебя, можно только пробуя. Плюс, у тебя есть мнение тех людей, кто уже попробовал. Есть другие варианты?
Если ты отказываешься пробовать, никто тебя особо убеждать не будет, никому это не надо. Однако, многим людям интересно исследовать способы, которые могут поднять продуктивность их труда, и я не понимаю, почему ты им отказываешь им в праве этим заниматься.
Ты ведь не пробовал Лисп, так? Так о чем ты вообще говоришь? Что ты можешь конструктивного сказать в этой дискуссии? Я не понимаю.
E>Мало того, что у меня вообще есть бОльшие сомнения на счет целесообразности смены C++ на что-то другое. Так еще и есть бОльшие сомнения, что переход на Lisp приведет к упрощению, удешевлению и повышению качества разработки. При этом я исхожу из двух статистических фактов: E>- язык Lisp менее распространен, чем C++/Java/C#/Python/Ruby. В качестве доказательства используем количество проектов на этих языках на SourceForge.net: Re[4]: Объем синтаксиса C#, Delphi 7, Java 2, ... (48 Kb)
;
Статистика проектов на sourceforge не имеет никакого отношения к "к упрощению, удешевлению и повышению качества разработки". Это косвенный показатель распространенности средства Х, не более того. Мне на распространенность плевать с высокой колокольни, разговор не о ней. Кстати, должен тебе напомнить, что распространенность приводят в языковых дискуссиях как последний "аргумент", когда по существу уже говорить нечего.
E>- для языка Lisp гораздо меньше готовых специалистов. А так же гораздо меньше доступных в продаже книг, по которым этих специалистов можно готовить.
Дело не в количестве книг, а в их качестве. По лиспу более чем достаточно замечательных книг, и он, в отличии от С++, давно и успешно используется как первый язык при обучении студентов в большом числе вузов. Что касательно количества специалистов — то это единственное, что ты можешь сказать по существу вопроса, и я тебе уже писал, что да, это некоторая проблема, но она не является фатальным showstopper-ом.
E>Ну и добавить сюда можно еще и небольшую реплику по поводу следующего абзаца:
G>>Но если говорить о смене платформы — то и это вполне возможно. Только начинать надо с микропрототипов для proof of the concept. А потом (если все в порядке) с маленьких некритичных проектов. Потом (если итоги их внедрения и экстплуатации положительны), внедрять новую платформу шире, с учетом накопленного опыта. Только осторожно, никакой спешки, риски надо контроллировать.
E>Имхо, когда компания выпускает несколько упешных продуктов и в живет за счет их тиражирования (в той или иной мере), то такой плавный переход на новую технологию может сильно затянуться. Я представляю для своих условий этот процесс и думаю, что только переход на создание новых продуктов сразу на Lisp стал бы возможен не раньше, чем через два-три года. А ведь остался бы багаж существующих проектов на C++/Java -- переписывать их на Lisp точно бы никто не стал. Даже при выходе следующей major версии какого-то продукта не факт, что оказалось бы дешевле делать ее с нуля на Lisp. А включение унаследованного C++/Java кода через какие-то переходники в Lisp код так же не кажется мне хорошим решением.
Абсолютно та же проблема существует и при переходе на С#, Java, you name it. Могу заметить, что с этой проблемой сталкивались еще в 70 годы, когда переходили с Ассемблеров на языки высокого уровня. Замечу, что сейчас мало кто пишет на ассемблере, так что история говорит нам о том, что проблема решаема. Так что ничего особенно страшного в этом нет.
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, CrazyPit, Вы писали:
CP>>Вот часть моих емаксовских конфигов, относящихся к Common Lisp:
CP>>;;;;;;;;;; Common Lisp ;;;;;;;;;; CP>>(add-to-list 'load-path "/home/cp/arc/lisp/slime-cvs/slime") CP>>(require 'slime)
CP>>;(set-variable inferior-lisp-program "/home/cp/arc/lisp/acl62_trial/alisp") CP>>;(set-variable inferior-lisp-program "clisp") CP>>(setf inferior-lisp-program "lisp")
СТ> У тебя всё это дело, я так понял, на линуксе (или ином *nix клоне)? СТ> Я к нему так и не привык, поэтому хочу настроить виндовую версию. Вижу в этом твоем конфиге закомменченные Allegro CL и clisp. Не работают? А тот, что текущий — это некий стандартный лисп (если есть такой)?
lisp — это по умолчанию — cmucl (но он только под юниксы). А закомментированны потому, что эта переменная устанавливает лисп по умолчанию, а так и clisp и ACL работают прекрасно. В принципе я думаю нет сильной разнице в насторойке емакса по видой и под юниксами. А slime-mode то работает или нет?
Здравствуйте, CrazyPit, Вы писали:
CP>Здравствуйте, Сергей Туленцев, Вы писали:
СТ>> У тебя всё это дело, я так понял, на линуксе (или ином *nix клоне)? СТ>> Я к нему так и не привык, поэтому хочу настроить виндовую версию. Вижу в этом твоем конфиге закомменченные Allegro CL и clisp. Не работают? А тот, что текущий — это некий стандартный лисп (если есть такой)?
CP>lisp — это по умолчанию — cmucl (но он только под юниксы). А закомментированны потому, что эта переменная устанавливает лисп по умолчанию, а так и clisp и ACL работают прекрасно. В принципе я думаю нет сильной разнице в насторойке емакса по видой и под юниксами. А slime-mode то работает или нет?
Ну, пишет "slime-mode enabled". На этом весь эффект и заканчивается. Щас закачаю Lisp in a box, посмотрю этого зверя.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Cyberax, Вы писали:
C>>Почему же? Все логично — уровень гибкости существующих шаблонов им C>>оказался достаточен, и гнаться за новыми фичами стало ненужно.
Кё>Логично, это "Я выбрал новый BMW, потому что он всех обогнал".
Кё>А "Я выбрал Фольксваген, потому что новый BMW всех обогнал" — нелогично. У вас так и получается, выбрали С++ потому что (???) Java, php всех обогнали
Не, все несколько сложнее. Java c PHP всех обогнали, поэтому Лисп ацтой, а писать надо на С++, местами транслируя в него Лисповый код посредством самописной Лисп-машины. Ночью летим, ночью!
Gaperton wrote:
> C>>Почему же? Все логично — уровень гибкости существующих шаблонов им > C>>оказался достаточен, и гнаться за новыми фичами стало ненужно. > Кё>Логично, это "Я выбрал новый BMW, потому что он всех обогнал". > Кё>А "Я выбрал Фольксваген, потому что новый BMW всех обогнал" — > нелогично. У вас так и получается, выбрали С++ потому что (???) Java, > php всех обогнали > Не, все несколько сложнее. Java c PHP всех обогнали, *поэтому *Лисп > ацтой, а писать надо на С++, местами транслируя в него Лисповый код > посредством самописной Лисп-машины. Ночью летим, ночью!
Не так: "Эта куча Лиспового кода уже давно не дает нам никаких
конкурентных преимуществ, а после .COM-коллапса мы уже не можем держать
штат из 30 лаурятов премии Тьюринга для его поддержки. Так что пора его
по кусочкам переписать, а у нас тут как раз крутые С++-программисты из
отдела поиска есть.".
Здравствуйте, Gaperton, Вы писали:
E>>Вот здесь и кроется основное несовпадение наших мнений. Вот ты говоришь: "Для новых проектов это вполне может иметь смысл, почему нет?" Но у меня есть вопрос: "А почему да?"
G>Ответ на этот вопрос один — потому, что средство Х (предположительно) позволяет тебе вести разработку с меньшими затратами.
Это в данной дискусии доказано не было.
G> Выяснить, так ли это на самом деле для тебя, можно только пробуя. Плюс, у тебя есть мнение тех людей, кто уже попробовал. Есть другие варианты?
Есть. Есть и противоположные мнения. Причем людей, которые пробовали Lisp.
G>Если ты отказываешься пробовать, никто тебя особо убеждать не будет, никому это не надо. Однако, многим людям интересно исследовать способы, которые могут поднять продуктивность их труда, и я не понимаю, почему ты им отказываешь им в праве этим заниматься.
G>Что ты можешь конструктивного сказать в этой дискуссии? Я не понимаю.
Конструктивного мало чего. Но, имхо, здесь вокруг Lisp-а создали такую бочку меда, что мне захотелось выступить в качестве ложки дегтя
А если серьезно, то после прочтения всех положительных отзывов я не могу никак понять одной вещи: если Lisp так хорош, то почему же он не мейнстрим? Ну не могу я понять. И аргументов, которые бы доказывали, что Lisp хорош не вижу. Только восторженные отзывы.
Вот, например, есть язык Ruby, который лично мне очень симпатичен. Это практически полностью Open-Source проект, который на протяжении 12 лет развивается на чистом энтузиазме. И сейчас он более популярен и распространен, чем Lisp с его 40-летней историей, наличием продвинутых коммерческих дистрибутивов и, как я понял, официального стандарта. Тоже самое можно сказать и про Perl, и про Python.
Но почему же Lisp в таком подполье находится? Это имеет какие-то объяснения?
G>Статистика проектов на sourceforge не имеет никакого отношения к "к упрощению, удешевлению и повышению качества разработки". Это косвенный показатель распространенности средства Х, не более того.
Имхо, распространенность является косвенным признаком пригодности инструмента к массовому использованию. Не знаю, насколько это будет адекватная аналогия, но т.к. гвозди приходится забивать чаще, чем изучать препараты в микроскоп, то молотки являются более доступным и распространенным товаром, чем микроскопы. Не смотря на то, что микроскопами так же можно забивать гвозди. Вот не является ли переход на Lisp в большинстве случаев попыткой забивать гвозди микроскопом?
G> Мне на распространенность плевать с высокой колокольни, разговор не о ней. Кстати, должен тебе напомнить, что распространенность приводят в языковых дискуссиях как последний "аргумент", когда по существу уже говорить нечего.
А у меня шкурный интерес. У нас в компании сейчас ведутся разработки на Java и C++. При открытии нового проекта стоит выбор, на чем его реализовывать. И здесь аргумент о том, что Java в большей степени мейнстрим является весьма серьезным, т.к. проекты начинаются не на один релиз, а с расчетом на длительный жизненый цикл. Поэтому приходится принимать в расчет то, как может изменится ситуация в ближайшие несколько лет. И если здесь такой распространенный и проверенный жизнью C++ зачастую проигрывает, то можно ли вообще заводить речь о такой экзотике, как Lisp?
G>Дело не в количестве книг, а в их качестве. По лиспу более чем достаточно замечательных книг, и он, в отличии от С++, давно и успешно используется как первый язык при обучении студентов в большом числе вузов.
Первым языком у многих из моего поколения был Бейсик, затем Паскаль, затем C. Но практически никто из них на этих языках никогда не программировал. Так что аргумент о том, что Lisp используется в качестве первого языка для меня серьезным не является.
G> Что касательно количества специалистов — то это единственное, что ты можешь сказать по существу вопроса, и я тебе уже писал, что да, это некоторая проблема, но она не является фатальным showstopper-ом.
А по мне, так очень фатальным. Наверное из-за того, что в провинции у таких вещей, как функциональные языки вообще нет будущего. Хорошо бы, чтобы хоть мейнстрим осваивался на должном уровне.
G>Абсолютно та же проблема существует и при переходе на С#, Java, you name it. Могу заметить, что с этой проблемой сталкивались еще в 70 годы, когда переходили с Ассемблеров на языки высокого уровня. Замечу, что сейчас мало кто пишет на ассемблере, так что история говорит нам о том, что проблема решаема. Так что ничего особенно страшного в этом нет.
Я готов принять этот аргумент, если будет действительно показано, что программирование на Lisp проще и надежнее, чем на C++ или, скажем, Java/C#, при массовом применении. Пока были высказаны личные мнения и впечатления. И приводились ссылки на такие же цитаты и статьи. Но в этом море положительных отзывов меня смущает вот что: имхо, личный профессиональный уровень высказавшихся гораздо выше среднего. Поэтому нет ничего удивительного, когда продвинутый специалист находит удобный для себя инструмен и с его помощью достигает производительности на порядок больше, чем окружающие. Только ведь фокус в том, что тоже самое происходит с любым языком/технологией. Для меня ближе C++, для VladD2 и AndrewVK -- C#/.Net. Для тебя -- Lisp. Но ведь проблема в том, насколько удобно этим инструментом будет пользоваться не таким фанатично увлеченным программированием коллегам.
И здесь аргументы о том, что нужно не экономить на специалистах, не нужно нанимать вместо одного продвинутого двух посредственностей и т.д. Есть реальные сроки и бюджеты. Есть реальная ситуация на кадровом рынке (в провинции я имею в виду), в которой возможности выбора вообще нет -- нужно брать то, что есть и доводить до ума самостоятельно.
Поэтому, когда сторонник Lisp-а противопоставляет Lisp созданию инструментов для C++ (которым среднего уровня специалисты в состоянии пользоваться), мне интересно, насколько же Lisp будет применим в реальных условиях.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, CrazyPit, Вы писали:
CP>>Здравствуйте, Сергей Туленцев, Вы писали:
СТ>>> У тебя всё это дело, я так понял, на линуксе (или ином *nix клоне)? СТ>>> Я к нему так и не привык, поэтому хочу настроить виндовую версию. Вижу в этом твоем конфиге закомменченные Allegro CL и clisp. Не работают? А тот, что текущий — это некий стандартный лисп (если есть такой)?
CP>>lisp — это по умолчанию — cmucl (но он только под юниксы). А закомментированны потому, что эта переменная устанавливает лисп по умолчанию, а так и clisp и ACL работают прекрасно. В принципе я думаю нет сильной разнице в насторойке емакса по видой и под юниксами. А slime-mode то работает или нет? СТ>Ну, пишет "slime-mode enabled". На этом весь эффект и заканчивается. Щас закачаю Lisp in a box, посмотрю этого зверя.
У тебя должно появиться меню SLIME, через него можно вызвать часть функций. Остальное читай в документации на сайте SLIME.
E>Конструктивного мало чего. Но, имхо, здесь вокруг Lisp-а создали такую бочку меда, что мне захотелось выступить в качестве ложки дегтя
E>А если серьезно, то после прочтения всех положительных отзывов я не могу никак понять одной вещи: если Lisp так хорош, то почему же он не мейнстрим? Ну не могу я понять. И аргументов, которые бы доказывали, что Lisp хорош не вижу. Только восторженные отзывы.
ИМХО главные проблемы лиспа, это не технические а социальные проблеммы, туманная история этого языка, которая повлекла за собой множество мифов. Вот интересная ссылка на эту тему — так и называется "Социальные проблемы лиспа"
CrazyPit,
CP>ИМХО главные проблемы лиспа, это не технические а социальные проблеммы, туманная история этого языка, которая повлекла за собой множество мифов. Вот интересная ссылка на эту тему — так и называется "Социальные проблемы лиспа"
Здравствуйте, eao197, Вы писали:
E>Ну да, потому что проекты нужно делать здесь и сейчас. Я программированием на хлеб зарабатываю, поэтому разные резкие пируеты, вроде смены языка и технологии, могут пагубно сказаться благосостоянии моей семьи.
К качествам собственно языков это не имеет никакого отношения.
Здравствуйте, CrazyPit, Вы писали:
E>>А если серьезно, то после прочтения всех положительных отзывов я не могу никак понять одной вещи: если Lisp так хорош, то почему же он не мейнстрим? Ну не могу я понять. И аргументов, которые бы доказывали, что Lisp хорош не вижу. Только восторженные отзывы.
CP>ИМХО главные проблемы лиспа, это не технические а социальные проблеммы, туманная история этого языка, которая повлекла за собой множество мифов. Вот интересная ссылка на эту тему — так и называется "Социальные проблемы лиспа"
Да, видимо, ты прав. Даже по приведенной ссылке находится такое количество bla-bla-bla, что я в большинстве случаев терял нить повествования. Но вот одна фраза:
But, people who like to experiment will tend more towards Lisp than say C.NET or Java. Lisp's tendency to attract "experimentors" is one of its social problems. Different languages tend to attract different kinds of personality flaws.
По-видимому, и объясняет все. Lisp -- это язык для хакеров. Если проект делает пара-тройка хорошо взаимодействующих между собой "изобретателей велосипедов", то Lisp, вероятно, дает им огромные преимущества. Но останется ли проект на плаву, если эта команда распадется или будет разбавлена людьми с другим восприятем мира -- это еще очень большой вопрос. И мне кажется, на основании собственного опыта по изобретению велосипедов, что в большинстве случаев проект будет обречен.
Отсюда у меня складывается мнение, что Lisp хорош для прорыва, для выпуска небольшими командами за короткое время принципиально новых продуктов. Об этом как раз и Пол Грэхэм говорит. Но ситуация меняется на диаметрально противоположную, когда этот проект переходит в стадию сопровождения. И когда этим сопровождением занимаютс уже совсем другие люди. Имхо, это и подтвердилось в истории с Yahoo Shop.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Эка, народ как пробрало! E>А давайте через два месяца у тех, кто с Lisp-ом благодоря этому топику познакомился, спросим: как оно, вообще?
А давайте спросим у тех, кто два месяца назад начал с С++ знакомиться
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, eao197, Вы писали:
E>>Эка, народ как пробрало! E>>А давайте через два месяца у тех, кто с Lisp-ом благодоря этому топику познакомился, спросим: как оно, вообще?
Д>А давайте спросим у тех, кто два месяца назад начал с С++ знакомиться
А что мешает? Спроси.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, eao197, Вы писали:
Д>>>А давайте спросим у тех, кто два месяца назад начал с С++ знакомиться
E>>А что мешает? Спроси.
Д>Мне ответ уже известен.
Дык по поводу C++ ответ мне так же известен. А вот про Lisp -- нет.
И есть большое подозрение, что в случае с Lisp-ом это будет тот же самый ответ.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>Что ты можешь конструктивного сказать в этой дискуссии? Я не понимаю.
E>Конструктивного мало чего. Но, имхо, здесь вокруг Lisp-а создали такую бочку меда, что мне захотелось выступить в качестве ложки дегтя
E>А если серьезно, то после прочтения всех положительных отзывов я не могу никак понять одной вещи: если Lisp так хорош, то почему же он не мейнстрим? Ну не могу я понять. И аргументов, которые бы доказывали, что Lisp хорош не вижу. Только восторженные отзывы.
"Если RISC лучше, то почему у всех стоит Intel"
"Если FreeBSD лучше, то почему Windows более распространён"
"Если интерфейс Mac OS всегда был лучше (впереди), то почему даже опен-сорсные библиотеки ему не следуют"
Много факторов повлияло на проигрыш лучших технологий, но факт проигрыша не доказывает ущербность идеи. Ты всё время смотришь в прошлое, на то, что уже есть, тогда как будущее определяет не оно. Разве факт того, что Тайсон, когда начинал заниматься боксом, проиграл первые пять боев, говорит о том, что он никуда не годен?
В каждой идее есть некий потенциал. С++ его почти исчерпал, не просто так популярность набирают языки вроде C# или D. Лисп — ещё конь не валялся.
E>Имхо, распространенность является косвенным признаком пригодности инструмента к массовому использованию.
Нет, ты опять судишь о будущем по прошлому. Если так, то Visual Studio 2005 и Longhorn, и все будущие версии программ от MS, абсолютно непригодны для массового использования, потому что по статистике ими почти никто не пользуется. Правильно?
Здравствуйте, Дарней, Вы писали:
Д>Кажется, кто-то здесь грозился выложить литературу... когда ждать?
Вся литература у Пола Грехема на сайте. Там есть ссылки на платные и онлайновые бесплатные книги.
Что угодно http://www.paulgraham.com/booklinks.html:
Common Lisp: An Interactive Approach (Free) — для изучения с нуля, + там еще несколько вводных
Common Lisp: The Language, 2 (Free) — полный справочник по языку, фактически стандарт с комментариями. Прим: в онлайн-версии глюки со ссылками, миррорить её не надо, надо скачать архив и его распаковать.
On Lisp (Free) — для лисперов это должно быть что-то вроде Александреску для С++, сам еще только начал читать.
Плюс еще какие-то книги по дизайну программ и др.
Вообще Грэхэм один из немногих людей, который _явно_ говорит о повышении уровня сознания, умений, фактически о саморазвитии как программиста. Вроде еще Брукс писал, у Алистера Кокберна я видел слова на эту тему, у Кента Бека. А значит, тем кто повышает свой уровень, а не "производит ПО", их книги можно читать читать подряд без разбору
Там же, в разделе "Lisp Resources" ссылки на CLiki и множество сообществ.
Д>Кажется, кто-то здесь грозился выложить литературу... когда ждать?
Я думаю, нет смысла все это оттуда сюда переписывать
Здравствуйте, Кодёнок, Вы писали:
E>>А если серьезно, то после прочтения всех положительных отзывов я не могу никак понять одной вещи: если Lisp так хорош, то почему же он не мейнстрим? Ну не могу я понять. И аргументов, которые бы доказывали, что Lisp хорош не вижу. Только восторженные отзывы.
Кё>Много факторов повлияло на проигрыш лучших технологий, но факт проигрыша не доказывает ущербность идеи. Ты всё время смотришь в прошлое, на то, что уже есть, тогда как будущее определяет не оно. Разве факт того, что Тайсон, когда начинал заниматься боксом, проиграл первые пять боев, говорит о том, что он никуда не годен?
Вот именно, что кроме технического превосходства есть и другие стороны. Которые при запуске технологии в промышленную эксплуатацию играют гораздо более важную роль. И в этой ветке внимание уделяется как раз технической продвинутости Lisp-а, а меня интересуют последствия выбора Lisp-а в качестве платформы.
Если же речь идет только о том, чтобы изучить Lisp для себя и использовать его самому для собственных задач, вместе с двумя-тремя единомышленниками, то давайте об этом так и скажем. Тогда я перестану возражать.
Кё>В каждой идее есть некий потенциал. С++ его почти исчерпал, не просто так популярность набирают языки вроде C# или D.
Имхо, с такими заявлениями прямая дорога в "Священные войны".
Кё> Лисп — ещё конь не валялся.
Угу, уже 40 лет, а он все не валяется и не валяется. Наверное, сферический. И в вакууме.
E>>Имхо, распространенность является косвенным признаком пригодности инструмента к массовому использованию.
Кё>Нет, ты опять судишь о будущем по прошлому. Если так, то Visual Studio 2005 и Longhorn, и все будущие версии программ от MS, абсолютно непригодны для массового использования, потому что по статистике ими почти никто не пользуется. Правильно?
Нет. Не передергивай. Ни Visual Studio 2005, но Longhorn-а еще нет (только alpha и beta). А Lisp уже 40 лет как есть.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> Д>>>А давайте спросим у тех, кто два месяца назад начал с С++ знакомиться > E>>А что мешает? Спроси. > Д>Мне ответ уже известен. > Дык по поводу C++ ответ мне так же известен. А вот про Lisp -- нет. > И есть большое подозрение, что в случае с Lisp-ом это будет тот же > самый ответ.
Да, в этом году на кафедре математики УдГУ первокурсникам решили
преподавать Лисп на практике по программированию — мой коллега по работе
как раз ее ведет (аспирантом порабатывает). Я помогал составлять
практические задания — ничего сложного, простенькие вещи типа чисел
Фибоначчи, сортировок, поиска.
Студенты плевались сильно и качество их программ было на очень низком
уровне (они их писал в паскалевском стиле). Несколько раз было прикольно
— ко мне по аське обращались с просьбами сделать практические задания,
которые я же и помогал сочинять.
Здравствуйте, Cyberax, Вы писали:
C>Студенты плевались сильно и качество их программ было на очень низком C>уровне (они их писал в паскалевском стиле). Несколько раз было прикольно C>- ко мне по аське обращались с просьбами сделать практические задания, C>которые я же и помогал сочинять.
Это нормальная реакция при использовании нового инструмента. Достоинствами человек пользоваться не умеет, а любые отличия от привычного видит как недостаток. Если не учить правильно обращаться с инструментом и не требовать этого от учеников, то толку от этого не будет.
Здравствуйте, eao197, Вы писали:
Кё>>Много факторов повлияло на проигрыш лучших технологий, но факт проигрыша не доказывает ущербность идеи. Ты всё время смотришь в прошлое, на то, что уже есть, тогда как будущее определяет не оно. Разве факт того, что Тайсон, когда начинал заниматься боксом, проиграл первые пять боев, говорит о том, что он никуда не годен?
E>Вот именно, что кроме технического превосходства есть и другие стороны. Которые при запуске технологии в промышленную эксплуатацию играют гораздо более важную роль. И в этой ветке внимание уделяется как раз технической продвинутости Lisp-а, а меня интересуют последствия выбора Lisp-а в качестве платформы.
Ты на своем же примере показываешь, что прежде чем идея станет технологией, она должна быть опробована. Иначе никто не примет решения о её использовании. Нужны конкретные аргументы.
E>Если же речь идет только о том, чтобы изучить Lisp для себя и использовать его самому для собственных задач, вместе с двумя-тремя единомышленниками, то давайте об этом так и скажем. Тогда я перестану возражать.
Мы пробуем Лисп, распространяем, все его пробуют, и если появляются конкретные проблемы и недостатки, тогда уже и ведем речь о его непригодности.
Ты просто сомневаешься, в чём? Не в качествах языка, а в целесообразности его применения в твоей фирме прямо сейчас. Разве тебя убеждают срочно применить Лисп?
E>Нет. Не передергивай. Ни Visual Studio 2005, но Longhorn-а еще нет (только alpha и beta). А Lisp уже 40 лет как есть.
Windows версий 1 и 2 была полным и никому не нужным отстоем. И Офис вначале имел очень скромные позиции. Несколько лет. Суть не меняется. Есть примеры, что лучшее не всегда самое распространенное.
Распространенность куда больше зависит от количества вложенных усилий, чем от качеств языка. А мы ведь обсуждаем возможности языка.
mihoshi wrote:
> C>Студенты плевались сильно и качество их программ было на очень низком > C>уровне (они их писал в паскалевском стиле). Несколько раз было > прикольно > C>- ко мне по аське обращались с просьбами сделать практические задания, > C>которые я же и помогал сочинять. > Это нормальная реакция при использовании нового инструмента.
Ну так спросили о мнении людей о С++, которые с ним знакомы всего пару
месяцев. Потом спросили мнение людей о Лиспе — я ответил.
> Достоинствами человек пользоваться не умеет, а любые отличия от > привычного видит как недостаток. Если не учить правильно обращаться с > инструментом и не требовать этого от учеников, то толку от этого не будет.
Да, но некоторым студентам понравилось такое извращение, как Refal
(крестики-нолики на Refal'е — это сильно). Лисп не понравился никому — а
это тоже показатель.
Здравствуйте, Кодёнок, Вы писали:
Кё>Ты на своем же примере показываешь, что прежде чем идея станет технологией, она должна быть опробована. Иначе никто не примет решения о её использовании. Нужны конкретные аргументы.
Это ты сейчас о чем?
E>>Если же речь идет только о том, чтобы изучить Lisp для себя и использовать его самому для собственных задач, вместе с двумя-тремя единомышленниками, то давайте об этом так и скажем. Тогда я перестану возражать.
Кё>Мы пробуем Лисп, распространяем, все его пробуют, и если появляются конкретные проблемы и недостатки, тогда уже и ведем речь о его непригодности.
Кё>Ты просто сомневаешься, в чём? Не в качествах языка, а в целесообразности его применения в твоей фирме прямо сейчас. Разве тебя убеждают срочно применить Лисп?
Если срочно, то Лисп вообще не вариант. Меня интересует другое -- если я сейчас заложусть на изучение Lisp, начну организационные мероприятия по развитию малозначащих и экспериментальных проектов на Lisp-е, буду изыскивать время для обучения коллег (причем, в первую очередь, их время), и т.д. и т.п., то каковы шансы, что эти затраты в конце-концов окупятся? Или я окажусь в роли разработчика офисных приложений для FreeBSD -- вроде бы и уровень хороший, и конкурентов на этой платформе нет, да только сама платформа ни кем в этой роли не используется.
Собственно, вопрос такой, на которого ответа все равно никто не даст. Это мои проблемы и решение должно быть моим.
Но может кто-нибудь внятно объяснить, почему, если Lisp такой супер-пупер, он всех остальных не задавил (за сорок-то лет существования)?
Пока я получил один заслуживающий внимания ответ: Re[9]: Metaprogramming et al
. Из которого понятно, что Lisp -- это язык для чокнутых программистов (в хорошем смысле этого слова). И тогда понятно, что Lisp просто не сможет применяться в командах, в которых нормальные, а не чокнутые, программисты работают. А ведь каких команд большинство. В том числе и у нас в компании.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Собственно, вопрос такой, на которого ответа все равно никто не даст. Это мои проблемы и решение должно быть моим.
Задал вопрос и сам же на него ответил Да, гарантии я тебе не дам.
E>Но может кто-нибудь внятно объяснить, почему, если Lisp такой супер-пупер, он всех остальных не задавил (за сорок-то лет существования)? E>Пока я получил один заслуживающий внимания ответ: Re[9]: Metaprogramming et al
. Из которого понятно, что Lisp -- это язык для чокнутых программистов (в хорошем смысле этого слова). И тогда понятно, что Lisp просто не сможет применяться в командах, в которых нормальные, а не чокнутые, программисты работают. А ведь каких команд большинство. В том числе и у нас в компании.
Может быть принципиальная интерпретируемость и соответственно, низкое быстродействие на современных "mov ax,bx"-машинах. Сейчас набирают популярность интерпретируемые языки, и Лисп "всплыл" опять.
Здравствуйте, Кодёнок, Вы писали:
E>>Но может кто-нибудь внятно объяснить, почему, если Lisp такой супер-пупер, он всех остальных не задавил (за сорок-то лет существования)?
Кё>Может быть принципиальная интерпретируемость и соответственно, низкое быстродействие на современных "mov ax,bx"-машинах.
А почему же это Perl, Python, Ruby, Tcl/Tk никогда не мешало?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
Кё>>Может быть принципиальная интерпретируемость и соответственно, низкое быстродействие на современных "mov ax,bx"-машинах.
E>А почему же это Perl, Python, Ruby, Tcl/Tk никогда не мешало?
А 20-40 лет назад этих языков не было. Лиспу сейчас это тоже не мешает.
Кодёнок wrote:
> Кё>>Может быть принципиальная интерпретируемость и соответственно, > низкое быстродействие на современных "mov ax,bx"-машинах. > E>А почему же это Perl, Python, Ruby, Tcl/Tk никогда не мешало? > А 20-40 лет назад этих языков не было. Лиспу сейчас это тоже не мешает.
Эти языки появились всего лет 10 назад — и на них уже пишет в десятки
раз больше программистов, чем на Лиспе. Почему эти языки стали
распространенными (причем Питон и Руби никто не пиарил до недавнего
времени), а Лисп так и не стал?
Здравствуйте, Cyberax, Вы писали:
C>Да, в этом году на кафедре математики УдГУ первокурсникам решили C>преподавать Лисп на практике по программированию — мой коллега по работе C>как раз ее ведет (аспирантом порабатывает). Я помогал составлять C>практические задания — ничего сложного, простенькие вещи типа чисел C>Фибоначчи, сортировок, поиска.
C>Студенты плевались сильно и качество их программ было на очень низком C>уровне (они их писал в паскалевском стиле). Несколько раз было прикольно C>- ко мне по аське обращались с просьбами сделать практические задания, C>которые я же и помогал сочинять.
Есть подозрение, что:
1. Преподаватель не захотел/не смог/не успел показать студентам, как правильно использовать Lisp.
2. Студенты, привыкшие думать "на Паскале" (это ключевой момент!), не захотели/не успели понять, как правильно использовать незнакомый инструмент.
В результате комбинации этих факторов Lisp воспринимался как незнакомый и неудобный аналог Паскаля — отсюда и низкое качество, и плевательство.
P.S. Кстати, интересный вывод пришел в голову: немаловажную роль в таком печальном развитии ситуации сыграла гибкость Lisp'а. Т.к. на нем все же можно писать Pascal-подобные программы. Вот если бы ситуация была обратной — студентам, знакомым с Lisp'ом или каким-нибудь ФЯ, пришлось бы писать на Паскале/C++/C#/Java — они бы волей-неволей приспособились к новому способу программирования.
P.P.S. А если бы студенты, привыкшие к ФЯ, пересели на C++ — они могли бы заюзать библиотеки, позволяющие писать в функциональном стиле! Представляете результат?
Здравствуйте, Cyberax, Вы писали:
C>Эти языки появились всего лет 10 назад — и на них уже пишет в десятки C>раз больше программистов, чем на Лиспе. Почему эти языки стали C>распространенными (причем Питон и Руби никто не пиарил до недавнего C>времени), а Лисп так и не стал?
Потому что они императивные. Понятные всем. А чтобы освоить новое мышление, нужно немного усилий.
Кодёнок wrote:
> C>Эти языки появились всего лет 10 назад — и на них уже пишет в десятки > C>раз больше программистов, чем на Лиспе. Почему эти языки стали > C>распространенными (причем Питон и Руби никто не пиарил до недавнего > C>времени), а Лисп так и не стал? > Потому что они императивные. Понятные всем. А чтобы освоить новое > мышление, нужно немного усилий.
Ну так может оно того и не стоит? Кстати, на том же Питоне вполне можно
писать и функционально — никто не мешает.
pvgoran wrote:
> C>Студенты плевались сильно и качество их программ было на очень низком > C>уровне (они их писал в паскалевском стиле). Несколько раз было > прикольно > C>- ко мне по аське обращались с просьбами сделать практические задания, > C>которые я же и помогал сочинять. > Есть подозрение, что: > 1. Преподаватель не захотел/не смог/не успел показать студентам, как > правильно использовать Lisp.
Преподаватель учил Лисп вместо со студентами, стараясь все сделать как
можно более красиво Лисп вообще давался в этом курсе для изучения
функционального подхода. В следующем году будет либо Scheme, либо Clean.
> 2. Студенты, привыкшие думать "на Паскале" (это ключевой момент!), не > захотели/не успели понять, как правильно использовать незнакомый > инструмент.
Именно.
> В результате комбинации этих факторов Lisp воспринимался как > незнакомый и неудобный аналог Паскаля — отсюда и низкое качество, и > плевательство.
А это уже скорее недостаток Лиспа — он не побуждает думать по-другому,
если человек уже не знает что такое функциональное программирование и с
чем его едят.
> P.P.S. А если бы студенты, привыкшие к ФЯ, пересели на C++ — они могли > бы заюзать библиотеки, позволяющие писать в функциональном стиле! > Представляете результат?
Я его не представляю, я его видел. После натыкания по разу на
стандартные ляпсусы в С++ писали вполне нормальный код.
Здравствуйте, Cyberax, Вы писали:
C>Кодёнок wrote:
>> C>Эти языки появились всего лет 10 назад — и на них уже пишет в десятки >> C>раз больше программистов, чем на Лиспе. Почему эти языки стали >> C>распространенными (причем Питон и Руби никто не пиарил до недавнего >> C>времени), а Лисп так и не стал? >> Потому что они императивные. Понятные всем. А чтобы освоить новое >> мышление, нужно немного усилий.
C>Ну так может оно того и не стоит? Кстати, на том же Питоне вполне можно C>писать и функционально — никто не мешает.
А макросы уровня лиспа писать тоже никто не мешает? Писать функционально мало, имхо, на плюсах тоже получается местами вполне функционально...
Курилка wrote:
> C>Ну так может оно того и не стоит? Кстати, на том же Питоне вполне можно > C>писать и функционально — никто не мешает. > А макросы уровня лиспа писать тоже никто не мешает?
Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью
скрипта обходили AST кода и добавляли трассировку вызовов определенной
функции. Выглядело очень красиво, вспомню как называлось — напишу сюда.
Здравствуйте, Cyberax, Вы писали:
C>Студенты плевались сильно и качество их программ было на очень низком C>уровне (они их писал в паскалевском стиле). Несколько раз было прикольно C>- ко мне по аське обращались с просьбами сделать практические задания, C>которые я же и помогал сочинять.
Это говорит только о плохом качестве преподавания.
Дарней wrote:
> C>Студенты плевались сильно и качество их программ было на очень низком > C>уровне (они их писал в паскалевском стиле). Несколько раз было > прикольно > C>- ко мне по аське обращались с просьбами сделать практические задания, > C>которые я же и помогал сочинять. > Это говорит только о плохом качестве преподавания.
Однако у этого же преподавателя студенты вполне нормально разобрались с
Рефалом (преподаватель его тоже вместе со студентами учил).
Кстати о квалификации — этот же преподаватель почти в одиночку пишет
софт для http://taxcalc.com (бывший http://taxchecker.co.uk — у них там
сейчас реорганизация, поэтому веб-версии недоступны) — систему для
подсчета налогов в Британии, ядро которой работает без изменений в
веб-версии и в stand-alone. В этой системе правила рассчета налогов
декларативно задаются в MathML, из которого потом генерируется
JavaScript-код для веб-версии и С++ для stand-alone, для каждого поля
генерируется скрипт, который вызывает пересчет зависимых полей,
валидацию и т.п.
Здравствуйте, Cyberax, Вы писали:
C>Курилка wrote:
>> C>Ну так может оно того и не стоит? Кстати, на том же Питоне вполне можно >> C>писать и функционально — никто не мешает. >> А макросы уровня лиспа писать тоже никто не мешает?
C>Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью C>скрипта обходили AST кода и добавляли трассировку вызовов определенной C>функции. Выглядело очень красиво, вспомню как называлось — напишу сюда.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, eao197, Вы писали:
E>>Собственно, вопрос такой, на которого ответа все равно никто не даст. Это мои проблемы и решение должно быть моим.
Кё>Задал вопрос и сам же на него ответил Да, гарантии я тебе не дам.
E>>Но может кто-нибудь внятно объяснить, почему, если Lisp такой супер-пупер, он всех остальных не задавил (за сорок-то лет существования)? E>>Пока я получил один заслуживающий внимания ответ: Re[9]: Metaprogramming et al
. Из которого понятно, что Lisp -- это язык для чокнутых программистов (в хорошем смысле этого слова). И тогда понятно, что Lisp просто не сможет применяться в командах, в которых нормальные, а не чокнутые, программисты работают. А ведь каких команд большинство. В том числе и у нас в компании.
Кё>Может быть принципиальная интерпретируемость и соответственно, низкое быстродействие на современных "mov ax,bx"-машинах. Сейчас набирают популярность интерпретируемые языки, и Лисп "всплыл" опять.
ЭЭЭ вообще-то большинство реализаций Common Lisp, компилируемые...
Так что это не аргрумент, скорее некоторые исторические причины + то что Common Lisp сильно навороченный и часто сложен в изучении не дают ему широко распостранится. А если учитывать все диалекты и встроенные языки лисп достаточно широко распространёт. Я видел много программ, которые используют те или иные диалекты лиспа, как внутренний язык.
Курилка wrote:
> C>Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью > C>скрипта обходили AST кода и добавляли трассировку вызовов определенной > C>функции. Выглядело очень красиво, вспомню как называлось — напишу сюда. > Ждём, сравним с defmacro
Здравствуйте, Кодёнок, Вы писали:
E>>Но может кто-нибудь внятно объяснить, почему, если Lisp такой супер-пупер, он всех остальных не задавил (за сорок-то лет существования)? E>>Пока я получил один заслуживающий внимания ответ: Re[9]: Metaprogramming et al
. Из которого понятно, что Lisp -- это язык для чокнутых программистов (в хорошем смысле этого слова). И тогда понятно, что Lisp просто не сможет применяться в командах, в которых нормальные, а не чокнутые, программисты работают. А ведь каких команд большинство. В том числе и у нас в компании.
Кё>Может быть принципиальная интерпретируемость и соответственно, низкое быстродействие на современных "mov ax,bx"-машинах. Сейчас набирают популярность интерпретируемые языки, и Лисп "всплыл" опять.
Принципиальная интерпретируемость Лиспа — это в неправда. Есть много компиляторов Lisp (часть кода компилируется, часть выполняется на этапе компиляции). Элементарный пример — компилятор Scheme Gambit — была статья, в которой объяснялось, как написать простенький компилятор Scheme за несколько часов .
О быстродействии. Быстродействие реализации CLisp на целых числах сравнимо с Java, а CMULISP на равных с Java и при использовании плавающей запятой. Т. е. современные Лиспы работают примерно вдвое медленнее С++. Разумеется, писать быстрые программы на Lisp надо уметь — для начала не забывать давать аннотации типов.
P>2. Студенты, привыкшие думать "на Паскале" (это ключевой момент!), не захотели/не успели понять, как правильно использовать незнакомый инструмент.
Вот именно, недавно провёл эксперимент, попробовал обучить человека, вообще ничего не знающего о программирование сначала питону потом scheme(ну схема то конечно намного проще CL, хотя в том что я показывал особой разницы нет), во втором случае результаты оказались намного лучше, так что дело тут именно в закостенелости мозгов.
Здравствуйте, Cyberax, Вы писали:
C>Курилка wrote:
>> C>Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью >> C>скрипта обходили AST кода и добавляли трассировку вызовов определенной >> C>функции. Выглядело очень красиво, вспомню как называлось — напишу сюда. >> Ждём, сравним с defmacro
C>Это было сделано на основе (кажется), C>http://www.logilab.org/projects/pyreverse или C>http://www.python.org/doc/current/lib/module-parser.html, но сейчас тот C>сэмпл не могу найти.
Без сэмла слабо понятно, что имеется в виду, чем это принципиально от того же рефлекшна в C# отличается? Через него тоже по идее можно преобразования над кодом выполнять, но по сравнению с лисповскими макросами...
Здравствуйте, Cyberax, Вы писали:
C>Однако у этого же преподавателя студенты вполне нормально разобрались с C>Рефалом (преподаватель его тоже вместе со студентами учил).
я не знаю, что общего у него с Лиспом и чем они отличаются, поэтому не знаю, какие из этого можно сделать выводы
C>Кстати о квалификации — этот же преподаватель почти в одиночку пишет C>софт для http://taxcalc.com (бывший http://taxchecker.co.uk — у них там C>сейчас реорганизация, поэтому веб-версии недоступны) — систему для C>подсчета налогов в Британии, ядро которой работает без изменений в C>веб-версии и в stand-alone. В этой системе правила рассчета налогов C>декларативно задаются в MathML, из которого потом генерируется C>JavaScript-код для веб-версии и С++ для stand-alone, для каждого поля C>генерируется скрипт, который вызывает пересчет зависимых полей, C>валидацию и т.п.
Дарней wrote:
> C>Однако у этого же преподавателя студенты вполне нормально разобрались с > C>Рефалом (преподаватель его тоже вместе со студентами учил). > я не знаю, что общего у него с Лиспом и чем они отличаются, поэтому не > знаю, какие из этого можно сделать выводы
В отличие от ЛИСПа, основу РЕФАЛа составляет сопоставление с образцом.
Благодаря этому типовая программа на РЕФАЛе вдвое-втрое короче по
объему, чем аналогичная программа на языке ЛИСП, и гораздо более
читаема. От ПРОЛОГа РЕФАЛ отличает концептуальная простота. Его
сопоставление с образцом работает в прямом направлении, а не в обратном
(начиная от цели), как в ПРОЛОГе. Это более естественный подход к
написанию алгоритмов, что делает их более легкими для тестирования и
отладки.
Далее, имеется существенное различие между структурами данных в РЕФАЛе и
в большинстве других языков высокого уровня. Основные структуры данных в
ЛИСПе и ПРОЛОГе — это */списки/*, которые могут читаться только в одном
направлении. РЕФАЛ использует более общие структуры. Вы можете строить
и читать их слева-направо и справа-налево и, конечно же, прыгать внутрь
и наружу по скобочным структурам. Это очень удобно для программиста.
РЕФАЛ дает свободу и удобство в создании структур данных наряду с
использованием лишь математически простых механизмов управления —
/*сопоставления с образцом и подстановки. */Это именно то, что нужно для
символьной обработки и для искусственного интеллекта.
Здравствуйте, Cyberax, Вы писали:
C>Кстати, можно. Для Питона мне показывали что-то подобное R# — с помощью C>скрипта обходили AST кода и добавляли трассировку вызовов определенной C>функции. Выглядело очень красиво, вспомню как называлось — напишу сюда.
Есть стандартный модуль compiler который умеет строить AST по исходному коду и удобно его обрабатывать.
Ссылка интересная, спасибо. Но вот один настораживающий момент:
В то же время, для ПЕРЕМЕННОЙ указание типа данных, вообще говоря, необязательно. Это можно рассматривать и как преимущество, и как недостаток. Например, для функции max, которую в Лиспе можно для двух аргументов определить как
(defun my-max (x y) (if (> x y) x y)))
и это можно расценивать как благо. Ведь, к примеру, в C++ так определить максимум нельзя. Нужно использовать перегрузку (overloading) либо пользоваться макросами. В случае определения в виде макроса, неправильный результат даст вычисление
MAX(i++,j++), поскольку i и j будут увеличены дважды. При использовании overloading придется написать множество версий сравнения.
Очевидно, что о простейшей C++ конструкции
template <typename T>
inline T max(T a, T b) {return a < b ? b : a;}
автор никогда не слышал и оперирует он знаниями совсем древнего C++. А это есть минус статье, т.к. взялся сравнивать — разберись в вопросе.
Здравствуйте, CrystaX, Вы писали:
CX>Здравствуйте, CrazyPit, Вы писали:
CP>>Вот ещё интересная ссылка о мифах про лисп http://lisp.narod.ru/msg.html.
CX>Ссылка интересная, спасибо. Но вот один настораживающий момент:
[...] CX>автор никогда не слышал и оперирует он знаниями совсем древнего C++. А это есть минус статье, т.к. взялся сравнивать — разберись в вопросе.
Там и еще было:
Помимо списков и символов, в Лисп есть отдельные типы данных для строк, массивов, хеш-таблиц, записей (структур), потоков ввода-вывода. Кроме того, стандарт Common Lisp включает в себя систему объектно-ориентированного программирования CLOS, далеко превосходящую по выразительным возможностям систему программирования C++. Для доказательства этого превосходства достаточно отметить, что есть возможность выбирать вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно определить четыре метода
(defmethod draw ((x sentence) (y screen)) (message-box x y)) ; для отображения сообщения на экране
(defmethod draw ((x sentence) (y paper)) (write x y)) ; нужно просто написать слова на бумаге
(defmethod draw ((x picture) (y screen)) (show-picture-in-a-box x y)) ; показываем картинку на экране
(defmethod draw ((x picture) (y screen)) (paint-picture-on-a-paper x y)) ; рисуем картинку на бумаге.
При вызове
>(draw my-data my-device)
выбор одного из четырех определенных методов будет динамически осуществляться в момент вызова. Это невозможно в C++, где пришлось бы делать draw либо методом общего предка объектов screen и paper, либо методом общего предка sentence и picture, а выбор кода по типу второго аргумента осуществлять с помощью анализа этого типа в конструкции if.
И еще пару перлов:
Например, легко ошибиться, написав (i==j || k==l) вместо ((i==j) || (k==l)), а в Лисп такая ошибка просто невозможна, потому что нужно будет написать (or (= i j) (= k l))
Т.е. запись (or (= i j) (= k l)) сразу понятнее, чем (i==j || k==l). Кстати, насколько я знаю, обе приведенные записи в C++ эквивалентны (т.к. приоритет сравнения выше, чем приоритет логического ИЛИ).
А так же:
Например, оператор if в C не возвращает значения, и, чтобы это обойти, была придумана операция ( ? : ). Было бы удобно, если бы оператор switch в C мог также возвращать значение, которое можно присвоить переменной после завершения его выполнения. В Паскале и Бейсике даже присваивание является оператором и не возвращает значения, поэтому нельзя написать a=b=с. В Лиспе в этом плане все гораздо удобнее. if возвращает значение. Одну и ту же конструкцию if можно использовать для ветвления алгоритма и для выбора значения по условию. Также возвращает значение и cond (аналог switch), и setf (аналог присваивания). Да и вообще, в Лиспе значение возвращается всегда, где это имеет смысл.
Как будто в C++ подругому .
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
P>>А что это значит??
G>В пылу дискуссии участники незаметно перешли с русского на Липс, так как он дает больше выразительных возможностей чем любой другой язык.
Здравствуйте, Cyberax, Вы писали:
>> Есть подозрение, что: >> 1. Преподаватель не захотел/не смог/не успел показать студентам, как >> правильно использовать Lisp.
C>Преподаватель учил Лисп вместо со студентами, стараясь все сделать как C>можно более красиво
Н-да... Звучит это довольно подозрительно. Если воспринимать буквально, то получается, что преподавателю надо было за время, отведенное на преподавание дисциплины (N часов в учебном плане), самому изучить язык. Однако IMHO времени на самостоятельное изучение языка (и тем более на подготовку к преподаванию) уходит гораздо больше, чем на восприятие нормального курса по этому языку, и N часов, выделенных на второе, запросто может не хватить на первое.
C>Лисп вообще давался в этом курсе для изучения C>функционального подхода. В следующем году будет либо Scheme, либо Clean.
Если интересно, могу рассказать/посоветовать одну книжку по Scheme (и не только).
>> В результате комбинации этих факторов Lisp воспринимался как >> незнакомый и неудобный аналог Паскаля — отсюда и низкое качество, и >> плевательство.
C>А это уже скорее недостаток Лиспа — он не побуждает думать по-другому, C>если человек уже не знает что такое функциональное программирование и с C>чем его едят.
А что, он должен заставлять? Multi-paradigm языки не имеют право на существование? Вон C++ тоже не заставляет использовать ООП программиста, который знаком с C.
>> P.P.S. А если бы студенты, привыкшие к ФЯ, пересели на C++ — они могли >> бы заюзать библиотеки, позволяющие писать в функциональном стиле! >> Представляете результат?
C>Я его не представляю, я его видел. После натыкания по разу на C>стандартные ляпсусы в С++ писали вполне нормальный код.
Уточняю: речь идет о вещах вроде FC++. Их действительно можно использовать без особого напряга, не имея приличного опыта с C++?
E>Помимо списков и символов, в Лисп есть отдельные типы данных для строк, массивов, хеш-таблиц, записей (структур), потоков ввода-вывода. Кроме того, стандарт Common Lisp включает в себя систему объектно-ориентированного программирования CLOS, далеко превосходящую по выразительным возможностям систему программирования C++. Для доказательства этого превосходства достаточно отметить, что есть возможность выбирать вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно определить четыре метода
E>(defmethod draw ((x sentence) (y screen)) (message-box x y)) ; для отображения сообщения на экране
E>(defmethod draw ((x sentence) (y paper)) (write x y)) ; нужно просто написать слова на бумаге
E>(defmethod draw ((x picture) (y screen)) (show-picture-in-a-box x y)) ; показываем картинку на экране
E>(defmethod draw ((x picture) (y screen)) (paint-picture-on-a-paper x y)) ; рисуем картинку на бумаге.
E>При вызове
>>(draw my-data my-device)
E>выбор одного из четырех определенных методов будет динамически осуществляться в момент вызова. Это невозможно в C++, где пришлось бы делать draw либо методом общего предка объектов screen и paper, либо методом общего предка sentence и picture, а выбор кода по типу второго аргумента осуществлять с помощью анализа этого типа в конструкции if.
Просто по ходу дела автор путается и ляпы допускает, хотя в его словах есть доля истины, просто здесь смысл не в параметрах, даж незнаю как это выразить, короче говоря — в CLOS изначально есть мультиметоды, т.е. перегрузка идёт не по 1 (неявному) параметру this, а по всем параметрам, т.е. получаем эдакую виртуальную матрицу вызовов. В плюсах для такого приходится извращаться, не зря много про двойную диспетчеризацию написано (не у Александреску ли была нехилая глава этому посвещена или у Мейерса?), ну а для множественной диспетчеризации надо ещё хитрей изгаляться...
Хотя, признаюсь, сам ещё особо с этими мультиметодами не разбирался, так что сильно не пинайте — не гуру лиспа далеко
Здравствуйте, Курилка, Вы писали:
К>Просто по ходу дела автор путается и ляпы допускает, хотя в его словах есть доля истины, просто здесь смысл не в параметрах, даж незнаю как это выразить, короче говоря — в CLOS изначально есть мультиметоды, т.е. перегрузка идёт не по 1 (неявному) параметру this, а по всем параметрам, т.е. получаем эдакую виртуальную матрицу вызовов. В плюсах для такого приходится извращаться, не зря много про двойную диспетчеризацию написано (не у Александреску ли была нехилая глава этому посвещена или у Мейерса?), ну а для множественной диспетчеризации надо ещё хитрей изгаляться...
Да я понял, что здесь речь идет о чем-то типа мультиметодов. Просто из-за таких явнях ляпов в знании C++ сама ценность такого сравнения сильно уменьшается, имхо.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да я понял, что здесь речь идет о чем-то типа мультиметодов. Просто из-за таких явнях ляпов в знании C++ сама ценность такого сравнения сильно уменьшается, имхо.
Конечно, подобное можно видеть и тут на рсдн в лице всяких апологетов Оберона (возможно в чём-то стоящего язык).
К сожалению такого просто избежать невозможно, все когда-то были профанами, только вот, к сожалению, многие ими остаются...
Здравствуйте, eao197, Вы писали:
E>Там и еще было: E>
E>Помимо списков и символов, в Лисп есть отдельные типы данных для строк, массивов, хеш-таблиц, записей (структур), потоков ввода-вывода. Кроме того, стандарт Common Lisp включает в себя систему объектно-ориентированного программирования CLOS, далеко превосходящую по выразительным возможностям систему программирования C++. Для доказательства этого превосходства достаточно отметить, что есть возможность выбирать вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно определить четыре метода
E>(defmethod draw ((x sentence) (y screen)) (message-box x y)) ; для отображения сообщения на экране
E>[ skipped ]
E>При вызове
>>(draw my-data my-device)
E>выбор одного из четырех определенных методов будет динамически осуществляться в момент вызова. Это невозможно в C++, где пришлось бы делать draw либо методом общего предка объектов screen и paper, либо методом общего предка sentence и picture, а выбор кода по типу второго аргумента осуществлять с помощью анализа этого типа в конструкции if.
И что? Я так понимаю, имеются в виду мультиметоды (хотя, может, показано это не очень ясно), которых в C++ пока нет.
E>И еще пару перлов: E>
E>Например, легко ошибиться, написав (i==j || k==l) вместо ((i==j) || (k==l)), а в Лисп такая ошибка просто невозможна, потому что нужно будет написать (or (= i j) (= k l))
E>Т.е. запись (or (= i j) (= k l)) сразу понятнее, чем (i==j || k==l).
А что, там так и написано — что одно понятнее другого??
E> Кстати, насколько я знаю, обе приведенные записи в C++ эквивалентны (т.к. приоритет сравнения выше, чем приоритет логического ИЛИ).
Значит, ошибся человек... С кем не бывает.
E>А так же: E>
E>Например, оператор if в C не возвращает значения, и, чтобы это обойти, была придумана операция ( ? : ). Было бы удобно, если бы оператор switch в C мог также возвращать значение, которое можно присвоить переменной после завершения его выполнения. В Паскале и Бейсике даже присваивание является оператором и не возвращает значения, поэтому нельзя написать a=b=с. В Лиспе в этом плане все гораздо удобнее. if возвращает значение. Одну и ту же конструкцию if можно использовать для ветвления алгоритма и для выбора значения по условию. Также возвращает значение и cond (аналог switch), и setf (аналог присваивания). Да и вообще, в Лиспе значение возвращается всегда, где это имеет смысл.
E>Как будто в C++ подругому .
Таки по-другому. switch, if, for и т.п. — все не возвращают значение, хотя во многоих случаях это могло бы быть полезным.
С другой стороны, есть высказывание в духе "Лисп-программисты для всего на свете знают значение, но не цену" . (За точность не ручаюсь.)
CX>>Ссылка интересная, спасибо. Но вот один настораживающий момент: E>[...] CX>>автор никогда не слышал и оперирует он знаниями совсем древнего C++. А это есть минус статье, т.к. взялся сравнивать — разберись в вопросе.
E>Там и еще было: E>
вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>
Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет. Как и Java. Как и C#. Как и Smalltalk. Перфразируя CrystalX, взялся чморить — разберись в вопросе.
Здравствуйте, Курилка, Вы писали:
К>Просто по ходу дела автор путается и ляпы допускает, хотя в его словах есть доля истины, просто здесь смысл не в параметрах, даж незнаю как это выразить, короче говоря — в CLOS изначально есть мультиметоды,
Текст далек от идеала, но этот момент, кажется, выражен ясно
выбор одного из четырех определенных методов будет динамически осуществляться в момент вызова.
Курилка,
К>Конечно, подобное можно видеть и тут на рсдн в лице всяких апологетов Оберона (возможно в чём-то стоящего язык).
Не всяких, а некоторых. Например, AVC вполне толково рассказывал про Оберон,
eao197,
E>>Да я понял, что здесь речь идет о чем-то типа мультиметодов. Просто из-за таких явнях ляпов в знании C++ сама ценность такого сравнения сильно уменьшается, имхо.
Аутор конечно как слон в посудной лавке. Тем не менее, хорошей реализации мультиметодов в C++ нет, каждая обладает какими-то недостатками, но все (известные реализации) — необходимостью в интеллектуальной работе руками при масштабировании. То есть здесь 1:0 в пользу Лиспа. Увы.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
P>>>А что это значит??
G>>В пылу дискуссии участники незаметно перешли с русского на Липс, так как он дает больше выразительных возможностей чем любой другой язык.
Т>Вы будете смеяться, но это был С++/
Буду . Мой пример с C++ и Clean отдыхает. Честно скажу — не знал, что запятая перегружается .
Здравствуйте, Gaperton, Вы писали:
G>вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>[/q]
G>Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет.
Вот написал бы он мультиметоды -- я бы слова не сказал. А то, что было выделено жирным сильно смахивает на обычный overloading.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
pvgoran wrote:
> C>Преподаватель учил Лисп вместо со студентами, стараясь все сделать как > C>можно более красиво > Н-да... Звучит это довольно подозрительно. Если воспринимать > буквально, то получается, что преподавателю надо было за время, > отведенное на преподавание дисциплины (N часов в учебном плане), > самому изучить язык.
Кто говорит, что преподаватель изучал язык на парах??? Он его изучал
дома (и на работе), составляя и решая задания, которые только потом уже
давались студентам.
> C>Лисп вообще давался в этом курсе для изучения > C>функционального подхода. В следующем году будет либо Scheme, либо Clean. > Если интересно, могу рассказать/посоветовать одну книжку по Scheme (и > не только).
Мне-то не нужно. А вот студентам — пригодится, причем надо на русском языке.
> C>А это уже скорее недостаток Лиспа — он не побуждает думать по-другому, > C>если человек уже не знает что такое функциональное программирование и с > C>чем его едят. > А что, он должен заставлять? Multi-paradigm языки не имеют право на > существование? Вон C++ тоже не заставляет использовать ООП > программиста, который знаком с C.
Ну так в С++ главная парадигма — это императивное программирование. В
Лиспе — все же близкое к функциональному, но вот сам Лисп не особо
побуждает его использовать.
> C>Я его не представляю, я его видел. После натыкания по разу на > C>стандартные ляпсусы в С++ писали вполне нормальный код. > Уточняю: речь идет о вещах вроде FC++. Их действительно можно > использовать без особого напряга, не имея приличного опыта с C++?
STL они использовали совершенно нормально, а больше и не надо было.
Здравствуйте, eao197, Вы писали:
E>Да я понял, что здесь речь идет о чем-то типа мультиметодов. Просто из-за таких явнях ляпов в знании C++ сама ценность такого сравнения сильно уменьшается, имхо.
Камень в твой огород
People frightened by Lisp make up other reasons for not using it. The standard excuse, back when C was the default language, was that Lisp was too slow. Now that Lisp dialects are among the faster languages available, that excuse has gone away. Now the standard excuse is openly circular: that other languages are more popular.
(Beware of such reasoning. It gets you Windows.)
Я отвлекусь в философию непрограммирования. Вообщем-то, это справедливо. Для того, кто выбирает только то, что уже проверено, есть только один способ принять новую технологию: если ему её навяжут насильно Моё жирное имхо, что .Net (и C#.Net в частности) никогда так быстро не заняли бы свои позиции, если бы не заявление Microsoft, что следующая версия ОС будет содержать .Net и более того, многие новые API будут доступны только из managed-кода. Если кто-то сомневается, как eao197, то ему дают гарантию.
На самом деле не думаю, что у Microsoft есть в запасе какая-нибудь волшебная палочка (или волшебная кредитка? ), с помощью которой она может такую гарантию всем обеспечить. Просто они уже на практике проверили, что "личные качества" технологии мало на что влияют, а решающим является количество вложенных усилий. Иными словами, любая технология может стать широко распространённой и повсеместно используемой, (зачеркнуто '(если Microsoft этим займется )) если этим просто заняться. Без всяких ноу-хау и волшебства, без неоспоримых достоинств, которые посрамят всех конкурентов; ничего не нужно. Примеры уже приводились — Basic, Windows, x86, MFC.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я отвлекусь в философию непрограммирования. Вообщем-то, это справедливо. Для того, кто выбирает только то, что уже проверено, есть только один способ принять новую технологию: если ему её навяжут насильно Моё жирное имхо, что .Net (и C#.Net в частности) никогда так быстро не заняли бы свои позиции, если бы не заявление Microsoft, что следующая версия ОС будет содержать .Net и более того, многие новые API будут доступны только из managed-кода. Если кто-то сомневается, как eao197, то ему дают гарантию.
Кё>На самом деле не думаю, что у Microsoft есть в запасе какая-нибудь волшебная палочка (или волшебная кредитка? ), с помощью которой она может такую гарантию всем обеспечить. Просто они уже на практике проверили, что "личные качества" технологии мало на что влияют, а решающим является количество вложенных усилий. Иными словами, любая технология может стать широко распространённой и повсеместно используемой, (зачеркнуто '(если Microsoft этим займется )) если этим просто заняться. Без всяких ноу-хау и волшебства, без неоспоримых достоинств, которые посрамят всех конкурентов; ничего не нужно. Примеры уже приводились — Basic, Windows, x86, MFC.
Да все это правильно. Одно смущает: почему же с Lisp-ом такого (в смысле популяризации и расширения применения) не происходит за сорок-то лет существования? С Perl-ом происходит, с Python-ом происходит, с Ruby происходит. Даже у C++, который только ленивый не ругает -- и то проблем с популярностью нет. А вот с таким, на словах, замечательным Lisp -- нет.
Ну да ладно, я здесь и так этим вопросом всех достал. Пора завязывать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
> вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>
> Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет.
Гм... А библиотечные решения отвергаются? Если да, то по каким соображениям?..
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Трурль, Вы писали:
Т>>Здравствуйте, eao197, Вы писали:
E>>>А то, что было выделено жирным сильно смахивает на обычный overloading.
Т>>Обычный overloading в языке с динамической типизацией
E>"руководствуясь типами нескольких параметров" в C++ работает обычный overloading.
Разница тут в том, что в Лиспе оверлоадинг возможен в рантайме.
Более того, сама идея generic functions/methods напоминает
специализацию темплейтов в C++, только в период выполнения
(а поскольку выполнение может быть и в период компиляции, то
фактически ничего не теряется).
Здравствуйте, Cyberax, Вы писали:
C>eao197 wrote:
>> Д>>>А давайте спросим у тех, кто два месяца назад начал с С++ знакомиться >> E>>А что мешает? Спроси. >> Д>Мне ответ уже известен. >> Дык по поводу C++ ответ мне так же известен. А вот про Lisp -- нет. >> И есть большое подозрение, что в случае с Lisp-ом это будет тот же >> самый ответ.
C>Да, в этом году на кафедре математики УдГУ первокурсникам решили C>преподавать Лисп на практике по программированию — мой коллега по работе C>как раз ее ведет (аспирантом порабатывает). Я помогал составлять C>практические задания — ничего сложного, простенькие вещи типа чисел C>Фибоначчи, сортировок, поиска.
C>Студенты плевались сильно и качество их программ было на очень низком C>уровне (они их писал в паскалевском стиле). Несколько раз было прикольно C>- ко мне по аське обращались с просьбами сделать практические задания, C>которые я же и помогал сочинять.
С прискорбием могу заметить, что мировая общественность игнорирует (очевидно, себе во вред) передовой опыт УдГУ. Куда только смотрит руководство вузов, использующих в обучении Lisp(scheme).
И главное — каких плохих специалистов наверно готовит лучший программерский вуз мира MIT, применяющий Scheme в качестве первого языка. И это что — посмотрите, сколько универовлицензировало этот курс у МИТа. Куда катимся...
Gaperton wrote:
> C>Студенты плевались сильно и качество их программ было на очень низком > C>уровне (они их писал в паскалевском стиле). Несколько раз было > прикольно > C>- ко мне по аське обращались с просьбами сделать практические задания, > C>которые я же и помогал сочинять. > С прискорбием могу заметить, что мировая общественность игнорирует > (очевидно, себе во вред) передовой опыт УдГУ. Куда только смотрит > руководство вузов, использующих в обучении Lisp(scheme) > <http://www.schemers.com/schools.html>.
Я это прекрасно знаю.
> И главное — каких плохих специалистов наверно готовит лучший > программерский вуз мира MIT, применяющий Scheme в качестве первого > языка <http://mitpress.mit.edu/sicp/>. И это что — посмотрите, сколько > универов <http://mitpress.mit.edu/sicp/adopt-list.html>лицензировало > этот курс у МИТа. Куда катимся...
Вот, кстати, надо было начинать именно со Схемы с забаненым set'ом.
Здравствуйте, Cyberax, Вы писали:
>> И главное — каких плохих специалистов наверно готовит лучший >> программерский вуз мира MIT, применяющий Scheme в качестве первого >> языка <http://mitpress.mit.edu/sicp/>. И это что — посмотрите, сколько >> универов <http://mitpress.mit.edu/sicp/adopt-list.html>лицензировало >> этот курс у МИТа. Куда катимся...
C>Вот, кстати, надо было начинать именно со Схемы с забаненым set'ом.
Надо было вообще взять МИТовский курс SICP на основе Scheme за основу . Материалы курса, как вы видите, открыты.
E>Да все это правильно. Одно смущает: почему же с Lisp-ом такого (в смысле популяризации и расширения применения) не происходит за сорок-то лет существования? С Perl-ом происходит, с Python-ом происходит, с Ruby происходит. Даже у C++, который только ленивый не ругает -- и то проблем с популярностью нет. А вот с таким, на словах, замечательным Lisp -- нет.
У lisp'а те же проблемы что и у forth'а, синтаксис(нечеловеческий ) и чрезмерная гибкость.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, eao197, Вы писали:
E>>Да все это правильно. Одно смущает: почему же с Lisp-ом такого (в смысле популяризации и расширения применения) не происходит за сорок-то лет существования? С Perl-ом происходит, с Python-ом происходит, с Ruby происходит. Даже у C++, который только ленивый не ругает -- и то проблем с популярностью нет. А вот с таким, на словах, замечательным Lisp -- нет.
FR>У lisp'а те же проблемы что и у forth'а, синтаксис(нечеловеческий ) и чрезмерная гибкость.
Я писал на форте, впечатления самые приятные. Проблем с нечеловеческим синтаксисом и (тем более) "чрезмерной гибкостью" не припомню, все очень просто и удобно. Реальная проблема форта как языка общего назначения — принципиальное отсутствие типов в языке — он типизирован примерно так же, как ассемблер, т.е. типы существуют только в воображении программиста. В лиспе такой проблемы нет.
Здравствуйте, Cyberax, Вы писали:
>> C>Преподаватель учил Лисп вместо со студентами, стараясь все сделать как >> C>можно более красиво >> Н-да... Звучит это довольно подозрительно. Если воспринимать >> буквально, то получается, что преподавателю надо было за время, >> отведенное на преподавание дисциплины (N часов в учебном плане), >> самому изучить язык.
C>Кто говорит, что преподаватель изучал язык на парах???
Написано же: "вместе со студентами".
C>Он его изучал C>дома (и на работе), составляя и решая задания, которые только потом уже C>давались студентам.
Ну, я и не думал всерьез, что все было так экстремально (на парах). Но и в описанном сценарии у преподавателя могло не оказаться достаточно времени. Хотя могло и оказаться...
>> C>Лисп вообще давался в этом курсе для изучения >> C>функционального подхода. В следующем году будет либо Scheme, либо Clean. >> Если интересно, могу рассказать/посоветовать одну книжку по Scheme (и >> не только).
C>Мне-то не нужно. А вот студентам — пригодится, причем надо на русском языке.
Ну, это скорее "в пользу" преподавателя, который будет вести курс.
Книга называется "Structure and interpretation of computer programs", написана вроде бы преподавателем MIT на основе курса, который он там читал. На Wiki ее превозносят прямо-таки до небес. (С другой стороны, кое-кто пишет, что она полезнее при самостоятельном изучении, а не при использовании ее в качестве учебного пособия.) Та часть, которую я читал, мне понравилась, и в качестве курса вроде подходит.
Перевод на русский есть URL http://newstar.rinet.ru/~goga/sicp/sicp.ps.gz. В бумажном виде, соответственно, тоже должен быть.
>> C>А это уже скорее недостаток Лиспа — он не побуждает думать по-другому, >> C>если человек уже не знает что такое функциональное программирование и с >> C>чем его едят. >> А что, он должен заставлять? Multi-paradigm языки не имеют право на >> существование? Вон C++ тоже не заставляет использовать ООП >> программиста, который знаком с C.
C>Ну так в С++ главная парадигма — это императивное программирование. В C>Лиспе — все же близкое к функциональному, но вот сам Лисп не особо C>побуждает его использовать.
C++ vs. C — это ООП vs "процедурное программирование", Lisp vs. C++ — это функциональное (допустим) vs. императивное программирование. Однако C++ можно использовать в процедурном стиле (не побуждает использовать ООП), а Lisp — в императивном (не побуждает использовать функциональный стиль). Ни то, ни другое IMHO не является недостатком соответствующего языка.
>> C>Я его не представляю, я его видел. После натыкания по разу на >> C>стандартные ляпсусы в С++ писали вполне нормальный код. >> Уточняю: речь идет о вещах вроде FC++. Их действительно можно >> использовать без особого напряга, не имея приличного опыта с C++?
C>STL они использовали совершенно нормально, а больше и не надо было.
Тогда это, наверное, был уже все-таки не функциональный стиль...
Здравствуйте, Gaperton, Вы писали:
>>> И главное — каких плохих специалистов наверно готовит лучший >>> программерский вуз мира MIT, применяющий Scheme в качестве первого >>> языка <http://mitpress.mit.edu/sicp/>. И это что — посмотрите, сколько >>> универов <http://mitpress.mit.edu/sicp/adopt-list.html>лицензировало >>> этот курс у МИТа. Куда катимся...
C>>Вот, кстати, надо было начинать именно со Схемы с забаненым set'ом. G>Надо было вообще взять МИТовский курс SICP на основе Scheme за основу . Материалы курса, как вы видите, открыты.
Здравствуйте, Gaperton, Вы писали:
FR>>У lisp'а те же проблемы что и у forth'а, синтаксис(нечеловеческий ) и чрезмерная гибкость. G>Я писал на форте, впечатления самые приятные. Проблем с нечеловеческим синтаксисом и (тем более) "чрезмерной гибкостью" не припомню, все очень просто и удобно. Реальная проблема форта как языка общего назначения — принципиальное отсутствие типов в языке — он типизирован примерно так же, как ассемблер, т.е. типы существуют только в воображении программиста. В лиспе такой проблемы нет.
Я тоже писал на форте(и даже как всякий уважающий себя фортист и на своей реализации языка ), на самом деле очень приятно писать, постоянно приходится немного напрягать мозги, очень стимулирует. Проблемы появляются позже, когда пытаешся читать то что написал, особенно если не позаботился комментировать то, что при написании казалось само сабой разумеющимся.
Здравствуйте, Павел Кузнецов, Вы писали:
>> E>Там и еще было: >> E>
>> вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>
>> Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет.
ПК>Гм... А библиотечные решения отвергаются? Если да, то по каким соображениям?..
К слову, а есть библиотечные решения, которые решают проблему мультиметодов насколько же просто, как если бы это было встроено в язык?
Точнее, даже не так: как выглядит максимально изящное библиотечное решение?
On Wed, 13 Jul 2005 13:51:24 -0500, Зверёк Харьковский <21481@users.rsdn.ru> wrote:
> Здравствуйте, Павел Кузнецов, Вы писали: > >>> E>Там и еще было: >>> E>
>>> вызываемое тело метода, руководствуясь типами нескольких параметров, а не одного, как в C++. Например, пусть у нас определены классы screen и paper, а также классы sentence и picture. Тогда для функции draw можно E>
> >>> Все написано правильно. Это называется "мультиметоды", и этого С++ не умеет. > > ПК>Гм... А библиотечные решения отвергаются? Если да, то по каким соображениям?.. > > К слову, а есть библиотечные решения, которые решают проблему мультиметодов насколько же просто, как если бы это было встроено в язык? > как выглядит максимально изящное библиотечное решение?
Ну, "максимально изящное" -- не знаю, тут долго можно спорить, т.к. понятия об изящном у всех свои... Но достаточно близкий по количеству писанины к встроенному в язык:
struct shape {...};
struct square : shape {...};
struct triangle : shape {...};
struct options {...};
// объявление мультиметодаbool overlap( virtual shape& a, virtual shape& b, options const& );
// реализацииbool overlap( static square& a, static triangle& b) {...}
bool overlap( static triangle& a, static square& b) {...}
Mожет быть, например, таким:
// Объявление "мультиметода" в одном из заголовочных файлов:
MM_METHOD(
overlap,
bool ( MM_VIRTUAL(shape)&, MM_VIRTUAL(shape)&, options const& )
);
// Реализация, потенциально в разных .cpp-файлах:
MM_METHOD_IMPL(
overlap,
bool, ( square& sq, triangle& tr, options const& o ),
{
// use 'sq', 'tr', and 'o' to implement
}
);
MM_METHOD_IMPL(
overlap,
bool, ( triangle& tr, square& sq, options const& o ),
{
// use 'sq', 'tr', and 'o' to implement
}
);
Если кому-то макросы принципиально не нравятся, то вполне возможны варианты с шаблонами. Правда писать придется чуть больше. Например:
Дарней wrote:
> C>Это язык, еще более извращенный: http://refal.ru/ > можно предположить, что он просто не допускает программирование в > "чисто процедурном" стиле > так что неудача с Лиспом — это просто провал преподавателя
Вот уж не знаю... Человек смог объяснить как писать программы на Рефале
и как он соотносится с НАМ (Нормальные Алгоритмы Маркова). Этот кусок
курса вообще замечательно получился — теория и практика замечательно
дополнили друг друга. А вот при попытке объяснить лямбда-исчисление и
функциональное программирование — что-то не так получилось.
И чего-то мне кажется, что виноват не только преподаватель.
Сейчас читаю MITовский курс — неплохо сделано, хотя он достаточно обширный.
Здравствуйте, Cyberax, Вы писали:
C>Вот уж не знаю... Человек смог объяснить как писать программы на Рефале C>и как он соотносится с НАМ (Нормальные Алгоритмы Маркова). Этот кусок C>курса вообще замечательно получился — теория и практика замечательно C>дополнили друг друга. А вот при попытке объяснить лямбда-исчисление и C>функциональное программирование — что-то не так получилось.
Cyberax wrote: > Вот, кстати, надо было начинать именно со Схемы с забаненым set'ом.
У нас в школе было интереснее — RL. Переменные? Зачем? let — нет. Ничего
нет. Арифметики нет. И на этом — двоичное возведение в степень писать
(число — список из I и O). Для счастья (чтоб не застрелились?) car и cdr
заменены на FIRST,LAST,BF(but first),BL,EXPR(=cons).
Здравствуйте, Cyberax, Вы писали:
C>Не так: "Эта куча Лиспового кода уже давно не дает нам никаких C>конкурентных преимуществ, а после .COM-коллапса мы уже не можем держать C>штат из 30 лаурятов премии Тьюринга для его поддержки. Так что пора его C>по кусочкам переписать, а у нас тут как раз крутые С++-программисты из C>отдела поиска есть.".
И денег им платить не надо... готовы работать за идею и хлеб. А что с них взять? Маньяки...
... << RSDN@Home 1.2.0 alpha rev. 557>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Gaperton, Вы писали:
FR>>>У lisp'а те же проблемы что и у forth'а, синтаксис(нечеловеческий ) и чрезмерная гибкость. G>>Я писал на форте, впечатления самые приятные. Проблем с нечеловеческим синтаксисом и (тем более) "чрезмерной гибкостью" не припомню, все очень просто и удобно. Реальная проблема форта как языка общего назначения — принципиальное отсутствие типов в языке — он типизирован примерно так же, как ассемблер, т.е. типы существуют только в воображении программиста. В лиспе такой проблемы нет.
FR>Я тоже писал на форте(и даже как всякий уважающий себя фортист и на своей реализации языка ),
Ну дык .
FR> на самом деле очень приятно писать, постоянно приходится немного напрягать мозги, очень стимулирует. Проблемы появляются позже, когда пытаешся читать то что написал, особенно если не позаботился комментировать то, что при написании казалось само сабой разумеющимся.
А вы не забывали следовать стилевым гайдлайнам? А именно — обязательный комментарий касательно входных/выходных параметров (одна строка) + короткие функции (в среднем 3-5 строк). Добавить сюда осмысленые имена слов + комментарии по структурам данных — и никаких проблем.
Здравствуйте, pvgoran, Вы писали:
P>C++ vs. C — это ООП vs "процедурное программирование", Lisp vs. C++ — это функциональное (допустим) vs. императивное программирование. Однако C++ можно использовать в процедурном стиле (не побуждает использовать ООП), а Lisp — в императивном (не побуждает использовать функциональный стиль). Ни то, ни другое IMHO не является недостатком соответствующего языка.
Более того. Лисп, строго говоря, не является функциональным языком — в нем императивный и функциональный стили равноправны. В упомянутом SICP рассмотрены оба стиля, также там рассмотрен ООП (объектная декомпозиция) и ФП (декомпозиция пограммы посредством "потоков" — ленивых списков).
Здравствуйте, Gaperton, Вы писали:
FR>> на самом деле очень приятно писать, постоянно приходится немного напрягать мозги, очень стимулирует. Проблемы появляются позже, когда пытаешся читать то что написал, особенно если не позаботился комментировать то, что при написании казалось само сабой разумеющимся.
G>А вы не забывали следовать стилевым гайдлайнам? А именно — обязательный комментарий касательно входных/выходных параметров (одна строка) + короткие функции (в среднем 3-5 строк). Добавить сюда осмысленые имена слов + комментарии по структурам данных — и никаких проблем.
Дело не в коментариях а в том, что читать нетривиальные манипуляции со стеками тяжело.
Здравствуйте, VladD2, Вы писали:
VD>Если для них быстрый цикл был важен, то почему они не сменили язык на тот который обладает более быстрым циклом?
А если уже быстрый цикл не важен? А если уже технология отработана и встал вопрос лишь об эффективной ее реализации?
VD>Это ведь полная бессмыслица исходя из этих сообрежения выбрать С++. Уж у него то цикл только длиннее.
Цикл чего, простите, длиннее? Цикл внесения серьезных изменений — да, длиннее. Цикл разработки по "устаканившемуся" ТЗ — ничуть.
VD>Сдается мне, что причина была банальнее. К управлению проектом пришел фанат плюсов который нашел фатальный недостаток в продутке. Ну, вы знаете какой.
Сдается мне, что причина была еще более банальной — в возросшем количестве пользователей.
VladD2 wrote:
> C>Не так: "Эта куча Лиспового кода уже давно не дает нам никаких > C>конкурентных преимуществ, а после .COM-коллапса мы уже не можем держать > C>штат из 30 лаурятов премии Тьюринга для его поддержки. Так что пора его > C>по кусочкам переписать, а у нас тут как раз крутые С++-программисты из > C>отдела поиска есть.". > И денег им платить не надо... готовы работать за идею и хлеб. А что с > них взять? Маньяки...
Тут возможно сыграла роль и личность Грэхема, его высокомерие по
отношению к остальным языкам (похоже, что это отличительная черта
лисповцев).
Здравствуйте, VladD2, Вы писали:
VD>Интересно как можно выразить мысль еще? Человек вообще не понял о чем идет речь или намерено подменяет тему разговора.
VD>Спорить с подобным бессысленно. А объяснять то что было написано двумя сообщениями выше нет никакого желания.
Gaperton wrote:
> C>Вот, кстати, надо было начинать именно со Схемы с забаненым set'ом. > Надо было вообще взять МИТовский курс SICP на основе Scheme за основу > . Материалы курса, как вы видите, открыты.
Все, сегодня нашел время его просмотреть. Курс классный, только вот явно
не для наших университетов — часов не хватит
Хотелось бы что-нибудь сосредоточенное на функциональном
программировании, чтобы шло параллельно с теорией лямбда-исчисления. С
НАМ (Нормальные Алгоритмы Маркова) это получилось очень хорошо, теперь
надо расширить до функциональщины.
Еще неплохо бы и по логическому программированию чего-нибудь. Хотя по
Прологу литература еще с советских времен осталась (причем местами очень
даже неплохая).
Здравствуйте, eao197, Вы писали:
E>Я сам сталкиваюсь с тем, что сейчас проще найти Java и C# программистов, чем C++. Поэтому...
Ой, правда что ли? А я тут один забавный фактик знаю. Сейчас поделюсь... Думаю, АВК и Вольфхаунд не дадут сорвать.
В одной не безызвестной конторе искали C#-программиста. Долго искали... упорно... и не то чтобы претендентов не было. Но все эти притенденты были... ну, как бы по мягче сказать... не очень высокой квалификации. Мноие из низ не могли список в обратную сторону развернуть... Так вот искали они искали и нашли. Как ты думашь кого? Правильно — С++-программиста который между делом немного изучил C#. Ну, чё? Малость подучил C# и теперь вроде как даже успешно трудится на благо той конторы. Думаю ты догадался кто был тем С++ программистом?
В чем мораль? Дело в том, что хороших программистов мало. И это слабо зависит от языка. Более того. Чем проще язык, тем сложнее найти грамотного программиста пишущего на нем.
E> начинать проект на C++ и держать в уме такой фактор риска, как сложность замены выбывающих по разным причинам участников команды, уже тяжело. А теперь попробуем заменить C++ на Lisp. Ситуация по этим параметрам ухудшается на порядок, если не больше.
Думаю, что хорошего программиста можно за относительно небольшой строк переучить на любой язык. Так что проблемы Лиспа скорее в нем самом. Это и ФЯ, и с очень спорным синтаксисом. И если в области метапрограммирования такой синтаксис просто находка, то в области тупой реализации ТЗ он может оказаться очень плохим выбором. Мне кажется проблема Лиспа в том, что его на нем намного проще что-то написать нежели прочитать. Тут он сроди Перлу.
E>Ну и еще один фактор, который лично меня смущает в этой теме. Имхо, здесь слишком часто делаются голословные утверждения о том, что Lisp лучше, Lisp понятнее, на Lisp-е требуется меньше строк и т.д. Сразу вспоминается американская пословица: "Если ты такой умный, то почему ты не миллионер"?
+10
E>Если Lisp так хорош, да еще и появился бог знает когда, да еще и развивался в лучшую сторону все это время, то почему мы работаем с C/C++, Java, C#, Perl, VB? Почему,
Боюсь Лисповцы ответят — потамучта ты мэйнстримовая мышевозила.
E>И давайте не будем вспоминать про "миллионов мух, которые не могут ошибаться".
А на это ответят — надо Федя, надо!
E> В идустрии разработки ПО этих мух действительно миллионы, но они нуждаются в инструментах, которыми они в состоянии воспользоваться. И выигрывает тот, кто такие инструменты предлагает.
И все же дело не в мухах. Лично я предпочту более длинный, но более понятный код. Не же ли хакирский (в лучшем смысле этого слова) выверт укладывающий 5 строк в одну. В конечном итоге грамотно написанный код все равно сведется к некой функции или классу который скроет от меня все эти 5 (500 или сколько угодно) строк и предоставит мне удобную абстракцию.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Я сам сталкиваюсь с тем, что сейчас проще найти Java и C# программистов, чем C++. Поэтому...
VD>Ой, правда что ли? А я тут один забавный фактик знаю. Сейчас поделюсь... Думаю, АВК и Вольфхаунд не дадут сорвать.
VD>В одной не безызвестной конторе искали C#-программиста. Долго искали... упорно... и не то чтобы претендентов не было. Но все эти притенденты были... ну, как бы по мягче сказать... не очень высокой квалификации. Мноие из низ не могли список в обратную сторону развернуть... Так вот искали они искали и нашли. Как ты думашь кого? Правильно — С++-программиста который между делом немного изучил C#. Ну, чё? Малость подучил C# и теперь вроде как даже успешно трудится на благо той конторы. Думаю ты догадался кто был тем С++ программистом?
Э...Неужели Карл Маркс? (из анекдота про советского археолога, которому показали найденый на раскопках череп и спросили: "Кто это? Ну вы же знаете, вас этому учили.")
Так эта история с тобой, AndrewVK и WolfHound-ом произошла?
VD>В чем мораль? Дело в том, что хороших программистов мало. И это слабо зависит от языка. Более того. Чем проще язык, тем сложнее найти грамотного программиста пишущего на нем.
+11
Но опять же, аналогия с анекдотом:
-- Мама, а правда, свою настоящую, единственную любовь в жизни нужно долго искать?
-- Да дочка, но чтобы скоротать время, можно пару раз выйти замуж.
Видимо сложность, с которой на собеседованиях сталкиваюсь я, состоит в том, что сейчас многие молодые ребята вообще не знают C++. Т.е. им дали что-то в течени одного семестра, но назвать это обучением С++ я не решусь. При этом они C# и Java хоть в какой-то мере владеют и поэтому в C#/Java проект могут быть включены сразу же (на сопровождение или на наименее ответственные направления). И если кто-то из них действительно окажется хорошим программистом, то это вскоре станет понятно.
А вот с C++-ом ситуация сложнее. Для того, чтобы нормально программировать на C++ и включится в большой, уже идущий проект, необходим уровень выше среднего. Для этого нужно прочитать несколько серьезных книг (Страуструпа, Саттера, Вандервуда, Джосьютеса, а может даже и Александреску) и набить достаточное количество собственных шишек. Вот как раз таких людей найти у нас не просто. А если новичка в C++ пустить в проект, то самый лучший исход -- это постоянный мониторинг его кода посредством частых codereview.
И еще хорошо, если человек действительно молодой, не очень опытный, понимающий это и без понтов. Такого можно и нужно учить. Если попадается обучаемый товарищ, и не раздолбай, то толк из него получается. При этом немаловажно, что он соглашается на время обучения на более низкую оплату (ну нет возможности сейчас практикантам платить больше, чем они реально стоят с расчетом на то, что в будущем это окупится). Хуже когда на роль C++ программиста приходит "матерый", "опытный" С/Java/VB (у меня был именно такой опыт) программист. Если человек вменяемый, без понтов и мозги нормально работают, то главная проблема в размере оплаты на время его обучения (когда он в production-коде практически не участвует). Если человек согласен начинать с оплаты, ниже средней, то проблем нет. А вот если не согласен, то... И ведь стимула к изучению C++, как такового, нет. Ну нужно освоить C++ для того, чтобы работать в нашей конторе, а вот в соседней конторе он на уже известной ему Java будет прямо сейчас получать устраивающую его зарплату. Так зачем же прилагать лишние усилия, если результат представляется одинаковым?
А теперь попробуем заменить C++ на Lisp, которого вообще никто не знает (тот небольшой процент знающих Lisp RSDN-овцев можно считать статичстической погрешностью). Как говорится, маразм крепчал.
VD>И все же дело не в мухах. Лично я предпочту более длинный, но более понятный код. Не же ли хакирский (в лучшем смысле этого слова) выверт укладывающий 5 строк в одну. В конечном итоге грамотно написанный код все равно сведется к некой функции или классу который скроет от меня все эти 5 (500 или сколько угодно) строк и предоставит мне удобную абстракцию.
+1
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>И еще хорошо, если человек действительно молодой, не очень опытный, понимающий это и без понтов. Такого можно и нужно учить. Если попадается обучаемый товарищ, и не раздолбай, то толк из него получается. При этом немаловажно, что он соглашается на время обучения на более низкую оплату (ну нет возможности сейчас практикантам платить больше, чем они реально стоят с расчетом на то, что в будущем это окупится). Хуже когда на роль C++ программиста приходит "матерый", "опытный" С/Java/VB (у меня был именно такой опыт) программист. Если человек вменяемый, без понтов и мозги нормально работают, то главная проблема в размере оплаты на время его обучения (когда он в production-коде практически не участвует). Если человек согласен начинать с оплаты, ниже средней, то проблем нет. А вот если не согласен, то... И ведь стимула к изучению C++, как такового, нет. Ну нужно освоить C++ для того, чтобы работать в нашей конторе, а вот в соседней конторе он на уже известной ему Java будет прямо сейчас получать устраивающую его зарплату. Так зачем же прилагать лишние усилия, если результат представляется одинаковым?
Все это здорово, но с дотнетом та же самая ситуация. Тот, кто раньше писал на С++, перейдя на дотнет, первое время просто не в состоянии писать нормальный код, потому что упорно пытается применить старые техники, которые, чаще всего, просто не работают. Единственное преимущество дотнета и джавы в этом плане — проект на них меньше страдает от некачественного кода, а если пострадал, то очень быстро находится кто есть ху.
Здравствуйте, AndrewVK, Вы писали:
AVK>Все это здорово, но с дотнетом та же самая ситуация. Тот, кто раньше писал на С++, перейдя на дотнет, первое время просто не в состоянии писать нормальный код, потому что упорно пытается применить старые техники, которые, чаще всего, просто не работают. Единственное преимущество дотнета и джавы в этом плане — проект на них меньше страдает от некачественного кода, а если пострадал, то очень быстро находится кто есть ху.
Имхо, именно в этом у Java/C# и есть огромное преимущество перед C++. Поэтому и вход новичка в Java/C# проект менее болезненный, чем в C++ проект (инкубационный период гораздо короче).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197,
> AVK> Единственное преимущество дотнета и джавы в этом плане — проект на них меньше страдает от некачественного кода, а если пострадал, то очень быстро находится кто есть ху.
> Имхо, именно в этом у Java/C# и есть огромное преимущество перед C++. Поэтому и вход новичка в Java/C# проект менее болезненный, чем в C++ проект (инкубационный период гораздо короче).
И эта же нацеленность на компенсацию некачественного кода и помощь новичкам является их слабостью, т.к. в погоне за простотой они урезают возможности, которые могли бы оказаться полезными более квалифицированному программисту, а иногда, организуя "защиту от дурака" теряют в выразительности, которая могла бы пригодиться для более точного контроля, чем встроенный. Вот такая диалектика, понимаешь, получается...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> AVK> Единственное преимущество дотнета и джавы в этом плане — проект на них меньше страдает от некачественного кода, а если пострадал, то очень быстро находится кто есть ху.
>> Имхо, именно в этом у Java/C# и есть огромное преимущество перед C++. Поэтому и вход новичка в Java/C# проект менее болезненный, чем в C++ проект (инкубационный период гораздо короче).
ПК>И эта же нацеленность на компенсацию некачественного кода и помощь новичкам является их слабостью, т.к. в погоне за простотой они урезают возможности, которые могли бы оказаться полезными более квалифицированному программисту, а иногда, организуя "защиту от дурака" теряют в выразительности, которая могла бы пригодиться для более точного контроля, чем встроенный. Вот такая диалектика, понимаешь, получается...
Угу. Выбирай, но осторожно. Но выбирай... ((С) Жванецкий)
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, AndrewVK, Вы писали:
AVK>>Все это здорово, но с дотнетом та же самая ситуация. Тот, кто раньше писал на С++, перейдя на дотнет, первое время просто не в состоянии писать нормальный код, потому что упорно пытается применить старые техники, которые, чаще всего, просто не работают. Единственное преимущество дотнета и джавы в этом плане — проект на них меньше страдает от некачественного кода, а если пострадал, то очень быстро находится кто есть ху.
E>Имхо, именно в этом у Java/C# и есть огромное преимущество перед C++. Поэтому и вход новичка в Java/C# проект менее болезненный, чем в C++ проект (инкубационный период гораздо короче).
Этот тезис более чем спорный. На самом деле, C# и Java -- надувательские языки, они не столько помогают бороться с ошибками, сколько их банально скрывают.
Здравствуйте, eao197, Вы писали:
E>Так эта история с тобой, AndrewVK и WolfHound-ом произошла?
Почти угадал. Не со мней.
E>
E>-- Мама, а правда, свою настоящую, единственную любовь в жизни нужно долго искать?
E>-- Да дочка, но чтобы скоротать время, можно пару раз выйти замуж.
E>Видимо сложность, с которой на собеседованиях сталкиваюсь я, состоит в том, что сейчас многие молодые ребята вообще не знают C++. Т.е. им дали что-то в течени одного семестра, но назвать это обучением С++ я не решусь. При этом они C# и Java хоть в какой-то мере владеют и поэтому в C#/Java проект могут быть включены сразу же (на сопровождение или на наименее ответственные направления). И если кто-то из них действительно окажется хорошим программистом, то это вскоре станет понятно.
Хоть в какой-то мере можно владеть абсолютно любым языком. Вот только востребовнны такие программисты не очень сильно.
E>А вот с C++-ом ситуация сложнее. Для того, чтобы нормально программировать на C++ и включится в большой, уже идущий проект, необходим уровень выше среднего.
Полная ерунда. Чтобы нормально программировать нужно просто уметь нормально программировать. И человек поверхносно знающий С++ ничем не будет отличаться от человека поверхносно знающего C#.
Другое дело, что человек знающий и C# и С++ потенциально более ценеен, так как он попросту дольше и более разнообразно тренировался. Кстати, вот таких C# and C++ Developer процентов 15 от всех С++-ных вакансий. Т.е. людям нужны C#-программисты, но "пропитанные солью". А пропитаться как раз проще всего трахаясь с С++.
E> Для этого нужно прочитать несколько серьезных книг (Страуструпа, Саттера, Вандервуда, Джосьютеса, а может даже и Александреску) и набить достаточное количество собственных шишек.
Шишек и форумов достаточно. Хотя книги в любой области полезны. Вот только грош цена тому кто начитался Алексондреску и забыл прочесть базовые вщи о дизайне, безопасности качестве и т.п.
Александреску полезен просто тем, что это хорошее выворачивание мозгов. Гикость такое чтиво увеличивает. Но читать ли Александреску или что-то про Скамл разницы никакой нет. Так что я пожалуй скорее соглашусь с идеей, что хороших программистов (в том числе и С++-) нужно обучать разным ФЯ. Ну, чтобы мозги так раком встали, что потом С++ показался бы детской забавой.
E>И еще хорошо, если человек действительно молодой, не очень опытный, понимающий это и без понтов.
С понтами скорее те кто считает С++-ников высшей кастой. Понимать здесь точно нечего.
E> Такого можно и нужно учить. Если попадается обучаемый товарищ, и не раздолбай, то толк из него получается.
Как в прочем и везде (на любом языке).
E> При этом немаловажно, что он соглашается на время обучения на более низкую оплату (ну нет возможности сейчас практикантам платить больше, чем они реально стоят с расчетом на то, что в будущем это окупится). Хуже когда на роль C++ программиста приходит "матерый", "опытный" С/Java/VB (у меня был именно такой опыт) программист.
А у меня был опыт когда я просто хринел от тупого С++-ника который нихрена не мог вникнуть в те самые Java/VB. Надо признать и на С++ он писал не лучшим образом. Вернее тот самый средний С++ он понимал, но вот то что нужно еще изучить то самое MFC на котором пишеш программу до него не доходило. Но это уже детали.
E> Если человек вменяемый, без понтов и мозги нормально работают, то главная проблема в размере оплаты на время его обучения (когда он в production-коде практически не участвует). Если человек согласен начинать с оплаты, ниже средней, то проблем нет. А вот если не согласен, то...
Еще раз. Это везде так. С++ тут не причем. Хороший C# программист стоит не дешево и его еще поискать надо. К сожалению в жизни больше тех кого можно назвать ниже среднего.
E> И ведь стимула к изучению C++, как такового, нет. Ну нужно освоить C++ для того, чтобы работать в нашей конторе, а вот в соседней конторе он на уже известной ему Java будет прямо сейчас получать устраивающую его зарплату. Так зачем же прилагать лишние усилия, если результат представляется одинаковым?
Не льсти себе. Нет у вас никакой касты. И в соседней конторе он получит по началу минимум. Ну, и если он 0, то высоких окладов ему не видать.
Ява же просто терпимее относится к ошибкам. И там где ламер (которые и бывают обычно дешевыми) насажает в С++ ошибок которые потом бригадов за пол года не вычистить, то на яве он просто сделает не эффектинове и кривое решение которое с помощью рефакторинга и какой-то матери получится хоть как-то запустить.
E>А теперь попробуем заменить C++ на Lisp, которого вообще никто не знает (тот небольшой процент знающих Lisp RSDN-овцев можно считать статичстической погрешностью). Как говорится, маразм крепчал.
Причем тут лисп? Уж на нем то сможет писать тот самый ламер. И даже резултат будет куда более безопасным. А ламеров всегда можно найти. Лисп в первую очередь не нужен работодателям (не будем обсуждать почему, но это факт). А раз нет спроса, то не будет и предложения. Вот Гапертон все время повторяет "вот в MIT первым языком используется Лисп...". Ну, и что? Я вот в школе пение проходил чуть ли не в первом классе. И что я что петь научился? А как я изумительно знаю химию... Студент знает, что Лисп ему при выходе на рабту и на фиг не упадет. Наших форумов с агитацией он еще не читает. Ну, и пройдет он ... мимо этого лиспа в лучем виде. Так что менять нужно (если вообще нужно) не образование, а производство. Будут нужны Лиспари — будут люди его по ночам зубрить. Тоже самое и с С++-никами.
РСДН изначально был С++-ным сайтом. Почти все кто стоял у его истоков (и даже я) был С++-ником до мозга костей. Любое голосование тип "Ххх sv. C++" на этом сайте несколько лет назад был бы проигран с разгромным счетом. А теперь дивись
. И это только начало.
VD>>И все же дело не в мухах. Лично я предпочту более длинный, но более понятный код. Не же ли хакирский (в лучшем смысле этого слова) выверт укладывающий 5 строк в одну. В конечном итоге грамотно написанный код все равно сведется к некой функции или классу который скроет от меня все эти 5 (500 или сколько угодно) строк и предоставит мне удобную абстракцию.
E>+1 E>
Ну, хоть в чем то мы стоим на единых позициях.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>И эта же нацеленность на компенсацию некачественного кода и помощь новичкам является их слабостью, т.к.
Ага. Конкуренцию гады создают... зарплаты сшибают.
ПК> в погоне за простотой они урезают возможности, которые могли бы оказаться полезными более квалифицированному программисту, а иногда, организуя "защиту от дурака" теряют в выразительности, которая могла бы пригодиться для более точного контроля, чем встроенный. Вот такая диалектика, понимаешь, получается...
Ну, в то что возможностей хватает ты все равно не повришь.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Этот тезис более чем спорный. На самом деле, C# и Java -- надувательские языки, они не столько помогают бороться с ошибками, сколько их банально скрывают.
Примеры скрытия ошибок языком можно поглядеть?
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>...если Lisp так хорош, то почему же он не мейнстрим? Ну не могу я понять. И аргументов, которые бы доказывали, что Lisp хорош не вижу. Только восторженные отзывы.
Дело в том, что Лисп плох. Да и восхваляют его очень небольшое количество людей. Но с тем что лисповские макросы до сих пор являются одним из смых гибких средств метапрограммирования не поспоришь. Это факт.
Между прочем если взять самых рьяных апологетов ФЯ (т.е. Гапертора и Квантонара), то можно заметить, что они как раз на лисп смотрят довольно прохладно. Так Гапертон, как мне показалось, больше агетировал за Хаскель и Эрлинг (по крайней мере для целей обучения). Примеры на этих языках мне тоже больше понравились. Квантонар выступал за Окамл. И я очень даже понимаю его аргументы. Это как раз то ФЯ на котором очень даже можно писать риальные приложения. Причем это статически типизированный язык в котором нет даже компромиса в типобезопасности.
А Лисп — это прородитель всего этого у которого в добавок удобный для трасформаций синтаксис. Только и всего.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Кодёнок, Вы писали:
Кё>"Если RISC лучше, то почему у всех стоит Intel"
Потому что это вранье. Лучше тот процессор который бысрее решает задачи. Интел решает задачи ПК бысрее.
Кё>"Если FreeBSD лучше, то почему Windows более распространён"
Потому что это тоже вранье. FreeBSD лучше Линукса и то как сервер. А как машина для бухгалтера или как машина для геймера FreeBSD полный 0.
Кё>"Если интерфейс Mac OS всегда был лучше (впереди), то почему даже опен-сорсные библиотеки ему не следуют"
Чё?
Кё>Много факторов повлияло на проигрыш лучших технологий,
Лучше то что побидило.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Кодёнок, Вы писали:
Кё>Потому что они императивные. Понятные всем. А чтобы освоить новое мышление, нужно немного усилий.
О, как?!
Скажи, а for в Лиспе функциональнее чем for в Питоне? А скажем, map() в Питоне императивнее чем в Лиспе?
Что является критерием функциональности и императивности?
Мое мнение по этому вопросу таково. Императивный и функциональый это про стиль программирования. И если язык поддерживает оба стиля, то определение того к какому классу относится язык — это не более чем устоявшийся стереотип.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>А макросы уровня лиспа писать тоже никто не мешает? Писать функционально мало, имхо, на плюсах тоже получается местами вполне функционально...
Аргумент был "Потому что они императивные". Хаскель тоже функциональный, но с макросами там туго, так как язык имеет четкий и развитой синтаксис и не имеет препроцессора.
А что до макросов, то их при желании можно прикрутить к любому языку. Например, вот вариант прикручивания их к Яве. В Питоне и Руби тоже есть свои реализации макросво я-ля Лисп.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
Ш>> надувательские языки, они не столько помогают бороться с ошибками, Ш>> сколько их банально скрывают.
V> Примеры скрытия ошибок языком можно поглядеть?
Легко. Исключение в finally во время обработки уже выброшенного исключения.
Первое при этом потеряется. Одна ошибка уже скрыта
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
P.S.
V>> Примеры скрытия ошибок языком можно поглядеть?
ПК> Легко. Исключение в finally во время обработки уже выброшенного ПК> исключения. Первое при этом потеряется. Одна ошибка уже скрыта
: вместо исправления ситуации ошибку
"замазали" требованием поддержки множественных вызовов Dispose. При этом
сами же признают, что ошибки таким макаром прячутся:
Though it is legal to invoke Dispose more than once, if this happens it may indicate the presence
of a bug since such an object is usually rendered otherwise unusable after the first Dispose invocation.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
E>>А вот с C++-ом ситуация сложнее. Для того, чтобы нормально программировать на C++ и включится в большой, уже идущий проект, необходим уровень выше среднего.
VD>Полная ерунда. Чтобы нормально программировать нужно просто уметь нормально программировать. И человек поверхносно знающий С++ ничем не будет отличаться от человека поверхносно знающего C#.
В том-то и дело, что в C++ недостаточно "просто уметь нормально программировать". Кроме умения нормально проектировать решения в C++ требуется еще довольно много внимания уделять "мелким" техническим деталям. В противном случае даже хорошие программисты, перешедшие с Java на C++ будут писать проблемный код. Типа вот такого:
void do_something()
{
int * params = new int[ 10 ];
....
}
class connection_info_t
{
private :
std::string & m_data_source;
...
public :
...
std::string data_source() { return m_data_source; }
...
};
connection_t *
connect( connection_info_t * info );
connection_t *
establish_connection( std::string data_source, std::string user, std::string password )
{
...
connection_t * c = connect( new connection_info_t( data_source, user, password ) );
...
return c;
}
И проблема заключается именно в том, чтобы научить человека заниматься такими мелочами. А это действительно проблема, т.к. лично я время от времени, после очередного указания на подобные ляпы, слышал в ответ: "Да нафига этот C++ вообще нужен, если я о таких мелочах думать должен! Об этом компилятор и run-time заботиться должны!". Вот именно такой сдвиг в психологии Java программистов и не дает многим из них нормально перейти на C++.
E>>И еще хорошо, если человек действительно молодой, не очень опытный, понимающий это и без понтов.
VD>С понтами скорее те кто считает С++-ников высшей кастой. Понимать здесь точно нечего.
С понтами -- это те, кто говорят: "Да дайте любую задачу, я вам щас ее за 5 минут!". А после пятиминутного махания шашкой оказывается, что решения, в лучшем случае, приходится ждать в два раза дольше намеченного срока.
E>> И ведь стимула к изучению C++, как такового, нет. Ну нужно освоить C++ для того, чтобы работать в нашей конторе, а вот в соседней конторе он на уже известной ему Java будет прямо сейчас получать устраивающую его зарплату. Так зачем же прилагать лишние усилия, если результат представляется одинаковым?
VD>Не льсти себе. Нет у вас никакой касты.
Покажи мне, пожалуйста, где я говорил о нашей кастовости? Или у тебя после перехода с C++ на C# комплекс возник? Вроде того, что раньше, в бытность C++ программистом, ты был в касте, а сейчас уже нет. Абыдно, да? ((C) Ю.Никулин)
VD>Ява же просто терпимее относится к ошибкам. И там где ламер (которые и бывают обычно дешевыми) насажает в С++ ошибок которые потом бригадов за пол года не вычистить, то на яве он просто сделает не эффектинове и кривое решение которое с помощью рефакторинга и какой-то матери получится хоть как-то запустить.
Так об этом же я и говорю.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>И все же дело не в мухах. Лично я предпочту более длинный, но более понятный код. Не же ли хакирский (в лучшем смысле этого слова) выверт укладывающий 5 строк в одну. В конечном итоге грамотно написанный код все равно сведется к некой функции или классу который скроет от меня все эти 5 (500 или сколько угодно) строк и предоставит мне удобную абстракцию.
Дело в том, что Lisp (вроде бы) позволяет без особых проблем заложить в абстракцию то, что (например) в C++ абстрагировать либо совсем невозможно, либо можно, но очень неудобно (реализации и/или в использовании).
Пример — boost::spirit, в частности, его closures (если что — это не то же, что closures в Лиспе). Они полезны, без них было бы сложнее жить — но они так криво описываются...
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>И эта же нацеленность на компенсацию некачественного кода и помощь новичкам является их слабостью, т.к. в погоне за простотой они урезают возможности, которые могли бы оказаться полезными более квалифицированному программисту, а иногда, организуя "защиту от дурака" теряют в выразительности, которая могла бы пригодиться для более точного контроля, чем встроенный. Вот такая диалектика, понимаешь, получается...
Ответ не верный. Эти платформы меньше страдают от некачественного кода не потому, что они менее гибкие, а потому что проблема, возникшая из-за ошибок программиста вычисляется значительно быстрее, и как правило сразу точно известно почему и кто виноват. Т.е. для определения кто есть ху мне не нужно копаться в исходниках и искать косяки, достаточно глянуть на стек-трейс.
AndrewVK wrote:
> ПК>И эта же нацеленность на компенсацию некачественного кода и помощь > новичкам является их слабостью, т.к. в погоне за простотой они урезают > возможности, которые могли бы оказаться полезными более > квалифицированному программисту, а иногда, организуя "защиту от > дурака" теряют в выразительности, которая могла бы пригодиться для > более точного контроля, чем встроенный. Вот такая диалектика, > понимаешь, получается... > Ответ не верный. Эти платформы меньше страдают от некачественного кода > не потому, что они менее гибкие, а потому что проблема, возникшая > из-за ошибок программиста вычисляется значительно быстрее, и как > правило сразу точно известно почему и кто виноват.
В том-то и дело, что ошибки программиста могут быть замечены намного
позднее.
> Т.е. для определения кто есть ху мне не нужно копаться в исходниках и > искать косяки, достаточно глянуть на стек-трейс.
Да? А вы знаете, что в core-файлах вдобавок к stack-trace'ам всех тредов
еще сохраняются и стековые фреймы (или даже полное состояние
приложения)? По dmp-файлам мне лично отлаживать намного приятнее, чем по
одиночному stack-trace'у.
Здравствуйте, Cyberax, Вы писали:
C>Да? А вы знаете, что в core-файлах вдобавок к stack-trace'ам всех тредов C>еще сохраняются и стековые фреймы (или даже полное состояние C>приложения)? По dmp-файлам мне лично отлаживать намного приятнее, чем по C>одиночному stack-trace'у.
По стектрейсу обычно отлаживаться не надо, и без отладчика все понятно. Дело не в самом стектрейсе, а в том что вероятность наведенной ошибки мала, грохается обычно в непосредственной близости от косяка.
епрст, ну когда научимся читать оппонентов малость тщательнее?
Цикл чего, простите, длиннее? Цикл внесения серьезных изменений — да, длиннее. Цикл разработки по "устаканившемуся" ТЗ — ничуть.
Без уточнения, цикл чего именно имеется в виду — спорить бессмысленно. На тот момент, когда шла разработка, была важна скорость изменения функциональности.
Если же ТЗ вполне устоялось, то скорость разработки на С++ не уступит ни Java ни C#. А если проект достаточно большой, то может существенно обогнать.
----------
"Достаточно большой" в данном контексте означает содержание большой доли функциональности, которой нет во всяких фреймворках.
AndrewVK wrote:
> C>Да? А вы знаете, что в core-файлах вдобавок к stack-trace'ам всех > тредов > C>еще сохраняются и стековые фреймы (или даже полное состояние > C>приложения)? По dmp-файлам мне лично отлаживать намного приятнее, > чем по > C>одиночному stack-trace'у. > По стектрейсу обычно отлаживаться не надо, и без отладчика все > понятно. Дело не в самом стектрейсе, а в том что вероятность > наведенной ошибки мала, грохается обычно в непосредственной близости > от косяка.
Вот как раз хэндлинг NullPointerException'а и может навести ошибку, так
как очень часто NPE просто скрывает баги в коде.
Здравствуйте, Cyberax, Вы писали:
C>Вот как раз хэндлинг NullPointerException'а и может навести ошибку, так C>как очень часто NPE просто скрывает баги в коде.
Это зависит какой хендлинг. Если он после себя оставляет следы, например ввиде записей в логе, то ничего не скрывается. А за пустой catch в 99% случаев надо расстреливать на месте.
и погляди о чем там идет речь. Мне совершенно по фигу правильность или не правильность рассуждений о "длиннах". Там сделан вывод о том что от А отказались в пользу Б так как В имеет приемущество. Все! Точка! Если ты действительно не всилах понять алогичности подобных рассуждений, то обсуждать больше нечего.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, pvgoran, Вы писали:
P>Дело в том, что Lisp (вроде бы) позволяет без особых проблем заложить в абстракцию то, что (например) в C++ абстрагировать либо совсем невозможно, либо можно, но очень неудобно (реализации и/или в использовании).
В любом ЯП можно абстрагироваться от любой проблемы. Для этого достаточно банальных процедур. Так что не нужно рассказывать сказки.
P>Пример — boost::spirit, в частности, его closures (если что — это не то же, что closures в Лиспе). Они полезны, без них было бы сложнее жить — но они так криво описываются...
boost::spirit — это LL(1)-парсер. Про то что в нем есть closures я никогда не слышал.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>В том-то и дело, что в C++ недостаточно "просто уметь нормально программировать". Кроме умения нормально проектировать решения в C++ требуется еще довольно много внимания уделять "мелким" техническим деталям.
Это включается в понятие "просто уметь нормально программировать на С++". Ну, и по совместительству является недостатком языка усложняющим разработку.
E> В противном случае даже хорошие программисты, перешедшие с Java на C++ будут писать проблемный код.
С++-программисты недавно перешедшие на C# тоже делают не мало глупостей. Виной тому не какая-то эллитарность C#, а банальные привычки и попытка применять паттерны которые были нормальными в другой технологии, но бессмысленны или вредны в этой.
E> Типа вот такого: E>
E>И проблема заключается именно в том, чтобы научить человека заниматься такими мелочами.
Научи этом "матерых С++-ников" с этого сайта. У нас в половине статей delete или разные вариации free используются направо и налево. Вот, например, третья же статья в поиске по статьям выдала: http://rsdn.ru/article/patterns/singleton.xml
Что будет при исключении думаю ты и сам понимашь. И таких случаев море.
E> А это действительно проблема, т.к. лично я время от времени, после очередного указания на подобные ляпы, слышал в ответ: "Да нафига этот C++ вообще нужен, если я о таких мелочах думать должен! Об этом компилятор и run-time заботиться должны!". Вот именно такой сдвиг в психологии Java программистов и не дает многим из них нормально перейти на C++.
Интересно, а какие задачи вы заставляете решать на С++ бывших Явщиков?
VD>>С понтами скорее те кто считает С++-ников высшей кастой. Понимать здесь точно нечего.
E>С понтами -- это те, кто говорят: "Да дайте любую задачу, я вам щас ее за 5 минут!". А после пятиминутного махания шашкой оказывается, что решения, в лучшем случае, приходится ждать в два раза дольше намеченного срока.
10 минут?
E>Покажи мне, пожалуйста, где я говорил о нашей кастовости?
Ты постоянно подчеркивашь какое-то различие между С++-программистами и другими. И найти их сложнее. И то что деньги он получит большие за работу на Яве тебя почему-то удивляет. И вообще — это сквозит во всех твоих, да и не только твоих, словах.
E> Или у тебя после перехода с C++ на C# комплекс возник?
У меня возникает раздражение когда я вижу рассуждения о некотором превосходстве С++-программистов.
E> Вроде того, что раньше, в бытность C++ программистом, ты был в касте, а сейчас уже нет. Абыдно, да? ((C) Ю.Никулин)
Я не считаю, что качество программиста зависит от многих факторов. И среди этих факторв есть такой как количество и разнообразие изученных языков и технологий, но нет конкретного пункта про С++. Более того лдей программирующих на Дельфи или VB, но, при этом , отлично знающих, к пример Ocaml я считаю потенциально более развитыми чем тех кто знает С/С++.
VD>>Ява же просто терпимее относится к ошибкам. И там где ламер (которые и бывают обычно дешевыми) насажает в С++ ошибок которые потом бригадов за пол года не вычистить, то на яве он просто сделает не эффектинове и кривое решение которое с помощью рефакторинга и какой-то матери получится хоть как-то запустить.
E>Так об этом же я и говорю.
Ты говоришь не о том. Еще раз. Класс программиста не зависит от того изучил он С++ или Яву. И то что Ява — это типобезопасный язык без ужасного наследия не делает автоматом даунами всех кто на ней пишет. Ты же постоянно пыташся доказать обратное. У тебя С++-программист это особенный человек обладающий способностями суперменов.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
Ш>>> надувательские языки, они не столько помогают бороться с ошибками, Ш>>> сколько их банально скрывают.
V>> Примеры скрытия ошибок языком можно поглядеть?
ПК>Легко. Исключение в finally во время обработки уже выброшенного исключения. ПК>Первое при этом потеряется. Одна ошибка уже скрыта
Эдак можно и до радио докапаться. В catch тоже исключения ведь могут быть.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>P.S.
V>>> Примеры скрытия ошибок языком можно поглядеть?
ПК>> Легко. Исключение в finally во время обработки уже выброшенного ПК>> исключения. Первое при этом потеряется. Одна ошибка уже скрыта
ПК>Кстати, еще один пример
: вместо исправления ситуации ошибку ПК>"замазали" требованием поддержки множественных вызовов Dispose. При этом ПК>сами же признают, что ошибки таким макаром прячутся: ПК>
ПК>Though it is legal to invoke Dispose more than once, if this happens it may indicate the presence
ПК>of a bug since such an object is usually rendered otherwise unusable after the first Dispose invocation.
Я вижу только безграмотную реализацию паттерна. Если в базовом классе, к примеру в Form, реализован паттерн Dispose и сделано это с помощью создания виртуального метода:
protected virtual void Dispose(bool disposing)
то нефига вызывать этот метод вручную. Нужно просто переопределять его и менять реакцию (если оно вообще нужно). Вот твой пример переписанный без ошибок:
using System;
namespace cs_test
{
class C : IDisposable
{
// Реализуем Dispose Pattern, как завещает спецификация.private bool disposed = false;
~C()
{
Console.WriteLine("~C");
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
Console.WriteLine("C.Dispose({0})", disposing);
if (!this.disposed)
{
if (disposing)
{
// TODO: Dispose managed resources.
}
// TODO: Dispose unmanaged resources here.
}
disposed = true;
}
}
class C1 : C
{
private bool disposed = false;
protected override void Dispose(bool disposing)
{
Console.WriteLine("C1.Dispose({0})", disposing);
if (!this.disposed)
{
base.Dispose(disposing);
}
disposed = true;
}
}
class C2 : C1
{
private bool disposed = false;
protected override void Dispose(bool disposing)
{
Console.WriteLine("C2.Dispose({0})", disposing);
if (!this.disposed)
{
base.Dispose(disposing);
}
disposed = true;
}
}
class Program
{
static void Main(string[] args)
{
C2 c = new C2();
GC.Collect();
GC.WaitForPendingFinalizers();
}
}
}
Здравствуйте, VladD2, Вы писали:
P>>Дело в том, что Lisp (вроде бы) позволяет без особых проблем заложить в абстракцию то, что (например) в C++ абстрагировать либо совсем невозможно, либо можно, но очень неудобно (реализации и/или в использовании).
VD>В любом ЯП можно абстрагироваться от любой проблемы. Для этого достаточно банальных процедур. Так что не нужно рассказывать сказки.
Однако ж в C# вместо абстракции при помощи процедур пришлось вводить ключевое слово foreach. Или итераторы C#2 те же.
Здравствуйте, VladD2, Вы писали:
VVD>РСДН изначально был С++-ным сайтом. Почти все кто стоял у его истоков (и даже я) был С++-ником до мозга костей. Любое голосование тип "Ххх sv. C++" на этом сайте несколько лет назад был бы проигран с разгромным счетом. А теперь дивись
И что это доказывает? Привлекательность "направления .NET/C#" для... для кого? Или попросту то, что те, для кого привлекателен C# чаще заглядывают в "голосования"?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
: вместо исправления ситуации ошибку "замазали" требованием поддержки множественных вызовов Dispose. При этом сами же признают, что ошибки таким макаром прячутся: > ПК>
> ПК>Though it is legal to invoke Dispose more than once, if this happens it may indicate the presence
> ПК>of a bug since such an object is usually rendered otherwise unusable after the first Dispose invocation.
> ПК>
> Я вижу только безграмотную реализацию паттерна. <...>
Это да, ошибку я сделал.
Но при этом ситуация еще хуже получается: у ребят вообще не было вразумительной технической причины чтобы вводить такое требование, замазывающее ошибки пользователей?
> От таких ошибок не застрахует ни один язык. Это банальное не понимание паттерна.
Имхо, просто паттерн несколько хрупковатый для ручной реализации получился
VladD2,
> ПК> Легко. Исключение в finally во время обработки уже выброшенного исключения. Первое при этом потеряется. Одна ошибка уже скрыта
> Эдак можно и до радио докапаться. В catch тоже исключения ведь могут быть.
Могут. Это одна из причин, почему catch лучше для освобождения ресурсов не использовать. Но с catch ситуация все же немножко лучше: туда мы попадаем только в случае обработки исключения, а в finally — всегда. Соответственно, в finally особенно сложно писать код, который бы не глотал исключения. И реально исключения зачастую глотаются. Собственно, в этом разница с C++, где легче получить abort(), чем на практике "проглотить" исключение.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И что это доказывает? Привлекательность "направления .NET/C#" для... для кого? Или попросту то, что те, для кого привлекателен C# чаще заглядывают в "голосования"?
Это пказывает, что даже С++-программисты (которые как раз значительно чаще заглядывают в голосования, как показывает практика) и сами осознают большую перспективность дотнета нежели нэйтив-С++-а. Ну, или то что относительная популярность дотнета ростет.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Однако ж в C# вместо абстракции при помощи процедур пришлось вводить ключевое слово foreach.
foreach — это синтаксический сахар позволяющий быть менее многословным для выражения паттерна перебора. Абстракцией он не является. Абстракцией является интерфейс IEnumerable и IEnumerable<T>. Они кстати, я взык не вмонтированы.
ANS>Или итераторы C#2 те же.
Ты путаешь термин "абстракция" и "простота реализации". Итераторы — это упрощение реализации абстракци IEnumerable<T>/IEnumerable.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это пказывает, что даже С++-программисты (которые как раз значительно чаще заглядывают в голосования, как показывает практика) и сами осознают большую перспективность дотнета нежели нэйтив-С++-а. Ну, или то что относительная популярность дотнета ростет.
Нет. Это показывает, что за одинаковые деньги люди скорее будут работать на C# чем на Си++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это да, ошибку я сделал.
ПК>Но при этом ситуация еще хуже получается: у ребят вообще не было вразумительной технической причины чтобы вводить такое требование, замазывающее ошибки пользователей?
Это какое мое требование замазывает ошибки?
ПК>Имхо, просто паттерн несколько хрупковатый для ручной реализации получился
Там ровно одна ошибка. Второй случай, то просто упрощенный вариант. И это на 2.5 метра кода две трити которого писали не самые квалифицированные специалисты. Не думаю, что эта статистика говорит о том, что этот паттерн является реальной проблемой. Тот же foreach куда чаще используется, но почему-то тебя он не волнует, хотя ошибки вроде выхода за границу массива бывают куда чаще.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Могут. Это одна из причин, почему catch лучше для освобождения ресурсов не использовать.
Ну, и чем тогда отличие C# в замазывании ошибок от С++.
ПК> Но с catch ситуация все же немножко лучше: туда мы попадаем только в случае обработки исключения, а в finally — всегда.
Ну, то-есть в finally мы не всегда потеряем информацию об исключении. Серьезная проблема однако.
ПК> Соответственно, в finally особенно сложно писать код, который бы не глотал исключения. И реально исключения зачастую глотаются.
Зачастую? Можно статистику? Я на своем веку еще не разу с такой ошибкой не сталкивался.
ПК> Собственно, в этом разница с C++, где легче получить abort(), чем на практике "проглотить" исключение.
Большое достоинство языка... простота получения вылета.
ЗЫ
И все же хотелось бы или услышать рельные обоснования утверждении о том, что Шарп замазывает ошибки, или признание не правоты.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> при этом ситуация еще хуже получается: у ребят вообще не было вразумительной технической причины чтобы вводить такое требование, замазывающее ошибки пользователей?
> Это какое мое требование замазывает ошибки?
Не твое, а спецификации. Требование поддержки множественных вызовов Dispose. (Множественные вызовы Finalize, обусловленные "воскрешением", не считаем).
> ПК> Имхо, просто паттерн несколько хрупковатый для ручной реализации получился
...
> Там ровно одна ошибка. Второй случай, то просто упрощенный вариант.
Ага, похоже, во втором случае ты ошибку просто не заметил... Feature тоже реализует Dispose(), но Forum, являясь наследником Feature, Feature.Dispose не вызывает.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ага, похоже, во втором случае ты ошибку просто не заметил... Feature тоже реализует Dispose(), но Forum, являясь наследником Feature, Feature.Dispose не вызывает.
Ах в этом смысле. Да, действительно. Нужно было позвать base.Dispose(). Это АВК был не прав.
Вот только такую ошибку и без всяких паттернов можно залепить.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Ага, похоже, во втором случае ты ошибку просто не заметил... Feature тоже реализует Dispose(), но Forum, являясь наследником Feature, Feature.Dispose не вызывает.
> Ах в этом смысле. Да, действительно. Нужно было позвать base.Dispose(). Это АВК был не прав. > > Вот только такую ошибку и без всяких паттернов можно залепить.
Интересно, как можно не вызвать деструктор базового класса?..
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
E>>В том-то и дело, что в C++ недостаточно "просто уметь нормально программировать". Кроме умения нормально проектировать решения в C++ требуется еще довольно много внимания уделять "мелким" техническим деталям.
VD>Это включается в понятие "просто уметь нормально программировать на С++".
Вначале мной было сказано:
А вот с C++-ом ситуация сложнее. Для того, чтобы нормально программировать на C++ и включится в большой, уже идущий проект, необходим уровень выше среднего.
На что ты мне возразил:
Полная ерунда. Чтобы нормально программировать нужно просто уметь нормально программировать. И человек поверхносно знающий С++ ничем не будет отличаться от человека поверхносно знающего C#.
Я же тебе говорю, что умение нормально программировать вообще в C++ оказывается недостаточно, поскольку есть масса мелких технических заморочек, которые постоянно нужно принимать во внимание. И вот тут ты мне объясняешь, что "нормальное программирование" + знание этих мелких деталей и есть "нормальное программирование на C++". Так ведь я об этом сразу сказал. И сразу сказал, что специалистов, которые "нормально программируют на C++" мало, и искать их, в нашей провинции, нужно днем с огнем. Или самим воспитывать из того, что есть.
VD> Ну, и по совместительству является недостатком языка усложняющим разработку.
С этим полностью согласен.
E>> В противном случае даже хорошие программисты, перешедшие с Java на C++ будут писать проблемный код.
VD>С++-программисты недавно перешедшие на C# тоже делают не мало глупостей. Виной тому не какая-то эллитарность C#, а банальные привычки и попытка применять паттерны которые были нормальными в другой технологии, но бессмысленны или вредны в этой.
Опять повторю, про элитарность (в смысле того, что C++ программист круче всех и выше всех остальных на две, да нет, на три головы) я не говорил. Я говорил про недостаточное количество толковых C++ программистов. Если недостаточное количество для тебя эквивалентно элитарности, то это твои личные проблемы мировосприятия.
E>>И проблема заключается именно в том, чтобы научить человека заниматься такими мелочами.
VD>Научи этом "матерых С++-ников" с этого сайта. У нас в половине статей delete или разные вариации free используются направо и налево. Вот, например, третья же статья в поиске по статьям выдала: VD>http://rsdn.ru/article/patterns/singleton.xml
VD>Что будет при исключении думаю ты и сам понимашь. И таких случаев море.
Боюсь, что если человек счел себя достаточно граммотным в C++, чтобы опубликовать статью с подобными ляпами, то здесь есть всего две дороги: либо сесть за изучение классиков типа Страуструпа, Александреску и Саттера, либо перейти на язык с GC. Думаю, что второй вариант гораздо проще.
E>> А это действительно проблема, т.к. лично я время от времени, после очередного указания на подобные ляпы, слышал в ответ: "Да нафига этот C++ вообще нужен, если я о таких мелочах думать должен! Об этом компилятор и run-time заботиться должны!". Вот именно такой сдвиг в психологии Java программистов и не дает многим из них нормально перейти на C++.
VD>Интересно, а какие задачи вы заставляете решать на С++ бывших Явщиков?
Да вот, пытались делать все свои проекты на нашем SObjectizer-е. В общем случае получалось средненько. И по объективным, и по субъективным причинам. Но переучить явщиков как раз не получилось. Поэтому теперь явщики программируют на Яве, а C++-ники на C++.
VD>>>С понтами скорее те кто считает С++-ников высшей кастой. Понимать здесь точно нечего.
E>>С понтами -- это те, кто говорят: "Да дайте любую задачу, я вам щас ее за 5 минут!". А после пятиминутного махания шашкой оказывается, что решения, в лучшем случае, приходится ждать в два раза дольше намеченного срока.
VD>10 минут?
Это было бы смешно, если бы не было так грусно. Обычно бывает так: я приблизительно оцениваю, что на решение задачи требуется неделя. Поскольку у меня есть склонность слишком оптимистично занижать сроки, я делаю поправку и декларирую две недели. Обычно, в лучшем случае, решение приносят через месяц.
E>>Покажи мне, пожалуйста, где я говорил о нашей кастовости?
VD>Ты постоянно подчеркивашь какое-то различие между С++-программистами и другими. И найти их сложнее.
Не какое-то, а вполне конкретное. В C++, в отличии от Java или Ruby, на которых мне довелось попрограммировать, очень много внимания нужно уделять мелким техническим деталям (которые, при их игнорировании становятся большими занозами в заднице). И специалистов, которые считают нормальным такое внимание к этим деталям действительно становятся все меньше и меньше. Чему лично я вижу два объяснения.
Во-первых, программистов, которые начинали программировать лет 17-15-10 назад (т.е. тем, кому сейчас за тридцать), когда у C++ реальной альтернативы еще не было, становится все меньше и меньше. Просто потому, что с возрастом от программирования устаешь и переходишь в другие области (системный архитектор, технический писатель, менеджер, владелец фирмы, а то и вообще, фермер). Программировать остаются только те, кто действительно от этого фанатеет, либо кто на большее-то и не способен.
Во-вторых, сейчас C++ уже не мейнстрим. Это слишком сложный язык. На его изучение нужно тратить слишком много времени. А тратить много времени сейчас не любят. Начинающему специалисту гораздо проще освоить Java, C#, VB, Python и найти оплачиваемую работу согласно своему уровню подготовки не тратя лишнее время на такую сложную штуку, как C++.
VD>И то что деньги он получит большие за работу на Яве тебя почему-то удивляет.
Я не говорил, что меня это удивляет. Я привел еще одну причину, почему человеку, не знающему C++, нет стимула изучать C++.
VD> И вообще — это сквозит во всех твоих, да и не только твоих, словах.
Я у себя такого не замечал. А если ты между моих строк видишь какие-то намеки на элитарность, то ничего поделать не могу. "У нас свобода сновидений".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Во-первых, программистов, которые начинали программировать лет 17-15-10 назад (т.е. тем, кому сейчас за тридцать), когда у C++ реальной альтернативы еще не было, становится все меньше и меньше. Просто потому, что с возрастом от программирования устаешь и переходишь в другие области (системный архитектор, технический писатель, менеджер, владелец фирмы, а то и вообще, фермер). Программировать остаются только те, кто действительно от этого фанатеет, либо кто на большее-то и не способен.
+1
Родной язык это тот, на котором ты думаешь, имхо, определенному слою программеров просто повезло родится вовремя и расти одновременно. Типа ух ты — ввели ключевое слово mutable — ну теперь то точно за..сь!
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Родной язык это тот, на котором ты думаешь, имхо, определенному слою программеров просто повезло родится вовремя и расти одновременно. Типа ух ты — ввели ключевое слово mutable — ну теперь то точно за..сь!
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Здравствуйте, eao197, Вы писали:
E>>Во-первых, программистов, которые начинали программировать лет 17-15-10 назад (т.е. тем, кому сейчас за тридцать), когда у C++ реальной альтернативы еще не было, становится все меньше и меньше. Просто потому, что с возрастом от программирования устаешь и переходишь в другие области (системный архитектор, технический писатель, менеджер, владелец фирмы, а то и вообще, фермер). Программировать остаются только те, кто действительно от этого фанатеет, либо кто на большее-то и не способен.
ЮБ>+1
ЮБ>Родной язык это тот, на котором ты думаешь, имхо, определенному слою программеров просто повезло родится вовремя и расти одновременно. Типа ух ты — ввели ключевое слово mutable — ну теперь то точно за..сь!
А я еще помню, как ввели try/catch, и template.
Действительно повезло родится вовремя.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, pvgoran, Вы писали:
P>>Дело в том, что Lisp (вроде бы) позволяет без особых проблем заложить в абстракцию то, что (например) в C++ абстрагировать либо совсем невозможно, либо можно, но очень неудобно (реализации и/или в использовании).
VD>В любом ЯП можно абстрагироваться от любой проблемы. Для этого достаточно банальных процедур. Так что не нужно рассказывать сказки.
Вы меня удивляете. Сильно. Не знаю даже, что сказать... Варианты на выбор:
1. Если "для всего" достаточно процедур — может, будем на ассемблере программировать? Там call и ret есть.
2. Т.е. тот же ООП как инструмент абстракции излишен?
3. Возьмем в качестве примера operator << из стандартной библиотеки. Как Вы предлагаете с помощью процедур (например, используя C или Pascal) построить аналогичную (решающую ту же задачу) абстракцию?
P>>Пример — boost::spirit, в частности, его closures (если что — это не то же, что closures в Лиспе). Они полезны, без них было бы сложнее жить — но они так криво описываются...
VD>boost::spirit — это LL(1)-парсер.
Spirit is an object-oriented recursive-descent parser generator framework [ etc ]
Насколько я понимаю, это означает, что он может работать как минимум с LL(k)-грамматиками.
VD> Про то что в нем есть closures я никогда не слышал.
Spirit — достаточно большая и сложная библиотека, там много чего есть. Closures я лично использовал.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Однако ж в C# вместо абстракции при помощи процедур пришлось вводить ключевое слово foreach.
VD>foreach — это синтаксический сахар позволяющий быть менее многословным для выражения паттерна перебора. Абстракцией он не является. Абстракцией является интерфейс IEnumerable и IEnumerable<T>. Они кстати, я взык не вмонтированы.
Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией, и как его реализовать на C#1.
ANS>>Или итераторы C#2 те же.
VD>Ты путаешь термин "абстракция" и "простота реализации". Итераторы — это упрощение реализации абстракци IEnumerable<T>/IEnumerable.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>Ты путаешь термин "абстракция" и "простота реализации". Итераторы — это упрощение реализации абстракци IEnumerable<T>/IEnumerable.
ANS>Влад, абстракция без простоты это фигня какая то.
А теперь ты путаешь "простоту использования" и "простоту реализации" Это вообще вещи обычно обратно зависимые.
и погляди о чем там идет речь. Мне совершенно по фигу правильность или не правильность рассуждений о "длиннах". Там сделан вывод о том что от А отказались в пользу Б так как В имеет приемущество. Все! Точка! Если ты действительно не всилах понять алогичности подобных рассуждений, то обсуждать больше нечего.
Не надо вырывать строки из контекста, а то действительно ерунда выходит. Там шла речь примерно о таком:
От подхода А отказались в пользу подхода B (приводились примеры 2-х конкретных реализаций подхода B: языки С и D), в конечном счете все-равно выбрали именно подход B, используя конкретную его реализацию в языке E. Ну вот показалось им, что использовать реализацию подхода B с помощью E лучше для условий их задачи, чем с помощью C и D
Я лишь добавил пару комментов к их выбору... Что у тебя не складывается, по прежнему не понятно.
Здравствуйте, Cyberax, Вы писали:
C>mihoshi wrote:
>> C>Студенты плевались сильно и качество их программ было на очень низком >> C>уровне (они их писал в паскалевском стиле). Несколько раз было >> прикольно >> C>- ко мне по аське обращались с просьбами сделать практические задания, >> C>которые я же и помогал сочинять. >> Это нормальная реакция при использовании нового инструмента.
C>Ну так спросили о мнении людей о С++, которые с ним знакомы всего пару C>месяцев. Потом спросили мнение людей о Лиспе — я ответил.
>> Достоинствами человек пользоваться не умеет, а любые отличия от >> привычного видит как недостаток. Если не учить правильно обращаться с >> инструментом и не требовать этого от учеников, то толку от этого не будет.
C>Да, но некоторым студентам понравилось такое извращение, как Refal C>(крестики-нолики на Refal'е — это сильно). Лисп не понравился никому — а C>это тоже показатель.
Не знаю — когда нам LISP переподавали — мне он сразу понравился.
Вот когда я с паскаля на с++ перелазил — плющило меня конкретно.
А сейчас С++ — мой второй язык после русского.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
и погляди о чем там идет речь. Мне совершенно по фигу правильность или не правильность рассуждений о "длиннах". Там сделан вывод о том что от А отказались в пользу Б так как В имеет приемущество. Все! Точка! Если ты действительно не всилах понять алогичности подобных рассуждений, то обсуждать больше нечего.
V>Не надо вырывать строки из контекста, а то действительно ерунда выходит. Там шла речь примерно о таком: V>От подхода А отказались в пользу подхода B (приводились примеры 2-х конкретных реализаций подхода B: языки С и D), в конечном счете все-равно выбрали именно подход B, используя конкретную его реализацию в языке E. Ну вот показалось им, что использовать реализацию подхода B с помощью E лучше для условий их задачи, чем с помощью C и D
Извини, но мне кажется ты слишком сильно додумываешь написанное другими. По этому и получается, что ты рассуждашь о вещах которых нет в природе. Вот и с моими словами тоже самое. Ты споришь не с ними, а сам с собой. Я в общем-то не против. Но я вряд ли буду тебе полезен.
V>Я лишь добавил пару комментов к их выбору...
А они тебя просили?
V>Что у тебя не складывается, по прежнему не понятно.
У меня? Ты сейчас с кем и о чем разговаривашь?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Кодёнок, Вы писали:
Кё>Главная идея такая, что дальнейшее развитие самых популярных языков (С++, C#, Java) в конце концов сделает из них Лисп
Не. С++ не сдастся. Его очень хорошо оберегают от всякой заразы. В принципе правильно. Шаблоны есть? Есть! Больше ничего не нужно.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Я же тебе говорю, что умение нормально программировать вообще в C++ оказывается недостаточно, поскольку есть масса мелких технических заморочек, которые постоянно нужно принимать во внимание.
А я тебе говорю, что ты пыташся изобразить С++-ников как некую элиту. А на самом деле это не так. Нормально программировать нужно уметь для любого языка и любого проенкта. А вот хреновый программист действительно на С++ способен наплодить больше бед (по сравнению с типобезопасными языками).
E> И вот тут ты мне объясняешь, что "нормальное программирование" + знание этих мелких деталей и есть "нормальное программирование на C++".
Без знания особенностей инструмена нормального прогаммирования не выйдет. ПК впервые пытаясь написать код на C# мочил еще те перлы. А он у нас в верху топа.
E> Так ведь я об этом сразу сказал. И сразу сказал, что специалистов, которые "нормально программируют на C++" мало, и искать их, в нашей провинции, нужно днем с огнем. Или самим воспитывать из того, что есть.
Еще рез. В С++ просто страшнее последствия. Ловить баги за ламерами тяжелее. А проблемы от ламера будут везде.
E>Опять повторю, про элитарность (в смысле того, что C++ программист круче всех и выше всех остальных на две, да нет, на три головы) я не говорил. Я говорил про недостаточное количество толковых C++ программистов.
Это и есть признание С++ элитарным. Толковых программистов не хватает в принципе. И С++ тут не причем.
E>Боюсь, что если человек счел себя достаточно граммотным в C++, чтобы опубликовать статью с подобными ляпами, то здесь есть всего две дороги: либо сесть за изучение классиков типа Страуструпа, Александреску и Саттера, либо перейти на язык с GC. Думаю, что второй вариант гораздо проще.
Боюсь, что ты принципиально не понимашь ситуации. На этом воруме есть человек 5 С++-программистов которые понимают всю опасность С++ и осознают необходимость использовать только небольшой сабсэт этого языка затыкая его баги "умными" обертками. Остальные же ради экономии времени или еще ради чего нибудь спокойно плюют на это. При этом им ничего не мешает себя считать круче паравоза и даже с пренебрижением смотреть на остальных. Посмотри в мой профайл и поверь мне на слово. Я постоянно сталкиваюсь с подобным. Просто в последнее время С++-а стало заметно меньше. А так...
E>Да вот, пытались делать все свои проекты на нашем SObjectizer-е. В общем случае получалось средненько. И по объективным, и по субъективным причинам. Но переучить явщиков как раз не получилось. Поэтому теперь явщики программируют на Яве, а C++-ники на C++.
Я, к сожалению, снова в офлайне и по ссылка кликать мне тяжело. Нелья ли на пальцах обяснить область разрботки. Ну, там автоматизация бизнеса, создания инструментов для 3D-моделирования...
E>Это было бы смешно, если бы не было так грусно. Обычно бывает так: я приблизительно оцениваю, что на решение задачи требуется неделя. Поскольку у меня есть склонность слишком оптимистично занижать сроки, я делаю поправку и декларирую две недели. Обычно, в лучшем случае, решение приносят через месяц.
Коэффициент не верный. Даво известно, что слова программиста о сроках нужно уможать на 4. Но причем тут С++ и т.п.?
E>Не какое-то, а вполне конкретное. В C++, в отличии от Java или Ruby, на которых мне довелось попрограммировать, очень много внимания нужно уделять мелким техническим деталям (которые, при их игнорировании становятся большими занозами в заднице). И специалистов, которые считают нормальным такое внимание к этим деталям действительно становятся все меньше и меньше. Чему лично я вижу два объяснения.
Я как бы согласен с тем, что программируя на С++ ты большую часть времени расходуешь не продуктивно. Но это еще не значит, что хороший программист не сможет научиться это делать. Плеваться будет, но научится.
Я могу привести в пример себя. Кодируя на С++ я как бы спровлялся с этими проблемами. И даже не пробуя альтернативу свыкся с этим и не особо крехтел. Но попробовав эту самую алтернативу и вернувшись обратно к С++ я начал плеваться так же как твои явщики.
Кстати, школа С++ не прошла даром. Контроль ресурсов на using-е у меня уже в крови. Но я знаю кучу людей пришедших не с С++ которые точно так же отлично контролируют ресурсы using-ом. Так что...
E>Во-первых, программистов, которые начинали программировать лет 17-15-10 назад (т.е. тем, кому сейчас за тридцать), когда у C++ реальной альтернативы еще не было, становится все меньше и меньше.
Альтернативы были есть и будут. То же дельфи появилось более 10 лет назад. Ява, кстати, в следующем году тоже червонец отметит.
E>Во-вторых, сейчас C++ уже не мейнстрим.
Я плякаль. Что не скажешь лиш бы почувствовать себя элитой.
E> Это слишком сложный язык. На его изучение нужно тратить слишком много времени. А тратить много времени сейчас не любят. Начинающему специалисту гораздо проще освоить Java, C#, VB, Python и найти оплачиваемую работу согласно своему уровню подготовки не тратя лишнее время на такую сложную штуку, как C++.
Понимаеш ли. Твои слова про сложность С++ — это не правда. Как язык C# значительно сложнее. Он обладает куда большим объемом кострукций не говоря уже о их применении.
Сам С++ относительно простой язык. Сложно же в нем обходить грабли. Вот тут действительно нужно выроботать привычку использовать только безопасные паттерны. Ну, и сложно следить за теми самыми мелочами. Однако сложность использования и сложность продукта не коррелирую между собой. К примеру, телевизор очень не простой продукт, то использовать его может трех-летний ребенок.
E>Я у себя такого не замечал. А если ты между моих строк видишь какие-то намеки на элитарность, то ничего поделать не могу. "У нас свобода сновидений".
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией,
Переведи это на русский. И посторайся избавить этот перводо от слов вроде "кривым".
ANS> и как его реализовать на C#1.
Реализовать интерфейс?
ANS>Влад, абстракция без простоты это фигня какая то.
Здравствуйте, pvgoran, Вы писали:
P>1. Если "для всего" достаточно процедур — может, будем на ассемблере программировать? Там call и ret есть.
Абстрагироваться от реализации можно и на ассемблере. Но реализация будет сложнее.
P>2. Т.е. тот же ООП как инструмент абстракции излишен?
Почему? Во многих облостях он более удобен. Причем удобне для тех кто реализует абстракцию. Но если опять таки не говорить сложности реализации, то процедур для абстрагирования достаточно.
P>3. Возьмем в качестве примера operator << из стандартной библиотеки. Как Вы предлагаете с помощью процедур (например, используя C или Pascal) построить аналогичную (решающую ту же задачу) абстракцию?
Брать перегрузку операторов, да еще и изменение их семантического смысла, в даном случае, не стоит. К абстракции это отношения не имеет. Это всего лишь изменение синтаксиса языка. Причем основанное на безолаберном отношении языка к безопасности кода. Вывод же данных в поток или на консоль астрагирован в любом языке. Просто обычно это делается банальной процедурой.
P>Насколько я понимаю, это означает, что он может работать как минимум с LL(k)-грамматиками.
Воможно и LL(k). Сути дела это не менят.
P>Spirit — достаточно большая и сложная библиотека, там много чего есть. Closures я лично использовал.
Теме не кажется, что использование внутренних классов парсера несколько странно?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Долго думал, что лучше -- просто поставить минус и не отвечать, или же дать пространный ответ с возражениями по каждому из твоих утверждений. В результате вот что получилось.
Нельзя уметь нормально программировать на любом языке и для любой задачи. Нейронные сети на ПЛИСах, SQL запросы к БД, принятие решений на Прологе, поддержка стека протоколов GSM на ассемблере какой-нибудь SIM карточки, лексический и синтаксический анализ на Java, большие распределенные математические вычисления на Fortran-е, разрешение блокировок и оптимизация доступа к страницам БД на C/C++. Много ли найдется программистов, которые смогут научится нормально решать все эти задачи? А им это вообще нужно?
Рейтинги RSDN или чьи-либо профайлы для меня совершенно не являются показателем практической полезности программиста. Просто потому, что на практике один трудолюбивый середнячек с минимальным необходимым набором знаний спокойно делает супер-эрудитов/философов/экспертов/пр. -- он работает.
Процент толковых программистов в любой технологии действительно является константной величиной. Вероятно, описываемой законом 20/80. Проблема в том, что в количественном выражении 20% от ста тысяч будет гораздо меньше, чем 20% от миллиона. А когда ищещь спеца на работу важны как раз не абстрактные проценты, а те реальные единицы, которых нужно найти. Имхо, для C++ количественное выражение этих 20% в последнее время неуклонно снижается.
Недостаточное количество != элитарности. Я помню восьмидесятые годы и такие дефициты, как колбаса или туалетная бумага. Можно ли было считать туалетную бумагу или московскую колбасу элитой среди прочих товаров? Можно ли вообще оценить, более ли элитарна туалетная бумага, чем колбаса. Или же все наоборот. Имхо, элита может существовать в рамках какой-то одной категории. Например, среди C++ программистов точно есть своя элита. Так же, как в C#, Java или Lisp-е. Но я никогда не утверждал, что С++ программисты -- это элита по сравнению со всеми остальными программистами. Я лишь говорил где-то, что после C++ нет проблем перейти на Java или C# (я среди своих знакомых это видел, да и ты сам про это говоришь). А вот обратных примеров я не видел, но и не утверждаю, что это невозможно. Если, по твоему мнению, подобные мои высказывания являются пропагандированием элитарности C++ -- ну пусть так и будет, аминь. В конце-концов, лично я нуждаюсь в том, чтобы вокруг было больше С++. И если это кого-то подвигнет на изучение C++, то я говорю: "Уважаемые читатели форумов RSDN, изучайте C++, программируйте на C++ -- дайте себе шанс стать программистской элитой!".
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, pvgoran, Вы писали:
P>>1. Если "для всего" достаточно процедур — может, будем на ассемблере программировать? Там call и ret есть.
VD>Абстрагироваться от реализации можно и на ассемблере. Но реализация будет сложнее.
Сложнее будет не только реализация, но и использование.
P>>2. Т.е. тот же ООП как инструмент абстракции излишен?
VD>Почему? Во многих облостях он более удобен. Причем удобне для тех кто реализует абстракцию. Но если опять таки не говорить сложности реализации, то процедур для абстрагирования достаточно.
Удобнее для тех, кто реализует, и для тех, кто использует. Вроде object->do_it() удобнее писать, чем object->vtbl->do_it(object). (А если бы не было понятия указателей на функции — вообще бы ужас получился.)
P>>3. Возьмем в качестве примера operator << из стандартной библиотеки. Как Вы предлагаете с помощью процедур (например, используя C или Pascal) построить аналогичную (решающую ту же задачу) абстракцию?
VD>Брать перегрузку операторов, да еще и изменение их семантического смысла, в даном случае, не стоит. К абстракции это отношения не имеет. Это всего лишь изменение синтаксиса языка.
Ну, все-таки не изменение, а скорее уточнение синтаксиса. Причем имеющее своей целью именно предоставление пользователю абстракции операции вывода, работающей для расширяемого множества типов потоков и расширяемого множества типов данных.
VD>Причем основанное на безолаберном отношении языка к безопасности кода.
Это почему??
VD> Вывод же данных в поток или на консоль астрагирован в любом языке. Просто обычно это делается банальной процедурой.
Возьмем, к примеру, C. Его printf-семейство абстрагирует вывод, но "не дотягивают" до operator << (отсутствие безопасности типов, необходимость явно указывать тип выводимых данных, полное отсутствие расширяемости).
Кстати, складывается впечатление, что у нас существенно разные понятия об абстракции. Определимся с определениями?
P>>Насколько я понимаю, это означает, что он может работать как минимум с LL(k)-грамматиками.
VD>Воможно и LL(k). Сути дела это не менят.
А какая суть? А то контекст, в котором было упоминание Spirit, что-то затерялся.
P>>Spirit — достаточно большая и сложная библиотека, там много чего есть. Closures я лично использовал.
VD>Теме не кажется, что использование внутренних классов парсера несколько странно?
Это не внутренние классы, а вполне даже внешний интерфейс, описанный в документации.
Здравствуйте, VladD2, Вы писали:
ANS>>Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией,
VD>Переведи это на русский.
Какое именно слово тебе не понятно?
VD>И посторайся избавить этот перводо от слов вроде "кривым".
А вот в этом предложении есть непонятные мне слова.
ANS>> и как его реализовать на C#1.
VD>Реализовать интерфейс?
Поподробнее, пожалуйста.
ANS>>Влад, абстракция без простоты это фигня какая то.
VD>На это тебе очень хорошо ответил mihoshi
AndrewVK wrote:
> C>Вот как раз хэндлинг NullPointerException'а и может навести ошибку, так > C>как очень часто NPE просто скрывает баги в коде. > Это зависит какой хендлинг. Если он после себя оставляет следы, > например ввиде записей в логе, то ничего не скрывается. А за пустой > catch в 99% случаев надо расстреливать на месте.
Ты видел мегабайтные логи исключений, которые выбрасывает JBoss? Могу
показать. Разобраться в них не очень просто — простой assert в самом
месте ошибки намного больше помог бы.
AndrewVK wrote:
> C>Ты видел мегабайтные логи исключений, которые выбрасывает JBoss? > Не видел. Хотя сам JBoss видел. Никакими мегабайтами там и не пахнет.
Могу прислать. Такие логи получаются, когда выбрасывается исключение с
вложенностью уровней в 30-40 и распечатывается потом на каждом уровне.
Здравствуйте, Cyberax, Вы писали:
C>Могу прислать. Такие логи получаются, когда выбрасывается исключение с C>вложенностью уровней в 30-40 и распечатывается потом на каждом уровне.
Во-первых все равно на мегабайт не потянет, а во-вторых то, что на каждом уровне распечатывается одна и та же информация это проблемы JBoss, а не исключений.
Здравствуйте, VladD2, Вы писали:
VD>Извини, но мне кажется ты слишком сильно додумываешь написанное другими.
Да нет, ты просто потерял нить разговора и уже давно. Вся ветка была о "клевом подходе" к разработке веба на LISP в эпоху CGI.
VD>По этому и получается, что ты рассуждашь о вещах которых нет в природе. Вот и с моими словами тоже самое. Ты споришь не с ними, а сам с собой. Я в общем-то не против. Но я вряд ли буду тебе полезен.
blah-blah-blah...
для тебя С++ — как красная тряпка для быка, удивляться его использованию в реальных проектах ты способен (намерен?) бесконечно.
V>>Я лишь добавил пару комментов к их выбору...
VD>А они тебя просили?
А тебя?
V>>Что у тебя не складывается, по прежнему не понятно.
VD>У меня? Ты сейчас с кем и о чем разговаривашь?
Ты привел с потолка взятый аргумент, насчет длины цикла, который я и оспорил. Занятно уже то, что твой же аргумент никак не относился к твоей же логике.
Ты бы определился, что не так? То, что не взяли Java, несмотря на фичи, или PHP несмотря на удобство разработки? О важности продолжительности цикла разработки для них в настоящий момент никто, кроме тебя не говорил (это было важно в эпоху CGI и отсутствия каких-либо RAD-ср-в разработки под веб). Речь там шла о всяких фичах, которые вполне достижимы на С++.
Возвращаясь к теме, очевидно, что просто требования у них устаканились, и величина цикла разработки стала конечной, какая бы она не была, потому и речь о ней уже не шла. Три месяца там или пять — какая для Google сейчас разница, если при текущем количестве их пользователей технические характеристики программного продукта начинают играть весьма заметную роль?
-----------
Ну, а насчет манеры ведения беседы — присоединяюсь к многочисленным просьбам в твой адрес выражаться по существу. Я отвечал на вполне конкретные твои слова. Посты, типа "Ты о чем? Ты кому? Кто тебя просил? Сходи туда..." лучше не писать вовсе, ИМХО.
AndrewVK wrote:
> C>Могу прислать. Такие логи получаются, когда выбрасывается исключение с > C>вложенностью уровней в 30-40 и распечатывается потом на каждом уровне. > Во-первых все равно на мегабайт не потянет
Ну ладно, с мегабайтом я погорячился. Но вот килобайт на 100 — запросто.
> а во-вторых то, что на каждом уровне распечатывается одна и та же > информация это проблемы JBoss, а не исключений.
В том-то и дело, что иногда где-то в цепочке исключение магическим
образом преобразуется в другой тип из-за наведенных ошибок. И такое не
сразу можно заметить.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией,
VD>>Переведи это на русский.
ANS>Какое именно слово тебе не понятно?
Выделенно жирным.
VD>>И посторайся избавить этот перводо от слов вроде "кривым".
ANS>А вот в этом предложении есть непонятные мне слова.
Не включай дурака.
ANS>>> и как его реализовать на C#1.
VD>>Реализовать интерфейс?
ANS>Поподробнее, пожалуйста.
Что подробнее? В IEnumerator два метода и одно свойство. Их название говорят сами за себя. Плюсь в МСДН для особо одаренных целый рассказ о томк как реализовывать этот интерфейс.
ANS>>>Влад, абстракция без простоты это фигня какая то.
VD>>На это тебе очень хорошо ответил mihoshi
Точнее не захотел. Ты постоянно путашь понятия. Абстракцию с внешней формой. Простоту абстракции и сложность реализаци скрываемой за абстракцией. У меня складывается ощущение, что ты делашь это намеренно. Если это не так, то просто обратись к словарям. Ну, а если так, то давно пора завязывать этот разговор. Все равно путного ничего не выйдет.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, pvgoran, Вы писали:
P>Сложнее будет не только реализация, но и использование.
Ровно настолько насколько делать вызовы методов на ассемблере нежели на языке высокого уровня.
P>Удобнее для тех, кто реализует, и для тех, кто использует. Вроде object->do_it() удобнее писать, чем object->vtbl->do_it(object). (А если бы не было понятия указателей на функции — вообще бы ужас получился.)
Не нужно привлекать сюда заморочки КОМ-а. На С можно писать и так:
do_it(object);
Это конечно не винец творения, но более чем приемлемо.
P>Ну, все-таки не изменение, а скорее уточнение синтаксиса.
Нет, это именно изменение. Только конечно не синтаксиса, а семантики. Но это уже не важно.
P> Причем имеющее своей целью именно предоставление пользователю абстракции операции вывода, работающей для расширяемого множества типов потоков и расширяемого множества типов данных.
Нда. Ну, и чем:
stdхзч << i;
абстрактнее чем:
print(i);
VD>>Причем основанное на безолаберном отношении языка к безопасности кода.
P>Это почему??
Потому что в оригинале << это побитовый сдвиг влево. Плюс используется ошибка языка допускающая вычисления значений без присвоения их в переменную или передачи в качестве параметра.
P>Возьмем, к примеру, C. Его printf-семейство абстрагирует вывод, но "не дотягивают" до operator << (отсутствие безопасности типов, необходимость явно указывать тип выводимых данных, полное отсутствие расширяемости).
Чушь какая-то причем тут безопасность типов? Господа, отделяйте мухи от котлет.
Отсуствие расширяемости тоже звучит забавно. Создай новую процедуру и делай в ней все что хочешь.
P>Кстати, складывается впечатление, что у нас существенно разные понятия об абстракции. Определимся с определениями?
Нет, проблем — Abstraction (computer science)
P>А какая суть? А то контекст, в котором было упоминание Spirit, что-то затерялся.
Суть в том, что это не библиотека предоставляющая примитивы.
P>Это не внутренние классы, а вполне даже внешний интерфейс, описанный в документации.
Можно ссылку на то, о чем ты ведешь речь?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>В том-то и дело, что иногда где-то в цепочке исключение магическим C>образом преобразуется в другой тип из-за наведенных ошибок. И такое не C>сразу можно заметить.
Здравствуйте, vdimas, Вы писали:
V>Да нет, ты просто потерял нить разговора и уже давно. Вся ветка была о "клевом подходе" к разработке веба на LISP в эпоху CGI.
В данном случае обсуждалась исключительно адекватность вывода.
V>blah-blah-blah... V>для тебя С++ — как красная тряпка для быка, удивляться его использованию в реальных проектах ты способен (намерен?) бесконечно.
Я вообще это не обсуждал. Еще раз тебе повторяю, что ты сражаешся с ветренными мельницами. Но если тебе охота получить вопрос о применении С++ в веб-проектах, то отвечу. Я таких людей считаю фанатиками и маньяками не способными принять адекватное решение.
Что же до С++ и красных тряпок... то мне плевать на этот язык. Просто его слишко часто суют во все дыры. Это и раздражает.
V>>>Я лишь добавил пару комментов к их выбору...
VD>>А они тебя просили?
V>А тебя?
V>Ты привел с потолка взятый аргумент, насчет длины цикла, который я и оспорил. Занятно уже то, что твой же аргумент никак не относился к твоей же логике...
Извини, но большей неадекватности на этих форумах встретить тяжело. Я не приводил никаких аргументов по длиннам циклов. Я заметил банальный алогизм в рассуждениях. Если ты не понял моих слов, то просто збудь их. Мне этот бессмысленный разговор порядком надоел.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Понимаеш ли. Твои слова про сложность С++ — это не правда. Как язык C# значительно сложнее. Он обладает куда большим объемом кострукций не говоря уже о их применении.
VD>Сам С++ относительно простой язык. Сложно же в нем обходить грабли. Вот тут действительно нужно выроботать привычку использовать только безопасные паттерны. Ну, и сложно следить за теми самыми мелочами. Однако сложность использования и сложность продукта не коррелирую между собой. К примеру, телевизор очень не простой продукт, то использовать его может трех-летний ребенок.
мне кажется — количество конструкций языка не говорит о его сложности.
Сложность языка — это наскольно сложно на нем писать КАЧЕСТВЕННЫЙ КОД.
Здравствуйте, mogadanez, Вы писали:
M>мне кажется — количество конструкций языка не говорит о его сложности. M>Сложность языка — это наскольно сложно на нем писать КАЧЕСТВЕННЫЙ КОД.
Сложность может расматриваться с разных точек зрения. Так что и да, и нет.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
P>>Сложнее будет не только реализация, но и использование.
VD>Ровно настолько насколько делать вызовы методов на ассемблере нежели на языке высокого уровня.
А что, (хотя бы) этого недостаточно??
В ассемблере не хватает многого из того, к чему привыкли пользователи ящыков высокого уровня. Например, такие возможности, как вычисление выражений, или "управляющие" конструкции (ветвление, циклы). Это тоже не абстракции?
P>>Удобнее для тех, кто реализует, и для тех, кто использует. Вроде object->do_it() удобнее писать, чем object->vtbl->do_it(object). (А если бы не было понятия указателей на функции — вообще бы ужас получился.)
VD>Не нужно привлекать сюда заморочки КОМ-а. На С можно писать и так: VD>
VD>do_it(object);
VD>
VD>Это конечно не винец творения, но более чем приемлемо.
Я имел в виду именно полиморфный вызов.
P>>Ну, все-таки не изменение, а скорее уточнение синтаксиса.
VD>Нет, это именно изменение. Только конечно не синтаксиса, а семантики. Но это уже не важно.
Действительно, не важно... Хотя с изменением семантики можно и поспорить.
P>> Причем имеющее своей целью именно предоставление пользователю абстракции операции вывода, работающей для расширяемого множества типов потоков и расширяемого множества типов данных.
VD>Нда. Ну, и чем: VD>
VD>stdхзч << i;
VD>
VD>абстрактнее чем: VD>
VD>print(i);
VD>
VD>
Если второй код — это C, то он хуже отсутствием полиморфизма времени компиляции. Я же явно написал про "расширяемые множества типов" (потоков и выводимых значений).
А так же тем, что для вывода нескольких значений нужно повторять много раз print.
VD>>>Причем основанное на безолаберном отношении языка к безопасности кода.
P>>Это почему??
VD>Потому что в оригинале << это побитовый сдвиг влево.
И что? Дизайн языка (C++) предполагает переопределение операторов, и стандартная библиотека потокового ввода-вывода C++ вполне корректно это использует. Нарушения безопасности кода здесь IMHO нет, т.к. для введение нового operator << никоим образом не влияет на существующий код, использующий операцию побитового сдвига для работы с целыми числами.
VD> Плюс используется ошибка языка допускающая вычисления значений без присвоения их в переменную или передачи в качестве параметра.
То, что это ошибка — тема для holy war. По мне — так это штатная "фича" языка, без которой, может быть, невозможно было бы реализовать тот же "цепочечный" operator <<. Хотя с точки зрения чистой идеологии она, действительно, нежелательна.
P>>Возьмем, к примеру, C. Его printf-семейство абстрагирует вывод, но "не дотягивают" до operator << (отсутствие безопасности типов, необходимость явно указывать тип выводимых данных, полное отсутствие расширяемости).
VD>Чушь какая-то причем тут безопасность типов? Господа, отделяйте мухи от котлет.
Безопасность типов в данном случае — это вполне объективное преимущество operator << перед printf(). Хотя, возможно, и не относящееся к теме абстрагирования.
Да, кстати: товарищи, будьте взаимовежливы.
VD>Отсуствие расширяемости тоже звучит забавно. Создай новую процедуру и делай в ней все что хочешь.
Я не хочу каждый раз (для каждого нового типа) создавать новую процедуру (точнее, процедуру с новым именем). Если это делать, код, выводящий значения (в консоль или куда-то еще) становится менее единообразным, менее простым и больше привязанным к реализации — т.е. "качество" абстракции ухудшается. Кроме того, это не позволяет по-нормальному использовать существующий код (хотя этот аргумент становится по-настоящему важен только при наличии шаблоков — или при использовании макросов C).
Явное указание типов значений — это туда же (к ухудшению качества абстракции).
P>>Кстати, складывается впечатление, что у нас существенно разные понятия об абстракции. Определимся с определениями?
VD>Нет, проблем — Abstraction (computer science)
Да, это вполне можно принять за основу:
In computer science, abstraction is a mechanism and practice to reduce and factor out details so that one can focus on few concepts at a time.
"Reduce and factor out details" — это и более короткая запись вызова процедуры (C cs ASM), и не "перегруженная" строкой форматирования, единообразная запись cout << i (C++ vs C), и in place создание функции типа (lambda (person) (display (name person))) (Lisp vs C/C++/C#/Java).
P>>А какая суть? А то контекст, в котором было упоминание Spirit, что-то затерялся.
VD>Суть в том, что это не библиотека предоставляющая примитивы.
Примитивы эта библиотека предоставляет, только они (в основном) не независимы, а формируют "язык", с помощью которого специфицируется парсер. Хотя там есть и большой кусок (Phoenix), который можно использовать отдельно.
P>>Это не внутренние классы, а вполне даже внешний интерфейс, описанный в документации.
VD>Можно ссылку на то, о чем ты ведешь речь?
Здравствуйте, pvgoran, Вы писали:
P>А что, (хотя бы) этого недостаточно??
Для чего?
P>В ассемблере не хватает многого из того, к чему привыкли пользователи ящыков высокого уровня. Например, такие возможности, как вычисление выражений, или "управляющие" конструкции (ветвление, циклы). Это тоже не абстракции?
Видимо я как-то очень туманно изъясняюсь. Попробую по проще...
Я не призываю программировать на ассемблере. Я просто сказал, что абстракции можно добиться практически на любом языке программирование.
P>Я имел в виду именно полиморфный вызов.
Полиморфный вызов на С может выглядеть так:
SomeFunctionPointer();
P>Если второй код — это C, то он хуже отсутствием полиморфизма времени компиляции.
В С вообще с полиморфизмом не зашибись. Но с точки зрения абстракции разницы, согласись, нет никакой.
P> Я же явно написал про "расширяемые множества типов" (потоков и выводимых значений).
А я ясно написал "не путай теплое с мягким".
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В данном случае обсуждалась исключительно адекватность вывода.
Ok, адекватность — суть соответствие чему-либо. Продолжим.
VD>Я вообще это не обсуждал. Еще раз тебе повторяю, что ты сражаешся с ветренными мельницами. Но если тебе охота получить вопрос о применении С++ в веб-проектах, то отвечу. Я таких людей считаю фанатиками и маньяками не способными принять адекватное решение.
А ты уверен, что JSP-технология (была как вариант в обсуждаемой теме) образца 3-х летней давности способна выдержать нагрузку многих тысяч одновременно работающих пользователей? Я че-то не уверен. Кстати, сам движок Google на чем написан? А Yahoo? A Alta-Vista? Не надо путать RAD-подход к разработке и подход: "мы спустимся медленно, и отымеем все стадо".
VD>Что же до С++ и красных тряпок... то мне плевать на этот язык. Просто его слишко часто суют во все дыры. Это и раздражает.
Нифига себе дыры — самые крутые поисковые движки. А теперь еще и store-движки. Да блин, трудоемкость презентационной части веба в подобных задачах не видна и под микроскопом.
Если бы они для подобных задач взяли Java или там (не дай бог) PHP, то "Я таких людей считаю фанатиками и маньяками не способными принять адекватное решение." (С) VlaD2.
Фронт-енд к движку мог быть написан на чем угодно. Хотя, это уже не суть важно т.к. может не дать значительно выигрыша в скорости-качестве разработки (надо же будет обертки над нативом писать, в Java это не так просто как в .Net, т.е. приличного выигрыша трудоемкости не получим).
VD>Извини, но большей неадекватности на этих форумах встретить тяжело. Я не приводил никаких аргументов по длиннам циклов. Я заметил банальный алогизм в рассуждениях. Если ты не понял моих слов, то просто збудь их. Мне этот бессмысленный разговор порядком надоел.
vdimas wrote:
> VD>Я вообще это не обсуждал. Еще раз тебе повторяю, что ты сражаешся с > ветренными мельницами. Но если тебе охота получить вопрос о применении > С++ в веб-проектах, то отвечу. Я таких людей считаю фанатиками и > маньяками не способными принять адекватное решение. > А ты уверен, что JSP-технология (была как вариант в обсуждаемой теме) > образца 3-х летней давности способна выдержать нагрузку многих тысяч > одновременно работающих пользователей? Я че-то не уверен.
BEA Inc. с тобой не согласна. Кстати, еще в 2000 году свободный
JSP-сервер Tomcat спокойно держал тысячу запросов в секнду на хорошем
железе.
> Кстати, сам движок Google на чем написан? А Yahoo? A Alta-Vista? Не > надо путать RAD-подход к разработке и подход: "мы спустимся медленно, > и отымеем все стадо".
Еще раз (последний) я утверждений не делал. Я высказал мысль, что если кто-то посчитал, что Ява и т.п. дают какую-то выгоду по сравнению с лиспом, то на основании этого архи глупо и нелепо принимать решение о переписывании софта на С++.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>AltaVista вот как раз на Java написана.
Откуда дровишки? Скорее, речь идет о презентационной части (и то не факт)? И разве имеет значение, на чем написана презентационная часть, тем более подобной "сложности".
Насколько я помню, самая первая ферма серверов Alta-Vista крутилась на DEC-Alpha серверах еще с 95-го или 96-го года, и никакой Джавы в движке не было и в помине. Да и в более поздних коммерческих версиях их движка — тоже.
в догонку
C>BEA Inc. с тобой не согласна. Кстати, еще в 2000 году свободный C>JSP-сервер Tomcat спокойно держал тысячу запросов в секнду на хорошем C>железе.
vdimas wrote:
> C>BEA Inc. с тобой не согласна. Кстати, еще в 2000 году свободный > C>JSP-сервер Tomcat спокойно держал тысячу запросов в секнду на хорошем > C>железе. > Кстати, тысяча и десятки тысяч — разные вещи.
vdimas wrote:
> C>AltaVista вот как раз на Java написана. > Откуда дровишки?
C theserverside'а вестимо...
> Скорее, речь идет о презентационной части (и то не факт)? И разве > имеет значение, на чем написана презентационная часть, тем более > подобной "сложности".
Как раз фронтенд у них написан в виде модулей к апачу, а поисковый бот и
сама логика поиска — на Java. Об этом была статья на theserverside'е
году так в 2001.
> Насколько я помню, самая первая ферма серверов Alta-Vista крутилась на > DEC-Alpha серверах еще с 95-го или 96-го года, и никакой Джавы в > движке не было и в помине. Да и в более поздних коммерческих версиях > их движка — тоже.
Сначала не было, потом в 99 году там все переписали. Полученый продукт
еще и продавали другим компаниям для внутреннего поиска.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>> и как его реализовать на C#1.
VD>>>Реализовать интерфейс?
ANS>>Поподробнее, пожалуйста.
VD>Что подробнее? В IEnumerator два метода и одно свойство. Их название говорят сами за себя. Плюсь в МСДН для особо одаренных целый рассказ о томк как реализовывать этот интерфейс.
IEnumerator — это внешняя итерация, а речь шла вроде о внутренней.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, pvgoran, Вы писали:
P>>А что, (хотя бы) этого недостаточно??
VD>Для чего?
Переформулирую. То, что для использования абстракции (точнее, процедуры, реализующей абстракцию), нужно написать N нетривиально связанных друг с другом ассемблерных команд вместо одной строчки на C — это существенное уменьшение удобства использования абстракции (некоторые абстракции оно может совершенно обесценить). Для меня это показатель того, что ASM "поддерживает абстракции" хуже, чем C.
P>>В ассемблере не хватает многого из того, к чему привыкли пользователи ящыков высокого уровня. Например, такие возможности, как вычисление выражений, или "управляющие" конструкции (ветвление, циклы). Это тоже не абстракции?
VD>Видимо я как-то очень туманно изъясняюсь. Попробую по проще... VD>Я не призываю программировать на ассемблере. Я просто сказал, что абстракции можно добиться практически на любом языке программирование.
А что значит "можно добиться абстракции"?
1. "Можно реализовать любую абстракцию". Я сомневаюсь, что это возможно сделать в каком бы то ни было ЯП.
2. "Можно реализовать какие-то абстракции". С этим я соглашусь — но это совершенно не относится к теме достаточности процедур для введения любых абстракций.
P>>Я имел в виду именно полиморфный вызов.
VD>Полиморфный вызов на С может выглядеть так: VD>
VD>SomeFunctionPointer();
VD>
Ну да. Только для того, чтобы это был полиморфный вызов, нужно где-то выше написать что-то вроде:
SomeFunctionPointer = object->vtbl->do_it;
P>>Если второй код — это C, то он хуже отсутствием полиморфизма времени компиляции.
VD>В С вообще с полиморфизмом не зашибись.
Совершенно верно, об этом и речь.
VD>Но с точки зрения абстракции разницы, согласись, нет никакой.
Не соглашусь. Полиморфизм позволяет абстрагироваться от того, с объектом какого типа мы имеем дело.
P>> Я же явно написал про "расширяемые множества типов" (потоков и выводимых значений).
VD>А я ясно написал "не путай теплое с мягким".
Не было этого!
А если серьезно — то не поясните ли Вы, где, что и с чем я спутал?
P.S. Вы оставили непрокомментированным довольно большую часть моего сообщения. Означает ли это, что Вы согласны с тем, что там было написано?
Здравствуйте, VladD2, Вы писали:
ANS>>>>Осталось выяснить в каком месте внутренний итератор (кривым отражением которого и есть foreach) не является абстракцией, VD>>>Переведи это на русский. ANS>>Какое именно слово тебе не понятно? VD>Выделенно жирным.
Гм. Мне не понятно что же тебе не понятно
ANS>>>> и как его реализовать на C#1. VD>>>Реализовать интерфейс? ANS>>Поподробнее, пожалуйста. VD>Что подробнее? В IEnumerator два метода и одно свойство. Их название говорят сами за себя. Плюсь в МСДН для особо одаренных целый рассказ о томк как реализовывать этот интерфейс.
Влад, реч идёт о внутреннем итераторе. Для его реализации нужен один метод.
ANS>>>>Влад, абстракция без простоты это фигня какая то. VD>>>На это тебе очень хорошо ответил mihoshi
. ANS>>Уж, извини, не понял я ответа. VD>Точнее не захотел. Ты постоянно путашь понятия. Абстракцию с внешней формой. Простоту абстракции и сложность реализаци скрываемой за абстракцией. У меня складывается ощущение, что ты делашь это намеренно. Если это не так, то просто обратись к словарям. Ну, а если так, то давно пора завязывать этот разговор. Все равно путного ничего не выйдет.
Во-первых, внешний итератор — 2 метода и одно свойство, внутренний — один метод. Вывод: внутренний итератор — абстракция более высокого уровня.
Во-вторых, зачастую сложность реализации чего-либо это почти равнозначно невозможности реализации. То есть результат конечный один и тот же — неиспользование.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Во-первых, внешний итератор — 2 метода и одно свойство, внутренний — один метод. Вывод: внутренний итератор — абстракция более высокого уровня.
Что ты понимашь под словами "внешний итератор"?
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ANS>>Во-первых, внешний итератор — 2 метода и одно свойство, внутренний — один метод. Вывод: внутренний итератор — абстракция более высокого уровня.
VD>Что ты понимашь под словами "внешний итератор"?
Извини, но данная теменология не общепринята и довольно не корректна. Все же применение функций высшего порядка новых объектов не создает. А итератор — это в первую очередь объект.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>>> и как его реализовать на C#1. VD>>>>Реализовать интерфейс? ANS>>>Поподробнее, пожалуйста. VD>>Что подробнее? В IEnumerator два метода и одно свойство. Их название говорят сами за себя. Плюсь в МСДН для особо одаренных целый рассказ о томк как реализовывать этот интерфейс.
ANS>Влад, реч идёт о внутреннем итераторе. Для его реализации нужен один метод.
Как я теперь понял "о внутреннем итераторе" — это ты пыташся приплести сюда функции высшего порядка. Ну, и причем тут это? Ощущение такое, что кому-то хочется попереключать тему, чтобы полностью всех запутать.
ANS>Во-первых, внешний итератор — 2 метода и одно свойство,
Во-первых, я не жалаю пользоваться этой терминологией. Во-вторых, методов может быть сколько угодно. В дотнете есть две реализации дженерик и обычная. Дженери расширяет обычную одним свойством.
ANS> внутренний — один метод. Вывод: внутренний итератор — абстракция более высокого уровня.
Агащазблин. Абстракция более высокого уровня должна устранять рассмотрение некоторых, не важных для некоторого случая, деталий. В данном случае ничего поднбго нет. Есть просто функция высшего порядка предназначеная для применения другой функции к списку и объект итератор. Т.е. разные интерфейсы абстракции перебора. Причем с разными характеристиками. Одно убоно в одном случае, другое в дургом.
ANS>Во-вторых, зачастую сложность реализации чего-либо это почти равнозначно невозможности реализации. То есть результат конечный один и тот же — неиспользование.
Замечательные абстрактные рассуждения ничего в прочем не дающие. IEnumerable в дотенете реализуется любой коллекцией. Сложности конечно есть, но не фатальные.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mogadanez, Вы писали:
VD>>Понимаеш ли. Твои слова про сложность С++ — это не правда. Как язык C# значительно сложнее. Он обладает куда большим объемом кострукций не говоря уже о их применении.
VD>>Сам С++ относительно простой язык. Сложно же в нем обходить грабли. Вот тут действительно нужно выроботать привычку использовать только безопасные паттерны. Ну, и сложно следить за теми самыми мелочами. Однако сложность использования и сложность продукта не коррелирую между собой. К примеру, телевизор очень не простой продукт, то использовать его может трех-летний ребенок.
M>мне кажется — количество конструкций языка не говорит о его сложности.
синтаксически-одинаковые конструкции могут быть семантически разными. Поэтому я бы подсчитывал число семантических конструкций. По этому показателю С++ сложнее того же C#. (взять хотя бы разнообразные способы объявления переменных и создания экземпляров как на стеке, так и в хипе, т.е. на каждую конструкцию в C# мы получаем минимум 2-3 конструкции в С++. Учитывая forward-declarations и макросы — и того больше.
Конструкции типа lock и using в С++ не нужны принципиально, из-за механизма детерминированного разрушения стековых объектов.
Эти конструкции были введены в C# для обеспечения детерменированности наиболее встречающихся сценариев.
Конструкция fixed — вообще относится к тонкостям работы с GC.
unsafe — объявляет класс/метод/блок кода, где возможна адресная арифметика, очень похожая на С++-ную.
Что действительно понравилось в C# — это возможность явного управления иерархиями виртуальных ф-ий. С++ в этом плане немного жестче и не столь очевиден.
M>Сложность языка — это наскольно сложно на нем писать КАЧЕСТВЕННЫЙ КОД.
И тут я бы уточнил. Сложность С++ заключается в большом количестве материала, который остается за кулисами. Например правила приведения типов, адресной арифметики, выведения аргументов шаблонов, видимость namespace там же и т.д.
Т.е. я бы оценил сложность языка еще в объеме материала, которым нужно владеть для адекватного кодирования на нем.
Но и тут следует уточнять. Мне, например, потребовалось переварить совсем немного материала, чтобы изучить ВСЕ конструкции языка C#, включая синтаксис применения аттрибутов (assembly:, return: ). Однако, относительно C#, чтобы писать на нем, нужно скорее знать не столько язык, сколько особенности и важнейшие типы (и аттрибуты) самой платформы. А их много.
Соответственно, специалистом в C# невозможно быть не будучи специалистом по самой .Net.
И кстати, гуру C# — это именно гуру .Net со всеми прибабахами, начиная от философии решения типовых задач (и не только типовых), заканчивая безопасностью, рефлекшеном и т.д. и т.п..
Здравствуйте, VladD2, Вы писали:
ГВ>>И что это доказывает? Привлекательность "направления .NET/C#" для... для кого? Или попросту то, что те, для кого привлекателен C# чаще заглядывают в "голосования"?
VD>Это пказывает, что даже С++-программисты (которые как раз значительно чаще заглядывают в голосования, как показывает практика) и сами осознают большую перспективность дотнета нежели нэйтив-С++-а. Ну, или то что относительная популярность дотнета ростет.
Или то, что ссылка на голосование лежала не в том форуме. Сейчас там 50/50 результат
Здравствуйте, VladD2, Вы писали:
VD>foreach — это синтаксический сахар позволяющий быть менее многословным для выражения паттерна перебора. Абстракцией он не является. Абстракцией является интерфейс IEnumerable и IEnumerable<T>. Они кстати, я взык не вмонтированы.
Кстати — это вообще прикольный аспект. Класс Exception тоже в язык не вмонтирован, но мы можем выбросить только его наследника. foreach — вмонтированная конструкция, однако, занимается перебором невмонтированного IEnumerable.
В этой ветке много говорилось о достоинствах Lisp-а как языка для метапрограммирования. А недавно набрел на ссылоку, где разсказывается про возможности метапрограммирования на Ruby.
Lisp
• Metaprogramming seems to have originated in Lisp. Lisp is a programmable programming language.
—John Foderaro In Lisp, you don’t just write your program down toward the language, you also build the language up toward your program.
—Paul Graham
• Lisp isn’t the only programmable language.
Ruby
• Rubyists have been rediscovering metaprogramming.
• Ruby style and idioms are still changing and adapting.
• Rails leverages metaprogramming heavily. • To great effect!
• Ruby is a natural for metaprogramming.
и, чуть дальше
How To Think About Metaprogramming
• Defining new constructs for your programming language.
• OK, but … constructs to do what?
• Whatever your domain-specific language (DSL) needs to do.
Another Way To Think About Metaprogramming
• A new set of conceptual tools for eliminating duplication (and other smells) from your code.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Интересно, как можно не вызвать деструктор базового класса?..
VD>Ты только деструкторы вызывашь? Или виртуальные методы не приходилось перегружать?
Похоже, надо возвращаться к началу.
Деструктор базового класса за меня вызовет компилятор. Т.е. освобождение ресурсов гарантирует мне компилятор. Ведь паттерн вроде для этого?
Здравствуйте, Павел Кузнецов, Вы писали:
>> как выглядит максимально изящное библиотечное решение?
ПК>Ну, "максимально изящное" -- не знаю, тут долго можно спорить, т.к. понятия об изящном у всех свои... Но достаточно близкий по количеству писанины к встроенному в язык: ПК> ... ПК>Mожет быть, например, таким:
Павел, ты не мог бы подсказать ссылку на цитируемое тобой библиотечное решение?
Здравствуйте, eao197, Вы писали:
E>В этой ветке много говорилось о достоинствах Lisp-а как языка для метапрограммирования. А недавно набрел на ссылоку, где разсказывается про возможности метапрограммирования на Ruby.
E>Metaprogramming Ruby, Domain-Specific Languages for Programmers
All my three build languages share another characteristic — they are all examples of a Domain Specific Language (DSL). However they are different kinds of DSL. In the terminology I've used before:
* make is an external DSL using a custom syntax
* ant (and nant) is an external DSL using an XML based syntax
* rake is an internal DSL using Ruby.
The fact that rake is an internal DSL for a general purpose language is a very important difference between it and the other two. It essentially allows me to use the full power of ruby any time I need it, at the cost of having to do a few odd looking things to ensure the rake scripts are valid ruby. Since ruby is a unobtrusive language, there's not much in the way of syntactic oddities. Furthermore since ruby is a full blown language, I don't need to drop out of the DSL to do interesting things — which has been a regular frustration using make and ant. Indeed I've come to view that a build language is really ideally suited to an internal DSL because you do need that full language power just often enough to make it worthwhile — and you don't get many non-programmers writing build scripts.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
aBuilder entry: [:entry |
entry name: self name.
entry email: [:email |
item title: 'This is my email'.
item description: 'This is the description of the e-mail']].
Такая метода — стандартный способ генерации XHTML в seaside.
E> E>DSL вместо явного написания SQL
E>
E>route "Problems" do
E> step "Problem Resolution"
E>end
E>route "EMail Order" do
E> step "Validate Customer"
E> step "Assemble Order"
E> step "Charge Credit Card" do
E> on "invalid", :route => "Problems", :step => "Problem Resolution"
E> end
E> step "Ship"
E>end
E>generate_sql
E>
E>вместо E>
E>INSERT INTO queues(id, name) VALUES (1, 'Validate Customer');
E>INSERT INTO queues(id, name) VALUES (2, 'Validate Books');
E>INSERT INTO queues(id, name) VALUES (3, 'Charge Credit Card');
E>INSERT INTO queues(id, name) VALUES (4, 'Ship Order');
E>INSERT INTO queues(id, name) VALUES (5, 'Problem Resolution');
E>INSERT INTO routes(id, name) VALUES (1, 'EMail Book Orders');
E>INSERT INTO routes(id, name) VALUES (2, 'Problems');
E>INSERT INTO steps(id, route_id, queue_id) VALUES(1, 1, 1);
E>INSERT INTO steps(id, route_id, queue_id) VALUES(2, 1, 2);
E>INSERT INTO steps(id, route_id, queue_id) VALUES(3, 1, 3);
E>INSERT INTO steps(id, route_id, queue_id) VALUES(4, 1, 4);
E>INSERT INTO steps(id, route_id, queue_id) VALUES(5, 2, 5);
E>INSERT INTO alternatives(id, step_id, code, next_step_id)
E> VALUES (1, 3, 'invalid', 5);
E>
Почему именно — можно почитать можно
приводит пример решения задачи,
Тут основной, мм, нюанс в том,
. Он лишь означает, что "банальные юнит-тесты и ассерты" перестают "спасать" несколько позже (для несколько более сложных программ), чем обычно.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
).
Если нам не помогут, то мы тоже никого не пощадим.
А что такое, например, параметризуемые модули, как не шаблоны?
