M>>>>Лучший тестер по прежнему остаётся человек. G>>>С чего бы? G>>>Человек ошибается, а компьютер — нет. G>>>unit-тесты и интеграционное тестирование, это как раз работа с которой компьютер справляется гораздо лучше человека. T>>Это в том случае, когда юнит-тесты и тесты интеграции представлены в виде проверяемых компьютером контрактов. G>Я про это чуть выше написал. G>С задачей проверки контрактов компьютер тоже справляется лучше.
Именно с ней он и справляется лучше всего.
T>>Читай — выражены в виде типов. G>Это не единственный способ выражения контрактов.
Ну, вырази контракт "не должно быть deadlock".
А теперь напиши тест, который это проверяет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Читай — выражены в виде типов. G>>Это не единственный способ выражения контрактов.
T>Ну, вырази контракт "не должно быть deadlock". T>А теперь напиши тест, который это проверяет.
А типами как такое сделать?
T>>>>Читай — выражены в виде типов. G>>>Это не единственный способ выражения контрактов. T>>Ну, вырази контракт "не должно быть deadlock". T>>А теперь напиши тест, который это проверяет. G>А типами как такое сделать?
Итак, ты не представляешь себе, как это выразить в контракте и как это проверить.
Здравствуйте, thesz, Вы писали:
T>>>>>Читай — выражены в виде типов. G>>>>Это не единственный способ выражения контрактов. T>>>Ну, вырази контракт "не должно быть deadlock". T>>>А теперь напиши тест, который это проверяет. G>>А типами как такое сделать?
T>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить.
В существующих языках — нет.
T>Вот, как это можно выразить в типах: http://edwinb.wordpress.com/2008/04/03/correct-by-construction-concurrency/
Создать другой язык — не совсем то что хотелось бы видеть.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
G>>>А типами как такое сделать? T>>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить. G>В существующих языках — нет.
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, thesz, Вы писали:
G>>>>А типами как такое сделать? T>>>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить. G>>В существующих языках — нет.
T>Придумай язык, вырази на нём.
Это портебует гораздо больше знаний и трудозатрат, чем обычное разруливание дедлоков.
T>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации.
Я в курсе про тяжесть ситуации.
T>>>Вот, как это можно выразить в типах: http://edwinb.wordpress.com/2008/04/03/correct-by-construction-concurrency/ G>>Создать другой язык — не совсем то что хотелось бы видеть. T>Если текущие языки неадекватны, зачем себя мучить?
Затем что создавать новые языки — нетривиальная задача.
Как там на лукоморье:
...необходимостью глубокого понимания лямбда-исчисления, замыканий, теории графов, теории категорий, сопромата, анатомии мозга и прочего матана даже для вывода на экран строки «Hello, World!»
G>>>>>А типами как такое сделать? T>>>>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить. G>>>В существующих языках — нет. T>>Придумай язык, вырази на нём. G>Это портебует гораздо больше знаний и трудозатрат, чем обычное разруливание дедлоков.
Да-да. Как когда-то распределение регистров.
Это же единовременное вложение, nes pa?
T>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>Я в курсе про тяжесть ситуации.
Нет, ты не в курсе.
G>>>Создать другой язык — не совсем то что хотелось бы видеть. T>>Если текущие языки неадекватны, зачем себя мучить? G>Затем что создавать новые языки — нетривиальная задача. G>Как там на лукоморье: G>
G>...необходимостью глубокого понимания лямбда-исчисления, замыканий, теории графов, теории категорий, сопромата, анатомии мозга и прочего матана даже для вывода на экран строки «Hello, World!»
Зато это сделает тебя лучшим, чем сейчас, программистом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, matumba, Вы писали:
M>Фактически, мои претензии к TDD состоят в их примитивности и РАЗДУТОЙ ШУМИХЕ вокруг них. Ни один _ля "профессионал" (коими кишит этот форум) никогда не делает оговорок об узкой применимости TDD — все только и умеют тыкать окружающих носом: "Как?! Вы не пишете тесты?!" (читай: ну вы и _удаки!) Да, возвышать себя унижая других — это древнее умение. M>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
Фактически, мои претензии к цементу состоят в его примитивности и РАЗДУТОЙ ШУМИХЕ вокруг него. Ни один _ля "профессионал" (коими кишат строительные форумы) никогда не делает оговорок об узкой применимости цемента — все только и умеют тыкать окружающих носом: "Как, вы кладете стены в многоэтажке, не используя цемент?!"
Кроме того, НИКТО не задает вопросов про стеклопакеты, кровельное железо, битум, паркет... Ухватились за то, на что мозгов хватило и давай пальцы груть!
Здравствуйте, thesz, Вы писали:
G>>>>>>А типами как такое сделать? T>>>>>Итак, ты не представляешь себе, как это выразить в контракте и как это проверить. G>>>>В существующих языках — нет. T>>>Придумай язык, вырази на нём. G>>Это портебует гораздо больше знаний и трудозатрат, чем обычное разруливание дедлоков.
T>Это же единовременное вложение, nes pa?
Вряд ли, создание DSL под каждую задачу единовременным не будет.
Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты.
T>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>Я в курсе про тяжесть ситуации. T>Нет, ты не в курсе.
Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи.
G>>>>Создать другой язык — не совсем то что хотелось бы видеть. T>>>Если текущие языки неадекватны, зачем себя мучить? G>>Затем что создавать новые языки — нетривиальная задача. G>>Как там на лукоморье: G>>
G>>...необходимостью глубокого понимания лямбда-исчисления, замыканий, теории графов, теории категорий, сопромата, анатомии мозга и прочего матана даже для вывода на экран строки «Hello, World!»
T>Зато это сделает тебя лучшим, чем сейчас, программистом.
Если я приду к начальству с таким обоснованием необходимости создания языка, то вряд ли кто-то согласится.
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет всем. BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
Я знаю одно замечательное свойство TDD: оно является средством, которое помогает программисту преодолеть лень и заставить самого себя сделать именно то, что нужно.;)
Разумеется, это не случай, когда над каждым стоит надсмотрщик — там и так запинают. Но я в таких местах не работаю, а работаю там, где больше свободы. А тут уже надо уметь себя заставить не отклоняться от задачи. И тогда — как только заметил, что начинается приступ лени — рисуешь тесты и получаешь самому себе причину не почитать RSDN или общаться с соседним отделом о перспективах версии 4.0 (когда ещё 1.0 не вышла), и тем более не цветного Штирлица смотреть, а кодить.
Ну и начальству яснее, когда говоришь, какое именно тестирование уже работает.
(Disclaimer: я имею в виду не только unit testing, но весь комплекс, включая функциональные и нагрузочные)
Здравствуйте, matumba, Вы писали:
M>Фактически, мои претензии к TDD состоят в их примитивности и РАЗДУТОЙ ШУМИХЕ вокруг них. Ни один _ля "профессионал" (коими кишит этот форум) никогда не делает оговорок об узкой применимости TDD — все только и умеют тыкать окружающих носом: "Как?! Вы не пишете тесты?!" (читай: ну вы и _удаки!) Да, возвышать себя унижая других — это древнее умение.
Тут можно понять обе стороны — и Вашу и противоположную. Да, тестирование само по себе примитивно;) Да, TDD примитивно. А теперь посмотрите чуть с другой стороны: что даёт TDD (в строгом понимании)? А оно даёт при выполнении соответствия кода тестам то, что:
1. То, что должно быть сделано (для соответствия тестам) — то сделано.
2. То, что не требуется (для соответствия тестам) — не делается.
ЭТО КРИТЕРИИ УСПЕШНОГО ФУНКЦИОНИРОВАНИЯ ДЛЯ МЕНЕДЖМЕНТА. Точка. Большая, жирная точка. Исполнитель сделал то, что должно быть сделано, и не делал (не тратил ресурсы) на то, что не должно делаться и на что не надо тратить ресурсы.
А дальше — два вопроса:
1. Кто начальник и как он наблюдает происходящее. Если, как в моём предыдущем сообщении в эту тему, я сам себе в значительной мере менеджер, по крайней мере по текущим задачам, я сам себе буду писать тесты. Если я, например, ленивый тормоз, не знающий ничего кроме какой-нибудь Явы, и то один год после заборостроительного техникума — надо мной будет стоять дядя с палкой, но оценивать он будет, скорее всего, по результатам тестов.
2. Насколько тесты адекватны поставленному ТЗ. Тут уже дело постановщика делать это адекватно. Но тем не менее тесты будут использоваться потому, что они отделены от реализации и для них не нужно лезть в реализацию — их может делать совсем другой человек с совсем другими знаниями (я уж не говорю про вариант, когда достаточно сказать make blackbox и в случае провала написать письмо — это и скрипт сумеет). И здесь неважно, программа это или автомат управления паровым котлом: тесты, хоть и разные, подойдут везде, вся технологическая промышленность всех видов строится на тестах.
M>Кроме того, НИКТО не задаёт вопросов про системное тестирование, многопоточное, транзакционное.... Ухватились за то, на что мозгов хватило, и давай пальцы на форумах гнуть! Надоело — вот и написал.
T>>Это же единовременное вложение, nes pa? G>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты.
Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency.
Это создание единовременно.
После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса.
T>>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>>Я в курсе про тяжесть ситуации. T>>Нет, ты не в курсе. G>Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи.
Какие?
T>>Зато это сделает тебя лучшим, чем сейчас, программистом. G>Если я приду к начальству с таким обоснованием необходимости создания языка, то вряд ли кто-то согласится.
Разница в производительности в два и более раз должна порадовать начальство.
Ты находишься в стандартной ловушке среднего программиста.
Во-первых, тебе требуется разрешение начальства. Уверяю, большинство полезных нововведений делается помимо этого разрешения. Хотя бы потому, что прощение получить проще, чем разрешение.
Во-вторых, тебе требуется разрешение начальства. Это означает, что твой рабочий день загружен до упора. У тебя нет пространства для маневра. Ты не можешь ничего ни написать, ни поэкспериментировать.
Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Это же единовременное вложение, nes pa? G>>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты.
T>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency. T>Это создание единовременно.
Но очень затратно.
T>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса.
Только читаемость в таком случае падает до 0.
T>>>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>>>Я в курсе про тяжесть ситуации. T>>>Нет, ты не в курсе. G>>Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи. T>Какие?
Связанные с concurrency.
T>>>Зато это сделает тебя лучшим, чем сейчас, программистом. G>>Если я приду к начальству с таким обоснованием необходимости создания языка, то вряд ли кто-то согласится.
T>Разница в производительности в два и более раз должна порадовать начальство.
А затраты на достижение этого могут не порадовать.
T>Ты находишься в стандартной ловушке среднего программиста. T>Во-первых, тебе требуется разрешение начальства. Уверяю, большинство полезных нововведений делается помимо этого разрешения. Хотя бы потому, что прощение получить проще, чем разрешение. T>Во-вторых, тебе требуется разрешение начальства. Это означает, что твой рабочий день загружен до упора. У тебя нет пространства для маневра. Ты не можешь ничего ни написать, ни поэкспериментировать.
Есть планы, которые надо выполнять, желательно в срок.
T>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих.
Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>>>Это же единовременное вложение, nes pa? G>>>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты. T>>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency. T>>Это создание единовременно. G>Но очень затратно.
В том смысле, что придётся стать умнее? Да, затратно.
Но повышение уровня интеллекта окупается большим удовольствием от жизни в целом. Есть такое выражение, что высшее образование позволяет понимать больше шуток. Вот за этим и надо становиться умнее.
T>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса. G>Только читаемость в таком случае падает до 0.
Это ты с чего взял?
Неужто из опыта? 8O
T>>>>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>>>>Я в курсе про тяжесть ситуации. T>>>>Нет, ты не в курсе. G>>>Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи. T>>Какие? G>Связанные с concurrency.
То есть, ты умеешь тестировать на дедлоки. Или нет?
T>>>>Зато это сделает тебя лучшим, чем сейчас, программистом. G>>>Если я приду к начальству с таким обоснованием необходимости создания языка, то вряд ли кто-то согласится. T>>Разница в производительности в два и более раз должна порадовать начальство. G>А затраты на достижение этого могут не порадовать.
Вопрос баланса.
Даже если тебя снять со всех работ и дать тебе год на всё про всё, то за следующий год ты всё отобъёшь.
T>>Ты находишься в стандартной ловушке среднего программиста. T>>Во-первых, тебе требуется разрешение начальства. Уверяю, большинство полезных нововведений делается помимо этого разрешения. Хотя бы потому, что прощение получить проще, чем разрешение. T>>Во-вторых, тебе требуется разрешение начальства. Это означает, что твой рабочий день загружен до упора. У тебя нет пространства для маневра. Ты не можешь ничего ни написать, ни поэкспериментировать. G>Есть планы, которые надо выполнять, желательно в срок.
Они есть у всех.
T>>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих. G>Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL.
С доказанным 100% отсутствием — невозможно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, thesz, Вы писали:
T>>>>>Это же единовременное вложение, nes pa? G>>>>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>>>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты. T>>>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency. T>>>Это создание единовременно. G>>Но очень затратно.
T>В том смысле, что придётся стать умнее? Да, затратно.
Нет, в том смысле что создание такого dsl дороже, чем разруливание нескольких дедлоков.
T>Но повышение уровня интеллекта окупается большим удовольствием от жизни в целом. Есть такое выражение, что высшее образование позволяет понимать больше шуток. Вот за этим и надо становиться умнее.
Это стоит перенести в раздел "О жизни".
Реквестирую статью о том как зависимая система типов помогает понимать больше шуток
T>>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса. G>>Только читаемость в таком случае падает до 0.
T>Это ты с чего взял? T>Неужто из опыта? 8O
Именно из опыта общения с различными с DSL.
T>>>>>>>Так ты хотя бы чуть-чуть почувствуешь всю тяжесть ситуации. G>>>>>>Я в курсе про тяжесть ситуации. T>>>>>Нет, ты не в курсе. G>>>>Может быть и не в курсе, но моего "не в курсе" вполне хватает чтобы решать такие задачи. T>>>Какие? G>>Связанные с concurrency. T>То есть, ты умеешь тестировать на дедлоки. Или нет?
Нет, я умею их находить.
T>>>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих. G>>Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL.
T>С доказанным 100% отсутствием — невозможно.
А нужно ли оно? Потребителя интересуют не идеальные программы, а те которые имеют приемлимый уровень качества.
Если этот уровень качества достигается гораздо более простыми средствами, то лучше использовать их.
Здравствуйте, thesz, Вы писали:
T>Но повышение уровня интеллекта окупается большим удовольствием от жизни в целом. Есть такое выражение, что высшее образование позволяет понимать больше шуток. Вот за этим и надо становиться умнее.
Здравствуйте, gandjustas, Вы писали:
G>А нужно ли оно? Потребителя интересуют не идеальные программы, а те которые имеют приемлимый уровень качества. G>Если этот уровень качества достигается гораздо более простыми средствами, то лучше использовать их.
Поддержу. Приемлимый уровень качества, за приемлимое время.
Автоматизированное (заметте не unit) тестирование это прекрасный способ достижения приемлимого компромисса.
А если бы все так простоы было с DSL, то у нас бы дааавным давно мейнстрим компиляторы детектировали дедлоки,
так же легко как и несоответсвие типов.
Но вот Ericson посчитали для себя обе перечеслинных проблемы неактуальными.
-- Главное про деструктор копирования не забыть --
T>>>>>>Это же единовременное вложение, nes pa? G>>>>>Вряд ли, создание DSL под каждую задачу единовременным не будет. G>>>>>Надо или иметь очень типовые задачи или очень большой опыт создания DSL, чтобы сократить затраты. T>>>>Создание языка, который позволяет создавать DSL наподобие того, что в correct-by-construction-concurrency. T>>>>Это создание единовременно. G>>>Но очень затратно. T>>В том смысле, что придётся стать умнее? Да, затратно. G>Нет, в том смысле что создание такого dsl дороже, чем разруливание нескольких дедлоков.
Да его вариант на Хаскеле делается за, не знаю, два дня.
Тоже мне, "дороже".
T>>>>После чего ты создаешь DSL, который единовременно решает все проблемы с deadlock. Потом создаешь DSL, который единовременно решает все проблемы с чем-то другим, с твоей задачей например. Потом соединяешь их и единовременно получаешь решение двух классов проблем вместе — безопасное параллельное решение твоей задачи. Всех задач из твоего класса. G>>>Только читаемость в таком случае падает до 0. T>>Это ты с чего взял? T>>Неужто из опыта? 8O G>Именно из опыта общения с различными с DSL.
DSL или DSEL?
G>>>Связанные с concurrency. T>>То есть, ты умеешь тестировать на дедлоки. Или нет? G>Нет, я умею их находить.
А как ты их находишь?
T>>>>Поэтому ты либо напряжешься, и сделаешь/выучишь язык, либо так и останешься разруливать деадлоки вручную до конца дней своих. G>>>Ты так говоришь как-будто создание программ без делоков невозможно без чудо-DSL. T>>С доказанным 100% отсутствием — невозможно. G>А нужно ли оно? Потребителя интересуют не идеальные программы, а те которые имеют приемлимый уровень качества. G>Если этот уровень качества достигается гораздо более простыми средствами, то лучше использовать их.
"Простыми" в каком смысле?
Если в смысле "я уже умею так делать", это да. Проще.
Если в смысле "затраченных усилий" на единицу кода на длительном промежутке времени, то нет, не проще.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, thesz, Вы писали:
T>>Но повышение уровня интеллекта окупается большим удовольствием от жизни в целом. Есть такое выражение, что высшее образование позволяет понимать больше шуток. Вот за этим и надо становиться умнее.
FR>"Горе от ума"
Заметь, не от повышения уровня интеллекта (что можно измерить), а от ума.
FR>"Многие знания многие печали"
Соломон?
Я же не про Библию (да ещё и Старый Завет) говорил. В ней, действительно, совсем ничего радостного нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
