Здравствуйте, Alex912, Вы писали:
A>>я хз кто такой eao197, но он пишет очень глупые вещи %) A>А в чем глупость?
зачем переписывать код на хаскел — глупый вопрос, ответ очевиден — программистам надо кушать и развлекаться, иначе они разбегутся.
ну и еще есть мечта что "код станет лучше".
программы питоне не медленные, т.к. обычно это "скрипты для управления быстрыми библиотеками на Си".
автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.
По опыту разборов найденных ошибок я могу сказать, что большая часть ошибок, с которыми мы сталкивались — это либо ошибка в ТЗ (то есть ошибка вашего покорного слуги), либо неправильно понятое ТЗ программистами. Но не локальная ошибка или забывчивость.
Из этого вытекает парадоксальный вывод: баги в программе на Хаскеле фиксить сложнее, чем в языках с динамической типизацией, потому что в языке с динамической типизацией очередное место, где вдруг внезапно вылез NoneType, поправил и ладушки, а на Хаскеле надо с алгоритмом разбираться да по повводу неясности ТЗ с другими людьми ругаться.
Разве из этого следует, что в языках с динамической типизацией нет "сложных" багов (ошибка в тз)? Тогда проще пофиксить разве что "средний баг", а в целом наоборот хуже ведь? А преподносится как достоинство, ну или мне так показалось.
Здравствуйте, DarkEld3r, Вы писали:
DE>Как-то не понял этот аргумент совсем: DE>
DE>По опыту разборов найденных ошибок я могу сказать, что большая часть ошибок, с которыми мы сталкивались — это либо ошибка в ТЗ (то есть ошибка вашего покорного слуги), либо неправильно понятое ТЗ программистами. Но не локальная ошибка или забывчивость.
DE>Из этого вытекает парадоксальный вывод: баги в программе на Хаскеле фиксить сложнее, чем в языках с динамической типизацией, потому что в языке с динамической типизацией очередное место, где вдруг внезапно вылез NoneType, поправил и ладушки, а на Хаскеле надо с алгоритмом разбираться да по повводу неясности ТЗ с другими людьми ругаться.
DE>Разве из этого следует, что в языках с динамической типизацией нет "сложных" багов (ошибка в тз)? Тогда проще пофиксить разве что "средний баг", а в целом наоборот хуже ведь? А преподносится как достоинство, ну или мне так показалось.
Не ясно, что он имел ввиду. Может взял сравнил чисто среднее время на фикс в Питоне и Хаскеле, ежу понятно, что в Хаскеле это будет больше, если меньше багов из за забывчивости. А может другая идея — костылями обкладывать в Хаскеле дороже.
Из этого вытекает парадоксальный вывод: баги в программе на Хаскеле фиксить сложнее, чем в языках с динамической типизацией, потому что в языке с динамической типизацией очередное место, где вдруг внезапно вылез NoneType, поправил и ладушки, а на Хаскеле надо с алгоритмом разбираться да по повводу неясности ТЗ с другими людьми ругаться.
DE>Разве из этого следует, что в языках с динамической типизацией нет "сложных" багов (ошибка в тз)? Тогда проще пофиксить разве что "средний баг", а в целом наоборот хуже ведь? А преподносится как достоинство, ну или мне так показалось.
Языки с продвинутой статтипизацией заставляют больше думать. В иных языках можно вставлять заплатки по месту и так из заплаток все и строить, типа:
def isPrime(x)
x==2 || x % 2 == 1
end
тесты:
isPrime(2) == true
isPrime(3) == true
isPrime(7) == true
isPrime(10) == false
isPrime(11) == true
пока неплохо
isPrime(9) == false
упс, тест не прошел, но у нас же TDD, в миг все поправим:
def isPrime(x)
x==2 || (x % 2 == 1 && x != 9)
end
Ура!
С хорошей статтипизацией подобный подход не работает, приходится реально думать о проблеме, а не тупо делать подкладки под тесты.
Здравствуйте, D. Mon, Вы писали:
DM>Языки с продвинутой статтипизацией заставляют больше думать. В иных языках можно вставлять заплатки по месту и так из заплаток все и строить, типа: DM>
DM>def isPrime(x)
DM> x==2 || x % 2 == 1
DM>end
DM>тесты:
DM>isPrime(2) == true
DM>isPrime(3) == true
DM>isPrime(7) == true
DM>isPrime(10) == false
DM>isPrime(11) == true
DM>пока неплохо
DM>isPrime(9) == false
DM>упс, тест не прошел, но у нас же TDD, в миг все поправим:
DM>def isPrime(x)
DM> x==2 || (x % 2 == 1 && x != 9)
DM>end
DM>Ура!
DM>
DM>С хорошей статтипизацией подобный подход не работает, приходится реально думать о проблеме, а не тупо делать подкладки под тесты.
Может оно и так, но вот глядя на твой пример, я не могу понять, как тебе строгая типизация тут поможет. Ты не добавил новых типов данных, ты только увеличил количество операндов в логическом выражении. Как тут хорошая статическая типизация спасёт? И давай заодно определимся с терминами, чтобы не путать друг друга: в каком языке статическая типизация хорошая, а где плохая?
Здравствуйте, monax, Вы писали:
M>Может оно и так, но вот глядя на твой пример, я не могу понять, как тебе строгая типизация тут поможет.
Это была лишь утрированная иллюстрация самой идеи, подхода, не конкретный пример для обсуждения.
M> Ты не добавил новых типов данных, ты только увеличил количество операндов в логическом выражении. Как тут хорошая статическая типизация спасёт?
Здравствуйте, Abyx, Вы писали:
A>зачем переписывать код на хаскел — глупый вопрос, ответ очевиден — программистам надо кушать и развлекаться, иначе они разбегутся.
Вы путаете вопросы "Зачем" и "Почему", т.е. цель переписывания на Хаскелл неясна, а вот причины понятны...
A>ну и еще есть мечта что "код станет лучше".
код зависит от программистов, а если программисты остались те же, только знают новый язык хуже, то не думаю, что стоит ожидать улучшения кода
A>программы питоне не медленные, т.к. обычно это "скрипты для управления быстрыми библиотеками на Си".
я так понимаю, автор имел ввиду, что питон управляет внешними библиотеками/утилитами на которых и лежит основная нагрузка, поэтому оптимизировать там, где не тормозит — не стоит
A>автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.
Юнит тесты не решают архитектурных "изысков" и не очевидных решений, зато могут отловить опечатки и ошибки "копи-паста", особенно в динамических языках
Женя (eao197) всё, в сущности, правильно написал. Самого главного из исходной статьи не понятно: что же именно переписывали и в каком контексте обитает разработка. Можно строить предположения, но они останутся предположениями.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Abyx, Вы писали:
A>>>я хз кто такой eao197, но он пишет очень глупые вещи %) A>>А в чем глупость? A>зачем переписывать код на хаскел — глупый вопрос, ответ очевиден — программистам надо кушать и развлекаться, иначе они разбегутся. A>ну и еще есть мечта что "код станет лучше".
Решение о переписывании в конечном итоге принимает менеджмент, поскольку он отвечает за использование средств компании. И вопрос "зачем" eao197 ставит, прежде всего, с позиций руководителя.
Но зачем, почему? Это не праздные вопросы для ПМа и руководства.
Насколько я понял, предыстория описана здесь: Открытие облака для новых клиентов. И там описаны вполне рациональные причины если и не перехода на Haskell, то уж по крайней мере — отказа от Python.
A>программы питоне не медленные, т.к. обычно это "скрипты для управления быстрыми библиотеками на Си".
A>автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.
eao197 прямо говорит, что тестирование — единственный способ бороться с ошибками "забывчивости" в динамических языках.
Вообще, когда якобы ПМ начинает говорить, что в выпущенном в продакшен Питоновском коде вылазят ошибки типизации или отсутствие обработки каких-то ситуаций, то этот ПМ сам расписывается в собственной неспособности управлять разработкой. Да, в языках с динамической типизацией есть такая особенность. ПМ этого не знал? Не знал того, что единственным способом борьбы с этим явлением является тестирование [...]
*Все* ошибки не выловят ни тесты, ни наилучшие языки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Насколько я понял, предыстория описана здесь: Открытие облака для новых клиентов. И там описаны вполне рациональные причины если и не перехода на Haskell, то уж по крайней мере — отказа от Python.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Abyx, Вы писали:
A>>>>я хз кто такой eao197, но он пишет очень глупые вещи %) A>>>А в чем глупость? A>>зачем переписывать код на хаскел — глупый вопрос, ответ очевиден — программистам надо кушать и развлекаться, иначе они разбегутся. A>>ну и еще есть мечта что "код станет лучше".
ГВ>Решение о переписывании в конечном итоге принимает менеджмент, поскольку он отвечает за использование средств компании. И вопрос "зачем" eao197 ставит, прежде всего, с позиций руководителя.
средства компании тратятся в любом случае, ежемесячно, на зарплату программистам.
в не зависимости от того чем они занимаются.
когда в плане пусто, программистов надо чем-то занять, и перепиливание кода — один из лучших вариантов, IMO.
ГВ>
Но зачем, почему? Это не праздные вопросы для ПМа и руководства.
так что по-моему это вопросы из серии "зачем в армии строем ходят"
ГВ>Насколько я понял, предыстория описана здесь: Открытие облака для новых клиентов. И там описаны вполне рациональные причины если и не перехода на Haskell, то уж по крайней мере — отказа от Python.
A>>автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.
ГВ>eao197 прямо говорит, что тестирование — единственный способ бороться с ошибками "забывчивости" в динамических языках.
ГВ>
Вообще, когда якобы ПМ начинает говорить, что в выпущенном в продакшен Питоновском коде вылазят ошибки типизации или отсутствие обработки каких-то ситуаций, то этот ПМ сам расписывается в собственной неспособности управлять разработкой. Да, в языках с динамической типизацией есть такая особенность. ПМ этого не знал? Не знал того, что единственным способом борьбы с этим явлением является тестирование [...]
ГВ>*Все* ошибки не выловят ни тесты, ни наилучшие языки.
в статье написано
Тесты, которые «покрывают весь код», к сожалению, совсем не покрывают «все возможные типы входных данных» (которые, внезапно, динамические) и совсем не спасают от ошибок типизации.
я из этого понял что у них уже были автоматические тесты, и были баги которые тесты не отлавливали.
а вот eao197 то ли этот абзац не читал, или говорит что "они не умеют тестировать, вот если бы там был Я, багов бы не было вообще."
Здравствуйте, Abyx, Вы писали:
ГВ>>Решение о переписывании в конечном итоге принимает менеджмент, поскольку он отвечает за использование средств компании. И вопрос "зачем" eao197 ставит, прежде всего, с позиций руководителя.
A>средства компании тратятся в любом случае, ежемесячно, на зарплату программистам. A>в не зависимости от того чем они занимаются. A>когда в плане пусто, программистов надо чем-то занять, и перепиливание кода — один из лучших вариантов, IMO.
На каком основании ты решил, что "в плане пусто"? Цитату можешь привести?
ГВ>>
Но зачем, почему? Это не праздные вопросы для ПМа и руководства.
A>так что по-моему это вопросы из серии "зачем в армии строем ходят"
Это вопросы, которые обязан задавать ПМ. Вне зависимости от того, какие у кого коннотации возникают по этому поводу.
ГВ>>Насколько я понял, предыстория описана здесь: Открытие облака для новых клиентов. И там описаны вполне рациональные причины если и не перехода на Haskell, то уж по крайней мере — отказа от Python. A>>>автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.
ГВ>>eao197 прямо говорит, что тестирование — единственный способ бороться с ошибками "забывчивости" в динамических языках.
ГВ>>
Вообще, когда якобы ПМ начинает говорить, что в выпущенном в продакшен Питоновском коде вылазят ошибки типизации или отсутствие обработки каких-то ситуаций, то этот ПМ сам расписывается в собственной неспособности управлять разработкой. Да, в языках с динамической типизацией есть такая особенность. ПМ этого не знал? Не знал того, что единственным способом борьбы с этим явлением является тестирование [...]
ГВ>>*Все* ошибки не выловят ни тесты, ни наилучшие языки.
A>в статье написано A>
A>Тесты, которые «покрывают весь код», к сожалению, совсем не покрывают «все возможные типы входных данных» (которые, внезапно, динамические) и совсем не спасают от ошибок типизации.
A>я из этого понял что у них уже были автоматические тесты, и были баги которые тесты не отлавливали.
Из этого следует, что тестовое покрытие было недостаточным. Что вполне естественно — если язык допускает "Not implemented"-методы, то тесты должны покрывать *все* случаи, где такие методы могут быть задействованы. Очевидно, что этого сделано не было.
Пребанальнейший вывод, не правда ли?
A>а вот eao197 то ли этот абзац не читал, или говорит что "они не умеют тестировать, вот если бы там был Я, багов бы не было вообще."
Оспаривать то, что тебе показалось, я не собираюсь. Разбирайся со своими тараканами сам. Могу только посоветовать перечитать то, что написано у Охотникова (eao197), там всё вполне однозначно изложено.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>*Все* ошибки не выловят ни тесты, ни наилучшие языки.
A>>в статье написано A>>
A>>Тесты, которые «покрывают весь код», к сожалению, совсем не покрывают «все возможные типы входных данных» (которые, внезапно, динамические) и совсем не спасают от ошибок типизации.
A>>я из этого понял что у них уже были автоматические тесты, и были баги которые тесты не отлавливали.
ГВ>Из этого следует, что тестовое покрытие было недостаточным. Что вполне естественно — если язык допускает "Not implemented"-методы, то тесты должны покрывать *все* случаи, где такие методы могут быть задействованы. Очевидно, что этого сделано не было.
ты сам себе противоречишь.
сначала ты говоришь "*Все* ошибки не выловят ни тесты, ни наилучшие языки.", а потом "тестовое покрытие было недостаточным, тесты должны покрывать *все* случаи".
кстати с статье говорится не про "Not implemented"-методы, а про "Null Pointer Dereference" (Object of type 'NoneType' has no method), но это не важно.
давай может возьмем конкретный пример?
def call_foo(obj):
obj.foo()
вызовов call_foo много и они равномерно размазаны по всему коду
расскажи пожалуйста какие тесты ты напишешь чтобы покрыть все случаи вызова call_foo с любыми obj
