«В Минске не пишут на Clojure». Зачем Targetprocess выбрала для нового продукта редкий язык

106 комментариев
«В Минске не пишут на Clojure». Зачем Targetprocess выбрала для нового продукта редкий язык

Минская продуктовая компания Targetprocess занимается разработкой Fibery, новой платформы для управления работой. Бета-версия продукта, вероятно, появится весной. Исходя из требований, ядро платформы было решено создать на Clojure. О минусе этого решения сооснователь компании Михаил Дубаков недавно сообщил на своей странице в Facebook: «По какой-то мистической причине в Минске нет разработчиков, которые хотят программировать на Clojure».

Читать далее

Иллюстрация: n01se.net

«Мы не собираемся создавать огромную команду, нам нужна ещё пара человек для работы над ядром продукта. Были ожидания, что Clojure станет своеобразным фильтром при поиске людей в проект, потому что «среднему» разработчику нелегко освоить и его, и функциональное программирование на приличном уровне», — рассказывает Михаил Дубаков.

В действительности фильтр оказался слишком узким.

«Многие считают, что изучать Clojure не нужно, потому что таких вакансий просто нет. Лично мне кажется, что глубокое погружение в LISP-подобный язык отлично развивает кругозор и дает ещё одну парадигму, сквозь которую можно смотреть на возникающие перед программистом проблемы. Знание Clojure/LISP делает программиста более эффективным», — считает сооснователь Targetprocess.

Сегодня над Fibery работает команда из 4 человек, из них два бэкенд-разработчика, пишущих на Clojure. В компании продолжают поиск энтузиастов в Минске и за его пределами — однако не исключают, что придётся создавать удалённую команду.  

Участник команды Fibery, разработчик Aндрей Щёткин описал причины выбора в пользу Clojure.

Задача

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

Схема модели данных в Fibery

Гибкость модели данных достигается материализацией её описания в метамодель, с помощью которой осуществляется управление. В программе на статически типизированном языке материализация описания модели данных заключается в факторизации типа в объект, то есть тип сущности становится first-class object с возможностью его создания/изменения.

Статически типизированный язык начинает со статики (раннее связывание везде) и добавляет динамику по требованию (зоны позднего связывания через полиморфизм).

Динамически типизированный язык начинает с динамики (позднее связывание везде) и ею же и заканчивает. При этому «статику» добавить нельзя никак, так как отсутствует шаг проверки типов на этапе компиляции (допустим, что язык компилируется).

При разработке модели на статически типизированным (далее CТ) языке речь идёт о регионах позднего связывания. Везде, где метамодель получает обращение на чтение (например, при обработке запроса за данными) проверяется соответствие запроса схеме типов, то есть происходит разыменование строкового значения в объект — регион позднего связывания.

Имея в решении на СТ-языке сопоставимое количество мест позднего связывания не через механизмы языка (речь о виртуальных методах — проверяемое на type check time позднее связывание) и количество мест раннего связывания с плюсами type check, в Targetprocess решили не пытаться «загибать» решение в динамическом стиле на СТ-языке, а попробовать сделать его на целиком на ДТ-языке.

Другими словами, в компании исходили из того, что первична именно динамика. Обычно происходит наоборот, и в СТ-языках конструируется инфраструктура для бесшовного взаимодействия с динамическим окружающим миром (dynamic в .NET) или адаптации внешней динамики к статике (F# TypeProvider).

В пользу выбора ДТ-языка говорят сразу несколько факторов:

  • динамика как сквозное свойство целевой системы и, как следствие, закономерное свойство решения: работа с сущностями, типы которых известны на этапе выполнения;
  • низкая концептуальная размерность: решение имеет намеренно минимальное количество ответственностей — манипуляция с моделью (сущности, связи) и манипуляция данными, экземплярами типов из модели;
  • инкапуслированность динамики — функциональность «выставляется» наружу через два интерфейса: язык запросов вокруг схемы и язык команд (квази-GraphQL). Интерфейсы «торчат» наружу через API или как public interface для in-proc запросов. Решение о первичности динамики на клиента public interface не распространяется, поэтому клиент ядра может быть написан на СТ-языке, эволюционируя по своим принципам и правилам;
  • миниатюрный размер команды разработки: 2 человека.

Путь Clojure

В Targetprocess пошли характерным именно для Clojure минималистичным путём и решили выразить все понятия решения через функции и данные (рекурсивная композиция гетерогенных мап), организованные в модули.

Преимущества: Clojure обладает отличной поддержкой стандартных структур данных (в частности, команду интересовали мапы), функциями вокруг этих структур данных («из коробки» есть, например, расчёт разницы между двумя рекурсивно вложенными мапами) и keywords (first-class имена). В дополнение — functional, immutable, jvm-hosted (интероп в jvm-экосистему).

Из минусов языка в компании отмечают отметить довольно крутую кривую обучения ввиду непривычного поначалу синтаксиса (Clojure можно подавать как внятно спроектированный «javascript со скобками»).

В Clojure удобно начинать с функциональной декомпозиции вокруг мапов (гетерогенных) и при разрастании логики решения сворачивать их, например, в типы (записи, протоколы). С учётом отсутствия безумной логики (вариаций по множеству параметров), около 90 процентов решения составляет прямолинейное функциональное программирование вокруг мап.

Возникает вопрос — как с этим жить и различать без типов, что где в решении «летает»? Ответ — keywords как first-class names. Сквозь всё решение «летают» мапы, общение с которыми происходит или через явные селекторы (:type obj-link), или через интерфейс модуля (schema/get-type-name type). Конкретный выбор зависит от того, пересекает ли мап границу модуля (попадает ли в окружающий мир).

Пример запроса на СТ языке:

Пример эквивалентного запроса на Clojure:

В результате подавляющее количество понятий в решении выразили через данные (мапы). Именованные мапы «летают» сквозь всю систему, а операции вокруг мапов выражены функциями, собранными в модули. Отдельные операции реифицированы в команды, запускающиеся через механизм predicate-based диспетчеризации вызова функции (мультиметоды).

И что?

Динамический домен возможно реализовать на статически типизированном языке, подключая динамический стиль по необходимости, но в случае с Fibery с учётом специфики задачи, набора требований, размера команды, в Targetprocess решили писать на динамически типизированном языке. Причина — в желании однородной работы с понятиями в коде без умножения сущностей для снижения случайной сложности (в виде добавления динамики в СТ-язык). Плата за решение — отсутствие проверки типа на этапе компиляции.

В связи с отсутствием статических типов контракты любого элемента в решении описываются логикой (библиотеки prismatic scheme, clojure.spec) и отслеживаются только на этапе выполнения. Итоговое решение проектируется таким образом, чтобы внятно сообщить, что и где пошло не так. Имея на руках first-class контракты, их можно компоновать, транслировать в документацию, API spec (swagger) и выполнять другие операции.

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

В компании преследуют цель написания предельно меньшего количества адекватного кода, удовлетворяющего требованиям, минимальными силами. Показателен и пример Fibery: размер кодовой базы составляет около 6 тысяч строк кода без тестов, размер бэкенд-команды — всего 2 человека.

Справка dev.by

Язык программирования Clojure работает на Java Virtual Machine и, соответственно, имеет прямой доступ ко всем библиотекам и API Java. А будучи диалектом Lisp, Clojure впитывает и его возможности. Согласно опросу Clojure-разработчиков, опубликованному в феврале 2017 года, чаще вего язык используют при разработке корпоративного, финансового ПО и в ритейле. При этом второй по частоте упоминания проблемой языка разработчики называют именно недостаток проектов для его использования. Для большинства инженеров, работающих с Clojure, основным языком является Java (33,08%), за ней следуют Ruby (14,28%), Python (14,15%) и JavaScript (13,18%).

Хотите сообщить важную новость?

Пишите в наш Телеграм

Горячие события

GoWayFest 4.0 Online Edition Conference
11 июля — 12 июля

GoWayFest 4.0 Online Edition Conference

Минск

Читайте также

Где в 2020 году выучить Python с нуля? Топ онлайн-курсов и школ
Где в 2020 году выучить Python с нуля? Топ онлайн-курсов и школ

Где в 2020 году выучить Python с нуля? Топ онлайн-курсов и школ

Python входит в топ самых популярных языков программирования. Он прост и элегантен. Собрали хорошие курсы, которые подходят и для тех, кто любит самостоятельность, и для тех, кому удобнее работать с преподавателем. Почти все курсы рассчитаны на начинающих и после каждого можно получить подтверждающий прохождение сертификат.
1 комментарий
Лучшие онлайн-курсы, чтобы прокачать язык Python
Лучшие онлайн-курсы, чтобы прокачать язык Python

Лучшие онлайн-курсы, чтобы прокачать язык Python

Python — один из самых популярных высокоуровневых языков программирования общего назначения. За счёт достаточно простого синтаксиса, гибкости и масштабируемости, а также активного глобального сообщества пользуется огромным интересом у начинающих кодеров. Богатый набор инструментов и библиотек покрывает широкий круг самых разнообразных задач от веб-разработки и анализа данных до AI и научных вычислений. Это делает Python одним из самых востребованных языков среди работодателей, его применяют практически все ведущие ИТ-компании мира. TechRadar собрал 5 лучших курсов по Python с пяти образовательных онлайн-площадок.
Топ-9 языков программирования, которые помогут зарабатывать до $150 тысяч в год
Топ-9 языков программирования, которые помогут зарабатывать до $150 тысяч в год

Топ-9 языков программирования, которые помогут зарабатывать до $150 тысяч в год

Facebook разработала AI-транскомпилятор TransCoder
Facebook разработала AI-транскомпилятор TransCoder

Facebook разработала AI-транскомпилятор TransCoder

Обсуждение

2

Про кривую обучения сказано слишком сильно, в сути неприязнь к чему то новому - списковому синтаксису, но Clojure в отличии от LISP использует специальный синтаксис для ассоциативных массивов и векторов, который участвует в построении управляющих конструкций.
ИМХО Clojure позволят писать код в разы проще чем другие языки, имеет минималистичный синтаксис и развитую стандартную библиотеку. Не описали REPL-development, а это очень сильная возможность.
В итоге получается код без всякого лишнего обвеса и ООП булшита.

-4

прям как rust?

Александр Фомин
Александр Фомин Developer в Track-POD
6

Я все равно не понял, почему именно clojure, а не другой мэйнстрим динамический язык - js, python, ruby. Да и кроме динамики в модели данных - где еще динамика? Любое приложение на 50% состоит из инфраструктурного кода. Зачем мне динамика в описании внутреннего API для обращения к базе данных или авторизации пользователя?

3

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

-3

легко проверяемый код? это в репле что ли?
аннотировать код для проверки типов на этапе компилации - а чем оно лучше явы или скалы?

кстати в своём порыве к динамизму CTO напортачил - я считаю надо брать и графовый сторидж а не старые добрые типизированные sql субд.

тут обычный рест апп + немножко бэкенд процессов, зачем себе как бизнесу жизнь усложнять?
в таких проектах первичны
- миграции схем и данных
- миграции долгоиграющих бизнес процессов
- поддержка версионирования фронтенда для разных версий клиентов
на данный момент все эти темы CI&CD максимально раскрыты в банальном спринге, на рынке полно спринх кодеров - бери и фантазируй сценарии на уровне бизнеса, зачем себе жизнь усложнять?

ладно в клоуже для финансистов интересный stm есть - но тут он зачем - целостность данных всё равно бд обеспечивать будет

1

> легко проверяемый код? это в репле что ли?
Да, репл вам дает очень многое для того что бы быстро написать и проверить ваш код, но не решает все вопросы. По видимому вы думаете что этот процесс заключается в копировании кода в командную строку запущенного repl? Ну я вам посоветую ещё почитать что это означает в clojure.)
> на данный момент все эти темы CI&CD максимально раскрыты в банальном спринге
Только про Java и Spring не нужно пожалуйста, я на Java не один год программировал и знаю все прекрасно и о множестве готовых специалистов под Java+Spring которые не первое и особенно второе толком и не знают и о многотысячной документации к этому Spring вы похоже забыли. А ещё через Spring решается 100500 банальных задача только после чтения километрового мануала и написания тонны кода для инициализации. По этому не нужно.)
> ладно в клоуже для финансистов интересный stm есть
stm и в Java есть, на которой stm Clojure и основан, когда вы начинаете говорить конкретные вещи вскрывается ваше полное непонимание происходящего.

3

Очерчу ситуацию, а фактически продублирую выжимку из статьи на медиум (ссылка в статье на дев бай)
Декомпозиция системы оформлена в виде ядра и всего остального (неважно в данном контексте).
Ядро обладает намеренно минимальным количеством ответственностей.
Ядро потребляется внешними клиентами через API, инкапсулируя в себе выбора языка, технологии общения с базой и т.д.
Команда ядра бэкэнд сейчас 2 человека. Стратегически рост комадны ядра больше 4 человек исключается ввиду ограничения функциональности, за которую ответственно ядро.
Таким образом, организационне масштабирование в случае необходимости ядро не затрагивает.

"тут обычный рест апп + немножко бэкенд процессов, зачем себе как бизнесу жизнь усложнять?"
Всё именно так, только "rest api", домен формируются в динамике. Это одно из отличий, которые мы взяли за опорное и для его реализации выбрали Clojure с целью упростить себе жизнь.

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

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

-2

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

про графы - я имел ввиду только oltp сценарии, olap на графе это слишком смело даже для жирных рынков лондона и долины

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

Anonymous
Anonymous
0

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

7

Вот это мне говорит лишь о том что вы не очень понимаете о чем говорите. Любой, повторю любой сложный и долгосрочный проект будет иметь очень большие проблемы если уйдут его ключевые разработчики. А переобучить на Clojure по сравнению с затратами на вход в новичка в сложный и долгосрочный проект это не так сложно. Потому что важно знать и понимать бизнес логику а синтаксис языка, который я лично смог освоить за месяц и практически полностью с нуля у Clojure, включая стандартную библиотеку. Но я отлично знал Java конечно.
И мой аргумент не в пользу Clojure а о том что ваш аргумент, точнее проблема которую вы описываете - это очень надуманно.
Хотя соглашусь что не все будут желать переобучаться на Clojure. Но я почитал вакансию и там написано что они готовы брать людей и без опыта, думаю людей они найдут им нужно не 100 человек. Найти 4 токовых можно и переобучить чуть что тоже.
А ваш скепсис только от не знания. Если попробовать изучить какой то принципиально новый язык, удивитесь как ваш кругозор изменится, может тогда и Clojure покажется не говном а чем то очень хорошим.

3

"это гомоиконность, функциональное программирование, отличные примитивы конкурентного программирования" абсолютно верно, в статье я не очерчивал намеренно.
В статье есть ссылка на мой пост, где упоминается исторический контекст появления поста в принципе.
Пост появился как комментарий на фейсбуке, где рассматривался именно выбор Clojure с точки зрения динамики/статики, я намеренно не намешивал всего остального.
Отсюда ОЧЕНЬ сильный крен статьи в статику и динамику.

"ИМХО Clojure позволят писать код в разы проще чем другие языки, имеет минималистичный синтаксис и развитую стандартную библиотеку. Не описали REPL-development, а это очень сильная возможность.
В итоге получается код без всякого лишнего обвеса и ООП булшита."

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

Очень согласен. Но тут аргументы вида "функциональное программирование" и "примитивы конкурентного программирования" сложно подать объективно, не получив контраргументов "вы не умеет тру ооп" и "вы не умеете тру конкурентное программирование"

3

> Очень согласен. Но тут аргументы вида "функциональное программирование" и "примитивы конкурентного программирования" сложно подать объективно, не получив контраргументов "вы не умеет тру ооп" и "вы не умеете тру конкурентное программирование"
Это все будет от балаболов которые толком то и не знают не об ооп и конкурентный код не писали, с ними все равно бестолку говорить. Это же сразу понятно когда человек разбирается, может задать конкретный вопрос и описать конкретную проблему. Когда нет будет ходить вокруг да около и повторять одни и те же общие фразы, не может же он специалист с 5+ лет упасть в грязь, сказав что слабенький и проекты у него были все время банальное УГ, хотя предположу что многие просто этого и не понимают о себе.)

1

"Я все равно не понял, почему именно clojure, а не другой мэйнстрим динамический язык - js, python, ruby"
Достаточно сложно обосновать объективно и однозначно выбор языка, мои аргументы - jvm экосистема с возможностью фолбэка в Scala.
"Да и кроме динамики в модели данных - где еще динамика?"
В перспективе в поведении, правила вот вот всё. Динамики для данных было достаточно.
"Любое приложение на 50% состоит из инфраструктурного кода. Зачем мне динамика в описании внутреннего API для обращения к базе данных или авторизации пользователя?" Абсолютно согласен, что не нужно в авторизации пользователя. С базой ты имеешь ввиду API самой базы данных? там динамика из коробки - формирование sql + отображение результата в тип. Насчёт 50 процентов кода не соглашусь, очень зависит от проекта, в TP 50% инфраструктурного кода? Complexity сосредоточена в регионах slice, причём случайная на мой взгляд.

2

Причем тут Scala?) Вы хотя бы немного на нем программировали сами? Это жуткий гемор, и гибкостью в нем не пахнет чего сильно хотят изначально от системы)

0

Scala - здесь адресная отсылка к автору комментария, на который я отвечал. С автором комментария я знаком лично и Scala вокруг него вращалась, так что вы заметили и атаковали пасхальное яйцо :)

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

1

Просто не нужно приводить как аргумент то что к делу не относится. Я на Scala работал больше года, пока не перешёл на Clojure и по этому не уместные аналогии меня смущают. Потому что для меня стал понятен гемор который вызывает Scala достаточно быстро.)
Теоретически можно писать на чем угодно, проблема в практической не эффективности.)

6

среднестатистический программист значит видит обычную по деньгам вакансию с необычным требованием КЛОУЖА.
ну и ради чего ему тратить время на изучение условно "ещё одного руби" ?
хотите фильтровать людей - создайте себе поток предложив ценник в 1.5-2 раза выше среднего по рынку.

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

Anonymous
Anonymous
2

А ведь правильно говорят, СV driven development. Когда люди отценивают знания исключительно из утилитарности, смогут ли они продать строчку в резюме или нет. Неудивительно что никто не хочет во что-то углубляться: в концепции, в парадигмы, в суть, в computer science. Исключительно потому что в РБ это не продать и выхлоп на их взгляд бесполезный.

1

так же плохо когда чел выбирает технологию уместную в проектах уровня Metadata Governance или Rule Engine в проекте для средненького rest сервиса.
кстати если взглянуть глубже на проблему, то корни её возможно в том что на рынке умных энтузиастов больше чем проектов в которых этот энтузиазм уместен.

Александр Фомин
Александр Фомин Developer в Track-POD
5

Ребята из MIT перестали преподавать SICP и начали учить питону. Почему? "Sussman pointed out that engineers now routinely write code for complicated hardware that they don’t fully understand (and often can’t understand because of trade secrecy.) The same is true at the software level, since programming environments consist of gigantic libraries with enormous functionality. According to Sussman, his students spend most of their time reading manuals for these libraries to figure out how to stitch them together to get a job done. He said that programming today is “More like science. You grab this piece of library and you poke at it. You write programs that poke it and see what it does. And you say, ‘Can I tweak it to do the thing I want?'”. The “analysis-by-synthesis” view of SICP — where you build a larger system out of smaller, simple parts — became irrelevant. Nowadays, we do programming by poking." http://www.posteriorscience.net/?p=206 Sad, but true.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
2

Это все отчасти верно, но мне не кажется, что подход SICP пора хоронить. Во-первых, кто-то же должен писать библиотеки. Во-вторых, не все задачи хорошо решаются набором библиотек. Они "как-то" решаются, но чтобы понимать эти решения нужно понимать принципы и основы. Poke-driven development и SICP-driven development — это как две вселенные, люди из которых плохо понимают друг друга (что видно из комментариев выше).

Александр Фомин
Александр Фомин Developer в Track-POD
0

Это просто ответ на вопрос, почему ж в Минске так мало Кложа программистов.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
0

А тебе как Clojure, кстати? и SICP?

Александр Фомин
Александр Фомин Developer в Track-POD
0

Когда я последний раз смотрел кложу - не понравилось. Моя любимая метафора - это автоматическая коробка передач. Я не хочу быть частью двигателя, переключая передачи руками, я просто хочу ехать. Так же я не хочу руками собирать AST или чекать типы в рантайме - компилятор это сделает в разы лучше меня. SICP отложен в долгий ящик, перед ним Ansible, AWS, EF, DataScience и более насущные книги.

1

я не уловил метафору.
Если я правильно понял:
- претензия к синтаксису ("не хочу руками собирать AST")
- претензия к динамической типизации ("компилятор это сделает в разы лучше меня")
так?

0

Аргумент про "чекать типы" настолько наивный. Что говорит мне как минимум что вы не писали в проде динамический код как минимум никогда.

Александр Фомин
Александр Фомин Developer в Track-POD
5

В разрезе этой конкретной метафоры - да.

-1

SICP и питон, это разные категории что бы их сравнивать, вам не кажется?)
Это как перестали преподавать Алгебру и начали Mathcad.
p.s. Мне ваш уровень понимания в профессий уже понятен)

Александр Фомин
Александр Фомин Developer в Track-POD
3

Это не я сравниваю, а авторы SICP, на минуточку. Почитайте ссылку.

1

А кто цитирует?
То что в стате пишется о том что сейчас все используют готовые библиотеки и упор делается на их компиляцию, не значит что не нужно думать системно и быть образованным. Если вы знаете много парадигм, понимаете суть фундаментальных структур данных и алгоритмов у вас получится код значительно проще и надежнее. Когда я работал в начале карьеры на галимых проектах, где суть была если подумать, получить запрос и сохранить его в БД или сформировать ответ на основе выборки из БД, а самые сложные вопросы были как прикрутить следующую функцию фреймворка, мне ни какие фундаментальные знания не были нужны. Но сейчас когда я сам принимаю решения по архитектуре, планирую самые сложные участки бизнес логики и принимаю другие решения мне это очень важно. Да, и ещё я стал понимать насколько низкоквалифицированными и даже бездарными было большинство тех в чьем подчинении я работал и теперь мне понятно почему проекты были такими кривыми. Если выразить через метафору - они не читали SICP, и по этому не могли сделать хорошего выбора или придумать хорошей идеи.

0

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

1

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

-1

Хм, обычно то, что в MIT отказались от SICP, приводят как аргумент в пользу того, что Lisp не нужен. Но по-моему этот комментарий ещё больше мотивирует учить Lisp.

0

Человеческий фактор присутствует абсолютно во всех сферах жизни и бизнеса. Нужно просто привыкнуть к этому и исходить из этого

0

брэйнфаков, последний раз прогал... Ну если вы видите выбор Clojure именно так - ваш уровень ушел так же недалеко, я даже уверен в этом.)
99% кто мыслит такими категориями - зарплата, зачем что-то новое изучать, критикую все к чему не привык даже не разобравшись, имеют одну общую проблему - порождение ужасного плохо работающего и с трудом поддерживаемого кода проекта, знакомо?)
p.s. А зарплату по видимому предлагаю хорошую, вы даже не соизволили поискать вакансию.)

8

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

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

-5

Только Германия в используя свою развитую науку потеряла в войне против всего мира ~7 мил. а СССР используя топорный метод в фактически войне только против германии ~45 мил. Если уж вам хочется на аналогиях.

-1

1) откуда 45 млн? обычно речь идет про 20-25
2) сравниваются с одной стороны убитые солдаты вермахта, а с другой все включая сожженных в печах конслагерей некомбатантов? 20 млн обычно как общие потери пишут.

-2

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

Игорь Трафимович
Игорь Трафимович Всё сложно в Fibery
1

Еще несколько сообщений, и в этом треде мог сработать Закон Годвина

1

Это писалось, касаемо фразы - "спецназ даже блицкриг не всегда осилит." Что очевидно если читать последовательно и внимательно.
Имелось в виду что есть более качественный и продуманные решения, хотя и не для масс. Но Clojure по моему простой, просто религия некоторым не позволяет, у точно проще Java и намного.

-2

Подумал ещё над вашим вопросом. А чего вы желаете - получить ответы прямо под вашим комментарием? Все ответы давно уже есть но для получения этих ответов нужно самостоятельно изучать вопросы. Зайдите на Clojure.org, начните читать, сделайте пару проектов что бы понять что к чему, решите пару задач которые у вас в работе вызывали проблемы или не вызывали и сравните. Если вам нужен какой то очень простой и быстрый ответ, то на такие вопросы его нет. Лично у меня опыт именно коммерческой разработки на Java/Scala/Clojure и я могу сравнить и увидеть сильные и слабые стороны, а у вас? Что-то сомневаюсь.)

2

Простите, но то, что вы пишете, противоречиво по сути, призывая разобраться и навешивая ярлыки и озвучивая свое мнение о том, чего не знаете, не разобравшись. Это все вызывает резкое неприятие, быть может и верных, ваших утверждений. Я думаю, я не одинок в своем мнении, поэтому и решил написать это. Если вопрос не подлежит обсуждению(сужу по вашему категоричному, как мне показалось, мнению), зачем убеждать в этом других?

3

Но как читателям что-то можно объяснить, если у них нет желания слушать?) Пиши не пиши, все попусту. Я же не могу человеку объяснить в комментах во всей красе и деталях что такое FP или другие важные концепции, для этого уже написано очень много статей и книг. Умный человек прочитает и задаст конкретный вопрос, а не что-то вида "как на ТАКОМ языке вообще писать можно, я не верю?" либо просто пойдет изучат тему т.к. поймет что он чего-то не знает.
А про ответ на вопросы от любителей, я лично их даю, но в ответ получаю шквал возмущений и новый пространные вопросы.
Ещё раз.) Вам сказали есть концепция/технология, она работает хорошо и решает массу вопросов вас уже навели на след - просто нужно дальше самому хотя бы что-то изучить.)
Можете задать мне любой Конкретный вопрос по Clojure, FP, Concurrency в Clojure - я отвечу.)

4

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

Без контекста неясно почему проект был написан на Haskell.
Неясно, почему бизнес решил пойти на rewrite на Ruby, имея работающее решение на Haskell. Чтобы проще найти разработчиков?
Неизвестно как было принято решение о rewrite, ведь может дешевле найти разработчиков и обучить Haskell, затем разобраться и развивать существующее решение, чем переписывать на Ruby и получить неопределенный результат.

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

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

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

Михаил Дубаков
Михаил Дубаков Writer в Fibery
-2

А какое среднее на рынке Clojure разработчиков?

0

на нашем рынке из 10ти человек которые способны сделать деливери в ДЦ и кучи сочуствующих латентных читателей мануалов и хелло ворлда?
на рынке лондона (участвовал в прототипах) видел клоужеров новичков за 5к фунтов в месяц и типа профи за 20к в месяц. эти 20к было кстати больше за CV чем за реальные заслуги в конкретном проекте.

2

Мне нравится Lisp, но я ботан-теоретик без опыта программирования на нём.

4

Wistful - один из разработчиков этой системы? Так брыжжет слюной на "не сторонников" языка что пришлось на всякий случай монитор протереть )

1

Не работаю у них.
p.s.
Брызжет слюной - это конечно аргумент по сильнее моих да и конечно не такой брызжущий.)

Михаил Дубаков
Михаил Дубаков Writer в Fibery
3

Нет, он мне не знаком. Но видимо это закаленный в боях ворчливый ветеран, которого достало все в мире java/spring/oop/orm и иже с ними.

-3

Не хочу даже писать какая это глупость и что тут можно даже обсуждать.

0

Что-то есть в ваших словах. Что-то есть.

0

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

Михаил Дубаков
Михаил Дубаков Writer в Fibery
4

За идею? За $3000-5000 в месяц

-1

1 умник сказал пару умных словечек на митинге по поводу выбора языка, другие (чуть менее умные), "да да, гомогенность, динамика, будет огонь!", а теперь компания ищет людей за 5к.

Anonymous
Anonymous
4

Там и другим чувакам не стеняются платить не только кложуристам. Да это ж обычные деньги для нашего рынка.

http://crew.targetprocess.by/.
Lead Developer $3,500 – $5,000
JavaScript Developer $2,500 – $4,000
.NET Developer от $2,500

А почему бы не заплатить, радовать хороших разработчиков, это ж здорово?

-1

Михаил Дубаков, вы про з/п не говорили ведь, но вроде теперь видно что это выше медианы, и тогда возможно make sense

1

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

"изучать технологию, чуть меньше чем полностью невостребованную на местном рынке, тратить на это своё время и т.д"
Тут можно посмотреть с двух сторон:
- инвестиция в изучение базовых принципов проектирования программ на immutable ФП; идей, принципов, лежащих в основе Clojure как языка программирования. Вооружиться ещё одной точкой зрения, так сказать. Clojure очень грубо не сложнее js как язык
- инвестиция в знания конкретных технологий - Hibernate, например, то есть экспертиза в знании мощностей, ограничений, болячек

Обе инвестиции имеют смысл. Тут уже разработчик выбирает, куда он вкладывает и что продаёт.
В первом случае, инвестиция абстрактная в знания/подходы/viewpoints, во втором - конкретная, знаю Hibernate и умею его готовить.

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

Anonymous
Anonymous
2

Хоть я и люблю Лисп (Scheme мой любимый "сферический язык в вакууме"), но делать коммерческие проекты на нем не стал бы (особенно для своего бизнеса).
1. Людей не найти.
2. Язык настолько гибкий, что аж жидкий - надо сильный техлид и/или дисциплинированная команда, который будет давать по шапке желающим самовыражаться через метапрограммирование и пр.
3. Если не повезет из-за п. 1 придется терпеть неадекватов.
4. Не так много преимуществ по сравнению с mainstream языками, особенно в контексте данного проекта.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
-1

Rich Hickey и некоторые другие с вами не согласны https://clojure.org/community/companies

Anonymous
Anonymous
1

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

Михаил Дубаков
Михаил Дубаков Writer в Fibery
2

Ну ок. Посмотрим что у нас получится.

Anonymous
Anonymous
2

Желаю удачи!

-1

1. Людей не найти.
Хороших специалистов в Минске очень сложно найти, много тех кто думает что они хорошие. На Clojure можно переучить любого Java'ста за месяц.
2. Язык настолько гибкий, что аж жидкий.
Не придумывайте, видимо не писали. У Java тоже есть reflection и что все его используют? 90% Clojure однозначна и бронебойная к ошибкам.
3. Если не повезет из-за п. 1 придется терпеть неадекватов.
Ещё раз вы вообще знаете сколько собеседований проходит в хороших компаниях и из них принимают на работу единицы? Соглашусь только с тем что с Clojure сложней.
4. Не так много преимуществ по сравнению с mainstream языками, особенно в контексте данного проекта.
Не понял как вы оценили контекст проекта, но про не преимуществ по сравнению с mainstream языками это лишь говорит что вы не сравнивали, для меня.)

4

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

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

0

Да, вот прямо в точку. Интересно было бы взглянуть на github молодого человека :)

0

В Java все используют reflection. Просто не знают об этом :)

-2

Delphi навсегда!

3

"Управление работой"? Тот же Таргетпроцесс только вид сбоку?

"Что бы мы не делали, у нас получается КПСС"(с)

Михаил Дубаков
Михаил Дубаков Writer в Fibery
1

Ну что поделать, мы учимся на своих ошибках
FogBugz -> Trello.
Hansoft -> Favro.

-1

Когда работает - хорошая. Согласен. :)

Михаил Дубаков
Михаил Дубаков Writer в Fibery
3

внезапно в тему
http://www.lispcast.com/clojure-and-types

2

Тот товарищ что протолкнул клоуж - приковал себя навечно золотой цепью к батарее в офисе таргетпроцеса

amok
amok Team Lead в Ergalio
5

Нда, targetprocess - гик компания. Технологии важнее продаж. Девелоперам хорошо и Михаилу интересно, пока оно само продаётся. Но с такими подходами atlassian не достать...

0

Почему же важнее? Как одно другому мешает? Покупателям всё равно на чём написано, а для ядра армия программеров не нужна, нужно несколько но толковых.
Тот же jet.com выбрал F# (нишевый в общем-то язык) в первую очередь чтобы привлечь талантливых программистов, и не прогадал.

1

Одно из важных практических преимуществ Clojure это ориентированность на данные. В языке отсутствуют классы а все данные представлены структурами данных, по этому нет необходимости в использовании ORM и трансформаций из JSON в объекты и т.п..
Реляционные таблицы в сути представляют собой списки кортежей и нативно представлены в языке. Пример:
Данные из таблицы User с полями: id | name | age, при получении из БД будут выглядеть в Clojure так:

( { :id 1 :name "Austin" :age 34 } { :id 2 :name "Tamara" :age 29 })

Здесь первый символ ключ второй значение ':id 1'

Теперь что бы получить первого пользователя нужно применить к коллекции функцию first а для получения его имени можно использовать специальный синтаксис под названием keyword:

(:name (first { :id 1 :name "Austin" :age 34 } { :id 2 :name "Tamara" :age 29 })))

И это очень сильно упрощает код, точнее работу с данными. При чем ассоциативные массивы(Map) которые выражены через {} можно формировать динамически добавлять и удаляя любые данные по ключу. Если вы хотите четко определить набор полей то в Clojure есть специальные возможности и для этого - defprotocol и defrecord.
JSON так же напрямую отображается в структуры Clojure т.к. является по своей сути структурами вложенными в другие структуры а именно списков и ассоциативных массивов. По этому выше приведённый пример можно напрямую перевести в JSON изменится только синтаксис, незначительно. Эта особенность полезна в работаете с не реляционными БД, многие их которых хранят данные в формате JSON.
Для работы с данными представленными списками и ассоциативными массивами Clojure обладает богатой и удобной в использовании библиотекой.
По этому вы сразу же избавляете свой код от обвесов которые делает всячески трансформации DTO -> ... -> Entity и обратно.

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

И ещё многое другое, что значительно упрощает разработку.

0

Вот это да - работать с таблицами как с мапами, побежал кейс классы стирать

Есть такая проблема в CD, называется колонку добавить в таблицу и промигрировать сервис с минимальным даунтаймом

Расскажите как вам в этом клоужа поможет своими внутренними механизмами

0

Интересно чем Case Class принципиально отличается от ассоциативного массива, кроме проверки в процессе компиляции? Если вам нужно ограничить поля которые могут быть в структуре можно - deftype и defrecord. Есть у вас такой код User(fName: String, fName: String) -> User("Валисий, "Denik") или User("Denik", "Валисий") кто/что поможет вам избежать проблем?)
Хотя Case Class это одно из того что мне нравилось в Scala после Java.
В общем тут вопрос только в динамической типизации которая не проверяет если вы что-то изменили нужно поменять и там где оно используется, я согласен что проверка компилятором это хорош но не критично. В Clojure код не упадет если вы добавили колонку и не используете её. Главное в местах где пишите и читаете эти данные сделать соответствующие изменения. Сейчас можно использовать так же clojure.spec для проверки корректности кода и много других утилит. Но поскольку код легко тестируется покрываемость намного выше и как оказывается проблемы такого рода редкие. И ещё я могу в REPL прямо из исходного кода функцию запустить и проверить её работу, и мне не нужно даже писать тест и ничего компилировать. Проблема вашего тезиса в том что о очень надуман, потому что на практике проблемы такого рода легко детектируются.
А вот проблемы гемороя когда у тебя 100500 типов и изменение в одном месте требует переписать все вашу вымученную модель построенную на типах - это вам не обойти. Вам должно быть знакома проблема когда вы что-то рефакторите из-за жесткой связанности приходится переписать очень много дополнительного кода. Это все в противовес маленькой выкристаллизованной программы, пусть и без проверки компилятором типов, но легко осязаемой и укладываемой в голове.
И заметьте с "мапой" как вы говорите не нужно ни каких подмешиваний трэйтов и прочего гемора что бы сделать код значительно гибче - добавил новое значение и уже можно передавать в другую сущность, если нужно.

0

И то что я описал про Case Class не надуманно. Была реальная проблема.
User(userId: String, userIp: String, ...) согласитель похожие названия, отличие только в 1-й букве, ошибиться легко.
Случайно поменяли местами, упало на записи в БД в проде или тесте, и только потому что одно из полей в БД было ограничено меньшим кол-вом символов.
А кейс в виде интеграционного теста не проводился потому что куча моков и др. зависимостей. Но вот в Clojure код получается очень слабо связанным и почти все функции я могу протестировать изолированно и без моков и проблем соответственно и еще что важно быстро, даже если функции пишут что-то в БД , потому что нет объектов с состоянием внутри, все данные необходимые для работы функция принимает на вход.

0

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

Это краткий сценарий из жизни реальных проектов

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

Успешный ит оринтированный бизнес без CD наверное уже не бывает. Для бизнеса важно иметь команду легко заменяем людей умеющих делать CD и вести зоопарк метаданных.
Даже если клоужа или скала или хаскель даст выигрыш в линиях кода но на рынке 95% кодеров умеет тока спринг - выбор очевиден.

Я как бы не против фп - пишу на Яве тока легковестные клиентские либы не создающий жархела, наверно даже попробую скоро клоужу ради структурного мачинга. Но бля - когда в стране не набирается команда из 4ёх человек за квартал - мот ну его нах?

Anonymous
Anonymous
4

А может ну его, эти простые пути и дешевых кодеров. Иногда хочется и поинтереснее и даже в чем-то логичнее и проще? Вот почему существуют такие тусовки как fby.by. И почему-то не все люди выбирают простые пути, а еще экспериментируют, хотят чего-то другого, чем унылое масивное гуано из патернов и так называемого "ООП"? В конце концов чего мы хотим от жизни? И очень будет грустно если мы живем, исключительно, чтоб бизнес приносил больше денег. Зачем мы вообще влезли в software engineering? Плыть по течению, это может и ок, но не для всех. Да и вы постоянно вспоминаете в коментариях дешевых кодеров и легко заменяемых людей, как-будто это что-то хорошее. Для бизнеса, который строится исключительно из-за денег - да. Но ведь всё еще есть и люди, которые любят то, что они делают. Неужели вам не интересно окружать себя интересными людьми, делать окружающее вас комьюнити хоть как-то лучше?

0

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

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

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

0

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

0

> такая ситуация на рынке с кодерами - следствие проектов в стране. вот если б тут хотя бы ...
Та самая ситуация когда начали писать свой продукт или мне кажется? А до 500 должно быть 1,2,..20,.. и т.д., не согласны?
> большого числа микрографов с полным журналом их изменений.
Судя по описанию это звучит как Graph DB + Audit. Но если использовать RDBMS то конечно есть где развернуться, ведь RDBMS это проверенная технология и вообще что кто кроме неё?) Как с ООП почти. Сарказм.)

0

Да, только микрографов в хранилище может быть под триллион

0

Если это микрографы, значит они замкнуты внутри себя, значит вы можете сделать секционирование (partitioning) без проблема. Neo4J что-то подобное поддерживает из коробки. Либо самостоятельно по некоторому признаку можно разделять. Любые проблемы с производительностью решаются. И вы получаете не только возможность хранения если это RDBMS и связи через ключи, но и готовый удобный язык запросов а не самописный.

0

Нео4ж не потянет, да и гремлин мощнее сайфера. Ну и в этих графах не столько нодов будет чтоб траверсал большой запускать

0

Я с вами не соглашусь про успешность применения тех или иных технологий, когда то Java вызывала отторжения, до этого С++ и т.д. Но была эволюция. Сначала писали консольные утилиты и было мало ресурсов, выбор бы в пользу СИ и императивного программирования. И только потому что LISP был очень медленным на компьютерах в то время, но он уже существовал и в нем на минуточку была сборка мусора как пример, а к этому в те времена относились как вы сейчас к Clojure.
Потом мощности увеличились и начали писать оконные интерфейсы, оказалось что ООП очень хорошо подходит для их описания, а императивный стиль не ушел так просто, т.к. все к нему привыкли, хотя нужно признаться аргумент производительности ещё имел место. Сегодня когда мы пишем много кода и он ну ни как не ложится на ООП парадигму так же хорошо как "окошки", а сервера стали невероятно мощными, на первый план как не удивительно выходит производительность программиста. Которая очень хорошо раскрывается концепциями заложенными в Clojure.
Пройдет время и все забудут об ООП и повальной императивщине, их вытеснят парадигмы помогающие писать больше сложного кода, в более короткий срок и вы свидетель этого процесса. Думал ли кто-то раньше что Clojure, Ruby, Scala, NodeJs займут такую нишу и даже Java пытается следовать этому тренду?

0

Ещё раз, я к фп и в частности к клоуже отношусь положительно. Я только топлю про риски с точки зрения бизнеса. И ладно бы это был проект где без клоужи будет гораздо труднее жить, но довольно обычный рест сервис.

Расскажите лучше про то как способна клоужа помочь для продукта контроля data lineage.
- есть даталэйк и куча входных датасорсов
- у датасорсов есть эволюция схем и в хранилище накапливаются данные из одного сорса но с разными схемами
- есть каталог бизнес схем тоже со своей эволюцией
- данные с бизнес схемами потребляют конечные пользователи
- есть Джобы которые трансформируют данные из датасорсов в бизнес данные (с бизнес схемами)
Ну и цели
- анализируя Джобы (спарк Джобы или sql трансформации) строить граф движения данных от входных пропертей к бизнес пропертям
- анализируя эволюцию схем автоматом корректировать Джобы трансформации чтоб минимизировать участие программистов
- вычислять неразрешимые автоматом дифы
- показывать в песочнице к чему привидёт возможная эволюция схем

1

У вас интересный аргумент, написали какие требования и спрашиваете как вам конкретный язык поможет разрешить эти вопросы.
Архитектура не определяется языком, но язык может сильно упростить реализацию архитектуры.
Разберу только одно требование.
> - анализируя эволюцию схем автоматом ...
У вас тут задача в первую очередь придумать алгоритм. Но если Clojure поможет вам написать этот алгоритм быстрее, и код будет содержать минимум выражений в дополнении к вашему алгоритму - это плюс или нет?
> ... Джобы трансформации чтоб минимизировать участие программистов
Трансформация данных это то что на Clojure получается очень хорошо. Потому что вы трансформируете в основном коллекции примитивов хорошо продуманной стандартной библиотекой. А не пишите много классов и кода который их трансформирует, 90% необходимых для трасформации методов уже есть в Сlojure, но c объектами вам придется писать свои собственные. Ещё и восхитительные примитивы конкурентного программирования, распараллелить проще .
Я вам могу привести пример, в средние века использовали римскую систему счисления, а потом перешли на ту что мы используем и сейчас. Достигнуть результата можно было с использованием обоих систем, но вот трудозатраты были разные.

0

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

Найти дифф схем я скала мачем быстро сделал. А вот аст на скаламакросах как-то не сильно красиво выходит. Вот смотрю по сторонам сейчас.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
0

Дружище, расслабься уже по поводу бизнеса. Открой свой, потом будешь переживать по этому поводу.

2

Не понял в чем суть задачи связанной с AST которую вы описали. Но код на Clojure это и есть AST, который можно если есть нужда, генерировать в исполнять прямо в runtime. И это будет выглядеть как работа со всё теме же структурами map/list, потому что Clojure гомоиконичен, т.е. код выглядит/является структурами данных этого же языка.

-4

получается что все эти ОРМ и ООП зло, даешь процедурное программирование ) я всю жизнь так говорил, но мне на собеседованиях не верили :(

1

Вам стоит расширить свой кругозор за пределы ООП.)

amok
amok Team Lead в Ergalio
0

Если у меня сущность не тривиальная, с десятком полей, некоторые составные (юзер с телефонами и адресами). Когда я создаю конкретный объект этой сущности, мне нужно помнить имена всех полей?
Не так уж часто нужно писать код трансформации DTOEntity, особенно, если сущности не часто добавляются. Тем более, что это автоматизируется, при желании.
Чистые функции - если у меня совсем не тривиальная бизнес логика и десяток сущностей задействано. Мне нужно сперва собраться все данные (даже те, которые могут не понадобится), чтобы что-то вызвать?

0

> Если у меня сущность не тривиальная, с десятком полей, некоторые составные (юзер с телефонами и адресами). Когда я создаю конкретный объект этой сущности, мне нужно помнить имена всех полей?
Не понял а как вы в вашем языке любимом языке работаете с данной сущностью?) Вам же необходимо знать какой getter дернуть? Если вам нужно четкое описание полей в Clojure есть deftype и defrecord. Ещё вы подумайте над таким фактом, что для большинства операций вам нужно ограниченное кол-во полей из сущности а ваше любимое ORM вам вернет весь объект целиком, в лучшем случае с lazy полями. А я предлагаю другой подход, вытянуть только то что нужно обработать и сохранить, и у вас в подавляющем большинстве случаев будет пару полей а не сотни.
> Не так уж часто нужно писать код трансформации DTOEntity, особенно, если сущности не часто добавляются. Тем более, что это автоматизируется, при желании.
В большинстве проектов это не редкое задание, вообще то. Не забывайте что весь ваш бизнес код это трансформация из одного типа в другой. Что такое сервис? Его методы принимают некоторый объект изменяют и возвращаю другой либо тот же но измененный, в первом случае вам придется на каждый случай писать новый объект а можно просто ассоциативный массив вернуть. Тут нужно попробовать и иначе смотря из далека можно до конца жизни плеваться, но может быть если подойти все окажется намного лучше.
> Чистые функции - если у меня совсем не тривиальная бизнес логика и десяток сущностей задействовано. Мне нужно сперва собраться все данные (даже те, которые могут не понадобится), чтобы что-то вызвать?
Я бы передал просто аргументы в функцию, не знаю что у вас там за пример в голове, для начала предлагаю подумать сколько нужно времени и кода что бы все замокать(ещё и выучить мокито какой ни будь если вы не знакомы) и сравнить просто с вызовом функции с аргументами, очевидно что аргументы функции это все что её понадобиться не больше не меньше, вообще ваш вопрос какой-то мягко говоря странный, вы точно понимаете что такое чистая функция?

Anonymous
Anonymous
0

Втирать своё мнение под лозунгом "только так и никак иначе" сверх :)
Ещё скажите что ФП лучше ООП или наоборот (по этому поводу недавно статья выходила на хабре).

P.S. Слишком много времени и постоянные срачи, видимо скучно.

3

ООП на самом деле не противоречит ФП, Scala тому пример. Есть противопоставление императивной и декларативной парадигмы, ООП это что-то ортогональное.
Я действительно считаю что подходы закрепившиеся в ФП позволяют писать код проще и надежнее.
Теперь про ООП, за годы работы я так и нашел где ООП помогает. Задачи которые встречаются на практике приходится буквально - натягивать на ООП парадигму, если это не окошки, животные или фигуры. Нет иерархии, полиморфизм только в либах, одна инкапсуляция нужна везде, но она есть почти во всех языках.
По итогу, выходит что супер простая вещь как HTTP, суть которой текстовый файл с парами ключ-значение, превращается в гемор из кучи классов.

Anonymous
Anonymous
0

Эмм... опять же. Сугубо ваше мнение по поводу применимости ООП которое основывается на исключительно вашем опыте.
По поводу "ООП на самом деле не противоречит ФП", да соглашусь, но и там и там есть ПЛЮСЫ и МИНУСЫ которые перекрывают/взаимозаменяют друг друга.

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

dzmitry_r
dzmitry_r Developer в Exadel
2

А почему не erlang или haskell ???

1

Так что удалённых кандидатов уже рассматриваете? Было бы интересно посмотреть, правда разница во времени с РБ плюс 9-10 часов.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
1

Пока еще не теряем надежды найти в Минске.

-2

Чушь. Добавьте в требования + 50% зарплаты и возьмите в команду человека которого хорошо знаете и на которого можно положиться и который за такие деньги будет вкалывать. Сказки про ниндзей с горящими глазами в поисках работы в "новых" технологиях - пусть остаются первокусникам и людям которые не в теме.

-1

После бокала pinot grigio навеяло:

Нубизмом пронизан весь тред -
Хипстовая нынче элита.
Добавьте в рекламку "agile".
Вакансия будет закрыта.

Раздались бурные, продо...

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже