Aq
Такое чувство что многие не довольны обилием хаскеля на митапах. Но видимо про другие ФЯП ничего интересного рассказать нельзя, потому и нет желающих.
других и нет
Size: a a a
2018 February 26
λO
других и нет
Ну это у вас, как всегда, радикальное мнение (хотя я согласен конечно)
λO
Еще хочу добавить что в подкасте Стефик упоминает исследования других авторов на ту же тему. Но ссылок нет. Так что тут такое.
АГ
Я вот вообще не понимаю аргумент "на статике сложнее переделать". Это чушь собачья, мне на статике проще переделать ибо не надо вспоминать все тысячи мест где что-то сломается. Нужно вспомнить пару мест всего, если семантика меняется. И тестами покрыть эту пару мест куда проще.
На мой вгзляд, вообще есть некое заблуждение насчет динамики.
Тезис: с динамической типизацией разработка сложнее, чем со статической.
Создавая код на языке с ДТ, вы думаете, что вам проще писать код, так как любой ваш синтаксически правильный код принимается интерпретатором, а ошибки типизации вам не видны, пока вы не запустите свой код. Да и в этом случае вы увидите только часть проблем; а часть останется еще на более позднее время. И почему-то этот "второй этап" отлова ошибок в рантайме ощущается как отдельный, не связанный с написанием кода, и поэтому его сложность не вкладывается в сложность разработки; скорее - это ощущается как отладка. И поэтому сторонники динамической типизации утверждают, что им очень легко писать код; однако, они не учитывают всех трудозатрат. На самом деле, "второй этап" - та же самая часть разработки функционала, потому что если код некорректно работает, - значит, вы ничего не сделали, вы не доработали, и неважно, что он запускается. Ведь от него нет толку.
В то же время, в статически типизированных языках компилятор очень больно бьет за ошибки типизации прямо с самого начала. Создается ощущение, что программироавть сложнее, так как для получения того же самого результата приходится вкладываться именно в написание кода, приходится исправлять эти ошибки прямо сейчас, а не когда-нибудь потом. Но это правильно, потому что это и значит - реализовать фичу.
Конечно, есть еще логические ошибки, но они есть в программах на любых языках, поэтому мы их сюда не относим.
Тезис: с динамической типизацией разработка сложнее, чем со статической.
Создавая код на языке с ДТ, вы думаете, что вам проще писать код, так как любой ваш синтаксически правильный код принимается интерпретатором, а ошибки типизации вам не видны, пока вы не запустите свой код. Да и в этом случае вы увидите только часть проблем; а часть останется еще на более позднее время. И почему-то этот "второй этап" отлова ошибок в рантайме ощущается как отдельный, не связанный с написанием кода, и поэтому его сложность не вкладывается в сложность разработки; скорее - это ощущается как отладка. И поэтому сторонники динамической типизации утверждают, что им очень легко писать код; однако, они не учитывают всех трудозатрат. На самом деле, "второй этап" - та же самая часть разработки функционала, потому что если код некорректно работает, - значит, вы ничего не сделали, вы не доработали, и неважно, что он запускается. Ведь от него нет толку.
В то же время, в статически типизированных языках компилятор очень больно бьет за ошибки типизации прямо с самого начала. Создается ощущение, что программироавть сложнее, так как для получения того же самого результата приходится вкладываться именно в написание кода, приходится исправлять эти ошибки прямо сейчас, а не когда-нибудь потом. Но это правильно, потому что это и значит - реализовать фичу.
Конечно, есть еще логические ошибки, но они есть в программах на любых языках, поэтому мы их сюда не относим.
AK
> если код некорректно работает — вы ничего не сделали
так получается, что я за всю свою жизнь ничего не сделал 🤷♀
так получается, что я за всю свою жизнь ничего не сделал 🤷♀
λO
На мой вгзляд, вообще есть некое заблуждение насчет динамики.
Тезис: с динамической типизацией разработка сложнее, чем со статической.
Создавая код на языке с ДТ, вы думаете, что вам проще писать код, так как любой ваш синтаксически правильный код принимается интерпретатором, а ошибки типизации вам не видны, пока вы не запустите свой код. Да и в этом случае вы увидите только часть проблем; а часть останется еще на более позднее время. И почему-то этот "второй этап" отлова ошибок в рантайме ощущается как отдельный, не связанный с написанием кода, и поэтому его сложность не вкладывается в сложность разработки; скорее - это ощущается как отладка. И поэтому сторонники динамической типизации утверждают, что им очень легко писать код; однако, они не учитывают всех трудозатрат. На самом деле, "второй этап" - та же самая часть разработки функционала, потому что если код некорректно работает, - значит, вы ничего не сделали, вы не доработали, и неважно, что он запускается. Ведь от него нет толку.
В то же время, в статически типизированных языках компилятор очень больно бьет за ошибки типизации прямо с самого начала. Создается ощущение, что программироавть сложнее, так как для получения того же самого результата приходится вкладываться именно в написание кода, приходится исправлять эти ошибки прямо сейчас, а не когда-нибудь потом. Но это правильно, потому что это и значит - реализовать фичу.
Конечно, есть еще логические ошибки, но они есть в программах на любых языках, поэтому мы их сюда не относим.
Тезис: с динамической типизацией разработка сложнее, чем со статической.
Создавая код на языке с ДТ, вы думаете, что вам проще писать код, так как любой ваш синтаксически правильный код принимается интерпретатором, а ошибки типизации вам не видны, пока вы не запустите свой код. Да и в этом случае вы увидите только часть проблем; а часть останется еще на более позднее время. И почему-то этот "второй этап" отлова ошибок в рантайме ощущается как отдельный, не связанный с написанием кода, и поэтому его сложность не вкладывается в сложность разработки; скорее - это ощущается как отладка. И поэтому сторонники динамической типизации утверждают, что им очень легко писать код; однако, они не учитывают всех трудозатрат. На самом деле, "второй этап" - та же самая часть разработки функционала, потому что если код некорректно работает, - значит, вы ничего не сделали, вы не доработали, и неважно, что он запускается. Ведь от него нет толку.
В то же время, в статически типизированных языках компилятор очень больно бьет за ошибки типизации прямо с самого начала. Создается ощущение, что программироавть сложнее, так как для получения того же самого результата приходится вкладываться именно в написание кода, приходится исправлять эти ошибки прямо сейчас, а не когда-нибудь потом. Но это правильно, потому что это и значит - реализовать фичу.
Конечно, есть еще логические ошибки, но они есть в программах на любых языках, поэтому мы их сюда не относим.
Ну и у классических СТ ЯП всё плохо с REPLами
λO
> если код некорректно работает — вы ничего не сделали
так получается, что я за всю свою жизнь ничего не сделал 🤷♀
так получается, что я за всю свою жизнь ничего не сделал 🤷♀
Горькая правда о программистах
АГ
Степерь корректности программы можно обсуждать, но в целом, если фича не делает того, что от нее ждут, - она не работает.
АГ
Тем более, если код, с ней связанный, крашится.
AK
> логические ошибки есть в программах на любых языках
какая мне разница, почему мой код некорректно работает – из-за логической ошибки или из-за ошибки типизации?
какая мне разница, почему мой код некорректно работает – из-за логической ошибки или из-за ошибки типизации?
AK
Степерь корректности программы можно обсуждать, но в целом, если фича не делает того, что от нее ждут, - она не работает.
черно-белое деление
АГ
> логические ошибки есть в программах на любых языках
какая мне разница, почему мой код некорректно работает – из-за логической ошибки или из-за ошибки типизации?
какая мне разница, почему мой код некорректно работает – из-за логической ошибки или из-за ошибки типизации?
Я написал ясно, что мы не учитываем логические ошибки ни для динамически типизированных, ни для статически типизированных языков. Это - отдельный класс ошибок.
AK
почему отдельный?
PK
Ну и у классических СТ ЯП всё плохо с REPLами
У F# все хорошо
АГ
почему отдельный?
Разве это подлежит сомнению?
λO
У F# все хорошо
я про яву с плюсами
AK
да
я вот сомневаюсь
я вот сомневаюсь
АГ
Обычное общепринятое деление
λO
Ну если ты вместо юзернейма подал фамилию то это ошибка типизации. Если ты забыл проверить пароль то это логическая ошибка же
AK
а ошибка, которая в хаскеле могла бы найтись, если бы там были refinement types — это логическая ошибка или ошибка типов?