Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Такое впечатление, что по вашему и libc является компонентом. S>А как же.
Ну, если под компонентным программированием начинает пониматься использование библиотек уровня libc, то аргументы о том, что Кнут ничего не понимает в компонентах вообще идут лесом. Поскольку он начал использовать такое компонентное программирование еще до рождения участников данного спора.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну, если под компонентным программированием начинает пониматься использование библиотек уровня libc, то аргументы о том, что Кнут ничего не понимает в компонентах вообще идут лесом.
Таких аргументов в ветке не было. Были аргументы про то, что у Кнута недостаточно опыта промышленной разработки.
То есть не такой, когда один человек ваяет TeX десять лет, имея только общие представления о том, как и что должно быть, а такой разработки, где 100 человек делают TeX за 1 год, с предсказуемым результатом и обязанностью отчитываться о потраченных ресурсах и достигнутом прогрессе.
Никаких сомнений в том, что Кнут в курсе, что такое компоненты, и имеет опыт повторного использования, лично у меня нет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
E>>Ну, если под компонентным программированием начинает пониматься использование библиотек уровня libc, то аргументы о том, что Кнут ничего не понимает в компонентах вообще идут лесом. S>Таких аргументов в ветке не было. Были аргументы про то, что у Кнута недостаточно опыта промышленной разработки.
Покажи мне работы Кнута на тему "Искусство объектно ориентированого дизайна", "Искусство построения компонентов" и тд.
Где здесь упоминание промышленной разработки?
S>То есть не такой, когда один человек ваяет TeX десять лет, имея только общие представления о том, как и что должно быть, а такой разработки, где 100 человек делают TeX за 1 год, с предсказуемым результатом и обязанностью отчитываться о потраченных ресурсах и достигнутом прогрессе.
Почему-то при этом Кнут отваживается платить за найденные ошибки в своих программах, а промышленные производители ПО -- нет. Но представители той самой промышленности с иронией насмехаются над подходами к программированию у Кнута. Надо полагать, на основании того, что умело отчитываются о потраченных ресурсах и достигнутом результате.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Почему-то при этом Кнут отваживается платить за найденные ошибки в своих программах, а промышленные производители ПО -- нет.
Кому здесь непонятны причины таких различий в подходах?
E>Но представители той самой промышленности с иронией насмехаются над подходами к программированию у Кнута. E> Надо полагать, на основании того, что умело отчитываются о потраченных ресурсах и достигнутом результате.
Надо полагать, на основании того, что в их деятельности Кнутовский подход неприменим.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
E>>Почему-то при этом Кнут отваживается платить за найденные ошибки в своих программах, а промышленные производители ПО -- нет. S>Кому здесь непонятны причины таких различий в подходах?
Мне, например.
E>>Но представители той самой промышленности с иронией насмехаются над подходами к программированию у Кнута. E>> Надо полагать, на основании того, что умело отчитываются о потраченных ресурсах и достигнутом результате. S>Надо полагать, на основании того, что в их деятельности Кнутовский подход неприменим.
Хорошо, если не применим. Но есть у меня подозрение, что он даже не рассматривался. Поскольку "Кнут -- теоритик-алгоритмист из прошлого века".
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>Пожалуй, подпишусь.
T>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.
Нужно уметь распределять обязанности, некоторые вещи лучше доверить группе сторонних разработчиков, которые будут развивать свои компоненты, исправлять баги, которые будешь находить не только ты, но и другие их клиенты.
А вносить исправления в достаточно большие проекты — может быть чревато тем, что исправишь в одном месте, и возникнут проблемы в другом.
По поводу допиливания чего-то под себя: можно использовать грамотно спроектированные компоненты, которые не требуют наличия исходного кода для своей кастомизации. Бывает так, что когда люди по-умолчанию поставляют исходный код, то часто на эту тему и не заморачиваются — код же есть, допиливайте, соответственно появляются люди, которые приспосабливаются к такому подходу и не представляют других вариантов) а потом имеют головняки из-за того что вышла новая версия и теперь все надо как-то обновить
Здравствуйте, eao197, Вы писали: E>Мне, например.
Ну так задавай вопросы на интересующую тему.
E>Хорошо, если не применим. Но есть у меня подозрение, что он даже не рассматривался. Поскольку "Кнут -- теоритик-алгоритмист из прошлого века".
Просто не нужно тратить много времени на рассмотрение подхода, пригодного для человека, чей опыт построен на "проектах с нелимитированным бюджетом и без чётких требований, выполняемых коллективом из 0-1 человека".
Я вообще не понимаю, о чём весь спор. По-моему, тут какие-то религиозные моменты задеты. Потому, что если отбросить ложный пиетет перед именем, а посмотреть хотя бы 30 секунд в корень, учитывая
1. Весь (сравнительно небольшой) текст интервью, а не отдельные слова оттуда
2. Известный background Кнута
то станет понятно, что
а) Практика code rewrite, проводимая Кнутом, в промышленной разработке неприменима
б) Критика component style/code reuse, проводимая Кнутом, к промышленной разработке не относится.
Она относится к тому, как стать великим гуру софтостроения.
Цитирую уместные фразы:
Remember, though, that my opinion on economic questions is highly suspect, since I’m just an educator and scientist. I understand almost nothing about the marketplace.
Almost every biography of every person whom you would like to emulate will say that he or she did many things against the "conventional wisdom" of the day.
Но надо понять, что "крутая биография" — это не совсем то, что нужно для 99% людей. С точки зрения истории, Колумб — мегакрутой перец. С точки зрения руководства, Колумб был никудышным администратором — за что, в частности, приехал домой в кандалах. Вам хочется быть арестованным по обвинению в "неспособности навести порядок в проекте"? Велкам — эмулируйте биографию Колумба.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
E>И кто сказал, что повторное использование компонентов -- это исключительно прерогатива ООП? Модули и компоненты активно развивались еще во времена процедурного и структурного программирования (см.например Modula-2 и Ada83).
Это была недолгая эпоха Компонентного программирования. Немного после процедурного. Делфи именно оттуда свои косяки несёт.
И при чём здесь Кнут? Совпадение по времени?
VD>>Кнут конечно человек известный, но как алгоритмист, а отнюдь не как архитектор ПО.
E>Сдается мне, что TeX и METAFONT вовсе не рядовые проекты. Так что Кнут вполне себе практик, раз тот же самый TeX уже десятки лет успешно используется так, как есть.
Здравствуйте, Sinclair, Вы писали:
E>>Мне, например. S>Ну так задавай вопросы на интересующую тему.
Спасибо, но я не верю в способность участников данного спора на них ответить. Генеральная линия партии не позволит.
E>>Хорошо, если не применим. Но есть у меня подозрение, что он даже не рассматривался. Поскольку "Кнут -- теоритик-алгоритмист из прошлого века". S>Просто не нужно тратить много времени на рассмотрение подхода, пригодного для человека, чей опыт построен на "проектах с нелимитированным бюджетом и без чётких требований, выполняемых коллективом из 0-1 человека".
Вот именно об этом я и говорил. Человек умудряется писать хороший софт, а его опыт априори отбрасывается только потому, что он работал в других условиях. Специалисты, мать, мать, мать.
Паттерны проектирования были приняты на ура, с использованием опыта Александера. Хотя паттерны у него относились к строительству, а не к программированию. У тут опыт программиста(!) выбрасывается в помойку. Причем о чем он говорит? Об OpenSource!
S>а) Практика code rewrite, проводимая Кнутом, в промышленной разработке неприменима S>б) Критика component style/code reuse, проводимая Кнутом, к промышленной разработке не относится.
То, о чем сказал Кнут применительно к re-editable vs. untouchable black box, является основой OpenSource. Баги, которые находят пользователи OpenSource проектов, патчи для их исправления, патчи с доработками, форки проектов -- это все следствие того самого re-editable подхода, о котором говорит Кнут.
Востребованность и успешность OpenSource в промышленной разработке нужно доказывать?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Это по твоему мы обсуждаем "вкус яичницы". А по-моему, мы обсуждаем способы приготовления яичницы. И для этого нужно быть поваром. А когда один повар начинает использовать аргументацию вида "да он дедушка", то можно отплатить той же монетой -- "да ты сосунок". Поскольку разумного контраргумента я здесь не вижу.
Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне" :)
Здравствуйте, COFF, Вы писали:
E>>Это по твоему мы обсуждаем "вкус яичницы". А по-моему, мы обсуждаем способы приготовления яичницы. И для этого нужно быть поваром. А когда один повар начинает использовать аргументацию вида "да он дедушка", то можно отплатить той же монетой -- "да ты сосунок". Поскольку разумного контраргумента я здесь не вижу.
COF>Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне"
Типа того.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>Вот именно об этом я и говорил. Человек умудряется писать хороший софт, а его опыт априори отбрасывается только потому, что он работал в других условиях. Специалисты, мать, мать, мать.
Да, специалисты. Домашнее задание: выяснить, сколько времени потребовала разработка TeX до первого релиза. Прикинуть, есть ли шанс при жизни поучаствовать в коммерческом проекте с таким timeframe. Умножить этот шанс на полезность подхода.
E>Паттерны проектирования были приняты на ура, с использованием опыта Александера.
Кем они были приняты "на ура"? Местные "специалисты", к которым ты относишься с таким пренебрежением, крайне спокойно относятся к паттернам.
E>То, о чем сказал Кнут применительно к re-editable vs. untouchable black box, является основой OpenSource.
Да ладно!
E>Баги, которые находят пользователи OpenSource проектов, патчи для их исправления, патчи с доработками, форки проектов -- это все следствие того самого re-editable подхода, о котором говорит Кнут.
Нет. Re-editable подход тут совершенно ни при чём. В промышленной разработке важен кросс-проектный reuse. Домашнее задание: посмотреть список зависимостей своего любимого Open-Source проекта; убедиться, что даже самый-распресамый ОткрытыйИсходник базируется на "untouchable black box" в значительно большей мере, чем на re-editable code.
E>Востребованность и успешность OpenSource в промышленной разработке нужно доказывать?
Вообще-то да. Потому что у меня, к примеру, неоднократно встречались случаи типа "есть бага, выпущенная в минорном релизе OpenSource 3rdparty, из-за которой мы валимся. Сабмиттить патч — дело бесполезное, потому что
а) у нас нет экспертизы в исходниках этой 3rdparty, чтобы этот патч сделать
б) даже если мы его сделаем, нужно убедить маинтейнеров включить его в следующий релиз
в) даже если патч войдет куда надо, надо дождаться, пока маинтейнеры дистрибутивов заапрувят его в стабильные ветки
г) когда это случится, в стабильную ветку попадёт еще масса изменений, которые потребуют повторного тестирования совместимости на нашей стороне
д) и если там есть изменения, ломающие обратную совместимость, нам придётся выпускать дополнительный релиз
В результате, вместо "reeditable" мы просто выпускаем бюллетень со словами "ОпенХня версии 5.2.3.31 официально не поддерживается нашим софтом. Ждите починки багов вендором".
По мне, так это epic fail опенсорса. А вовсе никакая не "успешность". Успешность — это MS SQL а не MySQL. Это IIS, а не корявый Apache. Это ASP.NET, а не PHP. Вот это я понимаю — успешность.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, COFF, Вы писали: COF>Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне"
Ну, только не ему в ответ, а адресуясь к работникам сети Подорожник, и комментируя вопросы приготовления обеда суммарной стоимостью менее 700 евро.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
E>>Баги, которые находят пользователи OpenSource проектов, патчи для их исправления, патчи с доработками, форки проектов -- это все следствие того самого re-editable подхода, о котором говорит Кнут. S>Нет. Re-editable подход тут совершенно ни при чём. В промышленной разработке важен кросс-проектный reuse. Домашнее задание: посмотреть список зависимостей своего любимого Open-Source проекта; убедиться, что даже самый-распресамый ОткрытыйИсходник базируется на "untouchable black box" в значительно большей мере, чем на re-editable code.
Подмена понятий. Если меня интересует только класса ACE_TTY_IO, то мне пофигу, что на Windows он работает повер WinAPI. Поскольку я подкручиваю под свои нужды именно ACE_TTY_IO, а не WinAPI.
E>>Востребованность и успешность OpenSource в промышленной разработке нужно доказывать? S>Вообще-то да. Потому что у меня, к примеру, неоднократно встречались случаи типа "есть бага, выпущенная в минорном релизе OpenSource 3rdparty, из-за которой мы валимся. Сабмиттить патч — дело бесполезное, потому что
Частные проблемы возводятся в разряд общей ситуации.
Тем более, что на любые проблемы с поддержкой OpenSource проектов можно привести такое же количество проблем с поддержкой закрытых сторонних компонентов.
S>По мне, так это epic fail опенсорса. А вовсе никакая не "успешность". Успешность — это MS SQL а не MySQL. Это IIS, а не корявый Apache. Это ASP.NET, а не PHP. Вот это я понимаю — успешность.
IIS -- успешность? ASP.NET -- успешность?
Не зря я про генеральную линию партии упомянул.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Это ересь по одной простой причине: десятки слегка отличающихся копипаст сложнее поддерживать. Код без ошибок бывает редко, и если ошибка найдена, то придется проверять на её наличие и исправлять все копии. Так что, no thanks, лучше уж наследование и полиморфизм.
Здравствуйте, Sinclair, Вы писали:
COF>>Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне" :) S>Ну, только не ему в ответ, а адресуясь к работникам сети Подорожник, и комментируя вопросы приготовления обеда суммарной стоимостью менее 700 евро.
Это я к тому, что оба на самом деле деле по своему правы. Вопрос в том, что нас больше интересует — приготовление вкусного омлета или стремление накормить как можно больше народа как можно дешевле. Поэтому, тут я с eao197 полностью согласен, нельзя откидывать в сторону мнение Кнута только потому, что он "на фабрике-кухне не работал". По моему мнению, да и опыту тоже, компоненты типа "черный ящик" плохи либо тем, что они перегружены функциональностью, либо их невозможно использовать так как именно нужной функциональности там нет. Естественно, речь не идет о небольших библиотечных функциях и классах, да и с ними проблемы бывают.
Здравствуйте, Sinclair, Вы писали:
E>>Вот именно об этом я и говорил. Человек умудряется писать хороший софт, а его опыт априори отбрасывается только потому, что он работал в других условиях. Специалисты, мать, мать, мать. S>Да, специалисты. Домашнее задание: выяснить, сколько времени потребовала разработка TeX до первого релиза. Прикинуть, есть ли шанс при жизни поучаствовать в коммерческом проекте с таким timeframe. Умножить этот шанс на полезность подхода.
Согласно Wikipedia, разработка первой версии TeX-а началась в 1978-м для PDP-10 на языке SAIL. По ходу дела Кнут разработал язык WEB и транслятор из него в Pascal для PDP-10.
Вторая, полностью переписанная версия TeX82 появилась в 1982-м.
Третья версия, TeX 3 -- в 1989-м. И вскоре после выхода версия 3 была заморожена для дальнейшего развития, в нее принимаются только багфиксы.
Т.о. двенадцать человеко-лет для трех мажорных версий неслабого пакета. Думаю, многие коммерческие проекты хотели бы иметь похожие темпы развития при столь высоком же качестве.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Т.о. двенадцать человеко-лет для трех мажорных версий неслабого пакета. Думаю, многие коммерческие проекты хотели бы иметь похожие темпы развития при столь высоком же качестве.
Я уже не знаю, как бы так потактиченее объяснить, что здесь важны не человеко-годы, а просто годы.
Где ты найдешь коммерческий проект, в котором тебе дадут страдать фигнёй 12 лет, зато потом будет найдено не более дюжины ошибок?
Спроси теперь Великого Кнута — "как разработать TeX 3.14 за один год"? Хватит ли тебе команды из 12 человек? Придется ли делить код на "чёрные ящики", или можно будет остаться в рамках re-editable code?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Где ты найдешь коммерческий проект, в котором тебе дадут страдать фигнёй 12 лет, зато потом будет найдено не более дюжины ошибок?
За двенадцать лет было выпущено три версии.
Согласно околопрограммискому фольклеру (не только ему) чуть ли не половина софтверных проектов выходит за рамки сроков и бюджетов, сильно сокращая при этом заявленную функциональность. На вскидку сейчас вспоминается PalmOS 6.0 на разработку которой, т.е. на фигню в чистом виде, было потрачено несколько лет, но потом все было выброшено коту под хвост. Да и путь от Windows 1.0 к Windows NT 3.51/Windows95 был очень неспешным.
Так что не нужно делать вид, что в промышленной разработке все настолько прекрасно, что никто не страдает фигней годами.
S>Спроси теперь Великого Кнута — "как разработать TeX 3.14 за один год"? Хватит ли тебе команды из 12 человек? Придется ли делить код на "чёрные ящики", или можно будет остаться в рамках re-editable code?
Так почему бы не спросить? Почему нужно заявлять, к словам Кнута "нужно относиться очень осторожно" и "это еще слабо сказано"?
Не говоря уже о том, почему слова Кнута воспринимаются как призыв к глобальному code rewrite.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
L>>Смотри. Если ты написал тип правильно, то, согласно Curry-Howard isomorphism, если функции, использующие этот тип, компилируются, то это будет доказательством того, что тип написан верно.
J>Имхо, это слишком общее утверждение...
... J>Слишком много вариантов мне видится, чтоб вот так вот утверждать, что просто компилируемости достаточно.
Компилируемости достаточно для доказательства инвариантов, описанных в типе.
L>>Написать тип неправильно, конечно, можно тоже, но тогда у тебя это выловится в дальнейшем, когда ты попытаешься с этим типом работать (ожидая от типа, что он описывает определённый граничный случай).
J>Ну так а если он его не описывает и подходит к нему так же, как ко всем остальным?
Тут же вроде разговор идёт о unit test vs DT? Так вот, если он его (граничный случай) не описывает, то неважно где он его не описывает — в юнит тесте или типе, согласен? А если описывает в типе, то юнит тест уже не нужен, т.к. компилируемости достаточно для доказательства.
Я чего здесь не пойму — если программист забыл описать инвариант в DT, то почему в юнит тесте он должен его вспомнить?
Возможно, дело в том, что в юнит тестах часто тестируются следствия инвариантов, а не сами инварианты? Может это смущает?
