Два года с Dart: о том, как мы пишем на языке, который ежегодно «хоронят» (часть 2)



    Продолжаем наше интервью с менеджером по разработке Wrike Игорем Демьяновым. Сегодня поговорим о перспективах языка, его развитии и улучшении инструментов, а также попробуем ответить на вопрос «Dart Шреденгира»: жив все-таки или умер язык, можно ли безбоязненно использовать его в своих проектах.

    Часть 1

    Кто еще из больших компаний использует Dart в разработке в России?

    Есть ребята, которые делают outsourcing на западный рынок, но лично я с ними не знаком. Периодически к нам подходят на конференциях с вопросами о языке, значит люди на нем пишут. У нас есть канал Ru-Dart в слэке, где мы стараемся поддерживать связь с русскоязычным сообществом, там уже больше 100 человек, но не все, конечно, из больших компаний. Хайп — это не самая сильная сторона Dart.

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

    Dart можно использовать и для создания мобильных приложений?

    Да, это Flutter, который они активно сейчас продвигают. На недавней конференции Google I/O было пять докладов по Flutter и один про Angular. Вот такой mobile first. Очевидно, что в приоритете у Google искусственный интеллект и мобильные устройства, акцент с веба немного сместился.

    Конечно, есть еще их большой проект Fuchsia, и он тоже задействует Dart.



    А какие собственные проекты Google пишет на Dart?

    На этом языке написаны все основные прибылеприносящие сервисы Google — AdWords, AdSense, но, как Google сам заявляет, это верхушка айсберга. Много внутренних систем написано на дарте, какие-то их CMS, финансовые тулы.

    По твоим ощущениям, насколько интенсивно язык развивается?

    Язык стандартизирован, и его стандарты не изменятся. Основное развитие сейчас и дальше будет связано с появлением и улучшением различных инструментов. Например, они отказываются от Dartium, потому что очень сложно держать две виртуальные машины, и переход с одной версии дартиума на другую проблематичен. Вместо него развивают Development Dart Compiler (DDC). Он будет работать по такому же принципу, как в Babel и в TypeScript. DDC будет использоваться для разработки, а для продакшн-кода — текущий компилятор, который достаточно хорошо жмет и оптимизирует.

    Насколько разработчики языка прислушиваются к сообществу и к большим компаниям, которые этот язык используют?

    Ребята из Google знают о нас. Раз в год мы делаем в Питере совместный митап по Dart, ежемесячно участвуем в онлайн-встречах с разработчиками языка. Нам сообщают новости о том, как развиваются инструменты, что в дальнейшем планируется, наши “хотелки” спрашивают. Мы можем на баги пожаловаться: что-то закрывается, что-то нет. Можно сказать, прямой диалог у нас есть.

    И какие инсайты?

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

    В Angular 4 должен быть очень сильный Boost и по скорости, и по размеру кода. То есть в третьем уже был boost – от 10 до 20%, плюс на 10% уменьшение самой кодовой базы. В четвертом ждем еще больше.

    И второй вектор их развития – это DDC. Они сейчас его активно «пилят», хотят освободить ресурсы, которые тратят на поддержку Dartium.

    На всех конференциях, где участвуют спикеры Wrike, приходится слышать два вопроса “Жив ли Dart?” и “Почему не TypeScript?”. Не устали отвечать?

    Это как извечная борьба остроконечников и тупоконечников. Кому что нравится. Я еще раз говорю, что для маленьких проектов, для прототипирования я бы выбрал JavaScript — в браузере накидал быстренько и запустил. Для больших проектов, когда требуются паттерны проектирования, когда нужно ООП, отлично подходит Dart. Да, можно выбрать и путь функционального программирования, но это словно спор двух школ боевых искусств. Задачи можно решать разными путями. Мне на эту тему спорить не интересно.



    В данный момент на рынке труда вы легко можете найти работу на JavaScript. Это связано с тем, что порог вхождения в язык низкий. Но если ты всю жизнь писал на C# или Java и хочешь во фронтенд, тебя вряд ли привлечет JS.

    Если речь зашла о людях, то какие разработчики приходят писать на Dart? Понятно, что в России резюме dart-разработчика вряд ли встретишь.

    Если вы хотите работать в Wrike, желательно иметь за плечами, кроме JavaScript, еще какой-то язык с достаточно сильным ООП, типа C#, Java, даже С++. Но все-таки главное для нас — умение мыслить и желание развиваться, искать нетривиальные решения.

    На техническом собеседовании обычно у нас есть два блока — JS и ООП. Мы спрашиваем про JavaScript, потому что у нас есть Legacy. Здесь мы не требуем глубокого погружения, достаточно знать основы языка, остальному легко научиться. Это не проблема. Проблема, как и у любого языка – это уметь писать хорошо. На JavaScript и TypeScript можно тоже писать хороший код, документированный, использовать JS-доки для JavaScript. Но на JS плохой код писать проще, чем на языках с ООП.

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

    А если ты без какого бы ни было опыта хочешь попробовать писать на Dart? Речь касается студентов в первую очередь.

    Есть достаточно хороший сайт webdev.dartlang.org Там много туториалов для тех, кто хочет погрузиться в язык. В Дарте не так много ключевых слов — классы, миксины, экстенды, надо знать стандартные библиотеки, коллекции. Есть такие вещи как стримы, фьючеры для асинхронности. На этом же сайте можно пройти небольшой курс по Angular Dart.

    Но по Angular в интернете достаточно много литературы, как по TypeScript-овому можно почитать, так и по Dart-овому. Там отличие в данный момент минимальное, а тонкости можно в процессе понять, когда будешь использовать код.

    Dart и серверную часть позволяет писать?

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

    Как этот код на дарте взаимодействует с кодом на Java? Здесь есть какие-то нюансы?

    Он взаимодействует через WebSocket-ы, еще мы используем http-взаимодействие. Ничего особенного нет здесь. Теоретически могут возникнуть проблемы с драйверами для кое-каких баз данных. Google использует свои облачные решения, и для них драйвера есть, для остальных — надо смотреть. На самом деле, я не думаю, что сейчас серверный Dart — это основной вектор языка, хотя, если смотреть на ту же «Фуксию», то там используется именно Dart VM. И Dart там является той средой, в которой запускается приложение.

    Wrike и Dart – это навсегда? Или есть что-то, что может вынудить отказаться от языка?

    Все может быть. Например, что-то случится с Google… Или подобного порядка вещи. Но сейчас мы видим, что Google хочет закрепить язык какой-то платформой, надежными инструментами, но точных планов гугла, мы, конечно не знаем. Выйдет Fuchsia, посмотрим, что с нею будет. Нас беспокоит, что не так много внимания уделяется сообществу, но это из-за того, наверное, что основные пользователи языка — создатели внутренних сервисов гугла.

    Они же проводят раз в год Dart-саммит

    Да, так же, как и Polymer-саммит, Angular-саммит. Не сказать, что Dart’у какое-то особое внимание. Но язык, безусловно, живой, коммьюнити, хоть и небольшое, но живое, у нас есть диалог с мейнтейнерами, есть общение в англоязычном и русскоязычном слэк-канале. Ну, конечно, и о своем опыте мы стараемся рассказывать и на больших фронтенд-конференциях, и на локальных технических встречах в Питере.

    Мы будем благодарны за вопросы в комментариях и, если потребуется, напишем более подробные технические статьи о работе с Dart на их основе.
    Wrike 80,40
    Wrike делает совместную работу над проектами проще
    Поделиться публикацией

    Вакансии компании Wrike

    Комментарии 87
    • +2
      Но на JS плохой код писать проще, чем на языках с ООП.

      Такое замечание сильно дискредитирует статью.

      • –5

        Тут скорее имелось в виду, что из-за мультипарадигменности и "свободы" JS на нём можно писать многими способами. Сам язык не даёт каких-то подсказок на эту тему. Языки же с более строгим "вектором" конечно ограничивают разработчика, но и дают ему многое. Статический анализ, типизация и прочее. Учитывая популярнось TS, Flow, уже очевидно, что мировое сообщество заинтересовано в типизации в web

        • +5

          Такая же ошибка. ООП !== статическая типизация.


          В остальном, в принципе, согласен.

          • +1
            С# мультипарадигменный, но и, если мне конечно память не изменяет, вроде про ООП. Какой получится код — плохой или хороший?
          • –5

            Ваш комментарий сильно дискредитирует js-leftpad.

            • 0

              Я тоже считаю что как-то неправильно не использовать функциональные (или в целом даже мульти) парадигмы. И тем более необосновано заявлять что JS отстой, а ООП серебряная пуля.


              Как будто в ООП нельзя лишних singlton-ов наделать, и сильную связность по всему проекту и так далее.

              • +1

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

                • 0
                  Ну, к слову, у OCaml вроде как GIL и проблемы с GC при распараллеливании так и не вылечили…
                  • 0
                    Ну я в принципе окамлы имею в виду, т.е. то, что выросло на плечах окамла. Эфшарп тот же. Ну и вместо лиспа кложур какой-нить. Весьма практичные языки, без тяжелого наследства.
                  • –1

                    С чего бы вдруг? Функциональное программирование не даёт никаких волшебных преимуществ в распараллеливании.

                    • +1

                      Правда, не дает. Просто ООП дает волшебные проблемы с распараллеливанием, а поскольку в ФП их нет...

                      • 0

                        Какие такие проблемы у ООП с распараллеливанием?

                        • +1
                          Shared mutable state?
                          • 0
                            Оно самое.
                            • 0
                              ООП не альтернатива функциональному подходу, это большой паттерн, который прекрасно сочетается с функциональным стилем. Shared mutable state появляется тогда, и только тогда, когда разработчик сам его создает.
                              • +1
                                Не могу не согласиться.

                                Но я начал активно использовать ФП подход в ООП языках только после того как прошел семь кругов ООП «паттернов» и «дизайна», так вот — чем меньше ООП в моих программах сегодня — тем меньше багов, абсолютно линейная зависимость. С ФП также можно перемудрить, но он больше прощает благодаря иммутабельности.

                                А ООП — это паттерн для обмена сообщениями между *переменными*, соответственно мутабельность идет первым классом, и все книги написаны о том как лучше менять переменные, а не о том как этого не делать.
                                • +2
                                  Я искренне хочу помочь людям правильно понимать ООП и то, как он правильно сочитается с ФП.
                                  Многое ниже будет очевидно.

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

                                  На самом деле, ООП — это наследование, полиморфизм и инкапсуляция.
                                  Если по простому — ООП это паттерн, в котором у функций есть первый аргумент, олицетворяющий this, (self, не важно), некий объект, являющийся логическим центром обработки. Эта функция не обязана менять состояние объекта, она может быть и const и pure.

                                  Если в вашем ФП коде есть методы аля updateUser и removeUser, которые принимают первым аргументом один и тот же тип объекта — это ООП.

                                  Вот так просто, есть объекты и их методы. Все остальное — не ОО функции.

                                  Конечно, мало просто иметь функции с одинаковым первым аргументом, это еще не полноценное ООП.
                                  1) Наследование. Единственное требование для наследования — возможность статически переопределять метод объекта, порождая новый тип так, чтобы в новом типе работали все предыдущие методы объекта.
                                  Это значит, что ваш updateUser и removeUser не ОО, потому что нельзя как-то создать новый тип User2, чтобы с ним updateUser вел себя иначе. Функции должны вызываться от типа. Как видите, это не связано с shared state, это лишь паттер — кладите функции внутрь типа, чтобы при наследовании типов одно и то же имя функции вело себя по разному.
                                  2) Полиморфизм. Это про то, что одно и то же имя функции будет вызывать разные функции для объектов, чей тип заранее _неизвестен_. Это опять же не связано с shared state, это ровно про то, что — у вас есть интерфейс, и разные типы могут реализовывать его по разному.
                                  3) Инкапсуляция. Это вообще и про ФП и про ОО. Есть ряд данных и функций, которые мы хотим скрыть от публичного интерфейса. Повесить на них ярлык — эти вещи не для внешнего использования, эти функции можно использовать только внутри определенных функций. Классический пример — функции, начинающиеся с _ или __
                                  __updateUser — скрытая функция, предназначенная для системы работы с пользователями, но никакая другая система не вправе вызывать эту функцию.
                                  updateUser — публичная функция, предназначенная для вызова из любой системы.

                                  Так или иначе, в любом — ФП, процедурном стиле — мы используем ООП, не замечая этого. ООП не про объекты — ООП про абстракцию в виде объектов, их методов и того как эти методы должны работать, переопределяться и быть доступны\недоступны в этом контексте.
                                  • +1
                                    Складывается ощущение, что изначальная мысль посыла о shared mutable state потеряна. Разговор шел не об ООП, а о простоте параллельных вычислений. И вы верно заметили, что SMS появляется там, где нужно. Просто в ФП оно вообще не появляется (без бубнов), вот и вся разница.
                                  • 0
                                    Вы совершенно очевидные вещи говорите для меня. :) Давайте проведем линию четко, без этого «ФП — это ООП и ООП — это ФП». Это две совершенно разные парадигмы. Они не становятся равнозначными просто потому что одно можно выразить через другое.

                                    ООП — изменяемые переменные и повторное использование кода путем наследования, с жесткой привязкой кода к типу данных

                                    ФП — неизменяемые переменные и повторное использование кода путем передачи функций через указатель, а степень привязки кода к типу данных зависит от языка

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

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

                                    В части переиспользования кода ФП также впереди, так как не полагается на бурную фантазию разработчика, лепящего абстракции и «оживляя» данные, а позволяет просто переиспользовать код когда нужно.

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

                                    В то время как по ООП есть отличные книги — помню лет 15 назад дал человеку «С++ для чайников», так он за пол года написал приложение для сбора статистики с нефтяных скважин, со своим драйвером модема, с графиками, базой данных и девицами. При полном отсутствии интернета в качестве источника информации.
                                    • 0
                                      С ФП у нас есть только одна реальная проблема — множество теоретиков от математики набежало и сделало ФП трудным для изучения. Хотя основы ФП просты как палка, начинающим упорно советуют начать обучение с языков-головоломок вместо каких-то практичных вещей.
                                      Вот прям в яблочко! Аж обидно от этого становится… А объяснить без этой базы (теоркат например) что-то более менее высокоуровневое сложновато, потому как шаг влево с тропинки, и все, джунгли из монад.
                                      • –1
                                        Т.е. в ФП программисту нужно запариться чтобы сделать рейс кондишен.

                                        В современных ООП языках тоже нужно париться для этого.

                                        • 0
                                          Простите, но у вас есть ошибка.
                                          «ООП — изменяемые переменные»
                                          Вовсе нет. ООП не требует изменяемых переменных, только инкапсуляцию, наследование и полиморфизм.
                                          Простите, если неверно подал мысль, я не говорил что ФП = ООП, я говорил что ООП и ФП это паттерны разных категорий, и они могут существовать вместе, а значит не противопоставляются.
                                          • +1
                                            Сосуществовать конечно могут.

                                            Но ООП — это по определению именно изменяемое состояние. Если объект при вызове метода вместо изменения состояния возвращает свою измененную копию, то это уже не ООП — это поведение дата-класса в лучшем случае (считается анти-паттерном проповедниками ООП, они даже придумали унизительное название «анемичная модель данных»). А в худшем случае можно сказать что это просто функция которая в лучших традициях ФП возвращает новое значение. При этом взаимосвязи в между объектами теряются и они не могут передавать друг другу сообщения, только от владельца обладаемому.

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

                                            Инкапсуляция, наследование и полиморфизм — это вовсе не определение ООП, это характерные особенности некоторых реализаций ООП, при том якобы эксклюзивная фишка «наследование» реализовано даже не во всех ООП языках. Само наследование есть только в ООП основанном на классах, можно сказать что это не ООП, а Класс-Ориентированное программирование. ТЛДР — Смысла в этом трио я вообще не вижу, им здорово только студентов пугать.
                                            • 0
                                              И снова та же ошибка.
                                              «Но ООП — это по определению именно изменяемое состояние.»
                                              Нет же. ООП не требует изменяемого состояния. Методы объекты могут возвращать что им угодно.
                                              "(считается анти-паттерном проповедниками ООП, они даже придумали унизительное название «анемичная модель данных»)."
                                              Я не знаю этих людей, и почему они называют себя проповедниками ООП, но поверьте, к ООП эта идея не имеет никакого отношения.

                                              «ООП по определению — это именно изменяемое состояние, это симуляция реальных объектов путем обмена сообщениями»
                                              Вот именно с этим заблуждением и боролся мой первый комментарий.

                                              из вики
                                              «Объе́ктно-ориенти́рованное программи́рование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса[1], а классы образуют иерархию наследования[2][3].»
                                              В определении все хорошо — от программы требуют писать все в объектах, их методах, взаимосвязь типов обязуют делать через наследование.

                                              Есть и другое определение, что ООП — это наследование, инкапсуляция и полиморфизм.
                                              Ни в одном из определений вы никогда не встретите требования иметь изменяемые данные.
                                              • +1
                                                В то время как лучшие умы ломают головы над тем что же есть ООП http://wiki.c2.com/?DefinitionsForOo

                                                В википедии, оказывается, все давно написано! :-D

                                                Наивно.
                                                • 0
                                                  Они ломают голову над нюансами. Так всегда происходит, когда определение чего-то допускает расширения. Вот вам пример — web 2.0. В свое время у каждого в голове было чуть ли не свое видение web 2.0, однако именно ключевые концепции были известны.
                                                  Формально точного определения ООП не существует, и да простите меня за новую цитату с ненадежной вики, но непосредственно ключевые, необходимые и достаточные моменты для ООП известны и точны:
                                                  «Ключевые черты ООП хорошо известны:

                                                  Первая — инкапсуляция — это определение классов — пользовательских типов данных, объединяющих своё содержимое в единый тип и реализующих некоторые операции или методы над ним. Классы обычно являются основой модульности, инкапсуляции и абстракции данных в языках ООП.
                                                  Вторая ключевая черта, — наследование — способ определения нового типа, когда новый тип наследует элементы (свойства и методы) существующего, модифицируя или расширяя их. Это способствует выражению специализации и генерализации.
                                                  Третья черта, известная как полиморфизм, позволяет единообразно ссылаться на объекты различных классов (обычно внутри некоторой иерархии). Это делает классы ещё удобнее и облегчает расширение и поддержку программ, основанных на них.
                                                  Инкапсуляция, наследование и полиморфизм — фундаментальные свойства, которыми должен обладать язык, претендующий называться объектно-ориентированным (языки, не имеющие наследования и полиморфизма, но имеющие только классы, обычно называются основанными на классах).»

                                                  И я с этими ключевыми моментами абсолютно согласен. И категорически не согласен, что изменяемые данные — это свойство или необходимый ключевой момент для ООП.
                                                  • 0
                                                    За вы уже задрали свою инкапсуляцию сюда копипастить, как будто это откровением для меня должно быть. )) Я про нее уже двадцать лет знаю. Вам делать больше нечего? Или просто поучать нравится?
                                                    • 0
                                                      Не нравится, честно честно.
                                                      Нравится разбираться и искать истину. Дух сообщения не в инкапсуляции же был, а в том, что она — действительно ключевой момент ООП, а shared state — вообще не момент из ООП, и никак к нему не относится.
                                                      • 0
                                                        Ясли я сделаю все методы и данные пабликом — моя ООП программа автоматически не превратстся в ФП или в Процедурное. Очевидно?
                                                        • 0
                                                          Конечно.
                                                          Она перестанет быть ОО, если в паблик попадут скрытые методы и данные, т. к. в процессе написания кода разработчик справедливо будет использовать публичные функции и данные, которые для этого не предназначены, и полезут UB.
                                                          • 0
                                                            Она перестанет быть ОО, если в паблик попадут скрытые методы и данные

                                                            Не перестанет.

                                                            • 0
                                                              Я соглашусь, что это получится ОО с ошибками.
                                                              • 0

                                                                Сколько можно путать сокрытие и инкапсуляцию...


                                                                И нет, ошибочный ООП код не перестаёт быть ООП.

                                                                • 0
                                                                  Да не путаю я, в контексте ООП сокрытие часть инкапсуляции. С остальным согласен.
                                                              • 0
                                                                То есть вы узнаете ООП код, даже если из него будут удалены все модификаторы private, хоть и назовете его не православным. Отлично.

                                                                Следовательно, инкапсуляция не является *обязательным* свойством ООП.

                                                                Поедем дальше. Что если я заменю все наследование в ООП коде на композицию, согласно с современным best practices — «favor composition over inheritance»? Вы узнаете ООП и в этом случае, не так ли?

                                                                Но еще остался полиморфизм. Мы уже удалили все наследование, соответственно в небольшом количестве мест где нам действительно нужен полиморфизм, мы использовали интерфейсы. Интерфейс — это всего лишь таблица с функциями, не так ли? Можно ли назвать любое место где используются таблицы с функциями — ООП? Конечно нет.

                                                                Но после всех этих трансформаций вы все еще можете распознать ООП в оригинальном приложении, не так ли? Вот объект Окно, у него есть положение, оно может передавать сообщение о том что пользователь нажал крестик другим объектам… По каким признакам вы узнаете ООП? Эти признаки и есть *настоящее определение ООП*, а вовсе не эти три пункта, которые вы копипастите. ;)

                                                                Настоящее определение ООП — это представление предметной области в виде групп переменных и функций, и эти группы (объекты) взаимодействуют путем отправки друг другу сообщений (вызывают функции друг друга).
                                                                • 0
                                                                  Смотрите, если у объекта Окно будет функция открытьДверь, а у Двери функция открытьЖалюзиОкна, т.е. бессвязная мешанина данных и функций, и нет такого, что группе функций сопоставляется один объект, я не распознаю ООП.
                                                                  А вот объединение функций в группы — и есть инкапсуляция. В любом коде с объектом и методами будет инкапсуляция.
                                                                  Предпочитать композицию хорошо, но что делать, если уже есть компонент VelocityComponent, и нам нужен (правда правда, мы в игре совершенствуем физику, и нам нигде не нужен VelocityComponent, зато нужен будет SuperVelocityComponent. И вот здесь, в терминах композиции я буду вынужден с нуля описывать SuperVelocityComponent, или как-то хитрить, и делать объект, у которого VelocityComponent это поле, и он просто проксирует через свои методы все все методы этого компонента, но суть будет все равно в том, что для правильной архитектуры нам будет нужно наследование для такой операции. Вы можете искуственно ограничить себя и сказать — без наследования все равно ООП но мне правда кажется что нет. То есть вот она, программа — код написан, и он работает, но именно из за отсутствия возможности расширять код дальше через наследование — убивает для меня объектную природу этого кода. Она становится компонентной, если позволите.
                                                                  Полиморфизм. Интерфейсы. Можно ли назвать таблицу с функциями полиморфизмом? Нет, ведь таблицы бывают разные, но та таблица с функциями, которая в зависимости от типа отдает разные функции — реализация полиморфизма с одним аргументом.
                                                                  • 0
                                                                    представление предметной области в виде групп переменных и функций

                                                                    Это и есть суть инкапсуляции, а не "модификаторы private".

                                                                    • 0
                                                                      Вы правы, у меня была другая дефиниция инкапсуляции. Да, инкапсуляция — необходимый элемент ООП.
                                                              • 0
                                                                Как быть с ООП языками, которые не имеют инкапсуляции?
                                                                • 0

                                                                  Что за ООП язык без инкапсуляции?

                                                                • 0
                                                                  Очевидно, они не ООП.
                                                                  Но вообще-то, поддержка инкапсуляции на уровне компилятора совершенно не обязательна. Достаточно code style нотации — к примеру ставить __ перед приватными членами и методами.
                                            • 0
                                              Полиморфизм. Это про то, что одно и то же имя функции будет вызывать разные функции для объектов, чей тип заранее неизвестен.

                                              Это динамическая диспетчеризация. Полиморфизм — возможность передавать аргументы разных типов.


                                              Инкапсуляция. Это вообще и про ФП и про ОО. Есть ряд данных и функций, которые мы хотим скрыть от публичного интерфейса.

                                              Это сокрытие. Инкапсуляция — объединение данных и функций для работы с ними в одной капсуле — объекте.

                                        • 0

                                          Вас кто-то заставляет шарить мутабельное состояние?.

                                  • 0

                                    У вас, видимо, неправильный ООП

                                    • 0
                                      На Jpoint был любопытный доклад на этот счет
                                      • +1
                                        Читал этого блоггера — он просто каждую функцию оборачивает в объект (называет это декораторами), вот и весь его ООП. Причем тут ООП вообще? Это ФП с кучей синтаксического мусора и кривой типизацией.

                                        Посмотрел лекцию. Аргументация хромает. Почему, к примеру, getPath нельзя, а getContent можно? Статические функции — зло? Я знаю почему *иногда* это зло (если статическая функция меняет внешние переменные), но аргументация в лекции основана на «это устарело». Мы где-то это слышали — 3.5мм джек устарел. Поэтому мы будем использовать переходники, это современно и элегантно (см «Элегантные объекты»).
                              • 0
                                Мы будем благодарны за вопросы в комментариях и, если потребуется, напишем более подробные технические статьи о работе с Dart на их основе.

                                Хотелось бы узнать подробнее про серверную часть.
                                • 0
                                  Если сформулируете конкретные вопросы, нам будет проще.
                                  • 0
                                    Что представляет из себя компонент, который вы зарелизели(это какой-то API, связующее звено между внутренними компонентами, модуль который выполняет математические операции, анализ, работа с бд или что), вы полностью его переписали на Dart или он по прежнему гибридный(java,nodejs… и что еще у вас)?
                                    Что нужно для того что бы запустить на сервере код который написан на Dart?
                                    Можно ли написать на Dart, полноценное API к приложению?
                                    • +2

                                      Давайте по-порядку:


                                      что представляет из себя компонент, который вы зарелизели

                                      У нас есть такая штука, как одновременное редактирование задач. Как в google документах, видно кто и что сейчас пишет, есть маркеры и пр. В основе лежит парадигма Operation Transformation. Как раз backend часть этой фичи и написана на Dart. Вкратце приложение общается с MongoDB и Postgress и с клиентом по websockets и передаёт туда-обратно данные


                                      вы полностью его переписали на Dart или он по прежнему гибридный

                                      Код в основном на Dart, есть небольшие модули на node, но в скором времени и их не будет


                                      Что нужно для того что бы запустить на сервере код который написан на Dart?

                                      Поставить Dart


                                      Можно ли написать на Dart, полноценное API к приложению?

                                      Не очень понимаю, к какому, но да, ничто не мешает это сделать. Есть такая штука Aqueduct

                                • +3
                                  Строго говоря, есть предостаточно компаний, которые используют нишевые языки, и используют их успешно. На ум приходит Jane Street Capital и их использование OCaml. До сих пор остались компании, которые использую APL — язык, который требует отдельную клавиатуру:

                                  image

                                  Ну и так далее. Я к чему — все это не показатель. То есть, мы рады за вас то у вас все полуается, но…
                                  • +2
                                    Чем, по-вашему, нишевый язык отличается от не нишевого?
                                    • 0
                                      Количеством ресурсов, которые сидят на этом языке. Например, на OCaml в какой-то момент был один человек. Это значит что если у тебя серьезная проблема с языком (например, констукт синтезирует неправильный байткод), тебе могут быстро ответить и пофиксить, или же такой возможности вообще не существует.
                                      • 0
                                        А если в цифрах? Где грань между нишевым и не нишевым?
                                  • +1
                                    Пытался посмотреть в сторону Dart. Не нашёл какой-либо библиотеки компонентов. Смотрел angular.dart.ui он в довольно за атомной состоянии. Подсаажите чем вы пользуетесь?
                                    • 0
                                      Извиняюсь пишу с телефона. Имелось в виду что angular.dart.ui в зачаточном состоянии.
                                    • +1
                                      Недавно начал знакомиться с Flutter, пока впечатления намного лучше, чем от React Native.
                                      • +1
                                        Пишу статью сравнивающую Dart и Scala.js. Надеюсь подойти к вопросу максимально объективно и непредвзято, хотя Scala нравится мне всё-таки больше. Сейчас на недельку-две отбываю на дачу по случаю летнего времени. Но к середине июля надеюсь всё-таки опубликовать.
                                        • 0
                                          Если будут нужны консультации по Dart, пишите в direct message или Dart Slack канал
                                          • 0
                                            Спасибо, хотя пока у меня куда больше вопросов по Scala. Оба языка я изучаю с нуля, одновременно с написанием статьи и небольшого, однако вполне реального и применимого на практике проекта на обоих языках сразу, на котором я их сравниваю. Но Dart вобщем-то почти ничего нового для меня не содержит. Это скорее даже старый знакомый С++ чем Java. Ну есть конечно отдельные вкусняшки типа именованных параметров. А вот Scala там да… Только что например с удивлением узнал, что там существует такая штука как Function0. Причём не просто для галочки, а некоторые методы библиотеки scalajs.dom требуют именно её в качестве обработчика. И не удовлетворяются обычными определениями через def, возвращающими Unit. Смысл этого мне абсолютно непонятен, однако медицинский факт! Вобщем чем дальше в лес, тем толще партизаны :)))
                                            • 0
                                              Обращайтесь если что.

                                              Function0 — функция арности 0 (количество аргументов = 0).
                                              Аналог Supplier в java 8. Сокращенная запись () => T, но можно записать и как Function0[T] (не ясно, правда, зачем). https://scalafiddle.io/sf/qs25LOB/1:
                                              def test1(f: () => String) = f()
                                              def test2(f: Function0[String]) = f()
                                              
                                              println(test1{ () => "Hi!" })
                                              println(test2{ () => "Hi!" })
                                              
                                              • 0
                                                Я это понял как функция не возвращающая вообще ничего. Даже Unit. Почему и дико удивился. Тем не менее нужное определение сделал и этот код у меня прекрасно работает. Но как говорится «осадочек остался» :))) Надо будет проверить в Jupyter, что же такое я определил. Пока явных преимуществ Scala перед Dart мне обнаружить не удалось, хотя сам я болею за Scala. Пока единственный интересный момент — классы, определяемые внутри функции. Возникла необходимость написать функцию, принимающую простые параметры, но довольно сложно их обрабатывающую. Для этого было удобно ввести некий класс, не нужный нигде за пределами этой функции. На Scala я это сделал сходу, определив класс внутри функции. А вот с Dart-ом ломаю голову что лучше, выносить этот код в отдельную библиотеку или обрабатывать всё как List.
                                                P.S. Увы, сегодня в 11 вечера по Москве отбываю на дачу. Появлюсь не раньше чем через неделю.
                                                • 0
                                                  У вас какой бэкграунд?

                                                  Просто scala.js отлично подходит тем, кто уже залез в глубины scala и не готов расставаться. А вот для изучения… безумству храбрых поем мы песню =).

                                                  Преимущества scala.js проявиться могут либо в единой кодовой базе с BE на jvm, либо в хардкорном метапрограммировании, либо в не менее хардкорном FP с вложенными монадами и прочими прелестями. Еще опция — формализация вашей задачи и описание в виде DSL.
                                                  Для всего этого надо быть scala спецом, решившим покодить под FE, а не наоборот.

                                                  А вот что с нуля вам предложить как киллерфичу scala.js я даже не представляю.
                                                  • 0
                                                    Бэкграунд у меня 30 лет программирования. Правда в основном низкоуровневого и околожелезного. Функциональщиной никогда не занимался, хотя и интересовался. Но просто не было задачи хотя бы под тот же хаскель. Но во всяком случае занимаюсь скалой имея некоторую базу. Ну а киллерфичей для меня стала сама скала. Давно ей интересовался. Мне очень нравится огромное количество научных и data science-библиотек, поддержка в Jupyter и наличие инструмента для хардварного дизайна (https://chisel.eecs.berkeley.edu/index.html), но было как-то не досуг. Когда же я узнал, что на этом ещё можно писать и веб-странички, это переполнило мою чашу терпения. Сейчас приехал с дачи и сходу написал фигню, принимающую в качестве параметров и Int и Double, но ничего кроме них. А потом другую фигню, позволяющую описывать все мои манипуляции с div-ами на веб-страничке на на чём-то, напоминающем естественный язык, причем родной рабоче-крестьянский(кириллица utf-8), а не буржуйский! Просто ради прикола. Вобщем последний раз мне так рвало крышу лет 20 назад, когда активно писал на Forth-е. Великий язык, однозначно. Хотя спроси меня сейчас на чём писать для продакшена человеку желающему работать, а не получать удовольствие, без сомнения порекомендую всё-таки Dart.
                                                    • 0
                                                      P.S. Серверная часть у меня на php. Тут увы, выбирать просто не из чего. Мой Большой Проект (а нынешний малый проект это часть большого), предназначен для нищей публики, выбирающей дешевые хостинги. Разумеется предпочел бы ту же скалу или яву с вкусняшкой типа Play 2. И с этим связано пожалуй единственное серьёзное огорчение, которое мне доставила скала к сегодняшнему дню. Ну не хочет её плагин жить под PhpStorm, хоть веником убейся! С Dart всё пушисто и шоколадно. Ставлю его в PhpStorm, создаю Dart-проект в виде минимального веб-приложения, добавляю php и вперёд. Бряки работают одновременно и в коде на php и в Dart. А вот со скалой приходится запускать Idea. И память собака жрёт нипадеццки, и переключаться из одной IDE в другую тоже лишнее рукомашество. В остальном доволен как слон. Кой-то веки получил игрушку, которая меня всерьёз увлекла и от которой явственно сносит крышу.
                                                      • 0
                                                        Про Play 2 — если scala нравится как язык, то я бы порекомендовал akka-http — на мой взгляд это гораздо более scala way.
                                                        • 0
                                                          Вообще-то я для своих домашних рукоблудийделий, обычно юзаю либо jetty либо поднимаю http прямо на сокетах, если нужно кому-то отдать что-то очень простое и предельно компактное. Про Play 2 просто слышал много хорошего и хотелось бы попробовать. Но в этой задаче увы, только классика, только трэш и хардкор. Я просто связан по рукам и ногам условиями использования — дешевым хостингом на apache с php+mysql. Так что хоть люблю php не более чем javascript, придется всё делать на нём. К счастью задача такова, что подавляющая часть работы будет на клиенте. Серверная часть тут скорее просто мост между клиентом и базой данных. Впрочем спасибо, akka-http обязательно попробую. Тут была задумка поторговать на форексе с применением всего того, чему научился за последние 10 лет. А поскольку я люблю веб-интерфейсы, хорошая серверная часть у меня всегда востребована.
                                                      • 0
                                                        P.P.S. Что ещё заметил. Пожалуй никому не стал бы рекомендовать скалу в качестве первого языка функционального программирования. Уж больно много свободы она собака такая даёт. Для продакшена это разумеется бесценное качество. Но оно же делает язык непригодным в качестве учебного. Приходится очень жестко себя контролировать чтобы не халтурить и по возможности писать функционально. Начинать наверно надо бы с чего-то типа хаскеля. Но с ним у меня увы, не сложилось. Читать книжки и делать упражнения не интересно, а реальной задачи под него к сожалению не было. Так что развиваюсь я наверно по далеко не лучшему пути. Ну что же, значит судьба моя такой :)
                                                        • 0
                                                          Есть возможность взять лучшее из 2 миров: есть отличная адаптация Learn You a Haskell for Great Good! для scala: herding cats.
                                                          • 0

                                                            Большое вам спасибо! Все не знал с какой стороны подступиться :)

                                                            • 0
                                                              Простите что влез, но попробуйте всё-таки по моему пути. Поставьте себе какую-нибудь не очень сложную, но тем не менее абсолютно реальную задачу. Например сверстать динамическую веб-страничку для своего сайта. И сделайте это на scala.js. Это абсолютно та же самая scala. Только компилируется она не в классы jvm, а в javascript. Так что пока работаете, будете изучать скалу. Просто для себя я уже понял, что книжки читать бесполезно. Новый язык можно освоить только если пишешь на нём что-то абсолютно реальное, не учебное. Нужное либо тебе самому, либо то, за что тебе платят деньги на работе. Хотя мне в данный конкретный момент легче. Сижу без работы и сам выбираю чем мне заняться :)
                                                          • 0
                                                            Спасибо, но это опять же книжка с упражнениями. Ну не получается у меня учиться по таким вещам! То ли возраст виноват (мне послезавтра стукнет 56), то ли характер. Мне для обучения нужна ЗАДАЧА. Та, которую я сам заинтересован решить. Или на работе, или мой собственный проект. Learn You a Haskell for Great Good я разумеется читать пытался. Но быстро во-первых заела текучка, во-вторых просто потерял интерес. Ну не было под хаскель никакого реального проекта! Впрочем и сейчас нет. Скале тут повезло куда больше. Поэтому сейчас с огромным удовольствием её изучаю, без отрыва от абсолютно реального проекта на ней :)
                                                            • 0
                                                              Например сверстать динамическую веб-страничку для своего сайта. И сделайте это на scala.js

                                                              Ну не было под хаскель никакого реального проекта!

                                                              Попробуйте провернуть то же самое с purescript. А тут книжка.

                                                              • 0
                                                                Да нет, я же не утверждаю что книжки читать не надо вообще. Иначе как вообще узнать хоть что-то об изучаемом предмете. Разве что с помощью телепатии :) Я лишь о том, что параллельно с чтением обязательно нужно на изучаемом языке что-то делать(хотя у меня скорее наоборот, чтение книжек идёт параллельно с работой как основой). Причем именно РЕАЛЬНОЕ, нужное по работе или хобби. Тут две фишки. Во-первых реальная задача Вас очень сильно мотивирует. Во-вторых выполняя реальную работу, Вам гораздо легче убедить себя, что все трудности преодолимы и незначительны. Хотя не отрицаю, что у моего подхода есть и недостатки. Например обучение делается несколько бессистемным. Кстати из той же оперы. В давние времена(ещё в СССР), когда я занимался мордобоем, тренер нам советовал не пренебрегать уличными драками, хотя конечно и с некоторой осторожностью и умом. Утверждая что без такой практики обучение бесполезно. С программированием вобщем-то по-моему абсолютно то же самое.
                                                        • 0
                                                          Вобщем даже не знаю что мне теперь делать. Обещал написать статью, значит надо выполнять. За одно может и инвайт на любимый хабр дадут, что тоже было бы не лишним. Но О ЧЁМ ПИСАТЬ, убей Бог не знаю. Умом понимаю что Dart бьёт Scala.js по всем статьям и с разгромным счётом. Но сердце моё отныне и во веки веков принадлежит scala… Трудная ситуация. Что посоветуете?
                                                          • 0
                                                            Если хотите написать о преимуществах scala, то надо с ними очень хорошо ознакомиться. Все-таки побить Dart на его поле (или хотя бы играть с ним на равных) можно только очень хорошо зная scala.
                                                            Лично я не настолько хорошо знаком с разработкой FE, чтоб писать такие статьи.
                                                            • +1
                                                              Можно написать что-то одинаковое на двух языках (todomvc, например) покажите код, опишите впечатления.
                                                              • +1
                                                                Да, наверно так и сделаю. Сначала хотел писать один в один, но увы, не получается. Чем больше знакомлюсь со скалой, тем сильнее код на ней расходится с параллельным проектом на Dart.
                                                          • 0
                                                            Презентация по scala.js от SAP. Возможно вам поможет.

                                                    • 0

                                                      Может сразу и Kotlin.js захватите?

                                                      • +1
                                                        Kotlin я первоначально рассматривал. Но пришел в ужас, когда увидал что простейшая hello world тащит за собой библиотеку весом без малого полтора мегабайта. Вообще у меня сейчас задача выбора языка для предстоящего довольно большого проекта. И я решил предварительно сделать небольшой, однако вполне практический проект на нескольких языках, чтобы выбрать лучший для большого. Раньше писал на typescript но он никогда мне особо не нравился и сменить его я уже давно намеревался. А тут и повод. Вобщем случилось так, что из претендентов остался только один Dart. Я уже плюнул на всю затею и начал писать на Dart-е, когда совершенно случайно узнал от любимого Хабра про Scala.js. Короче сейчас у меня чемпионат из двух участников. Причем и Dart и Scala я изучаю с нуля :)

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

                                                    Самое читаемое