Smalltalk
Victor Bazhenov
А тут еще остались смолтокеры? :)
--
Best regards
Alexey Desyatnik
VB> А тут еще остались смолтокеры? :)
Hет, а что ^_^
Victor Bazhenov
Sun, 02 Mar 2008 23:37:42, Alexey Desyatnik wrote:
VB>> А тут еще остались смолтокеры? :)
AD> Hет, а что ^_^
Тогда ничего. :)
--
Best regards
Serguey Zefirov
AD>> Hет, а что ^_^
То-то. ;)
Yours truly, Serguey Zefirov
Victor Bazhenov
Wed, 05 Mar 2008 10:44:12, Serguey Zefirov wrote:
VB>>>> А тут еще остались смолтокеры? :)
AD>>> Hет, а что ^_^
VB>> Тогда ничего. :)
SZ> То-то. ;)
Прям какое-то космическое спокойствие, а на дворе уже весна! Где обострения? :)
--
Best regards
Serguey Zefirov
AD>>>> Hет, а что ^_^
VB>>> Тогда ничего. :)
SZ>> То-то. ;)
VB> обострения? :)
все под контролем.
Мы, например, пустили нашу энергию на изучение зависимых типов. Любой Смолток
в сравнении с этим тихо курит в уголку. ;)
Yours truly, Serguey Zefirov
Victor Bazhenov
Thu, 06 Mar 2008 23:42:16, Serguey Zefirov wrote:
VB>>>>>> А тут еще остались смолтокеры? :)
AD>>>>> Hет, а что ^_^
VB>>>> Тогда ничего. :)
SZ>>> То-то. ;)
VB>> Прям какое-то космическое спокойствие, а на дворе уже весна! Где
VB>> обострения? :)
SZ> все под контролем.
SZ> Мы, например, пустили нашу энергию на изучение зависимых типов.
А конкретный пример можешь привести, какую пользу они могут принести народному
хозяйству? :)
SZ> Любой Смолток в сравнении с этим тихо курит в уголку. ;)
Кстати, откуда такая нелюбовь к нему? :) Или все что не Хиндли-Милнер, то
суксь и отстой? :)
--
Best regards
Dmitry Subbotin
VB> Кстати, откуда такая нелюбовь к нему? :) Или все что не Хиндли-Милнер, то
VB> суксь и отстой? :)
Кстати, любопытно, что сами смоллтокеры почему-то не говорят, что им
динамическая типизация подкладывает баги в программу (ни разу не слышал, во
всяком случае). Зато это много говорят люди, которые ST не пользуются. Hа
основе чисто теоритических умозаключений. Что наводит на размышления.
Предлагаю заодно разобраться и с другими языками. Тем же Перлом. Те, кто его
предпочитают типизованному С++, они все маньяки поголовно или все-таки их
выбор оправдан?
Дмитрий
Serguey Zefirov
SZ>> Мы, например, пустили нашу энергию на изучение зависимых типов.
VB> народному хозяйству? :)
Проверка различных инвариантов. От корректности реализации сортировки (не
меняет размера данных, выход есть перестановка входа, выход правильно
отсортирован, см. Why dependent types matter), до количества используемой
программой памяти.
SZ>> Любой Смолток в сравнении с этим тихо курит в уголку. ;)
VB> Кстати, откуда такая нелюбовь к нему? :) Или все что не Хиндли-Милнер, то
VB> суксь и отстой? :)
В нем уже нет идей. Одни решения. С этим можно было бы смириться, но решения
Смолтока не переносятся никуда больше. За это же я не люблю и C++, кстати.
А вот вывод типов в Смолтоке используется. И безымянные функции тоже.
По-моему, ясно, куда надо смотреть.
Yours truly, Serguey Zefirov
Serguey Zefirov
DS> Кстати, любопытно, что сами смоллтокеры почему-то не говорят, что им
DS> динамическая типизация подкладывает баги в программу (ни разу не слышал,
DS> во всяком случае). Зато это много говорят люди, которые ST не пользуются.
DS> Hа основе чисто теоритических умозаключений. Что наводит на размышления.
Если из наличия и обязательности юнит-тестов, о которых постоянно говорят
смолтокеры в обсуждениях ошибок, ты не умеешь вывести наличие багов при
динамической типизации, то ты просто не умеешь читать.
А потому говоришь глупости в своей обычной манере.
DS> Предлагаю заодно разобраться и с другими языками. Тем же Перлом. Те, кто
DS> его предпочитают типизованному С++, они все маньяки поголовно или
DS> все-таки их выбор оправдан?
Давай. Это будет интересно посмотреть.
Заодно расскажи нам, что ты знаешь про Audrey Tang.
Yours truly, Serguey Zefirov
Dmitry Subbotin
DS>> Кстати, любопытно, что сами смоллтокеры почему-то не говорят, что им
DS>> динамическая типизация подкладывает баги в программу (ни разу не слышал,
DS>> во всяком случае). Зато это много говорят люди, которые ST не
DS>> пользуются. Hа основе чисто теоритических умозаключений. Что наводит на
DS>> размышления.
SZ> Если из наличия и обязательности юнит-тестов, о которых постоянно говорят
SZ> смолтокеры в обсуждениях ошибок, ты не умеешь вывести наличие багов при
SZ> динамической типизации, то ты просто не умеешь читать.
Какая прелесть.
1. В смоллтоке нет юнитов, там единица языка - класс.
2. Об необходимости тестировании программы по частям говорят очень многие
программисты, в том числе и те, кто пишет на статических языках. Лично я не
замечаю, что смоллтокеры говорили бы об этом больше, чем другие программисты
(да и вообще я не замечаю, чтобы смоллтокеры об этом говорили, хотя
проглядывал ихние эхи).
3. До тебя вообще не дошел смысл того, что было написано. Речь была не о том,
что при динамической типизаци нет ошибок (они, кстати, есть и при статической
типизации), речь была о том, что программисты на смоллтоке не испытывают
больших сложностей с исправлением этих ошибок. То есть получить ошибку
run-time'а и исправить ее на практике не сильно сложнее, чем ошибку, найденную
компилятором. То есть значение этой проблемы явно преувеличено в целях рекламы
функциональных языков.
4. Ошибка в логике. Из того, что я не могу чего-то там вывести, не следует,
что я не умею читать.
SZ> А потому говоришь глупости в своей обычной манере.
Hадо наверное завязывать с тобой общаться. Очень много ерунды, апломба,
оскорблений. А интересного - пшик.
DS>> Предлагаю заодно разобраться и с другими языками. Тем же Перлом. Те, кто
DS>> его предпочитают типизованному С++, они все маньяки поголовно или
DS>> все-таки их выбор оправдан?
SZ> Давай. Это будет интересно посмотреть.
Могу сказать, что девиз программистов, победивших на последнем ICFP, звучит,
как я помню, как "Перл является хорошим выбором для многих задач".
Таким образом, Перл является любимым языком людей, входящих в число лучших
программистов мира. Sic.
Дмитрий
Victor Bazhenov
Sat, 08 Mar 2008 13:57:42, Serguey Zefirov wrote:
VB>>> Кстати, откуда такая нелюбовь к нему? :) Или все что не
VB>>> Хиндли-Милнер, то суксь и отстой? :)
DS>> Кстати, любопытно, что сами смоллтокеры почему-то не говорят, что
DS>> им динамическая типизация подкладывает баги в программу (ни разу
DS>> не слышал, во всяком случае). Зато это много говорят люди,
DS>> которые ST не пользуются. Hа основе чисто теоритических
DS>> умозаключений. Что наводит на размышления.
SZ> Если из наличия и обязательности юнит-тестов, о которых постоянно
SZ> говорят смолтокеры в обсуждениях ошибок, ты не умеешь вывести наличие
SZ> багов при динамической типизации, то ты просто не умеешь читать.
Сергей, ты правда считаешь, что статическая типизация - это silver bullet и
полностью гарантирует отсутствие ошибок в программах? Разве тесты используются
только при разработке на языках с динамической типизацией?
--
Best regards
Serguey Zefirov
SZ>> багов при динамической типизации, то ты просто не умеешь читать.
DS> Какая прелесть.
DS> 1. В смоллтоке нет юнитов, там единица языка - класс.
Это никак не влияет на название юнит-тестов.
Юнит-тест проверяет кусок программы. Это может быть один класс, один метод или
набор реализаций интерфейса.
DS> 2. Об необходимости тестировании программы по частям говорят очень многие
DS> программисты, в том числе и те, кто пишет на статических языках. Лично я
DS> не замечаю, что смоллтокеры говорили бы об этом больше, чем другие
DS> программисты (да и вообще я не замечаю, чтобы смоллтокеры об этом
DS> говорили, хотя проглядывал ихние эхи).
Родина TDD - Смолток.
Плюс они просто-напросто привыкли к ошибкам, привыкли обкладываться тестами.
DS> 3. До тебя вообще не дошел смысл того, что было написано. Речь была не о
DS> том, что при динамической типизаци нет ошибок (они, кстати, есть и при
DS> статической типизации), речь была о том, что программисты на смоллтоке не
DS> испытывают больших сложностей с исправлением этих ошибок. То есть
DS> получить ошибку run-time'а и исправить ее на практике не сильно сложнее,
DS> чем ошибку, найденную компилятором. То есть значение этой проблемы явно
DS> преувеличено в целях рекламы функциональных языков.
Это неверно.
Цена исправления ошибки пропорциональна времени между ее внесением и ее
обнаружением.
"Статические языки" как раз и сокращают это время.
Это проблема сомневающихся в "рекламе функциональных языков," что они не в
курсе методологии PSP/TSP, и какие выводы из нее можно (и нужно) сделать.
DS> 4. Ошибка в логике. Из того, что я не могу чего-то там вывести, не
DS> следует, что я не умею читать.
Именно это и следует. Если ты не понимаешь написанного, то ты не умеешь
читать.
SZ>> А потому говоришь глупости в своей обычной манере.
DS> Hадо наверное завязывать с тобой общаться. Очень много ерунды, апломба,
DS> оскорблений. А интересного - пшик.
Еще бы. Для понимания выдаваемой мною информации приходится думать, а это для
большинства народа совершенно неинтересно.
SZ>> Давай. Это будет интересно посмотреть.
DS> Могу сказать, что девиз программистов, победивших на последнем ICFP,
DS> звучит, как я помню, как "Перл является хорошим выбором для многих
DS> задач".
Проверь еще раз.
DS> Таким образом, Перл является любимым языком людей, входящих в число
DS> лучших программистов мира. Sic.
Рекомендую проверять свои слова перед высказыванием.
http://video.google.com/videoplay?docid=-6131258297916016786
Рассказ ведущих ICFP 2007 про задачу и, в конце, объявление победителей.
1:13:26
C++ is the language for discriminating hackers.
И вот так у тебя всегда. "Слышал звон, да не знаю, где он."
Yours truly, Serguey Zefirov
Serguey Zefirov
SZ>> говорят смолтокеры в обсуждениях ошибок, ты не умеешь вывести наличие
SZ>> багов при динамической типизации, то ты просто не умеешь читать.
VB> и полностью гарантирует отсутствие ошибок в программах?
Silver bullet имеет к гарантии отсутствия ошибок в программе опосредованное
отношение.
VB> Разве тесты
VB> используются только при разработке на языках с динамической типизацией?
При разработке программ на языках со статической типизацией (preferably HM
type system) тесты используются намного меньше.
Чем больше я смотрю на системы с зависимыми типами, тем больше они мне
нравятся. Они умеют проверять большую часть из того, что нужно - от размеров
векторов до отсортированности данных включая сложность алгоритма.
Это такой Effel на стероидах.
Если к ним добавить уникальные типы данных, будет просто волшебно.
Yours truly, Serguey Zefirov
Dmitry Subbotin
DS>> 2. Об необходимости тестировании программы по частям говорят очень
DS>> многие программисты, в том числе и те, кто пишет на статических языках.
DS>> Лично я не замечаю, что смоллтокеры говорили бы об этом больше, чем
DS>> другие программисты (да и вообще я не замечаю, чтобы смоллтокеры об
DS>> этом говорили, хотя проглядывал ихние эхи).
SZ> Родина TDD - Смолток.
Это еще не означает, что все (или хотя бы большинство) программистов на
Смоллтоке постоянно его применяют.
SZ> Плюс они просто-напросто привыкли к ошибкам, привыкли обкладываться
SZ> тестами.
К ошибкам привыкли все программисты независимо от языка, кто пишет
сколь-нибудь долго. И тестами тоже обкладываются, в некоторых классах
приложений довольно серьзно.
Хотя для типичной гуйно-базовой программы (которые, собственно, на ST в
большинстве своем и пишут) тесты 1) не нужны 2) не применимы.
Потом, масса программистов на ST как минимум владеет еще и С++, и они тоже не
говорят, что "перейдя на этот язык я стал больше тратить времени на поиск
ошибок". Sic.
Прикол же состоит в том, что ST в ихней рекламе позиционируется как язык, в
котором делают мало ошибок. Они даже приводят какие-то замеры vs. C++. :))
DS>> 3. До тебя вообще не дошел смысл того, что было написано. Речь была не о
DS>> том, что при динамической типизаци нет ошибок (они, кстати, есть и при
DS>> статической типизации), речь была о том, что программисты на смоллтоке
DS>> не испытывают больших сложностей с исправлением этих ошибок. То есть
DS>> получить ошибку run-time'а и исправить ее на практике не сильно сложнее,
DS>> чем ошибку, найденную компилятором. То есть значение этой проблемы явно
DS>> преувеличено в целях рекламы функциональных языков.
SZ> Это неверно.
SZ> Цена исправления ошибки пропорциональна времени между ее внесением и ее
SZ> обнаружением.
Ой ли.
Даже если так
SZ> "Статические языки" как раз и сокращают это время.
В динамическом языке время на обнаружение ошибки, связанной с использованием
неверных типов, равно времени на прогон программы до места ошибки. Hа практике
в большинстве случаев - секунды. Sic.
И вообще. Лично у меня то, что ловит компилятор, это ерундовые ошибки, типа
"явную чушь написал". Куда страшнее ошибки в логике, типа "я думал, оно будет
работать, а оно не будет". Вот это иногда приходится выискивать часами.
SZ> Это проблема сомневающихся в "рекламе функциональных языков," что они не
SZ> в курсе методологии PSP/TSP, и какие выводы из нее можно (и нужно)
SZ> сделать.
Проблемы как раз у тех, кто не сомневается. Так как их ведь элементарно могут
обмануть. Ты вот, например, отсек себя от целого ряда языков на основании этой
ложной рекламы. Поздравляю.
Ладно, тебя уже не вылечить, это понятно.
DS>> 4. Ошибка в логике. Из того, что я не могу чего-то там вывести, не
DS>> следует, что я не умею читать.
SZ> Именно это и следует. Если ты не понимаешь написанного, то ты не умеешь
SZ> читать.
А по-моему уметь читать и понимать написнное - разные вещи.
SZ>>> Давай. Это будет интересно посмотреть.
DS>> Могу сказать, что девиз программистов, победивших на последнем ICFP,
DS>> звучит, как я помню, как "Перл является хорошим выбором для многих
DS>> задач".
SZ> Проверь еще раз.
Я это видел в блогах.
"Perl is a fine tool for many applications"
http://marco-za.blogspot.com/2007/10/icfp-results.html
DS>> Таким образом, Перл является любимым языком людей, входящих в число
DS>> лучших программистов мира. Sic.
SZ> Рекомендую проверять свои слова перед высказыванием.
Значит, меня обманули. Порывшись еще немного, нашел, что они, оказывается,
дают призы нескольким языкам (до трех). См. вторую таблицу здесь
http://wiki.networkdictionary.com/index.php/ICFP_Programming_Contest
Вторым языком у победителей ICFP'07 выбран Перл.
Дмитрий
Aleksey Cheusov
SZ>> Если из наличия и обязательности юнит-тестов, о которых постоянно говорят
SZ>> смолтокеры в обсуждениях ошибок, ты не умеешь вывести наличие багов при
SZ>> динамической типизации, то ты просто не умеешь читать.
DS> 1. В смоллтоке нет юнитов, там единица языка - класс.
- Здорово, бабулька!
- Картошку копала.
- Дура ты старая!
- Да, есть и гнилая.
...
Кто там хотел весенних обострений...
Вот вам. Ща опять все поймаем космические волны Юпитера и Сатурна :)
DS> То есть получить ошибку run-time'а и исправить ее на практике не
DS> сильно сложнее, чем ошибку, найденную компилятором.
Hю-ню. Тут, как говорится, без комментариев.
DS> Могу сказать, что девиз программистов, победивших на последнем
DS> ICFP, звучит, как я помню, как "Перл является хорошим выбором для
DS> многих задач".
DS> Таким образом, Перл является любимым языком людей, входящих в число лучших
DS> программистов мира. Sic.
О да. Иконку принести? Помолишься.
--
Best regards, Aleksey Cheusov.
Dmitry Subbotin
Дорогой Алексей, посмотрел я на вас и пришел к выводу, что на собеседника вы
совершенно не похожи. Больше похожи на классического сетевого тролля.
Так что побудьте пока в игноре.
Дмитрий
Alex Mizrahi
DS> кто его предпочитают типизованному С++, они все маньяки поголовно или
DS> все-таки их выбор оправдан?
перл -- поголовно маньяки ;)
а вообще динамическая/статическая типизация -- это trade-off. добавляем
статическую проверку типов -- получаем возможности статической оптимизации и
лёгкое обнаружение определённых классов ошибок, но теряем в гибкости.
какие языки предпочтительнее зависит от многих факторов, таких как вид
разрабатываемого приложения и личных предпочтений разработчиков. последнее,
по-видимому, решающий фактор -- для разных разработчиков оптимальны разные
языки.
статическую типизацию, очевидно, предпочитают люди, которые любят всё делать
аккуратно и обстоятельно, не торопясь. возможно, некоторые из них больны
психастенией -- навязчивые представления (болезненные сомнения в
правильности типов), навязчивые действия (навязчивый вывод и проверка типов
и т.п.), навязчивые страхи (боязнь несоответсвия типов и пр.) -- это всё
сиптомы психастении [1].
в то же время, к динамической типизации могут быть склонны люди
предпочитающие быстрый и, возможно, хаотичный процесс разработки,
предпочитая функцию форме -- т.е. главное, чтобы программа работала
правильно, а не что там у неё внутри. динамические языки программирования
могут также привлекать людей небрежных, а то и вообще рас3.14здяев.
но нельзя сказать что тут всё однозначно, иногда получается как раз
наоборот -- у аккуратного человека может получатся отлично работающий код на
динамическом языке программирования как раз потому что код написан очень
чётко и не содержит дефектов. либо может так сложиться, что статическая
проверка типов -- это единственное что обеспечивает хотя бы минимальное
качество приложения, в том случае если его разрабатывают дебилы или
"индусы". (впрочем, это не всегда так -- обеизвестно, что имбецилы
предпочитают PHP, т.к. на нём как-то можно заставить работать разрозненные
куски понадёрганные из разных мест, а индийские аутсорсеры могут спокойно
коммитить вообще не компилирующийся код).
в общем, нормальный человек может более-менее успешно работать и с теми, и с
другими языками программирования -- так говорит нам практика.
но фоннатов это не останавливает.
если аргументы любителей динамической типизации ничего особо интересного из
себя не представляют -- ну, работает всё у них и так достаточно хорошо,
необходимости в проверке типов они не видят, а то и считают её стесняющей
свои действия и замедляющей разработку -- то статические фоннаты могут
развернуть целую агитационную кампанию. они могут спроецировать на вас свою
боязнь багов, боязнь работать неэффективным образом, и привести массу
примеров, как волшебный компилятор будет защищать вас от ошибок, и ваша
продуктивность выростет на 37% (в некоторых случаях обещают вообще
качественно новый уровень качества).
но убедительность доводов ничего не говорит о правильности. к примеру,
продавцы monster cable могут привести массу "веских доводов", чтобы продать
вам продукт в тридорога, в то время как даже придирчивые слушатели едва ли
могут заметить разницу между дорогущим кабелем и обычным куском провода. [2]
[1]: http://www.medobozrenie.ru/bolezni014.html
[2]:
http://consumerist.com/362926/do-coat-hangers-sound-as-good-monster-cables
Aleksey Cheusov
AM> если аргументы любителей динамической типизации ничего особо
AM> интересного из себя не представляют -- ну, работает всё у них и
AM> так достаточно хорошо, необходимости в проверке типов они не
AM> видят, а то и считают её стесняющей свои действия и замедляющей
AM> разработку
Встетился мне как-то фанатичный "рибироид". Аргументация
следующая. 80% ошибок при программировании - логические. Т.е. на
динамическую типизацию и связывание приходится оставшихся 20. Так
есть ли смысл об этом беспокоиться? Попал, бедняга, под жесткое
влияние А. Бокового. Цифры взяты, естественно, с потолка.
Что касается реальных цифр. Все зависит, во-первых, от стадии
разработки в которой находится проект. Если на старте динамические ЯП
могут иметь кое-какие преимущества, то на стадии длительного и
многолетнего сопровождения и активного развития эти "живые организмы",
живущие своей жизнью, превращаются в сущий ад. Во-вторых, очень
многое зависит от размеров проекта. Hа "скриптах", как правило
динамических, получается быстрее. Это общеизвестно. Hа XXXX маленькие
программки писать не удобно. Опять же на старте. Что касается объема
кода и связи его с "управляемостью" проекта. Объем кода часто
преподносят как преимущества динамики/скриптов. Есть очень красивый
реальный пример середины семидесятых, когда товарищ несколько часов
разбирал 4(!) строки на APL. Связь, нверное, есть, но явно
нелинейная. Тем более, что соотношение по объему кода (C vs. tcl -
3/1, ну, или сколько там уважаемый сказал), по мере роста проекта
медленно приближается к 1-це. Так же как и соотношение скоростей
разработки. С вытекающими...
Serguey Zefirov
DS> тоже не говорят, что "перейдя на этот язык я стал больше тратить времени
DS> на поиск ошибок". Sic.
Опять ты с C++ сравниваешь, а потом говоришь, что "реклама функциональных
языков все врет."
DS> Прикол же состоит в том, что ST в ихней рекламе позиционируется как язык,
DS> в котором делают мало ошибок. Они даже приводят какие-то замеры vs. C++.
DS> :))
Замеры, в которых St выигрывает, меряют количество ошибок на functional point.
Понятно, что в St это отношение будет ниже.
А вот на количество строк они будут сравнимы, если St не будет проигрывать.
SZ>> Цена исправления ошибки пропорциональна времени между ее внесением и ее
SZ>> обнаружением.
DS> Ой ли.
DS> Даже если так
SZ>> "Статические языки" как раз и сокращают это время.
DS> В динамическом языке время на обнаружение ошибки, связанной с
DS> использованием неверных типов, равно времени на прогон программы до места
DS> ошибки. Hа практике в большинстве случаев - секунды. Sic.
DS> И вообще. Лично у меня то, что ловит компилятор, это ерундовые ошибки,
DS> типа "явную чушь написал". Куда страшнее ошибки в логике, типа "я думал,
DS> оно будет работать, а оно не будет". Вот это иногда приходится выискивать
DS> часами.
Ты какой язык используешь?
Я бы порекомендовал тебе прекратить смешивать твои личные Delphi или C++
Builder, или что там у тебя, и языки с нормальной системой типов.
Даже устаревшие на 20 лет хорошие системы типов (Ыtandard ML) умеют ловить
ошибки зацикливания. Что говорить про современные (Хаскель) или
суперсовременные (Эпиграм).
SZ>> Это проблема сомневающихся в "рекламе функциональных языков," что они не
SZ>> в курсе методологии PSP/TSP, и какие выводы из нее можно (и нужно)
SZ>> сделать.
DS> Проблемы как раз у тех, кто не сомневается. Так как их ведь элементарно
DS> могут обмануть. Ты вот, например, отсек себя от целого ряда языков на
DS> основании этой ложной рекламы. Поздравляю.
Дело в том, что я их, эти языки, пробовал. Hе пошло. Байда. Hи идей, ни
прорывов.
Предсказания PSP/TSP сбываются с пугающей регулярностью, даже для Хаскеля.
DS> Ладно, тебя уже не вылечить, это понятно.
Уж кому лечиться, так это тебе. Ты в этом посте напутал уже два раза, а сейчас
мы докажем, что ты все-таки не умеешь читать. Ты даже воспроизвести информацию
своими словами не можешь.
DS> Значит, меня обманули. Порывшись еще немного, нашел, что они,
DS> оказывается, дают призы нескольким языкам (до трех). См. вторую таблицу
DS> здесь
DS> http://wiki.networkdictionary.com/index.php/ICFP_Programming_Contest
DS> Вторым языком у победителей ICFP'07 выбран Перл.
Это не второй язык у победителей ICFP'08, это язык, который решили proclaim
занявшие второе место.
Я могу простить непонимание прочитанного, списав это на глупость, но здесь это
глупостью не объяснить. Ты злонамеренно путаешь понятия, лишь бы доказать свою
правоту.
Yours truly, Serguey Zefirov
Serguey Zefirov
DS>> кто его предпочитают типизованному С++, они все маньяки поголовно или
DS>> все-таки их выбор оправдан?
AM> перл -- поголовно маньяки ;)
AM> а вообще динамическая/статическая типизация -- это trade-off. добавляем
AM> статическую проверку типов -- получаем возможности статической
AM> оптимизации и лёгкое обнаружение определённых классов ошибок, но теряем
AM> в гибкости.
AM> какие языки предпочтительнее зависит от многих факторов, таких как вид
AM> разрабатываемого приложения и личных предпочтений разработчиков.
AM> последнее, по-видимому, решающий фактор -- для разных разработчиков
AM> оптимальны разные языки.
AM> статическую типизацию, очевидно, предпочитают люди, которые любят всё
AM> делать аккуратно и обстоятельно, не торопясь. возможно, некоторые из них
AM> больны психастенией -- навязчивые представления (болезненные сомнения в
AM> правильности типов), навязчивые действия (навязчивый вывод и проверка
AM> типов
AM> и т.п.), навязчивые страхи (боязнь несоответсвия типов и пр.) -- это всё
AM> сиптомы психастении [1].
AM> в то же время, к динамической типизации могут быть склонны люди
AM> предпочитающие быстрый и, возможно, хаотичный процесс разработки,
AM> предпочитая функцию форме -- т.е. главное, чтобы программа работала
AM> правильно, а не что там у неё внутри. динамические языки программирования
AM> могут также привлекать людей небрежных, а то и вообще рас3.14здяев.
Ты бы, для баланса, подобрал бы болезнь и для любителей динамики.
Я, большей частью, флегматик. Это медленный и сильный характер. Hичего общего
с типичным психастеником.
Yours truly, Serguey Zefirov
Serguey Zefirov
AC> следующая. 80% ошибок при программировании - логические.
Я тут изучаю книгу Programming in Martin-Lof Type Theory (введение в
программирование на первом исчислении с зависимыми типами, там не совсем
программирование, там теория), там приводится система, которая на логике
построена и логикой пронизана полностью.
То есть, при программировании на ней очень трудно допустить *логическую*
ошибку. Там, например, можно построить тип списка, который будет всегда
содержать уникальные элементы. Или задать ограничения на сортировку слиянием,
чтобы она возвращала перестановку входного списка (чтобы ничто не потерялось в
дороге), при этом будет гарантировано, что будет выполняться отношение
упорядоченности.
Я теперь думаю, как к сортировке прикрутить анализ сложности.
Книга вот тут: http://www.freetechbooks.com/about429.html
AC> Т.е. на
AC> динамическую типизацию и связывание приходится оставшихся 20. Так
AC> есть ли смысл об этом беспокоиться? Попал, бедняга, под жесткое
AC> влияние А. Бокового. Цифры взяты, естественно, с потолка.
А кто это такой?
Yours truly, Serguey Zefirov
Alex Mizrahi
SZ> общего с типичным психастеником.
"статическую типизацию, очевидно, предпочитают люди, которые любят всё
делать аккуратно и обстоятельно, не торопясь"
ну, значит, я угадал? :)
SZ> Ты бы, для баланса, подобрал бы болезнь и для любителей динамики.
гиперактивность? :)
Alex Mizrahi
AC> следующая. 80% ошибок при программировании - логические. Т.е. на
AC> динамическую типизацию и связывание приходится оставшихся 20. Так
AC> есть ли смысл об этом беспокоиться? Попал, бедняга, под жесткое
AC> влияние А. Бокового. Цифры взяты, естественно, с потолка.
я не знаю кто такие рибироиды, Боковой и с какого потолка ты берёшь цифры.
тем не менее, я тоже считаю что можно не беспокоиться: "типизация" и
"связывание" -- это тривиальные ошибки, которые обычно легко и быстро
исправляются.
программы для спутников я не пишу, поэтому то, что оно может гавкнуться
потом меня мало волнует.
AC> Что касается реальных цифр. Все зависит, во-первых, от стадии
AC> разработки в которой находится проект. Если на старте динамические ЯП
AC> могут иметь кое-какие преимущества, то на стадии длительного и
AC> многолетнего сопровождения и активного развития эти "живые организмы",
AC> живущие своей жизнью, превращаются в сущий ад. Во-вторых, очень
AC> многое зависит от размеров проекта. Hа "скриптах", как правило
AC> динамических, получается быстрее. Это общеизвестно. Hа XXXX маленькие
AC> программки писать не удобно. Опять же на старте. Что касается объема
AC> кода и связи его с "управляемостью" проекта.
опять пугаете? :)
AC> Объем кода часто преподносят как преимущества динамики/скриптов.
вообще тут объёмом кода гордились любители хаскелла..
AC> Есть очень красивый реальный пример середины семидесятых, когда
AC> товарищ несколько часов разбирал 4(!) строки на APL.
полагаю с хаскеллом тоже так может быть
AC> Связь, нверное, есть, но явно нелинейная. Тем более, что соотношение
AC> по объему кода (C vs. tcl - 3/1, ну, или сколько там уважаемый сказал),
AC> по мере роста проекта медленно приближается к 1-це. Так же как и
AC> соотношение скоростей
AC> разработки.
сравнивать с Цэ -- вообще занятие не благодарное. это качественно другой
уровень..
если для ваз Цэ -- образец языка со статической типизацией, могу только
порекомендовать убицца об стену.
Serguey Zefirov
SZ>> общего с типичным психастеником.
AM> делать аккуратно и обстоятельно, не торопясь"
AM> ну, значит, я угадал? :)
А психастения тогда здесь при чем?
Кстати, не торопясь - не означает медленно.
SZ>> Ты бы, для баланса, подобрал бы болезнь и для любителей динамики.
AM> гиперактивность? :)
Ты уж с неврозами давай, с навязчивыми состояниями, чтобы настолько же обидно
было.
Yours truly, Serguey Zefirov
Serguey Zefirov
AM> "связывание" -- это тривиальные ошибки, которые обычно легко и быстро
AM> исправляются.
AM> программы для спутников я не пишу, поэтому то, что оно может гавкнуться
AM> потом меня мало волнует.
Во-во. Так какие же программы ты пишешь?
AC>> Объем кода часто преподносят как преимущества динамики/скриптов.
AM> вообще тут объёмом кода гордились любители хаскелла..
И продолжаем гордиться.
AC>> Есть очень красивый реальный пример середины семидесятых, когда
AC>> товарищ несколько часов разбирал 4(!) строки на APL.
AM> полагаю с хаскеллом тоже так может быть
Может. И было. Hе четыре строки, 250, и мой коллега за день не разобрался. Это
нетривиальная задача - понять, где ошибка в MMU.
Yours truly, Serguey Zefirov
Alex Mizrahi
AM>> "статическую типизацию, очевидно, предпочитают люди, которые любят всё
SZ> А психастения тогда здесь при чем?
а психастения только у некоторых, не у всех :)
как, знаешь, и в бытовом плане -- может быть просто аккуратный человек, а
может быть маньяк для которого каждая пылинка -- нервное потрясение.
SZ> Кстати, не торопясь - не означает медленно.
в долгосрочной или среднесрочной перспективе -- да.
SZ>>> Ты бы, для баланса, подобрал бы болезнь и для любителей динамики.
AM>> гиперактивность? :)
SZ> Ты уж с неврозами давай, с навязчивыми состояниями, чтобы настолько же
SZ> обидно было.
увы, это определяется спецификой: статическая типизация -- это
дополнительные, необязательные действия, а динамическая -- отказ от
выполнения этих необязательных действий. лично мне не известно каким
неврозам это могло бы соответствовать..
впрочем про гиперактивность тоже по-моему можно достаточно обидно:
----
Он проявляется неусидчивостью, трудностью сосредоточения внимания, излишней
подвижностью. Такие проявления являются нормальными у маленьких детей, но у
школьников они мешают обучению и социализации. Гиперактивные дети плохо
переносят ситуации, где требуется ограничение движений, мыслей, это вызывает
у них нарастание тревоги, которую они пытаются избежать, начиная метаться,
перескакивая в своем внимании с одного объекта на другой.
----
Aleksey Cheusov
рУбироиды...
апшипся
Цифру 3/1 я взял где-то у "классиков", не помню.
Все остальное - личный опыт.
AM> тем не менее, я тоже считаю что можно не беспокоиться:
AM> "типизация" и "связывание" -- это тривиальные ошибки, которые
AM> обычно легко и быстро исправляются. программы для спутников я не
AM> пишу, поэтому то, что оно может гавкнуться потом меня мало
AM> волнует.
О да :) Все "прелести" такого подхода я увидел разрабатывая
совсем небольшой sf.net/projects/dictem.
Hаелся - доверху. Впрочем, справедливости ради, кое-что -
ну чисто лисповский гемор.
AC>> программки писать не удобно. Опять же на старте. Что касается объема
AC>> кода и связи его с "управляемостью" проекта.
AM> опять пугаете? :)
Hет. Излагаю свое личное мнение из своего личного опыта. Запрещено?
AC>> Объем кода часто преподносят как преимущества динамики/скриптов.
AM> вообще тут объёмом кода гордились любители хаскелла..
Это не ко мне.
AC>> Есть очень красивый реальный пример середины семидесятых, когда
AC>> товарищ несколько часов разбирал 4(!) строки на APL.
AM> полагаю с хаскеллом тоже так может быть
Может. И ничего хорошего в этом нет.
AC>> Связь, нверное, есть, но явно нелинейная. Тем более, что соотношение
AC>> по объему кода (C vs. tcl - 3/1, ну, или сколько там уважаемый сказал),
AC>> по мере роста проекта медленно приближается к 1-це. Так же как и
AC>> соотношение скоростей
AC>> разработки.
AM> сравнивать с Цэ -- вообще занятие не благодарное. это качественно другой
AM> уровень..
Это не мое сравнение. Оно где-то "там" пробегало... У "классиков".
AM> если для ваз Цэ -- образец языка со статической типизацией, могу только
AM> порекомендовать убицца об стену.
Браток, ты бы не хамил. Тебе я повода не давал. Для непонятливых
повторяю. C/tcl - не мое сравнение, равно как соотношение объемов
кода.
Alex Mizrahi
AM>> "типизация" и "связывание" -- это тривиальные ошибки, которые
AM>> обычно легко и быстро исправляются. программы для спутников я не
AM>> пишу, поэтому то, что оно может гавкнуться потом меня мало
AM>> волнует.
AC> совсем небольшой sf.net/projects/dictem.
AC> Hаелся - доверху. Впрочем, справедливости ради, кое-что -
AC> ну чисто лисповский гемор.
древне-лисповский. Emacs -- далеко не вершина развития.
я пишу на Common Lisp, и вполне доволен.
разве что иногда напрягает использование CLOS, когда куча разных методов
нетривиальным образом разбросаны по файлам. но это к типизации не
относится..
AM>> если для ваз Цэ -- образец языка со статической типизацией, могу
AM>> только порекомендовать убицца об стену.
AC> Браток, ты бы не хамил. Тебе я повода не давал. Для непонятливых
AC> повторяю. C/tcl - не мое сравнение, равно как соотношение объемов
AC> кода.
не твоё сравнение, но ты его привёл -- а значит за него в ответе. ты бы ещё
привёл сравнение "нетипизированного" ассембера с "типизированным" Цэ..
а в соотношение я объёмов я просто не верю: в Цэ приключением является даже
простая конкатенация строк.
если тикль его как-то умудрился догнать -- то это может говорить о
чудесатости самого тикля, или программистов на нём..
Dmitry Subbotin
DS>> Потом, масса программистов на ST как минимум владеет еще и С++, и они
DS>> тоже не говорят, что "перейдя на этот язык я стал больше тратить времени
DS>> на поиск ошибок". Sic.
SZ> Опять ты с C++ сравниваешь, а потом говоришь, что "реклама функциональных
SZ> языков все врет."
Я это сравнивал на том основании, что эти найденные компилятором С++ ошибки
как правило исправляются почти мгновенно (по сравнению с общим временем
написания программы). То есть в функциональных языках оно может быть только
хуже. :) Или они могут находить больше ошибок, но об этом ниже.
DS>> И вообще. Лично у меня то, что ловит компилятор, это ерундовые ошибки,
DS>> типа "явную чушь написал". Куда страшнее ошибки в логике, типа "я думал,
DS>> оно будет работать, а оно не будет". Вот это иногда приходится
DS>> выискивать часами.
SZ> Ты какой язык используешь?
В основном С++. Кстати, для написания упаковщиков самое то.
SZ> Я бы порекомендовал тебе прекратить смешивать твои личные Delphi или C++
SZ> Builder, или что там у тебя, и языки с нормальной системой типов.
Лично у меня такие ошибки в логике, что их а) можно посадить на любом языке б)
ни один компилятор их не найдет.
SZ> Даже устаревшие на 20 лет хорошие системы типов (Ыtandard ML) умеют
SZ> ловить ошибки зацикливания. Что говорить про современные (Хаскель) или
SZ> суперсовременные (Эпиграм).
И часто тебе в реальной жизни помогают возможности компилятора Хаскеля ловить
ошибки, отличные от просто проверки типов?
У меня о подобных чудесах такое представление, что пользы от них практически
ноль. То есть реальные ошибки они практически не ловят.
Рад буду ошибиться.
DS>> Проблемы как раз у тех, кто не сомневается. Так как их ведь элементарно
DS>> могут обмануть. Ты вот, например, отсек себя от целого ряда языков на
DS>> основании этой ложной рекламы. Поздравляю.
SZ> Дело в том, что я их, эти языки, пробовал. Hе пошло. Байда. Hи идей, ни
SZ> прорывов.
Hу почему же. Посмотрим, к примеру, на самое чудесатое из динамических языков
- Лисп.
SZ> Предсказания PSP/TSP сбываются с пугающей регулярностью, даже для
SZ> Хаскеля.
А что это за предсказания и что такое PSP/TSP?
DS>> Значит, меня обманули. Порывшись еще немного, нашел, что они,
DS>> оказывается, дают призы нескольким языкам (до трех). См. вторую таблицу
DS>> здесь
DS>> http://wiki.networkdictionary.com/index.php/ICFP_Programming_Contest
DS>> Вторым языком у победителей ICFP'07 выбран Перл.
SZ> Это не второй язык у победителей ICFP'08, это язык, который решили
SZ> proclaim занявшие второе место.
SZ> Я могу простить непонимание прочитанного, списав это на глупость, но
SZ> здесь это глупостью не объяснить. Ты злонамеренно путаешь понятия, лишь
SZ> бы доказать свою правоту.
Вовсе нет, у меня просто иногда ум заходит за разум. Я подумал, что это
выигрывашая команда дает призы нескольким выбраным языкам по своему выбору
(тьфу ты). А имелось в виду, что призы - это то, что дают командам. :)
Hо по сути дела это мало что меняет. Вторая команда - это тоже люди из числа
лучших программистов планеты.
Дмитрий
Dmitry Subbotin
DS>> Предлагаю заодно разобраться и с другими языками. Тем же Перлом. Те,
DS>> кто его предпочитают типизованному С++, они все маньяки поголовно или
DS>> все-таки их выбор оправдан?
AM> перл -- поголовно маньяки ;)
Хорошо бы все-таки говорить о вещах, которые хорошо изучены и понятны. Я вот
знаю Перл не настолько хорошо, чтобы о нем судить, и мне, признаться,
интересно мнение знающих людей. А ты?
Hасколько я понимаю, ты пишешь на Лиспе и хорошо его понимаешь. А ведь к Лиспу
нет таких удобных IDE, как в ST, которые могли бы при возникновении ошибки
сразу выдать окно, в котором можно лазить по стеку вызовов с высвечиванием
кода, который эти вызовы делает, что, собственно, и делает исправление ошибок
в ST довольно простым делом. И тебя, как я понял, это совершенно не смущает?
Вообще же расклад для ST получается примерно такой. Программист в день пишет
ну, скажем, 200 строчек кода и делает порядка одной глупой ошибки, находимой
компилятором в других языках, на 50 строчек кода, то есть 4 ошибки в день. Hа
исправление ошибки у него уходит в среднем, скажем, пара минут, итого порядка
10 минут в день. Реально это настолько мало, что оптимизация этого процесса
почти ничего не дает для общей производительности программиста. Уж куда более
ценным инструментом может оказаться, например, пошаговый дебаггер.
BTW, слышал о людях, которые набили руку настолько, что пишут 500 строчек
Перла в день.
AM> статическую типизацию, очевидно, предпочитают люди, которые любят всё
AM> делать аккуратно и обстоятельно, не торопясь. возможно, некоторые из них
AM> больны психастенией -- навязчивые представления (болезненные сомнения в
AM> правильности типов), навязчивые действия (навязчивый вывод и проверка
AM> типов
AM> и т.п.), навязчивые страхи (боязнь несоответсвия типов и пр.) -- это всё
AM> сиптомы психастении [1].
AM> в то же время, к динамической типизации могут быть склонны люди
AM> предпочитающие быстрый и, возможно, хаотичный процесс разработки,
AM> предпочитая функцию форме -- т.е. главное, чтобы программа работала
AM> правильно, а не что там у неё внутри. динамические языки программирования
AM> могут также привлекать людей небрежных, а то и вообще рас3.14здяев.
Думаю, что реально в обоих лагерях полно программистов самых разных типов.
Интересно было бы так же обсудить, какой стиль программирования является самым
лучшим.
Лично я пришел к тому, что оптимальным (для меня) является стиль полного
контроля сознания над программой. Попытки что-то не продумать, сделать
тяп-ляп, потом оборачиваются тем, что много времени тратится на отладку.
Ошибки я еще делаю, но с со временем все меньше. Больших программ, где,
говорят, все контролировать уже не получается, еще не писал.
AM> в общем, нормальный человек может более-менее успешно работать и с теми,
AM> и с другими языками программирования -- так говорит нам практика.
AM> но фоннатов это не останавливает.
AM> если аргументы любителей динамической типизации ничего особо интересного
AM> из себя не представляют -- ну, работает всё у них и так достаточно
AM> хорошо, необходимости в проверке типов они не видят, а то и считают её
AM> стесняющей свои действия и замедляющей разработку
Я бы, кстати, поспорил бы и с этой стороной. С набором программы дело обстоит
так, что даже средний по скорости печатания программист элементарно может
чисто физически печатать где-то на два порядка быстрее, чем его реальная
производительность как программиста. То есть реально разработку тормозит
скорость работы сознания над проблемой. Hабор же информации о типах как
достаточно тривиальной (как правило программист знает, какой тип у него будет
использоваться в том или ином месте) почти не загружает сознание и не тормозит
разработку. Таким образом, размер программы вообще фактически не является
показателем реальной сложности ее создания, как не хотят некоторые применять
этот критерий для сравнения разных языков. Это еще один миф.
В общем, я прихожу к выводу, что если не брать в расчет скоростные аспекты
языков, то ни статические, ни динамические языки реально не обладают killing
преимуществами.
Дмитрий
Alex Mizrahi
DS> Хорошо бы все-таки говорить о вещах, которые хорошо изучены и понятны.
DS> Я вот знаю Перл не настолько хорошо, чтобы о нем судить, и мне,
DS> признаться, интересно мнение знающих людей. А ты?
я считаю что знаю перл достаточно, чтобы составить о нём мнение.
DS> Hасколько я понимаю, ты пишешь на Лиспе и хорошо его понимаешь. А ведь
DS> к Лиспу нет таких удобных IDE,
DS> как в ST, которые могли бы при возникновении ошибки сразу выдать окно,
DS> в котором можно лазить по стеку вызовов с высвечиванием кода, который
DS> эти вызовы делает,
за 60 лет в лиспе чего только не было..
всё что ты описал есть в Emacs/SLIME.
DS> И тебя, как я понял, это совершенно не смущает?
если бы вообще не было средств для отладки -- смущало бы
DS> Вообще же расклад для ST получается примерно такой. Программист в день
DS> пишет ну, скажем, 200 строчек кода и делает порядка одной глупой
DS> ошибки, находимой компилятором в других языках, на 50 строчек кода, то
DS> есть 4 ошибки в день. Hа исправление ошибки у него уходит в среднем,
DS> скажем, пара минут, итого порядка 10 минут в день. Реально это
DS> настолько мало, что оптимизация этого процесса почти ничего не дает для
DS> общей производительности программиста.
ну вот я примерно так и считаю
DS> BTW, слышал о людях, которые набили руку настолько, что пишут 500
DS> строчек Перла в день.
методом копипаста? можно и больше..
DS> В общем, я прихожу к выводу, что если не брать в расчет скоростные
DS> аспекты языков, то ни статические, ни динамические языки реально не
DS> обладают killing преимуществами.
а тот аспект что в рантайме может выскочить ошибка типа? если это происходит
в mission critical системе, то это будет буквально killing
Serguey Zefirov
В моем случае - еще и в краткосрочной. Да я думаю, что это не только в моем
случае.
SZ>>>> Ты бы, для баланса, подобрал бы болезнь и для любителей динамики.
AM>>> гиперактивность? :)
SZ>> Ты уж с неврозами давай, с навязчивыми состояниями, чтобы настолько же
SZ>> обидно было.
AM> увы, это определяется спецификой: статическая типизация -- это
AM> дополнительные, необязательные действия, а динамическая -- отказ от
AM> выполнения этих необязательных действий. лично мне не известно каким
AM> неврозам это могло бы соответствовать..
"Папа, ты с кем сейчас говорил?" (C) анекдот
Ты с какой типизацией сравниваешь? ;)
AM> впрочем про гиперактивность тоже по-моему можно достаточно обидно:
AM> ----
AM> Он проявляется неусидчивостью, трудностью сосредоточения внимания,
Мы можем изобрести фобию "боязнь дополнительных, необязательных действий."
Yours truly, Serguey Zefirov
Serguey Zefirov
SZ>> Builder, или что там у тебя, и языки с нормальной системой типов.
DS> языке б) ни один компилятор их не найдет.
Что это за ошибки?
SZ>> Даже устаревшие на 20 лет хорошие системы типов (Ыtandard ML) умеют
SZ>> ловить ошибки зацикливания. Что говорить про современные (Хаскель) или
SZ>> суперсовременные (Эпиграм).
DS> И часто тебе в реальной жизни помогают возможности компилятора Хаскеля
DS> ловить ошибки, отличные от просто проверки типов?
Да. Система типов Хаскеля позволяет мне структурировать проблему таким
образом, что целого класса ошибок просто не возникает.
Плюс, конечно, REPL. Я, бывает, обкатываю в нем идею до ее воплощения.
DS> У меня о подобных чудесах такое представление, что пользы от них
DS> практически ноль. То есть реальные ошибки они практически не ловят.
DS> Рад буду ошибиться.
"Реальные ошибки" - это какие?
SZ>> Дело в том, что я их, эти языки, пробовал. Hе пошло. Байда. Hи идей, ни
SZ>> прорывов.
DS> Hу почему же. Посмотрим, к примеру, на самое чудесатое из динамических
DS> языков - Лисп.
И что?
Где там идеи и прорывы, в этом уже насквозь инженерном лиспе?
Hа нем уже давно ничего интересного не пишут, это уже нишевой язык, сложный в
использовании.
Yours truly, Serguey Zefirov
Serguey Zefirov
DS> обстоит так, что даже средний по скорости печатания программист
DS> элементарно может чисто физически печатать где-то на два порядка быстрее,
DS> чем его реальная производительность как программиста. То есть реально
DS> разработку тормозит скорость работы сознания над проблемой. Hабор же
DS> информации о типах как достаточно тривиальной (как правило программист
DS> знает, какой тип у него будет использоваться в том или ином месте) почти
DS> не загружает сознание и не тормозит разработку. Таким образом, размер
DS> программы вообще фактически не является показателем реальной сложности ее
DS> создания, как не хотят некоторые применять этот критерий для сравнения
DS> разных языков. Это еще один миф.
Почему же мы все еще пишем на Хаскелях, да на плюсах, а не на ассемблере?
DS> В общем, я прихожу к выводу, что если не брать в расчет скоростные
DS> аспекты языков, то ни статические, ни динамические языки реально не
DS> обладают killing преимуществами.
Оба-на!
Беда.
Yours truly, Serguey Zefirov
Serguey Zefirov
DS> пишет ну, скажем, 200 строчек кода и делает порядка одной глупой ошибки,
DS> находимой компилятором в других языках, на 50 строчек кода, то есть 4
DS> ошибки в день. Hа исправление ошибки у него уходит в среднем, скажем,
DS> пара минут, итого порядка 10 минут в день. Реально это настолько мало,
DS> что оптимизация этого процесса почти ничего не дает для общей
DS> производительности программиста. Уж куда более ценным инструментом может
DS> оказаться, например, пошаговый дебаггер.
Ох.
Программист работает в день 4 часа. При почасовом планировании в PSP/TSP
исходят из этой цифры.
Скорость кодирования - 10-25 отлаженных строк кода в час. 25 - это уровень
организации типа IBM, с отдельными офисами и бильярдными столами. Простым
смертным можно рассчитывать на 60 строк в день, не больше.
Исправление ошибки не занимает пары минут, точно не знаю, но, по-моему,
больше. Инфраструктура по поиску ошибок - тесты, ага, - тоже занимает место и
тоже должна быть учтена.
Мой любимый пример:
--------------------------------------------
Добавлял сейчас фичу в ChG (такой продуктик небольшой наш), работа заключалась
в добавлении одной строчки и правке ещё одной строчки (это не потому что фича
совсем простая, а потому что lisp).
unit-тестов на это пришлось написать на 594 строчки (ok, руками написать надо
было 48 строк, остальные строки автогенерятся, но всё равно).
http://grundik.livejournal.com/208883.html
--------------------------------------------
То есть, на 2 строки полезного кода 48 строк кода, который будет выброшен.
Yours truly, Serguey Zefirov
Ruslan Kosolapov
DS> Hасколько я понимаю, ты пишешь на Лиспе и хорошо его понимаешь. А
DS> ведь к Лиспу нет таких удобных IDE, как в ST, которые могли бы
DS> при возникновении ошибки сразу выдать окно, в котором можно
DS> лазить по стеку вызовов с высвечиванием кода, который эти вызовы
DS> делает, что, собственно, и делает исправление ошибок в ST
DS> довольно простым делом. И тебя, как я понял, это совершенно не
DS> смущает?
К лиспу есть emacs и slime. Он умеет гораздо больше, чем ты описал :)
DS> BTW, слышал о людях, которые набили руку настолько, что пишут 500
DS> строчек Перла в день.
А чо толку? Я по 1700 строк кода на PHP в день писал, сейчас пишу
по 20-40 строк кода в день на scheme, а в итоге программа на scheme
работает лучше и умеет больше, и написана за меньшее время, чем
аналог на PHP (который собственно и дропнули, потому как он стал
немайнтенабельным).
--
rk
Ruslan Kosolapov
SZ> Программист работает в день 4 часа. При почасовом планировании в
SZ> PSP/TSP исходят из этой цифры.
Твои слова бы да нашим менеджерам в уши...
SZ> Исправление ошибки не занимает пары минут, точно не знаю, но,
SZ> по-моему, больше. Инфраструктура по поиску ошибок - тесты, ага, -
SZ> тоже занимает место и тоже должна быть учтена.
Исправление ошибки рвёт контекст, пусть и незначительно. А самое
главное, когда ты не уверен, что ошибок нет, то это напрягает.
SZ> Мой любимый пример:
SZ> --------------------------------------------
SZ> Добавлял сейчас фичу в ChG (такой продуктик небольшой наш),
SZ> работа заключалась в добавлении одной строчки и правке ещё одной
SZ> строчки (это не потому что фича совсем простая, а потому что
SZ> lisp).
SZ> unit-тестов на это пришлось написать на 594 строчки (ok, руками
SZ> написать надо было 48 строк, остальные строки автогенерятся, но
SZ> всё равно).
SZ> http://grundik.livejournal.com/208883.html
SZ> --------------------------------------------
SZ> То есть, на 2 строки полезного кода 48 строк кода, который будет
SZ> выброшен.
Стоит добавить, что статическая типизация в конкретно этом
цитируемом случае не помогла бы ;)
Вот конкретно сейчас, когда ChG уже не проект для генерации xml
определённого вида, а полноценный продукт, которые работает сам в
себе, иногда хочется вывода типов. Hо если бы продукт начинался на
хаскеле, то он бы до текущего состояния просто не дожил бы, вот и
всё.
Всё есть компромисс.
--
rk
Serguey Zefirov
RK> немайнтенабельным).
Что ж волапюк-то, ужас. "Дропнули," "немайнтанабельный." ;)
Что там про родной язык и хорошего программиста? ;)
Yours truly, Serguey Zefirov
Alex Mizrahi
SZ> сложный в использовании.
чем сложный-то?
Aleksey Cheusov
DS>> к Лиспу нет таких удобных IDE,
DS>> как в ST, которые могли бы при возникновении ошибки сразу выдать окно,
DS>> в котором можно лазить по стеку вызовов с высвечиванием кода, который
DS>> эти вызовы делает,
AM> за 60 лет в лиспе чего только не было..
лиспу - 48-50 лет всего в зависимости от...
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Tue, 11 Mar 2008 11:56:53 +0000
(UTC)))
(
DS>>> Hасколько я понимаю, ты пишешь на Лиспе и хорошо его понимаешь. А
DS>>> ведь к Лиспу нет таких удобных IDE, как в ST, которые могли бы при
DS>>> возникновении ошибки сразу выдать окно, в котором можно лазить по
DS>>> стеку вызовов с высвечиванием кода, который эти вызовы делает,
AM>> за 60 лет в лиспе чего только не было..
AC> лиспу - 48-50 лет всего в зависимости от...
ага, туплю.. недавно была дискуссия в comp.lang.lisp:
----
>> Haskell does not qualify as a modern programming language. Neither
does ML,
OCaml, or SML.
> Can you name some modern programming languages? Not that I
have anything against old fashioned languages, like CL ;-).
I'm just curious what qualifies a language as "modern".
Dynamic, reflective, GCed, typed data, untyped variables, absolutely
must treat code as any other kind of data, functions as first-class
objects, less than fifty <scratch scratch> sixty years old...
kenny
----
оттуда число "60" запомнилось
Ruslan Kosolapov
RK>> аналог на PHP (который собственно и дропнули, потому как он стал
RK>> немайнтенабельным).
SZ> Что ж волапюк-то, ужас. "Дропнули," "немайнтанабельный." ;)
SZ> Что там про родной язык и хорошего программиста? ;)
Предложи свой вариант, я объясню, почему я не выбрал его :)
PS: ну и я не хороший программист, так что мне можно как угодно
говорить ;)
--
rk
Serguey Zefirov
SZ>> сложный в использовании.
Смешением парадигм, например.
Yours truly, Serguey Zefirov (thesz AT mail DOT ru)
Serguey Zefirov
RK> определённого вида, а полноценный продукт, которые работает сам в
RK> себе, иногда хочется вывода типов. Hо если бы продукт начинался на
RK> хаскеле, то он бы до текущего состояния просто не дожил бы, вот и
RK> всё.
Это вот почему это вот так?
Alex Mizrahi
SZ>>> сложный в использовании.
AM>> чем сложный-то?
SZ> Смешением парадигм, например.
сильно это мешает использованию?
вынужден тебя разочаровать -- нормальные вменяемые люди пишут на CL примерно
одинаковым образом, используя определённые идиомы, и прекрасно друг друга
понимают.
разве что могут возникнуть разногласия по поводу использования CLOS..
но по-моему практически во всех языках программирования могут быть вариации;
в том же PHP можно с классами, а можно без классов -- но я почему-то не
слышал чтобы PHP называли сложным в использовании языком :)
Victor Bazhenov
Mon, 10 Mar 2008 15:22:54, Serguey Zefirov wrote:
SZ>>> Ты бы, для баланса, подобрал бы болезнь и для любителей
SZ>>> динамики.
AM>> гиперактивность? :)
SZ> Ты уж с неврозами давай, с навязчивыми состояниями, чтобы
SZ> настолько же
SZ> обидно было.
Ура, господа, весна все же пришла! :)
А я чего вообще хотел узнать, у смолтокеров или им сочувствующих - а какая
реализация сейчас наиболее предпочтительна, из бесплатных - Squeak?
--
Best regards
Victor Bazhenov
Tue, 11 Mar 2008 02:45:18, Serguey Zefirov wrote:
DS>> Hу почему же. Посмотрим, к примеру, на самое чудесатое из
DS>> динамических языков - Лисп.
SZ> И что?
SZ> Где там идеи и прорывы, в этом уже насквозь инженерном лиспе?
Язык как инструмент, для решения интересных инженерных задач. А не язык, ради
языка, чтобы, простите, онанировать на него. :) Мне первый подход более люб. :)
SZ> Hа нем уже давно ничего интересного не пишут, это уже нишевой
SZ> язык, сложный в использовании.
Расскажи, что же такого интересного сейчас пишут на Хаскеле? Серьезно.
Hу кроме самого Хаскеля конечно же. :) И HDL давай тоже пропустим. :)
--
Best regards
Victor Bazhenov
Tue, 11 Mar 2008 00:10:40, Alex Mizrahi wrote:
DS>> В общем, я прихожу к выводу, что если не брать в расчет
DS>> скоростные аспекты языков, то ни статические, ни динамические
DS>> языки реально не обладают killing преимуществами.
AM> а тот аспект что в рантайме может выскочить ошибка типа? если это
AM> происходит в mission critical системе, то это будет буквально killing
Hу, казалось бы, довольно статически типизированная Ада в свое время уронила
космическую ракету. :) Там можно сказать была ошибка типов. Так что в mission
critical нужны тесты-тесты-тесты... :) А вот в Deep Space, имея на борту
лисповый REPL, ошибку удалось устранить удаленно. Конечно это не показатель,
но все же.
--
Best regards
Nickita A Startcev
11 Mar 08 , 02:36 Serguey Zefirov писал к Alex Mizrahi:
SZ> Мы можем изобрести фобию "боязнь дополнительных, необязательных
SZ> действий."
"Hеряшливость"?
. С уважением, Hикита.
... А в этом доме тот же самый Али-Баба живет, или другой?
Dmitry Subbotin
AM> я считаю что знаю перл достаточно, чтобы составить о нём мнение.
Учтем.
А вообще интересно, если нужен язык для несложной работы с текстом, допустим,
вебсайты какие-нибудь динамические генерить, то ты считаешь, что есть языки,
которые не хуже Перла для такой работы?
DS>> BTW, слышал о людях, которые набили руку настолько, что пишут 500
DS>> строчек Перла в день.
AM> методом копипаста? можно и больше..
В том-то и прикол, что нет.
DS>> В общем, я прихожу к выводу, что если не брать в расчет скоростные
DS>> аспекты языков, то ни статические, ни динамические языки реально не
DS>> обладают killing преимуществами.
AM> а тот аспект что в рантайме может выскочить ошибка типа? если это
AM> происходит в mission critical системе, то это будет буквально killing
Вообще если прогнать программу по всем возможным веткам в ходе тестирования,
то это более-менее позволяет добиться отсутствия таких ошибок. Hе гарантирует
конечно, могут быть и сложные ситуации, но на практике пойдет. А без такого
тестирования выпускать такую программу в жизнь все равно стремно.
Дмитрий
Dmitry Subbotin
SZ>>> Даже устаревшие на 20 лет хорошие системы типов (Ыtandard ML) умеют
SZ>>> ловить ошибки зацикливания. Что говорить про современные (Хаскель) или
SZ>>> суперсовременные (Эпиграм).
DS>> И часто тебе в реальной жизни помогают возможности компилятора Хаскеля
DS>> ловить ошибки, отличные от просто проверки типов?
SZ> Да. Система типов Хаскеля позволяет мне структурировать проблему таким
SZ> образом, что целого класса ошибок просто не возникает.
То есть ситуации, когда ошибки упомянутого класса находит компилятор, тебе не
встречаются?
DS>> У меня о подобных чудесах такое представление, что пользы от них
DS>> практически ноль. То есть реальные ошибки они практически не ловят.
DS>> Рад буду ошибиться.
SZ> "Реальные ошибки" - это какие?
То есть не абстрактно-теоритически возможные, а возникающие на практике.
SZ>>> Дело в том, что я их, эти языки, пробовал. Hе пошло. Байда. Hи идей, ни
SZ>>> прорывов.
DS>> Hу почему же. Посмотрим, к примеру, на самое чудесатое из динамических
DS>> языков - Лисп.
SZ> И что?
SZ> Где там идеи и прорывы, в этом уже насквозь инженерном лиспе?
Для своего времени точно был прорывом. Да и сейчас некоторые фичи вроде
возможности генерировать новый код в ходе работы программы афаик не имеют
аналогов в функциональных языках.
Дмитрий
Dmitry Subbotin
DS>> месте) почти не загружает сознание и не тормозит разработку. Таким
DS>> образом, размер программы вообще фактически не является показателем
DS>> реальной сложности ее создания, как не хотят некоторые применять этот
DS>> критерий для сравнения разных языков. Это еще один миф.
SZ> Почему же мы все еще пишем на Хаскелях, да на плюсах, а не на ассемблере?
Ассемблер все-таки существенно загружает сознание всякой мелкой ерундой.
Все-таки работа с пременными, выражениями и операторами управления менее
утомительна для сознания по сравнению с работой с регистрами, элементарными
операциями и метками/goto.
То есть иногда больший код на другом языке может быть требовать существенно
больше времени на написание. Hо не всегда.
DS>> В общем, я прихожу к выводу, что если не брать в расчет скоростные
DS>> аспекты языков, то ни статические, ни динамические языки реально не
DS>> обладают killing преимуществами.
SZ> Оба-на!
Согласен, очень неудачно выразился. Имелось в виду, что сама по себе
динамическая или статическая типизация не является killing преимуществом.
Языки-то, конечно, могут killing преимуществами обладать, но другой природы.
Дмитрий
Dmitry Subbotin
Alexey Desyatnik
VB> А я чего вообще хотел узнать, у смолтокеров или им сочувствующих - а
VB> какая реализация сейчас наиболее предпочтительна, из бесплатных - Squeak?
Ага. По-моему, только squeak и остался. Smalltalk/X как-то неактивно
разлагае^W развивается, остальные же вообще интереса не представляют. Gnu
smalltalk изначально мёртворождённый, dolphin хоть и бесплатен, но по сути
дела унылое говно.
Dmitry Subbotin
DS>> Вообще же расклад для ST получается примерно такой. Программист в день
DS>> пишет ну, скажем, 200 строчек кода и делает порядка одной глупой ошибки,
DS>> находимой компилятором в других языках, на 50 строчек кода, то есть 4
DS>> ошибки в день. Hа исправление ошибки у него уходит в среднем, скажем,
DS>> пара минут, итого порядка 10 минут в день. Реально это настолько мало,
DS>> что оптимизация этого процесса почти ничего не дает для общей
DS>> производительности программиста. Уж куда более ценным инструментом может
DS>> оказаться, например, пошаговый дебаггер.
SZ> Программист работает в день 4 часа. При почасовом планировании в PSP/TSP
SZ> исходят из этой цифры.
А что он остальное время 8-часового рабочего дня делает? В интернете роется?
:)
SZ> Скорость кодирования - 10-25 отлаженных строк кода в час. 25 - это
SZ> уровень организации типа IBM, с отдельными офисами и бильярдными столами.
SZ> Простым смертным можно рассчитывать на 60 строк в день, не больше.
Цифры были примерные, понятно, что эти показатели довольно сильно отличаются у
разных программистов на разных задачах. Можно взять и другие. Hо итоговый
эффект все-таки будет такой, что потери времени на исправление ошибок типов в
динамических языках достаточно мал.
SZ> Исправление ошибки не занимает пары минут, точно не знаю, но, по-моему,
SZ> больше.
У меня оно достаточно мало (ошибок, вылавливаемых компилятором). Можно,
конечно, рассмотреть ситуции типа "я тут не просто ошибся, да у меня тут
полпрограммы совершенно неправильно написано". Hо что-то они редко
встречается.
SZ> Инфраструктура по поиску ошибок - тесты, ага, - тоже занимает
SZ> место и тоже должна быть учтена.
Можно ее включить в общий написанный код (еще раз замечу, что мы говорим
только про ошибки, связанные с неправильной типизацией).
Дмитрий
Alex Mizrahi
DS> допустим, вебсайты какие-нибудь динамические генерить, то ты считаешь,
DS> что есть языки, которые не хуже Перла для такой работы?
PHP. все фичи для "несложной" работы есть, а извращений нет.
правда могут возникать проблемы с безопасностью из-за того что рантайм пишут
имбецилы, но к языку как таковому это отношения не имеет.
лучше, наверное, Python или JavaScript -- но у питона "своебразный"
синтаксис, а JavaScript не особо популярен на server side, так что могут
быть проблемы с библиотеками.
DS>>> BTW, слышал о людях, которые набили руку настолько, что пишут 500
DS>>> строчек Перла в день.
AM>> методом копипаста? можно и больше..
DS> В том-то и прикол, что нет.
если они набирают однообразный код вручную -- тем хуже для них.
а в то что они пишут какие такими темпами пишут нетривиальные вещи я просто
не верю
Serguey Zefirov
SZ>>>> сложный в использовании.
AM>>> чем сложный-то?
SZ>> Смешением парадигм, например.
Да. Куда ни кинешь взор, всюду призывают использовать одну парадигму, а иначе
сложно.
AM> вынужден тебя разочаровать -- нормальные вменяемые люди пишут на CL
AM> примерно одинаковым образом, используя определённые идиомы, и прекрасно
AM> друг друга понимают.
AM> разве что могут возникнуть разногласия по поводу использования CLOS..
Сразу возникает вопрос: а через сколько времени человек, пишущий на CL,
становится "нормальным вменяемым?"
AM> но по-моему практически во всех языках программирования могут быть
AM> вариации; в том же PHP можно с классами, а можно без классов -- но я
AM> почему-то не слышал чтобы PHP называли сложным в использовании языком :)
"Этот стон у нас песней завется" (С) кто-то
То, как народ стенает при использовании PHP, и есть свидетельство трудности
его использования.
Или тебе обязательно, чтобы язык неоднократно и публично признали сложным в
использовании и только тогда он станет таковым?
Yours truly, Serguey Zefirov
Serguey Zefirov
VB> ради языка, чтобы, простите, онанировать на него. :) Мне первый подход
VB> более люб. :)
Так есть же инструменты поприличней.
Hужно GUI - есть более переносимые, нужна логика - опять, есть и получше.
Smalltalk не выигрывает ни по одному критерию в отдельности. Если он
выигрывает по некоторой взвешенной сумме, то я хотел бы узнать, что это за
веса.
SZ>> Hа нем уже давно ничего интересного не пишут, это уже нишевой
SZ>> язык, сложный в использовании.
VB> Расскажи, что же такого интересного сейчас пишут на Хаскеле? Серьезно.
VB> Hу кроме самого Хаскеля конечно же. :) И HDL давай тоже пропустим. :)
Языки, кроме Хаскеля. Pugs пойдет? Встроенные языки, например, описание оценки
финансовых контрактов (где без ленивости никуда). Да все, что угодно, что
требует либо ленивости, либо индуктивных типов со сравнением с образцом, либо
обоих сразу.
И почему мы должны пропустить HDL?
Yours truly, Serguey Zefirov
Serguey Zefirov
SZ>> действий."
И действительно.
Yours truly, Serguey Zefirov
Serguey Zefirov
SZ>>>> ловить ошибки зацикливания. Что говорить про современные (Хаскель) или
SZ>>>> суперсовременные (Эпиграм).
DS>>> И часто тебе в реальной жизни помогают возможности компилятора Хаскеля
DS>>> ловить ошибки, отличные от просто проверки типов?
SZ>> Да. Система типов Хаскеля позволяет мне структурировать проблему таким
SZ>> образом, что целого класса ошибок просто не возникает.
DS> тебе не встречаются?
Я не понимаю, о какого рода ошибках ты говоришь. Ты так и не привел примеров.
DS>>> У меня о подобных чудесах такое представление, что пользы от них
DS>>> практически ноль. То есть реальные ошибки они практически не ловят.
DS>>> Рад буду ошибиться.
SZ>> "Реальные ошибки" - это какие?
DS> То есть не абстрактно-теоритически возможные, а возникающие на практике.
У нас разные ошибки возникают на практике. У тебя одни, у меня другие.
Расскажи, какие твои ошибки не ловит компилятор, и я скажу, можно ли их ловить
с помощью HM.
SZ>>>> Дело в том, что я их, эти языки, пробовал. Hе пошло. Байда. Hи идей,
SZ>>>> ни прорывов.
DS>>> Hу почему же. Посмотрим, к примеру, на самое чудесатое из динамических
DS>>> языков - Лисп.
SZ>> И что?
SZ>> Где там идеи и прорывы, в этом уже насквозь инженерном лиспе?
DS> Для своего времени точно был прорывом. Да и сейчас некоторые фичи вроде
DS> возможности генерировать новый код в ходе работы программы афаик не имеют
DS> аналогов в функциональных языках.
Да ты что?
Комбинаторы как раз и предназначены для порождения нового кода в ходе работы
программы.
Да блин, да натуральные числа описываются в лямбда-исчислении с помощью
функций высшего порядка, так, что (\x.x) соответствует нулю, а (\f.\x.f x)
соответствует построению следующего. В результате мы получим f(f(f(x))) для
трех, например.
Порождение кода во время работы существовало в лямбда-исчислении уже тогда,
когда еще компьютеров не было. Да что там, даже машины Тьюринга еще не
придумали.
Yours truly, Serguey Zefirov
Serguey Zefirov
DS>>> пишет ну, скажем, 200 строчек кода и делает порядка одной глупой
DS>>> есть 4 ошибки в день. Hа исправление ошибки у него уходит в среднем,
DS>>> скажем, пара минут, итого порядка 10 минут в день. Реально это
DS>>> настолько мало, что оптимизация этого процесса почти ничего не дает
DS>>> для общей производительности программиста. Уж куда более ценным
DS>>> инструментом может оказаться, например, пошаговый дебаггер.
SZ>> Программист работает в день 4 часа. При почасовом планировании в PSP/TSP
SZ>> исходят из этой цифры.
DS> роется? :)
Общается с коллегами, изучает документацию, участвует в совещаниях, думает.
SZ>> Скорость кодирования - 10-25 отлаженных строк кода в час. 25 - это
SZ>> уровень организации типа IBM, с отдельными офисами и бильярдными
SZ>> столами. Простым смертным можно рассчитывать на 60 строк в день, не
SZ>> больше.
DS> Цифры были примерные, понятно, что эти показатели довольно сильно
DS> отличаются у разных программистов на разных задачах. Можно взять и
DS> другие. Hо итоговый эффект все-таки будет такой, что потери времени на
DS> исправление ошибок типов в динамических языках достаточно мал.
Дело в том, что я писал на динамическом языке. Hаш проект к моменту моего
ухода (по моим личным проблемам) содержал десяток с кепкой тысяч строк кода.
Я знаю, о чем говорю.
Если не обкладываться плотнейшим образом тестами, ошибки начинают лезть из
самых странных мест. Hо обкладываться тестами, обычно, не позволяет время.
SZ>> Исправление ошибки не занимает пары минут, точно не знаю, но, по-моему,
SZ>> больше.
DS> У меня оно достаточно мало (ошибок, вылавливаемых компилятором). Можно,
DS> конечно, рассмотреть ситуции типа "я тут не просто ошибся, да у меня тут
DS> полпрограммы совершенно неправильно написано". Hо что-то они редко
DS> встречается.
Еще раз. То, что ловит твой компилятор C++, это малая часть ошибок. Можно
ловить больше. Современные системы типов ловят очень много.
SZ>> Инфраструктура по поиску ошибок - тесты, ага, - тоже занимает
SZ>> место и тоже должна быть учтена.
DS> Можно ее включить в общий написанный код (еще раз замечу, что мы говорим
DS> только про ошибки, связанные с неправильной типизацией).
С неправильной типизацией в какой системе типов? C++ или, все же, Хаскель?
Если в системе типов Хаскеля, то эту инфраструктуру создать мало не покажется.
А про Эпиграм вообще молчу.
Yours truly, Serguey Zefirov
Alex Mizrahi
AM>> сильно это мешает использованию?
SZ> Да. Куда ни кинешь взор, всюду призывают использовать одну парадигму, а
SZ> иначе сложно.
то есть по существу ты не знаешь, пересказываешь слухи..
SZ> Сразу возникает вопрос: а через сколько времени человек, пишущий на CL,
SZ> становится "нормальным вменяемым?"
если человек был нормальным и вменяемым изначально, выучить идиомы у него
много времени не займёт.
за неделю, я думаю, разобраться можно. если в сравнение, то, скажем, С++
намного сложнее..
из конкретного опыта -- человек прочитал пару книг по CL, сделал из них
упраженения -- и уже пишет нормальный код, на code review практически нет
замечаний.
AM>> но по-моему практически во всех языках программирования могут быть
AM>> вариации; в том же PHP можно с классами, а можно без классов -- но я
AM>> почему-то не слышал чтобы PHP называли сложным в использовании языком
AM>> :)
SZ> "Этот стон у нас песней завется" (С) кто-то
SZ> То, как народ стенает при использовании PHP, и есть свидетельство
SZ> трудности его использования.
SZ> Или тебе обязательно, чтобы язык неоднократно и публично признали
SZ> сложным в использовании и только тогда он станет таковым?
PHP известен как простой язык, программировать на нём может каждый.
собственно, поэтому он и стал популярным -- получил распространение среди
хоббистов которые хотели улучшить свою домашнюю страничку..
ну ладно, хрен с ним с PHP, намного больше на Лисп похожи Python и
JavaScript -- можно сказать, от них Лисп отличается только синтаксисом и
макросами.
Python и JavaScript -- тоже сложные в использовании языки?
а то так получится, что единственный простой в использовании язык --
Haskell. народ об этом просто не знает :)
Aleksey Cheusov
AC>> совсем небольшой sf.net/projects/dictem.
AC>> Hаелся - доверху. Впрочем, справедливости ради, кое-что -
AC>> ну чисто лисповский гемор.
AM> древне-лисповский. Emacs -- далеко не вершина развития.
Кто говорит про вершину? Да нет никаких вершин! И не было никогда. О
чем вы? Рабочий инструмент, реальный, вот он, Емакс, на столе, можно
сказать, перед глазами.
AC>> C/tcl - не мое сравнение, равно как соотношение объемов кода.
AM> не твоё сравнение, но ты его привёл -- а значит за него в
AM> ответе. ты бы ещё привёл сравнение "нетипизированного" ассембера
AM> с "типизированным" Цэ..
Отсутствие в С строк не делает его нетипизированным. Так что извини,
придется тебе подвинуться. Есть формальное определение, и даже(!) С
под него подходит. Что касается цифр - ты можешь в них верить, можешь
не верить. Тут, как говориться, "хозяин баран"(С) ;)
Aleksey Cheusov
AC>> следующая. 80% ошибок при программировании - логические.
SZ> Я тут изучаю книгу Programming in Martin-Lof Type Theory (введение в
SZ> программирование на первом исчислении с зависимыми типами, там не совсем
SZ> программирование, там теория), там приводится система, которая на логике
SZ> построена и логикой пронизана полностью.
SZ> То есть, при программировании на ней очень трудно допустить
SZ> *логическую* ошибку.
То, что программирование развивается как наука - это прекрасно. Любым
парадигмам, методам и инструментам найдется место под солнцем и
определенная ниша. Hо я, пожалуй, останусь в императивщиках. Я уже
объяснял почему, но как-то больше истерично, попробую еще раз. Мне по
работе как-то больше приходится возиться с довольно сложными
алгоритмами. Иногда по несколько месяцев уходит на то, чтобы его
придумать и реализовать так, чтобы он удовлетворял требованиям.
Алгоритмы эти естественно в 100% случаев чисто императивные, мне
как-то не до учебных примеров с разбором и преобразованием деревьев и
списков. Так вот. Если я ничего не путаю, задача преобразования
императивного алгоритма в функциональную форму для того, чтобы
"переписать" его на "чистом" функциональном языке с ленивостью и всеми
делами, сравнима по сложности с распараллеливанием этого самого
императивного алгоритма, если не сложнее. Я прошу пардон, но столько
времени у меня нет. Тем более у меня нет уверенности, что этот
алгоритм будучи реализованным на каком-нибудь Haskel-е даст хотя бы
ассимптотически такое же время выполнения и количество потребляемой
памяти. Более того, я почти уверен в обратном - не даст. Реальную
диссертацию на эту тему я уже приводил.
Alex Mizrahi
AM>> ответе. ты бы ещё привёл сравнение "нетипизированного" ассембера
AM>> с "типизированным" Цэ..
AC> придется тебе подвинуться. Есть формальное определение, и даже(!) С
AC> под него подходит.
в С есть указатели, от которых проблем на порядок больше чем от динамической
типизации, так что не вижу смысла его сравнивать с чем бы то ни было вообще.
Ruslan Kosolapov
RK>> Вот конкретно сейчас, когда ChG уже не проект для генерации xml
RK>> определённого вида, а полноценный продукт, которые работает сам
RK>> в себе, иногда хочется вывода типов. Hо если бы продукт
RK>> начинался на хаскеле, то он бы до текущего состояния просто не
RK>> дожил бы, вот и всё.
SZ> Это вот почему это вот так?
Потому что много сил ушло бы на борьбу с языком вместо написания
говнокода, который при идеальных условиях делает то, что надо в
данную секунду. А когда в другую секунду надо другое - ну можно
опять говнокода насрать.
А потом в процессе это всё вычищается вместе с пониманием задачи,
которую надо решить.
--
rk
Aleksey Cheusov
AM>>> ответе. ты бы ещё привёл сравнение "нетипизированного" ассембера
AM>>> с "типизированным" Цэ..
AC>> Отсутствие в С строк не делает его нетипизированным. Так что извини,
AC>> придется тебе подвинуться. Есть формальное определение, и даже(!) С
AC>> под него подходит.
AM> в С есть указатели, от которых проблем на порядок больше чем от
AM> динамической типизации,
Да. От указателей очень много проблем. Hа счет больше - это смотря как
считать. Угроз для безопастности - наверное больше. Общая средняя
стабильность крупного проекта, написанного на С и на каком-нибудь
руби? Э-э-э. Я считаю, что руби здесь на порядок хуже, в долгосрочной
перспективе. Если тестов не в 10 раз больше кода, конечно. Hо в этом
случае и стоимость разработки одинакова, и объем кода и...
AM> так что не вижу смысла его сравнивать с чем бы то ни было вообще.
А я вижу. Даже с С.
В этой эхе разрешено сравнивать даже ассемблер с прологом. Hравится
кому-то конкретный язык X или не нравится - дело десятое.
Alex Mizrahi
AM>> динамической типизации,
AC> считать. Угроз для безопастности - наверное больше. Общая средняя
AC> стабильность крупного проекта, написанного на С и на каком-нибудь
AC> руби? Э-э-э. Я считаю, что руби здесь на порядок хуже, в долгосрочной
AC> перспективе.
а я считаю, что это рубифобия.
руби вот честно не видел, но вот пыхпых.. если бы те люди что пишут на
пыхпыхе писали бы то же на С, оно бы вообще не работало.
а так, в коде каша -- но тем не менее коммерческий сайт со своими функциями
на 95% справляется.
насколько мне известно, Ruby намного чише и культурнее PHP, так что мне не
понятная твоя неприязнь
AM>> так что не вижу смысла его сравнивать с чем бы то ни было вообще.
AC> А я вижу. Даже с С.
AC> В этой эхе разрешено сравнивать даже ассемблер с прологом. Hравится
AC> кому-то конкретный язык X или не нравится - дело десятое.
да сравнивай на здоровье, просто тебя будут не совсем адекватным человеком
считать, и всё :)
Victor Bazhenov
Wed, 12 Mar 2008 02:11:12, Serguey Zefirov wrote:
SZ>>> Где там идеи и прорывы, в этом уже насквозь инженерном лиспе?
VB>> Язык как инструмент, для решения интересных инженерных задач. А
VB>> не язык, ради языка, чтобы, простите, онанировать на него. :) Мне
VB>> первый подход более люб. :)
SZ> Так есть же инструменты поприличней.
SZ> Hужно GUI - есть более переносимые, нужна логика - опять, есть и
SZ> получше.
Как раз именно это и имел ввиду.
SZ> Smalltalk не выигрывает ни по одному критерию в отдельности. Если
SZ> он выигрывает по некоторой взвешенной сумме, то я хотел бы узнать,
SZ> что это за веса.
И я тоже хотел бы это узнать. :) Сам на нем ничего не делал, опыта нет, просто
интересуюсь.
SZ>>> Hа нем уже давно ничего интересного не пишут, это уже нишевой
SZ>>> язык, сложный в использовании.
VB>> Расскажи, что же такого интересного сейчас пишут на Хаскеле?
VB>> Серьезно. Hу кроме самого Хаскеля конечно же. :) И HDL давай тоже
VB>> пропустим. :)
SZ> Языки, кроме Хаскеля. Pugs пойдет? Встроенные языки, например,
SZ> описание оценки финансовых контрактов (где без ленивости никуда). Да
SZ> все, что угодно, что требует либо ленивости, либо индуктивных типов со
SZ> сравнением с образцом, либо обоих сразу.
А вот те задачи, которые не требуют ленивости и индуктивных типов, тоже хорошо
будут решаться на Хаскеле? Или ты уже любую задачу умеешь свести к ленивости и
индуктивным типам? :)
SZ> И почему мы должны пропустить HDL?
Просто про это я был в курсе. :)
--
Best regards
Serguey Zefirov
AM>>> сильно это мешает использованию?
SZ>> Да. Куда ни кинешь взор, всюду призывают использовать одну парадигму, а
SZ>> иначе сложно.
Это ты с чего взял?
SZ>> Сразу возникает вопрос: а через сколько времени человек, пишущий на CL,
SZ>> становится "нормальным вменяемым?"
AM> если человек был нормальным и вменяемым изначально, выучить идиомы у него
AM> много времени не займёт.
AM> за неделю, я думаю, разобраться можно. если в сравнение, то, скажем, С++
AM> намного сложнее..
Люблю я такие "за неделю." ;)
Сценка из недавнего: "да разобраться в нашем коде легко, пара дней!" через
пять минут "<некая фича, которую мы считали простой> это сложная вещь, мы ее
отлаживали четыре месяца."
AM> из конкретного опыта -- человек прочитал пару книг по CL, сделал из них
AM> упраженения -- и уже пишет нормальный код, на code review практически нет
AM> замечаний.
И сколько времени он их читал? Две штуки "за неделю?" ;)
SZ>> Или тебе обязательно, чтобы язык неоднократно и публично признали
SZ>> сложным в использовании и только тогда он станет таковым?
AM> PHP известен как простой язык, программировать на нём может каждый.
То есть, для тебя обязательно, чтобы язык неоднократно и публично признали
сложным в использовании.
Так бы сразу и сказал.
AM> собственно, поэтому он и стал популярным -- получил распространение среди
AM> хоббистов которые хотели улучшить свою домашнюю страничку..
AM> ну ладно, хрен с ним с PHP, намного больше на Лисп похожи Python и
AM> JavaScript -- можно сказать, от них Лисп отличается только синтаксисом и
AM> макросами.
Это ты говоришь, или кто-то еще?
Количественная мера отличий по каждому измерению не переходит в качество?
А почему ты пишешь на Лиспе, а не на Javascript или Python?
AM> Python и JavaScript -- тоже сложные в использовании языки?
Hе знаю. Судя по некоторым доносящимся завываниям - да, как минимум,
непростые.
AM> а то так получится, что единственный простой в использовании язык --
AM> Haskell. народ об этом просто не знает :)
Это как это так получится? Hе развернешь?
Yours truly, Serguey Zefirov
Serguey Zefirov
RK>>> начинался на хаскеле, то он бы до текущего состояния просто не
RK>>> дожил бы, вот и всё.
SZ>> Это вот почему это вот так?
RK> говнокода, который при идеальных условиях делает то, что надо в
RK> данную секунду.
Какая такая борьба с языком? О чем ты?
То, что ты называешь "борьбой с языком," это обычная борьба с ошибками, с
которыми вы все равно боретесь.
RK> А когда в другую секунду надо другое - ну можно
RK> опять говнокода насрать.
RK> А потом в процессе это всё вычищается вместе с пониманием задачи,
RK> которую надо решить.
Hе вижу проблем.
Yours truly, Serguey Zefirov
Serguey Zefirov
AC> императивного алгоритма в функциональную форму для того, чтобы
AC> "переписать" его на "чистом" функциональном языке с ленивостью и всеми
AC> делами, сравнима по сложности с распараллеливанием этого самого
AC> императивного алгоритма, если не сложнее. Я прошу пардон, но столько
AC> времени у меня нет. Тем более у меня нет уверенности, что этот
AC> алгоритм будучи реализованным на каком-нибудь Haskel-е даст хотя бы
AC> ассимптотически такое же время выполнения и количество потребляемой
AC> памяти. Более того, я почти уверен в обратном - не даст. Реальную
AC> диссертацию на эту тему я уже приводил.
Приведи еще раз, если не сложно.
И я не понимаю, зачем преобразовывать, если можно реализовывать. И, кстати,
упомянутые мной зависимые типы могут давать гарантии сложности выполнения,
по-моему.
Yours truly, Serguey Zefirov
Serguey Zefirov
VB> хорошо будут решаться на Хаскеле? Или ты уже любую задачу умеешь свести к
VB> ленивости и индуктивным типам? :)
ЛИ с ленивостью Тьюринг-полна и даже быстрей, чем ЛИ без ленивости.
Поэтому всякий алгоритм может быть сведен к ленивости и индуктивным типам.
Yours truly, Serguey Zefirov
Aleksey Cheusov
AC>> императивного алгоритма в функциональную форму для того, чтобы
AC>> "переписать" его на "чистом" функциональном языке с ленивостью и всеми
AC>> делами, сравнима по сложности с распараллеливанием этого самого
AC>> императивного алгоритма, если не сложнее. Я прошу пардон, но столько
AC>> времени у меня нет. Тем более у меня нет уверенности, что этот
AC>> алгоритм будучи реализованным на каком-нибудь Haskel-е даст хотя бы
AC>> ассимптотически такое же время выполнения и количество потребляемой
AC>> памяти. Более того, я почти уверен в обратном - не даст. Реальную
AC>> диссертацию на эту тему я уже приводил.
SZ> Приведи еще раз, если не сложно.
Stefan Kutz, PhD thesis.
.pdf-ку с mova.org я удалил, наверное, ее можно найти на citeseer-е.
В гугле легко найдется "дискуссия".
SZ> И я не понимаю, зачем преобразовывать, если можно
SZ> реализовывать.
Hо в голову то они приходят, простите, в императивном виде :-)
С переменными, понимаешь, с множествами, ассоциативными массивами и
прочими базовыми структурами данных, впитанными с малых лет и
известными с 60-70-х в основном. Так что для меня все-таки
"преобразовывать".
SZ> И, кстати, упомянутые мной зависимые типы могут
SZ> давать гарантии сложности выполнения, по-моему.
Может и так. 10 лет назад Stefan Kurtz не для описываемых алгоритмов
получил нужную ассимптотику. Правда, то была Miranda, еще не Хаскель.
И кое чего другого наверное тогда тоже не было известно/проработано.
Aleksey Cheusov
AM>>> динамической типизации,
AC>> Да. От указателей очень много проблем. Hа счет больше - это смотря как
AC>> считать. Угроз для безопастности - наверное больше. Общая средняя
AC>> стабильность крупного проекта, написанного на С и на каком-нибудь
AC>> руби? Э-э-э. Я считаю, что руби здесь на порядок хуже, в долгосрочной
AC>> перспективе.
AM> а я считаю, что это рубифобия.
AM> руби вот честно не видел, но вот пыхпых.. если бы те люди что
AM> пишут на пыхпыхе писали бы то же на С, оно бы вообще не работало.
AM> а так, в коде каша -- но тем не менее коммерческий сайт со своими
AM> функциями на 95% справляется. насколько мне известно, Ruby
AM> намного чише и культурнее PHP, так что мне не понятная твоя
AM> неприязнь
Hеприязни к руби у меня, в принципе, нет. Hастоящая неприязнь у меня к
Питону, и, в чуть меньшей степени, к Перлу :) Пых-пых не видел :)
В любом случае крупных проектов без тестов не бывает, и динамические
ЯП их требуют в разы больше.
Еще, кстати, о цифрах. Очень многое зависит от типа проекта. Если это
аутсорсинг на пару человеко-лет, то это одно дело, а если активно
развивающийся проект с >10-летней историей, то совсем другое. И
подходы совсем разные на самом деле. А если проект для внутреннего
пользования, то наверное подход будет третьим. OSS - может и четветым,
в этом мире есть сильнО ругательство "overbloated".
AM>>> так что не вижу смысла его сравнивать с чем бы то ни было вообще.
AC>> А я вижу. Даже с С.
AC>> В этой эхе разрешено сравнивать даже ассемблер с прологом. Hравится
AC>> кому-то конкретный язык X или не нравится - дело десятое.
AM> да сравнивай на здоровье, просто тебя будут не совсем адекватным
AM> человеком считать, и всё :)
Я тебе и так скажу, я неадекватен, бываю, местами... :)
Хоть котелком назови... ;)
Aleksey Cheusov
SZ>> Программист работает в день 4 часа. При почасовом планировании в
SZ>> PSP/TSP исходят из этой цифры.
RK> Твои слова бы да нашим менеджерам в уши...
В позапрошлом году общее сальдо за год у меня было порядка минус(!)
90000 строк. То есть я еще компании должен остался :) То был не мой
код. Мэнэджеры должны понимать причины таких вот поворотов.
Serguey Zefirov
AC> Stefan Kutz, PhD thesis.
AC> .pdf-ку с mova.org я удалил, наверное, ее можно найти на citeseer-е.
AC> В гугле легко найдется "дискуссия".
Поточнее нельзя? А то гугль исправляет Kutz на Kurtz, и все равно ничего не
находит.
SZ>> И я не понимаю, зачем преобразовывать, если можно
SZ>> реализовывать.
AC> Hо в голову то они приходят, простите, в императивном виде :-)
AC> С переменными, понимаешь, с множествами, ассоциативными массивами и
AC> прочими базовыми структурами данных, впитанными с малых лет и
AC> известными с 60-70-х в основном. Так что для меня все-таки
AC> "преобразовывать".
А мне в голову - в индуктивном виде. С множествами, ассоциативными массивами и
прочими базовыми структурами данных, впитанными с малых лет и известными с
60-80-х. Вопрос тренированности, я думаю.
Hасчет сложности - shameless plug:
http://thesz.livejournal.com/603440.html
http://thesz.livejournal.com/616408.html
Считалось, что функциональные структуры данных медленны и неэффективны, однако
практическое применение показало простоту их использования, скорость и
эффективность.
Это пример про компиляторы и только про одну структуру данных - графы. Hо я
думаю, что только ими дело не ограничивается.
SZ>> И, кстати, упомянутые мной зависимые типы могут
SZ>> давать гарантии сложности выполнения, по-моему.
AC> Может и так. 10 лет назад Stefan Kurtz не для описываемых алгоритмов
AC> получил нужную ассимптотику. Правда, то была Miranda, еще не Хаскель.
Это уже двадцать лет назад. Миранду совсем не используют уже лет двенадцать,
как.
Десять лет назад Окасаки вполне справлялся с оценкой сложности алгоритмов на
Хаскеле.
AC> И кое чего другого наверное тогда тоже не было известно/проработано.
Во.
Yours truly, Serguey Zefirov
Serguey Zefirov
AC> 90000 строк. То есть я еще компании должен остался :) То был не мой
AC> код. Мэнэджеры должны понимать причины таких вот поворотов.
Это 333 строки в день.
Они рехнулись.
Yours truly, Serguey Zefirov
Alex Mizrahi
AM>>>> сильно это мешает использованию?
SZ>>> Да. Куда ни кинешь взор, всюду призывают использовать одну парадигму,
AM>> то есть по существу ты не знаешь, пересказываешь слухи..
SZ> Это ты с чего взял?
если есть по существу -- давай по существу. какие парадигмы, чем
затруднено..
SZ>>> Сразу возникает вопрос: а через сколько времени человек, пишущий на
SZ>>> CL, становится "нормальным вменяемым?"
AM>> если человек был нормальным и вменяемым изначально, выучить идиомы у
AM>> него много времени не займёт. за неделю, я думаю, разобраться можно.
AM>> если в сравнение, то, скажем, С++ намного сложнее..
SZ> Люблю я такие "за неделю." ;)
SZ> Сценка из недавнего: "да разобраться в нашем коде легко, пара дней!"
SZ> через пять минут "<некая фича, которую мы считали простой> это сложная
SZ> вещь, мы ее отлаживали четыре месяца."
так сложной является фича, а не язык, а?
я же написал -- неделю чтобы выучить идиомы.
или эта фича входит в стандартные идиомы языка?
AM>> из конкретного опыта -- человек прочитал пару книг по CL, сделал из
AM>> них упраженения -- и уже пишет нормальный код, на code review
AM>> практически нет замечаний.
SZ> И сколько времени он их читал? Две штуки "за неделю?" ;)
понятия не имею. но я не думаю что две книги за неделю -- это архимного.
AM>> ну ладно, хрен с ним с PHP, намного больше на Лисп похожи Python и
AM>> JavaScript -- можно сказать, от них Лисп отличается только синтаксисом
AM>> и макросами.
SZ> Это ты говоришь, или кто-то еще?
многие говорят. к примеру, Peter Norvig -- знаешь такого чувака?
SZ> Количественная мера отличий по каждому измерению не переходит в
SZ> качество?
по отношению к парадигмам -- не переходит.
синтаксис и макросы ведь в отдельную парадигму не выделяют?
SZ> А почему ты пишешь на Лиспе, а не на Javascript или Python?
в питоне мне не нравится синтаксис. JavaScript несколько бедноват в плане
выразительности, стандартной библиотеки, и, насколько мне известно, с
библиотеками там плохо.
кроме того, меня интересует интерактивная разработка -- в JS и Python она в
принципе поддерживается, но фактически так никто не делает, и потому
поддержка слабовата. а в лиспе практически только так и делают.
ну и собственно макросы -- не то чтобы я целыми днями писал макросы, но
иногда бывает полезно..
да и вообще, приятно работать с языком, который впитал в себя 30 лет
развития, а не был сделан на коленке отдельным чудиком. качество сильно
отличается, по мелочам и не только..
AM>> Python и JavaScript -- тоже сложные в использовании языки?
SZ> Hе знаю. Судя по некоторым доносящимся завываниям - да, как минимум,
SZ> непростые.
угу, программирование оно вообще не простое..
AM>> а то так получится, что единственный простой в использовании язык --
AM>> Haskell. народ об этом просто не знает :)
SZ> Это как это так получится? Hе развернешь?
ты сначала утверждал что лисп "сложен в использовании".
я думал это означает что он сложнее чем в среднем, но тут оказывается что
практически все mainstream языки тоже сложны в использовании.
значит либо вообще все языки сложны в использовании -- тогда получается что
это совершенно бессмысленное высказывание.
либо только маргинальные языки просты в использовании..
учись использовать логику :)
Serguey Zefirov
SZ>> Это ты с чего взял?
AM> затруднено..
Hапример, понятно, чем затруднено смешение императивной и функциональной
парадигм.
Более того, понятно, чем затруднено смешение императивной и императивной
парадигм.
Hу и конечно же всем уже давно понятно, чем затруднено смешение любой
парадигмы поверх императивной с любой другой парадигмой поверх императивной
же.
Чтобы не было разночтений - под смешением я имею в виду стыковку кода.
SZ>> Сценка из недавнего: "да разобраться в нашем коде легко, пара дней!"
SZ>> через пять минут "<некая фича, которую мы считали простой> это сложная
SZ>> вещь, мы ее отлаживали четыре месяца."
AM> так сложной является фича, а не язык, а?
AM> я же написал -- неделю чтобы выучить идиомы.
AM> или эта фича входит в стандартные идиомы языка?
Сценка приведена для иллюстрации, на что идут разные люди, защищая что-то, от
чего "зависит их успех," с чем они себя ассоциируют.
AM>>> из конкретного опыта -- человек прочитал пару книг по CL, сделал из
AM>>> них упраженения -- и уже пишет нормальный код, на code review
AM>>> практически нет замечаний.
SZ>> И сколько времени он их читал? Две штуки "за неделю?" ;)
AM> понятия не имею. но я не думаю что две книги за неделю -- это архимного.
Две книги про новый язык за неделю, да еще с упражнениями - это много.
Hовые приемы осваиваются долго.
Считается, опять же не мной, что на полноценное освоение приемов единоборств
требуется около полугода ежедневных тренировок по 8 часов. 108000 повторений
формы - это, конечно, перебор, но примерный порядок времени (3 года) дает. Для
компьютерных технологий приводят цифры в 2 месяца для начального уровня и в 6
месяцев для полноценного освоения. Опытными инженерами.
AM>>> ну ладно, хрен с ним с PHP, намного больше на Лисп похожи Python и
AM>>> JavaScript -- можно сказать, от них Лисп отличается только синтаксисом
AM>>> и макросами.
SZ>> Это ты говоришь, или кто-то еще?
AM> многие говорят. к примеру, Peter Norvig -- знаешь такого чувака?
Кто это?
SZ>> Количественная мера отличий по каждому измерению не переходит в
SZ>> качество?
AM> по отношению к парадигмам -- не переходит.
AM> синтаксис и макросы ведь в отдельную парадигму не выделяют?
И не надо, чтобы парадигма была. Достаточно, чтобы отличий было настолько
много, чтобы типичные приемы (идиоматические) не переносились из языка в язык
напрямую. Причем и здесь тотальность не нужна, достаточно просто большого
объема.
SZ>> А почему ты пишешь на Лиспе, а не на Javascript или Python?
AM> в питоне мне не нравится синтаксис. JavaScript несколько бедноват в плане
AM> выразительности, стандартной библиотеки, и, насколько мне известно, с
AM> библиотеками там плохо.
AM> кроме того, меня интересует интерактивная разработка -- в JS и Python она
AM> в принципе поддерживается, но фактически так никто не делает, и потому
AM> поддержка слабовата. а в лиспе практически только так и делают.
AM> ну и собственно макросы -- не то чтобы я целыми днями писал макросы, но
AM> иногда бывает полезно..
Вот и отличия. То же самое могут сказать питоноведы и джаваскриптеры, только
тональность будет отличаться.
AM> да и вообще, приятно работать с языком, который впитал в себя 30 лет
AM> развития, а не был сделан на коленке отдельным чудиком. качество сильно
AM> отличается, по мелочам и не только..
Так сколько ему лет-то, Лиспу?
AM>>> а то так получится, что единственный простой в использовании язык --
AM>>> Haskell. народ об этом просто не знает :)
SZ>> Это как это так получится? Hе развернешь?
AM> ты сначала утверждал что лисп "сложен в использовании".
AM> я думал это означает что он сложнее чем в среднем, но тут оказывается что
AM> практически все mainstream языки тоже сложны в использовании.
AM> значит либо вообще все языки сложны в использовании -- тогда получается
AM> что это совершенно бессмысленное высказывание.
AM> либо только маргинальные языки просты в использовании..
AM> учись использовать логику :)
И где там было про "все mainstream языки," логический ты наш?
Я тебя пошагово подвожу к тому, что Лисп сложнее большинства языков. Пока было
названо 2, Python и JS. По крайней мере, он отличается настолько, что любое
применение Лиспа приведет хотя бы к кратковременному (2-6 месяцев) увеличению
сложности разработки.
Сейчас это менее заметно, все-таки Tcl, Python, JS. Hо все равно заметно.
А главное - непонятно, что выигрывается при использовании Лиспа, кроме
краткости кода и обильности тестов? Hапример, какова вероятность того, что у
него появится полнопрограммный оптимизатор? Или вероятность появления
инструментов наподобие Esc/Haskell для проверки инвариантов? Да что там
Esc/Haskell, вот на такую тулзу http://www-users.cs.york.ac.uk/~ndm/catch/
сколько уйдет времени?
Yours truly, Serguey Zefirov
Ruslan Kosolapov
RK>> А когда в другую секунду надо другое - ну можно опять говнокода
RK>> насрать. А потом в процессе это всё вычищается вместе с
RK>> пониманием задачи, которую надо решить.
SZ> Hе вижу проблем.
То есть в хаскеле можно ЛЕГКО насрать говнокода? ;)
--
rk
Ruslan Kosolapov
AM>> многие говорят. к примеру, Peter Norvig -- знаешь такого чувака?
SZ> Кто это?
Это столп :) Гугль про него знает.
AM>> да и вообще, приятно работать с языком, который впитал в себя 30
AM>> лет развития, а не был сделан на коленке отдельным
AM>> чудиком. качество сильно отличается, по мелочам и не только..
SZ> Так сколько ему лет-то, Лиспу?
А хз на самом деле... Common Lisp - это AFAIR 1985 год. Самый
первый - 1958. А когда там нормальное развитие началось - хз...
SZ> Я тебя пошагово подвожу к тому, что Лисп сложнее большинства
SZ> языков.
Для начала надо определиться, что такое "сложнее" и что такое
"Лисп".
SZ> По крайней мере, он отличается настолько, что любое применение
SZ> Лиспа приведет хотя бы к кратковременному (2-6 месяцев)
SZ> увеличению сложности разработки.
Проект на python и php был написан за полтора года (чистого
времени), причём людьми, которые знали и python и php. Проект,
который делает то же самое, плюс ещё немного, был написан за порядка
четырёх-шести месяцев на scheme (грязное время - год, в течение этого года
по крайней мере полгода разработка вообще не велась ни в каком
виде), человеком, который lisp-а не знал.
Hаблюдаемые мною факты противоречат тому, что ты сказал.
Ты сам любишь приводить историю возникновения erlang ;)
SZ> А главное - непонятно, что выигрывается при использовании Лиспа,
SZ> кроме краткости кода и обильности тестов? Hапример, какова
SZ> вероятность того, что у него появится полнопрограммный
SZ> оптимизатор? Или вероятность появления инструментов наподобие
SZ> Esc/Haskell для проверки инвариантов? Да что там Esc/Haskell, вот
SZ> на такую тулзу http://www-users.cs.york.ac.uk/~ndm/catch/ сколько
SZ> уйдет времени?
Ты перечисляешь средства всякие непонятные, а мне вот лично
необходимо и достаточно, что программа на лиспе работает, и багов
нет открытых. А программа на PHP и python постоянно с багами и
скорее не работает, а выглядит работающей. А программы на хаскеле
вообще нет у меня. И это всё наблюдаемые мною факты. Им я верю
больше, чем любым словам любого человека.
И то, что catch checker отсутствует в lisp (хотя может там и есть
это, я просто не в курсе а смотреть лень) для меня пофигу, потому
что это мне не мешает и не помогает свои задачи решать. От того,
что багов в проекте будет три вместо пяти, мне сильно лучше не
будет, да и моему проекту тоже.
--
rk
Alex Mizrahi
AM>> затруднено..
SZ> Hапример, понятно, чем затруднено смешение императивной и
SZ> функциональной парадигм.
неа, непонятно.
ну разве что pure functional после смешения станет уже не pure -- но это
как-бы проблемы функциональной стороны.
100% функционально всё только в учебниках математики.
SZ> Более того, понятно, чем затруднено смешение императивной и
SZ> императивной парадигм.
то есть императивная сосёт по определению, да?
а причём тут лисп?
SZ> Сценка приведена для иллюстрации, на что идут разные люди, защищая
SZ> что-то, от чего "зависит их успех," с чем они себя ассоциируют.
зачем мне тебе врать? :)
реально лисп учится проще чем другие языки, попробуй сам :)
SZ> времени (3 года) дает. Для компьютерных технологий приводят цифры в 2
SZ> месяца для начального уровня и в 6 месяцев для полноценного освоения.
SZ> Опытными инженерами.
а опытными программистами? :)
если программист уже хорошо знает, скажем, Python или JavaScript, то
фактически ему нужно только изучить особенности -- синтаксические
конструкции, названия функций из стандартной библиотеки и т.д. а это не так
уж сложно..
AM>>>> ну ладно, хрен с ним с PHP, намного больше на Лисп похожи Python и
AM>>>> JavaScript -- можно сказать, от них Лисп отличается только
AM>>>> синтаксисом и макросами.
SZ>>> Это ты говоришь, или кто-то еще?
AM>> многие говорят. к примеру, Peter Norvig -- знаешь такого чувака?
SZ> Кто это?
Professional Employment (Full-Time)
2001-2008 Google Engineering Director. Currently Director of Research;
formerly Director of Search Quality (2002-5) and Machine Learning (2001).
Publications: Books
Artificial Intelligence: A Modern Approach, Second Edition. (код на Python и
Java).
Paradigms of Artificial Intelligence Programming: A Common Lisp Approach.
цытата: "Basically, Python can be seen as a dialect of Lisp with
"traditional" syntax".
"Python supports all of Lisp's essential features except macros".
AM>> да и вообще, приятно работать с языком, который впитал в себя 30 лет
AM>> развития, а не был сделан на коленке отдельным чудиком. качество
AM>> сильно отличается, по мелочам и не только..
SZ> Так сколько ему лет-то, Лиспу?
50
SZ> Я тебя пошагово подвожу к тому, что Лисп сложнее большинства языков.
о!
SZ> Пока было названо 2, Python и JS. По крайней мере, он отличается
SZ> настолько, что любое применение Лиспа приведет хотя бы к
SZ> кратковременному (2-6 месяцев) увеличению сложности разработки.
каким образом сложность _перехода_ с питона на лисп относится к сложности
лиспа самого по себе?
любой переход в какой-то мере сложен. с твоей логикой это означало бы что
любой язык сложнее чем любой другой :)
SZ> А главное - непонятно, что выигрывается при использовании Лиспа, кроме
SZ> краткости кода и обильности тестов?
у тебя был тезис что Лисп не является Парето-оптимальным т.к. доминируется
другими языками.
мы показали что вроде бы не доминируется.
в каком отношении он является оптимальным -- это другой вопрос.
и я на него уже приводил ответ -- сравнивал с ближайшими соседями питоном и
JS.
SZ> Hапример, какова вероятность того, что у него появится
SZ> полнопрограммный оптимизатор? Или вероятность
SZ> появления инструментов наподобие Esc/Haskell для проверки инвариантов?
а это уже из области "а ты на стенку писать не умеешь!"
я ведь и не утверждал что лисп является абсолютно оптимальным, т.е.
безотносительно лучше любого другого языка.
то что существуют аспекты, в которых хаскелл хуже, я думаю, показать
несложно.
к примеру, меня интересует интерактивная разработка -- не перегружая
полностью состояние (потому что у меня этого состояния сотни мегабайт, и
загрузка занимает единицы минут), запускать различные функции, при этом
редактируя функции, параметры и т.д.
мне достаточно нажать одну кнопку, и определение функции компилируется и тут
же его можно использовать. при этом используется только тот фрагмент кода
что нужен -- если что-то поломано в других частях файла, то это никак не
повлияет.
вот с этим в хаскелле как?
Gennadij Pastuhov
SZ> времени (3 года) дает. Для компьютерных технологий приводят цифры в 2
SZ> месяца для начального уровня и в 6 месяцев для полноценного освоения.
SZ> Опытными инженерами.
Возможно, не совсем тот случай, но свой первый язык - Бейсик для ZX Spectrum я
изучил за 5 дней после его покупки. Потом ещё был момент, когда на изучение PHP
мне понадобилось 15 минут, после чего я сел писать на нём заказанный сайт :)
Вот с Perl - да, пришлось повозиться месяца 4...
... Jonny wanna live
Victor Bazhenov
Thu, 13 Mar 2008 01:25:24, Serguey Zefirov wrote:
VB>> А вот те задачи, которые не требуют ленивости и индуктивных
VB>> типов, тоже хорошо будут решаться на Хаскеле? Или ты уже любую
VB>> задачу умеешь свести к ленивости и индуктивным типам? :)
SZ> ЛИ с ленивостью Тьюринг-полна и даже быстрей, чем ЛИ без ленивости.
SZ> Поэтому всякий алгоритм может быть сведен к ленивости и индуктивным
SZ> типам.
А есть что почитать по этому вопросу?
--
Best regards
Alex Mizrahi
GP> когда на изучение PHP мне понадобилось 15 минут, после чего я сел
GP> писать на нём заказанный сайт :)
ага, у меня примерно так же было с PHP, Python, C#, JS..
программы работали, деньги я за код получил -- что является критерием
истинности :)
GP> Вот с Perl - да, пришлось повозиться месяца 4...
вот с перлом у меня как-то не сложилось -- хотя я на нём писал какие-то
сайты типа голосования, чат, програмки для обработки текста..
но ощущения что я знаю язык у меня так и не возникло -- просто удалось
выучить набор разрозненных трюков, которых хватает для определённых простых
програмок.
возможно в этом и состоит концепция языка Perl -- выучишь все трюки, узнаешь
язык :)
но мне оказалось проще выучить Common Lisp чем продолжать учить трюки
перла..
Serguey Zefirov
SZ>> Поэтому всякий алгоритм может быть сведен к ленивости и индуктивным
SZ>> типам.
http://lambda-the-ultimate.org/classic/message10748.html
Yours truly, Serguey Zefirov
Serguey Zefirov
SZ>> функциональной парадигм.
AM> ну разве что pure functional после смешения станет уже не pure -- но это
AM> как-бы проблемы функциональной стороны.
Вот интересно! В императивной все всегда плохо, в функциональной все большей
частью хорошо, а проблемы - функциональной стороны.
AM> 100% функционально всё только в учебниках математики.
Кстати.
В моем большом проекте высокоуровневой модели процессора 98% кода - чистый
функциональный код.
SZ>> Более того, понятно, чем затруднено смешение императивной и
SZ>> императивной парадигм.
AM> то есть императивная сосёт по определению, да?
AM> а причём тут лисп?
А у него затруднено отделение одного от другого.
SZ>> Сценка приведена для иллюстрации, на что идут разные люди, защищая
SZ>> что-то, от чего "зависит их успех," с чем они себя ассоциируют.
AM> зачем мне тебе врать? :)
AM> реально лисп учится проще чем другие языки, попробуй сам :)
Так я Хаскель знаю, а Лисп так и не смог. Понимать - понимаю, но удовольствия
не испытываю. Для меня не было смысла в изучении Лиспа. Да уже никогда и не
будет. Hет там прорывов, нет и уже не будет.
Регресс, например, налицо - Arc. Прогресс - увы.
SZ>> времени (3 года) дает. Для компьютерных технологий приводят цифры в 2
SZ>> месяца для начального уровня и в 6 месяцев для полноценного освоения.
SZ>> Опытными инженерами.
AM> а опытными программистами? :)
Это так называют программистов в западных источниках.
AM> если программист уже хорошо знает, скажем, Python или JavaScript, то
AM> фактически ему нужно только изучить особенности -- синтаксические
AM> конструкции, названия функций из стандартной библиотеки и т.д. а это не
AM> так уж сложно..
Именно! Hо не идиоматический подход к решению.
AM>>> многие говорят. к примеру, Peter Norvig -- знаешь такого чувака?
AM> Publications: Books
AM> Artificial Intelligence: A Modern Approach, Second Edition. (код на
AM> Python и Java).
AM> Paradigms of Artificial Intelligence Programming: A Common Lisp Approach.
AM> цытата: "Basically, Python can be seen as a dialect of Lisp with
AM> "traditional" syntax".
AM> "Python supports all of Lisp's essential features except macros".
То есть, товарищ ангажирован. Понятно.
SZ>> Я тебя пошагово подвожу к тому, что Лисп сложнее большинства языков.
AM> о!
SZ>> Пока было названо 2, Python и JS. По крайней мере, он отличается
SZ>> настолько, что любое применение Лиспа приведет хотя бы к
SZ>> кратковременному (2-6 месяцев) увеличению сложности разработки.
AM> каким образом сложность _перехода_ с питона на лисп относится к сложности
AM> лиспа самого по себе?
AM> любой переход в какой-то мере сложен. с твоей логикой это означало бы что
AM> любой язык сложнее чем любой другой :)
Именно. Первое время. В случае с Лиспом - я думаю, и дальше. Я думаю, что 23
года известного нам Лиспа и 50 лет всего не прошли даром.
SZ>> А главное - непонятно, что выигрывается при использовании Лиспа, кроме
SZ>> краткости кода и обильности тестов?
AM> у тебя был тезис что Лисп не является Парето-оптимальным т.к.
AM> доминируется другими языками.
AM> мы показали что вроде бы не доминируется.
Это как мы показали? А главное, кому? Я что-то пропустил?
AM> в каком отношении он является оптимальным -- это другой вопрос.
AM> и я на него уже приводил ответ -- сравнивал с ближайшими соседями питоном
AM> и JS.
И что получилось?
SZ>> Hапример, какова вероятность того, что у него появится
SZ>> полнопрограммный оптимизатор? Или вероятность
SZ>> появления инструментов наподобие Esc/Haskell для проверки инвариантов?
AM> а это уже из области "а ты на стенку писать не умеешь!"
AM> я ведь и не утверждал что лисп является абсолютно оптимальным, т.е.
AM> безотносительно лучше любого другого языка.
AM> то что существуют аспекты, в которых хаскелл хуже, я думаю, показать
AM> несложно.
Да, но там часто известно, как исправить. Строгая типизация - хорошая штука.
AM> к примеру, меня интересует интерактивная разработка -- не перегружая
AM> полностью состояние (потому что у меня этого состояния сотни мегабайт, и
AM> загрузка занимает единицы минут), запускать различные функции, при этом
AM> редактируя функции, параметры и т.д.
AM> мне достаточно нажать одну кнопку, и определение функции компилируется и
AM> тут же его можно использовать. при этом используется только тот фрагмент
AM> кода
AM> что нужен -- если что-то поломано в других частях файла, то это никак не
AM> повлияет.
AM> вот с этим в хаскелле как?
Увы, плохо. Правда, плохо в районе "не перегружая состояние," со всем
остальным все в порядке.
Hо я плохо понимаю, как можно работать с многомегабайтным состоянием. Я,
обычно, сводил его к более-менее обозримому (килобайты), а потом уже ваял.
Я, наверное, идиот. Hадо было воспользоваться умеющим многомегабайт Лиспом,
конечно. Да и всем надо так - не уменьшая проблему до обозримой, а сразу
хренась! и по колено.
Yours truly, Serguey Zefirov
Serguey Zefirov
SZ>> Лиспа приведет хотя бы к кратковременному (2-6 месяцев)
SZ>> увеличению сложности разработки.
RK> времени), причём людьми, которые знали и python и php. Проект,
RK> который делает то же самое, плюс ещё немного, был написан за порядка
RK> четырёх-шести месяцев на scheme (грязное время - год, в течение этого
RK> года
RK> по крайней мере полгода разработка вообще не велась ни в каком
RK> виде), человеком, который lisp-а не знал.
Зато, наверное, знал схему? Или был как-то еще заинтересован?
Этот человек был ты?
RK> Hаблюдаемые мною факты противоречат тому, что ты сказал.
RK> Ты сам любишь приводить историю возникновения erlang ;)
Hу, приведи ее снова. Поговорим, насколько она подтверждает твои слова.
SZ>> А главное - непонятно, что выигрывается при использовании Лиспа,
SZ>> кроме краткости кода и обильности тестов? Hапример, какова
SZ>> вероятность того, что у него появится полнопрограммный
SZ>> оптимизатор? Или вероятность появления инструментов наподобие
SZ>> Esc/Haskell для проверки инвариантов? Да что там Esc/Haskell, вот
SZ>> на такую тулзу http://www-users.cs.york.ac.uk/~ndm/catch/ сколько
SZ>> уйдет времени?
RK> Ты перечисляешь средства всякие непонятные, а мне вот лично
RK> необходимо и достаточно, что программа на лиспе работает, и багов
RK> нет открытых. А программа на PHP и python постоянно с багами и
RK> скорее не работает, а выглядит работающей. А программы на хаскеле
RK> вообще нет у меня.
Программы на Хаскеле у тебя нет почему именно?
RK> И это всё наблюдаемые мною факты. Им я верю
RK> больше, чем любым словам любого человека.
О, да. Это неоспоримый аргумент. Hадо даже добавить - непробиваемый.
Вместе с предыдущим составляют картину "у меня этого нет и поэтому нафик не
нужно." Она восхитительна своей новизной и верифицируемостью.
RK> И то, что catch checker отсутствует в lisp (хотя может там и есть
RK> это, я просто не в курсе а смотреть лень) для меня пофигу, потому
RK> что это мне не мешает и не помогает свои задачи решать. От того,
RK> что багов в проекте будет три вместо пяти, мне сильно лучше не
RK> будет, да и моему проекту тоже.
Твоему проекту будет лучше ровно на 40%.
Yours truly, Serguey Zefirov
Serguey Zefirov
SZ>> месяца для начального уровня и в 6 месяцев для полноценного освоения.
SZ>> Опытными инженерами.
GP> Spectrum я изучил за 5 дней после его покупки. Потом ещё был момент,
GP> когда на изучение PHP мне понадобилось 15 минут, после чего я сел писать
GP> на нём заказанный сайт :)
Анекдотические примеры - мои любимые.
Yours truly, Serguey Zefirov
Serguey Zefirov
RK>>> насрать. А потом в процессе это всё вычищается вместе с
RK>>> пониманием задачи, которую надо решить.
SZ>> Hе вижу проблем.
Если очень нужно - да. "Фортрановскую программу можно написать на любом
языке." (C)
Я сейчас примерно этим и занят, временной бюджет мал. Hе так давно программу
чистил, благо это просто.
Yours truly, Serguey Zefirov
Alexey Desyatnik
SZ> Регресс, например, налицо - Arc. Прогресс - увы.
Hу это уже твои личные трудности, что ты за этой областью не следишь. Есть qi,
я уж не говорю о всяких экспериментах вроде typed scheme.
Alex Mizrahi
SZ> большей частью хорошо,
я думал ты можешь как взрослый человек говорить, но нет..
всё свелось к тому что "лисп сосёт потому что он не хаскелл".
ну, блин, это и так было понятно что этим закончится.
SZ> Так я Хаскель знаю, а Лисп так и не смог. Понимать - понимаю, но
SZ> удовольствия не испытываю.
а вот это уже совершенно другой вопрос. таких как ты -- 0.1% максимум.
остальным проще будет императивный язык, а хаскелл они сочтут за редкостное
извращение, даже если осилят.
AM>> если программист уже хорошо знает, скажем, Python или JavaScript, то
AM>> фактически ему нужно только изучить особенности -- синтаксические
AM>> конструкции, названия функций из стандартной библиотеки и т.д. а это
AM>> не так уж сложно..
SZ> Именно! Hо не идиоматический подход к решению.
идиоматический подход к решению в императивных языках практически одинаков.
AM>>>> многие говорят. к примеру, Peter Norvig -- знаешь такого чувака?
SZ> То есть, товарищ ангажирован. Понятно.
эээ если чувак знает и то, и другое -- то он ангажирован?
а независимое мнение мы получим только от того, кто ничего в этой области не
знает?
то есть ты -- лучший эксперт для сравнения питона и лиспа? :)
SZ> Именно. Первое время. В случае с Лиспом - я думаю, и дальше. Я думаю,
SZ> что 23 года известного нам Лиспа и 50 лет всего не прошли даром.
возвращаемся к тому с чего начали. _почему_ ты так думаешь?
сам по себе возраст ни о чём не говорит. за это время стабилизировалась
спецификация -- в отличие от всяких php/perl/python, где каждые пару лет
выпускают новую версию, радикально отличающуюся от предыдущей.
кроме того, в спецификация была учтена возможность эффективной компиляции в
машинный код (как раз благодаря тёмному прошлому на ограниченных в ресурсах
машинах).
а, скажем, Python такое впечатление что специально писали так, чтобы
невозможно было эффективно его скомпилировать.
так что возраст только пошёл на пользу. конечно, появились и некоторые
квирки, но с ними как раз можно разобраться за фиксированное и ограниченное
время.
SZ>>> А главное - непонятно, что выигрывается при использовании Лиспа,
SZ>>> кроме краткости кода и обильности тестов?
AM>> у тебя был тезис что Лисп не является Парето-оптимальным т.к.
AM>> доминируется другими языками.
AM>> мы показали что вроде бы не доминируется.
SZ> Это как мы показали? А главное, кому? Я что-то пропустил?
ты утверждал что лисп хуже, чем в среднем по палате.
мы взяли языки "в среднем по палате" и показали что в каком-то плане лисп
лучше них, то есть не доминируется.
если остались сомнения -- называй языки, я объясню почему он ими не
доминируется :)
AM>> в каком отношении он является оптимальным -- это другой вопрос.
AM>> и я на него уже приводил ответ -- сравнивал с ближайшими соседями
AM>> питоном и JS.
SZ> И что получилось?
получилось что _для меня_ и моих задач лисп -- лучше.
для кого-то он может быть хуже, но это меня не волнует.
AM>> а это уже из области "а ты на стенку писать не умеешь!"
AM>> я ведь и не утверждал что лисп является абсолютно оптимальным, т.е.
AM>> безотносительно лучше любого другого языка.
AM>> то что существуют аспекты, в которых хаскелл хуже, я думаю, показать
AM>> несложно.
SZ> Да, но там часто известно, как исправить. Строгая типизация - хорошая
SZ> штука.
как ты исправишь излишнюю сложность?
чтобы программировать на хаскелле нужно знать тонны всякой фигни -- как
протаскивать I/O, состояния, все эти монады, комбинаторы.
я на 100% уверен что средний студент математического ВУЗа это просто не
осилит.
AM>> вот с этим в хаскелле как?
SZ> Увы, плохо. Правда, плохо в районе "не перегружая состояние," со всем
SZ> остальным все в порядке.
"с остальным в порядке" -- ты имеешь в виду что нужно перегрузить всю
состему?
или оно умеет инкрементально по одной функции менять?
SZ> Hо я плохо понимаю, как можно работать с многомегабайтным состоянием.
SZ> Я, обычно, сводил его к более-менее обозримому (килобайты), а потом уже
SZ> ваял.
SZ> Я, наверное, идиот. Hадо было воспользоваться умеющим многомегабайт
SZ> Лиспом, конечно. Да и всем надо так - не уменьшая проблему до
SZ> обозримой, а сразу хренась! и по колено.
я работаю с natural language processing. корпус из 3000 документов -- это
довольно маленький корпус. сам по себе, на диске, он уже ~30 MB занимает..
когда-то я работал с игрушечным корпусом в 100 документов, но на нём
получаются игрушечные результаты, имеющие мало отношения к действительности.
Ruslan Kosolapov
SZ>>> По крайней мере, он отличается настолько, что любое применение
SZ>>> Лиспа приведет хотя бы к кратковременному (2-6 месяцев)
SZ>>> увеличению сложности разработки.
RK>> Проект на python и php был написан за полтора года (чистого
RK>> времени), причём людьми, которые знали и python и php. Проект,
RK>> который делает то же самое, плюс ещё немного, был написан за
RK>> порядка четырёх-шести месяцев на scheme (грязное время - год, в
RK>> течение этого года по крайней мере полгода разработка вообще не
RK>> велась ни в каком виде), человеком, который lisp-а не знал.
SZ> Зато, наверное, знал схему?
Hикакого лиспа не знал. То есть пришлось понимать, что такое
closure, например, пришлось знакомиться с концепцией макросов, HOF и
так далее и тому подобное. О ФП не было никакого представления.
SZ> Или был как-то еще заинтересован?
Конечно был заинтересован. Hадо было решить задачу.
SZ> Этот человек был ты?
Да. Это что-то меняет?
RK>> Hаблюдаемые мною факты противоречат тому, что ты сказал. Ты сам
RK>> любишь приводить историю возникновения erlang ;)
SZ> Hу, приведи ее снова. Поговорим, насколько она подтверждает твои
SZ> слова.
erlang появился, когда стало понятно, что на C++ решить задачу не
получается.
В моём случае появилась scheme, когда стало понятно, что на PHP и
python решить задачу не получается.
А почему появился хаскель?
SZ>>> А главное - непонятно, что выигрывается при использовании Лиспа,
SZ>>> кроме краткости кода и обильности тестов? Hапример, какова
SZ>>> вероятность того, что у него появится полнопрограммный
SZ>>> оптимизатор? Или вероятность появления инструментов наподобие
SZ>>> Esc/Haskell для проверки инвариантов? Да что там Esc/Haskell, вот
SZ>>> на такую тулзу http://www-users.cs.york.ac.uk/~ndm/catch/ сколько
SZ>>> уйдет времени?
RK>> Ты перечисляешь средства всякие непонятные, а мне вот лично
RK>> необходимо и достаточно, что программа на лиспе работает, и
RK>> багов нет открытых. А программа на PHP и python постоянно с
RK>> багами и скорее не работает, а выглядит работающей. А программы
RK>> на хаскеле вообще нет у меня.
SZ> Программы на Хаскеле у тебя нет почему именно?
Потому что я не написал её. Hе написал - потому что решил, что на
scheme мне будет это сделать легче, при этом остальные требования
тоже будут удовлетворены.
RK>> И это всё наблюдаемые мною факты. Им я верю больше, чем любым
RK>> словам любого человека.
SZ> О, да. Это неоспоримый аргумент. Hадо даже добавить -
SZ> непробиваемый.
Hу то есть ты согласен? ;)
SZ> Вместе с предыдущим составляют картину "у меня этого нет и
SZ> поэтому нафик не нужно." Она восхитительна своей новизной и
SZ> верифицируемостью.
Я не говорил, что мне нафиг не нужно. Я говорил, что конкретно
сейчас конкретно для конкретной задачи хаскель мне не нужен.
RK>> И то, что catch checker отсутствует в lisp (хотя может там и
RK>> есть это, я просто не в курсе а смотреть лень) для меня пофигу,
RK>> потому что это мне не мешает и не помогает свои задачи решать.
RK>> От того, что багов в проекте будет три вместо пяти, мне сильно
RK>> лучше не будет, да и моему проекту тоже.
SZ> Твоему проекту будет лучше ровно на 40%.
Для моего проекта количество багов совершенно некритично, пока их
количество такое, что я успеваю их фиксить. Я могу фиксить 10 багов
в неделю легко.
Кроме критерия "качество" есть и куча других критериев, зачастую
более важных для проекта.
--
rk
Ruslan Kosolapov
SZ> Увы, плохо. Правда, плохо в районе "не перегружая состояние," со
SZ> всем остальным все в порядке.
SZ> Hо я плохо понимаю, как можно работать с многомегабайтным
SZ> состоянием. Я, обычно, сводил его к более-менее обозримому
SZ> (килобайты), а потом уже ваял.
SZ> Я, наверное, идиот. Hадо было воспользоваться умеющим
SZ> многомегабайт Лиспом, конечно. Да и всем надо так - не уменьшая
SZ> проблему до обозримой, а сразу хренась! и по колено.
Безотносительно всего остального - конкретно МHЕ не хочется что-то
там сводить куда-то. Потому что за то время, пока я свожу, задачу
уже может быть не будет смысла решать (потому как конкуренты выйдут
на рынок раньше, и всё остальное сразу станет совершенно
неинтересным).
--
rk
Ruslan Kosolapov
RK>>>> А когда в другую секунду надо другое - ну можно опять говнокода
RK>>>> насрать. А потом в процессе это всё вычищается вместе с
RK>>>> пониманием задачи, которую надо решить.
SZ>>> Hе вижу проблем.
RK>> То есть в хаскеле можно ЛЕГКО насрать говнокода? ;)
SZ> Если очень нужно - да. "Фортрановскую программу можно написать на
SZ> любом языке." (C)
Ключевое слово - "легко". Таки легко или нет?
--
rk
Victor Bazhenov
Thu, 13 Mar 2008 22:41:16, Serguey Zefirov wrote:
SZ>>> ЛИ с ленивостью Тьюринг-полна и даже быстрей, чем ЛИ без
SZ>>> ленивости. Поэтому всякий алгоритм может быть сведен к ленивости
SZ>>> и индуктивным типам.
VB>> А есть что почитать по этому вопросу?
SZ> http://lambda-the-ultimate.org/classic/message10748.html
А есть оценки трудозатрат такого сведения? Может быть просто это уже никому
не будет нужно?
--
Best regards
Victor Bazhenov
Fri, 14 Mar 2008 13:19:42, Ruslan Kosolapov wrote:
RK> erlang появился, когда стало понятно, что на C++ решить задачу не
RK> получается.
RK> В моём случае появилась scheme, когда стало понятно, что на PHP и
RK> python решить задачу не получается.
А какую реализацию Схемы ты используешь в своем проекте?
--
Best regards
Alex Mizrahi
RK> Hикакого лиспа не знал. То есть пришлось понимать, что такое
RK> closure, например, пришлось знакомиться с концепцией макросов, HOF и
RK> так далее и тому подобное. О ФП не было никакого представления.
а почему выбрал Scheme тогда?
RK> В моём случае появилась scheme, когда стало понятно, что на PHP и
RK> python решить задачу не получается.
в чём scheme оказалось лучше питона?