Г
То есть у вас есть шанс добавить кастомную структуру/иерархию такого уровня строгости, что лично вам кажется адекватным для кода приложения.
Size: a a a
2021 April 05
Г
Java/Js interop, пожалуй, очень-очень полезен.
V
Да я бы не сказал, что отсутствие строгой типизации "так страшно, как ее молюют". Очень удобный синтакс. Вы можете так-то по-прежнему свои типы, интерфейсы, протоколы (deftype, definterface, defprotocol) писать, и это сильно упорядочивает код. Можно :pre или :post валидациями охватывать проект.
Спасибо! А код не становится очень громоздким от описания этих проверок? Или их принято в отдельные файлы выносить?
Г
Я пробовал Haskell, и даже восхищаюсь им. И сказал бы, что чисто по внешнему виду Reason задизайнен в таком же духе. Интересно и "рационально".
К сожалению API для некоторых реальных сервисов пилят не такие же умные и рациональные люди. Я, как уже сказал, столкнулся с проблемами на обработке многоуровневых вложенных json'ов, и перекладывания друг в друга, и т. д. Для этого lens придумали. Но это нереальный ментальный оверхед лично для меня.
К сожалению API для некоторых реальных сервисов пилят не такие же умные и рациональные люди. Я, как уже сказал, столкнулся с проблемами на обработке многоуровневых вложенных json'ов, и перекладывания друг в друга, и т. д. Для этого lens придумали. Но это нереальный ментальный оверхед лично для меня.
Г
Спасибо! А код не становится очень громоздким от описания этих проверок? Или их принято в отдельные файлы выносить?
Они так-то очень мало места и кода занимают. Если их правильно написать.
Можно только пре-валидацию давать, чтобы во флоу вашего приложения убедиться, что каждая функция "кушает" то, что вы от нее ожидаете. (А чем она "какает" не проверять, ага, я бы тоже не стал).
В чем конкретно ваше беспокойство выражается?
Можно только пре-валидацию давать, чтобы во флоу вашего приложения убедиться, что каждая функция "кушает" то, что вы от нее ожидаете. (А чем она "какает" не проверять, ага, я бы тоже не стал).
В чем конкретно ваше беспокойство выражается?
V
Они так-то очень мало места и кода занимают. Если их правильно написать.
Можно только пре-валидацию давать, чтобы во флоу вашего приложения убедиться, что каждая функция "кушает" то, что вы от нее ожидаете. (А чем она "какает" не проверять, ага, я бы тоже не стал).
В чем конкретно ваше беспокойство выражается?
Можно только пре-валидацию давать, чтобы во флоу вашего приложения убедиться, что каждая функция "кушает" то, что вы от нее ожидаете. (А чем она "какает" не проверять, ага, я бы тоже не стал).
В чем конкретно ваше беспокойство выражается?
Беспокойство в том что есть мнение что clojure не подходит для больших проектов. Вот я и хочу понять насколько обоснованно это мнение. Ведь любой маленький проект может разрастись до большого
Г
У @niquola была классная цитата в выступлени про количество строк кода в либах на clojure/cljs и аналогичных либах других языков.
V
При чем это мнение выражают даже в лекциях по clojure
Г
В каких именно?
V
В каких именно?
Например Рыжиков что-то такое говорил. Что оптимально 5 человек на проекте
V
И для больших проектов не очень
V
И по-моему что-то такое сказал в Иван Гришаев. У меня сейчас нет времени чтоб переслушивать его 2-часовое интервью "подлодке"
Г
Например Рыжиков что-то такое говорил. Что оптимально 5 человек на проекте
Ну постойте. Большой проект, не обязательно = на нем работает много людей.
Г
Всмысле обычно так, но его разбивают на команды так или иначе. Каждая из которых над своей часть работает. И в командах по 5 человек, вроде как стандартно держать
Г
Может вы просто не совсем поняли. Какова метрика величины проекта?
Г
В Фейсбуке же дохрена своих подпроектов, сервисов и т.д. он не полностью на пыхе написан.
V
Может быть и правда я неправильно понял
Г
5 человек это вроде стандарт: две пиццы, три тупицы
AC
Понятно что без типизации на начальных этапах писать проще и быстрее. Но типизация нужна обычно для облегчения работы с большой кодовой базой. Как в clojure решается вопрос с удобством работы с большой кодовой базой? За счёт тестов? Полного покрытия спеками?
Есть другие средства для облегчения работы с кодовой базой, такие как модульность, возможность писать более обобщенный код. Что касается покрытия тестами - типизация от него не избавляет. По разным данным ошибки связаные с типизацией это от 5 до 15 процентов общего числа ошибок. Типы не панацея и никаких исследований, подтверждающих обратное не существует.
AC
Спасибо! А код не становится очень громоздким от описания этих проверок? Или их принято в отдельные файлы выносить?
Ну прямо вот все проверять не нужно. В некоторых местах кложа сама типы выводит.