Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 09.07.09 15:12
Оценка: 11 (4) +4 -8 :)

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


Пожалуй, подпишусь.

Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.09 17:16
Оценка: 3 (3) +7 -1
Здравствуйте, thesz, Вы писали:

T>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


T>Пожалуй, подпишусь.


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


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

Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.

Исходный же код, на мой взгляд, намного более важен не для исправления чужих багов, а для понимания работы кода. Особенно это нужно когда ты развиваешь чужие продукты (например встраиваешь язык в некоторую IDE). Но для этой цели обычно бывает достаточно декомпилированного кода (если речь идет о дотнете или яве). Хотя конечно лучше иметь возможность пройтись по нему отладчиком.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 09:14
Оценка: 6 (1) +7
Здравствуйте, Ikemefula, Вы писали:

I>Да, да, я решил проста так посмеяться, представь, вижу Влад про Кнута пишет, дай, думаю, посмеюсь.


В этом признании больше всего сомнений вызывает слово "думаю".

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


Индустрия производства ПО, по мнению некоторых участников RSDN, находится в глубокой заднице. При этом программисты-практики, как представители этой самой индустрии, позволяют себе смеятся над человеком, достижения которого (как программиста) им и не повторить. Вместо того, чтобы подумать, а за счет чего Кнуту удается (удавалось) в одиночку делать так много и так хорошо. Может быть и его взгляд на повторное использование не так уж нелеп, как это кажется.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.07.09 10:25
Оценка: +3 :))) :))
Здравствуйте, Ikemefula, Вы писали:

VD>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>И это еще слабо сказано !


Авторитетно заявил офигенный программист-практик XXI века.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 08:21
Оценка: 40 (2) +1 -2 :))
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 09:07
Оценка: 3 (1) +2 -2 :))
Здравствуйте, Sinclair

Если после этого Синклер еще кого-нибудь обвинит в демагогии...


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[42]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 07:12
Оценка: +4 -1 :)
Здравствуйте, eao197, Вы писали:

E>Пример. Синклер здесь утверждал, что IIS -- это успех, в отличии от Apache. Поскольку Синклер не был замечен в причастности к альтернативным MS продуктам, его информация нуждается в проверке. Получается вот что: http://news.netcraft.com/archives/web_server_survey.html

Эта информация в первую очередь нуждается в осмыслении. Например, нужно сначала разобраться, какой успех имелся в виду. Это очень трудно сделать, ведь для этого придётся восстановить контекст беседы:

Востребованность и успешность OpenSource в промышленной разработке нужно доказывать?

То есть прежде, чем глядеть в убедительные графики неткрафта, стоит задуматься — а все ли сервера под Апачем "используются в промышленной разработке", или это так, чьи-то домашние странички.
Кроме этого, можно, к примеру, попытаться прикинуть, по какой причине очень небесплатный IIS занимает 2/3 от объемов абсолютно бесплатного апача. И после этого подумать — являются ли 40% рынка успехом для IIS или 60% — fail'ом для Апача.

Ну и совсем будет здорово подумать об успехе идеологии OpenSource. Правда, это рискованно — можно, к примеру, додуматься до того, что статистика использования Апача никакого отношения к "идеологии OpenSource" не имеет. Вот те 60%, которые там нарисованы — это что, "поредактированный" Apache? Нихрена, это тот самый blackbox, вытянутый из репозитория и запущенный в неизменном виде. Может быть, Apache как-то по функциям рвёт IIS? Нет, всё то же самое в IIS сделано куда как лучше. Может, он тогда супербыстрый? Опять нет — есть маленький nginx. То есть опять, весь передовой опенсорс вместо допиливания white box апача для перформанса, тупо ставит перед ним blackbox nginx-а и радуется.

Конечно, никакой фанат опенсорса в эту сторону думать не будет. Куда удобнее думать, что Синклер "не замечен в причастности" к альтернативным продуктам. Да-да, я ни Апача, ни nginx, ни lighttpd никогда в глаза не видел и в веб приложениях на PHP не разбираюсь. Тем более не стоит принимать во внимание моё мнение насчёт MS SQL и MySQL- я известный ламер в СУБД. И все мои так называемые мнения продиктованы исключительно "линией партии" (кстати, где к ней можно подключиться?).

E>Боюсь, мои познания в англиском не позволяют увидеть в цитате Кнута следующее: "С моей точки зрения весь использованный вами код должен быть вами модифицирован и это гораздо, гораздо лучше, чем черные ящики или инструменты, которые вы не можете трогать".

Я думаю, тебе стоит усовершенствовать свои познания. Потому что это гораздо ближе к тому, что написал Кнут, чем все передёргивания, приведённые тобой в топике ранее.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.09 18:45
Оценка: +4 :)
Здравствуйте, eao197, Вы писали:

E>Раз тов.Ikemefula пытается оценивать тов.Кнута, значит он сам считает себя авторитетом. Интересно на каком основании.


Не надо быть курицей, чтобы понимать толк в яичнице (с) Другой Авторитет (Марк Твен).

Что до текущей темы, то тут прослеживается явная попытка прикрыть свое слабо обоснованное мнение авторитетом большого дяди.
Учитывая, что большая часть людей всецело и бездумно доверяет авторитетам (см. здесь) — это очень "сильная" позиция.
Особо радует и то, что несогласные с мнением автора темы быстренько смешиваются с дерьмом путем зачисления в "моски тявкающие на слона".
Скажи тебе не стыдно поддерживать подобные методы ведения дискуссии?

E>Сдается мне, что TeX и METAFONT вовсе не рядовые проекты. Так что Кнут вполне себе практик, раз тот же самый TeX уже десятки лет успешно используется так, как есть.


Не расскажешь сколько человек работало над этими проектами?
А какие компоненты в нем были повторно использованы?
И главное как работа над этими проектами может обосновать неверность компонентного подхода и верность подхода основанного на правке кода в любых условиях?

За одно я с удовольствием послушал бы о том как соотносится твой SObjectizer (или как там его правильно?) и идея решать все проблемы правкой кода?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Кнут о компонентном программировании.
От: WolfHound  
Дата: 15.07.09 07:55
Оценка: +1 -2 :))
Здравствуйте, eao197, Вы писали:

E>

If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway

Перевожу с вежливого на понятный: Если ты упертый фанатик и веришь в такую чепуху как повторно используемый код то объяснять тебе что либо бесполезно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 17.07.09 11:34
Оценка: 44 (2) +2
Здравствуйте, Sinclair, Вы писали:

L>>Допустим, не пользуются этой возможостью 100%. От этого эта возможность никуда не исчезает и не перестаёт быть неотъемлемой частью OS. Без кавычек.

S>Допустим. На мой взгляд, возможность, которой не пользуется ровно никто, запросто можно отъять.

Отъять можно, но тогда это будет не OS и к данному треду никакого отношения иметь не будет.

Я вообще не понимаю, почему слова eao197 воспринимаются в штыки. Может я ошибаюсь, но он говорит ровно следующее: "Кнут говорит, что иметь код, который можно подправить, лучше чем иметь black box. Считаю, что к мнению Кнута стоит прислушаться".

Возможность подправить не значит постоянно править, и не пользовать компоненты. Хотя, конечно, подразумевает, что править всё таки будете.
Прислушаться не значит начать править всё кругом и забить на компоненты, а означает задуматься, почему Кнут так считает.

С первым ещё можно спорить, аргументы приводить разные. Пример аругмента: "нашим орлам только дай возможность что нибудь поправить, так их потом фиг остановишь.", ну или более основательные, о пользе компонентного подхода там.

Спорить же со вторым, мне кажется, это спорить с тем, что человеку стоит задумываться. Неужели не интересно почему Кнут так считает?
Re[36]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 07:12
Оценка: 7 (1) +3
Здравствуйте, eao197, Вы писали:
E>Ну просто для общего развития, что же тогда такое OpenSource?
OpenSource — это всего лишь свободная раздача доступа к исходникам. Часть идеологии OpenSource — в возможности "затачивать под себя", re-editable. К сожалению, эта техника has proven generally ineffective, что легко заметить невооруженным взглядом по небольшому количеству open source derived work по сравнению с open source dependent work.
Причины этого также нетрудно понять невооруженным мозгом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 10.07.09 09:27
Оценка: 3 (1) +3
Здравствуйте, thesz, Вы писали:

T>Проблема в поддержке инвариантов. Ты поправил повторно используемый код, ты уверен, что он правильно заработает во всех местах его использования?


Для решения этой проблемы существуют юнит-тесты.

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


Юнит-тесты все же надежнее и проще.
Хотя бы потому, что тебе не нужно запускать все тот список программ, что ты привел.

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


T>Стоимость исправления ошибки растёт с увеличением времени с момента её внесения. Это, вроде, медицинский факт, я не думаю, что ты будешь с этим спорить.


Не буду.

T>Собственно, "запрет" на изменения в повторно используемом коде как раз с этим и связан — нам не хочется исправлять ошибки в уже имеющемся коде.


Ну вот это, имхо, подход, которому не должно быть места в нормальной разработке.
Потму что ты фактически говоришь: "Я нашел баг, который проявляется в этом месте, он может проявиться еще в сотне других мест, но я не хочу их все проверять и фиксить, поэтому займусь индус-кодерством (т.е. copy/paste)."
Так можно делать только в случае срочных заплаток, с обязательной проверкой всего, иначе просто растет твой долг (technical debt), который рано или поздно придется выплачивать, не тебе, так твоим коллегам.
А если долго не выплачивать, то это просто приведет к банкротству (проект будет проще выкинуть целиком и написать заново, чем продолжать поддерживать).

T>Поэтому и такое количество округлений: лучше я внесу ошибку в свой собственный код и быстро поправлю, чем внесу исправление в чужой код. Последнее потребует от меня вылезти вне зоны моей ответственности.

T>Так что я понимаю тех разработчиков.

Этот подход был в свое время хорошо показан Райкиным: "К пуговицам претензии есть?"
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[14]: Кнут о компонентном программировании.
От: COFF  
Дата: 16.07.09 08:02
Оценка: 1 (1) +2 :)
Здравствуйте, eao197, Вы писали:

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


Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне" :)
Re[47]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 20.07.09 09:05
Оценка: 1 (1) :)))
Здравствуйте, IB, Вы писали:

L>>Нет, не вызывает.

IB>То есть, слепое поклонение авторитету думательную часть мозга отключает. ЧТД.

Настоящему мужчине всегда есть что возразить?
Re[5]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.07.09 17:54
Оценка: +1 -1 :))
Здравствуйте, Ikemefula, Вы писали:

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


VD>>>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>>>И это еще слабо сказано !


T>>Про тебя с Владом отлично написал в девятнадцатом веке Крылов: "Ай, моська..."


I>Покажи мне работы Кнута на тему "Искусство объектно ориентированого дизайна", "Искусство построения компонентов" и тд.


I>Валяй.


Комментарий вполне в стиле моськи, кстати. "Он не слон, поскольку не может так звонко тявкать, как это делаю я и моя стая."

Тьфу.

Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".

Я так думаю, что количество шаблонов проектирования не сильно превышает количество алгоритмов, названных его именем.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.09 17:38
Оценка: +4
Здравствуйте, eao197, Вы писали:

I>>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


E>А Вы? Написали?


А кто-то приводил его в качестве авторитета в этой области?

А вот thesz использовала Кнута как авторитета чтобы подтвердить свое мнение, что является голимой демагогией.

Кнут конечно человек известный, но как алгоритмист, а отнюдь не как архитектор ПО.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 07:58
Оценка: +2 -2
Здравствуйте, 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++.
Re[21]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 06:15
Оценка: 18 (1) +1 :)
Здравствуйте, Sinclair, Вы писали:

E>>Ну, если под компонентным программированием начинает пониматься использование библиотек уровня libc, то аргументы о том, что Кнут ничего не понимает в компонентах вообще идут лесом.

S>Таких аргументов в ветке не было. Были аргументы про то, что у Кнута недостаточно опыта промышленной разработки.

http://www.rsdn.ru/forum/philosophy/3464966.1.aspx
Автор: Ikemefula
Дата: 12.07.09

Покажи мне работы Кнута на тему "Искусство объектно ориентированого дизайна", "Искусство построения компонентов" и тд.

Где здесь упоминание промышленной разработки?

S>То есть не такой, когда один человек ваяет TeX десять лет, имея только общие представления о том, как и что должно быть, а такой разработки, где 100 человек делают TeX за 1 год, с предсказуемым результатом и обязанностью отчитываться о потраченных ресурсах и достигнутом прогрессе.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 04:39
Оценка: 2 (1) +2
Здравствуйте, EvilChild, Вы писали:
EC>А кого стоит слушать по этим вещам?
Хороший вопрос. Тут видишь ли какая штука — большинство народу, занятого именно коллективной разработкой больших вещей, достаточно хорошо скрыто от публики.
Те, кто на поверхности — тот же Фаулер — излагают достаточно искажённую точку зрения. Потому, что у enterprize проектов весьма специфические условия.

Поэтому, наверное, в таких вещах имеет смысл читать блоги тех, кто занимается схожей с вами деятельностью. При выпуске коробочных продуктов играют роль одни вещи, при разработке веб-сервисов — другие. Пишешь игру — важно третье.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 09:06
Оценка: 1 (1) +2
Здравствуйте, jazzer, Вы писали:

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


T>>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


T>>Пожалуй, подпишусь.


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


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


J>Имхо, reusable code и untouchable black box or toolkit — это немножко разные вещи.

J>В словосочетании "reusable code" ключевое слово — это слово "код", который, естественно, можно исправить, если в нем баг.
J>И если ты стараешься поддерживать его в reusable-состоянии (т.е. он _один_ зовется отовсюду) — в чем проблема?

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

Что самое интересное, вероятность правильной работы кода после исправлений растёт со временем. Компиляторы, дебаггеры, всякие валгринды с параллельными студиями интела... Вчера везде было проще использовать чёрный ящик, сегодня уже не в столь многих местах, а завтра вообще чёрных ящиков останется раз, два и обчёлся.

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


Стоимость исправления ошибки растёт с увеличением времени с момента её внесения. Это, вроде, медицинский факт, я не думаю, что ты будешь с этим спорить.

Собственно, "запрет" на изменения в повторно используемом коде как раз с этим и связан — нам не хочется исправлять ошибки в уже имеющемся коде.

Поэтому и такое количество округлений: лучше я внесу ошибку в свой собственный код и быстро поправлю, чем внесу исправление в чужой код. Последнее потребует от меня вылезти вне зоны моей ответственности.

Так что я понимаю тех разработчиков.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.09 17:04
Оценка: 1 (1) +2
Здравствуйте, eao197, Вы писали:


E>>>Раз тов.Ikemefula пытается оценивать тов.Кнута, значит он сам считает себя авторитетом. Интересно на каком основании.


VD>>Не надо быть курицей, чтобы понимать толк в яичнице (с) Другой Авторитет (Марк Твен).


E>Во-первых, странно разрушать веру в авторитеты цитированием авторитетов.


А я ее и не разрушаю. Это жувотный инстинкт который невозможно разрушить.
Я просто привел цитату которая отлично демонстрирует глупость и демагогичность твоих доводов. Я же не виноват в том, что Марк Твен первым так хорошо сформулировал эту мысль?

E>Во-вторых, мы же здесь не аичницу обсуждаем, а степень доверия к словам Кнута о повторном использовании.


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

E> Тем более, когда аргументация идет на уровне "он теоретик-алгоритмист из прошлого века, поэтому его словам грош цена". А судьи-то кто? Тут вот Ikemefula обвинил Кнута в том, что он не из индустрии. А ты сам-то из индустрии?


Судьи образованные люди знающие толк как в компонентном подходе, так и в правке кода, и при этом, заметь, не прикрывающиеся авторитемами и не боящиеся иметь свое мнение на некоторые темы, не совпадающее с мнением некоторых авторитетов (и мнящих себя таковыми).

В общем, твои нападки не только некорректны, но еще и смехотворны. Давай развернем ситуацию. Я приведу тебе какую-нибудь цитату более-менее известного человека, в которой тот будет поддерживать компонентный подход, ты будешь пытаться как-то парировать это, а я сидеть и подначивать, что мол "кто ты такой чтобы ..."? Ну, в общем, буду в вашем стиле проезжаться по вашим личностям. Давай?

VD>>Особо радует и то, что несогласные с мнением автора темы быстренько смешиваются с дерьмом путем зачисления в "моски тявкающие на слона".

VD>>Скажи тебе не стыдно поддерживать подобные методы ведения дискуссии?

E>А ты по адресу обращаешься?


Да, очень по адресу. Причем это не первый случай когда ты ведешь дисскуссию подобным образом или поддерживаешь тех кто так поступает. Похоже, что тебя просто прет от унижения окружающих и от применения некорректных методов ведения дискуссии.

E>>>Сдается мне, что TeX и METAFONT вовсе не рядовые проекты. Так что Кнут вполне себе практик, раз тот же самый TeX уже десятки лет успешно используется так, как есть.


VD>>Не расскажешь сколько человек работало над этими проектами?

VD>>А какие компоненты в нем были повторно использованы?
VD>>И главное как работа над этими проектами может обосновать неверность компонентного подхода и верность подхода основанного на правке кода в любых условиях?

E>Какие бы ни были условия разработки TeX и METAFONT в них Кнут мог сделать именно такие выводы.


Ну, и замечательно. Это его мнение. Только они ни стоят ни гроша, так как это очень частный опыт одного программиста одиночки работавшего над конкретной задачей. В его условиях возможно выгоды от компонентного подхода не было. Но кКогда программист начинает работать в команде или над большим проектом включающим множество типовых задач вроде создания GUI, то компонентный подход выходит на первую роль, а идея решить проблему путем правки чужого кода для решения частной задачи, становится не такой уж и хорошей.

E>Если кто-то из нынешних разработчиков (я или thesz) окажется в похожих условиях, может быть и он придет к таким же выводам.


Может быть. Но есть такое понятие как общность утверждения. Он сделал общее утверждение без оговорок о том, что оно применимо только для каких-то конкретных условий. В таком виде оно не верно. И лично я с ним не согласен (не смотря ни на какие авторитеты). Если бы он сказал — "В некоторых условиях лучше поправить код под свои нужды, а не искать готовое решение.", то я бы с ним согласился.

VD>>За одно я с удовольствием послушал бы о том как соотносится твой SObjectizer (или как там его правильно?) и идея решать все проблемы правкой кода?


E>В моих условиях, когда бОльшее количество кода пишется самостоятельно, rewriting оказывается дешевле reusing-а.


Если утверждение сделанное в теме верно, то не нужным становится сам твой SObjectizer так как всем проще будет не использовать его, а "поправить его код для своих нужд".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Кнут о компонентном программировании.
От: anton_t Россия  
Дата: 09.08.09 17:39
Оценка: 1 (1) :))
Здравствуйте, jazzer, Вы писали:

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


T>>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


T>>Пожалуй, подпишусь.


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


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


J>Имхо, reusable code и untouchable black box or toolkit — это немножко разные вещи.

J>В словосочетании "reusable code" ключевое слово — это слово "код", который, естественно, можно исправить, если в нем баг.
J>И если ты стараешься поддерживать его в reusable-состоянии (т.е. он _один_ зовется отовсюду) — в чем проблема?

J>А вот если под "re-editable code" понимается copy/paste с исправлениями под конкретную ситуацию, то я тебе сейчас расскажу, чем это заканчивается в реальных проектах (по собственному опыту).

J>Я имел удовольствие работать в одном огромном 10-летнем проекте.
J>В какой-то момент в одном месте обнаружились ошибки с округлением.
J>Когда я стал раскапывать ситуация с округлением, оказалось, что в проекте набралось 3-7 (не помню уже точно, сколько) функций округления, все, естественно, простые (что там может быть сложного в округлении), все явно сделанные из одной исходной функции (суда по именам локальных переменных) путем применения подхода "re-editable code". Разница была лишь в обработке всяких граничных случаев. Так как все это умножается на принцип "работает — не трогай" (софт ворочает миллионами долларов), я думаю, сейчас количество этих функций там уже подбирается к 10. И отследить, где какое округление в результате используется — это дело нескольких дней.
J>А вот если бы с самого начала был _один_ reusable компонент/класс/что-угодно "округлятель" и не разрешалось бы плодить его "легко исправляемые копии", то этого геморроя не было бы.

По поводу этих функций вспомнинаются слова:

Один плохой программист может создавать до двух рабочих мест в год.

Re[2]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 08:51
Оценка: +1 -2
Здравствуйте, StevenIvanov, Вы писали:

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


SI>на мой взгляд это вообще очевидная истина — написать идеальный интерфейс не получится, хоть сколько-нибудь сложная абстракция наверняка окажется "дырявой". Так что рано или поздно все написанное приходится фиксить, конечно при условии востребованности написанного...


Более того, современные практики и инструменты упрощают это дело всё больше и больше. Поэтому вероятность справится с улучшением за определённый срок всё время растёт, а вероятность найти подходящий компонент в тот же срок падает: растёт количество узко-специализированных компонент, которые тяжело использовать в общем случае.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.07.09 12:18
Оценка: +1 -2
Здравствуйте, Ikemefula, Вы писали:

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



VD>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>И это еще слабо сказано !


Про тебя с Владом отлично написал в девятнадцатом веке Крылов: "Ай, моська..."
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 14:29
Оценка: :)))
Здравствуйте, Ikemefula, Вы писали:

E>> И Кнут с Виртом для них теоритики из прошлого века, над которыми практики могут позволить себе посмеяться.


I>Кнут и Вирт это уже минимум позапрошлое поколение. ИТ-развивается слишком быстро.


Раньше я боялся, что монстры типа thesz со временем оставят меня без работы. Теперь я думаю, что мои опасения напрасны.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: untouchable игнорируется?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.07.09 09:12
Оценка: +1 -2
Здравствуйте, Sinclair, Вы писали:

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

E>>Еще мне кажется, что в высказывании Кнута совершенно игнорируется прилагательное untouchable. Так же как и "black box":
E>>

E>>much better than an untouchable black box or toolkit

S>А мне кажется, что перевод Кнута на уровне отдельных прилагательных — полная бессмыслица. Ты бы еще отдельные буквы там пообсуждал. Ты почитай текст вокруг — там же всё понятно. Он вообще пишет про ограниченную применимость общепринятых принципов.

Я читаю и вижу:

To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.

Тогда как другие, вероятно, видят:

To me, "re-editable code" is much, much better than an reusable toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


Пожалуй, на этом можно закончить.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 07:29
Оценка: +3
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 11.07.09 00:28
Оценка: 1 (1) +1
Здравствуйте, thesz, Вы писали:

T>>>Но он не будет проверять другие граничные условия, для других вариантов использования.

J>>Да.
J>>Может, их и нету, других граничных случаев.
J>>Это называется "решать проблемы по мере их появления".
J>>Ты, кстати, точно так же можешь забыть выразить граничные случаи в зависимых типах.

T>Не получится. По рукам дадут.


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

T>>>Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.

J>>Если ты внес в язык зависимые типы, которых там раньше не было, то это уже другой язык.

T>Расширение предыдущего.

Это обычно и означает — новый язык.

J>>Вот-вот: эдесь ты только что из С сделал С++.


T>Или просто использовал шаблоны.


В С нет шаблонов.
Так что это таки С -> С++.



T>>>>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>>>>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.
T>>>Нормально.
T>>>Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.
J>>Сокращают какой код?
J>>Код определения типа — могут только усложнить.

T>И насколько, как ты думаешь?

Что значит — насколько? В чем мерять?
Думаю, это от языка зависит. В том, который под зависимые типы заточен — в том мало будет дополнительной писанины, а в том, который не заточен — это либо очень многословно, либо вообще нереализуемо.

J>>В противовес этому, возможно, помрут какие-то юнит-тесты.

J>>Я говорю "возможно", потому что то, как ты запрограммировал свои зависимые типы, тоже неплохо бы проверить, а то вдруг ты где-то минус с плюсом перепутал, как указывали в соседней дискуссии.

T>Минус-плюс я могу в параметр внести, видно будет.

Ну вот о чем и речь, что придется весь текст функции засунуть в тип.
После чего у тебя сложность типа будет сравнима со сложностью кода функции, и если код сильно кучерявый, то и тип будет такой же.
И этот тип придется тестировать так же, как ты тестировал бы функцию без этого типа.

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


T>Правильно, функциональным тестом. Не юнит-тестом, в последнем смысла нет.

И каждый раз функциональный тест руками проделывать? А ты точно не забудешь проверить все граничные случаи, что ты их правильно запрограммировал? Их же все, по-хорошему, надо проверить. Это и есть юнит-тесты.

T>>>Спецификация не может быть длинней кода. Тем более она не может быть длинней тестов этого кода.

J>>Спецификация на человеческом языке вполне может быть короче кода, выражающего эту спецификацию на машинном языке.
J>>Просто потому что спецификация на человеческом языке опирается на весь контекст, доступный человеку, а для машины тебе придется весь этот контекст воспроизвести руками.

T>Спецификация на машинном языке — на той же Агде или на ACL2, — опирается на всю мощь библиотеки машинного языка, которую не надо воспроизводить руками.


Можешь развернуть этот тезис?

T>>>Почему-то любая дискуссия со мной выливается в "юинт-тесты супротив статической типизации".

J>>Ну потому что ты ратуешь за то, чтоб вообще все загнать в статику.

T>Потому, что когда человек пишет программу, он рассуждает о программе статически, и никак иначе.


Можешь развернуть и этот тезис?

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


T>Видишь ли, в типы нельзя загнать, я думаю, только красоту души девушки. Всё остальное типизируется.

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

J>>Я сам большой поклонник статики и все, что можно, стараюсь сделать ошибкой времени компиляции.

J>>Только вот потом тебе нужно все равно написать тест, который скомпилирует то, что правильно, и не скомпилирует то, что неправильно — иначе как ты узнаешь, что ты реализовал статику без ошибок?

T>Нет, мне не надо писать такой тест. Если я правильно написал основные типы, то мои операции будут ими правильно ограничены, я не смогу сделать лишнего и смогу сделать нужное.


Вот для проверки утверждения "Если я правильно написал" тесты и нужны, и никуда ты не денешься от них.
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]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.09 17:45
Оценка: 1 (1) :)
Здравствуйте, eao197, Вы писали:

E>Уж лучше демонстрировать подобие остроумия, чем подобие авторитетности...


Ну, и что же ты этого не делаешь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Кнут о компонентном программировании.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.07.09 15:26
Оценка: +1 :)
T>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.

нарушает принцип программирования:

26. c) Open for extension, closed for modification

http://blog.metatech.ru/post/ogni-razrabotki.aspx
Re[2]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 08:48
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

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


T>>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


T>>Пожалуй, подпишусь.


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


VD>Искать компонент на любой случай жизни — это идиотизм. Искать компонент для решения конкретной задачи — это нормально и очень правильно во многих ситуациях.


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

"Искать" и "найти" — разные вещи. Искать можно всегда, вероятность найти — низка.

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

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

Что ещё. Поскольку писать всё проще и проще, смысл имеет писать только очень сложные вещи, которые тяжело воспроизвести. А они, в общем, гораздо уже по области применения, чем простые.

Все остальные твои соображения я опущу. Они к делу не относятся. Только приведу подходящую цитату с с bash.org (без .ru):

&lt;Donut[AFK]&gt; HEY EURAKARTE<br />
&lt;Donut[AFK]&gt; INSULT<br />
&lt;Eurakarte&gt; RETORT<br />
&lt;Donut[AFK]&gt; COUNTER-RETORT<br />
&lt;Eurakarte&gt; QUESTIONING OF SEXUAL PREFERENCE<br />
&lt;Donut[AFK]&gt; SUGGESTION TO SHUT THE FUCK UP<br />
&lt;Eurakarte&gt; NOTATION THAT YOU CREATE A VACUUM<br />
&lt;Donut[AFK]&gt; RIPOSTE<br />
&lt;Donut[AFK]&gt; ADDON RIPOSTE<br />
&lt;Eurakarte&gt; COUNTER-RIPOSTE<br />
&lt;Donut[AFK]&gt; COUNTER-COUNTER RIPOSTE<br />
&lt;Eurakarte&gt; NONSENSICAL STATEMENT INVOLVING PLANKTON<br />
&lt;Miles_Prower&gt; RESPONSE TO RANDOM STATEMENT AND THREAT TO BAN OPPOSING SIDES<br />
&lt;Eurakarte&gt; WORDS OF PRAISE FOR FISHFOOD<br />
&lt;Miles_Prower&gt; ACKNOWLEDGEMENT AND ACCEPTENCE OF TERMS

Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.07.09 20:29
Оценка: +1 -1
Здравствуйте, Ikemefula, Вы писали:

T>>Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".


I>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


А Вы? Написали?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 14:04
Оценка: -2
Здравствуйте, Ikemefula, Вы писали:

E>>В этом признании больше всего сомнений вызывает слово "думаю".


I>Я не знал что думать это исключительно твоя привилегия. Извини, больше не буду.


Больше не будете думать? А что уже когда-то пробовали?

E>>Индустрия производства ПО, по мнению некоторых участников RSDN, находится в глубокой заднице.


I>Да, в заднце. Кнутов единицы, а нужны сотни тысяч. Всякие умные люди вроде тебя флудят на форуме вместо того что бы решить эту проблему.


Даже если все умные люди бросят флудить и займутся решением этой проблемы, то я все равно сомневаюсь, что нам под силу будет зачать хотя бы сотню тысяч будущих Кнутов.

I>Валяй, ищи реализацию, идею я тебе дарю.


В ваших потугах на остроумие еще и идея какая-то содержалась?



В обучении программистов есть один (среди прочих) очень неприятный момент: каждый сам себе гений и нет никакого уважения к авторитетам. Отчасти это оправдывается тем, что даже очень юные программисты с минимумом опыта могут писать программы гораздо лучше посредственностей с 20-ти летним стажем. Но фокус в том, что таких уникальных личностей не так уж много, это большое везение -- встретить такого таланта. В обычное же время на попытку объяснить, почему делать так-то и так-то не следует, приходится получать "железобетонные контрагрументы" вида: "Но ведь и так работает!?" И Кнут с Виртом для них теоритики из прошлого века, над которыми практики могут позволить себе посмеяться. Ну в баню попытки сделать из подобных товарищей программистов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 14:18
Оценка: +1 -1
Здравствуйте, eao197, Вы писали:

E>>>Индустрия производства ПО, по мнению некоторых участников RSDN, находится в глубокой заднице.


I>>Да, в заднце. Кнутов единицы, а нужны сотни тысяч. Всякие умные люди вроде тебя флудят на форуме вместо того что бы решить эту проблему.


E>Даже если все умные люди бросят флудить и займутся решением этой проблемы, то я все равно сомневаюсь, что нам под силу будет зачать хотя бы сотню тысяч будущих Кнутов.


I>>Валяй, ищи реализацию, идею я тебе дарю.


E>В ваших потугах на остроумие еще и идея какая-то содержалась?


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

E>В обучении программистов есть один (среди прочих) очень неприятный момент: каждый сам себе гений и нет никакого уважения к авторитетам.


На счет гения сильно не уверен, но уважения к авторитетам уменя было сильно мало и в школе.

E> И Кнут с Виртом для них теоритики из прошлого века, над которыми практики могут позволить себе посмеяться.


Кнут и Вирт это уже минимум позапрошлое поколение. ИТ-развивается слишком быстро.
Re[10]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 18:18
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

VD>>Кнут конечно человек известный, но как алгоритмист, а отнюдь не как архитектор ПО.


E>Сдается мне, что TeX и METAFONT вовсе не рядовые проекты. Так что Кнут вполне себе практик, раз тот же самый TeX уже десятки лет успешно используется так, как есть.


И в дополнение. Вот Кнут предлагает деньги за каждый найденный в TeX баг (согласно Wikipedia):

Donald Knuth offers monetary awards to people who find and report a bug in TeX. The award per bug started at $2.56 (one "hexadecimal dollar") and doubled every year until it was frozen at its current value of $327.68. Knuth, however, has lost relatively little money as there have been very few bugs claimed.

Много ли здесь найдется программистов-практиков, которые отважились бы на такие условия для своих собственных творений? Я, например, не решусь.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 08:17
Оценка: +1 :)
Здравствуйте, Lloyd, Вы писали:

E>>И раз уж мои познания в англиском так плохи, может подскажешь, является ли re-editable синонимом rewritten или modified?


L>re-editable == то, что можно отредактировать

L>rewritten == переписано
L>modified = изменено

Я уже в этом начал сомневаться.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[44]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 10:17
Оценка: +2
Здравствуйте, eao197, Вы писали:

E>Я указал, какой смысл я вкладываю в эти слова.

Но не то что требовалось.

E> Применимость должна определяться по месту. Т.е., сначала нужно решить, заслуживают ли доверия слова Кнута, а потом уже посмотреть, можно ли его подход применить в своих условиях.

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

E>Я его словам доверяю и его подход к предпочтению re-editable перед black box-ами в моих условиях применим.

А в условиях разработки реально востребованного софта в реальных командах — нет.

E>PS. Ну все, теперь я точно знаю, что Fortune 1000 -- это и есть весь бизнес, остальное не в счет.

Ну вот примерно так же ты и кнута извращаешь.. Не весь, а вполне репрезентативная выборка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[15]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 11:05
Оценка: +2
Здравствуйте, 4058, Вы писали:

4>А в каких условиях он работал? Были у него четкие сроки, или коллектив состоящий из разнокаллиберных умельцев?


В каких условиях работал Стив Возняк над Apple II?
В каких условиях разработчики PayPal делали свои первые версии для Palm-а?
В каких условиях разработчики Hotmail начинали свой почтовый сервис?

Четкие сроки и разнокалиберные команды -- это, блин, далеко не весь коммерческий софт. И далеко не весь успешный коммерческий софт.

4>Ну есть заявление, что КОП это плохо, и далее обращение к читателю, что если Вы это не признаете, значит еще "не доросли".


Давайте я переведу высказывание Кнута так, как я понимаю его. А дальше ваше дело, соглашаться или нет:

Так же я должен признаться в сильном предубеждении против моды на переиспользуемый код. Для меня код, который можно отредактировать, гораздо, гораздо лучше, чем черный яшик или инструмент, к которому нельзя прикасаться. Я мог бы говорить и говорить об этом. Если вы полностью убеждены, что повторно используемый код -- это прекрасно, то я, вероятно, не смогу поколебать вас, но и вы не сможете убедить меня, что повторно используемый код не является, по большей мере, угрозой.


Исходя из своего опыта я придерживаюсь следующих предпочтений:
— использовать готовый код лучше, чем писать самому;
— использовать сторонний компонент с доступным исходным кодом лучше, чем с закрытым (тот самый untouchable black box);
— использовать сторонний компонент с лицензией, которая допускает его модификацию лучше, чем компонент с исходным кодом, но с более жесткой лицензией.

Все это, на мой взгляд, согласуется со словами Кнута. И на мой взгляд, при использовании untouchable black box _всегда_ есть угроза того, что проблемы с ним возникнут, а вы ничего не сможете с этим поделать. И попробуйте убедить меня в обратном
Такая же угроза есть и при использовании OpenSource компонентов, но там хотя бы надежда есть благодоря тому, что код re-editable. Не говоря уже про то, что получив в свое распоряжение re-editable код, можно взяв его за основу, разработать собственный компонент, гораздо лучше исходного и получить с этого различные бенефиты.

И хоть убей не могу понять, где в словах Кнута есть призыв все переписывать под себя.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[23]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 14:54
Оценка: +2
Здравствуйте, 4058, Вы писали:

E>>А время и современные условия давят на всех -- и сроки снижаются, и стоимость заказов временами, и требования все время повышаются. Но, если под коммерческой разработкой понимается выпуск ПО в оффшоре по спецификациям заказчика, то я не могу ничего на эту тему сказать.


4>Разговор шел про Кнута, и на тему можно ли слепо доверять его выводам,

4>или же стоит основываться на собственном опыте и соответсвующих выводах из него.

Я не знаю, кто здесь что видит, я вступил в эту тему после того, как увидел утверждение о том, что ко мнению Кнута нужно "очень осторожно прислушиваться" и "это еще мягко сказано" (т.е. Кнута не нужно вообще слушать), поскольку он "теоретик-алгоритмист из прошлого века". И обоснованием этого утверждение было то, что Кнут не написал книг ни по ООП, ни по КОП. Да и вы сами сомневаетесь в том, достаточно ли Кнут попрограммировал, чтобы его вообще слушать.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: Кнут о компонентном программировании.
От: WFrag США  
Дата: 03.08.09 07:49
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

WF>>Да? А на мой взгляд, этим как минимум каждый дистрибутив занимается.


S>Да неужели? И какие дистрибутивы распространяют, к примеру, апач или мускул, существенно отличные от стандартной версии?


А откуда внезапно взялось требование «существенно»?

Речь о том, что у них есть возможность взять исходники, заточить под себя и выпустить продукт. Меняют они исходники существенно или нет — не важно. Важно то, что они это делают. А ты вдруг говоришь, что «эта техника has proven generally ineffective», в то время как половина смысла существования дистрибутивов Linux-а именно в этом затачивании под себя
Re[28]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.08.09 03:22
Оценка: +1 :)
Здравствуйте, master_of_shadows, Вы писали:
__>Если ваша команда не может починить багу в 3rd party, то чем тут поможет black box? Один фиг результат тот же — апликация не работает с тем-то и тем-то.
__>В случае с закрытым продуктом будет всё то же самое, но без пунктов а-б. Где разница то ?
Ну, в случае с коммерческим продуктом по крайней мере есть кто-то, кто отвечает за саппорт.
Впрочем, это неважно — фишка как раз в том, что разницы нет. Об ээтом я и говорю — для большинства потребителей Open Source возможность reedit-а исходников совершенно абстрактна. Поэтому считать её "неотъемлемой основой" я не хочу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: Кнут о компонентном программировании.
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 10.08.09 05:31
Оценка: +1 -1
Sinclair,

E>>Думаю, что опыт Кнута уже давно оказался восстребованным (хотя под соусом опыта Торвальдса) -- сейчас он активно используется в виде "спонсирования OpenSource разработок".

S>Я уже намекал на то, что OpenSource != "re-editable code".
S>OpenSource использует untouchable blackbox в полный рост.
S>Мне также непонятно, каким образом опыт Кнута приравнивается к "спонсированию". Он что, дал кому-то денег на прикручивание прямого рендера в PDF минуя DVI?

S>Я предлагаю прекратить измываться над этим интервью — ваши натяжки разных частей текста на выпуклые места уже утомили.


Я приведу маленький пример из своей практики. Rake — библиотека для автоматизации сборки, фактически EDSL на Ruby, который реализует make-like функционал. Для дотнета существует специальный джем, "rake-dotnet", который вдобавок реализует специфичные для дотнета вещи — вызов msbuild, генерация AssemblyInfo и прочее. Также, там реализован таск :help, однако попытка вызвать его для текущей версии (0.1.9) приводит к ошибке:
C:\workspace\dotnet\mycoolproject>rake help
(in C:/workspace/dotnet/mycoolproject)
rake aborted!
No such file or directory - rake.cmd -T

идём туда (в джем rake-dotnet-0.1.9) и видим строку
taskHash = Hash[*(`rake.cmd -T`.split(/\n/)....

меняем rake.cmd на просто rake — и вуаля!

Так что возможность запустить ручки в модуль (или другими словами во фреймворк, библиотеку, инструмент или просто компонент) является большим благом и позволяет использовать хорошую вещь (включая например тот же Немерле) в риал-лайф проекте, не дожидаясь, пока Большие-и-Влиятельные-Корпорации не возьмут эту вещь на буксир.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[3]: Кнут о компонентном программировании.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.07.09 16:06
Оценка: +1
T>И сразу же завершу: я говорил не о непреклонном принципе разработки, а о достижимости некоторой ситуации.

проведу аналогию с законами, который пишутся людьми для людей.

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

а кода много больше, он намного менее понятен людям, более закрытый (более оторванный от жизни людей) — соответственно задача еще менее реальная.

проблема в том, что при модификации чего-либо надо много чего держать в голове одновременно (причем счет может идти на миллиарды ситуаций), а человеческий мозг имеет довольно серьезные ограничения по количеству одновременно оперируемых понятий.
Re: Кнут о компонентном программировании.
От: StevenIvanov США  
Дата: 09.07.09 21:37
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


T>Пожалуй, подпишусь.


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


так же подпишусь.
мне несколько раз приходилось править ошибки/добавлять незначительный функционал в open source программы, которыми я пользуюсь.
если бы эти программы использовали закрытые компоненты или вовсе были закрыты, то не уверен, что мне бы это удалось

на мой взгляд это вообще очевидная истина — написать идеальный интерфейс не получится, хоть сколько-нибудь сложная абстракция наверняка окажется "дырявой". Так что рано или поздно все написанное приходится фиксить, конечно при условии востребованности написанного...
Re: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 10.07.09 00:12
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


T>Пожалуй, подпишусь.


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


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

Имхо, reusable code и untouchable black box or toolkit — это немножко разные вещи.
В словосочетании "reusable code" ключевое слово — это слово "код", который, естественно, можно исправить, если в нем баг.
И если ты стараешься поддерживать его в reusable-состоянии (т.е. он _один_ зовется отовсюду) — в чем проблема?

А вот если под "re-editable code" понимается copy/paste с исправлениями под конкретную ситуацию, то я тебе сейчас расскажу, чем это заканчивается в реальных проектах (по собственному опыту).
Я имел удовольствие работать в одном огромном 10-летнем проекте.
В какой-то момент в одном месте обнаружились ошибки с округлением.
Когда я стал раскапывать ситуация с округлением, оказалось, что в проекте набралось 3-7 (не помню уже точно, сколько) функций округления, все, естественно, простые (что там может быть сложного в округлении), все явно сделанные из одной исходной функции (суда по именам локальных переменных) путем применения подхода "re-editable code". Разница была лишь в обработке всяких граничных случаев. Так как все это умножается на принцип "работает — не трогай" (софт ворочает миллионами долларов), я думаю, сейчас количество этих функций там уже подбирается к 10. И отследить, где какое округление в результате используется — это дело нескольких дней.
А вот если бы с самого начала был _один_ reusable компонент/класс/что-угодно "округлятель" и не разрешалось бы плодить его "легко исправляемые копии", то этого геморроя не было бы.
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]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 19:48
Оценка: :)
Здравствуйте, thesz, Вы писали:

T>Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".


Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.
Re[10]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 13.07.09 07:10
Оценка: +1
Здравствуйте, Erop, Вы писали:

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


T>>Видишь ли, в типы нельзя загнать, я думаю, только красоту души девушки. Всё остальное типизируется.


E>IMHO, это не правда.

E>Скажем представь себе, что ты игрока в шахматы пишешь. Типизируй, например, требование "играет не хуже первого взрослого разряда".
E>Или, ещё хитрее: "скорее всего выиграет у последней доступной версии программы-конкурента"...

Да зачем так сложно...
Можно просто "время работы этой функции должно быть меньше 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[9]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 13.07.09 10:38
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:


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


T>>Published his groundbreaking paper "An empirical study of FORTRAN programs." ( Software---Practice and Experience, vol 1, pages 105-133, 1971) which laid the cornerstone of an empirical study of programming languages.


I>И что ?


Я не буду переводить.

T>>ОО языки программирования всё равно остаются языками программирования.


I>А прикинь, даже если не ОО, то все равно остаются языками программирования.


Именно поэтому труд Кнута стоит в основании и ООП, и не ООП.

Поэтому нападки в стиле "он не написал про компоненты" являются обычным тявканьем.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 11:26
Оценка: +1
Здравствуйте, eao197, Вы писали:

I>>Да, да, я решил проста так посмеяться, представь, вижу Влад про Кнута пишет, дай, думаю, посмеюсь.


E>В этом признании больше всего сомнений вызывает слово "думаю".


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

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


E>Индустрия производства ПО, по мнению некоторых участников RSDN, находится в глубокой заднице.


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

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


Практики частенько посмеиваются над теоретиками и наоборот. Для него его подход не является нелепым. А для других нужно стать таким же Кнутом.

Валяй, ищи реализацию, идею я тебе дарю.
Re[6]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.09 17:32
Оценка: -1
Здравствуйте, thesz, Вы писали:

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


Кстати, сколько ты знаешь алгоритмов названных его именем?

Хоор наверно тоже силен в вопросах компонентного проектирования и повторного использования кода на том основании, что изобрел алгоритм быстрой сортировки...

Нет, ты не моська, ты демогог.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 18:12
Оценка: +1
Здравствуйте, VladD2, Вы писали:

I>>>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


E>>А Вы? Написали?


VD>А кто-то приводил его в качестве авторитета в этой области?


Раз тов.Ikemefula пытается оценивать тов.Кнута, значит он сам считает себя авторитетом. Интересно на каком основании.

И кто сказал, что повторное использование компонентов -- это исключительно прерогатива ООП? Модули и компоненты активно развивались еще во времена процедурного и структурного программирования (см.например Modula-2 и Ada83).

VD>Кнут конечно человек известный, но как алгоритмист, а отнюдь не как архитектор ПО.


Сдается мне, что TeX и METAFONT вовсе не рядовые проекты. Так что Кнут вполне себе практик, раз тот же самый TeX уже десятки лет успешно используется так, как есть.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 19:14
Оценка: +1
Здравствуйте, eao197, Вы писали:

I>>>>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


E>>>А Вы? Написали?


VD>>А кто-то приводил его в качестве авторитета в этой области?


E>Раз тов.Ikemefula пытается оценивать тов.Кнута, значит он сам считает себя авторитетом. Интересно на каком основании.


Это твои домыслы. У меня никаких претензий к Кнуту нет, как к математику-алгоритмисту-теоретику. Как программисту-одиночке — тоже.

А вот слушать его советы по ООД , компонентным технологиям я вряд ли стану, просто потому что есть более серьезные вещи, а у Кнута этого раз два и обчелся.

E>И кто сказал, что повторное использование компонентов -- это исключительно прерогатива ООП? Модули и компоненты активно развивались еще во времена процедурного и структурного программирования (см.например Modula-2 и Ada83).


Да, само собой, только Кнут говорит об этом со своей колокольни — как программист-одиночка. Это не значит, что он плохо писал, это значи, что его опыт нельзя применить в индустрии, потому что понадобятся сотни тысяч таких же кнутов.

VD>>Кнут конечно человек известный, но как алгоритмист, а отнюдь не как архитектор ПО.


E>Сдается мне, что TeX и METAFONT вовсе не рядовые проекты. Так что Кнут вполне себе практик, раз тот же самый TeX уже десятки лет успешно используется так, как есть.


Программист-одиночка. В индустрии-ПО это меньше чем стат. погрешность.
Re[11]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 19:37
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Да, само собой, только Кнут говорит об этом со своей колокольни — как программист-одиночка. Это не значит, что он плохо писал, это значи, что его опыт нельзя применить в индустрии, потому что понадобятся сотни тысяч таких же кнутов.

I>Программист-одиночка. В индустрии-ПО это меньше чем стат. погрешность.

Вы с VladD2 будете сильно удивлены, узнав, как много в индустрии было сделано одиночками и очень маленькими коллективами. Например, с чего начилался Google, PayPal, Apple, Borland...


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Кнут о компонентном программировании.
От: EvilChild Ниоткуда  
Дата: 14.07.09 04:50
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Давай сначала


I>

I>>А вот слушать его советы по ООД , компонентным технологиям я вряд ли стану, просто потому что есть более серьезные вещи, а у Кнута этого раз два и обчелся.

I>А кого стоит слушать по этим вещам


I>Ты ответ на свой вопрос получил или по приведенной ссылке ты только рефакторинг увидел ?


Получил, Кнута тебе больше показывать не надо?
now playing: Oliver Koletzki — Nascita Of The Monsters (Martin Patino Remix)
Re[13]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.07.09 18:39
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>>>Мне не надо быть авторитетом в гинекологии, чтобы понять, что лично твои мысли в области генеалогии ни стоят ни гроша. Для этого мне достаточно знать, что ты ею никогда не занимался.


E>>Вот и отлично. Как только я начну утверждать, что чье-то мнение в области гинекологии или генеалогии не стоят ни гроша, тогда ты с полным правом можешь выяснять степень моей квалификации в данных областях и поднимать меня на смех.


VD>Алё! Меня не слышат? Я утверждаю, что твое мнение в гениклогии ни стоит ни гроша?


Да.

VD>Я не прав?


Прав

VD>Я не могу это утверждать?


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

VD>То что там говорит Кнут мне совершенно все равно. Я обсуждаю текущую тему.


А какова текущая тема? Для Кнута re-editable предпочтительнее, чем reuse? Или, что вы с Ikemefule знаете о компонентном программировании больше Кнута? Судя по заглавию темы -- как раз первое, что для Кнута предпочтительнее re-editable подход.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.07.09 08:04
Оценка: +1
Здравствуйте, eao197, Вы писали:
E>"Для меня" или "с моей точки зрения", но он явно оговаривает, что у читателя может быть совершенно другой взгляд на вещи, который Кнут вряд ли сможет поколебать:
E>

If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway

Ты совершенно напрасно пытаешься вложить свои слова в уста Кнута. Если бы Кнут хотел сказать "моя точка зрения может быть неприменима в вашей ситуации", то он так бы и сказал. А так он всего лишь говорит о том, что "вас вряд ли удастся переубедить". К тому же дальше он на одном дыхании говорит "but you’ll never convince me that reusable code isn’t mostly a menace." Безо всяких оговорок типа "в некоторых частных случаях", и т.п.
Так что прекрати эти передёргивания.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: untouchable игнорируется?
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.07.09 08:23
Оценка: +1
Здравствуйте, eao197, Вы писали:
E>Еще мне кажется, что в высказывании Кнута совершенно игнорируется прилагательное untouchable. Так же как и "black box":
E>

E>much better than an untouchable black box or toolkit

А мне кажется, что перевод Кнута на уровне отдельных прилагательных — полная бессмыслица. Ты бы еще отдельные буквы там пообсуждал. Ты почитай текст вокруг — там же всё понятно. Он вообще пишет про ограниченную применимость общепринятых принципов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 06:45
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

E>>Почему-то при этом Кнут отваживается платить за найденные ошибки в своих программах, а промышленные производители ПО -- нет.

S>Кому здесь непонятны причины таких различий в подходах?

Мне, например.

E>>Но представители той самой промышленности с иронией насмехаются над подходами к программированию у Кнута.

E>> Надо полагать, на основании того, что умело отчитываются о потраченных ресурсах и достигнутом результате.
S>Надо полагать, на основании того, что в их деятельности Кнутовский подход неприменим.

Хорошо, если не применим. Но есть у меня подозрение, что он даже не рассматривался. Поскольку "Кнут -- теоритик-алгоритмист из прошлого века".


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Кнут о компонентном программировании.
От: Tesh США  
Дата: 16.07.09 07:00
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


T>Пожалуй, подпишусь.


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


Нужно уметь распределять обязанности, некоторые вещи лучше доверить группе сторонних разработчиков, которые будут развивать свои компоненты, исправлять баги, которые будешь находить не только ты, но и другие их клиенты.
А вносить исправления в достаточно большие проекты — может быть чревато тем, что исправишь в одном месте, и возникнут проблемы в другом.
По поводу допиливания чего-то под себя: можно использовать грамотно спроектированные компоненты, которые не требуют наличия исходного кода для своей кастомизации. Бывает так, что когда люди по-умолчанию поставляют исходный код, то часто на эту тему и не заморачиваются — код же есть, допиливайте, соответственно появляются люди, которые приспосабливаются к такому подходу и не представляют других вариантов) а потом имеют головняки из-за того что вышла новая версия и теперь все надо как-то обновить
Re[16]: Кнут о компонентном программировании.
От: COFF  
Дата: 16.07.09 09:00
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

COF>>Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне" :)

S>Ну, только не ему в ответ, а адресуясь к работникам сети Подорожник, и комментируя вопросы приготовления обеда суммарной стоимостью менее 700 евро.

Это я к тому, что оба на самом деле деле по своему правы. Вопрос в том, что нас больше интересует — приготовление вкусного омлета или стремление накормить как можно больше народа как можно дешевле. Поэтому, тут я с eao197 полностью согласен, нельзя откидывать в сторону мнение Кнута только потому, что он "на фабрике-кухне не работал". По моему мнению, да и опыту тоже, компоненты типа "черный ящик" плохи либо тем, что они перегружены функциональностью, либо их невозможно использовать так как именно нужной функциональности там нет. Естественно, речь не идет о небольших библиотечных функциях и классах, да и с ними проблемы бывают.
Re[27]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 09:18
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

E>>Вот именно об этом я и говорил. Человек умудряется писать хороший софт, а его опыт априори отбрасывается только потому, что он работал в других условиях. Специалисты, мать, мать, мать.

S>Да, специалисты. Домашнее задание: выяснить, сколько времени потребовала разработка TeX до первого релиза. Прикинуть, есть ли шанс при жизни поучаствовать в коммерческом проекте с таким timeframe. Умножить этот шанс на полезность подхода.

Согласно Wikipedia, разработка первой версии TeX-а началась в 1978-м для PDP-10 на языке SAIL. По ходу дела Кнут разработал язык WEB и транслятор из него в Pascal для PDP-10.
Вторая, полностью переписанная версия TeX82 появилась в 1982-м.
Третья версия, TeX 3 -- в 1989-м. И вскоре после выхода версия 3 была заморожена для дальнейшего развития, в нее принимаются только багфиксы.

Т.о. двенадцать человеко-лет для трех мажорных версий неслабого пакета. Думаю, многие коммерческие проекты хотели бы иметь похожие темпы развития при столь высоком же качестве.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 09:47
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Т.о. двенадцать человеко-лет для трех мажорных версий неслабого пакета. Думаю, многие коммерческие проекты хотели бы иметь похожие темпы развития при столь высоком же качестве.

Я уже не знаю, как бы так потактиченее объяснить, что здесь важны не человеко-годы, а просто годы.
Где ты найдешь коммерческий проект, в котором тебе дадут страдать фигнёй 12 лет, зато потом будет найдено не более дюжины ошибок?
Спроси теперь Великого Кнута — "как разработать TeX 3.14 за один год"? Хватит ли тебе команды из 12 человек? Придется ли делить код на "чёрные ящики", или можно будет остаться в рамках re-editable code?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 16.07.09 10:32
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>На вскидку сейчас вспоминается PalmOS 6.0 на разработку которой, т.е. на фигню в чистом виде, было потрачено несколько лет, но потом все было выброшено коту под хвост. Да и путь от Windows 1.0 к Windows NT 3.51/Windows95 был очень неспешным.

Ты как-то очень ловко TeX с OS сравниваешь, это продукты по сложности не сопоставимые, так что не надо передергивать.

E>Не говоря уже о том, почему слова Кнута воспринимаются как призыв к глобальному code rewrite.

Вот это хороший вопрос. Потому что складывается впечатление, что адвокаты кнута настаивают именно на такой трактовке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[34]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 16.07.09 13:40
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Обоснуешь?

По сложности TeX сопоставим с относительно простой системой лэйаута, которую можно реализовать за пару человеколет.

E>Поэтому имеет смысл высказываться вот в таком стиле? http://www.rsdn.ru/forum/philosophy/3464879.1.aspx
Автор: Ikemefula
Дата: 12.07.09

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

E>>> Да думаю и много еще чего, поскольку поднять такую махину вряд ли можно было только в одиночку.

IB>>Все верно, так что там про компонентное программирование?

E>

E>To me, "re-editable code" is much, much better than an untouchable black box or toolkit.

Так как это согласуется с тем, что он, по твоим же словам, переиспользовал кучу black box-ов?

Далее, тут все спорщики не учитывают, что же на самом деле значит термин "re-editable code". Так вот сдается мне, что это не просто код, к которому у тебя есть исходники, которые ты можешь поправить под свои нужды — это бред, такой подход в жизни не работает.
А это как раз тот код, который спроектирован в лучших традициях компонентного программирования, OCP и других правильных вещей, где трогая одну часть, ты уверен, что остальное не сломается, и можешь выкинуть одну часть, и подставить туда свою реализацию, таки используя остальное как black box. Вот это на самом деле и есть re-editable code.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[34]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 06:21
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Думаю, что опыт Кнута уже давно оказался восстребованным (хотя под соусом опыта Торвальдса) -- сейчас он активно используется в виде "спонсирования OpenSource разработок".

Я уже намекал на то, что OpenSource != "re-editable code".
OpenSource использует untouchable blackbox в полный рост.
Мне также непонятно, каким образом опыт Кнута приравнивается к "спонсированию". Он что, дал кому-то денег на прикручивание прямого рендера в PDF минуя DVI?

Я предлагаю прекратить измываться над этим интервью — ваши натяжки разных частей текста на выпуклые места уже утомили.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 07:20
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

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

E>>Ну просто для общего развития, что же тогда такое OpenSource?
S>OpenSource — это всего лишь свободная раздача доступа к исходникам.

Ага, это то, что в MS называют SharedSource.

S>Часть идеологии OpenSource — в возможности "затачивать под себя", re-editable.


Это не часть, это краеугольный камень.

S>К сожалению, эта техника has proven generally ineffective,


Прям фраза из get the facts.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[37]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 17.07.09 07:53
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

E>>Ну просто для общего развития, что же тогда такое OpenSource?

S>OpenSource — это всего лишь свободная раздача доступа к исходникам. Часть идеологии OpenSource — в возможности "затачивать под себя", re-editable.

OpenSource — это не только возможность просмотра кода, но также обязательная возможность изменения. Не просто "часть идеологии", а неотъемлемая часть.
Re[39]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 17.07.09 08:26
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Отлично. И вот практика показывает, что 99% OS не пользуется этой "неотъемлемой" частью.


Практика может показывать, что 99% не пользуются и первой возможностью, чтения кода. Это ничего не говорит о понятии OpenSource.

Допустим, не пользуются этой возможостью 100%. От этого эта возможность никуда не исчезает и не перестаёт быть неотъемлемой частью OS. Без кавычек.
Re[40]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 08:54
Оценка: +1
Здравствуйте, lomeo, Вы писали:
L>Допустим, не пользуются этой возможостью 100%. От этого эта возможность никуда не исчезает и не перестаёт быть неотъемлемой частью OS. Без кавычек.
Допустим. На мой взгляд, возможность, которой не пользуется ровно никто, запросто можно отъять.

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

Допустим, кто-то придумывает такую штуку, как "идеология свободного автомобиля". В ней главными являются возможности использовать
1. Руль
2. Колёса
3. Тормозной парашют.
И всё это бесплатно.

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

Теперь мы смотрим, допустим, на статистику. Оказывается, что "закрытых" автомобилей — 40% процентов, "свободных" — 60%.
Свидетели Свободных Автомобилей объявляют это "очевидной успешностью и востребованностью свободных автомобилей в коммерческом применении".
И считают, что изобретатель тормозного парашюта, собственно, и внёс главный вклад в этот несомненный успех. Несмотря на то, что пользуются тормозным парашютом менее 1% народу.

Правы ли они? Или это религиозный бред и вера в чудотворные свойства тормозного парашюта?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[45]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 10:25
Оценка: +1
Здравствуйте, IB, Вы писали:

E>>Разработчик одиночка вполне может выпускать коммерческие проекты.

IB>Да кто бы спорил.

Тогда в чем проблема? Если у вас есть перспективная идея, которая может выстрелить, то найдите толкового человека, дайте ему развернуться, а потом получите девиденды.

E>>Это ты сам решай. Опыт возникновения и развития Hotmail-а (до покупки их MS) показывает, что можно и так пойти.

IB>А что, Hotmail писали все сами под себя, переписывая все что под руку попадется под свои нужды?

Где Кнут призывал все переписывать под себя?

E>>Не вижу оснований для этого.

IB>Рекомендую прозреть..

Я смотрю, здесь только ты и Синклер занимается разработкой коммерческого и восстребованного софта. Может это вам прозреть надо?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 10:37
Оценка: -1
Здравствуйте, eao197, Вы писали:
4>>Плохо или хорошо, использовать готовый хорошо отлаженный компонент?
E>Покажите, пожалуйста, в словах Кнута запрещение использовать готовые хорошо отлаженные компоненты.
Известно, что можно привести лошадь к воде, но напиться её не заставишь. С вами, по-видимому, тоже: можно сколько угодно мусолить один и тот же текст, но слова "угроза" по отношению к "готовому хорошо отлаженному коду" вы не увидите.

you’ll never convince me that reusable code isn’t mostly a menace.

... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Кнут о компонентном программировании.
От: 4058  
Дата: 17.07.09 10:43
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Написал TeX и METAFONT.

E>Результаты этой работы вы можете видеть, например, в книгах издательства The Pragmatic Programmers. И еще в туче книг и статей математической, физической, химической и т.д. направленности.

Прекрасно, такие вот узкоспециализированные академически-ориентированные задачки.
METAFONT — это скорее язык предназначенный в качестве дополнение к TeX, последняя которого вышла в 1989.

Цитата из WikiPedia:

В 1989 году Дональд Кнут выпустил новые версии систем TeX и METAFONT. Вопреки своему желанию сохранить программу неизменной, Кнут осознал, что 128-ми различных символов недостаточно, чтобы обеспечить ввод текста на разных языках. Таким образом, главным изменением в версии 3.0 была возможность работать с 8-ми битными входными данными, которые позволяли использовать 256 различных символов.


А в каких условиях он работал? Были у него четкие сроки, или коллектив состоящий из разнокаллиберных умельцев?
Если один и по нечетким срокам, то его изречения по поводу КОП, являются не обоснованными (ибо нет практики!),
ибо даже имеющиеся проекты не достаточно сложны, для понимания этого.

4>>Плохо или хорошо, использовать готовый хорошо отлаженный компонент?


E>Покажите, пожалуйста, в словах Кнута запрещение использовать готовые хорошо отлаженные компоненты.


Ну есть заявление, что КОП это плохо, и далее обращение к читателю, что если Вы это не признаете, значит еще "не доросли".
Re[18]: Кнут о компонентном программировании.
От: 4058  
Дата: 17.07.09 12:03
Оценка: +1
Здравствуйте, eao197, Вы писали:

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


E>У него не было ни сроков, ни, практически, денег на разработку. И он делал почти все сам в одиночку. Тем не менее в свое время Apple II стал продаваемым ПК.


Аналогичная история с Sinclair, да и многими другими бытовыми компьютерами.
Один в гараже, ни сроков, ни денег. Своего рода романтика...
Но какое отношение это имеет к сегодняшним суровым реалиям?

E>Т.е., по сути, вы сомневаетесь в том, если ли у Кнута достаточный практический опыт, чтобы высказываться на тему повторного использования кода. Так я вас понял?


Совершенно верно.

E>В выделенным жирным "повторно используемый код" является синонимом untochable black box.

E>Но даже когда повторно используемый код не является черным ящиком он все равно может нести в себе угрозу: например, неоднокрано упомянутый здесь за последнее время Arian 5 Flight 501.

Подобного рода примеры, ровном счетом ничего не доказывают, т.к. любой код может нести в себе угрозу.
Re[20]: Кнут о компонентном программировании.
От: 4058  
Дата: 17.07.09 14:21
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>В наши суровые реалии стартапы продолжают возникать, а некоторые даже становиться успешными. Так что не вижу принципиальных различий.


Принципиальные различия в том, что зачастую на стартапах, не удается прочувствовать всю "прелесть", современного софтвэр-инжиниринга.

E>Тут где-то IB пример приводил -- распознавание формул. Тратить большие деньги OCR-разработчики на эту узкую задачу не хотят. Но тот, кто первым сделает качественное распознавание, может стать монополистом рынка. Может сейчас кто-то по вечерам этой задачей занимается. И вряд ли для нее нужно большое количество сторонних black box-ов.


Это классическая утопичная задача подраздела ИИ, и в более широком смысле называется — распознавание образов.
Сейчас ведется множество проектов подобной тематики, та же MS носится со своим Project Natal-ом,
который собирается прикручивать в виде развлекательного устройства для PC и XBOX360.
По их заявдениям Натал (и демонстрации на выставке E3),
сможет распозновывать лица человека + эмоции/мимику, и приблизительно определять возраст (в реальном времени),
то расспознавание статических образов (формул) на этом фоне, выглядит не более чем подзадачей.
Аналогичными делами сейчас занимается Sony, для своей PS3.

E>>>Т.е., по сути, вы сомневаетесь в том, если ли у Кнута достаточный практический опыт, чтобы высказываться на тему повторного использования кода. Так я вас понял?


E>Боюсь, я не смогу вас разубедить. Поскольку вы считаете, что копьютерная верстка (которой занимается TeX) -- это "узкоспециализированные академически-ориентированные задачки", не идущие ни в какое сравнение с суровыми серверными системами режима 24/7. Единственный способ разубедить вас в этом -- попробовать реализовать аналог TeX-а.


Тут даже дело, не столько в функциональности, сколько в упомянутых ранее условиях.
"Суровые системы 24/7" имеют в своем составе, значительно более сложные компоненты чем упомянутая верстка,
причем некоторые нетривиальные в реализации компоненты в свое врямя приходилось писать на коленке.
А для чистоты эксперимента, смогу ли я убедить Кнута, проделать мою работу и в моих условиях?
Re[17]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.07.09 16:09
Оценка: :)
Здравствуйте, COFF, Вы писали:

COF>Это хорошо или плохо?


Это демагогия.

COF> Вообще, я ничего не доказывал, просто довел уже имевшиеся рассуждения об яичнице до некоторой точки


С какой целью?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[46]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 17:25
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Тогда в чем проблема? Если у вас есть перспективная идея, которая может выстрелить, то найдите толкового человека, дайте ему развернуться, а потом получите девиденды.

Проблема в том, что определить толкового человека, пока он ничего не реализовал нельзя. А реализовать надо было уже вчера. Поэтому проще, надежнее и выгоднее взять пяток нормальных и сделать то что нужно с гораздо более предсказуемым результатом.

E>Я смотрю, здесь только ты и Синклер занимается разработкой коммерческого и восстребованного софта. Может это вам прозреть надо?

Нет, зесь только ты и Кнут не представляете что это такое..
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[24]: Кнут о компонентном программировании.
От: 4058  
Дата: 19.07.09 09:23
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>...Да и вы сами сомневаетесь в том, достаточно ли Кнут попрограммировал, чтобы его вообще слушать.


Возвращаясь к вопросу о целесообразности КОП и "черных ящиков" ...
Допустим имеется клиент-серверная система уровня предприятия (пускай немного пафосное и абстрактное название, но суть передает).
В одном из требований оговорено, что в случае возникновения сбоя/ошибки и т.п. на стороне клиента,
отправить лог-серверу отчет, содержащий состояние памяти рабочего процесса (допустим состояние объектов),
а в службу поддержки необходимо отправить email содержащий скриншот (для более простой и удобной диагностики проблемы).
Пересылать DIB/BMP по email, как-то неразумно, т.к. среднее разрешение у пользователя 1280*800, а каналы
доступа до службы поддержки не всегда бывают широкие, и на почтовых серверах винты тоже не резиновые.
Лучшим (и очевидным) решением в данном случае является сжатие с потерями (JPG/PNG), т.к. здесь не требуется точная (PTP) передача растровой инфомации, при этом формат должен быть общедоступен. Следовательно нужен кодек-конвертер DIB->PNG/JPG. И как это не прискорбно для меня это кодек является тем самым "черным ящиком", т.к. я на прямую не занимаюсь проблемой сжатия растров, да и наличие исходого кода данного кодека, много пользы мне не пренесет (он прекрасно отлажен и регулярно используется, а если возникнет проблема, то на 99% я не смогу ее решить во всяком случае за приемлемое время).

И вот здесь хочется вернутся к рассуждению о том, что если человеку недавелось регулярно забивать гвозди (или он попытался, но отбил себе пальцы), то прислушиваться к его рассуждениям о чрезмерной опастности молотка, приходится с большой осторожностью.
Re[45]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 20.07.09 07:37
Оценка: +1
Здравствуйте, IB, Вы писали:

L>> Я не заметил, чтобы eao197 как то по своему описывал подход Кнута.

IB>То есть, его аргументация у тебя возражений не вызывает? А как же призывы подумать?

Нет, не вызывает.
А думать я стараюсь для того, чтобы понять, а не найти возражения.
Re[46]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 20.07.09 08:29
Оценка: -1
Здравствуйте, lomeo, Вы писали:

L>Нет, не вызывает.

То есть, слепое поклонение авторитету думательную часть мозга отключает. ЧТД.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
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[5]: Кнут о компонентном программировании.
От: Baudolino  
Дата: 03.08.09 19:04
Оценка: :)
T>Ты, как я понял, в expression problem всё ещё не ухом, ни рылом, так?
Рыло у свиней. Вы поняли неправильно. Я не вижу смысла в дальнейшем обсуждении притянутых за уши тем. Да и кто вы собственно такой, чтобы давать мне подобные советы?
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[13]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 04.08.09 13:51
Оценка: :)
Здравствуйте, master_of_shadows, Вы писали:

поскипал то, с чем согласен
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[13]: ROFL
От: Roman Odaisky Украина  
Дата: 08.08.09 09:06
Оценка: :)
Здравствуйте, 4058, Вы писали:

4>Поговорим об пресловутых печатных отчетах, для этого я использую (но не всегда) компонент, который преобразует HTML->PDF. Стоимость компонента 400$, работает у нас в условиях 24/7.


Я всегда полагал, что аббревиатура ROFL есть самопротиворечивая абстракция, но это твое сообщение как никогда близко подходит к тому, чтобы воплотить ее в жизнь. Противопоставлять себя Кнуту, настаивая на полезности «готовых хорошо отлаженных компонентов» в области «реальных систем» и на примере чего — «подготовки печатных отчетов»! Я, конечно, понимаю, что Кнут не стал бы заниматься «такой приземленной „ерундой“» вроде компонентов для преобразования текста в PDF, но предположив на минутку, что он задался бы такой целью, какие твои прогнозы насчет его (теоретической, конечно) конкурентоспособности с вышеупомянутым компонентом, который, с одной стороны, хорошо отлажен («хорошо отлажен» — это сколько известных багов?) и, с другой стороны, стоит всего лишь $400 (да, признаю: Кнут никогда не смог бы конкурировать на этом уровне)?
До последнего не верил в пирамиду Лебедева.
Re[47]: Завидую eao197!!!
От: Erop Россия  
Дата: 08.08.09 09:23
Оценка: :)
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, eao197, Вы писали:
IB>Нет, зесь только ты и Кнут не представляете что это такое..

Эх, чертовски неплохая компания, надо сказать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Кнут о компонентном программировании.
От: Воронков Василий Россия  
Дата: 10.08.09 17:49
Оценка: -1
Здравствуйте, eao197, Вы писали:

E>Индустрия производства ПО, по мнению некоторых участников RSDN, находится в глубокой заднице. При этом программисты-практики, как представители этой самой индустрии, позволяют себе смеятся над человеком, достижения которого (как программиста) им и не повторить. Вместо того, чтобы подумать, а за счет чего Кнуту удается (удавалось) в одиночку делать так много и так хорошо. Может быть и его взгляд на повторное использование не так уж нелеп, как это кажется.


Ну пусть и продолжает делать "так много и так хорошо" дальше, пишет книги, алгоритмы придумывает. Со всем к нему уважением. А повторное использование лучше уж оставить практикам.

А то это, извините, равносильно тому, чтобы молиться на советы по вождению от человека, который изобрел ДВС, но при этом сам никогда не водил автомобиль.
Re[18]: Кнут о компонентном программировании.
От: Воронков Василий Россия  
Дата: 11.08.09 08:11
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

ВВ>>Предположим, в компании есть отдельная команда, которая занимается разработкой компонент, используемых в других проектах. Данные компоненты никогда не меняются в рамках отдельных проектов, однако разработавшая их команда осуществляет поддержку, исправляет баги, добавляет фичи.

ВВ>>Это "в терминах Кнута" reusable или reeditable код?
S>Конечно же reusable. Поскольку все проекты используют этот код как чёрный ящик.
S>Reeditable был бы в том случае, если бы проектная команда брала исходники компонента и допиливала под себя.

Где ты видишь черный ящик? Код доступен, можешь его посмотреть да и вообще-то говоря он вполне изменяемый — просто есть разделение труда, его допиливает отдельная команда.
Вся разница сводится к тому, что в одном случае во всех проектах используется один и тот же компонент, а в другом — разные версии одного компонента.

Вариант, который защищают сторонники reeditable, это плодить кучу несвязанных модификаций, которые не смогут нормально поддерживать ни первоначальные разработчики, ни те, кто меняли, так как их знание о работе кода как правило весьма поверхностное?
Re[2]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.07.09 15:47
Оценка:
Здравствуйте, DarkGray, Вы писали:


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


DG>нарушает принцип программирования:

DG>

DG>26. c) Open for extension, closed for modification

DG>http://blog.metatech.ru/post/ogni-razrabotki.aspx

Интересно, почему этот принцип не работал при решении проблемы 2000-го года?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 09.07.09 15:55
Оценка:
T>>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.

DG>нарушает принцип программирования:

DG>

DG>26. c) Open for extension, closed for modification

DG>http://blog.metatech.ru/post/ogni-razrabotki.aspx

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

Начну с того, что он плохо подходит к ситуации с меняющимися требованиями.

И сразу же завершу: я говорил не о непреклонном принципе разработки, а о достижимости некоторой ситуации.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Кнут о компонентном программировании.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.07.09 16:12
Оценка:
E>Интересно, почему этот принцип не работал при решении проблемы 2000-го года?

в смысле не работал?

очень даже работал, во многих местах лишь меняли функцию сложения и вычитания времени, когда год 00 — год 99 получалось 1 год, при этом так и оставляя две цифры.

в тех местах где даты между годами сравнивать(оперировать) не надо, даже это не делали

т.е. люди снаружи договаривались о том, что если они видят цифры 00-49, то это 21 первый век, а если 50-99, то это 20 век
Re[4]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.07.09 16:36
Оценка:
Здравствуйте, DarkGray, Вы писали:


E>>Интересно, почему этот принцип не работал при решении проблемы 2000-го года?


DG>в смысле не работал?


В смысле, что во многих местах софт переписывали и базы перелопачивали.

DG>очень даже работал, во многих местах лишь меняли функцию сложения и вычитания времени, когда год 00 — год 99 получалось 1 год, при этом так и оставляя две цифры.


DG>в тех местах где даты между годами сравнивать(оперировать) не надо, даже это не делали


DG>т.е. люди снаружи договаривались о том, что если они видят цифры 00-49, то это 21 первый век, а если 50-99, то это 20 век


Да уж, классный способ работы. Как раз, чтобы в 2090-х годах специалисты по COBOL-у опять стали восстребованны.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 09.07.09 16:56
Оценка:
Здравствуйте, DarkGray, Вы писали:

T>>И сразу же завершу: я говорил не о непреклонном принципе разработки, а о достижимости некоторой ситуации.


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

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

Какую же я ставлю цель?

DG>а кода много больше, он намного менее понятен людям, более закрытый (более оторванный от жизни людей) — соответственно задача еще менее реальная.


Поэтому принято использовать специально обученных людей — программистов. Для них это жизнь.

DG>проблема в том, что при модификации чего-либо надо много чего держать в голове одновременно (причем счет может идти на миллиарды ситуаций), а человеческий мозг имеет довольно серьезные ограничения по количеству одновременно оперируемых понятий.


Это решается декомпозицией. Никакой проблемы я тут не вижу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Кнут о компонентном программировании.
От: Calabon Ниоткуда  
Дата: 09.07.09 19:05
Оценка:
Здравствуйте, thesz, Вы писали:

ИМХО, всего надо вмеру.
Я наблюдал как чрезмерно глобализированный код становился кучей воркараундов...

Чрезмерная глобализация ничем не лучше чем чрезмерное "говно-кодирование" (что означает тупо to make it work или re-editable в полном смысле всё девелопится заново каждый раз)

На мой взгляд данное утверждение справедливо для мелких тулзеней, которые выполняют очень мелкую работу и не планируют расширятся..
Таких очень много в линухе...
Re[4]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 10:32
Оценка:
Здравствуйте, jazzer, Вы писали:

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


T>>Проблема в поддержке инвариантов. Ты поправил повторно используемый код, ты уверен, что он правильно заработает во всех местах его использования?


J>Для решения этой проблемы существуют юнит-тесты.


А если их изначально не было? Как они решат эту проблему?

(кстати, уверен, это именно твой случай)

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

J>Юнит-тесты все же надежнее и проще.
J>Хотя бы потому, что тебе не нужно запускать все тот список программ, что ты привел.

Правильный компилятор
Автор: dotneter
Дата: 01.07.09
выявляет больше ошибок
Автор: thesz
Дата: 05.02.09
, чем любой юнит тест (и любое их количество).

Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 10.07.09 12:33
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Проблема в поддержке инвариантов. Ты поправил повторно используемый код, ты уверен, что он правильно заработает во всех местах его использования?


J>>Для решения этой проблемы существуют юнит-тесты.


T>А если их изначально не было? Как они решат эту проблему?


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

T>(кстати, уверен, это именно твой случай)

Слава богу, это уже несколько лет не мой случай

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

J>>Юнит-тесты все же надежнее и проще.
J>>Хотя бы потому, что тебе не нужно запускать все тот список программ, что ты привел.

T>Правильный компилятор
Автор: dotneter
Дата: 01.07.09
выявляет больше ошибок
Автор: thesz
Дата: 05.02.09
, чем любой юнит тест (и любое их количество).


Ты передергиваешь. "Компиляторы, дебаггеры, всякие валгринды", удобство и функциональность которых улучшаются со временем, не предполагают смены языка, как в случае перехода на зависимые типы, когда старый компонент по-любому не может быть использован, просто потому что язык другой.
Понятно, что на бейсике писать удобнее, чем на ассемблере, на С++ — удобнее, чем на бейсике, и т.д, с этим никто не спорит.

T>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.
Боюсь, что с ростом сложности требований к типам потребуется настолько сложое описание этого типа, что потребуется дебаггер для того, чтоб убедиться, что ты правильно все записал.
В то время как при помощи юнит-тестов подобные вещи выражаются очень просто, хотя, естественно, они не являются строгим доказательством корректности, как в случае использования зависимых типов.

Просто, имхо, баланс должен быть.
Что просто выразить через систему типов — должно быть выражено там, а что проще через простейшие юнит-тесты в противовес килобайту зависимых типов — должно быть в тестах.
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[3]: Кнут о компонентном программировании.
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 10.07.09 14:15
Оценка:
T>Современные средства программирования достаточно хороши, чтобы при наличии исходников можно было бы подправить компонент до поддержки твоих нужд.

T>Если мы зафиксируем некоторый срок, то вероятность дописать компонент до нужного уровня становится всё выше и выше с течением времени. Грубо говоря, вчера было труднее написать, чем найти, сегодня проще написать.


А объем этого кода в геометрической прогрессии больше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[5]: Кнут о компонентном программировании.
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 10.07.09 14:24
Оценка:
T>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

Цель ясна. И с ней наверное согласны. Но это не отменяет того факта, что разработка не становится дешевле, потому что избавившись от сложности на низком уровне, мы приобретаем сложность и многовариантность (что практически то же самое) на высоком.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[6]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 14:33
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>>>Для решения этой проблемы существуют юнит-тесты.

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

Но он не будет проверять другие граничные условия, для других вариантов использования.

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

J>>>Юнит-тесты все же надежнее и проще.
J>>>Хотя бы потому, что тебе не нужно запускать все тот список программ, что ты привел.

T>>Правильный компилятор
Автор: dotneter
Дата: 01.07.09
выявляет больше ошибок
Автор: thesz
Дата: 05.02.09
, чем любой юнит тест (и любое их количество).

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

Как автор, я не вижу здесь передергивания.

Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.

Например, если раньше я использовал FILE* read_filename_from_first_string(FILE*f), а теперь начал использовать FILE<content> read_filename_from_first_string(FILE<text_file>* f), то я не отверчусь. Надо будет сделать кучу телодвижений, которые окупятся потом.

J>Понятно, что на бейсике писать удобнее, чем на ассемблере, на С++ — удобнее, чем на бейсике, и т.д, с этим никто не спорит.


T>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.

Нормально.

Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.

J>Боюсь, что с ростом сложности требований к типам потребуется настолько сложое описание этого типа, что потребуется дебаггер для того, чтоб убедиться, что ты правильно все записал.

J>В то время как при помощи юнит-тестов подобные вещи выражаются очень просто, хотя, естественно, они не являются строгим доказательством корректности, как в случае использования зависимых типов.

J>Просто, имхо, баланс должен быть.

J>Что просто выразить через систему типов — должно быть выражено там, а что проще через простейшие юнит-тесты в противовес килобайту зависимых типов — должно быть в тестах.

Насчёт килобайта зависимых типов это ты повторяешь чужие глупые мысли.

Спецификация не может быть длинней кода. Тем более она не может быть длинней тестов этого кода.

PS
Почему-то любая дискуссия со мной выливается в "юинт-тесты супротив статической типизации".

Круто!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 14:35
Оценка:
Здравствуйте, VGn, Вы писали:

T>>Если мы зафиксируем некоторый срок, то вероятность дописать компонент до нужного уровня становится всё выше и выше с течением времени. Грубо говоря, вчера было труднее написать, чем найти, сегодня проще написать.


VGn>А объем этого кода в геометрической прогрессии больше.


В арифметической, если мы берём одного разработчика. В геометрической, если мы берем рост разработчиков.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Кнут о компонентном программировании.
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 10.07.09 15:07
Оценка:
T>>>Если мы зафиксируем некоторый срок, то вероятность дописать компонент до нужного уровня становится всё выше и выше с течением времени. Грубо говоря, вчера было труднее написать, чем найти, сегодня проще написать.

VGn>>А объем этого кода в геометрической прогрессии больше.


T>В арифметической, если мы берём одного разработчика. В геометрической, если мы берем рост разработчиков.


Вот именно, что нет. Пять лет назад у того же грида было в десять раз меньше свойств. И свойства стали сложнее. При этом он как гридом был, так им и остался. А поскольку средства стали лучше, мы сейчас можем использовать этот грид намного быстрее. И что теперь при наличии исходников проще стало доработать контрол?
Кстати это обычно не проблема. Все ведущие производители контролов поставляют исходники за отдельную плату. Но разработчики заглядывают в них всё реже и реже. И это правильно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[7]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 10.07.09 17:33
Оценка:
Здравствуйте, thesz, Вы писали:

J>>Стало быть, на этот фикс пишется соответствующий юнит-тест, который этот граничный случай будет проверять.


T>Но он не будет проверять другие граничные условия, для других вариантов использования.

Да.
Может, их и нету, других граничных случаев.
Это называется "решать проблемы по мере их появления".
Ты, кстати, точно так же можешь забыть выразить граничные случаи в зависимых типах.

T>Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.


Если ты внес в язык зависимые типы, которых там раньше не было, то это уже другой язык.

T>Например, если раньше я использовал FILE* read_filename_from_first_string(FILE*f), а теперь начал использовать FILE<content> read_filename_from_first_string(FILE<text_file>* f), то я не отверчусь. Надо будет сделать кучу телодвижений, которые окупятся потом.


Вот-вот: эдесь ты только что из С сделал С++.

T>>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.

T>Нормально.


T>Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.

Сокращают какой код?
Код определения типа — могут только усложнить.
В противовес этому, возможно, помрут какие-то юнит-тесты.
Я говорю "возможно", потому что то, как ты запрограммировал свои зависимые типы, тоже неплохо бы проверить, а то вдруг ты где-то минус с плюсом перепутал, как указывали в соседней дискуссии.
Такие вещи только юнит-тестами можно отловить, ну или любым другим альтернативным проверяющим движком — просто потому, что одну и ту же ошибку в двух совсем разных местах совершить затруднительно.

J>>Просто, имхо, баланс должен быть.

J>>Что просто выразить через систему типов — должно быть выражено там, а что проще через простейшие юнит-тесты в противовес килобайту зависимых типов — должно быть в тестах.

T>Насчёт килобайта зависимых типов это ты повторяешь чужие глупые мысли.

Вот еще! Это мои личные глупые мысли!

T>Спецификация не может быть длинней кода. Тем более она не может быть длинней тестов этого кода.

Спецификация на человеческом языке вполне может быть короче кода, выражающего эту спецификацию на машинном языке.
Просто потому что спецификация на человеческом языке опирается на весь контекст, доступный человеку, а для машины тебе придется весь этот контекст воспроизвести руками.

T>Почему-то любая дискуссия со мной выливается в "юинт-тесты супротив статической типизации".

Ну потому что ты ратуешь за то, чтоб вообще все загнать в статику.
На что тебе указывают, что даже твою статику надо чем-то проверять, не говоря уже о том, что нужно проверять и то, что нельзя (или трудно) загнать в систему типов.
Я сам большой поклонник статики и все, что можно, стараюсь сделать ошибкой времени компиляции.
Только вот потом тебе нужно все равно написать тест, который скомпилирует то, что правильно, и не скомпилирует то, что неправильно — иначе как ты узнаешь, что ты реализовал статику без ошибок?
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]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 10.07.09 19:09
Оценка:
T>>Но он не будет проверять другие граничные условия, для других вариантов использования.
J>Да.
J>Может, их и нету, других граничных случаев.
J>Это называется "решать проблемы по мере их появления".
J>Ты, кстати, точно так же можешь забыть выразить граничные случаи в зависимых типах.

Не получится. По рукам дадут.

T>>Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.

J>Если ты внес в язык зависимые типы, которых там раньше не было, то это уже другой язык.

Расширение предыдущего.

См. лямбда-куб.

T>>Например, если раньше я использовал FILE* read_filename_from_first_string(FILE*f), а теперь начал использовать FILE<content> read_filename_from_first_string(FILE<text_file>* f), то я не отверчусь. Надо будет сделать кучу телодвижений, которые окупятся потом.

J>Вот-вот: эдесь ты только что из С сделал С++.

Или просто использовал шаблоны.

T>>>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>>>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.
T>>Нормально.
T>>Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.
J>Сокращают какой код?
J>Код определения типа — могут только усложнить.

И насколько, как ты думаешь?

J>В противовес этому, возможно, помрут какие-то юнит-тесты.

J>Я говорю "возможно", потому что то, как ты запрограммировал свои зависимые типы, тоже неплохо бы проверить, а то вдруг ты где-то минус с плюсом перепутал, как указывали в соседней дискуссии.

Минус-плюс я могу в параметр внести, видно будет.

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


Правильно, функциональным тестом. Не юнит-тестом, в последнем смысла нет.

T>>Спецификация не может быть длинней кода. Тем более она не может быть длинней тестов этого кода.

J>Спецификация на человеческом языке вполне может быть короче кода, выражающего эту спецификацию на машинном языке.
J>Просто потому что спецификация на человеческом языке опирается на весь контекст, доступный человеку, а для машины тебе придется весь этот контекст воспроизвести руками.

Спецификация на машинном языке — на той же Агде или на ACL2, — опирается на всю мощь библиотеки машинного языка, которую не надо воспроизводить руками.

T>>Почему-то любая дискуссия со мной выливается в "юинт-тесты супротив статической типизации".

J>Ну потому что ты ратуешь за то, чтоб вообще все загнать в статику.

Потому, что когда человек пишет программу, он рассуждает о программе статически, и никак иначе.

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


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

J>Я сам большой поклонник статики и все, что можно, стараюсь сделать ошибкой времени компиляции.

J>Только вот потом тебе нужно все равно написать тест, который скомпилирует то, что правильно, и не скомпилирует то, что неправильно — иначе как ты узнаешь, что ты реализовал статику без ошибок?

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

А больше мне не надо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.07.09 13:52
Оценка:
Здравствуйте, jazzer, Вы писали:

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


T>>>>Но он не будет проверять другие граничные условия, для других вариантов использования.

J>>>Да.
J>>>Может, их и нету, других граничных случаев.
J>>>Это называется "решать проблемы по мере их появления".
J>>>Ты, кстати, точно так же можешь забыть выразить граничные случаи в зависимых типах.
T>>Не получится. По рукам дадут.
J>Ну что значит — не получится, если в момент написания они тебе попросту неизвестны?
J>И только то, что ты придумаешь, то там и будет.
J>И потом уже в продакшене выяснится, что еще вот такой случай надо специально обработать, и другой — своим особым образом...
J>А ты о них, когда писал первую версию, ни сном, ни духом.

Это такой сферический конь в вакууме, да?

Типа, если мы чего не знаем, то мы всегда ничего не знаем.

Да ну, глупость.

T>>>>Если я вношу в язык зависимые типы и начинаю их применять, то мне придётся распространять доказательства соответствия спецификации по всей программе.

J>>>Если ты внес в язык зависимые типы, которых там раньше не было, то это уже другой язык.
T>>Расширение предыдущего.
J>Это обычно и означает — новый язык.

Вот, в Хаскеле появились ассоциированные типы. Стал ли Хаскель новым языком?

J>>>Вот-вот: эдесь ты только что из С сделал С++.

T>>Или просто использовал шаблоны.
J>В С нет шаблонов.
J>Так что это таки С -> С++.

Приведённый мной код и Си, и Си++.

T>>>>>>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".

J>>>>>Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.
T>>>>Нормально.
T>>>>Из моего опыта использования ассоциированных типов в Хаскеле они действительно сокращают код.
J>>>Сокращают какой код?
J>>>Код определения типа — могут только усложнить.
T>>И насколько, как ты думаешь?
J>Что значит — насколько? В чем мерять?
J>Думаю, это от языка зависит. В том, который под зависимые типы заточен — в том мало будет дополнительной писанины, а в том, который не заточен — это либо очень многословно, либо вообще нереализуемо.

Ура. По-моему, есть подвижка/

J>>>В противовес этому, возможно, помрут какие-то юнит-тесты.

J>>>Я говорю "возможно", потому что то, как ты запрограммировал свои зависимые типы, тоже неплохо бы проверить, а то вдруг ты где-то минус с плюсом перепутал, как указывали в соседней дискуссии.
T>>Минус-плюс я могу в параметр внести, видно будет.
J>Ну вот о чем и речь, что придется весь текст функции засунуть в тип.

Внутренние связи между ограничениями не будут видны в типе. Поэтому я отвечаю резким "нет".

J>После чего у тебя сложность типа будет сравнима со сложностью кода функции, и если код сильно кучерявый, то и тип будет такой же.


Опять же, нет.

J>И этот тип придется тестировать так же, как ты тестировал бы функцию без этого типа.


И снова нет.

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

T>>Правильно, функциональным тестом. Не юнит-тестом, в последнем смысла нет.
J>И каждый раз функциональный тест руками проделывать? А ты точно не забудешь проверить все граничные случаи, что ты их правильно запрограммировал? Их же все, по-хорошему, надо проверить. Это и есть юнит-тесты.

Граничные условия отдельных функций проверяются типами функций.

T>>Спецификация на машинном языке — на той же Агде или на ACL2, — опирается на всю мощь библиотеки машинного языка, которую не надо воспроизводить руками.

J>Можешь развернуть этот тезис?

Да чего разворачивать. Вот стандартная библиотека Agda2: http://www.cs.nott.ac.uk/~nad/repos/lib/src/

В ней присутствуют: Алгебры, Категории, Операции по индукции, Коиндукция (для всякого рода бесконечных вещей), Отношения (например, типы, индексированные отношениями) и прочее.

Берешь и используешь.

T>>Потому, что когда человек пишет программу, он рассуждает о программе статически, и никак иначе.

J>Можешь развернуть и этот тезис?

У человека, рассуждающего о программе, есть только её текст. Иногда логи, которые показывают события, происходившие в отдельных частях программы, но в основном только текст.

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

Больше мне сказать нечего.

J>>>Я сам большой поклонник статики и все, что можно, стараюсь сделать ошибкой времени компиляции.

J>>>Только вот потом тебе нужно все равно написать тест, который скомпилирует то, что правильно, и не скомпилирует то, что неправильно — иначе как ты узнаешь, что ты реализовал статику без ошибок?
T>>Нет, мне не надо писать такой тест. Если я правильно написал основные типы, то мои операции будут ими правильно ограничены, я не смогу сделать лишнего и смогу сделать нужное.
J>Вот для проверки утверждения "Если я правильно написал" тесты и нужны, и никуда ты не денешься от них.

Если я неправильно написал типы, то у меня будут затруднения с выражением своих мыслей в других частях программы. Программа просто не будет написана.

Она На Хаскеле пишется с трудом, если типы плохие, что уж говорить про зависимые типы.

Тесты калибра меньше функциональных не нужны.

Функциональные тесты нужны для проверки высокоуровневой логики, Типа, "подходит ли это заказчику".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 11.07.09 19:40
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Ну вот о чем и речь, что придется весь текст функции засунуть в тип.

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

см. ниже.

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


Смотри. Если ты написал тип правильно, то, согласно Curry-Howard isomorphism, если функции, использующие этот тип, компилируются, то это будет доказательством того, что тип написан верно. Написать тип неправильно, конечно, можно тоже, но тогда у тебя это выловится в дальнейшем, когда ты попытаешься с этим типом работать (ожидая от типа, что он описывает определённый граничный случай).
Re[2]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 10:22
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


И это еще слабо сказано !
Re[4]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 11:04
Оценка:
Здравствуйте, eao197, Вы писали:

VD>>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>>И это еще слабо сказано !


E>Авторитетно заявил офигенный программист-практик XXI века.


Я просто программист-практик. Офигенный это про тебя.
Re[4]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 13:18
Оценка:
Здравствуйте, thesz, Вы писали:

VD>>>Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.


I>>И это еще слабо сказано !


T>Про тебя с Владом отлично написал в девятнадцатом веке Крылов: "Ай, моська..."


Покажи мне работы Кнута на тему "Искусство объектно ориентированого дизайна", "Искусство построения компонентов" и тд.

Валяй.
Re[4]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.07.09 13:23
Оценка:
Здравствуйте, thesz, Вы писали:

I>>И это еще слабо сказано !


T>Про тебя с Владом отлично написал в девятнадцатом веке Крылов: "Ай, моська..."


Это вряд ли. Тогда не было программистов-прагматиков.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 20:34
Оценка:
Здравствуйте, eao197, Вы писали:

T>>>Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".


I>>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


E>А Вы? Написали?


А ты ?
Re[7]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 12.07.09 21:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


T>>Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".


I>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


"Врага надо знать в лицо".

Published his groundbreaking paper "An empirical study of FORTRAN programs." ( Software---Practice and Experience, vol 1, pages 105-133, 1971) which laid the cornerstone of an empirical study of programming languages.

ОО языки программирования всё равно остаются языками программирования.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Кнут о компонентном программировании.
От: Erop Россия  
Дата: 12.07.09 21:56
Оценка:
Здравствуйте, thesz, Вы писали:

T>Видишь ли, в типы нельзя загнать, я думаю, только красоту души девушки. Всё остальное типизируется.


IMHO, это не правда.
Скажем представь себе, что ты игрока в шахматы пишешь. Типизируй, например, требование "играет не хуже первого взрослого разряда".
Или, ещё хитрее: "скорее всего выиграет у последней доступной версии программы-конкурента"...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 22:10
Оценка:
Здравствуйте, thesz, Вы писали:

T>Published his groundbreaking paper "An empirical study of FORTRAN programs." ( Software---Practice and Experience, vol 1, pages 105-133, 1971) which laid the cornerstone of an empirical study of programming languages.


И что ?

T>ОО языки программирования всё равно остаются языками программирования.


А прикинь, даже если не ОО, то все равно остаются языками программирования.
Re[9]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 05:25
Оценка:
Здравствуйте, Ikemefula, Вы писали:

T>>>>Он написал труд, сравнимый с, а то и превосходящий вышеуказанные. И не один. Практически каждый его труд лежит в основе "объектно-ориентированного дизайна" и в "построении компонент".


I>>>Он написал труд который никоим образом не относится к ООД и компонентам и многому, что есть в индустрии ПО.


E>>А Вы? Написали?


I>А ты ?


Нет. Поэтому и не позволяю себе насмехаться над Кнутом.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 09:04
Оценка:
Здравствуйте, eao197, Вы писали:

E>>>А Вы? Написали?


I>>А ты ?


E>Нет. Поэтому и не позволяю себе насмехаться над Кнутом.


Да, да, я решил проста так посмеяться, представь, вижу Влад про Кнута пишет, дай, думаю, посмеюсь.

Кнут, как программист, это одиночка, кроме того, он математик, алгоритмист-теоретик, отсюда его взгляды на реюзание кода нисколько неудивительны — в индустрии он никогда не работал.
Re[10]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 13.07.09 10:43
Оценка:
Здравствуйте, Erop, Вы писали:

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


T>>Видишь ли, в типы нельзя загнать, я думаю, только красоту души девушки. Всё остальное типизируется.


E>IMHO, это не правда.

E>Скажем представь себе, что ты игрока в шахматы пишешь. Типизируй, например, требование "играет не хуже первого взрослого разряда".
E>Или, ещё хитрее: "скорее всего выиграет у последней доступной версии программы-конкурента"...

Ранг шахматиста — его тип, — как раз и указывает на вероятность выигрыша у шахматиста другого ранга.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 11:14
Оценка:
Здравствуйте, thesz, Вы писали:

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


T>>>Published his groundbreaking paper "An empirical study of FORTRAN programs." ( Software---Practice and Experience, vol 1, pages 105-133, 1971) which laid the cornerstone of an empirical study of programming languages.


I>>И что ?


T>Я не буду переводить.


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

T>>>ОО языки программирования всё равно остаются языками программирования.


I>>А прикинь, даже если не ОО, то все равно остаются языками программирования.


T>Именно поэтому труд Кнута стоит в основании и ООП, и не ООП.


!A || A

T>Поэтому нападки в стиле "он не написал про компоненты" являются обычным тявканьем.


Ага, убедил
Re[11]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 13.07.09 12:09
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


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


T>>>>Published his groundbreaking paper "An empirical study of FORTRAN programs." ( Software---Practice and Experience, vol 1, pages 105-133, 1971) which laid the cornerstone of an empirical study of programming languages.

I>>>И что ?
T>>Я не буду переводить.
I>Не переводи, ты вместо его работы привел биографию, так бывает когда люди не умеют читать и тащат ссылки для весу.

Я Безрукову вполне доверяю.

T>>>>ОО языки программирования всё равно остаются языками программирования.


I>>>А прикинь, даже если не ОО, то все равно остаются языками программирования.


T>>Именно поэтому труд Кнута стоит в основании и ООП, и не ООП.


I>!A || A


¬A ∧ A, так лучше.

T>>Поэтому нападки в стиле "он не написал про компоненты" являются обычным тявканьем.

I>Ага, убедил

Я рад.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.09 17:20
Оценка:
I>>И это еще слабо сказано !

E>Авторитетно заявил офигенный программист-практик XXI века.


Съязвил офигительный программист XX-XXI-ых веков...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.09 17:26
Оценка:
Здравствуйте, thesz, Вы писали:

T>Про тебя с Владом отлично написал в девятнадцатом веке Крылов: "Ай, моська..."


Сдается тут моской является кто-то другой. Моски они очень хорошо определяются по тявканью на слонов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 17:42
Оценка:
Здравствуйте, VladD2, Вы писали:


I>>>И это еще слабо сказано !


E>>Авторитетно заявил офигенный программист-практик XXI века.


VD>Съязвил офигительный программист XX-XXI-ых веков...


Уж лучше демонстрировать подобие остроумия, чем подобие авторитетности...


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 18:03
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Уж лучше демонстрировать подобие остроумия, чем подобие авторитетности...


VD>Ну, и что же ты этого не делаешь?


Продемострировать остроумие не хвает способностей.
Не демострировать авторитетность хватает мозгов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.09 18:34
Оценка:
Здравствуйте, eao197, Вы писали:

E>Продемострировать остроумие не хвает способностей.

E>Не демострировать авторитетность хватает мозгов.

Последнее, на мой взгляд, не соответствует действительности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 18:56
Оценка:
Здравствуйте, eao197, Вы писали:

E>>> И Кнут с Виртом для них теоритики из прошлого века, над которыми практики могут позволить себе посмеяться.


I>>Кнут и Вирт это уже минимум позапрошлое поколение. ИТ-развивается слишком быстро.


E>Раньше я боялся, что монстры типа thesz со временем оставят меня без работы. Теперь я думаю, что мои опасения напрасны.


Это уже признак старости.
Re[11]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 19:31
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Раз тов.Ikemefula пытается оценивать тов.Кнута, значит он сам считает себя авторитетом. Интересно на каком основании.


VD>Не надо быть курицей, чтобы понимать толк в яичнице (с) Другой Авторитет (Марк Твен).


Во-первых, странно разрушать веру в авторитеты цитированием авторитетов.
Во-вторых, мы же здесь не аичницу обсуждаем, а степень доверия к словам Кнута о повторном использовании. Тем более, когда аргументация идет на уровне "он теоретик-алгоритмист из прошлого века, поэтому его словам грош цена". А судьи-то кто? Тут вот Ikemefula обвинил Кнута в том, что он не из индустрии. А ты сам-то из индустрии?

VD>Особо радует и то, что несогласные с мнением автора темы быстренько смешиваются с дерьмом путем зачисления в "моски тявкающие на слона".

VD>Скажи тебе не стыдно поддерживать подобные методы ведения дискуссии?

А ты по адресу обращаешься?

E>>Сдается мне, что TeX и METAFONT вовсе не рядовые проекты. Так что Кнут вполне себе практик, раз тот же самый TeX уже десятки лет успешно используется так, как есть.


VD>Не расскажешь сколько человек работало над этими проектами?

VD>А какие компоненты в нем были повторно использованы?
VD>И главное как работа над этими проектами может обосновать неверность компонентного подхода и верность подхода основанного на правке кода в любых условиях?

Какие бы ни были условия разработки TeX и METAFONT в них Кнут мог сделать именно такие выводы. Если кто-то из нынешних разработчиков (я или thesz) окажется в похожих условиях, может быть и он придет к таким же выводам.

VD>За одно я с удовольствием послушал бы о том как соотносится твой SObjectizer (или как там его правильно?) и идея решать все проблемы правкой кода?


В моих условиях, когда бОльшее количество кода пишется самостоятельно, rewriting оказывается дешевле reusing-а.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Кнут о компонентном программировании.
От: EvilChild Ниоткуда  
Дата: 13.07.09 19:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>А вот слушать его советы по ООД , компонентным технологиям я вряд ли стану, просто потому что есть более серьезные вещи, а у Кнута этого раз два и обчелся.


А кого стоит слушать по этим вещам?
now playing: Oliver Koletzki — Nascita Of The Monsters (Martin Patino Remix)
Re[12]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 19:44
Оценка:
Здравствуйте, eao197, Вы писали:

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


I>>Да, само собой, только Кнут говорит об этом со своей колокольни — как программист-одиночка. Это не значит, что он плохо писал, это значи, что его опыт нельзя применить в индустрии, потому что понадобятся сотни тысяч таких же кнутов.

I>>Программист-одиночка. В индустрии-ПО это меньше чем стат. погрешность.

E>Вы с VladD2 будете сильно удивлены, узнав, как много в индустрии было сделано одиночками и очень маленькими коллективами. Например, с чего начилался Google, PayPal, Apple, Borland...


Я то думал, откуда столько сервисов у гугла, а оказывается их кнутообразный одиночка пишет. И в Apple наверное точно так же, все версии системы одиночка пишет.

Убедительный аргумент, нечего и сказать даже.
Re[12]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 19:47
Оценка:
Здравствуйте, EvilChild, Вы писали:

I>>А вот слушать его советы по ООД , компонентным технологиям я вряд ли стану, просто потому что есть более серьезные вещи, а у Кнута этого раз два и обчелся.


EC>А кого стоит слушать по этим вещам?


http://rsdn.ru/summary/652.xml

Покажи мне там Кнута или покажи, что у Кнута есть посильнее в этом направлении. Спасибо.
Re[13]: Кнут о компонентном программировании.
От: EvilChild Ниоткуда  
Дата: 13.07.09 19:59
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EC>>А кого стоит слушать по этим вещам?


I>http://rsdn.ru/summary/652.xml


I>Покажи мне там Кнута или покажи, что у Кнута есть посильнее в этом направлении. Спасибо.


Какое отношение имеет Кнут к заданному мной вопросу?

Вообще это конечно мощно ставить в один ряд книги Кнута с такой попсой как рефакторинг, выполнение которого полностью автоматизируется средой разработки.
now playing: Oliver Koletzki — Nascita Of The Monsters (Ajello remix)
Re[14]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 20:45
Оценка:
Здравствуйте, EvilChild, Вы писали:

I>>http://rsdn.ru/summary/652.xml


I>>Покажи мне там Кнута или покажи, что у Кнута есть посильнее в этом направлении. Спасибо.


EC>Какое отношение имеет Кнут к заданному мной вопросу?


Ну ты влез в ветку где обсуждался Кнут.

EC>Вообще это конечно мощно ставить в один ряд книги Кнута с такой попсой как рефакторинг, выполнение которого полностью автоматизируется средой разработки.


В том то и дело, что нельзя ставить в ряд алгоритмы и проектирование(которое к рефакторингу не сводится).
Re[15]: Кнут о компонентном программировании.
От: EvilChild Ниоткуда  
Дата: 13.07.09 21:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EC>>Какое отношение имеет Кнут к заданному мной вопросу?


I>Ну ты влез в ветку где обсуждался Кнут.


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

EC>>Вообще это конечно мощно ставить в один ряд книги Кнута с такой попсой как рефакторинг, выполнение которого полностью автоматизируется средой разработки.


I>В том то и дело, что нельзя ставить в ряд алгоритмы и проектирование(которое к рефакторингу не сводится).

Ты как-то очень своеобразно читаешь написанное — я и не утверждал, что проектирование к рефакторингу сводится,
более того, я уверен, что рефакторинг имеет ценность и вне его.
now playing: Alex Young & Scella — Santiago De Chile
Re[16]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 21:46
Оценка:
Здравствуйте, EvilChild, Вы писали:

I>>В том то и дело, что нельзя ставить в ряд алгоритмы и проектирование(которое к рефакторингу не сводится).

EC>Ты как-то очень своеобразно читаешь написанное — я и не утверждал, что проектирование к рефакторингу сводится,
EC>более того, я уверен, что рефакторинг имеет ценность и вне его.

Давай сначала

I>А вот слушать его советы по ООД , компонентным технологиям я вряд ли стану, просто потому что есть более серьезные вещи, а у Кнута этого раз два и обчелся.

А кого стоит слушать по этим вещам


Ты ответ на свой вопрос получил или по приведенной ссылке ты только рефакторинг увидел ?
Re[18]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 14.07.09 09:05
Оценка:
Здравствуйте, EvilChild, Вы писали:

I>>Ты ответ на свой вопрос получил или по приведенной ссылке ты только рефакторинг увидел ?


EC>Получил, Кнута тебе больше показывать не надо?


Можешь оставить его себе.
Re[12]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.09 17:10
Оценка:
Здравствуйте, eao197, Вы писали:

E>Вы с VladD2 будете сильно удивлены, узнав, как много в индустрии было сделано одиночками и очень маленькими коллективами. Например, с чего начилался Google, PayPal, Apple, Borland...


Я не буду удивлен. К тому же даже коллектив из двух человек — это уже коллектив. И опыт одиночки в нем мало применим.

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

Возьмем к примеру IDE. Да, конечно, IDE для любого языка можно написать путем правки кода уже имеющейся реализации. Но стоит ли так поступать? Опыт IDE-строения показывает, что нет. Намного удобнее иметь IDE как компонент или их набор, оформляя интеграцию конкретного языка в виде отдельного компонент(а|ов). Не согласен?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.09 17:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>Раз тов.Ikemefula пытается оценивать тов.Кнута, значит он сам считает себя авторитетом. Интересно на каком основании.


Мне не надо быть авторитетом в гинекологии, чтобы понять, что лично твои мысли в области генеалогии ни стоят ни гроша. Для этого мне достаточно знать, что ты ею никогда не занимался.

Такая аналогия лучше поясняет суть, чем высказывание Твена про яичницу?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.07.09 18:20
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Раз тов.Ikemefula пытается оценивать тов.Кнута, значит он сам считает себя авторитетом. Интересно на каком основании.


VD>Мне не надо быть авторитетом в гинекологии, чтобы понять, что лично твои мысли в области генеалогии ни стоят ни гроша. Для этого мне достаточно знать, что ты ею никогда не занимался.


Вот и отлично. Как только я начну утверждать, что чье-то мнение в области гинекологии или генеалогии не стоят ни гроша, тогда ты с полным правом можешь выяснять степень моей квалификации в данных областях и поднимать меня на смех.

Пока же речь идет о программировании, то у меня есть возможность поступить так и с тобой, и с Ikemefula. Поскольку сильно сомневаюсь, что вы хотя бы понимаете о чем говорил Кнут (и в том, что вы прочитали его интервью).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Кнут о компонентном программировании.
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.09 18:24
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>>>Раз тов.Ikemefula пытается оценивать тов.Кнута, значит он сам считает себя авторитетом. Интересно на каком основании.


VD>>Мне не надо быть авторитетом в гинекологии, чтобы понять, что лично твои мысли в области генеалогии ни стоят ни гроша. Для этого мне достаточно знать, что ты ею никогда не занимался.


E>Вот и отлично. Как только я начну утверждать, что чье-то мнение в области гинекологии или генеалогии не стоят ни гроша, тогда ты с полным правом можешь выяснять степень моей квалификации в данных областях и поднимать меня на смех.


Алё! Меня не слышат? Я утверждаю, что твое мнение в гениклогии ни стоит ни гроша?
Я не прав?
Я не могу это утверждать?

E>Пока же речь идет о программировании, то у меня есть возможность поступить так и с тобой, и с Ikemefula. Поскольку сильно сомневаюсь, что вы хотя бы понимаете о чем говорил Кнут (и в том, что вы прочитали его интервью).


Ты можешь поступать как хочешь. Только не со мной или с кем-то, а с собой. Твои мозговедческие способности мало кого интересуют.
То что там говорит Кнут мне совершенно все равно. Я обсуждаю текущую тему. Если я ее не так понял, то это целиком и полностью проблема автора этой темы, а не моего понимания или не понимания кнута.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.07.09 18:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я удивляюсь другому..., тому, как факт наличия одиночек или маленьких коллективов может оправдывать отказ от компонентного подхода в пользу правки кода (во всех случаях).


А я удивляюсь тому, как вы воспринимаете слова Кнута. Он же там английским по белому говорит:

To me, "re-editable code" is much, much better than an untouchable black box or toolkit.


Для него! Причем здесь все случаи? Кнут занимается своими задачами, довольно специфическими. На основании своего опыта он пришел к такому выводу. Имеет право? Имеет. Может ли кто-нибудь из присутствующих оказаться в схожих условиях? Да запросто.

VD>Возьмем к примеру IDE.


А возмем, к примеру, не IDE. Вот в где-то в 2000-2002 один из французкий производителей SmartCard занимался разработкой и реализацией т.н. GlobalPlatform (если не путаю название) -- специальной стандартизированной начинки для SmartCard для загрузки приложений, конфиденциальной информации и пр. лабуды на SmartCard-ы. На тот момент была доступна только спецификация этой платформы и несколько тестовых карт. Никаких готовых инструментов, зато большой ажиотаж и стремление обогнать всех с разработке приложений для этой платформы. Никаких компонентов, никаких тулкитов -- только примеры кода от производителя и собственная голова. И таки да, в таких условиях re-editable используется на всю катушку.

Поэтому лично мне пофигу, что 95% программистов компонентный подход нужен каждый день. Поскольку лично мне приходилось заниматься темами, в которых не было готовых компонентов. Вообще.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.07.09 18:51
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Во-вторых, мы же здесь не аичницу обсуждаем, а степень доверия к словам Кнута о повторном использовании.


VD>Нет вы здесь разводите флуд и пытаетесь загнобить ни в чем не повинного парнишку. А в качестве "аргументации" используете "претензии" вроде "Ты не курица, значит толк в яичнице не знаешь...".


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

E>> Тем более, когда аргументация идет на уровне "он теоретик-алгоритмист из прошлого века, поэтому его словам грош цена". А судьи-то кто? Тут вот Ikemefula обвинил Кнута в том, что он не из индустрии. А ты сам-то из индустрии?


VD>Судьи образованные люди знающие толк как в компонентном подходе, так и в правке кода, и при этом, заметь, не прикрывающиеся авторитемами и не боящиеся иметь свое мнение на некоторые темы, не совпадающее с мнением некоторых авторитетов (и мнящих себя таковыми).


Тем не менее, раз для Ikemefula Кнут не из индустрии, то и ты для него не из индустрии. Ты ведь делаешь еще более маргинальные разработки, чем Кнут

VD>В общем, твои нападки не только некорректны, но еще и смехотворны. Давай развернем ситуацию. Я приведу тебе какую-нибудь цитату более-менее известного человека, в которой тот будет поддерживать компонентный подход, ты будешь пытаться как-то парировать это, а я сидеть и подначивать, что мол "кто ты такой чтобы ..."? Ну, в общем, буду в вашем стиле проезжаться по вашим личностям. Давай?


Так зачем тебе я? Ты все так хорошо выдумал, придумывай дальше -- как и что я буду возражать. А мы все почитаем, посмеемся.

VD>Ну, и замечательно. Это его мнение. Только они ни стоят ни гроша, так как это очень частный опыт одного программиста одиночки работавшего над конкретной задачей. В его условиях возможно выгоды от компонентного подхода не было. Но кКогда программист начинает работать в команде или над большим проектом включающим множество типовых задач вроде создания GUI, то компонентный подход выходит на первую роль, а идея решить проблему путем правки чужого кода для решения частной задачи, становится не такой уж и хорошей.


В словах Кнута нет ничего, чтобы противоречило этому утверждению.

VD>Если бы он сказал — "В некоторых условиях лучше поправить код под свои нужды, а не искать готовое решение.", то я бы с ним согласился.


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

VD>>>За одно я с удовольствием послушал бы о том как соотносится твой SObjectizer (или как там его правильно?) и идея решать все проблемы правкой кода?


E>>В моих условиях, когда бОльшее количество кода пишется самостоятельно, rewriting оказывается дешевле reusing-а.


VD>Если утверждение сделанное в теме верно, то не нужным становится сам твой SObjectizer так как всем проще будет не использовать его, а "поправить его код для своих нужд".


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.07.09 07:27
Оценка:
Здравствуйте, eao197, Вы писали:
E>Для него! Причем здесь все случаи? Кнут занимается своими задачами, довольно специфическими. На основании своего опыта он пришел к такому выводу. Имеет право? Имеет. Может ли кто-нибудь из присутствующих оказаться в схожих условиях? Да запросто.
А мне вот кажется, что to me здесь вовсе не означает "для меня". Это означает "с моей точки зрения".

Если бы он хотел сказать "в моей работе профессионала-одиночки, ...", он бы так и сказал. Это же Кнут — ты его книги читал? Педантизм в каждой фразе.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.07.09 07:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

E>>Для него! Причем здесь все случаи? Кнут занимается своими задачами, довольно специфическими. На основании своего опыта он пришел к такому выводу. Имеет право? Имеет. Может ли кто-нибудь из присутствующих оказаться в схожих условиях? Да запросто.

S>А мне вот кажется, что to me здесь вовсе не означает "для меня". Это означает "с моей точки зрения".

"Для меня" или "с моей точки зрения", но он явно оговаривает, что у читателя может быть совершенно другой взгляд на вещи, который Кнут вряд ли сможет поколебать:

If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: untouchable игнорируется?
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.07.09 07:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Если бы он хотел сказать "в моей работе профессионала-одиночки, ...", он бы так и сказал. Это же Кнут — ты его книги читал? Педантизм в каждой фразе.


Еще мне кажется, что в высказывании Кнута совершенно игнорируется прилагательное untouchable. Так же как и "black box":

much better than an untouchable black box or toolkit



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.07.09 10:20
Оценка:
Здравствуйте, eao197, Вы писали:


E>Для него! Причем здесь все случаи? Кнут занимается своими задачами, довольно специфическими. На основании своего опыта он пришел к такому выводу. Имеет право? Имеет. Может ли кто-нибудь из присутствующих оказаться в схожих условиях? Да запросто.


Да, имеет, с вероятностью ниже стат. погрешности.

E>Поэтому лично мне пофигу, что 95% программистов компонентный подход нужен каждый день. Поскольку лично мне приходилось заниматься темами, в которых не было готовых компонентов. Вообще.


Ты думаешь 95% используют готовые компоненты ?


E>Никаких готовых инструментов, зато большой ажиотаж и стремление обогнать всех с разработке приложений для этой платформы. Никаких компонентов, никаких тулкитов -- только примеры кода от производителя и собственная голова. И таки да, в таких условиях re-editable используется на всю катушку.


Ну да, когда нет компонентов, тулкитов и тд. их надо написать.
Re[15]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.07.09 10:26
Оценка:
Здравствуйте, Ikemefula, Вы писали:

E>>Поэтому лично мне пофигу, что 95% программистов компонентный подход нужен каждый день. Поскольку лично мне приходилось заниматься темами, в которых не было готовых компонентов. Вообще.


I>Ты думаешь 95% используют готовые компоненты ?


А по вашим оценкам, сколько используют готовые компоненты?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Кнут о компонентном программировании.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.07.09 11:17
Оценка:
Здравствуйте, eao197, Вы писали:

E>>>Поэтому лично мне пофигу, что 95% программистов компонентный подход нужен каждый день. Поскольку лично мне приходилось заниматься темами, в которых не было готовых компонентов. Вообще.


I>>Ты думаешь 95% используют готовые компоненты ?


E>А по вашим оценкам, сколько используют готовые компоненты?


Около 100% включая и Кнута.
Re[17]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.07.09 11:20
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Ты думаешь 95% используют готовые компоненты ?


E>>А по вашим оценкам, сколько используют готовые компоненты?


I>Около 100% включая и Кнута.


Такое впечатление, что по вашему и libc является компонентом.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 15.07.09 14:16
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Смотри. Если ты написал тип правильно, то, согласно Curry-Howard isomorphism, если функции, использующие этот тип, компилируются, то это будет доказательством того, что тип написан верно.


Имхо, это слишком общее утверждение...
Функции могут компилироваться, но работать неправильно, или использовать только часть типа, а не весь его целиком (через ПМ), тип может быть не определенным до конца, и т.д.
Слишком много вариантов мне видится, чтоб вот так вот утверждать, что просто компилируемости достаточно.

L>Написать тип неправильно, конечно, можно тоже, но тогда у тебя это выловится в дальнейшем, когда ты попытаешься с этим типом работать (ожидая от типа, что он описывает определённый граничный случай).


Ну так а если он его не описывает и подходит к нему так же, как ко всем остальным?
Все будет замечательно компилироваться и работать, просто результаты этой работы заказчика не устроят, и в следующей версии придется либо переделать этот тип (что лучше), либо воспользоваться подходом Кнута и поредактировать конкретное место, которое заметил заказчик (что хуже).
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[11]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 15.07.09 14:34
Оценка:
Здравствуйте, thesz, Вы писали:

J>>Ну что значит — не получится, если в момент написания они тебе попросту неизвестны?

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

T>Это такой сферический конь в вакууме, да?

T>Типа, если мы чего не знаем, то мы всегда ничего не знаем.

Почему всегда? Я же написал про первую версию.
Ко второй версии ты это уже, очевидно, знаешь, иначе программа уже правильна и незачем вторую версию выпускать.

T>Вот, в Хаскеле появились ассоциированные типы. Стал ли Хаскель новым языком?

Я не знаю, я не специалист по Хаскелю.
Но если Хаскель для этого доработали — то да, стал (ЕМНИП, программы на GHC не будут компилироваться обычным хаскелем-98, так что в этом смысле GHC — это новый язык, если, конечно, там дело не ограничивается одной только библиотекой).

T>Приведённый мной код и Си, и Си++.

Каким боком это С, если в С шаблонов нет?
Да и в С++ у тебя это просто обычная типизация разными несвязанными типами, с тем же успехом ты можешь вместо FILE<content> и FILE<text_file> написать FILE_content и FILE_text_file, ничего не изменится.

J>>Думаю, это от языка зависит. В том, который под зависимые типы заточен — в том мало будет дополнительной писанины, а в том, который не заточен — это либо очень многословно, либо вообще нереализуемо.


T>Ура. По-моему, есть подвижка/

э? ты заметил слово "нереализуемо"?

T>>>Минус-плюс я могу в параметр внести, видно будет.

J>>Ну вот о чем и речь, что придется весь текст функции засунуть в тип.

T>Внутренние связи между ограничениями не будут видны в типе. Поэтому я отвечаю резким "нет".

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

J>>После чего у тебя сложность типа будет сравнима со сложностью кода функции, и если код сильно кучерявый, то и тип будет такой же.

T>Опять же, нет.
Почему?

J>>И этот тип придется тестировать так же, как ты тестировал бы функцию без этого типа.

T>И снова нет.
Почему?

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

T>>>Правильно, функциональным тестом. Не юнит-тестом, в последнем смысла нет.
J>>И каждый раз функциональный тест руками проделывать? А ты точно не забудешь проверить все граничные случаи, что ты их правильно запрограммировал? Их же все, по-хорошему, надо проверить. Это и есть юнит-тесты.

T>Граничные условия отдельных функций проверяются типами функций.

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

T>>>Спецификация на машинном языке — на той же Агде или на ACL2, — опирается на всю мощь библиотеки машинного языка, которую не надо воспроизводить руками.

J>>Можешь развернуть этот тезис?

T>Да чего разворачивать. Вот стандартная библиотека Agda2: http://www.cs.nott.ac.uk/~nad/repos/lib/src/


T>В ней присутствуют: Алгебры, Категории, Операции по индукции, Коиндукция (для всякого рода бесконечных вещей), Отношения (например, типы, индексированные отношениями) и прочее.

T>Берешь и используешь.
ОК, по Агде спорить не готов.
Допускаю, что там все шоколадно.

T>>>Потому, что когда человек пишет программу, он рассуждает о программе статически, и никак иначе.

J>>Можешь развернуть и этот тезис?

T>У человека, рассуждающего о программе, есть только её текст. Иногда логи, которые показывают события, происходившие в отдельных частях программы, но в основном только текст.


T>Человек выписывает статические связи между участками программы, поскольку текст статичен. Даже если в динамике код программы будет изменяться, то все его изменения должны быть предсказуемы статически.


T>Больше мне сказать нечего.


Хм... Мало что понял, сорри.
Если только придраться к тому, что у человека на руках только текст программы, а я видел очень мало людей, способных уместить у себя в голове весь текст программы, чтобы смочь о нем рассуждать.
Обычно у человека есть нечто вроде спеков в каком-то полусыром и смутном виде, и программу он уже пишет, основываясь на них и своем интуитивном представлении о том, что же нужно.

T>Если я неправильно написал типы, то у меня будут затруднения с выражением своих мыслей в других частях программы. Программа просто не будет написана.

T>Она На Хаскеле пишется с трудом, если типы плохие, что уж говорить про зависимые типы.
Можешь привести пример, чтоб было понятно, как именно будут выглядеть "затруднения с выражением своих мыслей в других частях программы"?

T>Тесты калибра меньше функциональных не нужны.

пока не убедил.
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[18]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 03:59
Оценка:
Здравствуйте, eao197, Вы писали:
E>Такое впечатление, что по вашему и libc является компонентом.
А как же.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 05:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

E>>Такое впечатление, что по вашему и libc является компонентом.
S>А как же.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 06:01
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну, если под компонентным программированием начинает пониматься использование библиотек уровня libc, то аргументы о том, что Кнут ничего не понимает в компонентах вообще идут лесом.

Таких аргументов в ветке не было. Были аргументы про то, что у Кнута недостаточно опыта промышленной разработки.
То есть не такой, когда один человек ваяет TeX десять лет, имея только общие представления о том, как и что должно быть, а такой разработки, где 100 человек делают TeX за 1 год, с предсказуемым результатом и обязанностью отчитываться о потраченных ресурсах и достигнутом прогрессе.

Никаких сомнений в том, что Кнут в курсе, что такое компоненты, и имеет опыт повторного использования, лично у меня нет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 06:34
Оценка:
Здравствуйте, eao197, Вы писали:

E>Почему-то при этом Кнут отваживается платить за найденные ошибки в своих программах, а промышленные производители ПО -- нет.

Кому здесь непонятны причины таких различий в подходах?

E>Но представители той самой промышленности с иронией насмехаются над подходами к программированию у Кнута.

E> Надо полагать, на основании того, что умело отчитываются о потраченных ресурсах и достигнутом результате.
Надо полагать, на основании того, что в их деятельности Кнутовский подход неприменим.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Кнут о компонентном программировании.
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 07:29
Оценка:
E>И кто сказал, что повторное использование компонентов -- это исключительно прерогатива ООП? Модули и компоненты активно развивались еще во времена процедурного и структурного программирования (см.например Modula-2 и Ada83).

Это была недолгая эпоха Компонентного программирования. Немного после процедурного. Делфи именно оттуда свои косяки несёт.
И при чём здесь Кнут? Совпадение по времени?

VD>>Кнут конечно человек известный, но как алгоритмист, а отнюдь не как архитектор ПО.


E>Сдается мне, что TeX и METAFONT вовсе не рядовые проекты. Так что Кнут вполне себе практик, раз тот же самый TeX уже десятки лет успешно используется так, как есть.


Практик и архитектор — немного разные понятия.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[15]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 08:12
Оценка:
Здравствуйте, COFF, Вы писали:

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


COF>Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне"


Типа того.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 08:21
Оценка:
Здравствуйте, COFF, Вы писали:
COF>Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне"
Ну, только не ему в ответ, а адресуясь к работникам сети Подорожник, и комментируя вопросы приготовления обеда суммарной стоимостью менее 700 евро.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 08:42
Оценка:
Здравствуйте, 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++.
Re: Кнут о компонентном программировании.
От: Baudolino  
Дата: 16.07.09 08:51
Оценка:
T>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


Это ересь по одной простой причине: десятки слегка отличающихся копипаст сложнее поддерживать. Код без ошибок бывает редко, и если ошибка найдена, то придется проверять на её наличие и исправлять все копии. Так что, no thanks, лучше уж наследование и полиморфизм.
Re[29]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 10:07
Оценка:
Здравствуйте, 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++.
Re[12]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 16.07.09 10:08
Оценка:
Здравствуйте, jazzer, Вы писали:

L>>Смотри. Если ты написал тип правильно, то, согласно Curry-Howard isomorphism, если функции, использующие этот тип, компилируются, то это будет доказательством того, что тип написан верно.


J>Имхо, это слишком общее утверждение...

...
J>Слишком много вариантов мне видится, чтоб вот так вот утверждать, что просто компилируемости достаточно.

Компилируемости достаточно для доказательства инвариантов, описанных в типе.

L>>Написать тип неправильно, конечно, можно тоже, но тогда у тебя это выловится в дальнейшем, когда ты попытаешься с этим типом работать (ожидая от типа, что он описывает определённый граничный случай).


J>Ну так а если он его не описывает и подходит к нему так же, как ко всем остальным?


Тут же вроде разговор идёт о unit test vs DT? Так вот, если он его (граничный случай) не описывает, то неважно где он его не описывает — в юнит тесте или типе, согласен? А если описывает в типе, то юнит тест уже не нужен, т.к. компилируемости достаточно для доказательства.

Я чего здесь не пойму — если программист забыл описать инвариант в DT, то почему в юнит тесте он должен его вспомнить?

Возможно, дело в том, что в юнит тестах часто тестируются следствия инвариантов, а не сами инварианты? Может это смущает?
Re[31]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 10:44
Оценка:
Здравствуйте, IB, Вы писали:

E>>На вскидку сейчас вспоминается PalmOS 6.0 на разработку которой, т.е. на фигню в чистом виде, было потрачено несколько лет, но потом все было выброшено коту под хвост. Да и путь от Windows 1.0 к Windows NT 3.51/Windows95 был очень неспешным.

IB>Ты как-то очень ловко TeX с OS сравниваешь, это продукты по сложности не сопоставимые, так что не надо передергивать.

Ну потому, что не знаю уж как привлечь внимание к тому факту, что Кнут сделал действительно хороший продукт с очень небольшими трудозатратами (ведь 12 человеко-лет это не много совсем). Понятно, что просто так посадить 12 человек и получить то же самое за год не получится. Но ведь когда Кнут писал свой TeX уже были альтернативы, в том числе и коммерческие. Но все равно TeX их уделал и стал стандартом де-факто в области научной литературы. И вместо того, чтобы признать, что опыт на самом деле заслуживает внимания, начинается -- да сроков не было, да отчитываться не нужно было, да он не архитектор. Как будто TeX -- это 15 строк кода. И там не нужно было ничего проектировать, и на модули разбивать, и сторонние компоненты прикручивать (а ведь прикручивалась, например, система ввода-вывода от Guy Steele и алгоритм переносов, написанный Frank Liang). Да думаю и много еще чего, поскольку поднять такую махину вряд ли можно было только в одиночку.

E>>Не говоря уже о том, почему слова Кнута воспринимаются как призыв к глобальному code rewrite.

IB>Вот это хороший вопрос. Потому что складывается впечатление, что адвокаты кнута настаивают именно на такой трактовке.

У меня складывается обратное впечатление.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Кнут о компонентном программировании.
От: jazzer Россия Skype: enerjazzer
Дата: 16.07.09 11:31
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Компилируемости достаточно для доказательства инвариантов, описанных в типе.


L>Тут же вроде разговор идёт о unit test vs DT? Так вот, если он его (граничный случай) не описывает, то неважно где он его не описывает — в юнит тесте или типе, согласен? А если описывает в типе, то юнит тест уже не нужен, т.к. компилируемости достаточно для доказательства.


L>Я чего здесь не пойму — если программист забыл описать инвариант в DT, то почему в юнит тесте он должен его вспомнить?


L>Возможно, дело в том, что в юнит тестах часто тестируются следствия инвариантов, а не сами инварианты? Может это смущает?


Понятно, что если инвариант описан, то компилируемости достаточно.
Вопрос немножко в другом: как ты убедишься, что ты описал инвариант правильно и он делает то, что нужно, а не только то, что ты написал? Что не перепутал минус с плюсом или что-то в этом роде?
Это можно сделать только альтернативным методом, и на роль этого метода отлично подходят юнит-тесты.
Хотя, конечно же, юнит-тестом ты доказать ничего не сможешь (хотя это тоже зависит, можно извернуться и написать юнит-тест, который проверит твой инвариант с другой стороны), но по крайней мере проверишь очевидные следствия, которые сразу же тебе укажут на ошибку, если таковая имеется.
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[32]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 16.07.09 12:01
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну потому, что не знаю уж как привлечь внимание к тому факту, что Кнут сделал действительно хороший продукт с очень небольшими трудозатратами (ведь 12 человеко-лет это не много совсем).

Для такого продукта как TeX — это ужастно много.

E> Но все равно TeX их уделал и стал стандартом де-факто в области научной литературы.

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

E> И вместо того, чтобы признать, что опыт на самом деле заслуживает внимания,

Внимания он безусловно заслуживает, но вот воспринимать его как руководство к действию и строить свою разработку по тому же принципу — точно не стоит.

E> Да думаю и много еще чего, поскольку поднять такую махину вряд ли можно было только в одиночку.

Все верно, так что там про компонентное программирование?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[33]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 12:08
Оценка:
Здравствуйте, IB, Вы писали:

E>>Ну потому, что не знаю уж как привлечь внимание к тому факту, что Кнут сделал действительно хороший продукт с очень небольшими трудозатратами (ведь 12 человеко-лет это не много совсем).

IB>Для такого продукта как TeX — это ужастно много.

Обоснуешь?

E>> И вместо того, чтобы признать, что опыт на самом деле заслуживает внимания,

IB>Внимания он безусловно заслуживает, но вот воспринимать его как руководство к действию и строить свою разработку по тому же принципу — точно не стоит.

Поэтому имеет смысл высказываться вот в таком стиле? http://www.rsdn.ru/forum/philosophy/3464879.1.aspx
Автор: Ikemefula
Дата: 12.07.09


E>> Да думаю и много еще чего, поскольку поднять такую махину вряд ли можно было только в одиночку.

IB>Все верно, так что там про компонентное программирование?

To me, "re-editable code" is much, much better than an untouchable black box or toolkit.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 12:40
Оценка:
Здравствуйте, IB, Вы писали:

E>> И вместо того, чтобы признать, что опыт на самом деле заслуживает внимания,

IB>Внимания он безусловно заслуживает, но вот воспринимать его как руководство к действию и строить свою разработку по тому же принципу — точно не стоит.

Думаю, что опыт Кнута уже давно оказался восстребованным (хотя под соусом опыта Торвальдса) -- сейчас он активно используется в виде "спонсирования OpenSource разработок". Вкладывает, например, HP деньги в спонсирование разработки Linux-а (без сроков и отчетов), а затем выигрывает в борьбе с Sun на поставку оборудования крупным заказчикам. Или IBM спонсирует Eclipse, чтобы затем его использовать с выгодой для себя.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 16.07.09 13:07
Оценка:
Здравствуйте, jazzer, Вы писали:

L>>Возможно, дело в том, что в юнит тестах часто тестируются следствия инвариантов, а не сами инварианты? Может это смущает?


J>Понятно, что если инвариант описан, то компилируемости достаточно.

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

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

J>Это можно сделать только альтернативным методом, и на роль этого метода отлично подходят юнит-тесты.


Для этого DT подходят тоже — не забывай, мы можем DT индексировать значениями, т.е. результами выполнения того же filter
Вот пример из туториала

-- тут мы пишем теорему, обрати внимание на использование filter в типе.
lem-filter : {A : Set}(p : A -> Bool)(xs : List A) ->
             filter p xs ⊆ xs

-- а тут доказываем
lem-filter p []        = stop
lem-filter p (x :: xs) with p x
... | true = keep (lem-filter p xs)
... | false = drop (lem-filter p xs)


J>Хотя, конечно же, юнит-тестом ты доказать ничего не сможешь


А с DT — можешь
Re[34]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 16.07.09 13:40
Оценка:
Здравствуйте, eao197, Вы писали:

E>Думаю, что опыт Кнута уже давно оказался восстребованным (хотя под соусом опыта Торвальдса) -- сейчас он активно используется в виде "спонсирования OpenSource разработок".

Не надо еще и OS к Кнуту приплетать. По факту TeX как был сугубо исследовательским экспирементом, так им и остался, в общей же массе Open Source, за редким исключением, сливает проприетарному софту по всем параметрам, включая стоимость сопровождения, удобство использования, удовлетворение потребностей заказчика и общее качество.

E> Вкладывает, например, HP деньги в спонсирование разработки Linux-а (без сроков и отчетов),

С чего ты взял что без сроков и отчетов? Эти ребята очень хорошо считают деньги.
И вообщ, эти вот лозунги за Open Source — они сейчас к чему?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[35]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 13:46
Оценка:
Здравствуйте, IB, Вы писали:

IB>Не надо еще и OS к Кнуту приплетать.


Бытует мнение, что OpenSource начался вовсе не с Linuх-а, и даже не с GNU. С таких разработок, как TeX.

IB>По факту TeX как был сугубо исследовательским экспирементом, так им и остался


По какому факту?

IB>С чего ты взял что без сроков и отчетов?


Можешь продемонстрировать расписание релизов для ядра Linux-а? И указать какие последствия имели срывы сроков при разработке ядра Linux-а?

IB>И вообщ, эти вот лозунги за Open Source — они сейчас к чему?


К тому, что написанное Кнутом про re-editable является основой OpenSource. О чем я уже сказал. И в OpenSource это не считается ересью.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 13:56
Оценка:
Здравствуйте, IB, Вы писали:

E>>Обоснуешь?

IB>По сложности TeX сопоставим с относительно простой системой лэйаута, которую можно реализовать за пару человеколет.

Странно, что не человекомесяцев. Ах ну да, тогда же не было Windows c .NET. Простите, запамятовал.

E>>Поэтому имеет смысл высказываться вот в таком стиле? http://www.rsdn.ru/forum/philosophy/3464879.1.aspx
Автор: Ikemefula
Дата: 12.07.09

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

И с тем, что "прислушиваться нужно очень осторожно", и с тем, что "это еще мягко сказано". Особенно с последним.

Отдельно заслуживает упоминания аргументация -- мол Кнут не разбирается в компонентном программировании, поскольку не написал книг про ООП и КОП. Однако, если такой аргумент применить к критикам Кнута, то их мнение о КОП так же ничего не стоит, поскольку они так же ничего подобного не написали.

E>>

E>>To me, "re-editable code" is much, much better than an untouchable black box or toolkit.

IB>Так как это согласуется с тем, что он, по твоим же словам, переиспользовал кучу black box-ов?

Например, тем, что нахлебался с untouchable black box-а и пришел к выводу, что re-editable гораздо лучше.

IB>Далее, тут все спорщики не учитывают, что же на самом деле значит термин "re-editable code". Так вот сдается мне, что это не просто код, к которому у тебя есть исходники, которые ты можешь поправить под свои нужды — это бред, такой подход в жизни не работает.


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

IB>А это как раз тот код, который спроектирован в лучших традициях компонентного программирования, OCP и других правильных вещей, где трогая одну часть, ты уверен, что остальное не сломается, и можешь выкинуть одну часть, и подставить туда свою реализацию, таки используя остальное как black box. Вот это на самом деле и есть re-editable code.


Интересное мнение. Явно не совпадающее ни с моей, ни с мнением тех, с кем я до сих пор спорил. Но имеешь право. Так вот, с этой позиции к словам Кнута так же нужно относиться очень-очень осторожно?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[36]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 16.07.09 15:14
Оценка:
Здравствуйте, eao197, Вы писали:

E>Странно, что не человекомесяцев.

Нет, не странно, просто опыт есть. И да, это скорее оценка сверху.

E>И с тем, что "прислушиваться нужно очень осторожно", и с тем, что "это еще мягко сказано". Особенно с последним.

То есть, надо внимать и безаговорочно следовать.

E>Отдельно заслуживает упоминания аргументация -- мол Кнут не разбирается в компонентном программировании, поскольку не написал книг про ООП и КОП. Однако, если такой аргумент применить к критикам Кнута, то их мнение о КОП так же ничего не стоит, поскольку они так же ничего подобного не написали.

Это аргументация такого же уровня, что Кнут — крут немеряно и поэтому его нужно слушать не задумываясь над природой и применимостью его советов.

E>Например, тем, что нахлебался с untouchable black box-а и пришел к выводу, что re-editable гораздо лучше.

Так что ж он их не выкинул и не переписал все без черных ящиков?

E>Ну конечно, я живу в параллельной реальности.

Похоже на то.

E>Интересное мнение. Явно не совпадающее ни с моей, ни с мнением тех, с кем я до сих пор спорил. Но имеешь право. Так вот, с этой позиции к словам Кнута так же нужно относиться очень-очень осторожно?

Безусловно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[36]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 16.07.09 15:14
Оценка:
Здравствуйте, eao197, Вы писали:

E>Бытует мнение, что OpenSource начался вовсе не с Linuх-а, и даже не с GNU. С таких разработок, как TeX.

Да пофиг с чего оно началось

E>По какому факту?

По факту качества продуктов, удовлетворенности пользователей, удобству интерфейса и всем остальным.

E>Можешь продемонстрировать расписание релизов для ядра Linux-а? И указать какие последствия имели срывы сроков при разработке ядра Linux-а?

То что не разглашены детали дотаций HP, не значит, что их не было.

E>К тому, что написанное Кнутом про re-editable является основой OpenSource.

Это еще одна конспирологическая теория?

E>И в OpenSource это не считается ересью.

Это считается ересью везде, где приходится отвечать за качества кода, в не зависимости от того, открытый он или проприетарный.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[37]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 15:29
Оценка:
Здравствуйте, IB, Вы писали:

E>>Странно, что не человекомесяцев.

IB>Нет, не странно, просто опыт есть. И да, это скорее оценка сверху.

Ты делал аналог TeX?

E>>И с тем, что "прислушиваться нужно очень осторожно", и с тем, что "это еще мягко сказано". Особенно с последним.

IB>То есть, надо внимать и безаговорочно следовать.

Где я это утверждал?

E>>Отдельно заслуживает упоминания аргументация -- мол Кнут не разбирается в компонентном программировании, поскольку не написал книг про ООП и КОП. Однако, если такой аргумент применить к критикам Кнута, то их мнение о КОП так же ничего не стоит, поскольку они так же ничего подобного не написали.

IB>Это аргументация такого же уровня, что Кнут — крут немеряно и поэтому его нужно слушать не задумываясь над природой и применимостью его советов.

Правильно. Но ведь я нигде не доказывал, что Кнута нужно слушать без оглядки. Всего лишь говорил, что к его словам нужно прислушиваться, а не отмахиваться. Он того заслуживает.

E>>Например, тем, что нахлебался с untouchable black box-а и пришел к выводу, что re-editable гораздо лучше.

IB>Так что ж он их не выкинул и не переписал все без черных ящиков?

Где он призывал все переписывать?

E>>Интересное мнение. Явно не совпадающее ни с моей, ни с мнением тех, с кем я до сих пор спорил. Но имеешь право. Так вот, с этой позиции к словам Кнута так же нужно относиться очень-очень осторожно?

IB>Безусловно.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[37]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 15:37
Оценка:
Здравствуйте, IB, Вы писали:

E>>По какому факту?

IB>По факту качества продуктов, удовлетворенности пользователей, удобству интерфейса и всем остальным.

О как странно, но большое количество документации разного рода до сих пор делается в разных вариантах TeX-а.

E>>Можешь продемонстрировать расписание релизов для ядра Linux-а? И указать какие последствия имели срывы сроков при разработке ядра Linux-а?

IB>То что не разглашены детали дотаций HP, не значит, что их не было.

Дотации были. Я думаю, и их размеры не представляют тайны. Тот же IBM в начале 2000-х заявлял об инвестициях в Linux одного миллиарда долларов.

Но где же конкретные сроки и отчеты, на которых настаивают труженники коммерческиого программирования?

Между тем, компании используют опыт разработки на основе одиночек типа Кнута на полную катушку. Тот же Google нанял Гвидо ван Россума. Теперь он за деньги Google развивает Python.

E>>К тому, что написанное Кнутом про re-editable является основой OpenSource.

IB>Это еще одна конспирологическая теория?

Нет, просто опыт есть.

Ты еще предложения товарища Столлмана почитай про свободное ПО, там еще круче, чем re-editable.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 16.07.09 18:22
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ты делал аналог TeX?

Нет, просто видел, как делают другие.

E>Где я это утверждал?

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

E>Правильно. Но ведь я нигде не доказывал, что Кнута нужно слушать без оглядки. Всего лишь говорил, что к его словам нужно прислушиваться, а не отмахиваться. Он того заслуживает.

Никто от них не отмахиваются. Просто прислушиваясь — учитывают специфику и условия применимости кнутовских советов. И с учетом этого делают совершенно закономерные выводы.

E>Где он призывал все переписывать?

Он утверждает, что без блек-боксов лучше, но почему-то сам не следует своим советам, если принять твою точку зрения.
Мы уже победили, просто это еще не так заметно...
Re[38]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 16.07.09 18:29
Оценка:
Здравствуйте, eao197, Вы писали:

E>О как странно, но большое количество документации разного рода до сих пор делается в разных вариантах TeX-а.

Агащазблин. В академической среде, по превычке?

E>Но где же конкретные сроки и отчеты, на которых настаивают труженники коммерческиого программирования?

Ты думаешь они давали дотации просто так? Да, только на такой наивности и выезжает опенсорс.. )

E>Между тем, компании используют опыт разработки на основе одиночек типа Кнута на полную катушку. Тот же Google нанял Гвидо ван Россума. Теперь он за деньги Google развивает Python.

Конечно используют. Тот же Джим Грей отпахал на MS столько что мало не покажется и вообще, MS инвестирует в таких одиночек больше чем гугл и IBM вместе взятые.
И что?

E>Нет, просто опыт есть.

Опыт чего? Реэдитить код в одно лицо? Это байта ради.

E>Ты еще предложения товарища Столлмана почитай про свободное ПО, там еще круче, чем re-editable.

Не удивительно, это вообще известный звездобол и конспиролог.
Мы уже победили, просто это еще не так заметно...
Re[39]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 18:41
Оценка:
Здравствуйте, IB, Вы писали:

E>>Ты делал аналог TeX?

IB>Нет, просто видел, как делают другие.

Это на тему "Карузо не такой уж великий певец..."

E>>Где я это утверждал?

IB>Есть три варианта — полностью игнорить, осторожно прислушиваться, безоговорочно следовать. Очевидно ты против первого, как выяснилось и против второго тоже — остается третье.

Есть четыре варианта: полностью игнорить, осторожно прислушиваться, прислушиваться, безоговорочно следовать.
Я за вариант "прислушиваться".

E>>Где он призывал все переписывать?

IB>Он утверждает, что без блек-боксов лучше, но почему-то сам не следует своим советам, если принять твою точку зрения.

Например, как он не следует?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 18:58
Оценка:
Здравствуйте, IB, Вы писали:

E>>О как странно, но большое количество документации разного рода до сих пор делается в разных вариантах TeX-а.

IB>Агащазблин. В академической среде, по превычке?

Вот три документа, которые я скачал для прочтения в последнее время:

http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/beautiful.pdf — Beautiful concurrency, Simon Peyton Jones, Microsoft Research, Cambridge, May 1, 2007

http://parlab.eecs.berkeley.edu/sites/all/parlab/files/lithe-sosp09.pdf — Enabling Software Composability for the Manycore Era, Heidi Pan, Benjamin Hindman, and Krste Asanovic.

http://www.cs.brown.edu/~levyossi/Pubs/spaa09-scalablerwlocks.pdf — Scalable Reader-Writer Locks, Yossi Lev (Brown University and Sun Microsystems Laboratories), Victor Luchangco (Sun Microsystems Laboratories), Marek Olszewski (Massachusetts Institute of Technology and Sun Microsystems Laboratories)

Первые два были сформированы с помощью dvips, третий -- LaTeX. Ты можешь считать, что все это чисто академическая среда -- но таких вещей очень и очень много.

E>>Но где же конкретные сроки и отчеты, на которых настаивают труженники коммерческиого программирования?

IB>Ты думаешь они давали дотации просто так? Да, только на такой наивности и выезжает опенсорс.. )

Я много чего думаю. Только не я заикался о том, что коммерческие разработки это сроки и отчеты, и стиль работы Кнута без сроков и планов не катит. Пожалуйста, в Linux инвестируют много, Линус со товарищи работают без планов и отчетов. Результаты их работы очень активно используют в коммерческих проектах.

E>>Между тем, компании используют опыт разработки на основе одиночек типа Кнута на полную катушку. Тот же Google нанял Гвидо ван Россума. Теперь он за деньги Google развивает Python.

IB>Конечно используют. Тот же Джим Грей отпахал на MS столько что мало не покажется и вообще, MS инвестирует в таких одиночек больше чем гугл и IBM вместе взятые.
IB>И что?

А то, что это пример того, как можно использовать подход к работе Кнута (т.е. программист одиночка без планов и отчетов) в коммерции.

E>>Нет, просто опыт есть.

IB>Опыт чего? Реэдитить код в одно лицо? Это байта ради.

Ты сейчас сам с собой разговариваешь? Тогда нечего мне писать.
Ты спросил, почему re-editable является основой OpenSource. Я ответил -- потому что есть опыт исправления чужого OpenSource кода. Как с отсылкой патчей и предложений авторам кода, так и без.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.07.09 21:44
Оценка:
Здравствуйте, COFF, Вы писали:

COF>Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне"


Этот прием называется "доказательство по аналогии".
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[40]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.07.09 21:44
Оценка:
Здравствуйте, eao197, Вы писали:

E>Первые два были сформированы с помощью dvips, третий -- LaTeX. Ты можешь считать, что все это чисто академическая среда -- но таких вещей очень и очень много.


Касательно MSR Cambridge я тебе могу совершенно точно сказать — это академическая среда в чистом виде.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[2]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.07.09 21:44
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Это ересь по одной простой причине: десятки слегка отличающихся копипаст сложнее поддерживать.


Это если их десятки версий есть. А если у тебя один проект на всю жизнь, такой проблемы не наблюдается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[41]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 22:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


E>>Первые два были сформированы с помощью dvips, третий -- LaTeX. Ты можешь считать, что все это чисто академическая среда -- но таких вещей очень и очень много.


AVK>Касательно MSR Cambridge я тебе могу совершенно точно сказать — это академическая среда в чистом виде.


Документация по Scala написана с помощью LaTeX-а, включая книгу Programming In Scala. А так же книги от Progmatic Programmers (например, Programming Ruby 2nd и Programming Erlang: Software for a Concurrent World). Не думаю, что последние имеют отношение к академическому миру.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[40]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 05:33
Оценка:
Здравствуйте, eao197, Вы писали:

E>Вот три документа, которые я скачал для прочтения в последнее время:

Ну а мне за последние 10 лет, ни один не попадался, и что?

E>Ты можешь считать, что все это чисто академическая среда -- но таких вещей очень и очень много.

Да, могу и это очень мало )

E>Только не я заикался о том, что коммерческие разработки это сроки и отчеты, и стиль работы Кнута без сроков и планов не катит.

То есть, ты считаешь, что стиль работы кнута вполне подходит для коммерческой разработки?

E>Результаты их работы очень активно используют в коммерческих проектах.

В коммерческих проектах много чего используется, но это абсолютно ни о чем не говорит. В коммерческих проектах берут кусок кода написаный тем же кнутом и используют его как black-box, в сугубо коммерческом стиле.

E>А то, что это пример того, как можно использовать подход к работе Кнута (т.е. программист одиночка без планов и отчетов) в коммерции.

Ничего подобного. Использовать можно не подход, а результат. Если результат получился, так чегож его не использовать?
А без результата никто ничего просто так оплачивать не будет.

E>Ты спросил, почему re-editable является основой OpenSource. Я ответил -- потому что есть опыт исправления чужого OpenSource кода. Как с отсылкой патчей и предложений авторам кода, так и без.

Тебе Синклер в подробностях расписал, к чему такой опыт приводит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[40]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 05:33
Оценка:
Здравствуйте, eao197, Вы писали:

E>Есть четыре варианта: полностью игнорить, осторожно прислушиваться, прислушиваться, безоговорочно следовать.

E>Я за вариант "прислушиваться".
Это казуистика. Можешь сформулировать чем отличается "осторожно прислушиваться" от "прислушиваться"?

E>Например, как он не следует?

Использует black-box-ы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[3]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 06:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Это если их десятки версий есть. А если у тебя один проект на всю жизнь, такой проблемы не наблюдается.
Совершенно верно. И в таком проекте куда удобнее один раз скопипастить себе кусок чужого reeditable кода и всю жизнь заниматься его поддержкой, чем поддерживать интеграцию с чужим blackbox.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 06:23
Оценка:
Здравствуйте, IB, Вы писали:

E>>Вот три документа, которые я скачал для прочтения в последнее время:

IB>Ну а мне за последние 10 лет, ни один не попадался, и что?

А то, что я не верю, что в течении прошедших 10 лет, ты выяснял, каким инструментом был создан каждый из прочитанных тобой PDF-ов.

E>>Только не я заикался о том, что коммерческие разработки это сроки и отчеты, и стиль работы Кнута без сроков и планов не катит.

IB>То есть, ты считаешь, что стиль работы кнута вполне подходит для коммерческой разработки?

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

IB>В коммерческих проектах много чего используется, но это абсолютно ни о чем не говорит. В коммерческих проектах берут кусок кода написаный тем же кнутом и используют его как black-box, в сугубо коммерческом стиле.


Что такое "использование в сугубо коммерческом стиле"?

E>>Ты спросил, почему re-editable является основой OpenSource. Я ответил -- потому что есть опыт исправления чужого OpenSource кода. Как с отсылкой патчей и предложений авторам кода, так и без.

IB>Тебе Синклер в подробностях расписал, к чему такой опыт приводит.

Опыт Синклера не вызывает доверия.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[35]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 06:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

E>>Думаю, что опыт Кнута уже давно оказался восстребованным (хотя под соусом опыта Торвальдса) -- сейчас он активно используется в виде "спонсирования OpenSource разработок".

S>Я уже намекал на то, что OpenSource != "re-editable code".

Ну просто для общего развития, что же тогда такое OpenSource?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[41]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 06:36
Оценка:
Здравствуйте, IB, Вы писали:

E>>Есть четыре варианта: полностью игнорить, осторожно прислушиваться, прислушиваться, безоговорочно следовать.

E>>Я за вариант "прислушиваться".
IB>Это казуистика. Можешь сформулировать чем отличается "осторожно прислушиваться" от "прислушиваться"?

"Осторожно прислушиваться" -- это значит проверять полученную от источника информацию.
"Прислушиваться" -- значит доверять полученной от источника информации без предварительной проверки.

Пример. Синклер здесь утверждал, что IIS -- это успех, в отличии от Apache. Поскольку Синклер не был замечен в причастности к альтернативным MS продуктам, его информация нуждается в проверке. Получается вот что: http://news.netcraft.com/archives/web_server_survey.html
Т.е. к словам Синклера я осторожно прислушиваюсь, а к информации NetCraft-а просто прислушиваюсь.

E>>Например, как он не следует?

IB>Использует black-box-ы.

Боюсь, мои познания в англиском не позволяют увидеть в цитате Кнута следующее: "С моей точки зрения весь использованный вами код должен быть вами модифицирован и это гораздо, гораздо лучше, чем черные ящики или инструменты, которые вы не можете трогать".

И, поскольку мы видим в тексте совершенно разные вещи, то смысла продолжать я нет.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Кнут о компонентном программировании.
От: COFF  
Дата: 17.07.09 07:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:

COF>>Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне" :)


AVK>Этот прием называется "доказательство по аналогии".


Это хорошо или плохо? :) Вообще, я ничего не доказывал, просто довел уже имевшиеся рассуждения об яичнице до некоторой точки
Re[43]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 07:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Кроме этого, можно, к примеру, попытаться прикинуть, по какой причине очень небесплатный IIS занимает 2/3 от объемов абсолютно бесплатного апача. И после этого подумать — являются ли 40% рынка успехом для IIS или 60% — fail'ом для Апача.


Ой, апач такой плохой, IIS такой хороший, его делают на коммерческой основе, MS вкладывает офигенные ресурсы по навязыванию своих продуктов. Но все никак не может плохой апач задавить. Но успех!

S>Да-да, я ни Апача, ни nginx, ни lighttpd никогда в глаза не видел и в веб приложениях на PHP не разбираюсь. Тем более не стоит принимать во внимание моё мнение насчёт MS SQL и MySQL- я известный ламер в СУБД.


А что обидно стало, что твои слова (такого всего из себя заслуженного) не принимаются на веру только из-за того, что это твои слова? Правда странно?

S> И все мои так называемые мнения продиктованы исключительно "линией партии" (кстати, где к ней можно подключиться?).


Ты уже ее часть
Автор: eao197
Дата: 19.06.06


И раз уж мои познания в англиском так плохи, может подскажешь, является ли re-editable синонимом rewritten или modified?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 07:46
Оценка:
Здравствуйте, eao197, Вы писали:
E>Прям фраза из get the facts.
Со Свидетелями Иеговы, Столлмана, и прочего булшита я наобщался еще до начала карьеры разработчика. Засим откланяюсь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[44]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 08:03
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ой, апач такой плохой, IIS такой хороший, его делают на коммерческой основе, MS вкладывает офигенные ресурсы по навязыванию своих продуктов. Но все никак не может плохой апач задавить. Но успех!

Ой, IIS такой плохой, апач такой хороший, его раздают забесплатно, но всё никак не могут плохой IIS задавить. Но успех!
E>А что обидно стало, что твои слова (такого всего из себя заслуженного) не принимаются на веру только из-за того, что это твои слова? Правда странно?
Мне ничуть не обидно.
E>Ты уже ее часть
Автор: eao197
Дата: 19.06.06

Бред.

E>И раз уж мои познания в англиском так плохи, может подскажешь, является ли re-editable синонимом rewritten или modified?

Не является.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[44]: Кнут о компонентном программировании.
От: Lloyd Россия  
Дата: 17.07.09 08:09
Оценка:
Здравствуйте, eao197, Вы писали:

E>И раз уж мои познания в англиском так плохи, может подскажешь, является ли re-editable синонимом rewritten или modified?


re-editable == то, что можно отредактировать
rewritten == переписано
modified = изменено
Re[45]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 08:12
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ой, IIS такой плохой, апач такой хороший, его раздают забесплатно, но всё никак не могут плохой IIS задавить. Но успех!


Я не утверждал, что apache -- это успех. Но сильно сомневаюсь, что IIS успешен по сравнению с apache.

E>>И раз уж мои познания в англиском так плохи, может подскажешь, является ли re-editable синонимом rewritten или modified?

S>Не является.

Тогда почему слова Кнута воспринимаются так, как будто нельзя вставлять чужой кусок кода в свой проект предварительно не модифицировав его?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 08:20
Оценка:
Здравствуйте, lomeo, Вы писали:
L>OpenSource — это не только возможность просмотра кода, но также обязательная возможность изменения. Не просто "часть идеологии", а неотъемлемая часть.
Отлично. И вот практика показывает, что 99% OS не пользуется этой "неотъемлемой" частью.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[42]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 08:35
Оценка:
Здравствуйте, eao197, Вы писали:

E>А то, что я не верю, что в течении прошедших 10 лет, ты выяснял, каким инструментом был создан каждый из прочитанных тобой PDF-ов.

Твое право.

IB>>То есть, ты считаешь, что стиль работы кнута вполне подходит для коммерческой разработки?

E>Я думаю, что большое количество коммерческих разработок не достигнет такого уровня качества, как у Кнута.
Так ты на вопрос ответишь?
Вот у меня задача — написать коммерческое приложение и продать его за деньги. При этом я должен успеть сделать это раньше конкурентов, чтобы занять нишу и при этом достаточно качественно, чтобы пользователи не убежали к конкурентам потом. Должен ли я идти по пути кнута?

E>Я думаю, что большое количество коммерческих разработок не достигнет такого уровня качества, как у Кнута. При гораздо больших трудозатратах, превышенных бюджетах и сорванных сроках.

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

E>Что такое "использование в сугубо коммерческом стиле"?

Компонентное программирование.

E>Опыт Синклера не вызывает доверия.

Напрасно, я бы на твоем месте прислушался.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[42]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 08:35
Оценка:
Здравствуйте, eao197, Вы писали:

E>"Осторожно прислушиваться" -- это значит проверять полученную от источника информацию.

E>"Прислушиваться" -- значит доверять полученной от источника информации без предварительной проверки.
Ты не передергивай. Речь не о недоверии источнику, а о применимости информации из этого источника — для каких условий она справедлива.

E>Т.е. к словам Синклера я осторожно прислушиваюсь, а к информации NetCraft-а просто прислушиваюсь.

Гы. Учитывая что неткрафт неоднократно был замечен в пролинуховой пропаганде и неадекватности своих метрик, а Синклер выпускает продукты в том числе и под линух с апачем, так что хлебнул этого горя на своей шкуре, то рекомендую поступать ровно наоборот.
Но. Даже по этому отчету неткрафта видно, что опенсорсный апачь сливает в трубу, насквозь коммерческому IIS-у. А уж если вспомнить отчеты намного более уважаемого IDC, по компаниям Fortune 1000, где IIS занимает около 80 процентов рынка, если я правильно помню, то все становится более чем очевидно.
А еще можно вспомнить отчеты про число ошибок обнаруженых в том же IIS-е по сравнению с Апачем, тоже картина совсем не в пользу опенсорса.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[40]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 08:40
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Допустим, не пользуются этой возможостью 100%. От этого эта возможность никуда не исчезает и не перестаёт быть неотъемлемой частью OS. Без кавычек.

Понятно, это фетиш.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[43]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 08:54
Оценка:
Здравствуйте, IB, Вы писали:

IB>>>То есть, ты считаешь, что стиль работы кнута вполне подходит для коммерческой разработки?

E>>Я думаю, что большое количество коммерческих разработок не достигнет такого уровня качества, как у Кнута.
IB>Так ты на вопрос ответишь?

Я не знаком в деталях со стилем работы Кнута.
Разработчик одиночка вполне может выпускать коммерческие проекты.

IB>Вот у меня задача — написать коммерческое приложение и продать его за деньги. При этом я должен успеть сделать это раньше конкурентов, чтобы занять нишу и при этом достаточно качественно, чтобы пользователи не убежали к конкурентам потом. Должен ли я идти по пути кнута?


Это ты сам решай. Опыт возникновения и развития Hotmail-а (до покупки их MS) показывает, что можно и так пойти.

E>>Что такое "использование в сугубо коммерческом стиле"?

IB>Компонентное программирование.

Под компонентным программированием здесь стали понимать даже использование libc.

E>>Опыт Синклера не вызывает доверия.

IB>Напрасно, я бы на твоем месте прислушался.

Не вижу оснований для этого.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[43]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 09:04
Оценка:
Здравствуйте, IB, Вы писали:

E>>"Осторожно прислушиваться" -- это значит проверять полученную от источника информацию.

E>>"Прислушиваться" -- значит доверять полученной от источника информации без предварительной проверки.
IB>Ты не передергивай. Речь не о недоверии источнику, а о применимости информации из этого источника — для каких условий она справедлива.

Я указал, какой смысл я вкладываю в эти слова. Применимость должна определяться по месту. Т.е., сначала нужно решить, заслуживают ли доверия слова Кнута, а потом уже посмотреть, можно ли его подход применить в своих условиях. Я его словам доверяю и его подход к предпочтению re-editable перед black box-ами в моих условиях применим.

PS. Ну все, теперь я точно знаю, что Fortune 1000 -- это и есть весь бизнес, остальное не в счет.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Кнут о компонентном программировании.
От: 4058  
Дата: 17.07.09 09:30
Оценка:
Здравствуйте, eao197, Вы писали:

E>Индустрия производства ПО, по мнению некоторых участников RSDN, находится в глубокой заднице. При этом программисты-практики, как представители этой самой индустрии, позволяют себе смеятся над человеком, достижения которого (как программиста) им и не повторить. Вместо того, чтобы подумать, а за счет чего Кнуту удается (удавалось) в одиночку делать так много и так хорошо. Может быть и его взгляд на повторное использование не так уж нелеп, как это кажется.


Прошу прощения, что вмешиваюсь, но просто наболело.
Давайте уточним, что именно он сделал много (с точки зрения практики), и что именно хорошо?
Базовые алгоритмы? Прекрасно. А вот как насчет реальных систем?
Допустим у меня средний проект состоит из следующих компонентов:
Сетевые протоколы, библиотеки представления GUI, библиотеки подготовки печатных отчетов, провайдеры к БД...
Поговорим об пресловутых печатных отчетах, для этого я использую (но не всегда) компонент, который преобразует HTML->PDF. Стоимость компонента 400$, работает у нас в условиях 24/7.
(работать с HTML может каждый, поэтому знаток, экзотических средств по генерации отчетов, мне не требуется.)
В результате за один год конечные пользователи получают под миллион готовых бланков (автоматизированная исходящая корреспонденция).
Плохо или хорошо, использовать готовый хорошо отлаженный компонент? Конечно можно и самому это сделать (хотя не тревиальная задача HTML рендерить со всеми CSS-наворотам в тот-же PostScript), но в любом случае это будет заметно дороже, чем 400$.

Кнут занимался подобными проблеммами (просьба не писать, что он такой приземленонной "ерундой" не стал-бы заниматься, т.к. изобрести очередной связный список или алгоритм сортировки гораздо увлекательнее и более заслуживает уважения)?

Не ужели человек, который скажем пишет серверный софт, который за день, должен перемалывать большие объемы данных, получаемые в свою очередь из разношерстных хранилищ БД, где над каждым хранилищем, трудится богатых набор приемственного софта, не имеет правда не согдасится с теоретиком, который с таким зоопарком приемственного кода просто не сталкивался?

P.S. В идеале частенько возникает желание много чего переписать, но практика накладывает свои суровые ограничения.
Re[13]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 09:50
Оценка:
Здравствуйте, 4058, Вы писали:

4>Давайте уточним, что именно он сделал много (с точки зрения практики), и что именно хорошо?


Написал TeX и METAFONT.
Результаты этой работы вы можете видеть, например, в книгах издательства The Pragmatic Programmers. И еще в туче книг и статей математической, физической, химической и т.д. направленности.

4>Плохо или хорошо, использовать готовый хорошо отлаженный компонент?


Покажите, пожалуйста, в словах Кнута запрещение использовать готовые хорошо отлаженные компоненты.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[41]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 17.07.09 09:58
Оценка:
Здравствуйте, IB, Вы писали:

L>>Допустим, не пользуются этой возможостью 100%. От этого эта возможность никуда не исчезает и не перестаёт быть неотъемлемой частью OS. Без кавычек.

IB>Понятно, это фетиш.

Ну, бывает. Но я говорил про определение.
Re[4]: Кнут о компонентном программировании.
От: Baudolino  
Дата: 17.07.09 10:16
Оценка:
S>Совершенно верно. И в таком проекте куда удобнее один раз скопипастить себе кусок чужого reeditable кода и всю жизнь заниматься его поддержкой, чем поддерживать интеграцию с чужим blackbox.
Нет такого понятия "удобнее". Есть "дешевле". Если чужого кода мало и обратная связь с его разработчиками не работает, то дешевле, действительно, поддерживать копипасту. Вот только сложность ИТ проектов сейчас такова, что самостоятельная поддержка чужого кода стоит неоправданно дорого. Кнут этого, очевидно, не понимает, потому что экономикой ИТ не занимался.
Re[44]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 10:17
Оценка:
Здравствуйте, eao197, Вы писали:

E>Я не знаком в деталях со стилем работы Кнута.

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

E>Разработчик одиночка вполне может выпускать коммерческие проекты.

Да кто бы спорил.

E>Это ты сам решай. Опыт возникновения и развития Hotmail-а (до покупки их MS) показывает, что можно и так пойти.

А что, Hotmail писали все сами под себя, переписывая все что под руку попадется под свои нужды?

E>Не вижу оснований для этого.

Рекомендую прозреть..
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[42]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 10:17
Оценка:
Здравствуйте, eao197, Вы писали:

E>Если после этого Синклер еще кого-нибудь обвинит в демагогии...

Всяко не тебе обвинять Синклера.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[45]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 10:30
Оценка:
Здравствуйте, IB, Вы писали:

E>>Я указал, какой смысл я вкладываю в эти слова.

IB>Но не то что требовалось.

Я не несу ответственности за то, что требуется тебе.

E>> Применимость должна определяться по месту. Т.е., сначала нужно решить, заслуживают ли доверия слова Кнута, а потом уже посмотреть, можно ли его подход применить в своих условиях.

IB>Доверие кнуту сомнения не вызывают, я практически уверен, что все участники дискуссии считают, что кнут не слукавил и не соврал.

А я в этом сомневаюсь.

IB>Все разборки исключительно вокруг области применимости его откровений, так что не надо опять передергивать.


Тут есть несколько веток. Началось все с того, что усомнились в знаниях Кнута относительно компонентного программирования. А потом уже перешло к применимости программистов одиночек в коммерческих разработках.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 10:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>

you’ll never convince me that reusable code isn’t mostly a menace.


Это если рассматривать ее в отрыве от untouchable black box.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Кнут о компонентном программировании.
От: COFF  
Дата: 17.07.09 11:21
Оценка:
Здравствуйте, 4058, Вы писали:

E>>Покажите, пожалуйста, в словах Кнута запрещение использовать готовые хорошо отлаженные компоненты.


4>Ну есть заявление, что КОП это плохо, и далее обращение к читателю, что если Вы это не признаете, значит еще "не доросли".


Мне кажется, проблема в том, что не совсем ясно, что именно Кнут подразумевал под черным ящиком. Например, вышеуказанная конвертация html в pdf прекрасно выносится в отдельное приложение и полностью соответствует unix-way. Вряд ли Кнут против такого подхода. В конце-концов, это именно то, что сам TeX и делает — конвертирует файлы одних форматов в другие :)
Re[16]: Кнут о компонентном программировании.
От: COFF  
Дата: 17.07.09 11:26
Оценка:
Здравствуйте, eao197, Вы писали:

E>Четкие сроки и разнокалиберные команды -- это, блин, далеко не весь коммерческий софт. И далеко не весь успешный коммерческий софт.


Я бы даже сказал, что выдающийся софт как раз делается высокопрофессиональными командами и сроки там далеко не на первом месте. Взять тот же Blizzard. И четкие сроки при разработке на заказ и на продажу по разному могут выдерживаться — в первом случае скорее пожертвуют качеством, чем выкинут часть функционала, а во втором — наоборот.
Re[16]: Кнут о компонентном программировании.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.07.09 11:26
Оценка:
E>Исходя из своего опыта я придерживаюсь следующих предпочтений:
E>- использовать готовый код лучше, чем писать самому;
E>- использовать сторонний компонент с доступным исходным кодом лучше, чем с закрытым (тот самый untouchable black box);
E>- использовать сторонний компонент с лицензией, которая допускает его модификацию лучше, чем компонент с исходным кодом, но с более жесткой лицензией.

эти предпочтения как-то не в тему, спор-то идет о другом, что лучше:
компонент с исходным кодом, но с плохими возможностями по улучшению(развитию) снаружи
или
компонент без исходного кода, но с хорошими возможностями по улучшению(развитию) снаружи

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


а так всем вроде понятно, что:
компонент с исходным кодом и с хорошими возможностями по улучшению снаружи — лучше, чем такое же, но без исходного кода

также идут замечания, что модель open source из-за своей открытости исходников провоцирует именно плохие возможности по улучшению снаружи.
Re[16]: Кнут о компонентном программировании.
От: 4058  
Дата: 17.07.09 11:34
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>В каких условиях работал Стив Возняк над Apple II?


В таких-же, как и многие другие разработчики т.н. бытовых ПК и софта для них.
И в нашей стране были множество разработчиков БПК, и в основном это были одиночки.
(у самого было чудо советсткого комп. строения под названием Вектор06Ц,
один человек делал жезеку, второй софт под нее, и вперед на конвейер).
Но это область была молодая и время такое, что чем меньше народу, тем оно лучше.

E>В каких условиях разработчики PayPal делали свои первые версии для Palm-а?

E>В каких условиях разработчики Hotmail начинали свой почтовый сервис?

Вышеперечисленные нишы были доступны для таких условий.

E>Четкие сроки и разнокалиберные команды -- это, блин, далеко не весь коммерческий софт. И далеко не весь успешный коммерческий софт.


Совершенно верно, и в таких условиях, приходятся совершать "самурайские подвиги", чтобы софт в конечном счете был успешен. А вот в одиночку уже нельзя, слишком крупные проекты и слишком маленькие (а порой и вовсе неадекватные) сроки.
Поэтому зачитываясь мемуарами очередного теоретика, например на тему "ООП — плохо, а ФП — спасет мир" или "Динамика vs Статика", хочется спросить, а был ли практический опыт, а если был, то на сколько он весомен, чтобы обрести право навязывать (или даже просто высказывать), свое мнение?

E>Давайте я переведу высказывание Кнута так, как я понимаю его. А дальше ваше дело, соглашаться или нет:

E>

E>Так же я должен признаться в сильном предубеждении против моды на переиспользуемый код. Для меня код, который можно отредактировать, гораздо, гораздо лучше, чем черный яшик или инструмент, к которому нельзя прикасаться. Я мог бы говорить и говорить об этом. Если вы полностью убеждены, что повторно используемый код -- это прекрасно, то я, вероятно, не смогу поколебать вас, но и вы не сможете убедить меня, что повторно используемый код не является, по большей мере, угрозой.


Нужное выделено жирным.

E>Все это, на мой взгляд, согласуется со словами Кнута. И на мой взгляд, при использовании untouchable black box _всегда_ есть угроза того, что проблемы с ним возникнут, а вы ничего не сможете с этим поделать. И попробуйте убедить меня в обратном


Это все правильно, т.к. прыгать вокруг черного ящика, не имея ключа или даже отмычки дело совсем неблагородное...
Re[17]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 11:49
Оценка:
Здравствуйте, 4058, Вы писали:

E>>В каких условиях работал Стив Возняк над Apple II?


4>В таких-же, как и многие другие разработчики т.н. бытовых ПК и софта для них.


У него не было ни сроков, ни, практически, денег на разработку. И он делал почти все сам в одиночку. Тем не менее в свое время Apple II стал продаваемым ПК.

E>>В каких условиях разработчики PayPal делали свои первые версии для Palm-а?

E>>В каких условиях разработчики Hotmail начинали свой почтовый сервис?

4>Вышеперечисленные нишы были доступны для таких условий.


Ни за что не поверю, что сегодня абсолютно все ниши заняты.

4>А вот в одиночку уже нельзя, слишком крупные проекты и слишком маленькие (а порой и вовсе неадекватные) сроки.


Это далеко не везде так.

4>Поэтому зачитываясь мемуарами очередного теоретика, например на тему "ООП — плохо, а ФП — спасет мир" или "Динамика vs Статика", хочется спросить, а был ли практический опыт, а если был, то на сколько он весомен, чтобы обрести право навязывать (или даже просто высказывать), свое мнение?


Т.е., по сути, вы сомневаетесь в том, если ли у Кнута достаточный практический опыт, чтобы высказываться на тему повторного использования кода. Так я вас понял?

E>>Давайте я переведу высказывание Кнута так, как я понимаю его. А дальше ваше дело, соглашаться или нет:

E>>

E>>Так же я должен признаться в сильном предубеждении против моды на переиспользуемый код. Для меня код, который можно отредактировать, гораздо, гораздо лучше, чем черный яшик или инструмент, к которому нельзя прикасаться. Я мог бы говорить и говорить об этом. Если вы полностью убеждены, что повторно используемый код -- это прекрасно, то я, вероятно, не смогу поколебать вас, но и вы не сможете убедить меня, что повторно используемый код не является, по большей мере, угрозой.


4>Нужное выделено жирным.


В выделенным жирным "повторно используемый код" является синонимом untochable black box.
Но даже когда повторно используемый код не является черным ящиком он все равно может нести в себе угрозу: например, неоднокрано упомянутый здесь за последнее время Arian 5 Flight 501.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Кнут о компонентном программировании.
От: 4058  
Дата: 17.07.09 11:51
Оценка:
Здравствуйте, COFF, Вы писали:

COF>Я бы даже сказал, что выдающийся софт как раз делается высокопрофессиональными командами и сроки там далеко не на первом месте. Взять тот же Blizzard.


Blizzard это еще, что.
Например 3D Realms, более 10-ти лет делала свой DukeNukem Forever, а в этом году сообщила о банкротстве.

Это понятно, просто для примера наша комманда вынуждена работать в условиях, когда надо закончить проект еще "поза-вчера", по причине того, что ранее другая "высокопрофессиональная комманда" потратила на это слишком много времени,
а затем красиво развела руками.
Re[18]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 11:55
Оценка:
Здравствуйте, 4058, Вы писали:

4>Это понятно, просто для примера наша комманда вынуждена работать в условиях, когда надо закончить проект еще "поза-вчера", по причине того, что ранее другая "высокопрофессиональная комманда" потратила на это слишком много времени,

4>а затем красиво развела руками.

У вас хотя бы есть кого винить. А то ведь бывает, что заказчику что-то вдруг в голову (или не в голову) стукнет и оказывается, что вдруг нужен вот такой сервис и еще вчера.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[46]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 12:44
Оценка:
Здравствуйте, eao197, Вы писали:

E>Я не несу ответственности за то, что требуется тебе.

Я задал прямой вопрос, а ты уже три сообщения не можешь на него ответить...
И еще обвиняешь Синклева в демагогии, ага.

E>А я в этом сомневаюсь.

Здесь кто-то обвинял кнута во лжи?

E>И все это в уверенности в том, что Кнут призывал все переписывать под себя.

Эта уверенность появилась из твоей трактовки кнута.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[42]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 12:44
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Отъять можно, но тогда это будет не OS и к данному треду никакого отношения иметь не будет.

ну точно, фетишь. Никто не пользуется, но если отъять, то уже не то.

L>Может я ошибаюсь, но он говорит ровно следующее: "Кнут говорит, что иметь код, который можно подправить, лучше чем иметь black box. Считаю, что к мнению Кнута стоит прислушаться".

Не совсем так. Ему говорят, что подход кнута (как eao его описывает) не применим в серьезной командной разработке, а в ответ несется "ну как вы можете это же сам Кнут!"

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

Но по факту, даже самые ярые сторонники такого подхода не правят.

L>Прислушаться не значит начать править всё кругом и забить на компоненты, а означает задуматься, почему Кнут так считает.

eao заставляет делать выводы основываясь только на авторитете кнута, не принимая в рассчет других факторов.
А мы, как раз задумались и сделали свои выводы и они, по очевидным причинам, с идолопоклонничеством плохо согласуются.

L>Неужели не интересно почему Кнут так считает?

Интересно, более того, мы свой интерес удовлетворили.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[43]: Кнут о компонентном программировании.
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 17.07.09 13:16
Оценка:
Здравствуйте, IB, Вы писали:

L>>Может я ошибаюсь, но он говорит ровно следующее: "Кнут говорит, что иметь код, который можно подправить, лучше чем иметь black box. Считаю, что к мнению Кнута стоит прислушаться".

IB>Не совсем так. Ему говорят, что подход кнута (как eao его описывает) не применим в серьезной командной разработке, а в ответ несется "ну как вы можете это же сам Кнут!"

Ну, значит, я невнимателен. Я не заметил, чтобы eao197 как то по своему описывал подход Кнута.
Re[15]: Кнут о компонентном программировании.
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 17.07.09 13:48
Оценка:
COF>Это как если бы шеф-повар крутейшего ресторана говорил: "по моему опыту, чтобы приготовить хороший омлет, лучше использовать натуральные яйца, масло и молоко, чем яичный порошок, молочный концентрат и маргарин". А ему в ответ: "да что ты понимаешь в приготовлении пищи — ты хотя бы день работал на фабрике-кухне"

Согласен. Но посылаем этого повара накормить роту солдат и проверяем не изменилась ли после этого его позиция.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[47]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 13:49
Оценка:
Здравствуйте, IB, Вы писали:

E>>Я не несу ответственности за то, что требуется тебе.

IB>Я задал прямой вопрос, а ты уже три сообщения не можешь на него ответить...

Ok. Насколько я могу судить о подходе Кнута, то его способ работы может использоваться в коммерческой разработке ПО.
Может ли он использоваться в твоих условиях или условиях Синклера -- не знаю.

IB>И еще обвиняешь Синклева в демагогии, ага.


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

E>>А я в этом сомневаюсь.

IB>Здесь кто-то обвинял кнута во лжи?

Здесь неоднократно высказывались сомнения в том, что Кнут понимает о чем говорит. Последний пример: http://www.rsdn.ru/forum/philosophy/3471835.aspx
Автор: 4058
Дата: 17.07.09


E>>И все это в уверенности в том, что Кнут призывал все переписывать под себя.

IB>Эта уверенность появилась из твоей трактовки кнута.

Цитату из меня приведешь, где бы я утверждал подобное?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 13:59
Оценка:
Здравствуйте, 4058, Вы писали:

E>>У него не было ни сроков, ни, практически, денег на разработку. И он делал почти все сам в одиночку. Тем не менее в свое время Apple II стал продаваемым ПК.


4>Аналогичная история с Sinclair, да и многими другими бытовыми компьютерами.

4>Один в гараже, ни сроков, ни денег. Своего рода романтика...
4>Но какое отношение это имеет к сегодняшним суровым реалиям?

В наши суровые реалии стартапы продолжают возникать, а некоторые даже становиться успешными. Так что не вижу принципиальных различий.

Тут где-то IB пример приводил -- распознавание формул. Тратить большие деньги OCR-разработчики на эту узкую задачу не хотят. Но тот, кто первым сделает качественное распознавание, может стать монополистом рынка. Может сейчас кто-то по вечерам этой задачей занимается. И вряд ли для нее нужно большое количество сторонних black box-ов.

E>>Т.е., по сути, вы сомневаетесь в том, если ли у Кнута достаточный практический опыт, чтобы высказываться на тему повторного использования кода. Так я вас понял?


4>Совершенно верно.


Боюсь, я не смогу вас разубедить. Поскольку вы считаете, что копьютерная верстка (которой занимается TeX) -- это "узкоспециализированные академически-ориентированные задачки", не идущие ни в какое сравнение с суровыми серверными системами режима 24/7. Единственный способ разубедить вас в этом -- попробовать реализовать аналог TeX-а.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[21]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 14:38
Оценка:
Здравствуйте, 4058, Вы писали:

E>>В наши суровые реалии стартапы продолжают возникать, а некоторые даже становиться успешными. Так что не вижу принципиальных различий.


4>Принципиальные различия в том, что зачастую на стартапах, не удается прочувствовать всю "прелесть", современного софтвэр-инжиниринга.


What is the fu*king modern software engineering?

До сих пор речь шла о коммерческих разработках. Т.е. о разработках, которые должны приносить прибыль своим создателям/владельцам. Прикладних ниш и условий в которых ведется коммерческая разработка -- вагон и маленькая тележка, и их количество с каждым днем растет. И в каждой свои правила игры.

Вот тот же thesz, топик стартер, программирует модели для эмуляции аппаратуры. Вполне себе коммерческая разработка.
Я со своей маленькой командой делаем сервисы для поддержки мобильной/электронной коммерции. Это так же вполне себе коммерческая разработка.

Мне, чесно говоря, пофигу, какие проблемы в коммерческой разработке Web-приложений в индийском оффшоре. Или какие проблемы решают банковские программисты при разработке АРМ-ов своих РКЦ. Или какими проблемами страдают разработчики игр для консолей. Хотя все это тоже вполне себе коммерческие разработки со своими забабонами.

А время и современные условия давят на всех -- и сроки снижаются, и стоимость заказов временами, и требования все время повышаются. Но, если под коммерческой разработкой понимается выпуск ПО в оффшоре по спецификациям заказчика, то я не могу ничего на эту тему сказать.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[37]: Кнут о компонентном программировании.
От: WFrag США  
Дата: 17.07.09 14:39
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

E>>Ну просто для общего развития, что же тогда такое OpenSource?
S>OpenSource — это всего лишь свободная раздача доступа к исходникам. Часть идеологии OpenSource — в возможности "затачивать под себя", re-editable. К сожалению, эта техника has proven generally ineffective, что легко заметить невооруженным взглядом по небольшому количеству open source derived work по сравнению с open source dependent work.

Да? А на мой взгляд, этим как минимум каждый дистрибутив занимается.
Re[22]: Кнут о компонентном программировании.
От: 4058  
Дата: 17.07.09 14:47
Оценка:
Здравствуйте, eao197, Вы писали:

E>А время и современные условия давят на всех -- и сроки снижаются, и стоимость заказов временами, и требования все время повышаются. Но, если под коммерческой разработкой понимается выпуск ПО в оффшоре по спецификациям заказчика, то я не могу ничего на эту тему сказать.


Разговор шел про Кнута, и на тему можно ли слепо доверять его выводам,
или же стоит основываться на собственном опыте и соответсвующих выводах из него.
Re[42]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.07.09 16:09
Оценка:
Здравствуйте, eao197, Вы писали:

E>Документация по Scala написана с помощью LaTeX-а, включая книгу Programming In Scala.


Скала, помнится, тоже из научной среды.

E> А так же книги от Progmatic Programmers (например, Programming Ruby 2nd и Programming Erlang: Software for a Concurrent World).


Не читал и не в курсе кто их авторы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[5]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.07.09 16:09
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Нет такого понятия "удобнее".


Есть.

B> Есть "дешевле".


В некоммерческом проекте?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[43]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.07.09 16:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:

E>> А так же книги от Progmatic Programmers (например, Programming Ruby 2nd и Programming Erlang: Software for a Concurrent World).


AVK>Не читал и не в курсе кто их авторы.


Тогда имена авторов первой тебе ничего не скажут. А книгу про Erlang написал Джо Армстронг, разработчик языка Erlang.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Кнут о компонентном программировании.
От: Baudolino  
Дата: 17.07.09 16:32
Оценка:
B>> Есть "дешевле".
AVK>В некоммерческом проекте?
Даже в некоммерческом, если написание кода не самоцель.
Re[20]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 17:25
Оценка:
Здравствуйте, eao197, Вы писали:

E> И вряд ли для нее нужно большое количество сторонних black box-ов.

Тв даже не представляешь сколько..
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[48]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 17:25
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ok. Насколько я могу судить о подходе Кнута, то его способ работы может использоваться в коммерческой разработке ПО.

Если то что ты озвучивал в этой ветке, то ты глубоко заблуждаешься.

E>В моем демагогическом арсенале есть очень большой пробел -- я редко обвиняю кого-либо в демагогии, передергивании, подтасовки фактов, выдумываний слов оппонентов и т.д.

И это через два сообщения, после того, как ты обвинил Синклера в демагогии. Ну и как после этого верить твоим словам?

E>Нужно у вас получится, а то это борьба в разных весовых категориях получается

И вот это обвинение в демагогии тоже, редко делаешь, да? Вообщем ясно все с тобой.

E>Здесь неоднократно высказывались сомнения в том, что Кнут понимает о чем говорит. Последний пример: http://www.rsdn.ru/forum/philosophy/3471835.aspx
Автор: 4058
Дата: 17.07.09

Нет, это сомнения в том, что опыт кнута применим в условиях коммерческой разработки, о чем тебе уже было сказано неоднократно. Не надо опять разговор в другую плоскость переводить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[44]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 17.07.09 17:25
Оценка:
Здравствуйте, lomeo, Вы писали:

L> Я не заметил, чтобы eao197 как то по своему описывал подход Кнута.

То есть, его аргументация у тебя возражений не вызывает? А как же призывы подумать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[25]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.07.09 09:41
Оценка:
Здравствуйте, 4058, Вы писали:

E>>...Да и вы сами сомневаетесь в том, достаточно ли Кнут попрограммировал, чтобы его вообще слушать.


4>Возвращаясь к вопросу о целесообразности КОП и "черных ящиков" ...


Простите мне мой французкий, но здесь нет вопроса о целесообразности КОП и "черных ящиков".


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Кнут о компонентном программировании.
От: 4058  
Дата: 19.07.09 09:50
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>>>...Да и вы сами сомневаетесь в том, достаточно ли Кнут попрограммировал, чтобы его вообще слушать.


4>>Возвращаясь к вопросу о целесообразности КОП и "черных ящиков" ...


E>Простите мне мой французкий, но здесь нет вопроса о целесообразности КОП и "черных ящиков".


В моем случае DIB->PNG, тот самый "черный ящик".
Re[33]: Кнут о компонентном программировании.
От: Erop Россия  
Дата: 19.07.09 12:39
Оценка:
Здравствуйте, IB, Вы писали:

IB>Я тебе другой похожий пример привести могу — знаешь почему ни одна распознавалка, так до сих пор и не поддерживает распознавание формул? Потенциально это не очень сложно, просто ниша настолько узка, что серьезных денег не заработаешь и первый же кто это сделает, хоть за десять лет — станет стандартом де факто. Но никому не интересно иметь главный куличик в песочнице.


Я думаю, что причины тут другие.
1) Область очень разношёрстная. Формулы у физиков одни, у математиков разных направлений -- разные. Скажем сравни формулы из матана и CS... А ещё химия есть, сопромат, биология и т. д...
2) Не очень хорошо с общепринятым выходным форматом для формул
3) Не очень понятно кому и зачем это нужно. Кто и как сэкономит на распознавалке формул столько, чтобы её покупка отбилась?

Ну и доп. вопрос:
Есть ведь и опенсорсные распознавалки. Гуглическая, например. Они тоже что-то не рвутся

Короче -- сделать юзабельную систему трудно, а пользы от неё много не просматривается...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: Кнут о компонентном программировании.
От: Blondy  
Дата: 19.07.09 13:50
Оценка:
Здравствуйте, VGn, Вы писали:

T>>>>Если мы зафиксируем некоторый срок, то вероятность дописать компонент до нужного уровня становится всё выше и выше с течением времени. Грубо говоря, вчера было труднее написать, чем найти, сегодня проще написать.


VGn>>>А объем этого кода в геометрической прогрессии больше.


T>>В арифметической, если мы берём одного разработчика. В геометрической, если мы берем рост разработчиков.


VGn>Вот именно, что нет. Пять лет назад у того же грида было в десять раз меньше свойств. И свойства стали сложнее. При этом он как гридом был, так им и остался. А поскольку средства стали лучше, мы сейчас можем использовать этот грид намного быстрее. И что теперь при наличии исходников проще стало доработать контрол?

VGn>Кстати это обычно не проблема. Все ведущие производители контролов поставляют исходники за отдельную плату. Но разработчики заглядывают в них всё реже и реже. И это правильно.
А почему на гриде остановились? Ведь грида это часто антипатерн. В ASP.NET точно. Там гриду используют только ламеры. В смарт клинтах это не так явно, но в первой версии WPF гриды нет, и рекомендуется без нее обходиться. Смена порадигмы между WinForm и WPF как раз и произошла в том направлении, чтобы не было таких монстриков как грида.
Re[5]: Кнут о компонентном программировании.
От: Blondy  
Дата: 19.07.09 14:11
Оценка:
B>Кнут этого, очевидно, не понимает, потому что экономикой ИТ не занимался.
А вы занимались? Чего достигли? Если для вас главное экономика, то основной критерий оценки ваших успехов это ваше состояние в долларовом исчислении. Каково Ваше состояние? Может Кнут, не занимаясь экономикой, и по этому критерию вас сделал?
Re[34]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 19.07.09 15:38
Оценка:
Здравствуйте, Erop, Вы писали:

E>1) Область очень разношёрстная. Формулы у физиков одни, у математиков разных направлений -- разные. Скажем сравни формулы из матана и CS... А ещё химия есть, сопромат, биология и т. д...

E>2) Не очень хорошо с общепринятым выходным форматом для формул
Это все сложности конечно, но вполне преодолимые, если задаться целью — это не причины.

E>3) Не очень понятно кому и зачем это нужно. Кто и как сэкономит на распознавалке формул столько, чтобы её покупка отбилась?

Именно в этом и был поинт.

E>Есть ведь и опенсорсные распознавалки. Гуглическая, например. Они тоже что-то не рвутся

Ровно по той же причине — это мало кому нужно. Тому же гуглу работать на узкий рынок нет никакого резона, нишевых решений от него не дождешься, не те масштабы.
Что касается остального опенсорса — стандартный косяк всех опенсорсных решений: среди программистов нет тех кому нужно распознавать формулы, среди тех кому нужно распознавать формулы нет тех, кто умеет писать код, и приплыли, с этой стороны решения вообще ждать бесполезно, если не найдется еще один кнут.

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

От кнутовского TeX-а пользы тоже не дофига. Если бы его не было, ни кто бы не умер и все бы пользовались нормальными системами верстки.
Если для верстки формул нашелся такой кнут, которому было интересно написать подобную систему, то для распознавания формул (возможно пока) нет, вот и вся разница.
Мы уже победили, просто это еще не так заметно...
Re[44]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.07.09 17:34
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ой, апач такой плохой, IIS такой хороший, его делают на коммерческой основе, MS вкладывает офигенные ресурсы по навязыванию своих продуктов. Но все никак не может плохой апач задавить.


А с чего ты взял, что МС хочет его задавить? Они, вроде, даже как то apache foundation спонсировали.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[6]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.07.09 17:34
Оценка:
Здравствуйте, Blondy, Вы писали:

B>А вы занимались? Чего достигли? Если для вас главное экономика, то основной критерий оценки ваших успехов это ваше состояние в долларовом исчислении. Каково Ваше состояние? Может Кнут, не занимаясь экономикой, и по этому критерию вас сделал?


Тут, в топике, кажется уже писали о лигической некорректности аппеляции к авторитетам. Авторитеты хороши в процессе познания, а не в процессе спора.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[45]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.07.09 06:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А с чего ты взял, что МС хочет его задавить? Они, вроде, даже как то apache foundation спонсировали.


Apache Foundation уже давным-давно не только http-сервер: http://projects.apache.org/indexes/alpha.html и http://incubator.apache.org/projects/index.html


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Кнут о компонентном программировании.
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 20.07.09 08:48
Оценка:
B>А почему на гриде остановились? Ведь грида это часто антипатерн. В ASP.NET точно. Там гриду используют только ламеры. В смарт клинтах это не так явно, но в первой версии WPF гриды нет, и рекомендуется без нее обходиться. Смена порадигмы между WinForm и WPF как раз и произошла в том направлении, чтобы не было таких монстриков как грида.

На гриде остановился, потому как наиболее объёмный и узнаваемый из стандартных. По поводу антипаттерна: использование своих деревянных велосипедов — тоже довольно сильный антипаттерн.
Сейчас разработано много мощных сторонних компонентов (типа кубов, диаграмм, можных меню и целых функциональных модулей), которые довольно сложно охватить взглядом на уровне кода, да и, как я уже сказал, обычно никому не надо.
Это же касается WPF. У меня не много опыта работы с ним, но я точно знаю, что тот же Инфрагистикс уже наваеял под него офигенные контролы (даже круче чем под ASP.NET, несмотря на то, что с аспнетом они работают много дольше)
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[7]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 08:57
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


VD>Кстати, сколько ты знаешь алгоритмов названных его именем?


Knuth-Bendix completion algoritm, тебе, как интересующемуся компиляторами, желательно с ним ознакомиться.

Поиск назван его именем.

Ещё, наверное, по мелочи.

VD>Хоор наверно тоже силен в вопросах компонентного проектирования и повторного использования кода на том основании, что изобрел алгоритм быстрой сортировки...


Логика Хоара, те самые тройки {P} S {Q}.

С их помощью ты можешь описать (и с их помощью описывают) контракты на компоненты.

VD>Нет, ты не моська, ты демогог.


Это следовало бы говорить после моих ответов, а не в их ожидании.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 09:32
Оценка:
T>>Приведённый мной код и Си, и Си++.
J>Каким боком это С, если в С шаблонов нет?
J>Да и в С++ у тебя это просто обычная типизация разными несвязанными типами, с тем же успехом ты можешь вместо FILE<content> и FILE<text_file> написать FILE_content и FILE_text_file, ничего не изменится.

Да. Однако, типы связаны через типы функций.

T>>>>Минус-плюс я могу в параметр внести, видно будет.

J>>>Ну вот о чем и речь, что придется весь текст функции засунуть в тип.
T>>Внутренние связи между ограничениями не будут видны в типе. Поэтому я отвечаю резким "нет".
J>Ну где же нет, если ты только что сам сказал, что плюс вынесешь в тип?
J>Хотя... что ты подразумеваешь под "внутренними связями между ограничениями"?

То и называю. Тип — это теорема. Функция с таким типом — её доказательство.

Доказательство может быть сложнее и многословней формулировки теоремы. Обычно и бывает.

Для доказательства используются другие доказанные теоремы (функции с их типами). Связь между использованием этих внутренних теорем не имеет выражения в формулировке самой теоремы.

Если возвращаться обратно к программированию...

Функция void display_members_by_last_name(display_context *context) будет использовать функцию member* get_members_list() и функцию sort_list(A* list, B project_function, bool ascending_sort). Последней мы передадим функцию string project_member_last_name(member*m), сравнение строк на функцию сравнения и true, чтобы список был сортирован в алфавитном порядке.

Можно придумать тип для проверки правильности отображения. Я могу сформулировать ограничения на context, что это будет проверено.

Но если не хочешь, можешь обойтись.

Напомню, что строго типизированное лямбда-исчисление (любой язык программирования) мощнее, чем лямбда-исчисление (любой язык программирования) без типов.

J>>>После чего у тебя сложность типа будет сравнима со сложностью кода функции, и если код сильно кучерявый, то и тип будет такой же.

T>>Опять же, нет.
J>Почему?

Потому, что не будет. Опыт показывает, что не бывает.

J>>>И этот тип придется тестировать так же, как ты тестировал бы функцию без этого типа.

T>>И снова нет.
J>Почему?

Потому, что не надо. Потому, что ты не сможешь построить доказательство (написать функцию) неправильно сформулированной теоремы (с неправильно написанным типом).

T>>Граничные условия отдельных функций проверяются типами функций.

J>И сколько у тебя тогда типов расплодится в программе?
J>На каждую функцию — по типу?

Да.

Программистов на Java/C# это не смущает. А в случае зависимых типов типы ещё и выразительней (больше можно записать меньшими словами).

J>И в любом случае — как ты без тестов гарантируешь, что ты не ошибся при программировании этих самых типов функций?


У меня не будет написана программа.

T>>Человек выписывает статические связи между участками программы, поскольку текст статичен. Даже если в динамике код программы будет изменяться, то все его изменения должны быть предсказуемы статически.

T>>Больше мне сказать нечего.
J>Хм... Мало что понял, сорри.
J>Если только придраться к тому, что у человека на руках только текст программы, а я видел очень мало людей, способных уместить у себя в голове весь текст программы, чтобы смочь о нем рассуждать.
J>Обычно у человека есть нечто вроде спеков в каком-то полусыром и смутном виде, и программу он уже пишет, основываясь на них и своем интуитивном представлении о том, что же нужно.

И что, эти "спеки" динамические? Они во времени меняются? Они статические.

А если начинают меняться, то это приводит к краху проекта.

T>>Если я неправильно написал типы, то у меня будут затруднения с выражением своих мыслей в других частях программы. Программа просто не будет написана.

T>>Она На Хаскеле пишется с трудом, если типы плохие, что уж говорить про зависимые типы.
J>Можешь привести пример, чтоб было понятно, как именно будут выглядеть "затруднения с выражением своих мыслей в других частях программы"?

У модели процессора есть тип Stmt regaddrsize regdatasize memaddrsize memdatasize.

Он представляет собой несколько вариантов разных выражений, которые могут встретиться в реальном процессоре: запись в регистр, вычисление флага состояния, запись в память или чтение из памяти.

Вдруг выясняется, что у процессоров есть ещё и память команд и туда тоже можно писать и оттуда можно читать. И эта память команд по своим параметрам (ширина и размер) не совпадает с уже имеющимися.

Надо что-то делать. Изменим "тип" Stmt на Stmt regaddrsize regdatasize memaddrsize memdatasize progaddrsize progdatasize. Вариант Stmt по записи в память программ будет StmtStorePM :: Expr progaddrsize -> Expr progmemsize -> Stmt regaddrsize regdatasize memaddrsize memdatasize progaddrsize progdatasize.

Теперь для 24-хбитной памяти программ ADSP2181 мне придётся формировать полное 24-хбитное слово из содержимого 16-тибитного регистра АЛУ и специального 8-битного регистра. Вероятность ошибки снизилась: мне надо учитывать, что размеры слова памяти программ отличаются от размеров слова АЛУ. Поскольку от модули ADSP2181 требуется иметь память программ в 24 бита шириной, то мне придётся реализовать эту часть модели правильно, путём ознакомления с документацией.

T>>Тесты калибра меньше функциональных не нужны.

J>пока не убедил.

Я бы и рад, но ты не приводишь примеров, опровержение или подтверждение которых тебя убедит.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 09:35
Оценка:
Здравствуйте, Tesh, Вы писали:

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


T>>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


T>>Пожалуй, подпишусь.


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


T>Нужно уметь распределять обязанности, некоторые вещи лучше доверить группе сторонних разработчиков, которые будут развивать свои компоненты, исправлять баги, которые будешь находить не только ты, но и другие их клиенты.


А если это не ошибка? Если требуется доработка?

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


С этим справляются системы типов.

T>По поводу допиливания чего-то под себя: можно использовать грамотно спроектированные компоненты, которые не требуют наличия исходного кода для своей кастомизации.


Какова вероятность получения такой компоненты?

Возьми свой текущий проект и посчитай, что ты можешь вынести в компоненту, исходный код которой тебе практически никогда не потребуется. Вычисли процент от общего объёма кода.

Я думаю, ты будешь приятно удивлён.

T>Бывает так, что когда люди по-умолчанию поставляют исходный код, то часто на эту тему и не заморачиваются — код же есть, допиливайте, соответственно появляются люди, которые приспосабливаются к такому подходу и не представляют других вариантов) а потом имеют головняки из-за того что вышла новая версия и теперь все надо как-то обновить


Бедняжки.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 09:37
Оценка:
Здравствуйте, Baudolino, Вы писали:

T>>

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.


B>Это ересь по одной простой причине: десятки слегка отличающихся копипаст сложнее поддерживать.


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

B>Код без ошибок бывает редко, и если ошибка найдена, то придется проверять на её наличие и исправлять все копии. Так что, no thanks, лучше уж наследование и полиморфизм.


Ты про expression problem слышал? Наследование и полиморфизм не решают её.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[43]: Кнут о компонентном программировании.
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 20.07.09 10:16
Оценка:
S>Ну и совсем будет здорово подумать об успехе идеологии OpenSource. Правда, это рискованно — можно, к примеру, додуматься до того, что статистика использования Апача никакого отношения к "идеологии OpenSource" не имеет. Вот те 60%, которые там нарисованы — это что, "поредактированный" Apache? Нихрена, это тот самый blackbox, вытянутый из репозитория и запущенный в неизменном виде.

Хуже. Обычно это нередакитированный апач с дополнительной нахлобучкой
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[44]: Кнут о компонентном программировании.
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 20.07.09 10:18
Оценка:
VGn>Хуже. Обычно это нередакитированный апач с дополнительной нахлобучкой
VGn>

Уппс. Повторил твою мысль. Недочитал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[46]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.07.09 10:32
Оценка:
Здравствуйте, eao197, Вы писали:

E>Apache Foundation уже давным-давно не только http-сервер


Я в курсе. Но там речь шла про какие то доработки, связанные с апачем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[47]: Кнут о компонентном программировании.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.07.09 10:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

E>>Apache Foundation уже давным-давно не только http-сервер


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


http://port25.technet.com/archive/2008/07/25/oscon2008.aspx

It is not a move away from IIS as Microsoft’s strategic web server technology. We have invested significantly in refactoring and adding new, state-of-the-art features to IIS, including support for PHP. We will continue to invest in IIS for the long term and are currently under way with development of IIS 8.


Может они инвестируют в какие-то эксперименты с PHP под Apache+Windows для того, чтобы потом результаты этих экспериментов использовать в IIS (поскольку Apache-вская лицензия разрешает брать куски кода и вставлять их куда вздумается).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[43]: Кнут о компонентном программировании.
От: WFrag США  
Дата: 20.07.09 10:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну и совсем будет здорово подумать об успехе идеологии OpenSource. Правда, это рискованно — можно, к примеру, додуматься до того, что статистика использования Апача никакого отношения к "идеологии OpenSource" не имеет. Вот те 60%, которые там нарисованы — это что, "поредактированный" Apache? Нихрена, это тот самый blackbox, вытянутый из репозитория и запущенный в неизменном виде.


Из какого именно репозитория? А тот же это самый Apache, что раздают на сайте http://httpd.apache.org/?
Re[48]: Кнут о компонентном программировании.
От: IB Австрия http://rsdn.ru
Дата: 20.07.09 11:04
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Настоящему мужчине всегда есть что возразить?

Хочешь поговорить о настоящих мужчинах? Тогда тебе куда-нибудь сюда: http://www.mhealth.ru/
Здесь все-таки форум немного о другом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[48]: Кнут о компонентном программировании.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.07.09 11:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>Может они инвестируют в какие-то эксперименты с PHP под Apache+Windows для того, чтобы потом результаты этих экспериментов использовать в IIS (поскольку Apache-вская лицензия разрешает брать куски кода и вставлять их куда вздумается).


Да нет, все проще — Апач сам по себе особой конкуренции МС не составляет. Даже если, гипотетически, предположить, что Апач полностью вытеснит IIS, МС от этого особо не пострадает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[38]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.08.09 03:43
Оценка:
Здравствуйте, WFrag, Вы писали:
WF>Да? А на мой взгляд, этим как минимум каждый дистрибутив занимается.
Да неужели? И какие дистрибутивы распространяют, к примеру, апач или мускул, существенно отличные от стандартной версии?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.08.09 08:23
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Речь о том, что у них есть возможность взять исходники, заточить под себя и выпустить продукт. Меняют они исходники существенно или нет — не важно. Важно то, что они это делают. А ты вдруг говоришь, что «эта техника has proven generally ineffective», в то время как половина смысла существования дистрибутивов Linux-а именно в этом затачивании под себя

Ок. Пусть будет половина смысла от дистрибутивов.
Сколько у нас есть этих дистрибутивов? Пара десятков? Сотня? А сколько есть всего опенсорсных проектов? Вот в их существовании какую долю смысла будет занимать затачивание, а какую — зависимость от black box? Поэтому я и говорю — generally ineffective. Да, в некоторых узких, частных случаях эта техника всё еще применяется.

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

Ну вот, допустим, завтра в РФ официально разрешат браки мужчин с деревьями. И что, это автоматически сделает модель нашего законодательства более правильной? Будет ли главным наличие этой возможности? Даже если двадцать-тридцать фанатов таки зарегистрируют такие браки?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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[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[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[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.

Ну Кнут таки говорил не о копи/паст, а о том, что ему больше нравится наличие сорцов, чем наличие чёрных коробок.
Re[27]: Кнут о компонентном программировании.
От: master_of_shadows Беларусь  
Дата: 04.08.09 14:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

Как-то я не понял вот это:

S>Вообще-то да. Потому что у меня, к примеру, неоднократно встречались случаи типа "есть бага, выпущенная в минорном релизе OpenSource 3rdparty, из-за которой мы валимся. Сабмиттить патч — дело бесполезное, потому что

S>а) у нас нет экспертизы в исходниках этой 3rdparty, чтобы этот патч сделать
S>б) даже если мы его сделаем, нужно убедить маинтейнеров включить его в следующий релиз
S>в) даже если патч войдет куда надо, надо дождаться, пока маинтейнеры дистрибутивов заапрувят его в стабильные ветки
S>г) когда это случится, в стабильную ветку попадёт еще масса изменений, которые потребуют повторного тестирования совместимости на нашей стороне
S>д) и если там есть изменения, ломающие обратную совместимость, нам придётся выпускать дополнительный релиз

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


Если ваша команда не может починить багу в 3rd party, то чем тут поможет black box? Один фиг результат тот же — апликация не работает с тем-то и тем-то.
В случае с закрытым продуктом будет всё то же самое, но без пунктов а-б. Где разница то ?
Re[29]: Кнут о компонентном программировании.
От: WFrag США  
Дата: 05.08.09 03:39
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну, в случае с коммерческим продуктом по крайней мере есть кто-то, кто отвечает за саппорт.

S>Впрочем, это неважно — фишка как раз в том, что разницы нет. Об ээтом я и говорю — для большинства потребителей Open Source возможность reedit-а исходников совершенно абстрактна. Поэтому считать её "неотъемлемой основой" я не хочу.

Опять же, она не абстрактна для тех, кто предоставляет этим потребителям саппорт.

Это так же, как не считать забой скота «неотъемлемой основой» мясопроизводства. А что, ведь большинству потребителей возможность заколоть свинью совершенно абстрактна. Утрирую, конечно.
Re[29]: Кнут о компонентном программировании.
От: master_of_shadows Беларусь  
Дата: 05.08.09 06:05
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну, в случае с коммерческим продуктом по крайней мере есть кто-то, кто отвечает за саппорт.


У части опенсорсов то же есть сапорт за денежку. Только отстёгивай.

S>Впрочем, это неважно — фишка как раз в том, что разницы нет. Об ээтом я и говорю — для большинства потребителей Open Source возможность reedit-а исходников совершенно абстрактна. Поэтому считать её "неотъемлемой основой" я не хочу.


Для большинства потребителей комерческих продуктов саапорт то же не "неотъемлиая часть". Сужу точно так же по себе — ни разу в саппорт не обращался .
Проекты с лицензий конечно же.
Re[38]: И книги по музыке делают в LaTeX!
От: SergeCpp Россия http://zoozahita.ru
Дата: 08.08.09 15:42
Оценка:
Здравствуйте, eao197!

E>О как странно, но большое количество документации разного рода до сих пор делается в разных вариантах TeX-а.


И книги по музыке!

Вот Sample (от издательства) PDF-Book'а Bach: The Goldberg Variations / Peter Williams (или такая ссылка)

Там на 2 странице файла написано: System LaTeX 2e
http://zoozahita.ruБездомные животные Екатеринбурга ищут хозяев
Re[39]: И книги по музыке делают в LaTeX!
От: SergeCpp Россия http://zoozahita.ru
Дата: 08.08.09 16:57
Оценка:
Вот ещё одна (весьма солидная) книга: Music: a Mathematical Offering



В PDF-файле есть текст: Creator(LaTeX with hyperref package)
http://zoozahita.ruБездомные животные Екатеринбурга ищут хозяев
Re[14]: ROFL
От: 4058  
Дата: 10.08.09 13:56
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>...Я, конечно, понимаю, что Кнут не стал бы заниматься «такой приземленной „ерундой“» вроде компонентов для преобразования текста в PDF,


Здесь допущена одна очень важная ошибка, т.к. речь идет не о преобразовании просто текста в PDF, а о преобразовании HTML+CSS2.0[+JS] в PDF, и если делать это "с нуля" (да на коленке), то даже за пол года положительных результатов ждать не приходитя.
К тому-же TeX, не является нечто запредельным, что на столько уж далеко от "приземленной ерунды" вроде HTML->PDF.

RO>но предположив на минутку, что он задался бы такой целью, какие твои прогнозы насчет его (теоретической, конечно) конкурентоспособности с вышеупомянутым компонентом, который, с одной стороны, хорошо отлажен («хорошо отлажен» — это сколько известных багов?)


За несколько лет в процессе пром. эсплуатации было замечено около 3-х незначительных бага, причем появлялись они на очень сложных (дизайнерски) формах. Поток — под миллион печатных бланков в год, поэтому все это, как капля в море...

P.S. За прогнозами к метеорологам.
Re[11]: Кнут о компонентном программировании.
От: Erop Россия  
Дата: 10.08.09 16:37
Оценка:
Здравствуйте, thesz, Вы писали:

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

E>>Или, ещё хитрее: "скорее всего выиграет у последней доступной версии программы-конкурента"...
T>Ранг шахматиста — его тип, — как раз и указывает на вероятность выигрыша у шахматиста другого ранга.

Это всего лишь другое название требования "играет не хуже первого взрослого разряда".
Ты это требование в системе типов вырази
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: Кнут о компонентном программировании.
От: Воронков Василий Россия  
Дата: 10.08.09 18:06
Оценка:
Здравствуйте, eao197, Вы писали:

Предположим, в компании есть отдельная команда, которая занимается разработкой компонент, используемых в других проектах. Данные компоненты никогда не меняются в рамках отдельных проектов, однако разработавшая их команда осуществляет поддержку, исправляет баги, добавляет фичи.
Это "в терминах Кнута" reusable или reeditable код?

Когда ответите на этот вопрос, можем перейти ко второму.

Предположим, есть некая специализированная компания, которая занимается разработкой компонент...
Re[17]: Как оно обычно бывает...
От: Erop Россия  
Дата: 10.08.09 18:26
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Это "в терминах Кнута" reusable или reeditable код?

ВВ>Предположим, есть некая специализированная компания, которая занимается разработкой компонент...

Я не eao197, но попробую ответить.
Эти два случая отличаются только формально. Всё сводится к тому, как быстро кто-то будет обрабатывать запросы конкретного проекта.
Если команда/компания готова обеспечить для ВАШЕГО проекта реакцию с нужной ВАШЕМУ проекту скоростью и качеством, то и фиг с ним, с reeditable, а если нет, то reeditable становится остро необходимым...

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

Короче вопрос тупо в контроле. Есть у теюя контроль над ситуацией или нет. И в какой степени он есть...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.08.09 04:52
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


ВВ>Предположим, в компании есть отдельная команда, которая занимается разработкой компонент, используемых в других проектах. Данные компоненты никогда не меняются в рамках отдельных проектов, однако разработавшая их команда осуществляет поддержку, исправляет баги, добавляет фичи.

ВВ>Это "в терминах Кнута" reusable или reeditable код?
Конечно же reusable. Поскольку все проекты используют этот код как чёрный ящик.
Reeditable был бы в том случае, если бы проектная команда брала исходники компонента и допиливала под себя.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Кнут о компонентном программировании.
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.08.09 08:33
Оценка:
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Где ты видишь черный ящик? Код доступен, можешь его посмотреть да и вообще-то говоря он вполне изменяемый — просто есть разделение труда, его допиливает отдельная команда.
Как где? В проекте.
В коде, который использует этот компонент, никаких его внутренних особенностей не применяется.
Никакого "допиливания" проектная команда не делает. Если есть нужда доточить компонент — формируется просьба, и поверхность чёрного ящика пересматривается.
Ключевой момент здесь — в том, что изменения вносятся централизованно. В частности, если команде Б нужны какие-то фичи от команды А, то команда А при их реализации следит за тем, чтобы фичи для команды В не отвалились.

В случае reeditable команда Б имеет полную свободу действий — ей не нужно поддерживать совместимость с требованиями В (о которой Б вообще ничего не знает):
1. Можно использовать компонент как белый ящик, т.е. влезть ему вовнутрь и заточиться на его устройство. Поскольку мы не планируем ни с кем совместно использовать код, у нас нет риска напороться на независимо произведённые изменения
2. Можно вносить какие угодно исправления, опять же потому, что мы не планируем никому их отдавать.

Всё. Любое совместное использование кода моментально отбрасывает вариант с reeditable, оставляя только black box. Потому что иначе невозможно конструктивно вносить изменения.

ВВ>Вариант, который защищают сторонники reeditable, это плодить кучу несвязанных модификаций, которые не смогут нормально поддерживать ни первоначальные разработчики, ни те, кто меняли, так как их знание о работе кода как правило весьма поверхностное?

Да, совершенно верно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.08.09 09:05
Оценка:
Здравствуйте, Erop, Вы писали:

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


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

E>>>Или, ещё хитрее: "скорее всего выиграет у последней доступной версии программы-конкурента"...
T>>Ранг шахматиста — его тип, — как раз и указывает на вероятность выигрыша у шахматиста другого ранга.

E>Это всего лишь другое название требования "играет не хуже первого взрослого разряда".

E>Ты это требование в системе типов вырази

В чём проблема?

Тип будет долго проверяться — надо считать вероятность выигрыша, — но тем не менее он существует.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Кнут о компонентном программировании.
От: Erop Россия  
Дата: 11.08.09 09:32
Оценка:
Здравствуйте, thesz, Вы писали:


E>>Это всего лишь другое название требования "играет не хуже первого взрослого разряда".

E>>Ты это требование в системе типов вырази

T>В чём проблема?

T>Тип будет долго проверяться — надо считать вероятность выигрыша, — но тем не менее он существует.
1) Что-то как-то терзают меня смутные сомнения, что это вообще возможно -- аналитически посчитать вероятность выигрыша.
2) Тебе тут про то и говорят, что есть требования, которые на языке тестов выражаются просто, а на языке типов -- нет...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[19]: Я ж вам писал, всего строкою выше...
От: Erop Россия  
Дата: 11.08.09 09:43
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вариант, который защищают сторонники reeditable, это плодить кучу несвязанных модификаций, которые не смогут нормально поддерживать ни первоначальные разработчики, ни те, кто меняли, так как их знание о работе кода как правило весьма поверхностное?


Нет, есть ещё и другие варианты!
Например, команда "Б" может поправить то, что им надо, если им быстрее самим так сделать, и выставить фичереквест команды "А". Задача команды "Б" проще, так как им нужно учесть только контекст своей задачи, задача команды "А" сложнее, так как им надо предусмотреть все последствия во всём клиентском коде. Это может привести к тому, что фича будет немного не такая, как хотели в "Б", или её вообще не будет.
Тогда у "Б" будет выбор -- обойтись без этой фичи, или перейти на "не совсем такую", или вообще начать поддерживать форкнутую версию.
Последнее, если речь идёт о командах внутри одной конторы, обычно редко происходит. А вот если команда "А" -- это разработчики MFC, например, то много какие продукты таскали за собой пропатченную MFC, и все вроде бы рады были такой возможности...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: Кнут о компонентном программировании.
От: thesz Россия http://thesz.livejournal.com
Дата: 11.08.09 10:01
Оценка:
Здравствуйте, Erop, Вы писали:

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


E>>>Это всего лишь другое название требования "играет не хуже первого взрослого разряда".

E>>>Ты это требование в системе типов вырази

T>>В чём проблема?

T>>Тип будет долго проверяться — надо считать вероятность выигрыша, — но тем не менее он существует.
E>1) Что-то как-то терзают меня смутные сомнения, что это вообще возможно -- аналитически посчитать вероятность выигрыша.

Можно и эмпирически.

E>2) Тебе тут про то и говорят, что есть требования, которые на языке тестов выражаются просто, а на языке типов -- нет...


Типы включают в себя тесты. Но не наоборот.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Кнут о компонентном программировании.
От: Erop Россия  
Дата: 11.08.09 12:47
Оценка:
Здравствуйте, thesz, Вы писали:

T>Можно и эмпирически.

А смысл?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.