Здравствуйте, varenikAA, Вы писали:
AA>запускаю правда не релиз, а lein ring server. AA>собственно вся обвязка очень и очень медленно стартует. AA>В тоже время sbcl (Common Lisp) по сравнению с кложой(lein) можно сказать "летает". AA>Да и размер зависимостей в разы меньше. AA>Вот и думаю, стоит ли скорость лиспа менять на красивые хеш-мапки кложи? AA>Кложа конечно восхитительно смотрится в кодэ.
Она стартует медленно, но потом всё вроде более-менее нормально. Ну да, прожорливая, ну да, генерируемый код оставляет желать лучшего в плане производительности (дизассемблируй, много сюрпризов, особенно с "рекомендуемыми практиками" типа map и т.п.), но это не проблема даже. Серьезная проблема в другом, в типизации.
После того как полгода писал продуктовый код (не интеграционные тесты) на Elixir пришел к выводу, что динамика в проде вообще не опция, если ты планируешь писать больше 50 KLOC. Слишком много неожиданностей и неприятностей. Только статическая типизация, без вариантов. Хочется экзотики в проде — то, наверное, надо брать Haskell или F#. А лучше не брать экзотики вообще.
Да, я полностью поменял свое мнение в этом вопросе, но продолжаю считать что Python для интеграционных тестов, скриптов и POC это самое то что нужно
Здравствуйте, varenikAA, Вы писали:
AA>Рич Хикки на это замечает:
убрал много бла-бла-бла.
Да, он в чем-то прав, на том же JS кучу чего написали, при том что это динамический язык. Тем не менее, если хочется упростить жизнь и ускорить развитие продукта, именно развитие, а не изначальное написание, то с динамикой связываться не надо. Статическая типизация — это те же тесты, только принудительного характера, которые ты никак не можешь игнорировать. Так что его аналогия в данном случае кривая.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, varenikAA, Вы писали:
AA>>запускаю правда не релиз, а lein ring server. AA>>собственно вся обвязка очень и очень медленно стартует. AA>>В тоже время sbcl (Common Lisp) по сравнению с кложой(lein) можно сказать "летает". AA>>Да и размер зависимостей в разы меньше. AA>>Вот и думаю, стоит ли скорость лиспа менять на красивые хеш-мапки кложи? AA>>Кложа конечно восхитительно смотрится в кодэ.
KP>Она стартует медленно, но потом всё вроде более-менее нормально. Ну да, прожорливая, ну да, генерируемый код оставляет желать лучшего в плане производительности (дизассемблируй, много сюрпризов, особенно с "рекомендуемыми практиками" типа map и т.п.), но это не проблема даже. Серьезная проблема в другом, в типизации.
KP>После того как полгода писал продуктовый код (не интеграционные тесты) на Elixir пришел к выводу, что динамика в проде вообще не опция, если ты планируешь писать больше 50 KLOC. Слишком много неожиданностей и неприятностей. Только статическая типизация, без вариантов. Хочется экзотики в проде — то, наверное, надо брать Haskell или F#. А лучше не брать экзотики вообще.
KP>Да, я полностью поменял свое мнение в этом вопросе, но продолжаю считать что Python для интеграционных тестов, скриптов и POC это самое то что нужно
Рич Хикки на это замечает:
И мне нравится задавать этот вопрос: что верно
для каждой ошибки, найденной в продакшене?
(Ответ аудитории: Кто-то её написал.)
Она была кем-то написана. Да.
Что ещё более интересно:
она прошла проверку типов.
Что ещё она сделала?
Она прошла все тесты.
Да. Что теперь вам нужно сделать?
Я считаю, что мы в мире, как я его называю
оградительного программирования.
Грустно говорить это.
Мы такие: Я могу делать изменения,
потому что у меня есть тесты.
Кто так делает?
Кто водит машину,
стукаясь об ограждения, говоря:
«Вау! Я рад, что у меня есть эти ограждения,
иначе я никогда бы не приехал вовремя.»
И установленные ограждения
помогают вам добраться до места?
Вроде, ограждения направляют вас?
Нет. Ограждения повсюду.
Они не направляют вашу машину
в какое-то конкретное направление.
Здравствуйте, sambl74, Вы писали:
S>Здравствуйте, varenikAA, Вы писали:
AA>>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
S>Почему? Ленивый штоле?
S>Вот самый запущенный случай — Безумие и успех кода Oracle Database
Ну, интересная статья. Опять же сказки на ночь. Рич Х. тоже не лаптем щи хлебает. До кложи и собственного взгляда на разработку он десятки лет программировал на плюсах.
Он отрицает не столько тестирование, сколько идею тупого кодинга как это было в оракл. Прежде чем кодить требуется осмыслить задачу.
Возможно в оракле тоже думали, но производительность была важнее. Кто знает почему так получилось. Возможно, это было время когда еще не сформировались нужные подходы.
И да, помню был опыт установки оракл стандарт на "почти сервер(виндос)" и почему-то регулярно билась база. Как будто нужны были какие-то особые условия вроде рэйд-массивов с нормальным кэшем.
AA>>Все равно вылезит. Рич предлагает другой путь — по возможности упростить задачу, тогда и ошибок удаться избежать.
S>Ага-ага. Плохо быть бедным и больным — надо быть богатым и здоровым Ну и так-то упрощёние задачи позволяет и тесты хорошие написать — так что это правильно, но иногда с этим таки вылезают проблемы.
В основном согласен, тольео не понял насчет "вылезают".
Лично мое мнение, чем строже ЯП, тем больше времени уйдет на разработку той же фичи. просто проверьте, если есть код на каком нибудь C#,F# и на ванильном js.
В последнем словно крылья вырастают. Любую проблему можно решить кучей способов. По сути js — lisp для браузера ( с сишным синтаксом).
AA>обобщенные функции в CLOS наголову выше паттерн-матча, который по сути — те же if-ы.
обобщенные функции в CLOS являются убогим, многословным, жестко прибитым гвоздями говном по сравнению с паттерн-матчингом. Можно начать хотя бы с того, что обобщенные функции, как видно из самого названия, доступны только для объявления функций (весьма кривым способом с парой defgeneric/defmatohd, потому что иначе «самый лучший язык на земле» даже не способен понять, что происходит). Паттерн матчинг в функциональных языках доступен как для объявления функций так и внутри функций.
В итоге в CLOS есть defgeneric/defmethod + куча if'ов внутри. В некоторых других языках есть просто единообразный pattern matching.
S>Какая фантазия — реальный процесс, ты чё В мокапах, которые дают на разработку, уже показано, по какой кнопке чё происходит и всё это уже кучу раз обсуждено.
К вопросу о мире фантазий и эльфов, у которых «что в ТЗ и мокапах прописано, то и надо тестировать».
Авторы SQLite, видимо, ну очень ленивые программисты с точки зрения sambl74. Нет чтобы взять ТЗ на SQLite и написать все тесты «пользовательские юз-кейсы из мокапа» и «не писать тесты на все, потому что будет бесконечно много тестов». Но они, понимаешь ли, ленивые. Поэтому они вместо того, чтобы писать тесты, как все не ленивые люди, одной рукой генерируют тесты (TH3 генерирует 850k строк тестов), другой используют fuzzy-тестирование и в целом генерируют миллионы тестов.
Вот ведь ленивые программисты, да. Вместо того, чтобы тупо взять ТЗ и мокапы, они даже не могут написать простой тест на простое
#1 COLLATE nocase index on a WITHOUT ROWID table malfunctions
CREATE TABLE test (c1 TEXT PRIMARY KEY) WITHOUT ROWID;
CREATE INDEX index_0 ON test(c1 COLLATE NOCASE);
INSERT INTO test(c1) VALUES ('A');
INSERT INTO test(c1) VALUES ('a');
SELECT * FROM test; -- only one row is fetched
запускаю правда не релиз, а lein ring server.
собственно вся обвязка очень и очень медленно стартует.
В тоже время sbcl (Common Lisp) по сравнению с кложой(lein) можно сказать "летает".
Да и размер зависимостей в разы меньше.
Вот и думаю, стоит ли скорость лиспа менять на красивые хеш-мапки кложи?
Кложа конечно восхитительно смотрится в кодэ.
Здравствуйте, varenikAA, Вы писали:
AA>И установленные ограждения AA>помогают вам добраться до места? AA>Вроде, ограждения направляют вас? AA>Нет. Ограждения повсюду. AA>Они не направляют вашу машину AA>в какое-то конкретное направление.
Ну правильные тесты гарантируют что протестированный воркфлоу остался рабочим так-то. Т.е. можно гарантированно доехать до нужной точки, по аналогии с автомобилем.
Здравствуйте, sambl74, Вы писали:
AA>>Они не направляют вашу машину AA>>в какое-то конкретное направление.
S>Ну правильные тесты гарантируют что протестированный воркфлоу остался рабочим так-то. Т.е. можно гарантированно доехать до нужной точки, по аналогии с автомобилем.
Это какие же интересно тесты правильные?
Гарантию часовой завод дает.
Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
Все равно вылезит. Рич предлагает другой путь — по возможности упростить задачу, тогда и ошибок удаться избежать.
Здравствуйте, varenikAA, Вы писали:
AA>Это какие же интересно тесты правильные?
Тесты, который гарантируют работоспособность пользовательских сценариев
AA>Гарантию часовой завод дает.
Да?
AA>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
Почему? Ленивый штоле?
Вот самый запущенный случай — Безумие и успех кода Oracle Database
AA>Все равно вылезит. Рич предлагает другой путь — по возможности упростить задачу, тогда и ошибок удаться избежать.
Ага-ага. Плохо быть бедным и больным — надо быть богатым и здоровым Ну и так-то упрощёние задачи позволяет и тесты хорошие написать — так что это правильно, но иногда с этим таки вылезают проблемы.
Здравствуйте, kaa.python, Вы писали:
KP>После того как полгода писал продуктовый код (не интеграционные тесты) на Elixir пришел к выводу, что динамика в проде вообще не опция, если ты планируешь писать больше 50 KLOC. Слишком много неожиданностей и неприятностей. Только статическая типизация, без вариантов. Хочется экзотики в проде — то, наверное, надо брать Haskell или F#. А лучше не брать экзотики вообще.
Может это проблема элексира? Он динамичный?
Haskell или F#
— упаси, бог!
Простой пример:
match x with
| A -> f1()
| B -> f2()
...
и
(defgeneric description (object)
(:documentation"Return a description of an object."))
(defmethod description ((object integer))
(format nil"The integer ~D" object))
(defmethod description ((object float))
(format nil"The float ~3,3f" object))
(description 10); => "The integer 10"
(description 3.14); => "The float 3.140"
обобщенные функции в CLOS наголову выше паттерн-матча, который по сути — те же if-ы.
Совершенно не уменьшает связанность и следовательно сложность ПО, даже наоборот, каждый матч это новый клубок.
AA>>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
S>Почему? Ленивый штоле?
Потому что кейс на баг может быть из разряда «открыть файл, открыть файл параллельно, закрыть файл из одного потока, записать из второго, открыть из первого, записать из первого, закрыть из второго, закрыть из первого».
Ручками ты такой тест кейс не напишешь. А property-based и fuzzy-тестирование надо а) уметь и б) иметь библиотеки, которые в них умеют.
Здравствуйте, Mamut, Вы писали:
M>Потому что кейс на баг может быть из разряда «открыть файл, открыть файл параллельно, закрыть файл из одного потока, записать из второго, открыть из первого, записать из первого, закрыть из второго, закрыть из первого».
M>Ручками ты такой тест кейс не напишешь. А property-based и fuzzy-тестирование надо а) уметь и б) иметь библиотеки, которые в них умеют.
чёт не вижу тут сложного кейса. в чём тут конкретно проблема?
M>>Потому что кейс на баг может быть из разряда «открыть файл, открыть файл параллельно, закрыть файл из одного потока, записать из второго, открыть из первого, записать из первого, закрыть из второго, закрыть из первого».
M>>Ручками ты такой тест кейс не напишешь. А property-based и fuzzy-тестирование надо а) уметь и б) иметь библиотеки, которые в них умеют.
S>чёт не вижу тут сложного кейса. в чём тут конкретно проблема?
Как ты самостоятельно сможешь найти этот кейс? Именно этот, именно в этом порядке.
Здравствуйте, Mamut, Вы писали:
M>Как ты самостоятельно сможешь найти этот кейс? Именно этот, именно в этом порядке.
Тестеры/пользователи наткнулись, завели багу, её воспроизвели, поправили, написали тест. Всё, кейс рабочий. Навсегда Это же так и работает, не?
Пользователи же не тыкают в программу бездумно — выполняют какие-то рабочие сценарии. Их так-то ограниченное количество.
Проверять все возможные ветвления и сценарии это конечно хорошо, но избыточно. Это как с идеальной коробкой передач — которая экономит бензин на 50%, но при этом будет занимать очень много места. В случае с покрытием всех возможных сценариев код имхо будет очень сильно разбухать.
M>>Как ты самостоятельно сможешь найти этот кейс? Именно этот, именно в этом порядке.
S>Тестеры/пользователи наткнулись, завели багу
Стоп-стоп. Все начиналось с
AA>>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
S>Почему? Ленивый штоле?
А тут ВНЕЗАПНО нет, все кейсы тестами не обложил, а ждешь, чтобы на этот кейс наткнулись пользователи/тестеры и завели багу. Ленивый, что ле?
S>, её воспроизвели, поправили, написали тест. Всё, кейс рабочий. Навсегда Это же так и работает, не?
Что случилось с «программист должен написать все тест кейсы иначе он ленивый»?
S>Пользователи же не тыкают в программу бездумно — выполняют какие-то рабочие сценарии. Их так-то ограниченное количество.
S>Проверять все возможные ветвления и сценарии это конечно хорошо, но избыточно.
Ну то есть «Почему? Ленивый штоле?» на проверку оказалось «Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.», и непонятно, почему ты с этим споришь.
А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, включая воспроизведение, с 36:55 (описание самой проблемы, в кратце, на 27:00). Да и вообще вся презентация про такие проблемы.
Здравствуйте, Mamut, Вы писали:
M>Стоп-стоп. Все начиналось с
M>
AA>>>Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.
S>>Почему? Ленивый штоле?
M>А тут ВНЕЗАПНО нет, все кейсы тестами не обложил, а ждешь, чтобы на этот кейс наткнулись пользователи/тестеры и завели багу. Ленивый, что ле?
Так все кейсы — это все пользовательские сценарии. А не всё многообразие того, что можно сделать в программе.
S>>, её воспроизвели, поправили, написали тест. Всё, кейс рабочий. Навсегда Это же так и работает, не?
M>Что случилось с «программист должен написать все тест кейсы иначе он ленивый»?
Ну в ТЗ есть спецификация, какие сценарии пользователя должны работать — вот это и есть "все кейсы". Для них и пишутся тесты.
Избыточно потому, что программа должна делать хорошо то, что написано в спецификации. Если она что-то делает плохо, когда пользователь отклоняется от описанного сценария — то либо дополняем спецификацию и соответственно дорабатываем продукт и покрываем новый кейс тестами, либо пишем в документацию "Вот так делать нельзя!!!". Ну и можно запретить такое поведение пользователя и написать тест и на это
S>>Это как с идеальной коробкой передач — которая экономит бензин на 50%, но при этом будет занимать очень много места. В случае с покрытием всех возможных сценариев код имхо будет очень сильно разбухать.
M>Ну то есть «Почему? Ленивый штоле?» на проверку оказалось «Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.», и непонятно, почему ты с этим споришь.
В твоём понимании это не "тесты на все кейсы", а некие идеальные тесты, которые покрывают бесконечное количество вариаций входных данных и действий пользователя. И да — время выполнения тоже бесконечно
M>А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, включая воспроизведение, с 36:55 (описание самой проблемы, в кратце, на 27:00). Да и вообще вся презентация про такие проблемы.
M>https://youtu.be/zi0rHwfiX1Q?t=2215
S>Так все кейсы — это все пользовательские сценарии. А не всё многообразие того, что можно сделать в программе.
Откуда ты знаешь, что именно этот кейс — пользовательский сценарий, а «все многообразие» — нет?
M>>Что случилось с «программист должен написать все тест кейсы иначе он ленивый»? S>Ну в ТЗ есть спецификация, какие сценарии пользователя должны работать — вот это и есть "все кейсы". Для них и пишутся тесты.
А, месье из мира эльфов и фей.
S>Если у тебя в ТЗ написано "всё должно работать", то мне конечно тебя жаль
1. В какой спецификации?
2. Почему ты уверен, что спецификация покроет все варианты поведения программы?
3. Почему ты уверен, что спецификация покроет все варианты использования пользователем?
S>Если она что-то делает плохо, когда пользователь отклоняется от описанного сценария — то либо дополняем спецификацию и соответственно дорабатываем продукт и покрываем новый кейс тестами, либо пишем в документацию "Вот так делать нельзя!!!". Ну и можно запретить такое поведение пользователя и написать тест и на это
А, месье из мира эльфов и фей.
M>>Ну то есть «Почему? Ленивый штоле?» на проверку оказалось «Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.», и непонятно, почему ты с этим споришь. S>В твоём понимании это не "тесты на все кейсы", а некие идеальные тесты, которые покрывают бесконечное количество вариаций входных данных и действий пользователя. И да — время выполнения тоже бесконечно
Ты это говоришь и описываешь какие-то идеальные тесты и кейсы, которые все зарание продумали, тзательно записали в спецификации, а потом каждый из них написан и протестирован программистом.
M>>А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, включая воспроизведение, с 36:55 (описание самой проблемы, в кратце, на 27:00). Да и вообще вся презентация про такие проблемы.
M>>https://youtu.be/zi0rHwfiX1Q?t=2215
S>Гляну потом. Интересно
Очень рекомендую видео, да. Как раз проказывает разницу между реальным миром и фантазиями на тему «все должно быть описано в ТЗ и протестировано».
Ага
S>>Если у тебя в ТЗ написано "всё должно работать", то мне конечно тебя жаль
M>Оно обычно так и написано. Ну и обязательно посмотри видео, которое я привел, с самого начала. Они там тестируют и ТЗ в том числе, и находят ошибки в самом ТЗ.
Ну и что? Ошибка в ТЗ обычное явление и повод для его доработки.
M>1. В какой спецификации? M>2. Почему ты уверен, что спецификация покроет все варианты поведения программы?
Зачем? У нас описан сценарий, которому следует пользователь. Программа должна всегда корректно его обрабатывать.
M>3. Почему ты уверен, что спецификация покроет все варианты использования пользователем?
Потому что по спецификации пишется документация, по которой пользователь работает. Ну вот да, единственное моё спорное допущение — что это идеальный пользователь, который читает документацию и работает по ней
S>>Если она что-то делает плохо, когда пользователь отклоняется от описанного сценария — то либо дополняем спецификацию и соответственно дорабатываем продукт и покрываем новый кейс тестами, либо пишем в документацию "Вот так делать нельзя!!!". Ну и можно запретить такое поведение пользователя и написать тест и на это
M>А, месье из мира эльфов и фей.
Да, из мира где выпускается MVP и потом по результатам тестирования и фидбеку от пользователей допиливается функционал приложения, которое всегда стабильно работает на заданном наборе сценариев. Да, и программа как сервис, поэтому все пользователи всегда работают с актуальной версией. В прошлом проекте было десктопное приложение, и там кроме тестов было около 5000 описанных тест кейсов пользовательских сценариев.
M>>>Ну то есть «Почему? Ленивый штоле?» на проверку оказалось «Если есть сложный, запутанный стэйт, то обложить все кейсы тестами не реально.», и непонятно, почему ты с этим споришь. S>>В твоём понимании это не "тесты на все кейсы", а некие идеальные тесты, которые покрывают бесконечное количество вариаций входных данных и действий пользователя. И да — время выполнения тоже бесконечно
M>Ты это говоришь и описываешь какие-то идеальные тесты и кейсы, которые все зарание продумали, тзательно записали в спецификации, а потом каждый из них написан и протестирован программистом.
Да, так и работаем. Ощути тленность своего бытия
M>>>А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, включая воспроизведение, с 36:55 (описание самой проблемы, в кратце, на 27:00). Да и вообще вся презентация про такие проблемы.
M>>>https://youtu.be/zi0rHwfiX1Q?t=2215
S>>Гляну потом. Интересно
M>Очень рекомендую видео, да. Как раз проказывает разницу между реальным миром и фантазиями на тему «все должно быть описано в ТЗ и протестировано».
Какая фантазия — реальный процесс, ты чё В мокапах, которые дают на разработку, уже показано, по какой кнопке чё происходит и всё это уже кучу раз обсуждено.
M>>Оно обычно так и написано. Ну и обязательно посмотри видео, которое я привел, с самого начала. Они там тестируют и ТЗ в том числе, и находят ошибки в самом ТЗ.
S>Ну и что? Ошибка в ТЗ обычное явление и повод для его доработки.
Ну и то, что твое «ленивый што ле» продолжает разбиваться об стену жестокой реальности. Ну и да. Описанный ТЗ — промышленные стандарты на взаимодействие компонентов в машинах.
M>>3. Почему ты уверен, что спецификация покроет все варианты использования пользователем?
S>Потому что по спецификации пишется документация, по которой пользователь работает. Ну вот да, единственное моё спорное допущение — что это идеальный пользователь, который читает документацию и работает по ней
4. Почему ты уверен, что спецификация описывает поведение пользователя, как человека. Например, в видео, которе ты, видать, никогда и не посмотришь, никакого пользователя не было. Была система под нагрузкой, которая раз в один-два месяца падала с невнятной ошибкой.
M>>А, месье из мира эльфов и фей.
S>Да, из мира где выпускается MVP и потом по результатам тестирования и фидбеку от пользователей допиливается функционал приложения, которое всегда стабильно работает на заданном наборе сценариев.
Прекрасноэ, конечно.
Сначала «программисты ленивые, что не пишут тесты на все кейсы», потом «а что сложного в кейсе», потом «не, ну мы нифига не пишем все тесты, мы пишем что смошгли, а потом ждем баг репортов от тестеров и пользователей».
M>>Ты это говоришь и описываешь какие-то идеальные тесты и кейсы, которые все зарание продумали, тзательно записали в спецификации, а потом каждый из них написан и протестирован программистом.
S>Да, так и работаем. Ощути тленность своего бытия
Вы не рабоатете так. Вы работаете реально по принципу «написали те тесты, что смогли придумать, ждем отзыва от тестеров и реальных пользователей. получили отзыв о баге, починили баг, написали тест». Ну то есть ровно так, как работают все.
M>>>>А про «тестеры/пользователи наткнутся», воспроизвели, поправили, написали тест, вот тебе реальная жизнь, а не фантазии. Описание решения проблемы, M>>Очень рекомендую видео, да. Как раз проказывает разницу между реальным миром и фантазиями на тему «все должно быть описано в ТЗ и протестировано».
S>Какая фантазия — реальный процесс, ты чё В мокапах, которые дают на разработку, уже показано, по какой кнопке чё происходит и всё это уже кучу раз обсуждено.
«Мокапы, кнопки». Видео посмотри один раз уже, да.
AA>>обобщенные функции в CLOS наголову выше паттерн-матча, который по сути — те же if-ы.
M>обобщенные функции в CLOS являются убогим, многословным, жестко прибитым гвоздями говном по сравнению с паттерн-матчингом. Можно начать хотя бы с того, что обобщенные функции, как видно из самого названия, доступны только для объявления функций (весьма кривым способом с парой defgeneric/defmatohd, потому что иначе «самый лучший язык на земле» даже не способен понять, что происходит). Паттерн матчинг в функциональных языках доступен как для объявления функций так и внутри функций.
M>В итоге в CLOS есть defgeneric/defmethod + куча if'ов внутри. В некоторых других языках есть просто единообразный pattern matching.
Ага, только если у вас появится новый тип, то придется пройти по всей программе и добавить в каждый матчинг новый кейс,
а в случае обобщенной функции(протоколы в кложе) достаточно добавить новую реализацию для данного типа, ни строчки не меняя в месте применения.
матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками.
AA>Ага, только если у вас появится новый тип, то придется пройти по всей программе и добавить в каждый матчинг новый кейс,
1. Не по всей
2. Рефакторинг на то и рефакторинг
AA>а в случае обобщенной функции(протоколы в кложе) достаточно добавить новую реализацию для данного типа, ни строчки не меняя в месте применения.
Повторю опять: в лиспе есть только обобщенные и весьма ограниченные мультиметоды. Не говоря уже о дикой многословности на ровном месте. Паттерн матчинг сильно шире только мультиметодов.
AA>матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками.
Один и тот же человек на полном серьезе заявляет «паттерн-матчинг — по сути те же if'ы» и «матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками».
Ты уже определись, да. Если «паттерн-матчинг — по сути те же if'ы», то по твоей же логике if'ы точно так же «связывают компоненты в спагетти», как и pattern-matching.
Это если полностью пропустить то, что pattern-matching сильно мощнее if'ов.
Здравствуйте, Mamut, Вы писали:
AA>>Ага, только если у вас появится новый тип, то придется пройти по всей программе и добавить в каждый матчинг новый кейс,
M>1. Не по всей M>2. Рефакторинг на то и рефакторинг
AA>>а в случае обобщенной функции(протоколы в кложе) достаточно добавить новую реализацию для данного типа, ни строчки не меняя в месте применения.
M>Повторю опять: в лиспе есть только обобщенные и весьма ограниченные мультиметоды. Не говоря уже о дикой многословности на ровном месте. Паттерн матчинг сильно шире только мультиметодов.
AA>>матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками.
M>Один и тот же человек на полном серьезе заявляет «паттерн-матчинг — по сути те же if'ы» и «матчинг это связывание компонентов в спагетти, которое с успехом заменяется ифчиками».
M>Ты уже определись, да. Если «паттерн-матчинг — по сути те же if'ы», то по твоей же логике if'ы точно так же «связывают компоненты в спагетти», как и pattern-matching.
M>Это если полностью пропустить то, что pattern-matching сильно мощнее if'ов.
Так я и имел ввиду, что если нужно захардкодить логику в одном месте, то матч ничем не лучше ифчиков, ну может лишь компайлер под это дело заточен.
С одной стороны хорошо, что компайлер все контролирует, с другой кодер привыкший к матчингу, работая над ифчиками может не заметить, что есть новый кейс.
Как ни крути матч или иф, все равно упираемся в опыт.
Здравствуйте, Mamut, Вы писали:
AA>>Ага, только если у вас появится новый тип, то придется пройти по всей программе и добавить в каждый матчинг новый кейс,
M>1. Не по всей M>2. Рефакторинг на то и рефакторинг
AA>>а в случае обобщенной функции(протоколы в кложе) достаточно добавить новую реализацию для данного типа, ни строчки не меняя в месте применения.
M>Повторю опять: в лиспе есть только обобщенные и весьма ограниченные мультиметоды. Не говоря уже о дикой многословности на ровном месте. Паттерн матчинг сильно шире только мультиметодов.
в каком языке матчинг менее многословен вызова одной функции? прошу пример.
Здравствуйте, Mamut, Вы писали:
M>4. Почему ты уверен, что спецификация описывает поведение пользователя, как человека. Например, в видео, которе ты, видать, никогда и не посмотришь, никакого пользователя не было. Была система под нагрузкой, которая раз в один-два месяца падала с невнятной ошибкой.
Посмотрел, чё уж. В итоге же невнятная ошибка воспроизводилась простым тест-кейсом. Ну и одновременная конкурентная работа с одним файлом конечно источник проблем.
M>>>А, месье из мира эльфов и фей.
S>>Да, из мира где выпускается MVP и потом по результатам тестирования и фидбеку от пользователей допиливается функционал приложения, которое всегда стабильно работает на заданном наборе сценариев.
M>Прекрасноэ, конечно.
M>Сначала «программисты ленивые, что не пишут тесты на все кейсы», потом «а что сложного в кейсе», потом «не, ну мы нифига не пишем все тесты, мы пишем что смошгли, а потом ждем баг репортов от тестеров и пользователей».
Да, у нас так
M>>>Ты это говоришь и описываешь какие-то идеальные тесты и кейсы, которые все зарание продумали, тзательно записали в спецификации, а потом каждый из них написан и протестирован программистом.
S>>Да, так и работаем. Ощути тленность своего бытия
M>Вы не рабоатете так. Вы работаете реально по принципу «написали те тесты, что смогли придумать, ждем отзыва от тестеров и реальных пользователей. получили отзыв о баге, починили баг, написали тест». Ну то есть ровно так, как работают все.
Ну тебе конечно виднее.
M>«Мокапы, кнопки». Видео посмотри один раз уже, да.
Да посмотрел уже, не вижу проблемы. Была непонятная ситуация, написали тест кейс, который воспроизводит эту ситуацию на раз, починили. Норм же.
S>Посмотрел, чё уж. В итоге же невнятная ошибка воспроизводилась простым тест-кейсом.
Ты даже не понял, как эту ошибку нашли
S>Ну и одновременная конкурентная работа с одним файлом конечно источник проблем.
Именно. И, видимо, согласно тебе, «непонятно, что там сложного», да? А люди, которые не написали этот тест кейс — «ленивые чо». Так?
M>>Сначала «программисты ленивые, что не пишут тесты на все кейсы», потом «а что сложного в кейсе», потом «не, ну мы нифига не пишем все тесты, мы пишем что смошгли, а потом ждем баг репортов от тестеров и пользователей».
S>Да, у нас так
Это у всех так. Только почему-то именно вы отличные молодцы, а остальные — ленивые чо. Хотя вы точно так же не покрываете тестами все тест-кейсы.
M>>Вы не рабоатете так. Вы работаете реально по принципу «написали те тесты, что смогли придумать, ждем отзыва от тестеров и реальных пользователей. получили отзыв о баге, починили баг, написали тест». Ну то есть ровно так, как работают все.
S>Ну тебе конечно виднее.
Ты это пишешь прямым текстом.
M>>«Мокапы, кнопки». Видео посмотри один раз уже, да.
S>Да посмотрел уже, не вижу проблемы. Была непонятная ситуация, написали тест кейс, который воспроизводит эту ситуацию на раз, починили. Норм же.
Не «написали тест кейс, который воспроизводит ситуацию», а:
— кейс происходил в системе, работающей под нагрузкой, раз в один-два месяца
— причины ошибки были неизвестны
— воспроизвести ошибку на тестовых машинах не получалось в течение полугода
— пришлось генерировать кучу вариантов работы с системой, чтобы найти ту последовательность действий, которая приводит к ошибкам
— хорошо, QuickCheck (использовання для генерации тестов библиотека) умеет «схлопывать» сгенерированные тесты, и находить более-менее минимальный набор действий для воспроизведения ошибки
— в итоге только после генерации тестов и схлопывания их был найден минимальный набор действий для тест-кейса
sambl74: не, ну чо там такого. простой тест кейс, написали этот тест кйс, починили, че там такого. Ленивые программисты, нет чтобы по ТЗ написать тест-кейсы.
Здравствуйте, Mamut, Вы писали:
S>>Посмотрел, чё уж. В итоге же невнятная ошибка воспроизводилась простым тест-кейсом.
M>Ты даже не понял, как эту ошибку нашли
