Size: a a a

Clojure — русскоговорящее сообщество

2021 January 21

TP

Tim Plotnikov in Clojure — русскоговорящее сообщество
Иван Федоров
Я ищу исследование-оценку количества и стоимости разных типов ошибок в проекте. Потому что статика несёт значительные ограничения на дизайн, а ради чего? Чтобы предотвратить 5% достаточно тривиальных ошибок.
Я вот сколько не размышлял, приходил к выводу что стат. типизация всё-таки важна, особенно на больших проектах. И долгих.
Всё-таки, если ты можешь часть работы сгрузить на компилятор, то это лучше чем когда эту работу придется делать самому.
источник

TP

Tim Plotnikov in Clojure — русскоговорящее сообщество
И мы не говорим про тесты сейчас, потому что тесты это optional
источник

TP

Tim Plotnikov in Clojure — русскоговорящее сообщество
В конечном итоге мы опять приходим к тому, что под каждый конкретный случай ты выбираешь подход в силу прошлого опыта, воспитания, детских травм итд)
источник

D

Dos in Clojure — русскоговорящее сообщество
Иван Федоров
Конечно, физкультура, еда и сон важнее. Но тесты и ассёрты на месте меня сильно выручают. Надо только понимать, на что писать тесты, чтобы бонусы от тестов окупали затраты
тесты хоть дают какие-то минимальные гарантии
источник

ИФ

Иван Федоров... in Clojure — русскоговорящее сообщество
Tim Plotnikov
Я вот сколько не размышлял, приходил к выводу что стат. типизация всё-таки важна, особенно на больших проектах. И долгих.
Всё-таки, если ты можешь часть работы сгрузить на компилятор, то это лучше чем когда эту работу придется делать самому.
Ну вот у кложи мне очень нравится сейчас подход. Я могу накидать хинтов для понимания, я могу добавить спеку для проверок и понимания, я пишу тесты на ключевые 10-20% кода которые ловят 80-90% ошибок.
источник

ST

Sergey Trofimov in Clojure — русскоговорящее сообщество
Иван Федоров
Ну вот у кложи мне очень нравится сейчас подход. Я могу накидать хинтов для понимания, я могу добавить спеку для проверок и понимания, я пишу тесты на ключевые 10-20% кода которые ловят 80-90% ошибок.
Плюс comment блок с примерами кода для репла
источник

ИФ

Иван Федоров... in Clojure — русскоговорящее сообщество
Sergey Trofimov
Плюс comment блок с примерами кода для репла
аминь
источник

ИФ

Иван Федоров... in Clojure — русскоговорящее сообщество
Sergey Trofimov
Плюс comment блок с примерами кода для репла
и ассёрт на месте, для чистых фунок
источник

ST

Sergey Trofimov in Clojure — русскоговорящее сообщество
Иван Федоров
и ассёрт на месте, для чистых фунок
да, я свой assert написал 😊
источник

ИФ

Иван Федоров... in Clojure — русскоговорящее сообщество
Tim Plotnikov
И мы не говорим про тесты сейчас, потому что тесты это optional
для меня, тесты не более optional чем типы. Тест можно написать как хорошую доку
источник

TP

Tim Plotnikov in Clojure — русскоговорящее сообщество
Иван Федоров
для меня, тесты не более optional чем типы. Тест можно написать как хорошую доку
Под optional я имею ввиду, что нет ни одного компилятора, который бы заставил тебя писать тесты 😄
источник

TP

Tim Plotnikov in Clojure — русскоговорящее сообщество
Иван Федоров
Ну вот у кложи мне очень нравится сейчас подход. Я могу накидать хинтов для понимания, я могу добавить спеку для проверок и понимания, я пишу тесты на ключевые 10-20% кода которые ловят 80-90% ошибок.
Да, мне тоже нравится такое в кложе, мне нравится спека, которая парсить умеет сама в нужный облик, с удовольствием пишу на динамике и никаких проблем не испытываю)

Но, например, ФБ написали стат. анализаторы для пхп и js потому что на их скейле стало очень трудно без умной програмки, которая бы подсказала где ты ошибся. Я не хочу сказать что у всех скейл ФБ, но если ты хочешь в скейл, значит скорее всего ты столкнешься с похожими проблемами.

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

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Tim Plotnikov
Да, мне тоже нравится такое в кложе, мне нравится спека, которая парсить умеет сама в нужный облик, с удовольствием пишу на динамике и никаких проблем не испытываю)

Но, например, ФБ написали стат. анализаторы для пхп и js потому что на их скейле стало очень трудно без умной програмки, которая бы подсказала где ты ошибся. Я не хочу сказать что у всех скейл ФБ, но если ты хочешь в скейл, значит скорее всего ты столкнешься с похожими проблемами.

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

TP

Tim Plotnikov in Clojure — русскоговорящее сообщество
Anton Chikin
Ну а кто мешает писать статические анализаторы для любых языков?
Да никто)
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
По сути JetBrains на этом бизнес сделал
источник

ИФ

Иван Федоров... in Clojure — русскоговорящее сообщество
Tim Plotnikov
Да, мне тоже нравится такое в кложе, мне нравится спека, которая парсить умеет сама в нужный облик, с удовольствием пишу на динамике и никаких проблем не испытываю)

Но, например, ФБ написали стат. анализаторы для пхп и js потому что на их скейле стало очень трудно без умной програмки, которая бы подсказала где ты ошибся. Я не хочу сказать что у всех скейл ФБ, но если ты хочешь в скейл, значит скорее всего ты столкнешься с похожими проблемами.

Так что, мне кажется можно начать с поиска исследований, которые проверяли какие размеры кодовых баз актуальней всего)
Ну вот мы сгрузили проверку формы данных в компилятор. Но по какой цене? Мы теперь должны на каждое новое изменение формы лезть в тип. Или я не в курсе новых ЯП с non-restrictive types?
источник

TL

Timur Latypoff in Clojure — русскоговорящее сообщество
Tim Plotnikov
Да, мне тоже нравится такое в кложе, мне нравится спека, которая парсить умеет сама в нужный облик, с удовольствием пишу на динамике и никаких проблем не испытываю)

Но, например, ФБ написали стат. анализаторы для пхп и js потому что на их скейле стало очень трудно без умной програмки, которая бы подсказала где ты ошибся. Я не хочу сказать что у всех скейл ФБ, но если ты хочешь в скейл, значит скорее всего ты столкнешься с похожими проблемами.

Так что, мне кажется можно начать с поиска исследований, которые проверяли какие размеры кодовых баз актуальней всего)
Я так понимаю, основной плюс статической типизации (обычно) — это хороший intellisense в IDE. Чем язык более динамический, тем сложнее с этим :(
источник

TP

Tim Plotnikov in Clojure — русскоговорящее сообщество
Иван Федоров
Ну вот мы сгрузили проверку формы данных в компилятор. Но по какой цене? Мы теперь должны на каждое новое изменение формы лезть в тип. Или я не в курсе новых ЯП с non-restrictive types?
Так вроде в том и суть, разве нет?
С тестами же то же самое - хочешь что-то поменять, будь добр и тестики обновить
источник

AC

Anton Chikin in Clojure — русскоговорящее сообщество
Timur Latypoff
Я так понимаю, основной плюс статической типизации (обычно) — это хороший intellisense в IDE. Чем язык более динамический, тем сложнее с этим :(
Ну еще бы ты на входе в каждую функцию руками подписал хинт для автокомплита
источник

TL

Timur Latypoff in Clojure — русскоговорящее сообщество
А есть какой-то IDE/рекдактор для Кложи, который в рантайме подбирает intellisense? Не только по статическому анализу, но ещё и с текущего репла кушает состояние.
источник