Как стать автором
Обновить

Комментарии 87

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

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

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

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


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

С# мультипарадигменный, но и, если мне конечно память не изменяет, вроде про ООП. Какой получится код — плохой или хороший?
НЛО прилетело и опубликовало эту надпись здесь

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Да не путаю я, в контексте ООП сокрытие часть инкапсуляции. С остальным согласен.

Совершенно не обязательная часть.

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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


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

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


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

Поставить Dart


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

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

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

image

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

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!" })
Я это понял как функция не возвращающая вообще ничего. Даже Unit. Почему и дико удивился. Тем не менее нужное определение сделал и этот код у меня прекрасно работает. Но как говорится «осадочек остался» :))) Надо будет проверить в Jupyter, что же такое я определил. Пока явных преимуществ Scala перед Dart мне обнаружить не удалось, хотя сам я болею за Scala. Пока единственный интересный момент — классы, определяемые внутри функции. Возникла необходимость написать функцию, принимающую простые параметры, но довольно сложно их обрабатывающую. Для этого было удобно ввести некий класс, не нужный нигде за пределами этой функции. На Scala я это сделал сходу, определив класс внутри функции. А вот с Dart-ом ломаю голову что лучше, выносить этот код в отдельную библиотеку или обрабатывать всё как List.
P.S. Увы, сегодня в 11 вечера по Москве отбываю на дачу. Появлюсь не раньше чем через неделю.
У вас какой бэкграунд?

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

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

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

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

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

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

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

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

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

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