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

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

Интересно. Еще хотелось бы узнать, что надо что бы попробовать этот язык. Краткую инструкцию и/или ссылки на рабочие инструкции по установке и настройке нужных программ.
Кто-то конечно может возразить, что эти инструкции можно и в гугле найти. В ответ я скажу, что и введение в Scala тоже можно найти. Ибо о этом языке наслышан, и хочу на досуге попробовать его (вместе с nemerle). Но раз уж выпал шанс прочитать введение в скалу на Хабре, то хотелось бы и практические шаги тут же сделать.
В принципе подходит Eclipse с плагином.
Также есть плагин для IntelliJ Idea.
… Который я бы рекомендовал для ознакомления с языком — при всей моей любви к эклипсу в IDEA плагин гораздо функциональнее.
Собственно настройки никакой, у меня из коробки заработал и плагин на Eclipse и интерпретатор. Если имеется в виду установка компилятора и интерпретатора под Windows, к сожалению тут ничего подсказать не могу.
Ставим IntelliJ IDEA Comunity edition и Scala плагин, например 0.3.312.
Или 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 как говорится :),
Падает компилятор с NoClassDefFound, так-что отличия в исходниках не вариант.

Да я и в эклипсе хорошо живу, так минутка выпала попробовал покопаться. Проект я пока не готов публиковать по причине высокой убогости :)
В обычном мире 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 будет выведен.

Хм… Это 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();
Странно, что вывод generic-параметров для методов работает, а для конструкторов нет.
Да, видимо они посчитали, что конструктор — что-то более ответственное, чем просто вызов метода)
А nemerle умеет и отложенный вывод типов, то есть можно писать так:

def hash = Dictionary();
hash[«key»] = 5;
hash[«another key»] = 9;

а компилятор сам выведет, что у hash тип Dictionary[string,int].

Язык достаточно удобный, из крупных проектов на нем написал uniquation.ru.
Хм… странная фича, не понятно зачем нужна. Неужели у словаря нет удобного конструктора, который, например, пары принимает?
Дело не в конструкторе словаря, а в том, что Nemerle распознаёт тип объекта «hash», анализируя не только строку с его инициализацией, но и код ниже по тексту.
А конструктор может быть или не быть, не о том речь.
прикольный сайт но вот ява апплет как то криво смотрится
> Язык достаточно удобный, из крупных проектов на нем написал uniquation.ru.

сам поисковый движок? или и веб-морду тоже?
Движок написан на Nemerle, а сам сайт на C# — лень было настраивать Nemerle для ASP.NET для пары страниц.
да, вопрос как раз следующий был про то, как прикручивали Nemerle к ASP.NET) но нет, так нет)
Не видел, на работе 2.0 версия языка, а для души не тянет изучать :)
«Для души» nemerle можно, раз .NET знаешь, то будет просто =)
Я дотнетчик так себе. Там студию запустить, да бряк поставить, посмотреть что с Java-сервера пришло =)
Да, тоже сложилось впечатление, что Scala = Nemerle для Java :)

Очень мне понравился Nemerle, жаль что не он на месте F# в 2010 студии. Интересно, что помощнее — Scala или он. Мне кажется, что всё же Nemerle)
Если в Scala нет удобных шаблонов и вообще метапрограммирования, то 100% выиграет Nemerle)
Удобных шаблонов это как?
Метапрограммирования — какого? Кодогенерации врантайме?
То есть имелись в виду макросы? А зачем они в языке с поддержкой функций высокого порядка?
Функции высшего порядка — это замечательно, никто не спорит, но все же это run-time сущности. А макросы — compile-time.
Меня интересует, к примеру, возможно ли на Scala реализовать DSL или АОП.
Да.
Не знаю.
Окей, спасибо вам. Значит, здесь все на уровне, и фраза «Scala == Nemerle для Java» себя оправдывает)
вот на хабре была уже статья по поводу скалы и ДСЛ
pleax.habrahabr.ru/blog/39904/
DSL — ещё как можно, одно удовольствие :-)

Вот например. Дядька, кстати, пишет книгу про DSL, в качестве основного языка использует скалу.
Интересно узнать, на какие ограничения автор наткнулся в питоне
Ограничения на размер программ, к сожалению. Языки с динамической типизацией для поддержания работоспособности больших приложений и библиотек требуют неслабой тестовой базы, которая сама является кодом требующим поддержки (рекурсия, ага).
если проблема именно в типах, никто не мешает:
spam = str('eggs')
test = dict({str('spam'): str('eggs'), str('bacon'): str('хабр')}) #unicode in str because py3k can do it!
Не понял примера. В 2.5 str просто делала из объекта строку, 3й я не изучал, но судя по гуглу она делает то-же самое.
Ну а что надо?
Я так понимаю, что запутываешься, где какой тип. А в чем еще проблема с динамической типизацией? Меня вот почему-то устраивает и даже нравится, проще (:
Не могу сказать, что сильно путаюсь, но на 100 строк кода хоть один промах с типами да делается. А как выловить такое? Тоьлко тотальным «прозвоном» кода в тестах.
>Python таки хорош, но у нетипизированных языков есть свои ограничения
конкретнее можно?
Вообще-то, Python динамически, но типизированный ;) кури stdtypes.html
См. комментарием выше.
За замечание спасибо, действительно глупость написал.
Парсер съел ссылку, и движок еще не дает мне часто комментировать! И обновляет медленно => не увидел того, что об этом уже спросили.

docs.python.org/library/stdtypes.html
Читал, читал ссылку… Говорюж глупость написал.
Я уже нашёл человека-ворда для проверки, но всё-равно спасибо.
Статья отличная! Буду ждать продолжения! Если честно, тоже хотел свой первый пост написать про Scala в виде «Scala For Dummies») А сравнивать Scala с C# глупо, вернее сравнение будет Scala vs F#.

p.s. Исправьте ошибку «классическим пример высисления суммы»
а ещё вернее — Scala с Nemerle ;-)
Common Lisp, D и TCL должно хватить для всех неспециализированных задач. Если есть необъяснимая привязанность к jvm [;)], посмотрите Clojure.
> Common Lisp
вы суровы :)
Не люблю я лисп, что греха таить. Курс ФП на нём в универе нанёс мне небольшую психическую травму :(
Всё, конечно, хорошо…
Но тут java-программиста приличного днём с огнём не сыщешь. Где ж их на common lisp искать?
У D тоже неплохая поддержка ФП и, при этом, отсутствует привязка к платформе jvm. А человек, который смог освоить C++ до состояния «приличного программиста» осилит D за пару дней, в крайнем случае (если кроме C++ ничего в жизни не видел) недель.
А к какой платформе у него есть привязка?
Вопрос опирается на неверное предположение. :P

Но на данный момент, безглючные компиляторы есть только для x86 и x86-64.
win/linux/solaris?
да :)
На самом деле, он сейчас не слишком готов для production. Дайте разработчикам компилятора ещё полтора-два месяца на допиливание.

А лучше просто забудьте про D (если нет времени и/или желания посмотреть заранее) и ждите новости на Хабре.
Вот так оно всегда и получается…
С одной стороны «в языке… есть всё что нужно».
С другой — компилятор — уже почти готов,
профайлера нет (или есть, но глючный, под линух, и с командной строкой)
ide по функциональности как turbo pascal 7.0
разработчиков на него хрена лысого найдёшь
заявленная совместимость совмещается только на сферическом приложении в вакууме
и т. д.

Разработчиков не для языков надо искать, а для задач.
А IDE да… под Java они основная компенсация за косяки в языке.
А какие в java ещё косяки кроме, пожалуй, кривых generics и слегка кривоватых примитивных типов?
Это весьма немало. И массивы сделаные так, что их без private final боятся юзать (: И об синхронизацию как она в язык введена мозг сломать можно. И first-class функций не хватает аццки.
Этого немало, только IDE это никак не компенсирует…
к сожалению…
> профайлера нет (или есть, но глючный, под линух, и с командной строкой)
Во-первых, не глючный, во-вторых, если палец к мыши не прирос, то что плохого в командной строке?

> ide по функциональности как turbo pascal 7.0
Я бы не сказал, что Descent на уровне TP7. Или TP7 действительно имел outline, подсветку ошибок при редактировании кода и умный автокомплишен?

> заявленная совместимость совмещается только на сферическом приложении в вакууме
Надо сильно постараться, чтобы написать не кроссплатформенное и не кросскомпайлерное приложение. Не так сильно, как а Java, но всё-равно нужно.

Про разработчиков уже сказали выше.
Командная строка — это хорошо. Я её люблю искренне и всей душой за исключением случаев, когда профайлер используется достаточно редко чтобы успеть забыть все команды, но достаточно часто чтобы задолбаться их каждый раз вспоминать.

Если говорить, например, про scala plugin for eclipse — первое на что я наткнулся это криво работающая подсветка ошибок и отсутствие organize imports.
Rename variable — работает, но глючит.
Запуск на исполнение — надо допиливать, прямо «из коробки» не работает.
> Я её люблю искренне и всей душой за исключением случаев, когда профайлер используется достаточно редко чтобы успеть забыть все команды, но достаточно часто чтобы задолбаться их каждый раз вспоминать.

Да хоть сейчас. Ключик "-cov" компилятору. :)
И да, Lisp тоже с динамической типизацией ;)
А в TCL всё просто. :) Для разработчика есть всего один тип — строка. Остальные из программы не видны и используются машиной только для оптимизации.

Само собой, о HPC на TCL забудьте.
а почему не groovy тогда?
Производительность Clojure не смотрел, но по сравнению с SBCL Groovy — ужасный тормоз.

Краткое гугление показало, что у Groovy сложная система метапрограммирования и достаточно сложный синтаксис. Homoiconic (хз как по-русски) языки, например, Clojure, имеют преимущество простого синтаксиа. Функция — форма, принимающая вычисленные один раз аргументы и возвращающая результат. Макрос — форма, которая принимает невычисленные аргументы и возвращает форму, которая, при вычислении, возвращает результат. Вот и вся разница.
>Производительность Clojure не смотрел
зря

>Краткое гугление показало, что у Groovy сложная система метапрограммирования и достаточно сложный синтаксис.
ну вот как минимум на счёт синтаксиса с вами не соглашусь — он может быть вообще максиматьно близким к java
>> Производительность Clojure не смотрел
> зря
Почему? Сейчас посмотрел. Как и ожидалось, немного медленнее Java, но намного быстрее Groovy(больше двух порядков). Тест числодробительный.

> ну вот как минимум на счёт синтаксиса с вами не соглашусь — он может быть вообще максиматьно близким к java
Хотите сказать, что у Java простой синтаксис? :D С кучей инфиксных операторов, разделением деклараций и выражений, хитрыми (с точки зрения компилятора, а не математики) правилами по определению порядка вычисления операндов в выражении и т.д.
А два конструктора можно?
Например, Complex(re, im) и Complex(abs, angle).

Generics в рантайме доступны?

Методы на ходу добавлять можно?

При заявленной прозрачности для java-приложений — как там будет reflections работать?
А как их различать?)
Искал тут один товарищ ответ на этот вопрос. Я не совсем понял что именно он нашёл :(
Нет. В качестве альтернативы авторы рекоммендуют использовать неявные преобразования типов, про которые я из соображений гуманизма писать не стал.
Точно так-же, вся стандартная библиотека Java доступна, вместе с пакетом java.lang.reflect.
Там не будет глюков при попытке запросить метод с именем «name_=»?
Нет.
scala> class Test { def test_=(s: String) = printf(s)}
defined class Test
scala> new Test test_= "qq"
qq

Меня, скорее, наоборот интересует:
public static void main(...){
  Method m = Class.forName("Test").getMethod("test_=");
}


Экспериментов не ставил. Но проблемы не вижу — формат class-файлов кажется ограничений на имена методов не накладывает.
scalac когда компилирует занемяет пунктуацию в именах на мнемонику, = на $eq, + на $plus, — на $minus и т.д.

Например, если в 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");
  }
}
Интересно. Не знал.
НЛО прилетело и опубликовало эту надпись здесь
Благодарю, намёк понял.
было бы интересно почитать про то как скала с XML работает, там же вроде на уровне языка
большое спасибо за введение в 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…
а скорость работы в сравнении в явой?
Не замерял, штука в процессе написания.
Скорость работы такая же, или быстрее, в случае если не переборщить с ФП и не вляпаться в несколько не очевидных моментов.
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 версии.
Спасибо! Влез в вашу статью, так как нужно было по-быстрому освоить Chisel
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории