Менеджер про хаскель в продакшне
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.10.13 16:04
Оценка: 30 (4) +1
Извиняюсь за хабр и жэжэ !

Исходная посылка

Коментарий того самого eao197

Еще коментарии
Re: Менеджер про хаскель в продакшне
От: Abyx Россия  
Дата: 10.10.13 17:53
Оценка: -9 :))) :)
Здравствуйте, Ikemefula, Вы писали:

I>Исходная посылка

спасибо, интересная статья.

I>Коментарий того самого eao197

я хз кто такой eao197, но он пишет очень глупые вещи %)
In Zen We Trust
Re[2]: Менеджер про хаскель в продакшне
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.10.13 17:57
Оценка: 2 (1)
Здравствуйте, Abyx, Вы писали:

I>>Исходная посылка

A>спасибо, интересная статья.

I>>Коментарий того самого eao197

A>я хз кто такой eao197, но он пишет очень глупые вещи %)

Вот
http://rsdn.ru/stat/top/philosophy
Re[2]: Менеджер про хаскель в продакшне
От: Alex912  
Дата: 10.10.13 18:49
Оценка:
Здравствуйте, Abyx, Вы писали:

A>я хз кто такой eao197, но он пишет очень глупые вещи %)


А в чем глупость?
Re[3]: Менеджер про хаскель в продакшне
От: Abyx Россия  
Дата: 10.10.13 19:15
Оценка: :)
Здравствуйте, Alex912, Вы писали:

A>>я хз кто такой eao197, но он пишет очень глупые вещи %)

A>А в чем глупость?

зачем переписывать код на хаскел — глупый вопрос, ответ очевиден — программистам надо кушать и развлекаться, иначе они разбегутся.
ну и еще есть мечта что "код станет лучше".

программы питоне не медленные, т.к. обычно это "скрипты для управления быстрыми библиотеками на Си".

автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.
In Zen We Trust
Re: Менеджер про хаскель в продакшне
От: DarkEld3r  
Дата: 10.10.13 22:15
Оценка:
Как-то не понял этот аргумент совсем:

По опыту разборов найденных ошибок я могу сказать, что большая часть ошибок, с которыми мы сталкивались — это либо ошибка в ТЗ (то есть ошибка вашего покорного слуги), либо неправильно понятое ТЗ программистами. Но не локальная ошибка или забывчивость.

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

Разве из этого следует, что в языках с динамической типизацией нет "сложных" багов (ошибка в тз)? Тогда проще пофиксить разве что "средний баг", а в целом наоборот хуже ведь? А преподносится как достоинство, ну или мне так показалось.
Re[2]: Менеджер про хаскель в продакшне
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.13 05:01
Оценка:
Здравствуйте, DarkEld3r, Вы писали:

DE>Как-то не понял этот аргумент совсем:

DE>

DE>По опыту разборов найденных ошибок я могу сказать, что большая часть ошибок, с которыми мы сталкивались — это либо ошибка в ТЗ (то есть ошибка вашего покорного слуги), либо неправильно понятое ТЗ программистами. Но не локальная ошибка или забывчивость.

DE>Из этого вытекает парадоксальный вывод: баги в программе на Хаскеле фиксить сложнее, чем в языках с динамической типизацией, потому что в языке с динамической типизацией очередное место, где вдруг внезапно вылез NoneType, поправил и ладушки, а на Хаскеле надо с алгоритмом разбираться да по повводу неясности ТЗ с другими людьми ругаться.

DE>Разве из этого следует, что в языках с динамической типизацией нет "сложных" багов (ошибка в тз)? Тогда проще пофиксить разве что "средний баг", а в целом наоборот хуже ведь? А преподносится как достоинство, ну или мне так показалось.

Не ясно, что он имел ввиду. Может взял сравнил чисто среднее время на фикс в Питоне и Хаскеле, ежу понятно, что в Хаскеле это будет больше, если меньше багов из за забывчивости. А может другая идея — костылями обкладывать в Хаскеле дороже.
Re[2]: Менеджер про хаскель в продакшне
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 11.10.13 05:15
Оценка: 2 (2) +1 -1
Здравствуйте, DarkEld3r, Вы писали:

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

Ура!

С хорошей статтипизацией подобный подход не работает, приходится реально думать о проблеме, а не тупо делать подкладки под тесты.
Re[3]: Менеджер про хаскель в продакшне
От: monax  
Дата: 11.10.13 09:30
Оценка:
Здравствуйте, 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>С хорошей статтипизацией подобный подход не работает, приходится реально думать о проблеме, а не тупо делать подкладки под тесты.

Может оно и так, но вот глядя на твой пример, я не могу понять, как тебе строгая типизация тут поможет. Ты не добавил новых типов данных, ты только увеличил количество операндов в логическом выражении. Как тут хорошая статическая типизация спасёт? И давай заодно определимся с терминами, чтобы не путать друг друга: в каком языке статическая типизация хорошая, а где плохая?
Re[4]: Менеджер про хаскель в продакшне
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 11.10.13 10:20
Оценка:
Здравствуйте, monax, Вы писали:

M>Может оно и так, но вот глядя на твой пример, я не могу понять, как тебе строгая типизация тут поможет.


Это была лишь утрированная иллюстрация самой идеи, подхода, не конкретный пример для обсуждения.

M> Ты не добавил новых типов данных, ты только увеличил количество операндов в логическом выражении. Как тут хорошая статическая типизация спасёт?


Если угодно, вот тут есть примеры, где типы позволяют отловить в том числе ошибки в арифметике:
http://thedeemon.livejournal.com/59724.html
http://thedeemon.livejournal.com/41035.html
http://thedeemon.livejournal.com/41545.html

M> И давай заодно определимся с терминами, чтобы не путать друг друга: в каком языке статическая типизация хорошая, а где плохая?


Например так: в Си и Java плохая, в Хаскеле и Окамле близка к хорошей, в Идрисе, Агде и ATS, пожалуй, хорошая.
Re[4]: Менеджер про хаскель в продакшне
От: Plague Россия http://web.icq.com/whitepages/online?icq=177230800&img=5177230800
Дата: 11.10.13 10:47
Оценка: +1
Здравствуйте, Abyx, Вы писали:

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

Вы путаете вопросы "Зачем" и "Почему", т.е. цель переписывания на Хаскелл неясна, а вот причины понятны...

A>ну и еще есть мечта что "код станет лучше".

код зависит от программистов, а если программисты остались те же, только знают новый язык хуже, то не думаю, что стоит ожидать улучшения кода

A>программы питоне не медленные, т.к. обычно это "скрипты для управления быстрыми библиотеками на Си".

я так понимаю, автор имел ввиду, что питон управляет внешними библиотеками/утилитами на которых и лежит основная нагрузка, поэтому оптимизировать там, где не тормозит — не стоит

A>автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.

Юнит тесты не решают архитектурных "изысков" и не очевидных решений, зато могут отловить опечатки и ошибки "копи-паста", особенно в динамических языках
http://rsdn.org/tools/member.aspx?id=Plague
Re: Менеджер про хаскель в продакшне
От: artem.komisarenko Украина  
Дата: 11.10.13 23:33
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Коментарий того самого eao197


Всё правильно сказал
Updated: Нет, не всё
Re[2]: Менеджер про хаскель в продакшне
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.10.13 20:23
Оценка: +1
Здравствуйте, Abyx, Вы писали:

A>я хз кто такой eao197, но он пишет очень глупые вещи %)


Глупость там в основном в абзаце про растаманов программистов из глубинки. Остальное более менее по делу.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re: Менеджер про хаскель в продакшне
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.10.13 18:44
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

I>Извиняюсь за хабр и жэжэ !


I>Исходная посылка


Статья совершенно ни о чём.

I>Коментарий того самого eao197


I>Еще коментарии


Женя (eao197) всё, в сущности, правильно написал. Самого главного из исходной статьи не понятно: что же именно переписывали и в каком контексте обитает разработка. Можно строить предположения, но они останутся предположениями.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Менеджер про хаскель в продакшне
От: neFormal Россия  
Дата: 26.10.13 19:19
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Извиняюсь за хабр и жэжэ !

I>Исходная посылка
I>Коментарий того самого eao197
I>Еще коментарии

тема проблем не раскрыта. требуются слайды.
...coding for chaos...
Re[4]: Менеджер про хаскель в продакшне
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.10.13 19:50
Оценка:
Здравствуйте, Abyx, Вы писали:

A>>>я хз кто такой eao197, но он пишет очень глупые вещи %)

A>>А в чем глупость?
A>зачем переписывать код на хаскел — глупый вопрос, ответ очевиден — программистам надо кушать и развлекаться, иначе они разбегутся.
A>ну и еще есть мечта что "код станет лучше".

Решение о переписывании в конечном итоге принимает менеджмент, поскольку он отвечает за использование средств компании. И вопрос "зачем" eao197 ставит, прежде всего, с позиций руководителя.

Но зачем, почему? Это не праздные вопросы для ПМа и руководства.


Насколько я понял, предыстория описана здесь: Открытие облака для новых клиентов. И там описаны вполне рациональные причины если и не перехода на Haskell, то уж по крайней мере — отказа от Python.

A>программы питоне не медленные, т.к. обычно это "скрипты для управления быстрыми библиотеками на Си".


A>автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.


eao197 прямо говорит, что тестирование — единственный способ бороться с ошибками "забывчивости" в динамических языках.

Вообще, когда якобы ПМ начинает говорить, что в выпущенном в продакшен Питоновском коде вылазят ошибки типизации или отсутствие обработки каких-то ситуаций, то этот ПМ сам расписывается в собственной неспособности управлять разработкой. Да, в языках с динамической типизацией есть такая особенность. ПМ этого не знал? Не знал того, что единственным способом борьбы с этим явлением является тестирование [...]


*Все* ошибки не выловят ни тесты, ни наилучшие языки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: Менеджер про хаскель в продакшне
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.10.13 19:57
Оценка:
ГВ>Насколько я понял, предыстория описана здесь: Открытие облака для новых клиентов. И там описаны вполне рациональные причины если и не перехода на Haskell, то уж по крайней мере — отказа от Python.

Забавно, но оказывается, что это событие "обсуждалось" и на RSDN: http://www.rsdn.ru/forum/flame.comp/4616391.1
Автор: graninas
Дата: 14.02.12
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: Менеджер про хаскель в продакшне
От: Abyx Россия  
Дата: 26.10.13 22:03
Оценка: -2
Здравствуйте, Геннадий Васильев, Вы писали:

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


A>>>>я хз кто такой eao197, но он пишет очень глупые вещи %)

A>>>А в чем глупость?
A>>зачем переписывать код на хаскел — глупый вопрос, ответ очевиден — программистам надо кушать и развлекаться, иначе они разбегутся.
A>>ну и еще есть мечта что "код станет лучше".

ГВ>Решение о переписывании в конечном итоге принимает менеджмент, поскольку он отвечает за использование средств компании. И вопрос "зачем" eao197 ставит, прежде всего, с позиций руководителя.


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

когда в плане пусто, программистов надо чем-то занять, и перепиливание кода — один из лучших вариантов, IMO.

ГВ>

Но зачем, почему? Это не праздные вопросы для ПМа и руководства.


так что по-моему это вопросы из серии "зачем в армии строем ходят"

ГВ>Насколько я понял, предыстория описана здесь: Открытие облака для новых клиентов. И там описаны вполне рациональные причины если и не перехода на Haskell, то уж по крайней мере — отказа от Python.


A>>автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.


ГВ>eao197 прямо говорит, что тестирование — единственный способ бороться с ошибками "забывчивости" в динамических языках.


ГВ>

Вообще, когда якобы ПМ начинает говорить, что в выпущенном в продакшен Питоновском коде вылазят ошибки типизации или отсутствие обработки каких-то ситуаций, то этот ПМ сам расписывается в собственной неспособности управлять разработкой. Да, в языках с динамической типизацией есть такая особенность. ПМ этого не знал? Не знал того, что единственным способом борьбы с этим явлением является тестирование [...]


ГВ>*Все* ошибки не выловят ни тесты, ни наилучшие языки.


в статье написано

Тесты, которые «покрывают весь код», к сожалению, совсем не покрывают «все возможные типы входных данных» (которые, внезапно, динамические) и совсем не спасают от ошибок типизации.


я из этого понял что у них уже были автоматические тесты, и были баги которые тесты не отлавливали.
а вот eao197 то ли этот абзац не читал, или говорит что "они не умеют тестировать, вот если бы там был Я, багов бы не было вообще."
In Zen We Trust
Re[6]: Менеджер про хаскель в продакшне
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.10.13 00:18
Оценка: +2
Здравствуйте, Abyx, Вы писали:

ГВ>>Решение о переписывании в конечном итоге принимает менеджмент, поскольку он отвечает за использование средств компании. И вопрос "зачем" eao197 ставит, прежде всего, с позиций руководителя.


A>средства компании тратятся в любом случае, ежемесячно, на зарплату программистам.

A>в не зависимости от того чем они занимаются.
A>когда в плане пусто, программистов надо чем-то занять, и перепиливание кода — один из лучших вариантов, IMO.

На каком основании ты решил, что "в плане пусто"? Цитату можешь привести?

ГВ>>

Но зачем, почему? Это не праздные вопросы для ПМа и руководства.

A>так что по-моему это вопросы из серии "зачем в армии строем ходят"

Это вопросы, которые обязан задавать ПМ. Вне зависимости от того, какие у кого коннотации возникают по этому поводу.

ГВ>>Насколько я понял, предыстория описана здесь: Открытие облака для новых клиентов. И там описаны вполне рациональные причины если и не перехода на Haskell, то уж по крайней мере — отказа от Python.

A>>>автор верит в 146% процентное покрытие программы автоматическими тестами, и что юнит тесты могут выловить *все* ошибки.

ГВ>>eao197 прямо говорит, что тестирование — единственный способ бороться с ошибками "забывчивости" в динамических языках.


ГВ>>

Вообще, когда якобы ПМ начинает говорить, что в выпущенном в продакшен Питоновском коде вылазят ошибки типизации или отсутствие обработки каких-то ситуаций, то этот ПМ сам расписывается в собственной неспособности управлять разработкой. Да, в языках с динамической типизацией есть такая особенность. ПМ этого не знал? Не знал того, что единственным способом борьбы с этим явлением является тестирование [...]


ГВ>>*Все* ошибки не выловят ни тесты, ни наилучшие языки.


A>в статье написано

A>

A>Тесты, которые «покрывают весь код», к сожалению, совсем не покрывают «все возможные типы входных данных» (которые, внезапно, динамические) и совсем не спасают от ошибок типизации.


A>я из этого понял что у них уже были автоматические тесты, и были баги которые тесты не отлавливали.


Из этого следует, что тестовое покрытие было недостаточным. Что вполне естественно — если язык допускает "Not implemented"-методы, то тесты должны покрывать *все* случаи, где такие методы могут быть задействованы. Очевидно, что этого сделано не было.

Пребанальнейший вывод, не правда ли?

A>а вот eao197 то ли этот абзац не читал, или говорит что "они не умеют тестировать, вот если бы там был Я, багов бы не было вообще."


Оспаривать то, что тебе показалось, я не собираюсь. Разбирайся со своими тараканами сам. Могу только посоветовать перечитать то, что написано у Охотникова (eao197), там всё вполне однозначно изложено.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Менеджер про хаскель в продакшне
От: Abyx Россия  
Дата: 27.10.13 09:45
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>*Все* ошибки не выловят ни тесты, ни наилучшие языки.


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
In Zen We Trust
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.