Re[41]: Кнут о компонентном программировании.
От: WFrag США  
Дата: 03.08.09 08:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ок. Пусть будет половина смысла от дистрибутивов.

S>Сколько у нас есть этих дистрибутивов? Пара десятков? Сотня?

А сколько в них каждом пакетов? Тысяча? Десяток тысяч? По сути, каждый пакет в дистрибутиве — это микро-форк опенсорсного проекта.

S>А сколько есть всего опенсорсных проектов? Вот в их существовании какую долю смысла будет занимать затачивание, а какую — зависимость от black box?


Между опенсорсными проектами — да, большая часть просто зависимость.

S>Поэтому я и говорю — generally ineffective. Да, в некоторых узких, частных случаях эта техника всё еще применяется.


Она не «всё ещё применяется», это, по моему разумению, единственный способ, когда связка «апстрим» (разработка) — «мейнтейнер» (поддержка) может эффективно работать, если «апстрим» ≠ «мейнтейнер. Ну не будет (скорее всего) автор nginx исправлять дыру в версии годовалой давности. А нам что, каждый раз latest & greatest ставить?

S>Хотя что-то мне подсказывает, что даже в большинстве дистрибутивов всё "затачивание" сводится к компиляции с нестандартным набором ключей и дефайнов, а то и тупо к выбору какого-то подмножества пакетов.


Это не так. К примеру, в Debian Apache и MySQL обкладывается 32 патчами каждый. Тут и безопасность, и мелкие ошибки и соответствие политикам дистрибутива.

S>То есть исходники по-прежнему не трогаются. А вы продолжаете себя гипнотизировать словами "главное — что есть возможность".


Как это не трогаются, если даже взять тот же Debian и окажется, что большая часть (а то и все 100%) опенсорсных проектов, что дистрибутив предоставляет в виде пакетов, обложены патчами? Я не думаю, что в других дистрибутивах ситуация строго противоположная.

Плюс в работе я регулярно использую эту возможность чтобы предоставить клиенту решение здесь и сейчас, а не ждать три месяца пока апстрим почешется и внесёт исправление в их код. Не знаю, почему в твоей компании так не делается (я бы предположил, что вопрос скорее экономический), но чисто технически сложностей пропатчить чужую библиотеку/пакет — нет.

Да даже вот, наткнулись на проблему с MySQL. Можно ждать, когда они выпустят следующий релиз с фиксом (долго) или собирать из VCS транк (ненадёжно), а можно приложить 1 патчик (который они же и распространяют), собрать пакет и поставить.

S>Ну вот, допустим, завтра в РФ официально разрешат браки мужчин с деревьями. И что, это автоматически сделает модель нашего законодательства более правильной? Будет ли главным наличие этой возможности? Даже если двадцать-тридцать фанатов таки зарегистрируют такие браки?


Браками с деревьями не интересуюсь.
Re[2]: Кнут о компонентном программировании.
От: master_of_shadows Беларусь  
Дата: 03.08.09 08:49
Оценка:
Здравствуйте, jazzer, Вы писали:

T>>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.


J>В чем проблема иметь возможность быстро всё исправить в reusable code?


J>А вот если бы с самого начала был _один_ reusable компонент/класс/что-угодно "округлятель" и не разрешалось бы плодить его "легко исправляемые копии", то этого геморроя не было бы.


Хех. Вот теоретик Кнут написал как надо делать. А практики взяли сделали так да не так. Хотя многие в треде ругались — мол Кнут теоретик, не шарит как оно на самом то деле всё происходит . А что выходит? На практике ситуация: 10 ф-ций делающие одно и то же, но чутка по разному сплош и рядом. И иметь возможность их подредактировать, а не налепить горбылей вокруг библиотеки без сорцов, очень важна.
Re[42]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.08.09 09:14
Оценка:
Здравствуйте, WFrag, Вы писали:
WF>Как это не трогаются, если даже взять тот же Debian и окажется, что большая часть (а то и все 100%) опенсорсных проектов, что дистрибутив предоставляет в виде пакетов, обложены патчами? Я не думаю, что в других дистрибутивах ситуация строго противоположная.
Ну, ок. И во всех остальных ситуация именно такая?

WF>Плюс в работе я регулярно использую эту возможность чтобы предоставить клиенту решение здесь и сейчас, а не ждать три месяца пока апстрим почешется и внесёт исправление в их код. Не знаю, почему в твоей компании так не делается (я бы предположил, что вопрос скорее экономический), но чисто технически сложностей пропатчить чужую библиотеку/пакет — нет.

Я пояснял, почему в нашей компании так не делается. Ну, то есть делается, но мы это очень не любим. Потому, что maintenance 3rd party — это не наша любимая работа. Вот ты сделал патч. Дальше апстрим почесался, изменение внёс. Твой патч будет с ними работать? Тебе надо проводить тестирование каждого их релиза на предмет совместимости с твоими патчами. А клиент давит тебе на печень — "we need to urgently rollout this update to our servers, because it includes critical security fixes". И так до тех пор, пока твой патч не включат в транк, если это вообще когда-либо случится. С ростом количества 3rdparty софта ситуация становится "всё страньше и страньше" (с) — тебе приходится бежать всё быстрее для того, чтобы хотя бы оставаться на месте.

WF>Да даже вот, наткнулись на проблему с MySQL. Можно ждать, когда они выпустят следующий релиз с фиксом (долго) или собирать из VCS транк (ненадёжно), а можно приложить 1 патчик (который они же и распространяют), собрать пакет и поставить.

Ключевые слова выделены. Это по-прежнему blackbox методика, вид сбоку.
В мире закрытых исходников есть полный аналог — специфические хотфиксы, которые МС раздаёт тем, кто наступил на определённые грабли. Точно так же, чтобы не ждать MS SQL 2008 SP2, ты ставишь конкретный хотфикс на конкретный инстанс. Никакого отношения к возможности "поправить код" это не имеет.

WF>Браками с деревьями не интересуюсь.

Ну вот и меня не интересует теоретическая возможность внести в код мускуля произвольные изменения. И никого, по большому счёту, это не интересует — кроме профессиональных маинтейнеров чего-нибудь там. Но профессиональный майнтенанс — это узкоспециальная ниша. Думать, что он главный — всё равно, что считать основной идеей мерседеса возможность существования гелендвагена.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 03.08.09 09:50
Оценка:
Здравствуйте, master_of_shadows, Вы писали:

__>Здравствуйте, jazzer, Вы писали:


T>>>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.


J>>В чем проблема иметь возможность быстро всё исправить в reusable code?


J>>А вот если бы с самого начала был _один_ reusable компонент/класс/что-угодно "округлятель" и не разрешалось бы плодить его "легко исправляемые копии", то этого геморроя не было бы.


__>Хех. Вот теоретик Кнут написал как надо делать. А практики взяли сделали так да не так. Хотя многие в треде ругались — мол Кнут теоретик, не шарит как оно на самом то деле всё происходит . А что выходит? На практике ситуация: 10 ф-ций делающие одно и то же, но чутка по разному сплош и рядом. И иметь возможность их подредактировать, а не налепить горбылей вокруг библиотеки без сорцов, очень важна.


Что-то я так и не понял, то ли ты споришь, то ли соглашаешься...
И с кем споришь/соглашается, тоже не понял...
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[43]: Кнут о компонентном программировании.
От: WFrag США  
Дата: 03.08.09 10:13
Оценка:
Здравствуйте, Sinclair, Вы писали:

WF>>Как это не трогаются, если даже взять тот же Debian и окажется, что большая часть (а то и все 100%) опенсорсных проектов, что дистрибутив предоставляет в виде пакетов, обложены патчами? Я не думаю, что в других дистрибутивах ситуация строго противоположная.

S>Ну, ок. И во всех остальных ситуация именно такая?

Не понял вопроса. Я просто хорошо знаком с Debian-ом и понимаю, зачем они это всё делают, вот и привожу его в пример. Предполагаю, что в коммерческих дистрибутивах уровень их вмешательства в код других проектов ещё больше — в конце-концов, им за это по сути и платят.

S>Я пояснял, почему в нашей компании так не делается. Ну, то есть делается, но мы это очень не любим. Потому, что maintenance 3rd party — это не наша любимая работа. Вот ты сделал патч. Дальше апстрим почесался, изменение внёс. Твой патч будет с ними работать? Тебе надо проводить тестирование каждого их релиза на предмет совместимости с твоими патчами. А клиент давит тебе на печень — "we need to urgently rollout this update to our servers, because it includes critical security fixes". И так до тех пор, пока твой патч не включат в транк, если это вообще когда-либо случится. С ростом количества 3rdparty софта ситуация становится "всё страньше и страньше" (с) — тебе приходится бежать всё быстрее для того, чтобы хотя бы оставаться на месте.


Согласен, так и есть. Это я и имел ввиду под экономическими причинами. Выгода от своего патча в вашем случае скорее всего меньше, чем трудозатраты.

WF>>Да даже вот, наткнулись на проблему с MySQL. Можно ждать, когда они выпустят следующий релиз с фиксом (долго) или собирать из VCS транк (ненадёжно), а можно приложить 1 патчик (который они же и распространяют), собрать пакет и поставить.


S>Ключевые слова выделены. Это по-прежнему blackbox методика, вид сбоку. В мире закрытых исходников есть полный аналог — специфические хотфиксы, которые МС раздаёт тем, кто наступил на определённые грабли. Точно так же, чтобы не ждать MS SQL 2008 SP2, ты ставишь конкретный хотфикс на конкретный инстанс. Никакого отношения к возможности "поправить код" это не имеет.


Ок, MySQL не очень хороший пример, т.к они и сами занимаются поддержкой в какой-то мере, плюс ещё и платная есть, где тебе сделают всё, что захочешь. А вот nginx — вряд ли. Максимум, что автор, скорее всего, сделает — это закоммитит фикс в VCS и всё.

S>Ну вот и меня не интересует теоретическая возможность внести в код мускуля произвольные изменения. И никого, по большому счёту, это не интересует — кроме профессиональных маинтейнеров чего-нибудь там. Но профессиональный майнтенанс — это узкоспециальная ниша. Думать, что он главный — всё равно, что считать основной идеей мерседеса возможность существования гелендвагена.


Меня это косвенно интересует, так как иначе я не могу быть уверенным, что тот же Debian обеспечит мне обещанный уровень сервиса.

Вот представь, что официальных СТО нет (или их мало, они работают медленно, дорого, и.т.д) и ты предлагаешь запретить ремонт автомобиля всем, кроме его производителей (а в случае опен-сорса, производителей вообще куча, каждый со своими задвигами). Интересует тебя возможность открыть капот и поменять свечи? Лично — скорее всего нет, косвенно — да, ты можешь приехать в удобный тебе сервис и тебе поменяют свечи.
Re[4]: Кнут о компонентном программировании.
От: master_of_shadows Беларусь  
Дата: 03.08.09 10:37
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Что-то я так и не понял, то ли ты споришь, то ли соглашаешься...


Начал читать тред. Увидел разборки в духе — да Кнут теоретик, в практике не силён. Потом твой ответ. Заметил, что у вас в коде классика: 10 похожих ф-ций, которые ну никак не тянут на reusable компонент. Тебе хотелось бы, что бы они были 1-ой, но на практике обычно их 10. А ещё бывает, что нужно пропатчить код в сторонней библиотеке без сорцов — код обрастает костылями. Таким вот хитрым образом "голая теория" Кнута оказалась более практичной нежели самая что ни на есть суровая практика .

J>И с кем споришь/соглашается, тоже не понял...


Да вроде и не спорю/соглашаюсь, просто наблюдение из ответа.
Re[44]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.08.09 10:38
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Согласен, так и есть. Это я и имел ввиду под экономическими причинами. Выгода от своего патча в вашем случае скорее всего меньше, чем трудозатраты.

Воот. И у нас случай достаточно типичный — обрати внимание, что мы пишем софт.

WF>Ок, MySQL не очень хороший пример, т.к они и сами занимаются поддержкой в какой-то мере, плюс ещё и платная есть, где тебе сделают всё, что захочешь. А вот nginx — вряд ли. Максимум, что автор, скорее всего, сделает — это закоммитит фикс в VCS и всё.

Не очень понял. Ты хочешь сказать, что типичные разработчики решений на основе nginx самостоятельно подтачивают его под свои нужды, и маинтейнят это чудо всю жизнь? А мне вот казалось, что большинству это нахрен не упёрлось — если в нём есть проблема, и её не чинят, то скорее перейдут на тот софт, где этой проблемы нет.

WF>Вот представь, что официальных СТО нет (или их мало, они работают медленно, дорого, и.т.д) и ты предлагаешь запретить ремонт автомобиля всем, кроме его производителей (а в случае опен-сорса, производителей вообще куча, каждый со своими задвигами).

Нет. Я предлагаю отказаться рассматривать автомобили с точки зрения возможности вносить изменения, не предусмотренные производителем.

WF>Интересует тебя возможность открыть капот и поменять свечи? Лично — скорее всего нет, косвенно — да, ты можешь приехать в удобный тебе сервис и тебе поменяют свечи.

Меня не интересует возможность проапгрейдить мерседес до гелендвагена. Аналог замены свечей — это конфигурирование апача. Да, именно оно меня интересует. Несмотря на то, что лично я его делать не буду — поеду на СТО, то есть к админу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[45]: Кнут о компонентном программировании.
От: Cyberax Марс  
Дата: 03.08.09 10:48
Оценка:
Здравствуйте, Sinclair, Вы писали:

WF>>Ок, MySQL не очень хороший пример, т.к они и сами занимаются поддержкой в какой-то мере, плюс ещё и платная есть, где тебе сделают всё, что захочешь. А вот nginx — вряд ли. Максимум, что автор, скорее всего, сделает — это закоммитит фикс в VCS и всё.

S>Не очень понял. Ты хочешь сказать, что типичные разработчики решений на основе nginx самостоятельно подтачивают его под свои нужды, и маинтейнят это чудо всю жизнь?
Примерно так и происходит. Обычно только патчи засылаются в upstream, конечно.

S>А мне вот казалось, что большинству это нахрен не упёрлось — если в нём есть проблема, и её не чинят, то скорее перейдут на тот софт, где этой проблемы нет.

В IIS-е вот не оказалось нужной фичи => сразу переписываем всё на PHP?

Очень часто проще всего сделать нужный фикс в соответствующий пакет. С хотфиксами ситуация другая — если ты не компания с миллионными контрактами поддержки, то MS ради тебя не пошевелится. Ну или пошевелится через пару месяцев.
Sapienti sat!
Re[45]: Кнут о компонентном программировании.
От: WFrag США  
Дата: 03.08.09 11:12
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

WF>>Ок, MySQL не очень хороший пример, т.к они и сами занимаются поддержкой в какой-то мере, плюс ещё и платная есть, где тебе сделают всё, что захочешь. А вот nginx — вряд ли. Максимум, что автор, скорее всего, сделает — это закоммитит фикс в VCS и всё.

S>Не очень понял. Ты хочешь сказать, что типичные разработчики решений на основе nginx самостоятельно подтачивают его под свои нужды, и маинтейнят это чудо всю жизнь? А мне вот казалось, что большинству это нахрен не упёрлось — если в нём есть проблема, и её не чинят, то скорее перейдут на тот софт, где этой проблемы нет.

Возможны разные ситуации. Если рассматривать такое явление, как дистрибутивы Linux, то имеем следующее:

1) Если рассматривать безопасность, то может быть и прямо так. Например, у моего любимого Debian-а релиз-цикл по факту выходит примерно 1.5 года. Все эти полтора года версии пакетов в дистрибутиве не обновляются. За редким исключением.

Что они делают, если обнаруживается дыра? У них есть специальная Security Team, которая либо изобретает патч, либо вытаскивает его из апстрим-репозитория, либо ещё откуда-то и портирует на старую версию. Патч прикладывается, версия остаётся прежняя.

Кроме дыр они ничего в стабильном дистрибутиве не исправляют, увы.


2) Если речь о базовом функционале функционале, то зависит от мейнтенеров/политики/etc. Debian-овские мейнтенеры, в принципе, и сами правят баги и пуляют патчи в апстрим. Но это в тестируемом/нестабильном дистрибутиве. А могут просто ждать, пока апстрим поправит проблему.


3) Есть ещё функционал, специфичный для дистрибутива. Например, пути, соответствие политикам, целям дистрибутива, и.т.д. Такие патчи, насколько я понимаю, они мейнтейнят всю жизнь (или до тех пор, пока исходный код вдруг их не примет), портируя их постепенно на более новые версии.


Соответственно, если отбирать у них возможность править им самим, то теряем 1) и 3) и часть 2). Получаем Slackware, что ли Нафиг мне такой дистрибутив — не знаю, в продакшен я бы его ставить не стал. Ни быстрой реакции на дыры, ни «единой политики партии».

Плюс есть ещё ребята типа IBM/Oracle, которые берут Apache и мейнтейнят его всю жизнь (ну, не свю жизнь, но с довольно большим лагом), предлагая в комплекте со своим коммерческим продуктом.


Кстати, почему обязательно «маинтейнят это чудо всю жизнь»? Современные инструменты (VCS, системы управления патчами, и.т.д) позволяют относительно безболезненно портировать патчи на более новую версию. Понятно, что мажорный релиз патчи могут и не пережить, но в пределах одной мажорной версии некоторый лаг вполне может быть — по соображениям безопасности/тестированности/и.т.д.


В общем, в моём видении мира возможность править исходники самостоятельно более чем востребовано. Большей частью для схем, где одна сторона что-то там разрабатывает, а вторая на основе этого чего-то делает продукт с поддержкой и какими-то гарантиями, причём эта схема совсем редкость для опен-сорс софта.
Re[3]: Кнут о компонентном программировании.
От: Baudolino  
Дата: 03.08.09 13:17
Оценка:
T>Я не рекомендую считать Кнута глупее себя.
Я не рекомендую давать такие советы.

T>Ты про expression problem слышал? Наследование и полиморфизм не решают её.

Наследование и полиморфизм многого не решают, но все равно остаются прекрасными инструментами.
Re[4]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.08.09 13:45
Оценка:
Здравствуйте, Baudolino, Вы писали:

T>>Я не рекомендую считать Кнута глупее себя.

B>Я не рекомендую давать такие советы.

Хорошо. Дам совет в положительном ключе.

Я рекомендую считать Кнута умней себя.

Твой ход.

T>>Ты про expression problem слышал? Наследование и полиморфизм не решают её.

B>Наследование и полиморфизм многого не решают, но все равно остаются прекрасными инструментами.

Для весьма ограниченного круга задач.

Ты, как я понял, в expression problem всё ещё не ухом, ни рылом, так?

Позволю дать тебе совет: прочитай про неё, это очень важная задача, напрямую относящаяся к возможной неправоте Кнута.

Заодно поймёшь, с помощью чего она лучше решается. И где там используются "наследование и полиморфизм".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 03.08.09 16:52
Оценка:
Здравствуйте, master_of_shadows, Вы писали:

__> Заметил, что у вас в коде классика: 10 похожих ф-ций, которые ну никак не тянут на reusable компонент.

Отлично тянут. Просто их боятся трогать.

__>Тебе хотелось бы, что бы они были 1-ой, но на практике обычно их 10.

Из того, что обобщенные индусы пишут спагетти-код, не следует, что спагетти — это практично.
Из этого следует только, что их не научили писать по-человечески.

__> А ещё бывает, что нужно пропатчить код в сторонней библиотеке без сорцов — код обрастает костылями.

А это никакого отношения к теме не имеет, это задача совершенно другого плана.
И решается она созданием своей легковесной библиотеки-обертки, которая сдержит эти самые костыли и перепранаправляет вызовы в стороннюю библиотеку.
Причем _одной_ обертки со всеми костылями, а не садом разнокалиберных "легких в исправлении" почти (и никто тебе не расскажет, в чем заключается "почти", потому что тот парень уволился уже пару лет как) одинаковых костылей, разбросанных по всему коду проекта вперемежку с осмысленным кодом.

__> Таким вот хитрым образом "голая теория" Кнута оказалась более практичной нежели самая что ни на есть суровая практика .

см. выше про спагетти.


"Практично" — это не, что встречается в практике (иначе это все равно что сказать, что затягивание сроков в 10 раз — это практично, потому что куча программеров затягивает сроки).
"Практично" — это то, что помогает практике, делая ее более простой, эффективной и управляемой.
Про спагетти код, или про 10 функций вместо одной этого сказать никак нельзя.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: Кнут о компонентном программировании.
От: master_of_shadows Беларусь  
Дата: 03.08.09 17:51
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Из того, что обобщенные индусы пишут спагетти-код, не следует, что спагетти — это практично.

J>Из этого следует только, что их не научили писать по-человечески.

Ну мало ли что следует в красивой и стройной теории. На практике оно завсегда по другому выглядит .

__>> Таким вот хитрым образом "голая теория" Кнута оказалась более практичной нежели самая что ни на есть суровая практика .

J>см. выше про спагетти.

J>"Практично" — это не, что встречается в практике (иначе это все равно что сказать, что затягивание сроков в 10 раз — это практично, потому что куча программеров затягивает сроки).


В общем, что вы сделали? Переписали всё в один классную реюзаебльную ф-ию, или таки оставили лапшу из 10-ти ф-ций?

J>"Практично" — это то, что помогает практике, делая ее более простой, эффективной и управляемой.

J>Про спагетти код, или про 10 функций вместо одной этого сказать никак нельзя.

А что делать, если оно так есть по факту? Хоть в лепёшку разбейся, а такие случаи не исключение, а скорее правило.
Re[5]: Кнут о компонентном программировании.
От: Baudolino  
Дата: 03.08.09 19:04
Оценка: :)
T>Ты, как я понял, в expression problem всё ещё не ухом, ни рылом, так?
Рыло у свиней. Вы поняли неправильно. Я не вижу смысла в дальнейшем обсуждении притянутых за уши тем. Да и кто вы собственно такой, чтобы давать мне подобные советы?
Re[7]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 03.08.09 22:54
Оценка:
Здравствуйте, master_of_shadows, Вы писали:

__>Здравствуйте, jazzer, Вы писали:


J>>Из того, что обобщенные индусы пишут спагетти-код, не следует, что спагетти — это практично.

J>>Из этого следует только, что их не научили писать по-человечески.

__>Ну мало ли что следует в красивой и стройной теории. На практике оно завсегда по другому выглядит .

Ага, а получается, как всегда.
Только это не значит, что надо следовать рекомендации "Делайте, как всегда".

__>>> Таким вот хитрым образом "голая теория" Кнута оказалась более практичной нежели самая что ни на есть суровая практика .

J>>см. выше про спагетти.

J>>"Практично" — это не, что встречается в практике (иначе это все равно что сказать, что затягивание сроков в 10 раз — это практично, потому что куча программеров затягивает сроки).


__>В общем, что вы сделали? Переписали всё в один классную реюзаебльную ф-ию, или таки оставили лапшу из 10-ти ф-ций?

Я оттуда ушел несколько лет назад, так что не знаю, но подозреваю, что так и осталось все.
Там люди очень боятся слова "рефакторинг".

А теперь они еще получили поддержку со стороны такого авторитета, как Кнут
И если теперь им кто-нть заикнется, что нужна одна функция, то они его носом ткнут в транспарант на стене, в котором эти слова Кнута записаны.

А на моей нынешней работе такого просто не допускается, т.е. в такой ситуации была бы одна функция.
И вот это как раз практично, а не "как всегда".

J>>"Практично" — это то, что помогает практике, делая ее более простой, эффективной и управляемой.

J>>Про спагетти код, или про 10 функций вместо одной этого сказать никак нельзя.

__>А что делать, если оно так есть по факту? Хоть в лепёшку разбейся, а такие случаи не исключение, а скорее правило.

Такие случаи называются bad practice, и это не повод говорить "Ага, так и надо всем делать".

Мне твои слова напоминают "И зачем калькуляторы придумали и говорят, что это практичнее? Вон 90% до сих пор считают на счетах, а калькуляторы — это исключение, так что правы те, которые говорят, что надо считать все на счетах". Или давайте не будем читать учиться, вон, в Афганистане 70% населения читать не умеют, и ничего.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: Кнут о компонентном программировании.
От: master_of_shadows Беларусь  
Дата: 04.08.09 08:09
Оценка:
Здравствуйте, jazzer, Вы писали:

__>>Ну мало ли что следует в красивой и стройной теории. На практике оно завсегда по другому выглядит .

J>Ага, а получается, как всегда.
J>Только это не значит, что надо следовать рекомендации "Делайте, как всегда".
Ах ты ж ёклмн. Это значит только то, что на практике всё красивое в большинстве случаев становится как всегда. И красивые теоретические мехнизмы в духе "а мы подправим 1 ф-ию" срабатывают реже, чем "мы подправим 10".

__>>В общем, что вы сделали? Переписали всё в один классную реюзаебльную ф-ию, или таки оставили лапшу из 10-ти ф-ций?

J>Я оттуда ушел несколько лет назад, так что не знаю, но подозреваю, что так и осталось все.
J>Там люди очень боятся слова "рефакторинг".

И правильно делают . Плохой рефакторинг хуже татарина.
Рефакторингом можно сделать лучше, а можно так сломать, что разгребаться придётся долго. И чем больше проект, и чем большим кол-вом бабла он ворочает, чем меньше желания браться за рефакторинг.

J>А на моей нынешней работе такого просто не допускается, т.е. в такой ситуации была бы одна функция.

J>И вот это как раз практично, а не "как всегда".

Эт хорошо, да.

__>>А что делать, если оно так есть по факту? Хоть в лепёшку разбейся, а такие случаи не исключение, а скорее правило.

J>Такие случаи называются bad practice, и это не повод говорить "Ага, так и надо всем делать".

J>Мне твои слова напоминают "И зачем калькуляторы придумали и говорят, что это практичнее? Вон 90% до сих пор считают на счетах, а калькуляторы — это исключение, так что правы те, которые говорят, что надо считать все на счетах". Или давайте не будем читать учиться, вон, в Афганистане 70% населения читать не умеют, и ничего.


Передёргиваеш. Ты говориш: тебе нравится г-но, поэтому совковая лопата и рулит по его разгребанию. А я же на самом деле говорю: так как г-на много, то рулит по его разгребанию совковая лопата.
Re[9]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 04.08.09 11:27
Оценка: +1
Здравствуйте, master_of_shadows, Вы писали:

__>Здравствуйте, jazzer, Вы писали:


__>>>Ну мало ли что следует в красивой и стройной теории. На практике оно завсегда по другому выглядит .

J>>Ага, а получается, как всегда.
J>>Только это не значит, что надо следовать рекомендации "Делайте, как всегда".
__>Ах ты ж ёклмн. Это значит только то, что на практике всё красивое в большинстве случаев становится как всегда. И красивые теоретические мехнизмы в духе "а мы подправим 1 ф-ию" срабатывают реже, чем "мы подправим 10".
Ну и где в случае с 10 функциями красивое стало "как всегда"? Красивое просто изчезло, если и было когда-то.
А вот если бы красивое насаждалось сверху, а получалось все равно как всегда — вот тогда был бы разговор.

__>>>В общем, что вы сделали? Переписали всё в один классную реюзаебльную ф-ию, или таки оставили лапшу из 10-ти ф-ций?

J>>Я оттуда ушел несколько лет назад, так что не знаю, но подозреваю, что так и осталось все.
J>>Там люди очень боятся слова "рефакторинг".

__>И правильно делают . Плохой рефакторинг хуже татарина.

А хороший?
__>Рефакторингом можно сделать лучше, а можно так сломать, что разгребаться придётся долго. И чем больше проект, и чем большим кол-вом бабла он ворочает, чем меньше желания браться за рефакторинг.
Ага, и через 3 года проект становится окончательно неуправляемым, и никто не может сказать, что где происходит, не покопавшись в коде пару недель. Плавали, знаем.

J>>А на моей нынешней работе такого просто не допускается, т.е. в такой ситуации была бы одна функция.

J>>И вот это как раз практично, а не "как всегда".

__>Эт хорошо, да.

А то

__>>>А что делать, если оно так есть по факту? Хоть в лепёшку разбейся, а такие случаи не исключение, а скорее правило.

J>>Такие случаи называются bad practice, и это не повод говорить "Ага, так и надо всем делать".

J>>Мне твои слова напоминают "И зачем калькуляторы придумали и говорят, что это практичнее? Вон 90% до сих пор считают на счетах, а калькуляторы — это исключение, так что правы те, которые говорят, что надо считать все на счетах". Или давайте не будем читать учиться, вон, в Афганистане 70% населения читать не умеют, и ничего.


__>Передёргиваеш. Ты говориш: тебе нравится г-но, поэтому совковая лопата и рулит по его разгребанию. А я же на самом деле говорю: так как г-на много, то рулит по его разгребанию совковая лопата.

Сорри, не уловил здесь разгребания. В данном случае, если нет одного места, то совковая лопата поможет перекидать все материалы к соседу. Иными словами, что ты предлагаешь для разгребания спагетти-кода? Просто взять и узаконить практику, вооружась словами Кнута, чтоб люди, генеря спагетти, по крайней мере не мучались от угрызений совести?

Если уж пошли такие аналогии, то это "гадить только в туалете с канализацией (reusable component) — это все красивые слова. А практично — это гадить где попало, но аккуратными (easy editable) кучками, чтоб легко было убирать".

Короче, что ты предлагаешь-то для решения проблемы, если повторно используемые компоненты тебе кажутся недостижимым и непрактичным идеалом?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: Кнут о компонентном программировании.
От: master_of_shadows Беларусь  
Дата: 04.08.09 11:48
Оценка:
Здравствуйте, jazzer, Вы писали:

__>>Ах ты ж ёклмн. Это значит только то, что на практике всё красивое в большинстве случаев становится как всегда. И красивые теоретические мехнизмы в духе "а мы подправим 1 ф-ию" срабатывают реже, чем "мы подправим 10".

J>Ну и где в случае с 10 функциями красивое стало "как всегда"? Красивое просто изчезло, если и было когда-то.
J>А вот если бы красивое насаждалось сверху, а получалось все равно как всегда — вот тогда был бы разговор.

Не понимаю я тебя. Я говорю о том, что есть лапша из 10-и ф-ций. И такое сплош и рядом. Самая что ни на есть суровая реальность.

__>>И правильно делают . Плохой рефакторинг хуже татарина.

J>А хороший?

А его (хорошего) ещё надо постараться сделать. А так конечно, хороший рулит .

__>>Рефакторингом можно сделать лучше, а можно так сломать, что разгребаться придётся долго. И чем больше проект, и чем большим кол-вом бабла он ворочает, чем меньше желания браться за рефакторинг.

J>Ага, и через 3 года проект становится окончательно неуправляемым, и никто не может сказать, что где происходит, не покопавшись в коде пару недель. Плавали, знаем.

Живут такие проекты и десятки лет. Зависит от того, как часто в него лезут новые фичи добавлять.
Есть хорошая пословица: если чего работает, ничего сынок не трогай, ничего не меняй.
Конечно хотелось бы, что б всё было красиво. Но увы и ах, такое далеко не всегда. И прежде чем доставать шашку и рубать на право и на лево стоит задуматься: а оно надо? Надо ли переписывать дестяки мегабайт кода, ради того, что бы 10-ть ф-ций стали 1-ой, и можно было бы красиво заимплементить CR/пофиксать баг?
Если что, то устриц ел. И рефакторил по чуть чуть и по многу, и отгребал потом, и радовался когда выходило нормально. Рефакторил в 90% чужой код.

J>Сорри, не уловил здесь разгребания. В данном случае, если нет одного места, то совковая лопата поможет перекидать все материалы к соседу. Иными словами, что ты предлагаешь для разгребания спагетти-кода? Просто взять и узаконить практику, вооружась словами Кнута, чтоб люди, генеря спагетти, по крайней мере не мучались от угрызений совести?

Как это не уловил. Вот смотри: есть спагети код, надо пофиксать баг — это и есть разгребание.
Ты почему-то упорно на меня клеиш ярлык любителя г-но кода .

J>Если уж пошли такие аналогии, то это "гадить только в туалете с канализацией (reusable component) — это все красивые слова. А практично — это гадить где попало, но аккуратными (easy editable) кучками, чтоб легко было убирать".


Опять передёргиваеш. Если уж нагаженно где ни попадя, то лучше что б оно было кучками, чем тонким слоем.

J>Короче, что ты предлагаешь-то для решения проблемы, если повторно используемые компоненты тебе кажутся недостижимым и непрактичным идеалом?


Я? Ничего . Я просто заметил (как уже писал выше), что чистая теория Кнута в духе: лучше иметь сорцы, чем тучу компонент. На практике оказалась, в твоём же примере, практичней имения 10-ти закрытых компонентов .
Вот собственно и всё.
Re[11]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 04.08.09 12:15
Оценка:
Здравствуйте, master_of_shadows, Вы писали:

__>Не понимаю я тебя. Я говорю о том, что есть лапша из 10-и ф-ций. И такое сплош и рядом. Самая что ни на есть суровая реальность.

А, ну хорошо, с этим согласен. С этим никто и не спорит, тем паче что я сам же и привел пример с 10-ю функциями. Только это никакого отношения к правильности/неправильности повторного использования не имеет.

__>>>Рефакторингом можно сделать лучше, а можно так сломать, что разгребаться придётся долго. И чем больше проект, и чем большим кол-вом бабла он ворочает, чем меньше желания браться за рефакторинг.

J>>Ага, и через 3 года проект становится окончательно неуправляемым, и никто не может сказать, что где происходит, не покопавшись в коде пару недель. Плавали, знаем.

__>Живут такие проекты и десятки лет. Зависит от того, как часто в него лезут новые фичи добавлять.

Вот-вот, через три года он уже неуправляем, а живет еще десятки лет.
__>Есть хорошая пословица: если чего работает, ничего сынок не трогай, ничего не меняй.
А если не работает? Или плохо работает? Лепить заплатки или делать нормальное решение?

__>Конечно хотелось бы, что б всё было красиво. Но увы и ах, такое далеко не всегда. И прежде чем доставать шашку и рубать на право и на лево стоит задуматься: а оно надо? Надо ли переписывать дестяки мегабайт кода, ради того, что бы 10-ть ф-ций стали 1-ой, и можно было бы красиво заимплементить CR/пофиксать баг?


Во-первых, смёржить 10 функций в одну — это не ахти какой сложный рефакторинг, просто search/replace-ом поменять имена функций. Вопрос только в изначальном прояснении того, что во всех местах должно происходить, и в последующем тестировании.
На все это нужно время и силы, которые тратить лень, однако, ты сам понимаешь, это однократное вложение окупится сторицей в последующей поддержке.
Во-вторых, надо было изначально делать так, чтоб не появлялась даже вторая функция, не то что десятая — тогда вообще бы эти проблемы не возникли — ты ведь не будешь с этим спорить?

__>Если что, то устриц ел. И рефакторил по чуть чуть и по многу, и отгребал потом, и радовался когда выходило нормально. Рефакторил в 90% чужой код.

И что, с высоты твоего опыта, ты считаешь, что не надо рефакторить было, раз работало до рефакторинга?

J>>Сорри, не уловил здесь разгребания. В данном случае, если нет одного места, то совковая лопата поможет перекидать все материалы к соседу. Иными словами, что ты предлагаешь для разгребания спагетти-кода? Просто взять и узаконить практику, вооружась словами Кнута, чтоб люди, генеря спагетти, по крайней мере не мучались от угрызений совести?

__>Как это не уловил. Вот смотри: есть спагети код, надо пофиксать баг — это и есть разгребание.
Разгребание — это уничтожение спагетти.
А точечная правка — это просто перебрасывание спагетти на другой край тарелки.

__>Ты почему-то упорно на меня клеиш ярлык любителя г-но кода .

Не-не, я понятия не имею, чего ты любитель, сорри, если мои слова так выглядят! Но ты явно его защитник Хотя я несолько раз обмолвился, что не вполне понимаю посыл твоих постов — то ли ты за, то ли против, то ли просто стоишь в сторонке и комментируешь

J>>Короче, что ты предлагаешь-то для решения проблемы, если повторно используемые компоненты тебе кажутся недостижимым и непрактичным идеалом?


__>Я? Ничего . Я просто заметил (как уже писал выше), что чистая теория Кнута в духе: лучше иметь сорцы, чем тучу компонент. На практике оказалась, в твоём же примере, практичней имения 10-ти закрытых компонентов .

__>Вот собственно и всё.

Стоп. Всё наоборот. У меня как раз были 10 (может, их там уже 20 ) почти одинаковых функций с сорцами, а не один повторно-используемый компонент. Т.е. применение теории Кнута в чистом виде — никакого повторного использования, у нас есть супер-паттерн программирования copy/paste.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[12]: Кнут о компонентном программировании.
От: master_of_shadows Беларусь  
Дата: 04.08.09 12:44
Оценка:
Здравствуйте, jazzer, Вы писали:

J>А, ну хорошо, с этим согласен. С этим никто и не спорит, тем паче что я сам же и привел пример с 10-ю функциями. Только это никакого отношения к правильности/неправильности повторного использования не имеет.

Так это и есть практика. Оно есть (спагетти), а как уже его получше приготовить — вот вопрос.

__>>Есть хорошая пословица: если чего работает, ничего сынок не трогай, ничего не меняй.

J>А если не работает? Или плохо работает? Лепить заплатки или делать нормальное решение?
А если работает, но с полу-терпимыми багами? Или плохо, а через 3-и месяца как-бы выходит паралельный проект, который лучше? Или плохо, а людей разбирающихся что внутри нет, ибо не лазили в него 3-и года? И т.д. Каждый случай в некотором роде уникален.
Я призываю думать, прежде чем шашку доставать .

J>Во-первых, смёржить 10 функций в одну — это не ахти какой сложный рефакторинг, просто search/replace-ом поменять имена функций. Вопрос только в изначальном прояснении того, что во всех местах должно происходить, и в последующем тестировании.

Ну если б оно было так просто, то уже бы и смерджили . Вот второе твоё предложение и объясняет почему не смерджили . Одно дело поменять в 10-и местах string.Format(...) и совсем другое дело, силы и время разобраться как работает, кто и как использует, смерджить, протестировать и быть уверенным что оно взлетит.
Нет, я не против рефакторинга, а даже за. Весь мой идиалистический взгляд на мир говорит — надо что бы было красиво и правильно. Но память/разум тихо, но настойчиво говорят: подумай, а стоит ли именно тут шашкой махать?

J>И что, с высоты твоего опыта, ты считаешь, что не надо рефакторить было, раз работало до рефакторинга?

Чаще было больше плюсов, чем минусов. Только надо понимать, что процесс рефакторинга куда более сложная задача чем костыле-строительство. На неё надо более подкованный человек(и), это больший риск, это больший срок, за это не платят. А клиент сидит на голове и говорит, что фикс ему нужен ещё вчера.

J>Разгребание — это уничтожение спагетти.

Мы в терминах не сошлись. Я под разгребать имел ввиду процесс работы как таковой: "грести лопатой".

J>А точечная правка — это просто перебрасывание спагетти на другой край тарелки.

Ага.

J>Не-не, я понятия не имею, чего ты любитель, сорри, если мои слова так выглядят! Но ты явно его защитник Хотя я несолько раз обмолвился, что не вполне понимаю посыл твоих постов — то ли ты за, то ли против, то ли просто стоишь в сторонке и комментируешь

Скорее в сторонке. Но защищаю г-но код, пусть сирый и убогий но он есть, работает хоть как-то, а идального ещё нет. Но это не повод к последнему не стремится .

J>Стоп. Всё наоборот. У меня как раз были 10 (может, их там уже 20 ) почти одинаковых функций с сорцами, а не один повторно-используемый компонент. Т.е. применение теории Кнута в чистом виде — никакого повторного использования, у нас есть супер-паттерн программирования copy/paste.

Ну Кнут таки говорил не о копи/паст, а о том, что ему больше нравится наличие сорцов, чем наличие чёрных коробок.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.