![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Читаю потихоньку книгу про Лисп, любезно порекомендованную ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
cmm. Там вот такой пассаж:
Lisp's syntax is quite a bit different from the syntax of languages descended from Algol. The two most immediately obvious characteristics are the extensive use of parentheses and prefix notation. For whatever reason, a lot of folks are put off by this syntax. Lisp's detractors tend to describe the syntax as "weird" and "annoying." Lisp, they say, must stand for Lots of Irritating Superfluous Parentheses. Lisp folks, on the other hand, tend to consider Lisp's syntax one of its great virtues. How is it that what's so off-putting to one group is a source of delight to another?
I can't really make the complete case for Lisp's syntax until I've explained Lisp's macros a bit more thoroughly, but I can start with an historical tidbit that suggests it may be worth keeping an open mind: when John McCarthy first invented Lisp, he intended to implement a more Algol-like syntax, which he called M-expressions. However, he never got around to it. He explained why not in his article "History of Lisp."
The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred [S-expressions] to any FORTRAN-like or ALGOL-like notation that could be devised.
In other words, the people who have actually used Lisp over the past 45 years have liked the syntax and have found that it makes the language more powerful. In the next few chapters, you'll begin to see why.
Мне это обьяснение кажется случаем стокгольмского синдрома. Типа у нас другого нету, поэтому мы любим, чего есть. Впрочем, программисты часто этим страдают, все religious wars на тему софта оттуда же растут.
P.S. во избежание - я не говорю здесь, что Лисп плохой (обсуждать этот вопрос тут). Я про само обьяснение.
cmm. Там вот такой пассаж:Lisp's syntax is quite a bit different from the syntax of languages descended from Algol. The two most immediately obvious characteristics are the extensive use of parentheses and prefix notation. For whatever reason, a lot of folks are put off by this syntax. Lisp's detractors tend to describe the syntax as "weird" and "annoying." Lisp, they say, must stand for Lots of Irritating Superfluous Parentheses. Lisp folks, on the other hand, tend to consider Lisp's syntax one of its great virtues. How is it that what's so off-putting to one group is a source of delight to another?
I can't really make the complete case for Lisp's syntax until I've explained Lisp's macros a bit more thoroughly, but I can start with an historical tidbit that suggests it may be worth keeping an open mind: when John McCarthy first invented Lisp, he intended to implement a more Algol-like syntax, which he called M-expressions. However, he never got around to it. He explained why not in his article "History of Lisp."
The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred [S-expressions] to any FORTRAN-like or ALGOL-like notation that could be devised.
In other words, the people who have actually used Lisp over the past 45 years have liked the syntax and have found that it makes the language more powerful. In the next few chapters, you'll begin to see why.
Мне это обьяснение кажется случаем стокгольмского синдрома. Типа у нас другого нету, поэтому мы любим, чего есть. Впрочем, программисты часто этим страдают, все religious wars на тему софта оттуда же растут.
P.S. во избежание - я не говорю здесь, что Лисп плохой (обсуждать этот вопрос тут). Я про само обьяснение.
no subject
предложи лучше.
no subject
no subject
no subject
Мне это кажется аналогичным регулярно возникающему в околоюниксных эхах флейму по поводу того, что не существует хорошего norton-like файл-менеджера под *nix. Там ответ простой - те, кому он нужен, не в состоянии его написать, а тем, кто в состоянии его написать - он не нужен.
Заметим также, что стандартным упражнением для изучающих Lisp является реализация интерпретатора Prolog. У которого лишних скобочек в синтаксисе нет. Поэтому оценка интерпретатора M-выражений в месяц может даже, и завышенная. Таким образом проблема опять сводится к предыдущему абзацу. Пока ты изучишь лисповские макросы достаточно хорошо, чтобы быть способным написать парсер M-выражений, ты поймешь скрытую прелесть S-выражений (которую не сразу понял даже сам Маккарти - для этого нужно практически с ними поработать), и расхочешь его писать.
Ибо единственный оставшийся побудительный мотив - облагодетельствовать толпу чайников, еще никогда не приводил к появлению хороших программ.
no subject
человек пишет примерно следующее: вот есть синтаксис. выглядит он несколько неконвенционально, но он, во-первых, удобен, а во-вторых, позволяет производить нетривиальные синтаксические манипуляции. это вполне конкретные рациональные техничекие соображения. эти соображения очевидным образом перевешивают неконвенциональность — что очевидно из того факта, что никакие альтернативы в Лиспе не прижились.
если ты считаешь, что можно придумать более конвенциональный но при этом не менее мощный синтаксис, обоснуй.
если не считаешь, то what's your point, и где ты углядел стокгольмский синдром?
no subject
no subject
Просто агрументация "мы видим, что синтаксис какой-то не такой, и даже хотели сделать получше, но потом научились любить этот и получше стало влом делать" - кажется забавной.
no subject
Что понимать под "хорошим"? Я видел несколько.
Ибо единственный оставшийся побудительный мотив - облагодетельствовать толпу чайников, еще никогда не приводил к появлению хороших программ.
Я не вижу никакой связи между качеством программы и целевой аудиторией. По идее, наоборот, программы для "чайников" должны быть качественее, т.к. неопытный пользователь не простит того, что простит опытный и привыкший ко всякому. Но реально, конечно, это не так - все быстро приучаются, что от программ многого ждать нельзя.
аким образом проблема опять сводится к предыдущему абзацу. Пока ты изучишь лисповские макросы достаточно хорошо, чтобы быть способным написать парсер M-выражений, ты поймешь скрытую прелесть S-выражений
Ну, буду надеяться, что пойму :)
no subject
неиллюзорная рациональность этого "оценили" неочевидна из конкретного приведённого отрывка, особенно если читать его предвзято.
но тут такое дело: если уже брать в руки книжку, то желательно исходить из того что автор понимает в описываемом предмете несколько больше тебя; и если он пишет "когда дойдём до такой-то главы — поймёте", то логично ему поверить, правда? потому что иначе зачем читать?
no subject
no subject
Понимаешь, ли существует совершенно однозначная связь между качеством программы и целевой аудиторией.
Хорошими могут быть только те программы, автор которых входит в их целевую аудиторию. Программы написанные для других, будь то за деньги, из чистой pride и т.д. никогда не бывают доведены до хорошего состояния.
Потому что единственный способ довести программу до ума - это долго, ежедневно с ней работать, и заметив шероховатости - сразу бросаться их исправлять.
no subject
это смотря за какие деньги.
no subject
Т.е. хорошего коммерческого софта не бывает - ведь ворд-процессоры пишут не редакторы, а фотошоп писали не графики.
no subject
Фотошоп тоже удобным интерфейсом похвастаться не может. А уж поведение фотошопа при сканировании картинок - это вообще смерть на взлете. Нельзя такую продолжительную операцию как сканирование делать модальным диалогом. Пока данная картинка сканируется, можно предыдущую редактировать. Подозреваю, правда, что это проблемы не фотошопа, а так называемой "многозадачной многопользовательской системы" windows NT.
no subject
no subject
no subject
И all software will sucks до тех пор, пока умение выражать свои мысли на языке программирования не будет таким же неотъемлемым свойством образованного человека, как умение выражать свои мысли на естественном языке.
no subject
Ну, да. И ещё два примера. Заметим, что все три не являются коммерческим софтом и используются в основном людьми внутри тусовки. Не то, чтобы это было плохо - просто надо осознавать, что за пределами тусовки тоже кое-что есть.
gcc написан людьми, для которых он является типичным рабочим инструментом.
99.9% пользователей gcc не имеют никакого отношения к его написанию. Однако дело в другом - вы сейчас говорите о продуктах для программистов. Давайте прейдём к продуктам для людей, программистами не являющихся и посмотрим там. Хороших таких продуктов просто быть не может, как мы уже выяснили. Таким образом, человек, желающих пользоваться компьютером, должен или учить Лисп и писать всё для себя или отдыхать. Печальный подход, вам не кажется?
no subject
просто надо осознавать, что за пределами тусовки тоже кое-что есть.
А зачем это осознавать? Каким образом этот кое-кто поможет мне повысить качество того софта, которым я пользуюсь?
Для того, чтобы те кто «вне тусовки» могли реально повлиять на качество софта, необходим работающий механизм взаимодействия между разработчиками и пользователями.
Таких механизмов на данный момент опробовано два:
С первым механизмом всё ясно - я уже про него написал. Он требует чтобы пользователь умел выражать свои мысли на языке программирования. Эффективность его работы впрямую зависит от высокоуровневости применяемых средств разработки. К сожалению, в больших проектах на C и C++ эта эффективность недопустимо низка.
Со вторым механизмом всё намного хуже. Сложившаяся бизнес-модель на рынке программного обеспечения приводит к тому что маркетинговому отделу софтверной компании наименее интересны постоянные и опытные пользователи её продуктов - с них уже взято всё, что можно. Интересно завлечь пользовательей конкурентов, и людей ранее компьютерами не пользовавшихся. С этих можно денег взять. Поэтому чем популярнее программный продукт, и чем крупнее фирма, его производящая, тем менее эффективен этот канал фидбэка.
99.9% пользователей gcc не имеют никакого отношения к его написанию.
А вот это абсолютно не важно. Важно что 100% разработчиков gcc им пользуются. Поскольку реально повлиять на качество софта может только его разработчик.
Таким образом, человек, желающих пользоваться компьютером, должен или учить Лисп и писать всё для себя или отдыхать. Печальный подход, вам не кажется?
Нет не кажется. Учиться - никогда не вредно. Не обязательно учить lisp, можно tcl или python. Хотя лучше и lisp тоже. Вас же не удивляет, что желающий водить машину должен учить правила дорожного движения. А желающий ездить на машине в сравнительно дикой местности, где нельзя из произвольной точки вызвать эвакуатор, должен и кое-что про её ремонт изучить.
Проблема использования компьютера заключается в том, что для того чтобы написать программу, позволяющую использовать компьютер для решения некоторой задачи эффективно нужно в первую очередь уметь решать эту задачу. А уже во вторую - уметь программировать. Поэтому сейчас 90% компьютеров используется неэффективно. Потому что пользователь, как правило, не умеет правильно сформулировать что ему нужно, и правильно выбрать софт.
Про задачу эффективной организации взаимодействия человек-компьютер стоит помолчать. Её вообще никто пока решать толком не умеет. Получается либо язык программирования (unix shell), либо костыли (GUI MacOS или Windows) которые скорее мешают ходить, чем помогают.
Фантастика 50-х-60-х годов сформироавла представление о компьютерах, как о азимовских роботах, которые мудры, доброжелательны и способны решить все проблемы за человека (то что в процессе будет уничтожена жизнь на Земле - это мелочи). Современные компьютеры устроены не так. Это инструмент вроде электродрели. Поэтому хочешь получать пользу от такого инструмента - будь добр
а) выучиться им пользоваться
б) освой необходимоую технику безопасности.
no subject
Никаким. Так, для общего развития. Я понимаю, что Шерлоку Холмсу не мешало незнание того факта, что Земля вращается вокруг солнца. Но всё-таки, мне кажется, это полезно знать.
Таких механизмов на данный момент опробовано два:
Это, разумеется, не так. Пример: у нас на фирме для каждого продукта есть человек, _единственной_ задачей которого является выяснение пользовательских требований к продукту и формулировка их для R&D. Это, разумеется, к техподдержке отношения не имеет, поскольку делается на этапе _проектирования_.
маркетинговому отделу софтверной компании наименее интересны постоянные и опытные пользователи её продуктов - с них уже взято всё, что можно.
Эта фраза показывает, что либо с функционированием софтверных компаний вы знакомы очень поверхностно либо вы не позволяете фактам мешать вашим теориям.
Важно что 100% разработчиков gcc им пользуются. Поскольку реально повлиять на качество софта может только его разработчик.
Это не так. Реально на качество софта влияет тот, кто за него платит.
Вас же не удивляет, что желающий водить машину должен учить правила дорожного движения.
Не удивляет. Однако к дискуссии отношения не имеет - ПДД созданы для обеспечения безопасности и не являются необходимым условием для вождения машины.
А желающий ездить на машине в сравнительно дикой местности, где нельзя из произвольной точки вызвать эвакуатор, должен и кое-что про её ремонт изучить.
99.(9)% пользователей машин, однако, не желают изучать их ремонт. Вы можете попробовать экспериментально это опровергнуть, выпустив модель машины, требоющей от пользователя умения её ремонтировать. Возможно, на непритязательном российском рынке ваш даже ждёт сравнительный успех ;) На любых других рынках вашу машину купят только особо продвинутые фанаты. Та же ситуация и с софтом.
Про задачу эффективной организации взаимодействия человек-компьютер стоит помолчать. Её вообще никто пока решать толком не умеет
Поэтому вы предлагаете её решать, заставляя человека говорить на языке компьютера, а не наоборот. Человек, однако, этим доволен не будет, потому что считает, что главный тут - он, а не компьютер.
А уже во вторую - уметь программировать. Поэтому сейчас 90% компьютеров используется неэффективно
Неэффективно с точки зрения программиста - возможно. А с точки зрения организации - вполне возможно, что эффективно, т.к. обучение секретарш программированию на Лиспе, даже если оно окажется возможным, не окупится никогда.
Потому что пользователь, как правило, не умеет правильно сформулировать что ему нужно, и правильно выбрать софт.
Бедный, тупой пользователь. Вообще, мрачная картина. Программисты не знают, что пишут, пользователи не знают, что им надо. Как только живём?
Современные компьютеры устроены не так
No shit!
Поэтому хочешь получать пользу от такого инструмента - будь добр
а) выучиться им пользоваться
Вы упускаете важный момент - пользователь не желает учиться тому, что знает программист. Он желает учиться тому, как решать его задачу, а не как стать более похожим на мечты программиста об идеальном сферическом пользователе. Поэтому говорить пользователю "будь добр делать как я хочу" - можно, но это прямая дорога быть разорённым теми, кто сделает - как он хочет.
no subject
Более того, своим утверждением, что человек, который занимается сбором сведений о пользовательских предпочтений, не имеет отношения к техподдержке, вы фактически подтверждаете мой аргумент, что софтверным компаниям наплевать на существующую пользовательскую базу. Так как именно техподдержка знает какие вопросы чаще всего задают пользователи, где у них возникают трудности etc.
Вообще говоря, стоит определиться с какой позиции мы ведем разговор. Вы в данном случае ведете разговор с позиции коммерческого разработчика софта. Которому нужно максимизировать свою прибыль. Поэтому интересны разговоры о 99% которые не желают учиться.
Я, как ни странно, веду разговор с позиции пользователя. Которому нужно за минимальную цену добиться максимальной эффективности работы от своего компьютера. В цену естественным образом входят и деньги, заплаченные софтверным компаниям, и время, затраченное на обучение, и время затраченное на взаимодействие с саппортом. Время затраченное на взаимодействие с этим сотрудником раздела R&D, ежели он придет ко мне задавать вопросы, и я сочту что мне выгодно на них ответить, чтобы мои пожелания были учтены в следующей версии, тоже входит.
При таком подсчете оказывается, что покупать коробочные продукты крупных фирм производителей мне невыгодно. И чем крупнее фирма - тем менее выгодно. Поскольку меньше шансов что мне удастся получить вменяемую реакцию от техподдержки, не говоря уж о том, чтобы мои пожелания были учтены в следующей версии.
На узких нишевых рынках, например в области ГИС мне лет десять назад удавалось добиться подобного рода реакции от поставщиков (дело, правда, кончилось тем, что мне были высланы почти все исходники используемой нами системы).
Беда в том, что чем больше пользовательская база у продукта, тем менее он учитвывает потребности конкретного пользователя, и тем более оперирует некоторыми средними характеристиками обобщенного пользователя.
Крупные автомобильные компании уже осознали, что каждый пользователь индивидуален и предлагают кучу опций, вплоть до сборки автомобиля на заказ с контролем через web-камеру.
Кстати об автомобилях - предложенные Вами эксперимент уже лет 10 (с начала появления на российском рынке конкурентоспособных по цене подержанных иномарок) ставит Волжский Автомобильный Завод. И ведь не разорился пока.
no subject
"не относится к техподдержке" != "не разговаривает с техподдержкой", ага?
При таком подсчете оказывается, что покупать коробочные продукты крупных фирм производителей мне невыгодно
Ну, возможно. Однако это не означает, что невыгодно - всем. Большинству - резко выгоднее, чем писать самому.
Крупные автомобильные компании уже осознали, что каждый пользователь индивидуален и предлагают кучу опций, вплоть до сборки автомобиля на заказ с контролем через web-камеру.
Однако они не предлагают массовому пользователю проектировать и собирать автомобиль самому. И тем более не заставляют его самостоятельно ремонтировать.
ставит Волжский Автомобильный Завод. И ведь не разорился пока.
Ну да. Я ж говорю - на неизбалованом российском рынке можно ;)
no subject
Практика показывает, что очень многие шероховатости замечательно ловят технические писатели, пытаясь понятным пользователю языком объяснить то, как это работает.
А между "покупать коробочный продукт у крупной фирмы" и "писать самому" существует широкий спектр промежуточных вариантов. И где-то ближе к середине этого спектра находится оптимум. Лично у меня самостоятельно написанный софт обычно занимает примерно 2% экрана. Вот софта, к которому я делал патчи и эти патчи были приняты разработчиками - несколько больше.
no subject
Да ну? А кто мне рассказывал, что единственный вариант получить хороший софт - это чтобы его писал сам пользователь?
Лично у меня самостоятельно написанный софт обычно занимает примерно 2% экрана. Вот софта, к которому я делал патчи и эти патчи были приняты разработчиками - несколько больше.
Вы хотя-бы осознаёте, что пользователей софта, которые хотя бы знают, что значит "патч" - где-то 0.1%, а то и меньше?
no subject
А кто мне рассказывал, что единственный вариант получить хороший софт - это чтобы его писал сам пользователь?
Чтобы автор был пользователем - это некоторая разница. Каждый автор должен быть пользователем, т.е. решать реальные практичнеские задачи с помощью написанного им софта, но не каждый пользователь - автором.
Опять же, мы плавно перешли от идеализированной постановки задачи получить хороший софт к другой постановке получить оптимальный набор софта при приемлемых затратах на его получения. Очевидно, что в этом наборе софта не весь софт будет хорошим, многое будет только приемлемым. Например, не я не знаю хорошей GUI системы. Пользуюсь приемлемой X window. Которая обладает кучей известных мне недостатков, но всё же лучше чем конкуренты, которые вообще не приспособлены к работе по сети.
Вы хотя-бы осознаёте, что пользователей софта, которые хотя бы знают, что значит "патч" - где-то 0.1%, а то и меньше?
Ну и что? У пользователя есть разные способы повлиять на разработку. Конечно, патч - наиболее эффективный. Но есть и другие. Вот вчера один такой прислал мне файл, который неправильно обрабатывался моей программой (требовал явного указания кодировки), и практически совсем не обрабатывался более другими программами. Если он знает, что такое cvs, у него уже есть работающее решение. Если нет - будет когда следующий релиз доползет до поставщиков его операционной системы.
В данном случае, с позиции пользователя, для меня наиболее критично то, что я знаю что такое патч, и что есть достаточно большая вероятность того, что мои патчи будут приняты авторами того софта, которым я пользуюсь. А если и не будут - поддержка инфораструктуры по их применению локально для моих компьютеров, не стоит слишком дорого.
no subject
Упарится автор в каждой предметной области и софт делать, и задачи с ним решать.
Очевидно, что в этом наборе софта не весь софт будет хорошим, многое будет только приемлемым
Поскольку вы определили "хороший" как "софт, автор которого им пользуется для решения своих задач" - то да, очевидно - как я уже сказал, автор упарится себе задачи искать под весь софт, который пишет. Круг задач пользователей сильно шире круга задач автора, поэтому с необходимостью его софт не будет решать задачи пользователей или же будет "нехорош". Как я уже замечал, подобное определения "хорошего" - бессмысленно.
Если он знает, что такое cvs, у него уже есть работающее решение. Если нет - будет когда следующий релиз доползет до поставщиков его операционной системы.
Для бесплатного софта это приемлемая модель работы. Для платного - нет.
В данном случае, с позиции пользователя, для меня наиболее критично то, что я знаю что такое патч
Давайте разберёмся - если мы говорим о том, что удобно лично вам, то никаких вопросов быть не может, вы это знаете лучше и мне тут нечего добавить. Если вы хотите говорить о чём-то большем, чем ваши личные вкусы, то аргумент "а лично мне нравится так" - непригоден.
no subject
Больше 0.1%
Re: Больше 0.1%
no subject
К тому же OpenSSL это как раз пример большого C-шного проекта, где модель community работает недопустимо неэффективным образом.
no subject
no subject
Ну не знаю. Когда я пишу утилиты только для себя, я забиваю на юзабилити в угоду скорости разработки и количеству фич. С программой для посторонних этот номер не пройдёт.
no subject