Про ёжика в тумане, зазнайство, языки программирования и вериги

[vit_r]

Почему Ява лучше Хаскеля

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

Ява - хреновый язык, многословный как пятнадцатилетняя школьница на первом свидании. Но именно эта многословность создаёт необходимую избыточность.

Промышленное программирование - это постоянное внесение в код ошибок, иллюзий и случайных ляпов. Основную сложность составляют задачи типа «Зачем это? Или я дурак и ничего не понимаю, или писал какой-то идиот, или написано не то, что имелось ввиду, или всё это делается совсем по-другому».

Избыточное кодирование позволяет справится с такими проблемами. Код на Яве можно разобрать, понять, почистить, изменить или переписать. В крайнем случае, поставить заплатки и обойти.

Выяснить, что имел ввиду автор кода на «лаконичном выразительном языке» нет никакой возможности.

Тем более, комментарии никто не пишет. А те, кто пишет, делать этого не умеют. Кстати, именно этому надо было бы учить студентов вместо хитростей кодирования давно известных алгоритмов и создания одноразовых программ в угоду преподавателям.

Код двадцатилетней давности приходится исправлять. Код, который мы пишем сейчас, кто-то будет править через двадцать лет. Если это не так, то кодирование идёт в мусорную корзину, может быть, проходя по пути к ней другие, незначительные и не важные в данном контексте, стадии.

Comments

[norguhtar.livejournal.com]

А как же аннотации и IoC? В Java сейчас это все активно применяют.

[kouzdra.livejournal.com]

Как раз в смысле сопровождаемости функциональные языки лучше - система типов жестко "держит" семантику - большая часть логических ошибок вываливается на уровне проверки типов.

Да и проще они - меньше надо догадываться "что имел в виду автор"

Просто жаба привычнее.

[raydac.livejournal.com]

гораздо большую роль в сегодняшнем говнософте играет не тот факт что его пишут на чем то схожем с брайнфаком потому что "вася решил полробовать", а потому что никто уже не проектирует софт, херовая архитектура превратит переписывание в ад даже если написано на самом многословном и типизированном языке, а проектировать сейчас это "для слабаков, для хлюпиков!" (С) эстонская реклама

[vit-r.livejournal.com]

В энтерпрайзе даже штатные аналитики есть.

[vit-r.livejournal.com]

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

[vit-r.livejournal.com]

Это про школьницу на свидании.

[raydac.livejournal.com]

бывает даже два )) но это не значит что они как то используются по назначению и тем более что то умеют

[metaclass.livejournal.com]

Подтверждаю.
Переписал сейчас 500 строк хранимых процедур SQL на 500 строк Clojure в целях избавления от логики в БД.

Непонятно чуть менее чем все. В принципе. Оригинал на SQL чуть более читабельный, но нихрена не поддерживаемый и неудобный в деплойменте и обновлении, новая версия на Clojure - к ней нужно каждую строку комментировать двумя-тремя строками текста, причем не в коде, а отдельным сочинением, чтобы хоть кто-то понял, что там.

[orleanz.livejournal.com]

" Как раз в смысле сопровождаемости функциональные языки лучше

Вит просто спутал Хаскелл с Перлом, где действительно все очень кратко и часто непонятно, особенно если много сложных регэкспов.

В Хаскелле же как раз и кратко, и понятно.

[metaclass.livejournal.com]

Clojure тоже функциональная, но типов там нет.
Код на ней без отдельного текстового описания размером раз в 5 больше чем код, понять невозможно :)

[orleanz.livejournal.com]

а можно пример одной такой непонятной строки на Кложе с сочинением? чтобы не быть голословным. Или это военная тайна? Чисто нейтрально спрашиваю, без подьебки, сам Кложу не знаю.

[metaclass.livejournal.com]

Да вот, одна функция:
https://gist.github.com/anonymous/a4111ae1f41e0bcea91c
Занимается тем, что сопоставляет расписанию общественного транспорта (список поездок с контрольными точками) реальное выполнение им этого расписания и полученные записи дополняет информацией из шапки расписания (информация о маршруте, транспортном средстве, итд)

исходный вариант хранимой процедуры, без шапки, только поездки
https://gist.github.com/anonymous/83eaa9e71eca09bdd508

[vit-r.livejournal.com]

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

Всегда можно выбрать правильный стиль, хорошо сочетающийся с комментариями. Правда, не факт, что в этом случае останутся "преимущества" функционального языка.

[vit-r.livejournal.com]

Не надо говорить "Вит спутал".

[metaclass.livejournal.com]

Работает это примерно таким образом:
grouped-time-points - это список вида "поездка, начало по времени, конец по времени". Загружается sql-запросом+постобработка и передается в эту функцию
report-trips-dict - словарь "id отчета"->"список поездок в отчете", тоже загружается из результата sql запроса и передается в эту функцию.
ci_date - дата отчета, берется из текущей обрабатываемой шапки расписания
{:keys [itrep_xmlobj_id ci_enddt ci_xmlobj_id] :as car-itin} - запись назначенения расписания транспортному средству - сразу в параметрах функции раскладывается на интересующие нас поля

Потом происходит следующее: для каждой поездки из расписания (map ... grouped-time-points) выполняется поиск выполнения этой поездки в report-trips-dict, полученные данные обрабатываются в нужный формат, с значениями по умолчанию, если поездки нет и сливаются в одну запись (merge car-itin ... report-trip)

потом в (filter ... ) полученный результат фильтруется от поездок, которых нет в расчете и которые не нужны.

[zealer.livejournal.com]

Как человеку далекому от транспорта, мне непонятны наименования.
Почему ci_date это дата отчета? ci - не похоже на отчет никак.
itrpt очень странно-непонятный префикс не нужный тут.
car_itin - можно догадаться, что car_itinerary через несколько минут с каким-то английским.

(when (#{0 2} itrpttrip_quality) {:itrpttrip_mark "v"} - 0 и 2 о чем это.
ci_xmlobj_id тоже не очень красиво. Зачем надо знать в формировании отчета о каком-то xml?

Если имена нужны для legacy генератора отчета - делается еще две функции преобразования
1 названия полей из базы в нормальные переменные
2 преобразовывает понятные названия в непонятные для отчета.
Ну или словарик со всеми названиями полей нужен под рукой начинающего разбираться в этом коде (надеюсь описания полей в базе вносятся всегда)


Да, во времена писания дотнетных опердений я знал все флаги в своих приложениях, но помню как-то ошибся и написал неправильный флаг. Полтора года не могли найти кто и где. Потом перешли к константам и понятней, и не перепутаешь.

[metaclass.livejournal.com]

Имена из sql-запросов, легаси.

Преобразование имен полей из БД в нормальные сломает все гораздо больше - вместо одного имени придется помнить два, причем на клиенте придется держать два варианта описания отчета - для старых и новых имен.

С префиксами имен полей все плохо, там таблицы с именами типа ItineraryReportTrips, если их не сокращать - оно в firebird с его лимитом в 27 символов на идентификатор может и не влезть.

[vit-r.livejournal.com]

Сокращения складываются исторически и становятся практически внутренним языком предприятия.

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

Ну facepalm же

[ext_1684112 (from livejournal.com)]

>оно в firebird с его лимитом в 27 символов на идентификатор

шел 2014 год...

[ext_1684112 (from livejournal.com)]

У меня ощущение, что на LINQ это было бы намного понятнее.

Про студентов

[theaspect.livejournal.com]

Пять лет студентов учат предоставлять два раза в год единственный правильный ответ на заранее оговоренный вопрос при этом не сотрудничая с соседом. Какие еще противоречия есть?

[zealer.livejournal.com]

С полями ладно, стало чуть понятней. ( хотя ужасное сокращение для time_points никуда не делось)

Но константы надо привести к понятному виду. Или написать функции однострочники - типа car-assigned

[zealer.livejournal.com]

и помня обсуждение про добавление названия таблицы
Ведь тогда никто не написал, что названия приходится сокращать.

[zealer.livejournal.com]

Знаю. Это просто еще от месяца для вникания в проект.

Я до сих пор помню ту таблицу на почти двести полей, где почти все полдя были до 15 символов. Про часть полей никто ничего сказать не мог. Переименование помогло. Но, если б не меняли тогда 90% программистов - уверен переименования не было б.

Re: Про студентов

[vit-r.livejournal.com]

Мы о практике. Есть разные формы обучения. К тому же студенты постоянно списывают друг у друга и из Интернета.