Scala — всё по этой теме для программистов


Оглавление (нажмите, чтобы открыть):

Записки программиста

Мои впечатления от языка Scala после года работы с ним

19 августа 2015

Со Scala я начал играться еще в марте 2013-го года. Но тогда я писал на ней только hello world’ы на 100-200 строк кода. Писать настоящий, боевой, код на Scala я начал только год назад. Само собой разумеется, это совсем другой опыт по сравнению с написанием hello world’ов. В данной заметке я поделюсь своими впечатлениями от использования Scala, расскажу про сильные и слабые стороны языка, и так далее.

  • Строгая статическая типизация с автоматическим выводом типов, как в Haskell или SML. Ощущения от программирования такие же, как от программирования на Haskell — если программа компилируется, в ней вряд ли есть ошибки. Особенно, если указать побольше флагов -Y, придающих языку дополнительную строгость. О пользе типов в этом блоге было сказано немало, см например раз и два, поэтому не будем подробно останавливаться на этом пункте;
  • Несмотря на строгость, пишется на языке так же легко и приятно, как на скриптовых языках. Про Haskell я определенно не могу сказать того же;
  • Очень приятный и лаконичный синтаксис. Это особенно хорошо заметно в книге «Learning Spark», где приводятся примеры кода на Java, Scala и Python. Код на Scala всегда получается той же длины, что и код на Python, и раза в два короче, чем код на Java. При этом код на Scala и Python намного более читаем;
  • Функциональное программирование с неизменяемыми переменными, лямбдами, замыканиями, кортежами, списками и так далее. За счет повсеместного ФП код становится намного проще поддерживать, плюс существенно упрощается написание многопоточного кода;
  • Раз заговорили о многопоточности, то тут есть акторы, которые оказались прямо-таки ничем не хуже акторов в Erlang. В отличие от подхода с мьютексами и атомарными переменными, писать многопоточный код на акторах — одно удовольствие. Гонки, дэдлоки и многие другие проблемы уходят сами собой. Также акторы дают программисту множество удобных готовых примитивов — наблюдение за другими акторами, шедулеры, сброс состояния в случае возникновения непредвиденных ошибок (let it crash). Без акторов все это очень быстро придется изобретать самостоятельно;
  • Судя по синтетическим и ничего на практике не означающим бенчмаркам, язык числодробит не хуже, чем Java. Это действительно здорово, когда твой код получается достаточно быстрым с первого раза. Не нужно постоянно искать узкие места и подпирать их написанием половины проекта на основном языке, а половины — на Си;
  • За счет паразитизма на JVM язык имеет не только мощный GC, JIT-компилятор и кроссплатформенность, но и великое множество готовых библиотек практически на все случаи жизни, а также кучу крутых инструментов разработки, например, YourKit;
  • Широкая область применения. Компилятор Scala написан на самой Scala. Достоверно известно об успешном применении Scala не только при написании веба и бэкендов, но и десктоп-приложений, а также мобильных приложений под Android. Вероятно, можно писать и под iOS, используя RoboVM, но о реальных случаях использовании Scala для решения этой задачи мне не известно. Еще, говорят, можно писать фронтэнды на Scala.js. Мне даже рассказывали о создании при помощи Scala.js кроссплатформенных мобильных приложений по принципу SPA. Но сам я пока Scala.js не пробовал, так что не могу сказать, насколько хорошо или плохо получается;
  • Язык не ограничивает выбор программиста небольшим набором «правильных» средств, которые предположительно должны одинаково хорошо решать все задачи. Если задача хорошо ложится на акторы, используем акторы. Но также можно использовать мьютексы, атомарные переменные, агенты, volatile переменные, параллельные коллекции или, например, STM. После Erlang, в котором без плясок с бубнами даже обычный LRU-кэш написать нельзя, это просто прекрасно. Аналогично, там, где это удобно, пишем в функциональном стиле, иначе пишем в императивном. Если же вдруг задача хорошо ложится на ООП, то можно воспользоваться и ООП. А еще на всякий случай есть рефлексия, макросы, аспекты и другие средства. Считаю, что это примерно как cherry-pick в Git, или возможность менять размер шрифта в терминале. Большинству людей никогда не понадобится, но иногда может сэкономить целые дни работы и кучу нервов;
  • Слухи о медленной компиляции и тормознутости IDE оказались сильно преувеличены. В частности, на Scala можно без проблем писать реальный, большой, проект на слабеньком ултрабуке, купленном 2.5 года назад, я проверял. Сборка проекта с нуля занимает 2 минуты. За счет инкрементальной сборки обычно компиляция происходит за пару секунд. Если же проект очень крупный, его всегда можно разбить на артефакты, ну или микросервисы. На практике куда более серьезной проблемой, чем время компиляции, является долгий прогон тестов. Следует также учитывать, что, как отмечалось выше, 1000 строк кода на Scala соответствует примерно 2000 строкам кода на Java, что нужно принимать во внимание при сравнении скорости компиляции;
  • Опять таки, вопреки слухам, язык совсем не сложный. Я бы сказал, в отношении Scala путают сложность языка и большое пространство возможных решений конкретной задачи на этом языке, потому что, как было отмечено выше, Scala не говорит вам «используте только акторы и ФП». Это хорошо, потому что множество удачных решений в узком пространстве поиска является подмножеством удачных решений в более широком пространстве. То есть, в более широком пространстве можно найти такое хорошее решение, какого совсем нет в более узком пространстве. Единственная проблема заключается в том, что на выработку хороших эвристик для поиска в широком пространстве требуется немного больше времени. Но это никак не относится к сложности языка. Scala — простой язык, не сложнее, скажем, Python. При этом кривая обучения у Scala довольно пологая, чего не скажешь, например, о том же Haskell;
  • Зрелость языка. Отличные инструменты разработки, не исключая полноценной IDE, куча готовых библиотек как из мира Java, так и собственных, множество саксес сторис, большое сообщество программистов, книги и документация, широкий выбор вакансий — все в наличии;

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

  • На границах взаимодействия с Java-кодом может возникать NPE. Приходится писать небольшие пакеты-обертки с Option и try-catch. Это небольшая проблема, так как все NPE отлавливаются еще во время разработки и тестирования. Но лучше бы их, конечно, совсем не было;
  • Если вы раньше никогда не работали с футурам и Akka, то можете очень легко наплодить гонок, сделать блокирующий вызов на общем тредпуле или забить тредпул футурами по одному запросу, из-за чего остальные запросы начнут тормозить. Это тоже небольшая проблема, так как она полностью устраняется повсеместным использованием for comprehensions, созданием отдельных пулов для блокирующих вызовов и тяжелых вычислений, оборачиванием обработчиков сообщений у акторов в небольшие вспомогательные методы, использующие become и stash, использованием «медленного» treverse, и так далее. Но если заранее не знать про все эти проблемы, можно собрать гору граблей. Лучше бы этих проблем, опять таки, совсем не было, как, например, их нет в Go или Erlang;
  • Все-таки, было бы круто иметь скорость компиляции, как в Go, а также > -Xfatal-warnings ;
  • Куча всяких мелочей. Со scalable синтаксисом не все и не всегда гладко. Скажем, можно забыть написать new. Код тайпчекнится и скомпилируется, потому что в результате будет вызван метод apply у companion object. Но в рантайме программа упадет с очень странным исключением. Еще в Scala есть метод без скобочек def x , есть метод со скобочками def y() и есть метод принимающий Unit def z(t: Unit) , все это немного разные вещи. Также есть structural typing и атомы, как в Erlang или Lisp, но на практике их почти никто и ни для чего не использует. По умолчанию все методы public (почему так сделано). Deb-пакеты получаются большими, 50-70 Мб считается здесь абсолютно нормальным размером. Ну и другие такого рода вещи;

Думаю, что нет такого языка, который нравился бы абсолютно всем. Каждый программист имеет собственную уникальную функцию от многих аргументов, определяющую fitness языка для разных классов задач. Для кого-то все решает красота и декларативность языка. Есть и такие, для кого решающим фактором является наличие remsh. Что до меня, то моя функция включает в себя такие параметры, как (!) возможность быстро и качественно решать задачи, которыми обычно я занимаюсь, скорость выполнения программ, наличие строгой статической типизации, наличие библиотек и инструментов разработки, возможность нанять где-то программистов на этом языке и самому устроиться куда-нибудь программистом на нем. А также другие. На данный момент для Scala значение моей функции fitness для решаемого мной класса задач имеет наибольшее значение по сравнению со всеми другими языками, которые я пока что видел. Более того, сейчас я с трудом представляю язык, значение функции fitness для которого было бы существенно выше.

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

Функциональное программирование вместо объектно-ориентированного

Разбираемся — как Scala использует преимущества обоих миров

Серия контента:

Этот контент является частью # из серии # статей: Путеводитель по Scala для Java-разработчиков

Этот контент является частью серии: Путеводитель по Scala для Java-разработчиков

Следите за выходом новых статей этой серии.

Вы никогда не забудете свою первую любовь.

В моем случае ее звали Табинда (Бинди) Хан. Это были безмятежные годы моей юности, седьмой класс, если быть точным, а она была красива, смышлена и, что самое замечательное, она хохотала над моими неуклюжими подростковыми шуточками. Мы «запали» друг на друга (как это тогда называлось), со взлетами и падениями в отношениях, длившихся преимущественно в 7 и 8 классах. Но к 9 классу мы расстались, это было вежливым способом сказать, что ей надоело на протяжении двух лет выслушивать однообразные и нескладные юношеские хохмы. Я никогда ее не забуду (не в последнюю очередь потому, что мы столкнулись друг с другом снова на 10-летней встрече одноклассников), но что более важно — я никогда не расстанусь с этими заветными (если несколько преувеличить) воспоминаниями.

Об этой серии

Тед Ньювард погружается в язык программирования Scala и берет вас с собой. В этой новой серии от developerWorks вы узнаете вокруг чего поднята такая шумиха и увидите некоторые лингвистические возможности Scala в действии. Код Scala и код Java будут показаны бок о бок, если таковое сравнение будет важно, но (как скоро выяснится) многие вещи в Scala не могут быть напрямую соотнесены с чем-либо таким, что вам знакомо из Java-программирования, но в этом и заключается основное очарование Scala! В конце концов — если Java-код способен это сделать, зачем же утруждать себя изучением Scala?

Java-программирование и объектная ориентированность стали первой любовью для многих программистов, и мы принимаем это с таким же уважением и полным благоговением, как и мое отношение к Бинди. Некоторые разработчики скажут вам, что Java-программирование уберегло их от адских мук в преисподней, порождаемой управлением памятью и C++. Другие скажут, что Java-программирование возвышает их над пучиной процедурной безысходности. Найдутся даже такие разработчики, для которых объектно-ориентированное программирование в Java-коде просто является «изначальной данностью этого мира» (а как же иначе — ведь это работало и при моих предках и при их предках до них самих!)

Однако, время неизбежно преодолевает все первые влюбленности и наступает момент двигаться дальше. Чувства изменились а участники этой истории стали зрелыми (и, будем надеяться, подучили несколько новых шуток), Но более значимо — изменился мир вокруг нас. Многие Java-разработчики осознают, что как бы мы ни любили Java-программирование, пришло время выдвигаться к новым горизонтам на наших «девелоперских» просторах и выяснить, как мы можем все это постичь.

Я буду любить тебя всегда .

В течение последних пяти лет обозначилась нарастающая волна недовольства языком Java. В то время, как кое-кто может указать на развитие Ruby on Rails как на основной фактор в этом смысле, я приведу доводы что RoR (в нотации, знакомой поклонникам Ruby) является следствием, а не причиной. Или же, выражаясь точнее, докажу, что факт восприятия Java-разработчиками Ruby следует из глубинной, более скрытой причины.

Попросту говоря, в программировании на Java проступает возраст.

Или, что будет точнее, возраст проступает у языка Java.

И действительно: когда язык Java впервые появился на свет, Клинтон (в свое первое президентство) восседал в офисе, а Интернетом регулярно пользовались лишь настоящие энтузиасты, главным образом потому, что соединение по телефонной линии было единственным доступным способом в домашних условиях. Блоги (сетевые дневники) еще не были изобретены, и все верили, что наследование является фундаментальным подходом в повторном использовании. Мы также верили, что объекты являются наилучшим способом моделирования мира и что Закон Мура будет всегда господствовать экспоненциально.

На самом деле — именно законом Мура были в крайней степени озабочены многие в индустрии. С 2002/2003 доминирующей тенденцией в микропроцессорных технологиях было создание процессорных модулей с множеством «ядер»: в сущности, множества процессоров на одном чипе. Это позволяет обойти Закон Мура, который говорит, что скорость процессоров удваивается каждые 18 месяцев. Ситуация с многопоточными средами, исполняемыми на двух процессорах одновременно, вместо того, чтобы выполнять стандартный круговой цикл на едином процессоре, означает, что код должен быть непробиваемой глыбой с точки зрения потокобезопаности, коль скоро такой код претендует на существование.

В академическом сообществе предпринималось множество исследований касательно этой специфической проблемы, приведших к изобилию новоиспеченных языков. Существенным недостатком выступал тот факт, что большинство из этих языков надстраивались над своей собственной виртуальной машиной или интерпретатором, означая таким образом (как делает и Ruby) переход на новую платформу. Кризис параллелизма — настоящая головная боль и некоторые из новых языков предлагают мощные решения, но слишком много корпораций и предприятий помнят миграцию с C++ на платформу Java каких-то 10 лет тому назад. Перемещение на новую платформу — это риск, который многие компании даже не собираются рассматривать всерьез. Многие, в действительности, по-прежнему зализывают раны от последнего перехода на Java-платформу.

Знакомимся со Scala.

SCAlable LAnguage — Масштабируемый язык

Почему Scala?

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

  • Создавать внутренние DSL — типа Ruby, благодаря гибкой реализации идентификаторов в Scala.
  • Создавать в наивысшей степени масштабируемые, параллельные обработчики данных, благодаря тому, что Scala изначально стоит на позициях неизменяемости состояния.
  • Сократить размер эквивалентного Java-кода в половину или на две трети, из-за обилия в Scala синтаксических приемов, таких как замыкания и неявные определения.
  • Использовать преимущества параллельных аппаратных архитектур (таких как многоядерные процессоры), т.к. Scala предрасполагает к функциональному дизайну.
  • Контролировать большие объемы кода, из-за упрощения в Scala правил жесткого типизирования, выставляющих, по существу, одно требование — «все является объектом.»

Несомненно — Scala олицетворяет мощный, новый взгляд на программирование; факт компиляции в код, совместимый для запуска под управлением JVM как нельзя лучше позволяет воспользоваться Scala для «настоящей работы», да еще с такой легкостью.

Scala — функционально-объектный гибридный язык с несколькими сильными сторонами, подогревающими интерес к нему:

  • Во-первых, Scala компилируется в байт-код Java, подразумевая его запуск на JVM. В дополнение к вашей возможности продолжать использовать все преимущества Java как развитой экосистемы с открытым кодом, Scala может быть интегрирован в существующее информационное пространство (среду) с нулевыми усилиями на миграцию.
  • Во-вторых, Scala опирается на функциональные принципы Haskell и ML, не отказываясь от тяжкого бремени привычных объектно-ориентированных концепций, столь полюбившихся Java-программистам. В результате Scala может смешивать лучшее из двух миров в единое целое, что предоставляет значительный выигрыш без жертвования простотой, на которую мы привыкли рассчитывать.
  • И в заключение, Scala был разработан Мартином Одерски, возможно, более известным в Java-сообществе благодаря языкам Pizza и GJ, последний из которых стал рабочим прототипом универсальных типов (generics) в Java 5. Раз так, Scala несет ощущение «серьезности»; этот язык не создавался по капризу и он не будет брошен на произвол.
Мастер Йода рекомендует:  MIT представил систему ComText, улучшающую понимание команд роботами

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

Загрузка и установка Scala

Вы можете загрузить комплект поставки Scala с домашней страницы Scala. Текущим на момент написания статьи релизом является 2.6.1-final. Он доступен в виде Java-инсталлятора, пакетов RPM и Debian, архивов gzip/bz2/zip, которые достаточно просто распаковать в целевую директорию, а также в виде исходного tarball, позволяющего выполнить сборку с нуля. (Версия 2.5.0-1 доступна для пользователей Debian с Web-сайта Debian в виде готового к употреблению инсталляционного модуля. Однако версия 2.6 имеет некоторые незначительные отличия, поэтому рекомендуется загрузка и установка напрямую с сайта Scala.)

Установите Scala в каталог по выбору — я пишу это, находясь в среде Windows®, поэтому у меня это будет каталог C:/Prg/scala-2.6.1-final. Задайте этот каталог в переменной окружения SCALA_HOME и добавьте SCALA_HOME\bin к PATH для упрощения вызова из командной строки. Для проверки вашей инсталляции просто запустите » scalac -version «. В ответ должно последовать » Scala version, 2.6.1-final «.

Функциональные концепции

Прежде, чем мы начнем, я представлю несколько функциональных концепций, необходимых для понимания того, почему же Scala ведет себя так, а не иначе. Если вам доводилось иметь дело с функциональными языками — Haskell, ML или же с недавним пополнением в функциональном мире — F#, вы можете переходить к следующему разделу.

Функциональные языки получили свое название из концепции, предполагающей, что программы должны вести себя как математические функции; другими словами, при заданном наборе входных параметров функция должна всегда возвращать один и тот же результат. Это не просто означает, что каждая функция должна возвращать значение, а и то, что эти функции не должны переносить никакого внутреннего состояния от одного вызова к другому. Такая основополагающая идея несохраняемости состояния, перенесенная в функциональный/объектный мир и означающая объекты, неизменяемые по своей природе — главная причина того, почему функциональные языки провозглашаются великими спасителями безумно параллельного мира.

В отличие от многих динамичных языков, с недавних пор начавших отвоевывать себе пространство на платформе Java, Scala является статически типизированным, как и Java. Однако, в противовес платформе Java, Scala прилагает существенные усилия к использованию выведения типов (type inferencing), означающего, что компилятор выполняет глубокий анализ кода для выяснения типа конкретного значения, без вмешательства программиста. Выведение типа требует меньшей избыточности в типизации кода. Например, рассмотрим приведенный в листинге 1 Java-код, необходимый для объявления локальных переменных и присвоения им значений:

Листинг 1. Ох уж этот гениальный javac .

Scala не нуждается в таком расписывании, как и будет показано далее.

Множество прочих функциональных особенностей (таких как сопоставление с шаблоном — pattern matching) проложили себе путь в Scala, но полное их перечисление было бы забеганием вперед. Scala также добавляет некоторое количество деталей, отсутствующих на данный момент в Java, скажем, перегрузка оператора — operator overloading (являющаяся, как оказывается, тем, что Java-программисты вообще не могут себе вообразить), универсальные типы (generics) с «верхним и нижним ограничениями по типу», виды (views) и многое другое. Эти особенности, среди прочего, делают Scala чрезвычайно мощным для решения такого рода задач, как обработка или генерация XML.

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

Приступаем

Наша первая Scala-программа будет стандартной демонстрационной программой, Hello World, как того требуют Боги Компьютерных Наук:

Листинг 2. Hello.Scala

Скомпилируйте это вызовом scalac Hello.scala и запустите полученный код при помощи либо запускающего модуля ( scala HelloWorld ), либо используя традиционный запуск Java, не забыв включить библиотеку ядра Scala в JVM classpath ( java -classpath %SCALA_HOME%\lib\scala-library.jar;. HelloWorld ). В любом случае должно появиться традиционное приветствие.

Некоторые элементы в листинге 2 определенно вам знакомы, но также задействованы и некоторые явно новые. К примеру, начав с привычного вызова System.out.println , Scala демонстрирует свою дружественность к лежащей в основе платформе Java. Scala преодолевает огромное расстояние, чтобы обеспечить доступность всей мощи Java в Scala-программах. (В действительности, позволительно даже наследовать тип Scala от Java-класса и наоборот, но об этом позже).

С другой стороны, если вы внимательны, вы должно быть заметили отсутствие точки с запятой в конце вызова System.out.println — это не опечатка. В отличие от Java-платформы, Scala не требует точки с запятой для завершения оператора если это очевидно по факту окончания строки. Тем не менее, точки с запятой по-прежнему поддерживаются и являются иногда необходимыми если, например, физически в одной и той же строке присутствует более одного оператора. В большинстве случаев, прогрессирующие Scala-программисты могут опускать точки с запятой, а компилятор Scala ненавязчиво напомнит вам (обычно посредством броского сообщения об ошибке), когда такой разделитель будет необходим.

К тому же, хотя это и второстепенная мелочь, Scala не требует в названии файла, содержащего определение класса, отражать имя этого класса. Некоторые найдут в этом освежающее отличие от Java-программирования; а именно те, кто не может без проблем продолжать использовать принятое в Java класс/файл-соглашение об именовании.

Ну а теперь давайте взглянем на то, в чем Scala действительно начинает отклоняться от традиционного Java/объектно-ориентированного кода.

Функция и форма — наконец-то вместе

Прежде всего, приверженцы Java отметят, что вместо » class «, HelloWorld определен с использованием ключевого слова object . Это поклон Scala в сторону вездесущего шаблона Singleton — служебное слово object сообщает компилятору Scala, что это будет синглетон-объект, и в результате Scala гарантирует, что в любой момент времени будет существовать только один экземпляр HelloWorld . Обратите внимание — по той же причине main не определяется как статический метод, как это было бы в Java-программировании. Фактически Scala избегает использования » static » вообще. Если же приложению необходимо иметь экземпляры некоторого типа наряду с его «глобальным» вариантом, приложение Scala позволит как определение class так и object для одного и того же имени.

Далее, посмотрите на определение main , которое, как и в случае Java-кода, является общепринятой точкой входа для Scala-программ. Это определение, хотя оно и выглядит отличным от такового в Java, идентично: main принимает массив строк в качестве аргумента и ничего не возвращает. Тем не менее, в Scala такое определение несколько отличается от Java-версии. Определение параметра args задано как args: Array[String] .

В Scala массивы представлены экземплярами обобщенного класса Array , кроме прочего демонстрирующего то, что Scala использует квадратные скобки («[]») вместо угловых («<>«) как признак параметризованных типов. Ну и, для полноты картины, отметим использование в языке шаблона » имя: тип «.

Как и в случае с другими функциональными языками, Scala требует, чтобы функции (в данном случае метод main) в обязательном порядке возвращали значение. Вот он и возвращает значение «не-значение», называемое Unit . В практическом смысле Java-разработчики могут думать о Unit как об аналоге void , по крайней мере, на данный момент.

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

Вы сказали замыкания?

Из того, что функции являются концепциями первого рода, вытекает необходимость представления их каким-либо образом в виде автономных конструкций, также известных как замыкания (closures) — понятие, столь горячо обсуждаемое последнее время Java-сообществом. В Scala это легко выполнимо. Прежде чем демонстрировать возможности замыканий, рассмотрим простую программу в листинге 3. Здесь функция oncePerSecond() повторяет свою логику (в данном случае — печать в System.out) каждую секунду.

Листинг 3. Timer1.scala

К сожалению, именно этот код вообще не является функциональным . или хотя бы практичным. Например, если бы я захотел изменить текст выводимого сообщения, мне бы пришлось изменить тело метода oncePerSecond . Рядовой Java-программист определил бы в oncePerSecond параметр с типом String для передачи такого сообщения. Но даже такой подход крайне ограничен: Любая другая периодическая задача (допустим, пингование удаленного сервера) будет нуждаться в своей собственной версии oncePerSecond — что является прямым нарушением правила «Не повторяйся». Как показано в листинге 4, замыкания предлагают гибкую и мощную альтернативу:

Листинг 4. Timer2.scala

Теперь ситуация становится интереснее. В листинге 4 функция oncePerSecond принимает параметр, но его тип выглядит странно. Формально, в качестве значения параметра callback принимается функция. Это справедливо до тех пор, пока передаваемая функция сама не имеет входных параметров (обозначено как «()»), и возвращает (обозначено «=>») «ничего» (функциональное значение «Unit»). Далее обратите внимание — в теле цикла я использую callback для вызова переданного в параметре объекта-функции.

К счастью, где-то в программе у меня есть такая функция, а именно timeFlies . Поэтому я просто передаю ее в oncePerSecond при вызове из main . (Вы также заметите, что в timeFlies задействован Scala-специфичный класс Console , служащий для той же цели, что и System.out или же новый класс java.io.Console . Это чисто эстетический вопрос; здесь будут работать и System.out и Console .)

Анонимная функция, какова же твоя функция?

Сейчас функция timeFlies выглядит как нечто бесполезное — после всех усилий у нее, на самом деле, нет другого назначения, как только быть переданной в oncePerSecond . Раз так, я бы вообще не хотел формально ее определять, как показано в листинге 5:

Листинг 5. Timer3.scala

В листинге 5 функция main передает произвольный блок кода в качестве параметра oncePerSecond , это выглядит как лямбда-выражение из Lisp или Scheme, что, само по себе, является другой разновидностью замыкания. Такая анонимная функция опять демонстрирует мощь отношения к функциям как к гражданам «первого сорта», позволяя вам обобщать код таким совершенно новым способом, не прибегая к механизму наследования. (Поклонники шаблона Strategy, вероятно, уже начали неконтролируемо исходить слюной.)

Но на самом деле, oncePerSecond по-прежнему специфична: она завязана на неразумное ограничение в том, что callback будет вызываться каждую секунду. Я могу дальше продвинуться в обобщении, указав второй параметр, задающий — как часто вызывать переданную функцию, что и показано в листинге 6:

Листинг 6. Timer4.scala

Это распространенная практика в функциональных языках: создать абстрактную функцию верхнего уровня, выполняющую некоторую работу, передать в нее блок кода (анонимную функцию) как параметр, и вызвать этот блок кода внутри высокоуровневой функции. Например, при переборе коллекции объектов. Вместо использования в цикле традиционного для Java объекта-итератора, функциональная библиотека предлагает взамен функцию — обычно называемую «iter» или «map» — в коллекционных классах она принимает функцию с одним параметром (объектом, подлежащим итерированию). Таким образом, например, упомянутый ранее класс Array содержит функцию filter , определенную в листинге 7:

Листинг 7. Часть листинга Array.scala

Листинг 7 декларирует, что p — функция, принимающая параметр обобщенного типа A и возвращающая логическое значение. Документация Scala утверждает, что filter «возвращает массив, состоящий из всех элементов исходного массива, удовлетворяющих предикату p.» Это значит, что если я захочу на мгновение вернуться к моей программе Hello World и найти все аргументы командной строки, начинающиеся с буквы «G», это будет записано как в листинге 8:

Листинг 8. Привет, люди-G!

Здесь filter принимает предикат — анонимную функцию, неявным образом возвращающую логическое значение boolean (как результат вызова startsWith() ) и вызывает этот предикат для каждого элемента в массиве » args «. Если предикат возвращает истина, filter добавляет такой элемент в результирующий массив. После перебора всего массива, результирующий массив возвращается и немедленно используется в качестве исходного для вызова » foreach «, который выполняет именно то, что предполагает: foreach принимает другую функцию и применяет ее к каждому элементу массива (в данном случае — просто отображает в консоль)

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


Заключение

Программирование в Scala подкупающе просто и в то же время — необычно. Его простота в том, что вы продолжаете работать с теми же базовыми объектами Java, знакомыми и любимыми вами на протяжении многих лет, а очевидное отличие — в способе, которым вам предлагается осмысливать нисходящую декомпозицию программы на части. В этой первой статье из серии Путеводитель по Scala для Java-разработчиков я лишь бегло ознакомил вас с возможностями Scala. То ли еще будет, а пока — успешного «функционализирования»!

Разработка веб-приложений на Scala: среда разработки

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

Лично я — стандартный программист на Яве, в своё время для веб-разработки приноровился к JSP+Tomcat, с тех пор для для небольших эпизодических задач мне их вполне хватало. Но т.к. Сервер Роботов не просто крутится где-то в облаке, но и публикуется с исходным кодом в виде уроков, я не хотел использовать для него совсем уж откровенное (хотя и вполне актуальное) старьё, поэтому решил попробовать что-нибудь современное ультра-модное, но чтобы не совсем маргинальное. В этом смысле я уже давно посматривал в сторону функционального программирования вообще и Скалы в частности, теперь появился повод попробовать ее на практике конкретно в области веб-разработки.

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

очевидно из трейлера:

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

Однако, для того, чтобы легко понимать программы, написанные на Скале (не говоря о том, чтобы писать), знания одной Явы может быть недостаточно. Множество новаций в Скале касаются именно синтаксиса. По моим первым впечатлениям, она старается быть настолько лаконичной, насколько это возможно. Программист может опускать разнообразные ключевые слова (например, не указывать тип данных при инициализации переменных, или даже не писать ключевое слово «return») — что именно имелось ввиду в каждом случае, будет пытаться понять из контекста компилятор. Явный плюс такого подхода — программы действительно получаются очень лаконичными, их (как я постепенно начал ощущать) довольно приятно писать, т.к. в коде можно набирать только то, что действительно важно. Побочный эффект такой лаконичности — при чтении чужого кода (примера из интернета или кода библиотеки) работу компилятора приходится осуществлять читающему человеку.

Лично у меня сходу не получилось вникнуть в смысл некоторых примеров кода на Скале, которые я рассматривал на старте, ни с первого, ни со второго раза, как это часто прокатывало с другими языками. Поэтому если вы начнете ощущать накатывающееся раздражение при просмотре некоторых фрагментов кода на Скале, которые будут приведены далее, из-за того, что вы непрерывно смотрите на эти три строчки уже восемнадцать минут и все равно не понимаете, что там, блин, написано, настоятельно рекомендую предварительно прочитать какую-нибудь вводную книгу по основам языка. Хороший вариант — «Функциональное программирование. SCALA для нетерпеливых.», Кей Хорстман (Cay Horstmann).

Или просто перепишите всё на своём любимом языке программирования.

Инструменты для разработки веб-приложений на Скала

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

Лично я остановился на простом тулките (наборе инструментов) для обслуживания HTTP-запросов Unfiltered. Хотя он в первую очередь предназначен для обслуживания HTTP-запросов в веб-приложениях, его вполне можно использовать для генерации и отдачи статических и динамических HTML-страниц, т.е. с его помощью можно создать и запустить полноценное веб-приложение.

Хорошее введение в философию Unfiltered (компактные модульные тулкиты против перегруженных фреймворков) и демонстрация его основных возможностей на слайдах:

Из моего личного опыта, обычно между написанием кода и развертыванием веб-приложения на сервере (быстрый запуск из среды разработки не в счет) существует некоторое количество промежуточных шагов, не слишком сложных и вполне механических, но часто утомляющих и не всегда очевидных (скопировать архив в определенное место в файловой системе, убедиться, что в конфигурационном файле прописаны нужные значения, проверить работу сервиса и т.п.). В случае с Unfiltered я впервые увидел, что разработка и запуск веб-приложения может выглядеть точно также, как разработка и запуск самого простого консольного приложения, только вместо System.in и System.out и окошка с чОрной консолью, для ввода-вывода здесь используется любой интернет-браузер со всей мощью HTML, JavaScript и CSS. Т.е. буквально, приложение стартует из милой сердцу main через «java -jar», далее ввод-вывод в любимом браузере на localhost:8080; только это и больше ничего. Дополнительные фичи и навороты (типа ORM или работы с шаблонами) подключаются к приложению по мере необходимости из сторонних библиотек, как это всегда происходило с любыми другими сторонними библиотеками.

Мастер Йода рекомендует:  Как подключить WordPress к облачным сервисам хранения

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

В Скале решили сделать инновационным не только сам язык, но и процесс разработки приложений. Я ожидал увидеть просто дополнительный плагин к Эклипсу или Нетбинзу, но вместо него в литературе и разных интернет-ресурсах подразумевается, что работа ведется в специальном консольном Интерпретаторе Скала, который может компилировать и запускать код строка за строкой прямо в процессе набора или типа того. Плагины для Эклипса (на Эклипсе основана среда Scala IDE) и Нетбинза (и IntelliJ IDEA) тоже есть.

Я люблю комбинацию среды Netbeans с проектами в формате Maven (теоретически их можно попробовать открыть и в Эклипсе с плагином Maven или вообще собирать без IDE через консольные инструменты Maven), поэтому попробовал сохранить ее и для Скалы.

Итого, нужно скачать Netbeans (вариант как минимум для Java SE). Плагин для поддержки проектов Maven должен входить в стандартный комплект (если нет, то его всегда можно установить из среды через меню Сервис/Подключаемые модули).

Дальше скачать с Гитхаба (спешите видеть, пока его опять не заблокировал Роскомнадзор) и открыть в Нетбинзе проект snippets/scala-web/ScalaUnfilteredBasicD emo.

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

Ссылки на все необходимые инструменты и зависимости для сборки проекта компилятором Скала с библиотеками Unfiltered при помощи средств Maven уже прописаны в файле проекта ScalaUnfilteredBasicDemo/pom.xml, в том числе там указаны адреса необходимых репозиториев (https://oss.sonatype.org/content/repositories/releases/ — и для Скалы и для Unfiltered), все библиотеки уже есть в центральном репозитории Maven Central, этот диалог выкачивает их оттуда (нужен интернет и место на диске).

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

Если в коде не будет найдено ошибок, в окне вывода можно будет увидеть зеленое сообщение BUILD SUCCESS . Это значит, что классы и исполняемые файлы уже готовы, их можно найти в каталоге проекта scala-web/ScalaUnfilteredBasicDemo/targe t.

В частности, там лежит исполняемый jar-файл scala-unfiltered-basic-demo-1.0-SNAPSHOT и рядом в каталоге lib находятся все необходимые для его запуска jar-библиотеки (их туда заботливо положил Maven, следуя инструкциям, прописанным во все том же pom.xml: плагины maven-jar-plugin и maven-dependency-plugin).

В целом, на этом этапе уже худо-бедно можно работать — редактировать код на Скале, компилировать его в jar-файлы и запускать их на сервере в облаке — это всё осуществляет Maven, а всё, что ему нужно — это правильный pom.xml. Но для более комфортной работы с исходниками на Скале (подсветка синтаксиса, автодополнение, запуск приложения из среды и т.п.) лучше поставить дополнительных плагинов. Для этого идем в меню «Сервис/Подключаемые модули», на вкладке «Доступные подключаемые модули» делаем поиск по ключевому слову «scala» и устанавливаем всё, что найдется.

После этого редактор кода начнет подсвечивать синтаксис в файлах *.scala.

Автодополнение тоже работает:

Запуск исполняемого главного класса (содержит функцию » def main ( args : Array [ String ])») из среды разработки при помощи предназначенной для этого большой зелёной стрелочки на панели инструментов не работает, среда почему-то не может найти в проекте главный класс:

Может быть эту проблему исправят в будущих версиях плагинов Scala для Netbeans, пока что пришлось с этим смириться. Тем более, что есть рабочий обходной вариант: кликнуть правой кнопкой мыши на файле scala, в котором определена функция main, и выбрать меню «Отладка файла».

Проект запустится в режиме отладки, меня это вполне устраивает.

Язык программирования Scala: скала, которую стоит покорить

Современные разработчики хотят от новых языков программирования краткости, понятности и типобезопасности. Именно таким был создан Scala. Впрочем, называть его новым не совсем верно – разработка Scala ведется уже 15 лет.

В июльском рейтинге RedMonk язык Scala занял 12 позицию. И это повод присмотреться к нему подробнее.

Общая информация

Scala – мультипарадигмальный язык программирования, который унаследовал изобразительные возможности от нескольких языков. Например, он напоминает и Java, и C#, но с гораздо большими возможностями.

Разработала Scala команда из Федеральной политехнической школы Лозанны под руководством Мартина Одерски. Он также занимался созданием Generic Java и компилятора Java фирмы Sun. В 2001 году Одерски решил создать типобезопасный язык для решения научных задач и улучшить языковую поддержку компонентного программного обеспечения.

В 2003 году создатели выпустили первый внутренний релиз, в январе 2004 года представили первую версию для общего пользования на платформе JVM (Java Virtual Machine – виртуальной машины Java). В 2006 году появилась Scala 2.0. В июне 2004 года Scala вышел на платформе .NET. С 2012 года поддержка этой платформы прекращена. Полноценный нативный LLVM-компилятор (Scala Native) был представлен лишь в 2020 году.

Разработчики преследовали две основные цели:

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

Масшабируемая поддержка компонентов: унификация и обобщение функционального и объектно-ориентированного программирования.

Scala реализован для платформ Java и JavaScript. Разработчики верят, что он станет преемником Java, обеспечив возможность быстрого создания компонентного программного обеспечения благодаря типобезопасности, лаконичности и высокой мощности.

Компиляторы и библиотеки Scala распространяются под лицензией BSD (Berkeley Software Distribution license – программная лицензия университета Беркли).

Особенности

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

Но, в отличие от Java, в Scala объявляется не класс объекта, а сразу экземпляр объекта. Это естественная реализация шаблона проектирования Singleton («одиночка») – класса с единственным экземпляром.

Язык поддерживает абстракции типов и значений. К примеру, здесь есть гибкие симметричные конструкции примесей для композиции классов и типажей. Кроме того, доступны представления для внешних расширений компонентов (views) и поддержка обобщенных функций (generics), в частности, дженериков высшего типажа (generics of a higher kind). Views – очень мощный инструмент, полезный для интеграции. Он позволяет расширять класс новыми членами и типажами. Лаконичность кода на Scala можно продемонстрировать так:

Применение

На Scala созданы два крупных веб-фреймворка: Play и Lift. Play задействует платформы Coursera и Gilt, а самым популярным проектом на Lift является Foursquare. Кроме того, LinkedIn использует микрофреймворк Scalatra для поддержки своего Signal API.

Рывок популярности Scala обусловило и объявление Twitter в 2009 году: сервис микроблогов перевел с Ruby на Scala значительную часть серверного кода и продолжил работу в этом направлении. В 2011 году онлайн-версия газеты The Guardian была переписана с Java на Scala. Разработку на этом языке ведут Novell, Siemens, GridGain. Средство автоматической сборки Sbt, которое является одной из ключевых составляющих инфраструктуры разработки языка, также написано на Scala.

Так как Scala поддерживает «свободное смешивание» с Java, на нем можно писать Android-приложения. А возможность компиляции в JavaScript позволяет разрабатывать веб-приложения.

Почему Scala – выбор молодых и современных

Scala – считают академичным языком, писать на котором смогут немногие. Бытует мнение, что на Scala пишут «умники», а те, кто любит попроще, выбирают Python, Haskell или Erlang. Scala – достаточно сложный язык, но эта сложность позволяет реализовать высокую производительность и нестандартные решения на стыке функционального и объектно-ориентированного программирования.

На Scala будет просто перейти Java-разработчикам. Это прекрасный выбор и в качестве второго языка. 12 место в рейтинге RedMonk – отличный показатель популярности Scala. По сравнению с предыдущим кварталом 2020 года этот язык программирования улучшил свои позиции, поднявшись с 14 места. В других рейтингах позиции Scala не столь высоки: например, в списке TIOBE в мае 2020 года этот язык программирования оказался только 20-м месте. Правда, критерием для присвоения индекса служит количество поисковых запросов, содержащих название языка.

Еще один интересный показатель – «индекс предпочтения» GitHub, относительное количество пользователей языка, которые для следующего проекта в своей области выберут его же. Разочаровавшихся в Scala меньше, чем в Java или С++:

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

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

Java, Scala, Groovy и проч. что выбрать для разработки десктопа? [закрыт]

Есть запрос на написание десктопного мультиплатформенного приложения. Условие язык должен быть на платформе Java.

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

По C/C++/Perl и проч. просьба не умничать. У приложения есть довольно большой набор Java библиотек с бизнес-логикой, так что платформа строго Java — вариантов нет.

Закрыт по причине того, что не по теме участниками xaja, Kromster says support Monica, Cyrus, Kyubey, Владимир Мартьянов 6 ноя ’15 в 6:52 .

Похоже, этот вопрос не соответствует тематике сайта. Те, кто голосовал за его закрытие, указывали следующую причину:

  • «Вопросы-опросники запрещены на Stack Overflow на русском. Для получения ответа, перефразируйте ваш вопрос так, чтобы на него можно было дать однозначно правильный ответ.» – xaja, Kromster says support Monica, Cyrus, Kyubey, Владимир Мартьянов

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

3 ответа 3

  • Сами по себе Scala и Groovy пока не содержат в себе отдельных production-ready решений для GUI , кроме оберток над swing .
  • Если вы хорошо знакомы с Groovy / Scala (и если вы не единственный из команды, кто может этим похвастаться), то можете воспользоваться одним из этих подходов.

При этом, очевидно, стоит учитывать время на необходимость разобраться в деталях соответствующих оберток и возможные риски из-за их непродуманности или недоделанности. Очень обидно будет нарваться на UnsupportedOperationException(«Not yet implemented») в конце спринта.

  • Если нет, а выбор между vanilla Java / Scala / Groovy появился только благодаря «модности» последних, то работайте через них с java.swing , либо вообще остановитесь на просто Java .

Лично я, не будь у меня как минимум года работы со Scala / Groovy / Clojure / Kotlin , не стал браться за разработку бизнес-решения на их базе.

Наткнулся сегодня на dzone на номер журнала Java Tech Journal, посвященный Groovy, а уже в нем на статью о Grails-подобной платформе для десктопных приложений Griffon.

Что дают (если верить статье):

  • Набор утилит командной строки для создания проекта, сборки, упаковки и деплоя
  • MVC
  • Bindings для свойств бинов
  • различные реализации непосредственно GUI (Swing, SWT, JavaFX)
  • расширяемость плагинами
  • Convention over Configuration, управление структурой и жизненным циклом приложения

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

Язык Scala, сложности поддержки Scala в > Курс Хит

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

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


В первой части, Павел Фатин рассказывает о своем опыте разработки на Scala и о том, когда стоит использовать этот язык.

Во второй части доклада, Александр Подхалюзин рассматривет различные подводные камни, с которыми может столкнуться Scala-программист. Также рассмотрены некоторые высокоуровневые языковые конструкции, внутреннее устройство которых может быть интересно (например, как они транслируются в байт-код). Кроме того, рассмотрена такая прикладная задача, как бинарная совместимость Scala-программ.
Кроме того, Александр Подхалюзин рассказывает о своём опыте разработки Scala plugin для IntelliJ IDEA и в частности:

  • компилятор как спецификация: cложности поддержки языка;
  • почему практически невозможно повторить анализатор Scala, а можно лишь написать его адекватное приближение;
  • почему в компиляторе не проходят некоторые implicits конверсии, которые, вроде как, должны бы проходить;
  • когда должен отрабатывать local type inference (вывод generic параметров по вызову), а когда нет;
  • можно ли обойти отсутствие в языке понятия функции второго порядка с переменным числом параметров.

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

В третьей части, Дмитрий Найданов рассказывает о поддержке Play Framework 2.0 в IntelliJ IDEA.

Функциональное программирование со Scala: введение

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

Классические программы порождают концептуальные ограничения на использование модульной организации. Функциональные языки минимизируют эти ограничения. — Джон Хьюз, «Почему функциональное программирование значимо»

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

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

Почему Scala?

Scala – это язык с полной поддержкой функционального программирования, а также объектно-ориентированной парадигмы. Это один из наиболее широко используемых языков в функциональном сообществе, на высоком уровне наряду с таким языками как F# и Haskell, Clojure и других. Scala исполняется на JVM и отлично сочетается с Java, Groovy, Clojure и т.д.

Чистые функции

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

Нечистые функции

Нечистые функции позволяют влиять на внешний и/или внутренний контекст.

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

Функции высшего порядка

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

  • принять функцию, вернуть значение
  • принять значение, вернуть функцию
  • принять функцию, вернуть функцию

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

Неизменяемость

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

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

Эти примеры сравнивают преимущества, предлагаемые Scala в отличие от объектно-ориентированного языка, подобного Java,

Монады в Scala

Монада — это интерфейс, который просто определяет единый формат для составления данных.

Монады должны подчиняться определенным правилам. Scala не столь строга с этими законами, а ее ориентированность более практична. С точки зрения языка единственными чертами, которые должна иметь Монада, являются функции высокого порядка flatMap и map. Они предоставляют инструмент для составления данных, которые в них содержатся, с помощью применения функции.

Вероятно, проще объяснить это на примере,

Представьте себе на мгновение, что все известные нам коллекции является Монадой (в терминах Scala). Тогда мы можем составлять внутренние данные в этих коллекциях просто с помощью функции map или flatMap.

Резюме

В этом сообщении просто описывается некоторые из наиболее важных аспектов функционального программирования на Scala. Существует множество тем, требующих изучения. Например, специфические для языка Монады (Option, Future & Try) или «for-генераторы»(«for-comprehension») и «применить» («apply») методы для упрощения программ.

Кроме того, важно узнать больше о некоторых из наиболее широко используемых фреймворках, таких как Play!, Finagle и Akka.

Я искренне надеюсь, что мне удалось вызвать у вас интерес к Scala и функциональному программированию.

О выборе языка программирования

Честно говоря, вопрос о выборе языка программирования предо мной не стоял никогда, иначе говоря, выбор языка программирования для меня всегда был очевиден. Я никогда не участвовал в холиварах типа C++ vs. Java, столь популярные в конце 90-х в том же Новософте. Действительно, когда на ты на собственной шкуре видишь увеличение продуктивности в разы, любые споры становятся бессмысленными.

Мастер Йода рекомендует:  Какие методологии разработки применяются в различных IT-компаниях — Tproger собирает рассказы

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

Ну так вот, вопрос о выборе языка программирования, меня мучает последнюю неделю, и впервые за 20 лет моей профессиональной деятельности (да ребятишки, я уже 20 ебаных лет зарабатываю на жизнь программированием, и только программированием). Почему же сейчас? Ответ лежит в одном слове – Scala.

Конечно о Scala я услышал не на прошлой неделе, в 2008 году мы в конторе начали ощущать что Java уже не торт (все естественно познается в сравнении) и начали задумываться о языке программирования на котором мы сможем въехать в следующее десятилетие, собственно вопрос стратегический, и непосредственно связан с будущим компании. Тогда же в 2008-м мы купили еще не законченную первую книжку Odersky, в электронном виде, и тут же нашли Fantom…

The Rise of Fantom

Fantom был и есть охуеннен. Продукт деятельности Brian & Andy Frank (я не устаю восхищаться этими ребятам) попадает в ту же нишу, что и Groovy, Ceylon, и Kotlin, но из всего перечисленного я однозначно голосую за Fantom. И у меня есть для этого четкие аргументы (которые выходят за рамки данного поста). Собственно Fantom однозначно завоевал мое сердце 5 лет назад, и мы даже сделали IDE для Fantom (в первую очередь для собственных нужд), предполагая что он будет основным языком разработки в компании лет так на 10 вперед.

Здесь я совсем не уникален и как мне кажется JetBrains ровно по тем же причинам сделал Kotlin, чуваки из itemis – Xtend, Guidewire – Gosu, ну и Brian (SkyFoundry) – Fantom. Они хотят быть более продуктивными, и для этого им нужен язык программирования, который позволит им быть более продуктивным. Все эти языки по моему мнению лежат в одной нише, и действительно позволяют быть раза так в 2-3 более продуктивным чем при программировании на Java (это моя субъективная оценка), на чем я вопрос о языке программирования закрыл. Мы будем писать на Fantom, и хорошо.

Ах да, я забыл сказать о Scala. В том же, не столь далеком 2008, слегка охуев от беглого прочтения незаконченной книжки Одерского, я понял что команду способную писать на Scala мы не соберем, и неважно в какой точке мира мы их будем ее собирать. Точнее мы безусловно найдем программистов способных *пользоваться* Scala, что и происходит сейчас во многих хипстер-стартапах, воспринимающих Scala как некую подслащенную версию Java и не видящие дальше синтаксического сахара, но слава Богу, мы не относимся к этому типу “программистов”.

Язык, как и библиотка, фреймворк, технология, инструмент, и т.д. должен увеличивать вашу продуктивность. Пользование Scala а-ля Java – уменьшает вашу продуктивность ибо тулзы – гавно, экосистема – хилая, компилятор – медленный, и т.д., и т.п. У нас годы уходят на то, чтобы собрать команду достойных программистов, способных писать на Java, собрать команду же достойных, и способных писать на Scala, займет десятилетия – область поиска сужается.

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

Таким образом Fantom, и только Fantom. Тем более что мы быстренько поженили Fantom Runtime с Eclipse Equinox (OSGi), научились писать Eclipse plugins исключительно на нем, на нем же начали делать Eclipse-based IDE, что сделало Fantom прекрасным языком и для текущей части бизнеса, который приносит деньги. Кроме того лично познакомились с создателями языка, и убедились, что в случае чего мы можем влиять на его реализацию и будущее.

Будущее представлялось безоблачным и светлым, и свет этот назывался Fantom…

Scala Strikes Back

В окстябре 2012 года у меня была пара скучных вечеров в отеле в Германии, и я вспомнил про начинающего программиста, который недавно попросил меня совета, о том, что бы ему посмотреть из лекций на coursera. Каюсь, лекций я не смотрю, но как бы советовать судя только по названию было западло, я решил глянуть лекции Одерского для юных Scala программистов… и просмотрел весь курс за два вечера (естественно с некоторыми ускорениями и перемотками).

Цикл у меня в голове замкнулся: то что я увидел – это был Космос, мистическое чувство. Scala – безусловно вершина развития языков программирования на данный момент. Я сейчас не говорю о всякой экзотике, DSLях, и языках embedded в разные платформы типа 1С или JavaScript. Не говорю и о всяческой динамике типа Ruby и Python – с ними все просто.

С высоты птичьего полета эти языки у меня попадают в ту же нишу что и JVM-based Groovy, Fantom, Kotlin и прочие, но только рожденные не летать, а плавать. Что, по большому счету не меняет их класса. Если хотите можете считать Ruby и Python – дельфинами, а JVM-based вещи – приматами (макаками, горилами, и орангутангами)… ну и еще есть насмешка природы типа JRuby и Jython – это как бы ползающие дельфины.

И вот на фоне всего этого животного многообразия – она. Если бы у меня была опухоль, я бы назвал ее Scala. Маленькая язвочка на небе, которая зажила бы, если бесконечно не притрагиваться к ней языком. Сука… что то я отошел от темы… Так вот, я считаю Scala – текущей вершиной эволюции языков программирования в моменте (естественно заглянув сейчас гораздо дальше лекций Одерского), и с этим надо что-то делать. Собствено вопрос стоит очень просто: стоит ли писать наши следующие вещи на самом мощном языке программирования, созданном на данный момент, или не стоит. Ответ на этот простой вопрос далеко не прост.

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

Так же мне не интересно популярное сегодня возражение о том, что сейчас можно писать на любом языке и мультиязыковые проекты скорее норма чем исключение, это я знаю не хуже вас, но так же я знаю насколько непродуктивно сношать, например Fantom с Gosu, или Scala c JRuby, несмотря на то что они JVM-based. собственно все что они имеют общее-это JVM-классы, и все сношение ограниченно этим уровнем. Другими словами, это примерно то-же, что мы имели 20 лет назад, линкуясь с объектными файлами писанными на паскале, фортране, разнообразных сях и плюсах. Уровень “интеграции” примерно тот-же.

Спираль истории

Всем известно, что история движется по спирали. Поскольку я – стар, я застал большую часть предыдущего витка спирали, витка развития профессиональных компилируемых языков общего назначения и их эволюцию от структурно-ориентированных к объектно-ориентированным. Опять же с высоты птичьего полета, да и с позиций практикующего инженера, мне неинтересна всякая академическая хуета типа Haskell и т.п. Индустрия на предыдущем витке держалась на C и C++, что не должно вызывать сомнений. Есть еще промежуточное, успешное звено – Objective C (хотя я бы не сказал что индустрия держалась на нем :)), упомянуть это промежуточное звено очень важно.

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

С (процедурно-ориентированный) -> Objective C (с элементами ОО) -> C++ (объектно-ориентированный по уши)

Интересны только три этих языка. Я сознательно не включаю сюда Smalltalk, например. Smalltalk – был началом следующего витка истории, основное отличие текущего витка от предыдущего (C/C++) — это Managed Runtime и сборка мусора.

Таким образом развитие на предыдущем витке было от C к C++, от процедурно-ориентированного языка, к объектно-ориентированному (и в то же время все еще процедурно-ориентированному), как к вершине эволюции на предыдущем витке. Что интересно на этом пути появились, и успешно заняли свою нишу довольно неплохие промежуточные варианты типа Objective C (который, кстати некоторая школота и хипстер-программисты, ошибочно считают вершиной развития человеческой ЯП мысли, но их я тут не буду расстраивать).

Теперь к текущему витку. Текущий виток развития языков программирования просто копия предыдущего. Место С в текущем витке занимает Java (ну и C#, чтобы не обидеть .NET-людей, хотя для меня это не имеет никакого значения – это как спорить о различиях PowerPC и Intel в прошлом – интересно, но бессмысленно).

Как я уже говорил, текущий виток фундаментально отличается от предыдущего наличием managed runtime, и другой стартовой парадигмой. Если предыдущий виток начинался с простого процедурно-ориентированного языка C и завершился безумно сложным объектно-ориентированным языком C++, то этот виток начался простым объектно-ориентированным языком Java. Заметьте, гораздо более простым чем вершина развития предыдущего витка (С++), и движется этот виток, что уже очевидно, в сторону безумно сложного языка функционального программирования Scala (который в то же время объектно-ориентированный, как и C++ остался процедурно-ориентированным). Во время этого движения появляются промежуточные языки с элементами функционального программирования, типа уже названных Groovy, Fantom, Kotlin, и т.д.

Глядя на все это блядство, у меня нет никаких сомнений, что Scala будет вершиной развития языков программирования на этом витке, и займет то же место, что и C++ занимал в предыдущем. Все промежуточные вещи займут нишу Objective C. Java уже свою нишу заняла.

Что интересно, я пока не вижу языков, которые бы обозначили начало следующего витка, как в свое время Smalltalk, но точно знаю, что он будет проще чем Scala (так же прост как С и Java), но появление его будет сопровождать некий фундаментальный сдвиг, как и managed runtime. Недавно поднимая эту тему в конторе @_komaz сказал что возможно это будет distributed (с чем с удовольствием соглашусь, ну либо какая-та фундаментальная поддержка параллельных вычислений)…

Возвращаясь к “больному вопросу”

Я как бы не зря озвучил выше все эти мысли, поскольку проводя аналогии вопрос в выборе языка сейчас для меня стоит еще проще (я как бы перенес его в прошлое, и не сомневаюсь в цикличности истории): на что поставить? На Objective C или на C++? На Fantom или на Scala?

Ответ не столь очевиден как может показаться. Очевидно следующее: на C сделана херова туча огромных проектов (вопрос продуктивности не рассматриваем). На Java не меньшая туча огромных проектов. Делая ставку на Java вы точно не прогадаете. Делая ставку на “промежуточные” языки вы тоже не прогадаете – они как правило не меняют парадигмы и привносят лишь полезные элементы. Вы можете слегка пострадать из за слабой экосистемы, но с другой стороны поимеете хороший пинок продуктивности. В целом мне вариант сделать основным языком в конторе что либо из Groovy, Fantom или Kotlin – кажется умным ходом и безрисковым вариантом (по крайней мере я не увидел таких рисков за последние 4 года).

Мысль же сделать основным языком Scala меня одновременно возбуждает и пугает (насколько можно возбуждаться и пугаться в моем возрасте). Это как в начале 90-х сказать: “пацаны, теперь мы будем писать все на C++”. Конечно, если бы мне такое сказали в начале 90-х, я бы обоссал стены кипятком, и сказал “круто”, пишем. Но сейчас – страшно.

C++ и большие проекты

К сожалению, у меня нет опыта работы в большом плюсовом проекте. Не его и у моих знакомых (так, на вскидку), с которыми я мог бы поговорить. Вернее он есть у кучи моих знакомых, но мне этот опыт неинтересен и не релевантен. Как правило они либо не стояли у истоков проекта и не занимались вопросами коммуникации между разработчиками, вопросами связанными со сторонними библиотеками, и т.д., либо “допиливали” эти проекты на последних стадиях (предсмертная реанимация).

Т.е. мне стыдно, но я не знаю насколько С++ плох или хорош как основной язык в конторе. Он безусловно хорош для маленькой (общающейся на одной волне команды) и индивидуалов. Поскольку в каждой команде появляется “свой” С++, каждый проект приобретает некие индивидуальные черты. Java лишена этого свойства, как и C (если вы, конечно, не делаете бизнес на макроподставах). Пользуясь Scala у меня нет сомнений, каждая команда будет изобретать свой Scala-диалект, что отразится болью в заднице.

Собственно я ожидаю весь тот же список проблем, который виден в C++ проектах, и речь идет даже не о внутренних проблемах, а о сношениях с внешним миром (вспомните сколько вы видели реализаций строк в плюсовых проектах? Делая ставку на Scala я буду ожидать чего-то подобного, но немного на другом уровне абстракции)

Рассуждать можно долго, очевидно следующее. Scala даст огромный рост продуктивности по сравнению с Java (так же как C->C++). Это верно для проекта с одним автором в вакууме. Сложность, и безграничные возможности языка отразятся гемороем, который нихера не будет способствовать продуктивности. Вопрос только в том чего будет больше. Я пока не знаю, да и больших Scala проектов в мире по большому счету еще нет.

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

Scala программист

В первую очередь интересуют онлайн игры, но не откажусь от работы над платформером или rogue-like, если понравится проект.
Могу уделять 5-10 часов в неделю, хотя могу перейти на full-time, если будут заманчивые предложения.
Если проект опенсорсный и очень понравится мне, готов работать за место в титрах.
Знаю джаву, но мне больше нравится Scala (функциональный JVM-based язык).
Мой опыт на джаве и скале связан с приложениями для бизнеса и правительства, поэтому я не могу выложить примеры работ) Я делал ММОG экономическую стратегию для IM(ICQ, Jabber). Сделал движок, но заказчики перессорились и проект так и не вышел на свет, к сожалению.

Сомневаюсь, что знания Scala тебе помогут в геймдеве. Тут рулит и педалит С++

fullzull, примеры твоих работ укажи, как того требуют правила.

StiX
серверные программисты Java с тобой не согласны))

Разбираешься в JavaScript? HTML5? Есть какие-нибудь проекты?

Scala для младших программистов?

мы рассматриваем Scala для нового проекта в нашей компании. У нас есть младшие программисты с только знаниями PHP, и мы сомневаемся, что они могут обрабатывать Scala. Каковы ваши мнения? Некоторые говорят: «Scala — это сложный зверь!», Некоторые говорят: «Это легко, когда вы его получили». Может быть, у кого-то есть реальный опыт?

«Мои коллеги не поймут, что Scala» одновременно завышает свои трудности и оскорбляет ваших коллег.

Scala не так сложно. Это просто еще один язык программирования. Любые проблемы, с которыми младшие программисты имеют Scala, будут иметь более или менее те же проблемы, с которыми они столкнулись бы с любым другим языком.

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

Тем не менее, в моей компании у нас есть некоторые основные продукты, разработанные в Scala, и мы не обнаруживаем, что у людей с ними больше проблем, чем с Java. Код, как правило, более понятен и краток, проще обобщать и повторно использовать и т.д.

Я предполагаю, что Scala может использоваться как язык «начинающих». Несмотря на то, что за этим стоят сложные идеи, вам не нужно использовать/объяснять их в начале. Если вы объясните чистое ОО с помощью Scala, я бы сказал, что он прямолинейный и понятный. Поскольку Scala уменьшает количество накладных расходов кода на других языках, может быть, даже легче освоить понятия с помощью Scala, чем с Java/С++.

Основным недостатком, который я вижу с Scala в качестве языка начинающих, является отсутствие документации. Не ошибитесь, официальный документ Scala очень хорош, а также несколько доступных книг очень полезны, чтобы получить детали языка, но они не были написаны для новичков. Например, в Java вы найдете сотни книг под названием «Learning OO с Java», которые вы не найдете для Scala, который может быть шоу-стопом.

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

Добавить комментарий