Продолжаем наше интервью с менеджером по разработке 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 на их основе.
Поделиться с друзьями
k12th
Такое замечание сильно дискредитирует статью.
bunopus
Тут скорее имелось в виду, что из-за мультипарадигменности и "свободы" JS на нём можно писать многими способами. Сам язык не даёт каких-то подсказок на эту тему. Языки же с более строгим "вектором" конечно ограничивают разработчика, но и дают ему многое. Статический анализ, типизация и прочее. Учитывая популярнось TS, Flow, уже очевидно, что мировое сообщество заинтересовано в типизации в web
k12th
Такая же ошибка. ООП !== статическая типизация.
В остальном, в принципе, согласен.
raveclassic
С# мультипарадигменный, но и, если мне конечно память не изменяет, вроде про ООП. Какой получится код — плохой или хороший?
serg_deep
Ваш комментарий сильно дискредитирует js-leftpad.
knotri
Я тоже считаю что как-то неправильно не использовать функциональные (или в целом даже мульти) парадигмы. И тем более необосновано заявлять что JS отстой, а ООП серебряная пуля.
Как будто в ООП нельзя лишних singlton-ов наделать, и сильную связность по всему проекту и так далее.
Nakosika
Мне почему-то кажется уже несколько лет что ООП свое отживает. С выпуском многоядерных процессоров для широкой общественности всех ООП фанатов рынок заставит обрить голову и идти в сторону всяких окамлов и лиспов. Есть правда вариант что они продолжат катить квадратное, но подох же джамп в конце концов, авось и объекты туда же...
raveclassic
Ну, к слову, у OCaml вроде как GIL и проблемы с GC при распараллеливании так и не вылечили…
Nakosika
Ну я в принципе окамлы имею в виду, т.е. то, что выросло на плечах окамла. Эфшарп тот же. Ну и вместо лиспа кложур какой-нить. Весьма практичные языки, без тяжелого наследства.
vintage
С чего бы вдруг? Функциональное программирование не даёт никаких волшебных преимуществ в распараллеливании.
Nakosika
Правда, не дает. Просто ООП дает волшебные проблемы с распараллеливанием, а поскольку в ФП их нет...
vintage
Какие такие проблемы у ООП с распараллеливанием?
raveclassic
Shared mutable state?
Nakosika
Оно самое.
Shifty_Fox
ООП не альтернатива функциональному подходу, это большой паттерн, который прекрасно сочетается с функциональным стилем. Shared mutable state появляется тогда, и только тогда, когда разработчик сам его создает.
Nakosika
Не могу не согласиться.
Но я начал активно использовать ФП подход в ООП языках только после того как прошел семь кругов ООП «паттернов» и «дизайна», так вот — чем меньше ООП в моих программах сегодня — тем меньше багов, абсолютно линейная зависимость. С ФП также можно перемудрить, но он больше прощает благодаря иммутабельности.
А ООП — это паттерн для обмена сообщениями между *переменными*, соответственно мутабельность идет первым классом, и все книги написаны о том как лучше менять переменные, а не о том как этого не делать.
Shifty_Fox
Я искренне хочу помочь людям правильно понимать ООП и то, как он правильно сочитается с ФП.
Многое ниже будет очевидно.
Верно, неправильно применяя ООП, можно добиться невероятных приключений в разработке и поддержке кода.
На самом деле, ООП — это наследование, полиморфизм и инкапсуляция.
Если по простому — ООП это паттерн, в котором у функций есть первый аргумент, олицетворяющий this, (self, не важно), некий объект, являющийся логическим центром обработки. Эта функция не обязана менять состояние объекта, она может быть и const и pure.
Если в вашем ФП коде есть методы аля updateUser и removeUser, которые принимают первым аргументом один и тот же тип объекта — это ООП.
Вот так просто, есть объекты и их методы. Все остальное — не ОО функции.
Конечно, мало просто иметь функции с одинаковым первым аргументом, это еще не полноценное ООП.
1) Наследование. Единственное требование для наследования — возможность статически переопределять метод объекта, порождая новый тип так, чтобы в новом типе работали все предыдущие методы объекта.
Это значит, что ваш updateUser и removeUser не ОО, потому что нельзя как-то создать новый тип User2, чтобы с ним updateUser вел себя иначе. Функции должны вызываться от типа. Как видите, это не связано с shared state, это лишь паттер — кладите функции внутрь типа, чтобы при наследовании типов одно и то же имя функции вело себя по разному.
2) Полиморфизм. Это про то, что одно и то же имя функции будет вызывать разные функции для объектов, чей тип заранее _неизвестен_. Это опять же не связано с shared state, это ровно про то, что — у вас есть интерфейс, и разные типы могут реализовывать его по разному.
3) Инкапсуляция. Это вообще и про ФП и про ОО. Есть ряд данных и функций, которые мы хотим скрыть от публичного интерфейса. Повесить на них ярлык — эти вещи не для внешнего использования, эти функции можно использовать только внутри определенных функций. Классический пример — функции, начинающиеся с _ или __
__updateUser — скрытая функция, предназначенная для системы работы с пользователями, но никакая другая система не вправе вызывать эту функцию.
updateUser — публичная функция, предназначенная для вызова из любой системы.
Так или иначе, в любом — ФП, процедурном стиле — мы используем ООП, не замечая этого. ООП не про объекты — ООП про абстракцию в виде объектов, их методов и того как эти методы должны работать, переопределяться и быть доступны\недоступны в этом контексте.
raveclassic
Складывается ощущение, что изначальная мысль посыла о shared mutable state потеряна. Разговор шел не об ООП, а о простоте параллельных вычислений. И вы верно заметили, что SMS появляется там, где нужно. Просто в ФП оно вообще не появляется (без бубнов), вот и вся разница.
Shifty_Fox
Если что, я сторонник ФП (:
Nakosika
Вы совершенно очевидные вещи говорите для меня. :) Давайте проведем линию четко, без этого «ФП — это ООП и ООП — это ФП». Это две совершенно разные парадигмы. Они не становятся равнозначными просто потому что одно можно выразить через другое.
ООП — изменяемые переменные и повторное использование кода путем наследования, с жесткой привязкой кода к типу данных
ФП — неизменяемые переменные и повторное использование кода путем передачи функций через указатель, а степень привязки кода к типу данных зависит от языка
Инкапсуляцию оставим за бортом, так как это свойство конкретного языка программирования, а не парадигмы. В С инкапсуляция ни чуть не хуже чем в С++.
В части многопоточности ФП впереди так как держит изменение переменных под контролем, что делает каждый рейс кондишен очевидным в момент когда программист его пишет. Т.е. в ФП программисту нужно запариться чтобы сделать рейс кондишен.
В части переиспользования кода ФП также впереди, так как не полагается на бурную фантазию разработчика, лепящего абстракции и «оживляя» данные, а позволяет просто переиспользовать код когда нужно.
С ФП у нас есть только одна реальная проблема — множество теоретиков от математики набежало и сделало ФП трудным для изучения. Хотя основы ФП просты как палка, начинающим упорно советуют начать обучение с языков-головоломок вместо каких-то практичных вещей.
В то время как по ООП есть отличные книги — помню лет 15 назад дал человеку «С++ для чайников», так он за пол года написал приложение для сбора статистики с нефтяных скважин, со своим драйвером модема, с графиками, базой данных и девицами. При полном отсутствии интернета в качестве источника информации.
raveclassic
vintage
В современных ООП языках тоже нужно париться для этого.
Shifty_Fox
Простите, но у вас есть ошибка.
«ООП — изменяемые переменные»
Вовсе нет. ООП не требует изменяемых переменных, только инкапсуляцию, наследование и полиморфизм.
Простите, если неверно подал мысль, я не говорил что ФП = ООП, я говорил что ООП и ФП это паттерны разных категорий, и они могут существовать вместе, а значит не противопоставляются.
Nakosika
Сосуществовать конечно могут.
Но ООП — это по определению именно изменяемое состояние. Если объект при вызове метода вместо изменения состояния возвращает свою измененную копию, то это уже не ООП — это поведение дата-класса в лучшем случае (считается анти-паттерном проповедниками ООП, они даже придумали унизительное название «анемичная модель данных»). А в худшем случае можно сказать что это просто функция которая в лучших традициях ФП возвращает новое значение. При этом взаимосвязи в между объектами теряются и они не могут передавать друг другу сообщения, только от владельца обладаемому.
ООП по определению — это именно изменяемое состояние, это симуляция реальных объектов путем обмена сообщениями — см. причины создания первого ООП языка — Симула. Каждый объект представлен именно как объект, по одному объекту на симулируемый объект, и ни как иначе. Никакого копирования объектов для обеспечения иммутабельности там не было — это недавняя придумка программистов, которых окончательно выбесило дикое количество багов в ООП программах и которые решили хоть как-то упорядочить этот хаос. Ограничения по памяти и примитивная сборка мусора также не давали осуществить стратегию иммутабельности.
Инкапсуляция, наследование и полиморфизм — это вовсе не определение ООП, это характерные особенности некоторых реализаций ООП, при том якобы эксклюзивная фишка «наследование» реализовано даже не во всех ООП языках. Само наследование есть только в ООП основанном на классах, можно сказать что это не ООП, а Класс-Ориентированное программирование. ТЛДР — Смысла в этом трио я вообще не вижу, им здорово только студентов пугать.
Shifty_Fox
И снова та же ошибка.
«Но ООП — это по определению именно изменяемое состояние.»
Нет же. ООП не требует изменяемого состояния. Методы объекты могут возвращать что им угодно.
"(считается анти-паттерном проповедниками ООП, они даже придумали унизительное название «анемичная модель данных»)."
Я не знаю этих людей, и почему они называют себя проповедниками ООП, но поверьте, к ООП эта идея не имеет никакого отношения.
«ООП по определению — это именно изменяемое состояние, это симуляция реальных объектов путем обмена сообщениями»
Вот именно с этим заблуждением и боролся мой первый комментарий.
из вики
«Объе?ктно-ориенти?рованное программи?рование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса[1], а классы образуют иерархию наследования[2][3].»
В определении все хорошо — от программы требуют писать все в объектах, их методах, взаимосвязь типов обязуют делать через наследование.
Есть и другое определение, что ООП — это наследование, инкапсуляция и полиморфизм.
Ни в одном из определений вы никогда не встретите требования иметь изменяемые данные.
Nakosika
В то время как лучшие умы ломают головы над тем что же есть ООП http://wiki.c2.com/?DefinitionsForOo
В википедии, оказывается, все давно написано! :-D
Наивно.
Shifty_Fox
Они ломают голову над нюансами. Так всегда происходит, когда определение чего-то допускает расширения. Вот вам пример — web 2.0. В свое время у каждого в голове было чуть ли не свое видение web 2.0, однако именно ключевые концепции были известны.
Формально точного определения ООП не существует, и да простите меня за новую цитату с ненадежной вики, но непосредственно ключевые, необходимые и достаточные моменты для ООП известны и точны:
«Ключевые черты ООП хорошо известны:
Первая — инкапсуляция — это определение классов — пользовательских типов данных, объединяющих своё содержимое в единый тип и реализующих некоторые операции или методы над ним. Классы обычно являются основой модульности, инкапсуляции и абстракции данных в языках ООП.
Вторая ключевая черта, — наследование — способ определения нового типа, когда новый тип наследует элементы (свойства и методы) существующего, модифицируя или расширяя их. Это способствует выражению специализации и генерализации.
Третья черта, известная как полиморфизм, позволяет единообразно ссылаться на объекты различных классов (обычно внутри некоторой иерархии). Это делает классы ещё удобнее и облегчает расширение и поддержку программ, основанных на них.
Инкапсуляция, наследование и полиморфизм — фундаментальные свойства, которыми должен обладать язык, претендующий называться объектно-ориентированным (языки, не имеющие наследования и полиморфизма, но имеющие только классы, обычно называются основанными на классах).»
И я с этими ключевыми моментами абсолютно согласен. И категорически не согласен, что изменяемые данные — это свойство или необходимый ключевой момент для ООП.
Nakosika
За вы уже задрали свою инкапсуляцию сюда копипастить, как будто это откровением для меня должно быть. )) Я про нее уже двадцать лет знаю. Вам делать больше нечего? Или просто поучать нравится?
Shifty_Fox
Не нравится, честно честно.
Нравится разбираться и искать истину. Дух сообщения не в инкапсуляции же был, а в том, что она — действительно ключевой момент ООП, а shared state — вообще не момент из ООП, и никак к нему не относится.
Nakosika
Ясли я сделаю все методы и данные пабликом — моя ООП программа автоматически не превратстся в ФП или в Процедурное. Очевидно?
Shifty_Fox
Конечно.
Она перестанет быть ОО, если в паблик попадут скрытые методы и данные, т. к. в процессе написания кода разработчик справедливо будет использовать публичные функции и данные, которые для этого не предназначены, и полезут UB.
vintage
Не перестанет.
Shifty_Fox
Я соглашусь, что это получится ОО с ошибками.
vintage
Сколько можно путать сокрытие и инкапсуляцию...
И нет, ошибочный ООП код не перестаёт быть ООП.
Shifty_Fox
Да не путаю я, в контексте ООП сокрытие часть инкапсуляции. С остальным согласен.
vintage
Совершенно не обязательная часть.
Shifty_Fox
Да!
Nakosika
То есть вы узнаете ООП код, даже если из него будут удалены все модификаторы private, хоть и назовете его не православным. Отлично.
Следовательно, инкапсуляция не является *обязательным* свойством ООП.
Поедем дальше. Что если я заменю все наследование в ООП коде на композицию, согласно с современным best practices — «favor composition over inheritance»? Вы узнаете ООП и в этом случае, не так ли?
Но еще остался полиморфизм. Мы уже удалили все наследование, соответственно в небольшом количестве мест где нам действительно нужен полиморфизм, мы использовали интерфейсы. Интерфейс — это всего лишь таблица с функциями, не так ли? Можно ли назвать любое место где используются таблицы с функциями — ООП? Конечно нет.
Но после всех этих трансформаций вы все еще можете распознать ООП в оригинальном приложении, не так ли? Вот объект Окно, у него есть положение, оно может передавать сообщение о том что пользователь нажал крестик другим объектам… По каким признакам вы узнаете ООП? Эти признаки и есть *настоящее определение ООП*, а вовсе не эти три пункта, которые вы копипастите. ;)
Настоящее определение ООП — это представление предметной области в виде групп переменных и функций, и эти группы (объекты) взаимодействуют путем отправки друг другу сообщений (вызывают функции друг друга).
Shifty_Fox
Смотрите, если у объекта Окно будет функция открытьДверь, а у Двери функция открытьЖалюзиОкна, т.е. бессвязная мешанина данных и функций, и нет такого, что группе функций сопоставляется один объект, я не распознаю ООП.
А вот объединение функций в группы — и есть инкапсуляция. В любом коде с объектом и методами будет инкапсуляция.
Предпочитать композицию хорошо, но что делать, если уже есть компонент VelocityComponent, и нам нужен (правда правда, мы в игре совершенствуем физику, и нам нигде не нужен VelocityComponent, зато нужен будет SuperVelocityComponent. И вот здесь, в терминах композиции я буду вынужден с нуля описывать SuperVelocityComponent, или как-то хитрить, и делать объект, у которого VelocityComponent это поле, и он просто проксирует через свои методы все все методы этого компонента, но суть будет все равно в том, что для правильной архитектуры нам будет нужно наследование для такой операции. Вы можете искуственно ограничить себя и сказать — без наследования все равно ООП но мне правда кажется что нет. То есть вот она, программа — код написан, и он работает, но именно из за отсутствия возможности расширять код дальше через наследование — убивает для меня объектную природу этого кода. Она становится компонентной, если позволите.
Полиморфизм. Интерфейсы. Можно ли назвать таблицу с функциями полиморфизмом? Нет, ведь таблицы бывают разные, но та таблица с функциями, которая в зависимости от типа отдает разные функции — реализация полиморфизма с одним аргументом.
vintage
Это и есть суть инкапсуляции, а не "модификаторы private".
Nakosika
Вы правы, у меня была другая дефиниция инкапсуляции. Да, инкапсуляция — необходимый элемент ООП.
Nakosika
Как быть с ООП языками, которые не имеют инкапсуляции?
vintage
Что за ООП язык без инкапсуляции?
Nakosika
Python
vintage
Там всё в порядке с инкапсуляцией.
Shifty_Fox
Очевидно, они не ООП.
Но вообще-то, поддержка инкапсуляции на уровне компилятора совершенно не обязательна. Достаточно code style нотации — к примеру ставить __ перед приватными членами и методами.
vintage
Это динамическая диспетчеризация. Полиморфизм — возможность передавать аргументы разных типов.
Это сокрытие. Инкапсуляция — объединение данных и функций для работы с ними в одной капсуле — объекте.
vintage
Вас кто-то заставляет шарить мутабельное состояние?.
Veikedo
У вас, видимо, неправильный ООП
Wriketeam
На Jpoint был любопытный доклад на этот счет
Nakosika
Читал этого блоггера — он просто каждую функцию оборачивает в объект (называет это декораторами), вот и весь его ООП. Причем тут ООП вообще? Это ФП с кучей синтаксического мусора и кривой типизацией.
Посмотрел лекцию. Аргументация хромает. Почему, к примеру, getPath нельзя, а getContent можно? Статические функции — зло? Я знаю почему *иногда* это зло (если статическая функция меняет внешние переменные), но аргументация в лекции основана на «это устарело». Мы где-то это слышали — 3.5мм джек устарел. Поэтому мы будем использовать переходники, это современно и элегантно (см «Элегантные объекты»).
x07
Хотелось бы узнать подробнее про серверную часть.
Wriketeam
Если сформулируете конкретные вопросы, нам будет проще.
x07
Что представляет из себя компонент, который вы зарелизели(это какой-то API, связующее звено между внутренними компонентами, модуль который выполняет математические операции, анализ, работа с бд или что), вы полностью его переписали на Dart или он по прежнему гибридный(java,nodejs… и что еще у вас)?
Что нужно для того что бы запустить на сервере код который написан на Dart?
Можно ли написать на Dart, полноценное API к приложению?
bunopus
Давайте по-порядку:
У нас есть такая штука, как одновременное редактирование задач. Как в google документах, видно кто и что сейчас пишет, есть маркеры и пр. В основе лежит парадигма Operation Transformation. Как раз backend часть этой фичи и написана на Dart. Вкратце приложение общается с MongoDB и Postgress и с клиентом по websockets и передаёт туда-обратно данные
Код в основном на Dart, есть небольшие модули на node, но в скором времени и их не будет
Поставить Dart
Не очень понимаю, к какому, но да, ничто не мешает это сделать. Есть такая штука Aqueduct
mezastel
Строго говоря, есть предостаточно компаний, которые используют нишевые языки, и используют их успешно. На ум приходит Jane Street Capital и их использование OCaml. До сих пор остались компании, которые использую APL — язык, который требует отдельную клавиатуру:
Ну и так далее. Я к чему — все это не показатель. То есть, мы рады за вас то у вас все полуается, но…
Wriketeam
Чем, по-вашему, нишевый язык отличается от не нишевого?
mezastel
Количеством ресурсов, которые сидят на этом языке. Например, на OCaml в какой-то момент был один человек. Это значит что если у тебя серьезная проблема с языком (например, констукт синтезирует неправильный байткод), тебе могут быстро ответить и пофиксить, или же такой возможности вообще не существует.
Wriketeam
А если в цифрах? Где грань между нишевым и не нишевым?
ruslanfedoseenko
Пытался посмотреть в сторону Dart. Не нашёл какой-либо библиотеки компонентов. Смотрел angular.dart.ui он в довольно за атомной состоянии. Подсаажите чем вы пользуетесь?
ruslanfedoseenko
Извиняюсь пишу с телефона. Имелось в виду что angular.dart.ui в зачаточном состоянии.
alexalv
Недавно начал знакомиться с Flutter, пока впечатления намного лучше, чем от React Native.
eugenk
Пишу статью сравнивающую Dart и Scala.js. Надеюсь подойти к вопросу максимально объективно и непредвзято, хотя Scala нравится мне всё-таки больше. Сейчас на недельку-две отбываю на дачу по случаю летнего времени. Но к середине июля надеюсь всё-таки опубликовать.
Wriketeam
Если будут нужны консультации по Dart, пишите в direct message или Dart Slack канал
eugenk
Спасибо, хотя пока у меня куда больше вопросов по Scala. Оба языка я изучаю с нуля, одновременно с написанием статьи и небольшого, однако вполне реального и применимого на практике проекта на обоих языках сразу, на котором я их сравниваю. Но Dart вобщем-то почти ничего нового для меня не содержит. Это скорее даже старый знакомый С++ чем Java. Ну есть конечно отдельные вкусняшки типа именованных параметров. А вот Scala там да… Только что например с удивлением узнал, что там существует такая штука как Function0. Причём не просто для галочки, а некоторые методы библиотеки scalajs.dom требуют именно её в качестве обработчика. И не удовлетворяются обычными определениями через def, возвращающими Unit. Смысл этого мне абсолютно непонятен, однако медицинский факт! Вобщем чем дальше в лес, тем толще партизаны :)))
senia
Обращайтесь если что.
Function0 — функция арности 0 (количество аргументов = 0).
Аналог Supplier в java 8. Сокращенная запись () => T, но можно записать и как Function0[T] (не ясно, правда, зачем). https://scalafiddle.io/sf/qs25LOB/1:
eugenk
Я это понял как функция не возвращающая вообще ничего. Даже Unit. Почему и дико удивился. Тем не менее нужное определение сделал и этот код у меня прекрасно работает. Но как говорится «осадочек остался» :))) Надо будет проверить в Jupyter, что же такое я определил. Пока явных преимуществ Scala перед Dart мне обнаружить не удалось, хотя сам я болею за Scala. Пока единственный интересный момент — классы, определяемые внутри функции. Возникла необходимость написать функцию, принимающую простые параметры, но довольно сложно их обрабатывающую. Для этого было удобно ввести некий класс, не нужный нигде за пределами этой функции. На Scala я это сделал сходу, определив класс внутри функции. А вот с Dart-ом ломаю голову что лучше, выносить этот код в отдельную библиотеку или обрабатывать всё как List.
P.S. Увы, сегодня в 11 вечера по Москве отбываю на дачу. Появлюсь не раньше чем через неделю.
senia
У вас какой бэкграунд?
Просто scala.js отлично подходит тем, кто уже залез в глубины scala и не готов расставаться. А вот для изучения… безумству храбрых поем мы песню =).
Преимущества scala.js проявиться могут либо в единой кодовой базе с BE на jvm, либо в хардкорном метапрограммировании, либо в не менее хардкорном FP с вложенными монадами и прочими прелестями. Еще опция — формализация вашей задачи и описание в виде DSL.
Для всего этого надо быть scala спецом, решившим покодить под FE, а не наоборот.
А вот что с нуля вам предложить как киллерфичу scala.js я даже не представляю.
senia
Презентация по scala.js от SAP. Возможно вам поможет.
Riim
Может сразу и Kotlin.js захватите?
eugenk
Kotlin я первоначально рассматривал. Но пришел в ужас, когда увидал что простейшая hello world тащит за собой библиотеку весом без малого полтора мегабайта. Вообще у меня сейчас задача выбора языка для предстоящего довольно большого проекта. И я решил предварительно сделать небольшой, однако вполне практический проект на нескольких языках, чтобы выбрать лучший для большого. Раньше писал на typescript но он никогда мне особо не нравился и сменить его я уже давно намеревался. А тут и повод. Вобщем случилось так, что из претендентов остался только один Dart. Я уже плюнул на всю затею и начал писать на Dart-е, когда совершенно случайно узнал от любимого Хабра про Scala.js. Короче сейчас у меня чемпионат из двух участников. Причем и Dart и Scala я изучаю с нуля :)