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

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

BZ>>да, насчёт говнокода я попал в самую тютельку

VD>То что ты не видел говнокода (или не видишь его в своих проектах) говорит только об одном — ты работаешь один над относительно мелкими проектами.

VD>Говнокод — это обязательный атрибут любого большого, долгоживущего проекта.

которых почти нет на ФП. а ты прям как личное оскорбление это воспринял

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

IT>>Дни? На переименование методов?

VD>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное. Плюс сюда накладывается проблема бутсрипа когда просто переименование не прокатывает и 3 минуты на компиляцию.

IT>>Для переименования поля не нужно тратить день.

VD>Это реальный факт.

Теперь кажется становится ясно, почему ты не можешь без отладчика. Похоже, имеется некий трудно собираемый код, в котором на каждый чих надо ждать по 3 минуты компиляции. Понятно, что тебе проще поправить этот чих прямо в отладчике и продолжить выполнение. Т.е. фактически ты пользуешься не отладчиком как таковым, а edit&continue -- REPL для бедных.

Если код достаточно модульный и нет никакого bootstrapping-а, то пересборка -- это перекомпиляция одного-нескольких модулей. Не надо ждать тонну времени. Соответственно, edit&continue становится менее нужным.

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

MM>При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.

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

Здравствуйте, dr.Chaos, Вы писали:

DC>Угу, только вот найди мне рефакторинг: «перераспределить обязанности между классами и один из них, возможно, выкинь»

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

DC>Ну тут, видимо, опять вопрос в терминологии. Рефакторинг делается перед внесением фичи чтобы облегчить этот процесс.

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

DC>И основной стимул, тут не отсутствие средств (хотя что бы вы знали про vim, sed и awk ), а то что просто переписывание кода — это переливание из пустого в порожнее, т.к. код в итоге будет иметь «идеальную» архитектуру, а заказчик 0 новых функции и столько же багов.

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

DC>Мало того, потом окажется, что архитектура то не идеально и т.п.

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

DC>Основная цель рефаторингов изменить код так, чтоб его было проще менять под текущие и ближайшие цели, т.е. где-то добавить гибкости, где то убавить овердизайна. Ну и что касается твоего поинта: «большие рефакторинги состоят из кучи маленьких», — да, состоят, но по моему опыту занимают они не много времени ( может я их просто не замечаю благодаря «убогим» vim, sed, awk ).

Все зависит от объема проекта, наличия и изменений в целях и запущенности кода.

Здравствуйте, dr.Chaos, Вы писали:

DC>Ну тут, видимо, опять вопрос в терминологии. Рефакторинг делается перед внесением фичи чтобы облегчить этот процесс. И основной стимул, тут не отсутствие средств (хотя что бы вы знали про vim, sed и awk ), а то что просто переписывание кода — это переливание из пустого в порожнее, т.к. код в итоге будет иметь «идеальную» архитектуру, а заказчик 0 новых функции и столько же багов. Мало того, потом окажется, что архитектура то не идеально и т.п. Основная цель рефаторингов изменить код так, чтоб его было проще менять под текущие и ближайшие цели, т.е. где-то добавить гибкости, где то убавить овердизайна. Ну и что касается твоего поинта: «большие рефакторинги состоят из кучи маленьких», — да, состоят, но по моему опыту занимают они не много времени ( может я их просто не замечаю благодаря «убогим» vim, sed, awk ).

А можно ваше определение рефакторинга? Это то, что "делается перед внесением фичи, чтобы облегчить этот процесс"?. Просто если использовать, например, определение из wiki (которое более широкое, чем ваше), у меня получается, что как раз таки большая часть рефакторингов делается не перед внесением фичи а во время или сразу после внесения фичи, после изменения кода. Я в дальнейшем буду использовать термин "рефакторинг" для обозначения "изменения программы без изменения ее фунциональности (или внешнего поведения) с целью улучшения ее качества" (вольный перевод wiki). Если вас не устраивает — готов использовать другое название, только предложите Именно для того определения, которое я привел. Потому что такая активность существует и хочется как-то ее называть.

Все нижеследующее из моего опыта. Основное время пишу на Java, но какие-то вещи (в основном — утилиты разные) пишу на Ocaml. И на том и на другом могу писать как в vim'е, так и в IDE (eclipse JDT и OcaIDE). И всякие мелочи на одну-две сотни строк (эксперименты, примеры и т.п.) пишу именно в vim'e. Могу даже и в notepad'е, но просто неудобно по сравнению с vim'ом. Недавно еще баловался с FlashDevelop. Все это к чему — большая часть привычек выработана в eclipse IDE и я хорошо замечаю, когда мне некоторых функций (рефакторингов!) не хватает в других случаях.

Итак, поехали. Рефакторинги (в моем понимании, см. выше), которые выполняются в процессе или сразу после написания кода. Основная цель всех рефакторингов — "улучшение читаемости" кода. Формально дать определение читаемости сложно, субъективно — возможность просматривать код "по-диагонали", при этом быстро находя те места, которые мне нужны в указанном контексте. Те, что описаны, применяются достаточно часто, значительно чаще, чем остальные рефакторинги. Уж точно по нескольку раз в день, когда я работаю с кодом.

1. "Extract variable". Основное применение — когда части какого-либо сложного выражения хочется дать "человекочитаемое" имя. Для ocaml'а это было бы что-то вроде изменения кода f (f1 + f2 * f3) на let meaningfullName = f2 * f3 in f (f1 + meaningfullName). Вторая польза от такого рефакторинга встречается реже, но все же есть. Она проявляется, если в коде есть две похожие формулы. В этом случае после вынесения двух "переменных" для каждой из формул при чтении будет понятно, какая из двух имелась в виду. Необходимость заводить переменную для части формулы "сразу" не очевидна. Возможно, я формулу беру из ТЗ, составленного экспертами (т.е. на предварительных этапах мне достаточно знать, что формула реализуема в требуемом контексте). Либо изначально была простая формула, после чего к ней дописали одну "фичу", затем вторую и третью. После третьей фичи при взгляде на код стало понятно, что "что-то здесь не так", с одного беглого взгляда получившееся выражение не читается и неплохо было бы его разбить на читаемые части. Причем, как ни странно, делать это нужно сейчас — пока я еще помню, какой смысл несет какая часть формулы. Когда следующий раз придется менять это место, я могу и не вспомнить, что же там было. Придется разбирать формулу, пытаться понять ее значение. Возможно — смотреть ТЗ, справочники и т.п. По месту же — несколько раз "expand selection" + комбинация клавиш. По времени — копейки, дальнейшая экономия может быть вполне заметной. Да и по времени все это сравнимо будет с теми копейками, которые я потрачу на ручное вынесение переменной Так вот, в OcaIDE уже была ситуация, где при наличии автоматических инструментов я бы сделал такой рефакторинг (там два или три раза одно и то же выражение встретилось), только вот нету его. И, что интересно, года за 2, которые я применяю этот рефакторинг, его семантика всегда была "назвать выражение". На java это была final-переменная (галочка ставилась при первом применении рефакторинга и больше никогда не снималась). Т.е. именно "название" для чего-либо, а не "ячейка для хранения данных". В общем, типичная "переменная" из функциональных языков и иммено в такой семантике я и хотел рефакторинг для ocaml'а. Да, еще вспомнил применение — отладочная печать значения подвыражения. Очень естественно делается выделением переменной и добавлением инструкции печати.

2. "Introduce constant". Примерно то же, что первое. Только не для выражения, а для "магического числа". Также отличается тем, где заводится эта константа (для ocaml'а я бы ожидал константу на уровне модуля). Руками делается элементарно, но это нужно сначала сходить в ту область модуля, где лежат все консатны, написать там что-то, затем вернуться обратно. А так — в процессе кодирования пишется "магическое число", из которого затем заводится константа. Называть будем уже сразу по месту. Я, правда, еще хожу в объявление писать документацию (ага, ко всему), но если без этого — некоторый выигрыш. Сам по себе рефакторинг вроде бы несложный и выигрыш незаметный, но запомнился мне потому, что оказался удобен (при работе с протоколами байтовыми) и в то же время был повешен на hotkey. Еще раз повторю — основное применение — "назвать константу".

3. "Extract method". Ну, в общем, опять разновидность первого Только имя хочется дать уже не выражению, а формуле с параметрами. Учитывая вопросы с тем, чем должны быть использованные переменные — частью замыкания или параметрами, сразу скажу, что по умолчанию достаточно было бы их все делать параметрами с возможностью изменить на замыкание в диалоге. Опять же, функция для извлечения может появляться либо при написании из ТЗ, либо в результате эволюции. Для ocaml'а такой рефакторинг бы применялся, например, в случаях let a = if somecond1 then if somecond2 then value1 else value2 else if somecond3 then if somecond4 then value3 else value4 как части более сложной конструкции (другой функции, например). Достаточно большая часть вынесения методов на java у меня приходится именно на такой случай — заводим переменную и в зависимости от разных условий ее инициализируем. Да, выглядит по-другому, суть примерно та же. Есть еще часть случаев, когда идет императивщина (но в ocaml'е я тоже ее могу сделать), но и без нее достаточно случаев применимости. В ocaml'е сам видел ситуацию, когда такой рефакторинг помог бы. Причем родилось такое место в результате исправления ошибок. Сначала было два места, в которых делались похожие "элементарные" вещи. Что-то вроде "a + b", которые выносить в метод вроде бы было неоправданно. После пробных запусков я понял, что у меня логическая ошибка и нужно бы подправить код. Оказалось, что похожая ошибка была и во втором месте. На этом дело не закончилось, нашлась еще одна логическая ошибка. Итого — в двух местах "на ровном месте" у меня вырос патч двух логических ошибок. Сам по себе он было нормален, но появлялось дублирование да и исходные функции становились уже великоваты. Был бы удобный инструмент для рефакторинга — было бы совсем хорошо. А так — не было, но и код мне нужен был на один раз, поэтому все так и осталось жить. Итого — на самом деле у нас рефакторинг "назвать функцию или кусок кода человеческим именем", чтобы не приходилось "компилировать" этот код в его семантику.

4. "Rename something". Имя говорит само за себя. Используется, когда становится ясно, что имя неточно отражает значение, например. Опять же, образоваться имя может разными способами. Например, в результате дописывания фич, когда каждое изменение меняет семантику совсем чуть-чуть, но в результате значение переменной уже сильно отличается от ее названия. Еще один случай — когда оказывается, что методы в одинаковых ситуациях называются немного по-разному. Прекрасно ловится на этапе кодирования и там же прекрасно все переименовывается (пока еще не затронуло кучу пользователей). Применяется ко всему — и к локальным переменным, и к методам, и к классам. В ocaml'е вполне могло бы применяться к именам функций или модулей.

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

Про рефакторинги поговорили, теперь перейдем к месту IDE в этом процессе. Я полностью согласен, что все эти рефакторинги в рассматриваемых ситуациях делаются легко вручную (rename something может быть сложнее, но ничего экстраординарного там нет). Первые три можно даже попробовать в текстовом редакторе реализовать. Первые два даже и не слишком сложно будет сделать (для vim), и это покроет большинство случаев применения. Только вот не в сложности или скорости здесь дело. Если посмотреть то, что я написал выше, получается, что я использую операции "назвать результат формулы", "назвать константу", "назвать функцию", "исправить имя aka rename". Эти операции фактически являются (реализованы с помощью) соответствующими рефакторингами. Ну а рефакторинги в качестве механизма уже перемещают блоки текста или чего там еще использует IDE. Все четыре операции имеют соответствующие комбинации горячих клавиш. В результате на 4-х комбинациях я имею 4 операции. Высокоуровневых операции, описываемых в терминах конструкций языка. Т.е. я не просто куда-то переношу куски текста, я выполняю некоторую вполне осмысленную и "высокоуровневую" трансформацию программы. Да, я могу сам выполнить и все низкоуровневые операции с кусками текста, но зачем? Ведь в языках же, наоборот, стремятся к большей выразительности при меньшем количестве кода. Ну да, мы получаем большую выразительность и "высокоуровневые" термины для написания программ. Но в IDE я также получаю "высокоуровневые" операции для манипуляции над программами. Т.е. не просто скопировать блок кода, а именно "перенести метод", например. Или 4 указанных операции. Детали реализации этих операций меня не сильно интересуют. А манипуляции существующим кодом в ряде отраслей важны. На самом деле это практически вся автоматизация бизнеса с ее изменениями требований и прочим, когда важно не только то, что написано сейчас, но и как из того, что было вчера сделать то, что нужно сегодня. Из-за непредсказуемости требований это тоже имеет свой fun. И для решения этих задач используются соответствующие инструменты (те же IDE). Причем, что интересно, вполне может быть, что требования к возможности изменения кода как раз гораздо выше, чем требования к его выразительности. Т.е. требования меняются часто и нам важна вся инфраструктура, возможности найти места для изменений в огромной кодовой базе и т.п. Поэтому в данном случае вопрос о наличии и возможностях IDE будет очень и очень актуален.

Немного напишу про упомянутцй "expand selection", который используется для 1-го и 3-го рефакторингов. Это расширение существующего выделения на логические блоки кода, уже содержащего выделение. Возможный пример для ocaml'а: исходная конструкция let a = if b > 0 then c + d else let e = c-d in e * e, исходное выделение — первая e в выражении e * e. Выделения при очередных расширениях:

1. e * (для выделения метода или переменной, например)
   
2. e * e
   
3. let e = ...
   
4. if b > ...
   
5. let a = ...

Опять же, мелочи, но для подготовки к рефакторингам очень удобно. Не нужно глазками искать начало блока, конец, тянуть выделение. Всего лишь контролируется, что "по дереву языка" мы пришли в то место, которое нам нужно и над которым выполняется операция. Опять же, я команды отдаю не в терминах "текстового редактора", а в терминах языка, его грамматики. Примерно того же рода копирование "фрагмента кода" в другой код. Мелочь, но import'ы для java тянутся и автоматически появляются в новом месте. А вот будет ли в OcaIDE что-нибудь сделано, когда я скопирую кусок из одного файла в другой (не помню, где собранная лежит дома, а для мелочей хватает и vim'а)? А и исходном файле у меня могли быть #open вначале, поэтому не все можно оставить как есть, нужно либо имя модуля дописать првы вызовах, либо директивы #open в целевом файле. Мне с "кодом" работать все же приятнее, чем с "текстовым представлением этого кода".

Ну и напоследок про «перераспределить обязанности между классами и один из них, возможно, выкинь». В таком виде рефакторинга нет. Он будет выполняться с помощью нескольких более простых. А вот в каких терминах мы будем работать при этих мелких рефакторингах — это большой вопрос. Можно таскать "куски текста" (понимая под этим перемещение метода, например). Только вот при этом нужно контролировать, что все зависимости утянуты и т.п. Возможно, метод менять (если часть методов осталось в одном классе, а часть уехала). А можно сказать, что "вот этот метод должен уехать в тот класс". При этом IDE может проверить зависимости (например, скажет, что ссылки остались на приватный метод и видимость ему нужно поменять), сама поменяет все ссылки на функции в исходном коде. При перемещении метода вверх в иерархии классов можно одним кликом сказать "добавить зависимости", проверить их и продолжить операцию. Ну да, наверное, все равно какие-то мелочи придется сделать "в тексте руками". Но если не все плохо, это будет малая часть. А большая часть будет в реорганизации структуры, фрагментов программы.

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

IT>>По всей видимости вы вместе со твоей практикой вещи просто уникальные. Вымирающий вид. Любой краеведческий музей через десять лет выделит для вас не то что полку, целый стеллаж!

T>Наоборот.
T>Мы племя младое, незнакомое!

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

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

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

MM>>>При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.

T>>Конструктор — та же функция, и я не вижу причин, по которым я могу экспортировать функцию и не могу конструктор.

MM>Ну, блин...

MM>Вот у тебя в одном модуле написано
MM>А в другом
MM>Внезапно ты обнаружил, что тип нужно сделать более общим:
MM>Ищи его теперь в модуле B.

Неужто мне при компиляции про ошибки не скажут?

Неужто ты баг в ghc нашёл?

MM>И в B ничего менять не надо.

Это если они сводимы друг к другу.

T>>Только жизнь себе усложню.
MM>Как обычно — немного усложнишь поначалу, зато облегчишь потом.

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

После фиксации структуры я могу произвести преобразования типа описанного тобой.

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

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

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

IT>>>По всей видимости вы вместе со твоей практикой вещи просто уникальные. Вымирающий вид. Любой краеведческий музей через десять лет выделит для вас не то что полку, целый стеллаж!

T>>Наоборот.
T>>Мы племя младое, незнакомое!

IT>Это племя известно науке со времён возникновения самой науки. Имя этому племени "Первый парень на деревне". Характерные особенности: красный диплом (или как минимум красные глаза от учёбы) в институте (опционально), длительная работа в замкнутом окружении в качестве главной/самой важной персоны, в результате завышенная самооценка и непоколебимая уверенность в собственной гениальности, неумение и нежелание работать в команде равных, переходящие в паническую боязнь.

Да, мне известны такие товарищи.

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

Особенно мне было приятно, когда мои коллеги высоко отозвались о моём умении работать в команде. Лично я думал, что я хреновый командный игрок, ан нет!

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

IT>>Дни? На переименование методов?
VD>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное. Плюс сюда накладывается проблема бутсрипа когда просто переименование не прокатывает и 3 минуты на компиляцию.

Вот "плюс сюда накладывается" и есть самая большая проблема. А само по себе переименование не такая уж и большая.

IT>>Для переименования поля не нужно тратить день.
VD>Это реальный факт.

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

IT>>Объём каких работ? Влад, вот давай эксперимент, в следующий раз, когда ты потратишь день на какую-нибудь мелочь, ты расскажешь нам как-бы ты это делал с помощью автоматических средств рефакторинга. OK?
VD>Могу описать тебе задачу и посмеяться над тем как ты будешь ее решать. В прочем я уже дал подсказку которая может сэкономит пол дня.

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

Впрочем, всё это не важно. Я отвечал на твой вопрос, что важнее язык или IDE. И смысл сказанного заключался в том, что IDE здорово помогает получать быстрые типовые решения. Особенно это было доведено до совершенства в Дельфи. Но после определённого момента IDE перестаёт играть столько важную роль и на первый план выходят возможности и выразительность языка.

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

MM>>Ищи его теперь в модуле B.

T>Неужто мне при компиляции про ошибки не скажут?

При компиляции чего? Модуля A — не скажут. Модуля B — скажут. Через несколько дней. Когда у тебя до него руки дойдут.

MM>>И в B ничего менять не надо.

T>Это если они сводимы друг к другу.

Естественно.

Именно поэтому экспортировать структуру данных — не стоит. Лучше экспортировать необходимый минимум. Если нужно что-то ещё — доэкспортируешь. Зато минимализм означает, что то, что есть сейчас, с хорошей вероятностью сводимо к тому, что нужно потом.

MM>>Как обычно — немного усложнишь поначалу, зато облегчишь потом.

T>Если у меня структура данных меняется (а она меняется на протяжении всего проекта, практически), то это "немного усложнишь поначалу" означает постоянное повышение сложности на всём времени проекта.

T>После фиксации структуры я могу произвести преобразования типа описанного тобой.

Поясни. Я думал, что это преобразование как раз означает СМЕНУ структуры данных.

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

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

MM>>>Ищи его теперь в модуле B.
T>>Неужто мне при компиляции про ошибки не скажут?
MM>При компиляции чего? Модуля A — не скажут. Модуля B — скажут. Через несколько дней. Когда у тебя до него руки дойдут.

У меня несколько циклов: микроцикл с исправлением ошибок компилятора, малый цикл с REPL, базовый цикл с тестированием программы на каких-то моих функциональных тестах и далее идёт использование.

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

Есть у нас различие в подходах к разработке?

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

T>Есть у нас различие в подходах к разработке?

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

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

VD>Да, как-то мелкие довольно редко попадаются. 200 файлов — норма. Были проекты в которых было файлов по 10000 файлов. Полная перекомпиляция — 40 минут.

на чем (какой язык)?

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

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

T>>Есть у нас различие в подходах к разработке?

MM>Ты никогда не делаешь библиотек, которыми будут пользоваться другие?

Вот тогда я иногда делаю так, как ты сказал.

Но если у меня AST на 20+ типов, я его лучше так таскать буду.

Как это делают другие: http://haskell.org/ghc/docs/latest/html/libraries/haskell-src/Language-Haskell-Syntax.html которые поумней меня будут.

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

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

T>>Есть у нас различие в подходах к разработке?

MM>Ты никогда не делаешь библиотек, которыми будут пользоваться другие?

Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).

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

MM>>Ты никогда не делаешь библиотек, которыми будут пользоваться другие?

T>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).

Чем хорошо фундаментальное математическое образование — приучает плевать на любые авторитеты с высокой колокольни.

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

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

MM>>>Ты никогда не делаешь библиотек, которыми будут пользоваться другие?

T>>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).

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

То есть, ты не согласен.

Каковы твои аргументы?

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

FR>>>Функциональная же простые функции и ФВП работающие со сложными типами данных, плюс сложные параметризованные модули плюс потоки.

А>>Хотелось бы конкретных примеров. Пока больше похоже на утверждение, что некоторое масло более масленное, чем какое-то другое.

M> Отличный пример функциональной декомпозиции был в журнале "Практика функционального программирования", про игру в шашки. Подробненько так, шаг за шагом.

Ничего уникального не увидел -- обычный структурный подход "сверху вниз". Для тех, кто начинал программировать на языках типа Фортран/Бейсик или Паскаль/Модула, там ничего нового. Разве что Haskell позволяет типы сразу не писать.

Так что ждем-с примеров функциональной декомпозиции.

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

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

MM>>>Ты никогда не делаешь библиотек, которыми будут пользоваться другие?

T>>Будем бить авторитетом: The disadvantage is that pattern matching, which is so useful, cannot be used on abstract data types (страница 8).

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

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

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

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

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

Это если ты мыслишь в рамках этих операций.

VD>Не, рефакторинг делается тогда когда программист понимает, что текущее устройство кода отличается от его текущих воззрений.

Воззрений на что? На решаемую задачу? Или на ориентацию идентификаторов по Фен Шую?


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

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

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

Я об этом и говорю, ты упростил себе жизнь (сделал вообще возможным) добавление фичи/исправление бага.

DC>>Основная цель рефаторингов изменить код так, чтоб его было проще менять под текущие и ближайшие цели, т.е. где-то добавить гибкости, где то убавить овердизайна. Ну и что касается твоего поинта: «большие рефакторинги состоят из кучи маленьких», — да, состоят, но по моему опыту занимают они не много времени ( может я их просто не замечаю благодаря «убогим» vim, sed, awk ).

VD>Все зависит от объема проекта, наличия и изменений в целях и запущенности кода.

Влад, мне привести объём проекта в котором я работаю в мегабайтах?