Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 106
Интересно. Еще хотелось бы узнать, что надо что бы попробовать этот язык. Краткую инструкцию и/или ссылки на рабочие инструкции по установке и настройке нужных программ.
Кто-то конечно может возразить, что эти инструкции можно и в гугле найти. В ответ я скажу, что и введение в Scala тоже можно найти. Ибо о этом языке наслышан, и хочу на досуге попробовать его (вместе с nemerle). Но раз уж выпал шанс прочитать введение в скалу на Хабре, то хотелось бы и практические шаги тут же сделать.
Кто-то конечно может возразить, что эти инструкции можно и в гугле найти. В ответ я скажу, что и введение в Scala тоже можно найти. Ибо о этом языке наслышан, и хочу на досуге попробовать его (вместе с nemerle). Но раз уж выпал шанс прочитать введение в скалу на Хабре, то хотелось бы и практические шаги тут же сделать.
В принципе подходит Eclipse с плагином.
Собственно настройки никакой, у меня из коробки заработал и плагин на Eclipse и интерпретатор. Если имеется в виду установка компилятора и интерпретатора под Windows, к сожалению тут ничего подсказать не могу.
Ставим IntelliJ IDEA Comunity edition и Scala плагин, например 0.3.312.
Или Scala for Netbeans или как уже упоминали Eclipse с плагином.
Я использовал все три, дольше всего Eclipse, для Netbeans плагин совсем не понравился — сыроват еще, но в последнее время пересел на IDEA. Для тех кому все равно какое IDE использовать посоветовал бы IDEA, но и в Eclipse поддержка Scala вполне достойная.
Или Scala for Netbeans или как уже упоминали Eclipse с плагином.
Я использовал все три, дольше всего Eclipse, для Netbeans плагин совсем не понравился — сыроват еще, но в последнее время пересел на IDEA. Для тех кому все равно какое IDE использовать посоветовал бы IDEA, но и в Eclipse поддержка Scala вполне достойная.
в восьмой идее не везьде дополнение кода работает, не знаете как с этим в 9
В beta было весьма плохо и не только с этим. В релизе говорят, что много чего починили.
Субъективно стало лучше, например, по двойному ctrl+space видны недоступные методы. Специфически Scala плагин часто огрубляет дополнение при наличии ошибок. Видимо свой парсер не такой устойчивый/продвинутый как для Java, и пока scalac typer не вычислит все типы, предлагает только методы класса Object.
Свежескачанная идея community edition и плагин версии 0.3.312 тупо не могут скомпилять проект. LOL как говорится :)
А до этого чем компилировали, если Eclipse, то последний раз когда я его использовал там версия scalac была 2.7.7, в 0.3.312 — 2.8 пререлиз. 2.8 не полностью совместим с 2.7. Ну и пререлиз само собой подразумевает прекачество.
Если охота покапаться можно попробовать с командной строки 2.8 скомпилировать. Если неохота, и проект открытый могу и сам покопаться.
Ну а вообще YMMV как говорится :),
Если охота покапаться можно попробовать с командной строки 2.8 скомпилировать. Если неохота, и проект открытый могу и сам покопаться.
Ну а вообще YMMV как говорится :),
В обычном мире pattern matching принято реализовывать через паттерн посетитель, при этом не происходит большого числа функций.
Во-первых не стоит забывать, что это один из наиболее сложных структурных паттернов.
Во-вторых он ориентирован на аккумулирование информации от обхода какой-то структуры, для получения одного значения он неудобен.
В-третьих, да, при его использовании такие функции-селекторы концентрируются вместе, но каждый посетитель вынужден определять каждую функцию.
Во-вторых он ориентирован на аккумулирование информации от обхода какой-то структуры, для получения одного значения он неудобен.
В-третьих, да, при его использовании такие функции-селекторы концентрируются вместе, но каждый посетитель вынужден определять каждую функцию.
Пишите еще, было бы интересно почитать. Давно хотелось попробовать, но руки не дошли, так будет гораздо ближе =)
И маленький совет — проверяйте орфографию хотя бы вордом, у него многому можно научиться; при этом информация будет восприниматься в разы легче.
И маленький совет — проверяйте орфографию хотя бы вордом, у него многому можно научиться; при этом информация будет восприниматься в разы легче.
классный пост, спасибо
Справедливости ради замечу, что в c# сейчас уже есть вывод типов.
Для generic параметров тоже?
вот чего не знаю, то не знаю :)
Тоже. Например, в глубоких вызовах LINQ — там шаблон на шаблоне, и типы нигде не надо указывать.
Конкретно этот пример:
var list = new List<User>(new AnonymousUser(), new OtherUser(«Vasya»), new SomeOtherUser { Name=«Vasya», Age = 14});
Конкретно тут, раз уж вы указываете тип (List), то придётся указать полностью. Но если var list = Repeat(new OtherUser(«Vasya»)), где Repeat: T -> List<T>, тип list будет выведен.
Конкретно этот пример:
var list = new List<User>(new AnonymousUser(), new OtherUser(«Vasya»), new SomeOtherUser { Name=«Vasya», Age = 14});
Конкретно тут, раз уж вы указываете тип (List), то придётся указать полностью. Но если var list = Repeat(new OtherUser(«Vasya»)), где Repeat: T -> List<T>, тип list будет выведен.
Хм… Это C# уже и такое понимает? Надо тогда его подучить…
* fix: я тут с выводом немного увлёкся, и забыл про то, какой конструктор у List:
List<T>(IEnumerable<T> src);
Вот так правильно:
var list = new List<User>(new User[] { new AnonymousUser(), new OtherUser(«Vasya»), new SomeOtherUser { Name=«Vasya», Age = 14} });
Или, с одним упоминанием типа:
var list = new User[] { new AnonymousUser(), new OtherUser(«Vasya»), new SomeOtherUser { Name=«Vasya», Age = 14} }.ToList();
List<T>(IEnumerable<T> src);
Вот так правильно:
var list = new List<User>(new User[] { new AnonymousUser(), new OtherUser(«Vasya»), new SomeOtherUser { Name=«Vasya», Age = 14} });
Или, с одним упоминанием типа:
var list = new User[] { new AnonymousUser(), new OtherUser(«Vasya»), new SomeOtherUser { Name=«Vasya», Age = 14} }.ToList();
А nemerle умеет и отложенный вывод типов, то есть можно писать так:
def hash = Dictionary();
hash[«key»] = 5;
hash[«another key»] = 9;
а компилятор сам выведет, что у hash тип Dictionary[string,int].
Язык достаточно удобный, из крупных проектов на нем написал uniquation.ru.
def hash = Dictionary();
hash[«key»] = 5;
hash[«another key»] = 9;
а компилятор сам выведет, что у hash тип Dictionary[string,int].
Язык достаточно удобный, из крупных проектов на нем написал uniquation.ru.
Не видел, на работе 2.0 версия языка, а для души не тянет изучать :)
«Для души» nemerle можно, раз .NET знаешь, то будет просто =)
Я дотнетчик так себе. Там студию запустить, да бряк поставить, посмотреть что с Java-сервера пришло =)
Да, тоже сложилось впечатление, что Scala = Nemerle для Java :)
Очень мне понравился Nemerle, жаль что не он на месте F# в 2010 студии. Интересно, что помощнее — Scala или он. Мне кажется, что всё же Nemerle)
Очень мне понравился Nemerle, жаль что не он на месте F# в 2010 студии. Интересно, что помощнее — Scala или он. Мне кажется, что всё же Nemerle)
Если в Scala нет удобных шаблонов и вообще метапрограммирования, то 100% выиграет Nemerle)
Удобных шаблонов это как?
Метапрограммирования — какого? Кодогенерации врантайме?
Метапрограммирования — какого? Кодогенерации врантайме?
Это вот так.
То есть имелись в виду макросы? А зачем они в языке с поддержкой функций высокого порядка?
Функции высшего порядка — это замечательно, никто не спорит, но все же это run-time сущности. А макросы — compile-time.
Меня интересует, к примеру, возможно ли на Scala реализовать DSL или АОП.
Меня интересует, к примеру, возможно ли на Scala реализовать DSL или АОП.
Да.
Не знаю.
Не знаю.
вот на хабре была уже статья по поводу скалы и ДСЛ
pleax.habrahabr.ru/blog/39904/
pleax.habrahabr.ru/blog/39904/
DSL — ещё как можно, одно удовольствие :-)
Вот например. Дядька, кстати, пишет книгу про DSL, в качестве основного языка использует скалу.
Вот например. Дядька, кстати, пишет книгу про DSL, в качестве основного языка использует скалу.
Интересно узнать, на какие ограничения автор наткнулся в питоне
Ограничения на размер программ, к сожалению. Языки с динамической типизацией для поддержания работоспособности больших приложений и библиотек требуют неслабой тестовой базы, которая сама является кодом требующим поддержки (рекурсия, ага).
если проблема именно в типах, никто не мешает:
spam = str('eggs')
test = dict({str('spam'): str('eggs'), str('bacon'): str('хабр')}) #unicode in str because py3k can do it!
spam = str('eggs')
test = dict({str('spam'): str('eggs'), str('bacon'): str('хабр')}) #unicode in str because py3k can do it!
>Python таки хорош, но у нетипизированных языков есть свои ограничения
конкретнее можно?
Вообще-то, Python динамически, но типизированный ;) кури stdtypes.html
конкретнее можно?
Вообще-то, Python динамически, но типизированный ;) кури stdtypes.html
См. комментарием выше.
За замечание спасибо, действительно глупость написал.
За замечание спасибо, действительно глупость написал.
Парсер съел ссылку, и движок еще не дает мне часто комментировать! И обновляет медленно => не увидел того, что об этом уже спросили.
docs.python.org/library/stdtypes.html
docs.python.org/library/stdtypes.html
мощьный)
Статья отличная! Буду ждать продолжения! Если честно, тоже хотел свой первый пост написать про Scala в виде «Scala For Dummies») А сравнивать Scala с C# глупо, вернее сравнение будет Scala vs F#.
p.s. Исправьте ошибку «классическим пример высисления суммы»
p.s. Исправьте ошибку «классическим пример высисления суммы»
Common Lisp, D и TCL должно хватить для всех неспециализированных задач. Если есть необъяснимая привязанность к jvm [;)], посмотрите Clojure.
> Common Lisp
вы суровы :)
вы суровы :)
Не люблю я лисп, что греха таить. Курс ФП на нём в универе нанёс мне небольшую психическую травму :(
Всё, конечно, хорошо…
Но тут java-программиста приличного днём с огнём не сыщешь. Где ж их на common lisp искать?
Но тут java-программиста приличного днём с огнём не сыщешь. Где ж их на common lisp искать?
У D тоже неплохая поддержка ФП и, при этом, отсутствует привязка к платформе jvm. А человек, который смог освоить C++ до состояния «приличного программиста» осилит D за пару дней, в крайнем случае (если кроме C++ ничего в жизни не видел) недель.
А к какой платформе у него есть привязка?
Вопрос опирается на неверное предположение. :P
Но на данный момент, безглючные компиляторы есть только для x86 и x86-64.
Но на данный момент, безглючные компиляторы есть только для x86 и x86-64.
win/linux/solaris?
да :)
На самом деле, он сейчас не слишком готов для production. Дайте разработчикам компилятора ещё полтора-два месяца на допиливание.
А лучше просто забудьте про D (если нет времени и/или желания посмотреть заранее) и ждите новости на Хабре.
А лучше просто забудьте про D (если нет времени и/или желания посмотреть заранее) и ждите новости на Хабре.
Вот так оно всегда и получается…
С одной стороны «в языке… есть всё что нужно».
С другой — компилятор — уже почти готов,
профайлера нет (или есть, но глючный, под линух, и с командной строкой)
ide по функциональности как turbo pascal 7.0
разработчиков на него хрена лысого найдёшь
заявленная совместимость совмещается только на сферическом приложении в вакууме
и т. д.
С одной стороны «в языке… есть всё что нужно».
С другой — компилятор — уже почти готов,
профайлера нет (или есть, но глючный, под линух, и с командной строкой)
ide по функциональности как turbo pascal 7.0
разработчиков на него хрена лысого найдёшь
заявленная совместимость совмещается только на сферическом приложении в вакууме
и т. д.
Разработчиков не для языков надо искать, а для задач.
А IDE да… под Java они основная компенсация за косяки в языке.
А IDE да… под Java они основная компенсация за косяки в языке.
> профайлера нет (или есть, но глючный, под линух, и с командной строкой)
Во-первых, не глючный, во-вторых, если палец к мыши не прирос, то что плохого в командной строке?
> ide по функциональности как turbo pascal 7.0
Я бы не сказал, что Descent на уровне TP7. Или TP7 действительно имел outline, подсветку ошибок при редактировании кода и умный автокомплишен?
> заявленная совместимость совмещается только на сферическом приложении в вакууме
Надо сильно постараться, чтобы написать не кроссплатформенное и не кросскомпайлерное приложение. Не так сильно, как а Java, но всё-равно нужно.
Про разработчиков уже сказали выше.
Во-первых, не глючный, во-вторых, если палец к мыши не прирос, то что плохого в командной строке?
> ide по функциональности как turbo pascal 7.0
Я бы не сказал, что Descent на уровне TP7. Или TP7 действительно имел outline, подсветку ошибок при редактировании кода и умный автокомплишен?
> заявленная совместимость совмещается только на сферическом приложении в вакууме
Надо сильно постараться, чтобы написать не кроссплатформенное и не кросскомпайлерное приложение. Не так сильно, как а Java, но всё-равно нужно.
Про разработчиков уже сказали выше.
Командная строка — это хорошо. Я её люблю искренне и всей душой за исключением случаев, когда профайлер используется достаточно редко чтобы успеть забыть все команды, но достаточно часто чтобы задолбаться их каждый раз вспоминать.
Если говорить, например, про scala plugin for eclipse — первое на что я наткнулся это криво работающая подсветка ошибок и отсутствие organize imports.
Rename variable — работает, но глючит.
Запуск на исполнение — надо допиливать, прямо «из коробки» не работает.
Если говорить, например, про scala plugin for eclipse — первое на что я наткнулся это криво работающая подсветка ошибок и отсутствие organize imports.
Rename variable — работает, но глючит.
Запуск на исполнение — надо допиливать, прямо «из коробки» не работает.
Возможно вас заинтересует.
www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=17369
Почта на сайте erdani.com
www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=17369
Почта на сайте erdani.com
И да, Lisp тоже с динамической типизацией ;)
а почему не groovy тогда?
Производительность Clojure не смотрел, но по сравнению с SBCL Groovy — ужасный тормоз.
Краткое гугление показало, что у Groovy сложная система метапрограммирования и достаточно сложный синтаксис. Homoiconic (хз как по-русски) языки, например, Clojure, имеют преимущество простого синтаксиа. Функция — форма, принимающая вычисленные один раз аргументы и возвращающая результат. Макрос — форма, которая принимает невычисленные аргументы и возвращает форму, которая, при вычислении, возвращает результат. Вот и вся разница.
Краткое гугление показало, что у Groovy сложная система метапрограммирования и достаточно сложный синтаксис. Homoiconic (хз как по-русски) языки, например, Clojure, имеют преимущество простого синтаксиа. Функция — форма, принимающая вычисленные один раз аргументы и возвращающая результат. Макрос — форма, которая принимает невычисленные аргументы и возвращает форму, которая, при вычислении, возвращает результат. Вот и вся разница.
>Производительность Clojure не смотрел
зря
>Краткое гугление показало, что у Groovy сложная система метапрограммирования и достаточно сложный синтаксис.
ну вот как минимум на счёт синтаксиса с вами не соглашусь — он может быть вообще максиматьно близким к java
зря
>Краткое гугление показало, что у Groovy сложная система метапрограммирования и достаточно сложный синтаксис.
ну вот как минимум на счёт синтаксиса с вами не соглашусь — он может быть вообще максиматьно близким к java
>> Производительность Clojure не смотрел
> зря
Почему? Сейчас посмотрел. Как и ожидалось, немного медленнее Java, но намного быстрее Groovy(больше двух порядков). Тест числодробительный.
> ну вот как минимум на счёт синтаксиса с вами не соглашусь — он может быть вообще максиматьно близким к java
Хотите сказать, что у Java простой синтаксис? :D С кучей инфиксных операторов, разделением деклараций и выражений, хитрыми (с точки зрения компилятора, а не математики) правилами по определению порядка вычисления операндов в выражении и т.д.
> зря
Почему? Сейчас посмотрел. Как и ожидалось, немного медленнее Java, но намного быстрее Groovy(больше двух порядков). Тест числодробительный.
> ну вот как минимум на счёт синтаксиса с вами не соглашусь — он может быть вообще максиматьно близким к java
Хотите сказать, что у Java простой синтаксис? :D С кучей инфиксных операторов, разделением деклараций и выражений, хитрыми (с точки зрения компилятора, а не математики) правилами по определению порядка вычисления операндов в выражении и т.д.
А два конструктора можно?
Например, Complex(re, im) и Complex(abs, angle).
Generics в рантайме доступны?
Методы на ходу добавлять можно?
При заявленной прозрачности для java-приложений — как там будет reflections работать?
Например, Complex(re, im) и Complex(abs, angle).
Generics в рантайме доступны?
Методы на ходу добавлять можно?
При заявленной прозрачности для java-приложений — как там будет reflections работать?
А как их различать?)
Искал тут один товарищ ответ на этот вопрос. Я не совсем понял что именно он нашёл :(
Нет. В качестве альтернативы авторы рекоммендуют использовать неявные преобразования типов, про которые я из соображений гуманизма писать не стал.
Точно так-же, вся стандартная библиотека Java доступна, вместе с пакетом java.lang.reflect.
Искал тут один товарищ ответ на этот вопрос. Я не совсем понял что именно он нашёл :(
Нет. В качестве альтернативы авторы рекоммендуют использовать неявные преобразования типов, про которые я из соображений гуманизма писать не стал.
Точно так-же, вся стандартная библиотека Java доступна, вместе с пакетом java.lang.reflect.
Там не будет глюков при попытке запросить метод с именем «name_=»?
Нет.
scala> class Test { def test_=(s: String) = printf(s)}
defined class Test
scala> new Test test_= "qq"
Меня, скорее, наоборот интересует:
public static void main(...){
Method m = Class.forName("Test").getMethod("test_=");
}
Экспериментов не ставил. Но проблемы не вижу — формат class-файлов кажется ограничений на имена методов не накладывает.
scalac когда компилирует занемяет пунктуацию в именах на мнемонику, = на $eq, + на $plus, — на $minus и т.д.
Например, если в Scala имеется класс
То в Java к test_= методу можно доступится следующим образом:
ну или если reflection не нужен то:
Например, если в Scala имеется класс
package test
class Test {
def test_=(s: String) = println(s)
}
То в Java к test_= методу можно доступится следующим образом:
package test;
import java.lang.reflect.Method;
public class Main {
public static void main(String[] args) throws Exception {
Method m = Class.forName("test.Test").getMethod("test_$eq", String.class);
m.invoke(new Test(), new Object[] {"scala"});
}
}
ну или если reflection не нужен то:
package test;
public class Main {
public static void main(String[] args) throws Exception {
new Test() {
public void callScala(String s) {
test_$eq(s);
}
}.callScala("java");
}
}
большое спасибо за введение в Scala.
очень бы хотелось настоящий примеров из практики, в которых использование Scala сильно облегчает жизнь
очень бы хотелось настоящий примеров из практики, в которых использование Scala сильно облегчает жизнь
Самый известный — написание на нём бэкэнда Twitter. Второде никто не жаловался :)
про бэкэенд Твиттера мы знаем что он на Scala, а не на Ruby потому что когда его начали писать сам Ruby был довольно хилым и крайне медленным(не то что сейчас ruby1.9, rubinius и т.д.)
вот вы написали
вот вы написали
Причин тому много, основная — всё нарастающее со временем чувство неудобства при работе с cpp-подобными языками. Взгляд мой попеременно падал на Ruby, Groovy, Python, но все они оставляли впечатление инструментов, не совсем подходящих для моего обычного круга рабочих задач (Python-таки хорош, но у нетипизированных языков есть свои ограничения). Scala же, напротив, показалась вполне годным языком.Значит у Вас были задачи, которые императивными языками решались плохо, а на функциональном решались легко и органично. Собственно про эти задачи и хотелось почитать.
Хм… Его вроде делали около года назад, Ruby 1.9 уже был совсем на подходе. Хотя точно истории не знаю.
Нет Ruby, Groovy, Python я оценивал не из любви к ФП. Просто в Java есть и моногочисленные косяки и масса неудобств типа отсутствия функциональных типов. Задачи, самые обычные — посмотрите, например на создание списка в моём последнем примере. Во сколько раз делающий то-же самое код на Java длинее?
Практики рабочей у меня (надеюсь пока) нет. В качестве упражнения портировал на Scala старый курсовик по ray tracing(где-то 80% готово, всё лень геометрию перенести до конца). В этой задаче пригодилось практически всё, что я описал в посте. Объём кода около 400 строк включая парсер формата сцен. На Java около 2000…
Нет Ruby, Groovy, Python я оценивал не из любви к ФП. Просто в Java есть и моногочисленные косяки и масса неудобств типа отсутствия функциональных типов. Задачи, самые обычные — посмотрите, например на создание списка в моём последнем примере. Во сколько раз делающий то-же самое код на Java длинее?
Практики рабочей у меня (надеюсь пока) нет. В качестве упражнения портировал на Scala старый курсовик по ray tracing(где-то 80% готово, всё лень геометрию перенести до конца). В этой задаче пригодилось практически всё, что я описал в посте. Объём кода около 400 строк включая парсер формата сцен. На Java около 2000…
а скорость работы в сравнении в явой?
Не замерял, штука в процессе написания.
Скорость работы такая же, или быстрее, в случае если не переборщить с ФП и не вляпаться в несколько не очевидных моментов.
1. boxing происходит еще более незаметно, чем в Java. Это происходит в силу того, что примитивные типы теперь дозволено видеть в качестве параметров дженериков.
2. Return использованный внутри анонимных методов или for (что на самом деле тот же анонимный метод). Проблема в этом случае происходит в силу бросания эксепшина NonLocalReturnException (с названием могу и напутать), что происходит довольно долго (а на деле скажем этот код совсем простой и должен был в итоге выполниться в три раза быстрее).
3. ФП позволяет сократить количество кода, но за счет скорости выполнения. Скажем иногда удобно много раз итерироваться по массиву выполняя вещи, которые можно было сделать в одну итерацию. Происходит подобное просто из-за удобств функционального стиля.
1. boxing происходит еще более незаметно, чем в Java. Это происходит в силу того, что примитивные типы теперь дозволено видеть в качестве параметров дженериков.
2. Return использованный внутри анонимных методов или for (что на самом деле тот же анонимный метод). Проблема в этом случае происходит в силу бросания эксепшина NonLocalReturnException (с названием могу и напутать), что происходит довольно долго (а на деле скажем этот код совсем простой и должен был в итоге выполниться в три раза быстрее).
3. ФП позволяет сократить количество кода, но за счет скорости выполнения. Скажем иногда удобно много раз итерироваться по массиву выполняя вещи, которые можно было сделать в одну итерацию. Происходит подобное просто из-за удобств функционального стиля.
Сравниваю вышенаписанное с C#. Я не вижу чем скала в примерах удобней C#, а даже наоборот — более запутанный и неоднозначный синтаксис.
На счет коллекций, начиная с C# 3.0 (2004 г) коллекции инициализируются так:
var list1 = new List { new User(«Masha»), new User(«Petya»), kolyaUserObject };
и так
var list2 = new [] { «string1», «string2» };
В версиязх 4,5,6 огромное кол-во плюшек добавлено.Например именованные и необязательные аргументы в методах. Значения по умолчанию для геттеров:
string Field1 {
get; = «default value»
set;
}
Pattern Matching правда вот совсем недавно появился в 7 версии.
На счет коллекций, начиная с C# 3.0 (2004 г) коллекции инициализируются так:
var list1 = new List { new User(«Masha»), new User(«Petya»), kolyaUserObject };
и так
var list2 = new [] { «string1», «string2» };
В версиязх 4,5,6 огромное кол-во плюшек добавлено.Например именованные и необязательные аргументы в методах. Значения по умолчанию для геттеров:
string Field1 {
get; = «default value»
set;
}
Pattern Matching правда вот совсем недавно появился в 7 версии.
Спасибо! Влез в вашу статью, так как нужно было по-быстрому освоить Chisel
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scala. Введение