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

T>>>Это же единовременное вложение, nes pa?
G>>Вряд ли, создание DSL под каждую задачу единовременным не будет.
G>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты.

T>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency.
T>Это создание единовременно.

T>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса.

"и одним легким движеньем брюки..." (с)классика
можете привести пример (пример!) где используются 2 dsl и фраза "потом соединяешь их" не превращается в создание 3го dsl с выбрасыванием первых 2х.

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

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

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

K>Поддержу. Приемлимый уровень качества, за приемлимое время.

K>Автоматизированное (заметте не unit) тестирование это прекрасный способ достижения приемлимого компромисса.

K>А если бы все так простоы было с DSL, то у нас бы дааавным давно мейнстрим компиляторы детектировали дедлоки,
K>так же легко как и несоответсвие типов.

Мейнстрим-не-мейнстрим, а проверяют.

http://spinroot.com/spin/whatispin.html#A
http://www.kernel.org/pub/software/devel/sparse/
http://mtc.epfl.ch/software-tools/blast/

K>Но вот Ericson посчитали для себя обе перечеслинных проблемы неактуальными.

У них есть возможность бросать на проект большое количество программистов. Например, над AXD301 (или как он там) в конце проекта работало больше 100 человек (чуть ли не 150.

Для контор, где количество программистов на проект раз в двадцать меньше (5-7), этот метод не применим.

T>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса.

SD>"и одним легким движеньем брюки..." (с)классика
SD>можете привести пример (пример!) где используются 2 dsl и фраза "потом соединяешь их" не превращается в создание 3го dsl с выбрасыванием первых 2х.

Если говорить о DSEL (язык, встроенный в язык), то таких примеров навалом.

Монады — один DSEL, разбор — другой, использующий абстракцию первого. Вешаем на разбор проверку типов — pBinExpr = do {x <- pexpr; op <- pbinop; y <- pExprAsType x; return $ op x y} — получается третий, строго типизированый разбор.

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

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

T>>>>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса.
G>>>>Только читаемость в таком случае падает до 0.
T>>>Это ты с чего взял?
T>>>Неужто из опыта? 8O
G>>Именно из опыта общения с различными с DSL.
T>DSL или DSEL?
Больше с обычными DSL и несколькими DSEL (на Ruby).

G>>>>Связанные с concurrency.
T>>>То есть, ты умеешь тестировать на дедлоки. Или нет?
G>>Нет, я умею их находить.
T>А как ты их находишь?
Логи+дебаггер, как любые ошибки.

T>>>>>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих.
G>>>>Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL.
T>>>С доказанным 100% отсутствием — невозможно.
G>>А нужно ли оно? Потребителя интересуют не идеальные программы, а те которые имеют приемлимый уровень качества.
G>>Если этот уровень качества достигается гораздо более простыми средствами, то лучше использовать их.

T>"Простыми" в каком смысле?
T>Если в смысле "я уже умею так делать", это да. Проще.
В смысле "меньше думать и меньше писать".

T>Если в смысле "затраченных усилий" на единицу кода на длительном промежутке времени, то нет, не проще.
Тут стоит учитывать сумму по всем задачам, а то может выйти так что выигрываем в одном, а в другом проигрываем.

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

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

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

Тебе шашечки, или ехать?

T>>DSL или DSEL?
G>Больше с обычными DSL и несколькими DSEL (на Ruby).

Нашёл, кого в пример брать.

G>>>>>Связанные с concurrency.
T>>>>То есть, ты умеешь тестировать на дедлоки. Или нет?
G>>>Нет, я умею их находить.
T>>А как ты их находишь?
G>Логи+дебаггер, как любые ошибки.

А почему не можешь оттестировать?

T>>"Простыми" в каком смысле?
T>>Если в смысле "я уже умею так делать", это да. Проще.
G>В смысле "меньше думать и меньше писать".

"Меньше писать" это ты для красного словца, так?

T>>Если в смысле "затраченных усилий" на единицу кода на длительном промежутке времени, то нет, не проще.
G>Тут стоит учитывать сумму по всем задачам, а то может выйти так что выигрываем в одном, а в другом проигрываем.

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

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

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

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

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

T>Тебе шашечки, или ехать?
Дык мне именно "ехать".
Создание DSL пока что попадает в разряд шашечек.

G>>>>>>Связанные с concurrency.
T>>>>>То есть, ты умеешь тестировать на дедлоки. Или нет?
G>>>>Нет, я умею их находить.
T>>>А как ты их находишь?
G>>Логи+дебаггер, как любые ошибки.
T>А почему не можешь оттестировать?
Потому что воссоздать окружение, гарарнтированное приводящее к дедлоку не всегда возможно, а даже когда возможно, то не всегда за приемлимое время

T>>>"Простыми" в каком смысле?
T>>>Если в смысле "я уже умею так делать", это да. Проще.
G>>В смысле "меньше думать и меньше писать".
T>"Меньше писать" это ты для красного словца, так?
Нет

T>>>>Да его вариант на Хаскеле делается за, не знаю, два дня.
T>>>>Тоже мне, "дороже".
G>>>Тут наверное все и так знают что у хаскеля пиписька длиннее.
G>>>Хотелось бы видеть пример на мйнстримовом языке.
T>>Тебе шашечки, или ехать?
G>Дык мне именно "ехать".
G>Создание DSL пока что попадает в разряд шашечек.

В Одессе времен начала перестройки рассказывали такую историю. Некая дама выходит из здания аэровокзала. Носильщик везет за ней груду чемоданов и коробок. Дама восклицает: “Такси, такси!” Подъезжает легковушка, дама не обращает на нее внимания, продолжая покрикивать: “Такси, такси!” Легковушку перехватывает другой пассажир, к даме подъезжает еще одна машина, дама упускает и эту. Из третьей машины высовывается водитель: “Мадам, вам шашечки или ехать?”

В контексте данного обсуждения "ехать" — это использовать DSEL для 100%-го отсутствия ошибок. Я сомневаюсь, что мои слова можно толковать как-либо по-другому.

"Ехать с шашечками" — это использовать DSEL на мейнстримовом языке для 100%-го отсутствия ошибок.

Наличие шашечек для тебя важнее, чем сам процесс перемещения.

G>>>>>>>Связанные с concurrency.
T>>>>>>То есть, ты умеешь тестировать на дедлоки. Или нет?
G>>>>>Нет, я умею их находить.
T>>>>А как ты их находишь?
G>>>Логи+дебаггер, как любые ошибки.
T>>А почему не можешь оттестировать?
G>Потому что воссоздать окружение, гарарнтированное приводящее к дедлоку не всегда возможно, а даже когда возможно, то не всегда за приемлимое время

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

Киваешь на начальство, которое это одобряет.

T>>>>"Простыми" в каком смысле?
T>>>>Если в смысле "я уже умею так делать", это да. Проще.
G>>>В смысле "меньше думать и меньше писать".
T>>"Меньше писать" это ты для красного словца, так?
G>Нет

Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь?

Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню.

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

N> Да, TDD примитивно. А теперь посмотрите чуть с другой стороны: что даёт TDD (в строгом понимании)? ......
N>ЭТО КРИТЕРИИ УСПЕШНОГО ФУНКЦИОНИРОВАНИЯ ДЛЯ МЕНЕДЖМЕНТА. Точка.

Ну так мы ж не про то, как отвязаться от начальства! Мы про методы тестирования программ, в часности TDD. Насколько я сужу по общей температуре больницы, народ перегрелся на unit testing, даже как-то и не задумываясь о его слабой применимости к сложным системам. Да чего там сложным, "морда к базе" с транзакциями — и то уже проблема!

N>2. Насколько тесты адекватны поставленному ТЗ. Тут уже дело постановщика делать это адекватно. Но тем не менее тесты будут использоваться потому, что они отделены от реализации и для них не нужно лезть в реализацию

Это смотря какой уровень качества вы хотите гарантировать. Допустим, вы даёте на вход А, должны получить Б. Тест проходит на ура, но что, если подали Х? Это усложнение теста и тестирующий просто обязан знать как система должна отреагировать на "мусор" и _проверить_ это. А если "неправильное Х" ещё и должно быть отослано по мылу? (Хотел бы я видеть такой тест!) У меня башка идёт кругом от тех вариаций, которые могут провалить тест! Воистину, только от немногих знаний можно так оптимистично смотреть на unit testing.

M>>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.

N>Так ветка-то не про них.

Как это не про них??? Читаем исходное сообщение:

>В последнее время сталкиваюсь с большим колличеством советов обязательно использовать unit testing — проскакивает во многих подкастах .NET Rocks и Hanselminutes,...

Вот про этих "подкастоболов" и речь. Человек даже гуглом не стал ограничиваться — написал на форум, узнать как РЕАЛЬНО обстоят дела. На мой параноидальный взгляд, проходит "организованная шумиха" вокруг технологии, заслуживающей максимум упоминания на лекции. "Fire and motion" в действии, фигли...

Здравствуйте, thesz, Вы писали:
T>Ну, вырази контракт "не должно быть deadlock".
Есть формальные критерии дедлока
T>А теперь напиши тест, который это проверяет.
А вот с этим — облом. Можно сделать либо язык/среду, в которой дедлоки в принципе невозможны (дийкстра, гармонически взаимодействующие процессы. Сиомега, рандеву.), и тогда всё доказуемо статически. Либо дедлок возможен, и вместо теста будет контр-тест.

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

Здравствуйте, matumba, Вы писали:
M>Ну так мы ж не про то, как отвязаться от начальства! Мы про методы тестирования программ, в часности TDD. Насколько я сужу по общей температуре больницы, народ перегрелся на unit testing, даже как-то и не задумываясь о его слабой применимости к сложным системам. Да чего там сложным, "морда к базе" с транзакциями — и то уже проблема!
Просто unit testing — наименее интрузивная форма внедрения автоматизации тестирования вообще.

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

TDD — это вообще за пределами практического применения для подавляющего большинства российских коллективов. Поэтому обсуждать его результаты — примерно то же самое, что во времена Жюль Верна спорить о полезностях обратной стороны Луны. Нам бы сначала DDT (development-driven testing) внедрить, чтобы проверить состояние уже написанного кода. А уж потом можно попробовать понять, реально ли писать автоматические тесты на основе спецификаций (а не на основе обсуждений с девелоперами и наблюдаемого поведения).

Вот несколько лет назад на RSDN пробегал прикольный пример DDT — где автор коммитил логи успешного выполнения тест-кейзов в SVN. Это давало автоматический regression: как только менялось хоть что-то, SVN видел change. При этом совершенно не требовалось мучительно изобретать тесты по спецификации, а потом сводить их с реализацией (которая запросто может отличаться от ожиданий. Неужто никто не правил SRS по результатам неудачных попыток реализовать его?).

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

S>На моём термометре показан крайне низкий уровень QA-культуры в стране вообще.

Этак и до правительства добраться можно! Но этот низкий уровень — всего лишь индикатор как жлобство влияет на качество. Но мы-то сами должны разбираться в вопросе! Если мне дадут мильён и скажут "выбирай любую методику и реализуй", TDD — последнее, на что я потрачусь.

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

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

S>...автор коммитил логи успешного выполнения тест-кейзов в SVN. Это давало автоматический regression

Я так понимаю, речь идёт об оценке производительности и не упала ли она? Regression — какой-то неудачный термин, degradation test был бы уместнее. Но это на отлаженном коде! И требующем всё же некой мат.обработки. А нам бы вообще добиться верного результата.

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

S>TDD — это вообще за пределами практического применения для подавляющего большинства российских коллективов. Поэтому обсуждать его результаты — примерно то же самое, что во времена Жюль Верна спорить о полезностях обратной стороны Луны. Нам бы сначала DDT (development-driven testing) внедрить, чтобы проверить состояние уже написанного кода.
А что такое development-driven testing? Просто тесты к уже написанному коду?

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

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

N>> Да, TDD примитивно. А теперь посмотрите чуть с другой стороны: что даёт TDD (в строгом понимании)? ......
N>>ЭТО КРИТЕРИИ УСПЕШНОГО ФУНКЦИОНИРОВАНИЯ ДЛЯ МЕНЕДЖМЕНТА. Точка.

M>Ну так мы ж не про то, как отвязаться от начальства! Мы про методы тестирования программ, в часности TDD. Насколько я сужу по общей температуре больницы, народ перегрелся на unit testing, даже как-то и не задумываясь о его слабой применимости к сложным системам. Да чего там сложным, "морда к базе" с транзакциями — и то уже проблема!
Ты очередно раз говоришь чушь, не надоело?
С чего ты взял что unit testing вообще хоть как-то применим к сложным системам?
Ты упорно не понимаешь сути того, что пытаешься ругать.

N>>2. Насколько тесты адекватны поставленному ТЗ. Тут уже дело постановщика делать это адекватно. Но тем не менее тесты будут использоваться потому, что они отделены от реализации и для них не нужно лезть в реализацию

M>Это смотря какой уровень качества вы хотите гарантировать. Допустим, вы даёте на вход А, должны получить Б. Тест проходит на ура, но что, если подали Х? Это усложнение теста и тестирующий просто обязан знать как система должна отреагировать на "мусор" и _проверить_ это. А если "неправильное Х" ещё и должно быть отослано по мылу? (Хотел бы я видеть такой тест!) У меня башка идёт кругом от тех вариаций, которые могут провалить тест!
А декомпозировать задачу не пробовал? Или у тебя в программе есть один класс на 10000 строк, который делает все?

M>Воистину, только от немногих знаний можно так оптимистично смотреть на unit testing.
От немногих знаний можно так рассуждать о unit testing.

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

T>В контексте данного обсуждения "ехать" — это использовать DSEL для 100%-го отсутствия ошибок. Я сомневаюсь, что мои слова можно толковать как-либо по-другому.
T>"Ехать с шашечками" — это использовать DSEL на мейнстримовом языке для 100%-го отсутствия ошибок.
На самом деле "ехать" — создавать код с приемлимым уровнем качества, а вот "100% отсуствие, доказанное из системы типов" — шашечки.
Пока что такое мало где возможно и требует очень много от программиста.

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


T>>>>>"Простыми" в каком смысле?
T>>>>>Если в смысле "я уже умею так делать", это да. Проще.
G>>>>В смысле "меньше думать и меньше писать".
T>>>"Меньше писать" это ты для красного словца, так?
G>>Нет

T>Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь?
При фиксированном времени раздумий — да.

T>Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню.
Что такое CbCC?

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

S>>...автор коммитил логи успешного выполнения тест-кейзов в SVN. Это давало автоматический regression
M>Я так понимаю, речь идёт об оценке производительности и не упала ли она? Regression — какой-то неудачный термин, degradation test был бы уместнее.

Зато стандартный. Относится, кстати, и к случаю, когда перестало проходить тест.

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

N>> Да, TDD примитивно. А теперь посмотрите чуть с другой стороны: что даёт TDD (в строгом понимании)? ......
N>>ЭТО КРИТЕРИИ УСПЕШНОГО ФУНКЦИОНИРОВАНИЯ ДЛЯ МЕНЕДЖМЕНТА. Точка.

M>Ну так мы ж не про то, как отвязаться от начальства!

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

M> Мы про методы тестирования программ, в часности TDD. Насколько я сужу по общей температуре больницы, народ перегрелся на unit testing, даже как-то и не задумываясь о его слабой применимости к сложным системам. Да чего там сложным, "морда к базе" с транзакциями — и то уже проблема!

Никто не перегрелся. Просто находит, как себе же облегчить работу. Простая практическая статистика: если тестирования не делаешь совсем, гоняешь сразу готовую систему — находится огромное количество случаев, которые могли быть отловлены юнит-тестированием. А затраты на локализацию и опознание ошибки в разы больше, чем на юнит-тестирование. Встаёт простой вопрос — а зачем такое позволять? Чем сложнее система, тем важнее всё, что ловится на уровне отдельного модуля, ловить таки на уровне отдельного модуля. С какого-то порога таки нужен TDD, чтобы форсировать разработку тестов до написания кода. Насколько строго он будет соблюдаться во временнОм плане — уже не так важно, jIMHO (это я про то, что нет причины всегда писать тесты до кода, но сданной работой считается только такая, к которой нарисованы и пройдены тесты в нужном объёме).

N>>2. Насколько тесты адекватны поставленному ТЗ. Тут уже дело постановщика делать это адекватно. Но тем не менее тесты будут использоваться потому, что они отделены от реализации и для них не нужно лезть в реализацию
M>Это смотря какой уровень качества вы хотите гарантировать. Допустим, вы даёте на вход А, должны получить Б. Тест проходит на ура, но что, если подали Х? Это усложнение теста и тестирующий просто обязан знать как система должна отреагировать на "мусор" и _проверить_ это.

А что значит "как должна отреагировать"? Для большинства случаев, меня устроит, если она на недопустимые значения вывалит исключение, а что именно в этом исключении — уже неважно.
И что тут сложного в проверке? Пишешь функцию типа

  succeeded = False
  try:
      test(мусор)
  except NeededException:
      succeeded = True
  return succeeded

M> А если "неправильное Х" ещё и должно быть отослано по мылу? (Хотел бы я видеть такой тест!) У меня башка идёт кругом от тех вариаций, которые могут провалить тест! Воистину, только от немногих знаний можно так оптимистично смотреть на unit testing.

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

Юнит-тестирование с заглушками — совершенно нормальный вариант, и я не знаю, чем он тебя так пугает. Сложностью настройки обстановки, чтобы он работал? Да, это сложнее, чем просто запустить функцию.

M>>>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.

N>>Так ветка-то не про них.:)

M>Как это не про них??? Читаем исходное сообщение:

>>В последнее время сталкиваюсь с большим колличеством советов обязательно использовать unit testing — проскакивает во многих подкастах .NET Rocks и Hanselminutes,...

M>Вот про этих "подкастоболов" и речь. Человек даже гуглом не стал ограничиваться — написал на форум, узнать как РЕАЛЬНО обстоят дела. На мой параноидальный взгляд, проходит "организованная шумиха" вокруг технологии, заслуживающей максимум упоминания на лекции. "Fire and motion" в действии, фигли...

Ты так говоришь, будто за это кто-то бабло будет лопатой грести.:) нет, всё проще. Чем больше индусов из заборостроительного техникума и китайцев из Гуанжопы ((c) некто cathay-stray), тем больше необходимость учить самому базовому.

А системное тестирование всё равно никуда не денется, точно также как нагрузочное и прочее.

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

M> "морда к базе" с транзакциями — и то уже проблема!

Тестировал морды к базе. IoC контейнеры и Mock фрейворки рулят.
Тестировал отдельно PL/SQL процедуры, самописными ассертами — нет проблем.

Тестировал сайты, сразу все кучей бд и контролеры — нет проблем.

Недавно в форуме проскакивала ссылка на статью Фаулера о Руби, он там сравнивал
опыт двух подходов к тестированию и не пришел к однозначному выводу что лучше.

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

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

T>>В контексте данного обсуждения "ехать" — это использовать DSEL для 100%-го отсутствия ошибок. Я сомневаюсь, что мои слова можно толковать как-либо по-другому.
T>>"Ехать с шашечками" — это использовать DSEL на мейнстримовом языке для 100%-го отсутствия ошибок.
G>На самом деле "ехать" — создавать код с приемлимым уровнем качества, а вот "100% отсуствие, доказанное из системы типов" — шашечки.
G>Пока что такое мало где возможно и требует очень много от программиста.

Я сейчас, несмотря на свой "уровень" (считающийся высоким и мной в том числе), поражаюсь тому, как много может программист, вооружённый Хаскелем.

T>>Тем не менее, потерять своё время и время пользователя (наличие логов просаживает производительность программы) на их поиск ты считаешь возможным.
G>Логи только при отладке, в релизе отключаются.

И что, неужто дедлоков у заказчиков не было? Ни за что не поверю.

T>>Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь?
G>При фиксированном времени раздумий — да.

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

T>>Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню.
G>Что такое CbCC?

Correct by Construction Concurrency.

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

T>>>Тем не менее, потерять своё время и время пользователя (наличие логов просаживает производительность программы) на их поиск ты считаешь возможным.
G>>Логи только при отладке, в релизе отключаются.
T>И что, неужто дедлоков у заказчиков не было? Ни за что не поверю.
Конечно было. Даже было такое что локально воспроизвести ситуацию не удавалось.
Ну отправили заказчикам дебажный бинарь, а потом по логам достаточно быстро нашли причину.


T>>>Да ты что! ТЫ ещё и на полном серьёзе считаешь, что ты так меньше пишешь?
G>>При фиксированном времени раздумий — да.
T>Иными словами, ты признаешь, что тебя работа задалбывает настолько, что даже нет времени подумать.
Не вижу связи.

T>>>Ты взгляни на сорцы той CbCC, там всего строк триста, насколько я помню.
G>>Что такое CbCC?
T>Correct by Construction Concurrency.
Я примерно на 5 странице перестал понимать что там написано.

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

M>> "морда к базе" с транзакциями — и то уже проблема!

K>Тестировал морды к базе. IoC контейнеры и Mock фрейворки рулят.

Видите — уже привлекается IoC, про которое опять ни слова от продвигателей TDD (а существующую систему без IoC вообще никто переписывать не будет). Но суть остаётся та же: юнит тестинг делать желательно, если на это есть ресурсы, покрытие тестов вас удовлетворяет и что объект теста настолько нестабилен, что имеет смысл держать его в узде.

K>Недавно в форуме проскакивала ссылка на статью Фаулера о Руби, он там сравнивал
K>опыт двух подходов к тестированию и не пришел к однозначному выводу что лучше.

А вы не могли бы найти по каким-то ключевым словам, плиз? Боюсь, что я по "фаулер" и "руби" вряд ли найду что-то однозначное.