Здесь

Интересно любое мнение по этому поводу.

Imho довольно интересный язык. Дизайнер языка — Martin Odersky. Среди его предудыщих "творений" Pizza и GJ(который впоследствии стал базой для реализации Generics в Java).

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

На мой взгляд этот язык скорее тенденция, чем проект имеющий большое самостоятельное значение. Скажем из других языков, имеющих схожие черты и идеологию я могу назвать Nemerle, Boo(статически типизированный python),Groovy.

Я небезосновательно думаю, что примерно так будут выглядеть промышленные языки лет через пять. В принципе не важно будет ли это Scala или C# X.0, важна сама тенденция. И на мой взгляд, традиционные функциональные языки начинают отходить в прошлое, так и не успев стать языками промышленной разработки. Об этом говорит хотя бы то, что ocaml.org и haskell.org обновляются в последнее время крайне редко.

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

Здравствуйте, BulatZiganshin, Вы писали:

E>>PS. На мой далекий от Java взгляд, перспективы у Scala стать новым мейнстримовым языком на JVM, гораздо выше, чем у Nemerle/F# на .NET.

BZ>похоже, что в 2010-х мы будем иметь противостояние f# против скалы. не забывай, что f# официально продвигается, а это важнее достоинств самого языка

Поживем-увидим. Не долго уже осталось. Может они все будут соперничать с C++0x, и мы всех порвем! А потом нас догонят и мы опять всех порвем. А там я уже и на пенсию пойду

Здравствуйте, uw, Вы писали:

G>>В мои цели не входит замешивание Scala с дерьмом.
uw>Правильно, в твои цели видимо входит замешивание меня с дерьмом. Просто ради развлечения.


От себя лично скажу, что порой высказывания Gaperton действительно сквозят некой хамоватостью по отношению к другим посетителям форума. И было бы очень неплохо если бы он в своих высказываниях был бы более выдержан и не допускал выражений выражений на счет знаний/опыта собеседника. Тонкие намеки и ювелирные подколки, выглядящие со стороны практически безобидными, могут ранить человека на подсознательном уровне значительно сильнее чем прямое оскорбление.

В общем, не стоит доводить до вмешательства модераторов. Особенно таких предвзятых как я.

Здравствуйте, Quintanar, Вы писали:

Q>А вы сами писали что-нибуль на нормальном Ф.Я.?
Только очень небольшие программы на Haskell и Scheme, надо сказать что ни массивов, ни хешей я не использовал.

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

Q>Почему вы думаете, что на практике чаще используются массивы и хеши?
Потому, что на практике чаще используются императивные языки.

Q>Я вот могу сказать, что массивы вообще почти не нужны (кроме спец задач, когда они действительно нужны). Хеши тоже нужны только изредка. Я откровенно говоря вообще не представляю, что в языке останется функционального, если не будет списков, а будут одни типы с side effects.

Почему "одни". Да и потом кто сказал, что обязательно должны быть side effects? Многие структуры данных можно реализовать и без них.

На мой взгляд беда функциональных языков это их весьма ограниченный набор структур данных и пуризм, переходящий всякие границы. Там где нужен side-effect free код, там он и должен быть, а где нужен быть побочный эффект, должен быть побочный эффект.

Кстати интересно, что большинство новых разработок в функциональных языках касаются устранения накладных расходов, возникающих благодаря отсутствию эксплуатации побочного эффекта и overusing'у таких структур как списки. Скажем те же обычные списки хотят заменить на VList. Не говоря уже о том, что большинство современных ФЯ поддерживают как императивность так и побочные эффекты в той или иной форме. Это необходимость с которой придется свыкнуться, так как без нее нет эффективных программ.

При этом все забывают, что элементы функциональных языков если их использовать правильно(то есть в ограниченных количествах) могут значительно помочь в оптимизации императивного кода. Хороший пример — STL. Степанов сначала интересовался функциональными языками, но пришел к выводу, что побочный эффект является необходимым элементом программирования. В итоге мы имеем библиотеку STL, которая на 100% является императивной, но многие идеи которой были заимствованны из ФП. Та же специализация шаблонов C++ построена на term-rewriting и pattern-matching.

Здравствуйте, Gaperton, Вы писали:

G>Что касательно языка Scala, то на сколько я понял, это встроенный язык их ERP-системы для написания бизнес-логики. Совершенно неважно, будет ли он применяться где-то еще, от этого Scala ни жарко ни холодно, им на это просто плевать. Так что я бы за перспективы этого языка сильно не переживал — они слабо зависят от того, что язык "промышленный".
Если ты сделал этот вывод путем выгугливания, то ты скорее ошибся. Это просто совпадение названия.

Здравствуйте, eao197, Вы писали:

E>PS. На мой далекий от Java взгляд, перспективы у Scala стать новым мейнстримовым языком на JVM, гораздо выше, чем у Nemerle/F# на .NET.

похоже, что в 2010-х мы будем иметь противостояние f# против скалы. не забывай, что f# официально продвигается, а это важнее достоинств самого языка

Здравствуйте, VladD2, Вы писали:

VD>Мне больше интересно, что у него с IDE?

Под нетбинз есть вполне юзабельный плагин. http://wiki.netbeans.org/Scala

Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, uw, Вы писали:

uw>>Потому, что на практике чаще используются императивные языки.
Q>Но в функциональных-то языках, они используются реже. А очень часто — список.
uw>>Почему "одни". Да и потом кто сказал, что обязательно должны быть side effects? Многие структуры данных можно реализовать и без них.
Q>Можно. И основная такая структура данных — список.

Типа того. Хочу еще добавить на всякий случай об эффективности встроенных в ФЯ списков.

Встроенные в язык списки вместе с заточенным под них аллокатором — очень быстрая штука. Они потенциально быстрее списков "обычных" языков. Пример чрезвычайно эффективной реализации — Clean. Там менеджер хипа старается располагать элементы одного списка подряд, чтобы при пробежке по списку работала предвыборка. Списки там на реальных алгоритмах не проигрывают по скорости массивам (мерял — чудо какое-то), а массивы в Clean не уступают по скорости массивам VC++ (меряли с WolfHound решетом эратосфена).

Естественно, накладные расходы на сборку мусора в случае списков ФЯ меньше, чем в "обычных" языках, и на аллокацию тоже. Применяются однобитные счетчики ссылок — техника разработанная еще для Лисп; хорошо работает именно на длинных линейных списках (характерно для ФЯ). Плюс, компилятор умеет вычислять места, в которые можно воткнуть явную деаллокацию. Во многих случаях список в программе вообще может быть скомпилирован без применения "списока" — отоптимизится до безобразия. Пример — в случае применения list comprehensions списки часто используются ровно один раз, и могут быть скомпилированны без аллокации настоящих списков. Что в результате будет работать на постоянной памяти.

Так что я хотел отметить следующее. Мало того, что списков в ФЯ много, но они еще и достаточно быстры — быстрее, чем аналогичное использование списков в императивных языках общего назнчения. Так что списки — это не так плохо.

Q>Ну это уже ваша личная точка зрения. С тем же успехом можно сказать, что элементы императивных языков могут значительно помочь в оптимизации функционального кода, если их использовать правильно.
+1

Здравствуйте, Quintanar, Вы писали:

Q>Нельзя жертвовать referential transparency ради мнимой погони за эффективностью.

Извиняюсь за вопрос, но почему вы все в разговоре постоянно используете английскую терминологию? Неужели "прозрачность по ссылкам" чем-то хуже чем "referential transparency".

Q> В программе есть всего лишь несколько мест, где нужна эффективность.

Ага. Одно из таких мест — код. А второе — рантайм.

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

Взять тот же пример быстрой сортировки на Хаскеле. Да, корото, да выглядит привлекательно. Но эффективность у такого решения никакая. Во-первых, сортировка произходит копированием и надежны на супер-интеллектуальный оптимизатор маловато. А, во-вторых, алгоритм банально храмает. Он берет в качестве среднего элемента первый элемент списка. При некоторых обстаятельствах (например, если списко уже отсортирован) — это приведет к ужасным тормозам. Причем если "во-первых" еще как-то можно отдать на откуп очень умного оптимизатору, то "во-вторых" уж точно является алгоритмической проблемой. Массив легко спссает.

Что же касется хэш-таблиц, то — это вообще очень эффективное средство. И не использовать их просто неразумно.

В общем, полностью согласен с uw. Фнциональный подход интересен и полезен во многих случаях но обходиться им всегда смысла не имеет. Для ООП просто нармально когда модифицируется состяние объекта. Ну, глупо подгонять пир под догмы парадигмы. Ну, не создается новое окно когда у него изменяются размеры.

uw>>При этом все забывают, что элементы функциональных языков если их использовать правильно(то есть в ограниченных количествах) могут значительно помочь в оптимизации императивного кода.

Q>Ну это уже ваша личная точка зрения. С тем же успехом можно сказать, что элементы императивных языков могут значительно помочь в оптимизации функционального кода, если их использовать правильно.

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

Вот простой пример из программки которую я давича писал для нашего сата:

static void PatchFile(FileInfo file)
{
    try
    {
        string patchFileName = file.FullName;
        string destName = MakeDestinationName(patchFileName);
        string bakName = MakeBackupName(destName);
    
        if (IsDiff(patchFileName))
        {
            File.Move(destName, bakName);
            Patch.Do(bakName, patchFileName, destName);
        }
        else
        {
            string path = Path.GetDirectoryName(destName);
        
            if (!System.IO.Directory.Exists(path))
                System.IO.Directory.CreateDirectory(path);

            File.Copy(patchFileName, destName);
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
}

const string Signature = "RsdnDiff";
private static UTF8Encoding encoding = new UTF8Encoding();

static bool IsDiff(string file)
{
    using (FileStream reader = File.OpenRead(file))
    {
        byte[] buf = new byte[Signature.Length];
        reader.Read(buf, 0, Signature.Length);
        return Signature == encoding.GetString(buf);
    }
}

static string MakeBackupName(string destName)
{
    string bakName;
    int i = 0;
    do
    {
        bakName = destName + i.ToString("-000") + BakFileExt;
    }
    while (File.Exists(bakName));

    return bakName;
}

static string MakeDestinationName(string patchFileName)
{
    string patchFile = patchFileName.Substring(_patchPath.Length + 1);
    return  Path.Combine(_destinationPath, patchFile);
}

Легко заметить, что пока требуется вычисление строковых значений, то функциональный подход "рулит". Даже некоторые императивные вещи вроде цикла в MakeBackupName можно было бы сделат в функцинальном стиле (хоят это ничего бы не дало), но как только дело доходит до действий (выделенно жирным) то, императивный стиль становится самым удобным. Ну, какой мне смысл в функциональщине когда вся суть программы в создании некого побочного эффекта вроде копирования или перемещения файлов?

Или другой пример. Эта же программа использует алгоритм создания patch-а для создания дифференциального бэкапа. Этот алгоритм для повышения эффективности использует хэкштаблицу 64-битным хэшом. Табличка при создании diff-а на 4-х гигабайтных файлах получается огромной. Процесс жрет под гиг оперативки. И что вы мне прикажете делать без массива? Да на базе связанного списка этот бэкап умир бы или от нехвтаки памяти, или (что еще реальнее) от неимоверных тормозов. Объемы то не шуточные.

Здравствуйте, Gaperton, Вы писали:

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

G>Извини, но по моему скромному мнению, у тебя с головой немного не в порядке.
На самом деле не немного, а сильно.

G>По крайней мере нормальный человеческий разговор ты поддерживать не в состоянии. Всего доброго.
К сожалению не в состоянии.

P.S. Возможно я поторопился назвав Scala интересным языком. Но я такой человек — очень быстро увлекаюсь и так же быстро разочаровываюсь. Ничего поделать с собой не могу. Горбатого только могила исправит.

Здравствуйте, uw, Вы писали:

uw>На мой взгляд этот язык скорее тенденция, чем проект имеющий большое самостоятельное значение. Скажем из других языков, имеющих схожие черты и идеологию я могу назвать Nemerle, Boo(статически типизированный python),Groovy.

uw>Я небезосновательно думаю, что примерно так будут выглядеть промышленные языки лет через пять. В принципе не важно будет ли это Scala или C# X.0, важна сама тенденция.

Согласен. Я тоже пришел к выводу, что это и есть современная тенденция в развитии языков программирования. Обратите внимание:

1) Type inference, делающий необязательным аннотацию типов.
2) Pattern matching — наконец то, господи. Хоть кто-то додумался это в язык включить. Кстати, реальзация паттерн-матчинга до боли напоминает Erlang .
3) Частично строгая типизация — наличие типа Any (что, в сочетании с type inference и pattern matching рулит со страшной силой ). Есть альтернативный подход — динамическая семантика вызова по умолчанию (когда Any не пишется — разница кстати, колоссальная). В этом случае type inference движок будет выводить в том числе и ограничения на тип Any, и мы сможем сделать язык проще, избавившись от полиморфных типов. Впрочем, это усложняет type inference. В мэйнстрим это уже проникло — так сделано в JScript .NET (это совсем не обычный JScript, кстати, не путать).
4) функции высокого порядка, и, наконец-то, сurring .

При этом, отсутствуют встроенные в язык списки и, главное, tuples (чего им стоило добавить в язык tuples? не понимаю). Отсутствие алгебраических типов пережить можно, а вот list и array comprehensions реально жалко.

uw>И на мой взгляд, традиционные функциональные языки начинают отходить в прошлое, так и не успев стать языками промышленной разработки. Об этом говорит хотя бы то, что ocaml.org и haskell.org обновляются в последнее время крайне редко.

А они и не создавались как средство для промышленной разработки. Haskell — учебный язык, OCaml — исследовательский проект. Для промышленной разработки создан и применяется только Erlang. Но он тоже лишь обозначает тенденцию, не более.

uw>Что касается непосредственно Scala, то существует компилятор, с поддержкой Java и .NET. На мой взгляд неюзабельно, так как компилятор невероятно медленный, но сам язык на мой взгляд интереснее большинства существующих ОО функциональных языков.

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

Здравствуйте, Quintanar, Вы писали:

Q>Так в чем, собственно, состоит его прогрессивность? В ОО? Так ОО само по себе, а функциональный подход сам по себе. В xml? Так это вообще бред, не понимаю зачем он вообще нужен.

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

Лексика, кстати, ("вообще бред"), в очередной раз напоминает мне известных "экспертов в философии программирования", которые также не читают документацию в формате pdf .

Для тех, кто не любит читать ссылки, объясню. Кратко — как известно, современные ФЯ весьма хороши в обработке древовидных структур данных, которые описываются рекурсивно. Мотивацией для добавления в язык возможностей, традиционных для ФЯ, послужила необходимость гладкой и простой работы с XML-данными (как в свое время необходимость разработки GUI стимулировала широкое внедрение ООП, на которое GUI ложится великолепно).

Здравствуйте, Gaperton, Вы писали:

G>Язык Scala — промышленный до мозга кости, в этой области ничего не делается просто так, без мотивации — риски слишком велики. Которая описана и разжевана отдельным документом. Ты бы сначала почитал приведенные ссылки, что-ли.

Одна формулировка- промышленный навевает тоску. Сомневаюсь я в перспективах "промышленных" языков, последние языки ставшие популярными были разработаны энтузиастами без каких-либо промышленных целей.

Здравствуйте, Gaperton, Вы писали:

G>В мои цели не входит замешивание Scala с дерьмом.
Правильно, в твои цели видимо входит замешивание меня с дерьмом. Просто ради развлечения.

G>Мне не хочется переводить разговор в плоскость замера, но хочу обратить твое внимание на факт, что если ты чего-нибудь не понимаешь или не знаешь, то "элитарность" сабжа из этого совсем не следует.
Я хочу обратить внимание на тот факт, что если тебе кажется, что я чего то не понимаю или не знаю, то действительное "незнание" сабжа из этого совсем не следует.

G> У "макросов лиспа" и "макросов" общее только слово в названии. Если тебе не нравится слово "макрос", тогда действительно говорить не о чем.
Мне не нравится не слово "макрос", а именно макрос в смысле "макрос лиспа". Я прекрасно осведомлен о том, что именно он из себя представляет, а также о "гигиеничных" макросах Scheme и Nemerle я тоже знаю. Мне не нравится сам подход вызова кода в compile-time по требованию, imho это тупиковая идея. Чуть-чуть усложняем язык и написание такого макроса превращается в катастрофу, так как для term-rewriting по произвольному ast нужно либо очень грамотно сроектировать синтаксис, либо пишущий такой макрос должен очень хорошо знать язык. Эти трюки работали для языков вроде Lisp или Prolog, но сейчас особого интереса не представляют.

G>А. Ну понятно.
Ничего тебе не понятно.

G>А тебя никто в этом и не подозревает. Мне, например, просто любопытно, что это за язык Scala и почему он тебе так нравится.
Мне он не нравится, мне вообще никто и ничего никогда не нравится. Scala просто нравится мне больше чем остальные попытки совместить ОО и ФП. Я считаю, что в этом направлении будут двигаться промышленные языки. Я просто высказал свое мнение, уточнять, объяснять и.т.д. я ничего больше не буду, так как у меня нет никакой личной в этом заинтересованности. Если бы я был автором языка, я бы это делал. А так я получу только заряд отрицательных эмоций и ничего взамен. За то что я дал ссылку на Scala я уже получил один минус, большое спасибо некому beroal.

G>Но это правда. Каждый язык рулит в своем классе задач , который может быть уже или шире.
Это не правда, это твое субъективное мнение. Правды вообще нет.

Здравствуйте, uw, Вы писали:

G>>В мои цели не входит замешивание Scala с дерьмом.
uw>Правильно, в твои цели видимо входит замешивание меня с дерьмом. Просто ради развлечения.
?!

G>>А. Ну понятно.
uw>Ничего тебе не понятно.
??!

G>>А тебя никто в этом и не подозревает. Мне, например, просто любопытно, что это за язык Scala и почему он тебе так нравится.
uw>...уточнять, объяснять и.т.д. я ничего больше не буду, так как у меня нет никакой личной в этом заинтересованности. Если бы я был автором языка, я бы это делал. А так я получу только заряд отрицательных эмоций и ничего взамен. За то что я дал ссылку на Scala я уже получил один минус, большое спасибо некому beroal.



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

Здравствуйте, uw, Вы писали:

uw>Потому, что на практике чаще используются императивные языки.

Но в функциональных-то языках, они используются реже. А очень часто — список.

uw>Почему "одни". Да и потом кто сказал, что обязательно должны быть side effects? Многие структуры данных можно реализовать и без них.

Можно. И основная такая структура данных — список.

uw>На мой взгляд беда функциональных языков это их весьма ограниченный набор структур данных и пуризм, переходящий всякие границы. Там где нужен side-effect free код, там он и должен быть, а где нужен быть побочный эффект, должен быть побочный эффект.

Это смотря в каких языках. В Лиспе вообще нет никаких ограничений на структуры данных. В типизированных ФЯ используется особая система типов, которая намного лучше и гибче системы типов в императивных языках. Собственно, в OCaml есть (вроде бы) все структуры, что есть в C# и даже больше.
Вас, должно быть, ввел в заблуждение Хаскель, это такой язык, на который приятно смотреть, но программировать на нем сложно из-за постоянного гемороя с вводом-выводом. В ML-подобных языках нет таких строгих ограничений на side effects.

uw>Кстати интересно, что большинство новых разработок в функциональных языках касаются устранения накладных расходов, возникающих благодаря отсутствию эксплуатации побочного эффекта и overusing'у таких структур как списки. Скажем те же обычные списки хотят заменить на VList. Не говоря уже о том, что большинство современных ФЯ поддерживают как императивность так и побочные эффекты в той или иной форме. Это необходимость с которой придется свыкнуться, так как без нее нет эффективных программ.

Ну да, поддерживают, но не поощряют. Нельзя жертвовать referential transparency ради мнимой погони за эффективностью. В программе есть всего лишь несколько мест, где нужна эффективность.

uw>При этом все забывают, что элементы функциональных языков если их использовать правильно(то есть в ограниченных количествах) могут значительно помочь в оптимизации императивного кода.

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

Здравствуйте, uw, Вы писали:

uw>Ленивых списков в Scala вроде бы нет, равно как и в доброй половине "современных ФЯ".

Думаю, что ты ошибашся. Наличие yield недвусмысленно намекает на схожеть с yield извесных скриптовых языках и yield return в C# 2.0. А и там, и там с помощью этого оператора влет реализуются линивые списки. Ведь линивость можно рассматривать как точку зрения на потоковую (stream) модель. Поток можно рассматривать как линивую функцию. так что достаточно написать нечто вроде:

for (int i = 0;; i++)
    yield i;

и линивость у нас в кармане. По крайне мере на C# вот ткой код:

IEnumerator<int> Range(int start)
{
    for (int i = start;; i++)
        yield return i;
}

породит тот самый линивый список элементы которого будут генерироваться всякий раз когда мы их требуем.

uw> Намек "тебе не надо" понятен. Чего я больше всего не люблю — претензий на элитарность.

+1

uw> В форуме C++ тебе будут объяснять, что библиотеки boost это высшее достижение C++,

Скорее всего человечества.

uw> доказывающее уникальные возможности языка. В форуме "Декларативное Программирование" теперь говорят, что ленивые списки определяют "некосметическую разницу".

Ну, все же вещь удобная. Хотя в догму превращать или делать их особенностью ФЯ и на базе этого строить превосходство ФЯ на вем остальым просто глупо. Ни списки, ни их линивость не являются заслугой ФЯ. Как паттерн их можно реализовать в любом ИЯ. Да и в некоторые ИЯ ичи вроде линивых списков (потоков, итероторов или назовите их как хотите) тоже встроены, а многие ФЯ (а то и их отдельные реализации) не обладают линивостью.

uw>Нет я не удивлен этим фактом, объяснить пожалуй смогу, но не хочу. Если вкратце, то я вижу в Scala и ему подобных языках реальную альтернативу C# и Java.

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

uw>Мне было бы интересно устранить метапрограммирование как явление, сделав его частью обычного программирования,

О! Тут мы с тобой просто сходимся на 100%.

G>>Чем плох Lisp, например, в вариантах CLisp и CMU Lisp?
uw>Если в плане метапрограммирования, то мне не нравятся макросы в любом виде.

Ну, название "макросы" к ним прилипло по недаразумению.

uw> Я видел достаточно много "систем метапрограммирования" построенных на разного рода макросах и они не вызывают у меня положительных эмоций. Мне даже больше импонируют шаблоны C++, хотя сказать что я их люблю можно только с большой натяжкой.

Шаблоны тоже можно рассматривать с некоторой точки зрения как макросы... синтаксически управлямемы. Так что можно согласиться с Gaperton-ом в том плане, что МП в клонах Лиспа достигла очень больших высток. Вот только сам лисп — это довольно убокая пародия на программирование в AST.

uw>Если как язык, то единственный минус — неудобно. Я имел несчастье познакомиться с Prolog раньше чем с Lisp, поэтому считаю, что Lisp отстой.

А я позже, но того же мнения. Префиксные операторы, отсуствие типизации, отвсутсвтие полноценных структур данных, поря скобок, дебильные названия вроде CAR и т.п. не дают возможность спокойно воспринимать код на этом языке. А дресировать себя в распознавании иероглифов при наличии более вменяемых языков неохота.

G>>Язык Scala тоже предназначен для решения узкого класса задач — написания бизнес-логики ERP систем.
uw>Ну если считать, что C# и Java предназначены для этого же класса задач, тогда да. Но на практике C# и Java используются как general purpose языки. А вообще все что касается бизнес-логики и ERP-, CRM- итд, то это чем я буду заниматься в последнюю очередь.

Кстати, сами разработчики позиционируют C# именно как универсальный язык. Просто им не особо дают прзговориться маркетологи. А с ERP все обясняется просто. Самый богатый и большой рынок — это софт для бизнеса и его местная автоматизация. ERP и т.п. пишут и на С++, и на C# и даже на Лиспе. Так что попадание в этот сегмент просто гарантирует рельную распространненость.

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

Здравствуйте, VladD2, Вы писали:

VD>Кстати, функционалы и есть то что дает возможность использования функционального стиля. А все фичи вроде паттерн-матчинга или встроенной работы со списками всего лишь синтаксический сахар. Вот в лиспе почти ничего этого нет, но когда речь заходит о ФЯ, то сразу вспоминают Лисп.

А Лисп не ФЯ. Он поддерживает императивный стиль на равне с функциональным. Что же касается PM, то его на Лиспе можно реализовать с помощью макросов — в книге On Lisp приведена одна из возможных реализаций.

Я твои письма не читаю давно, читать их не собираюсь, и отвечать тем более. Можешь не стараться.

Здравствуйте, Quintanar, Вы писали:

Q>Ну так в Лиспе можно и в императивном стиле писать. Приветствуется функциональный стиль, но ислючительно из-за того, что он позволяяет создать код менее подверженный ошибкам.

Однако императивный код на Лиспе выглядит совсе уж стрнанно.

Здравствуйте, uw, Вы писали:


Скажите, почему Scala это только компилятор для JVM? Почему Microsoft не может сделать компилятор со Scala в высокопроизводительный код C++? Только из-за сборщика мусора JVM? Но можно ведь в компилятор встроить счетчик ссылок, уже не 1979 год на дворе

Так в чем, собственно, состоит его прогрессивность? В ОО? Так ОО само по себе, а функциональный подход сам по себе. В xml? Так это вообще бред, не понимаю зачем он вообще нужен.

Здравствуйте, Quintanar, Вы писали:

Q>Так в чем, собственно, состоит его прогрессивность? В ОО? Так ОО само по себе, а функциональный подход сам по себе. В xml? Так это вообще бред, не понимаю зачем он вообще нужен.

Что бред? XML сам по себе или XML в такой комбинации?

А вообще это ведь только идеи...
К чему такая реакция?

Здравствуйте, Gaperton, Вы писали:

G>При этом, отсутствуют встроенные в язык списки и, главное, tuples (чего им стоило добавить в язык tuples? не понимаю). Отсутствие алгебраических типов пережить можно, а вот list и array comprehensions реально жалко.
По поводу tuples. Во-первых сами классы могут в паттерн-мэтчинге выполнять роль tuples. При этом tuples это как бы экземпляры анонимных generic классов с n-ым числом аргументов конструктора. Imho использование анонимных классов не оправданно, в крайнем случае есть классы вроде Pair и TupleN.

Теперь по поводу списков. Списки это хорошо, но на практике чаще используются динамические массивы, строки, словари(rb-trees, tries, hash-tables). Поэтому дизайнеры Scala поступили достаточно мудро. Есть generic trait(что-то вроде интерфейса) Seq[T], он и выполняет роль "встроенного списка". Паттерн-мэтчинг по Seq[T] поддерживается, даже есть аналог list comprehensions, конечно слабый, но реализованный на уровне библиотеки(!). Кроме того есть связка anonymous closures + возможность использования методов как инфиксных операторов, при помощи нее можно реализовать любой вид comprehensions.

На мой взгляд интересно уже то, что я бы не отказался от использования такого языка как Scala(при наличии нормального компилятора) в реальном проекте. Чего я до сих пор не мог сказать ни об одном функциональном языке(и даже о ряде не функциональных, таких как Smalltalk или Cecil), фичи которого есть в этом самом коктейле. Erlang конечно чемпион по промышленному применению, но у него своя специфика, которая к сожалению слабо пересекается с большинством прикладных задач.

Здравствуйте, uw, Вы писали:

uw>Теперь по поводу списков. Списки это хорошо, но на практике чаще используются динамические массивы, строки, словари(rb-trees, tries, hash-tables). Поэтому дизайнеры Scala поступили достаточно мудро. Есть generic trait(что-то вроде интерфейса) Seq[T], он и выполняет роль "встроенного списка". Паттерн-мэтчинг по Seq[T] поддерживается, даже есть аналог list comprehensions, конечно слабый, но реализованный на уровне библиотеки(!). Кроме того есть связка anonymous closures + возможность использования методов как инфиксных операторов, при помощи нее можно реализовать любой вид comprehensions.

А вы сами писали что-нибуль на нормальном Ф.Я.? Почему вы думаете, что на практике чаще используются массивы и хеши? Я вот могу сказать, что массивы вообще почти не нужны (кроме спец задач, когда они действительно нужны). Хеши тоже нужны только изредка. Я откровенно говоря вообще не представляю, что в языке останется функционального, если не будет списков, а будут одни типы с side effects.

Здравствуйте, uw, Вы писали:

uw>Здравствуйте, Gaperton, Вы писали:

G>>При этом, отсутствуют встроенные в язык списки и, главное, tuples (чего им стоило добавить в язык tuples? не понимаю). Отсутствие алгебраических типов пережить можно, а вот list и array comprehensions реально жалко.
uw>По поводу tuples. Во-первых сами классы могут в паттерн-мэтчинге выполнять роль tuples. При этом tuples это как бы экземпляры анонимных generic классов с n-ым числом аргументов конструктора. Imho использование анонимных классов не оправданно, в крайнем случае есть классы вроде Pair и TupleN.

Tuples нужны хотя бы для того, чтобы возврящать несколько значений из функции. В сочетании с pattern matching это работает так:
( FirstRes, SecondRes ) = function( arguments );
И все. Просто и красиво. Если так можно писать в Scala, то нормально. Если это делается через зад, то это неудобно.

uw>Теперь по поводу списков. Списки это хорошо, но на практике чаще используются динамические массивы, строки, словари(rb-trees, tries, hash-tables). Поэтому дизайнеры Scala поступили достаточно мудро. Есть generic trait(что-то вроде интерфейса) Seq[T], он и выполняет роль "встроенного списка". Паттерн-мэтчинг по Seq[T] поддерживается, даже есть аналог list comprehensions, конечно слабый, но реализованный на уровне библиотеки(!). Кроме того есть связка anonymous closures + возможность использования методов как инфиксных операторов, при помощи нее можно реализовать любой вид comprehensions.

То, что по твоей ссылке дано, достаточно мутновато. То, что можно паттерн-матчить сиквенсы произвольного типа, это реально круто. Здесь отдыхают все известные мне языки. Но как-то убого это... Например, я не нашел в твоей ссылке comprehensions.

Вот смотри — так в Clean пишется массив квадратов индексов из 10 элементов:
{ n * n \\ n <- [0..10] }
Удобно. Можно так в Scala?

А вот так в Erlang разбирается бинарный пакет:
<< Version/int:8, "Scala", Lenght/int:16, Rest_of_data/binary >>
Обрати внимание — тип является частью паттерна при разборе последовательности. Как это быдет выглядеть в Scala?
А "ленивый" список я в Scala реализовать смогу? Возможно, тебе этого не надо, а мне — дает массу интересных возможностей, которые и определяют некосметическую разницу между современными ФЯ и обычными языками.

uw>На мой взгляд интересно уже то, что я бы не отказался от использования такого языка как Scala(при наличии нормального компилятора) в реальном проекте.
То есть ты сам удивлен этим фактом, и не можешь его объяснить? Ну давай, колись тогда почему, раз это тебе интересно. По твоим прошлым постам мне кажется, что тебе интересно метапрограммирование. Чем плох Lisp, например, в вариантах CLisp и CMU Lisp?

uw>Чего я до сих пор не мог сказать ни об одном функциональном языке(и даже о ряде не функциональных, таких как Smalltalk или Cecil), фичи которого есть в этом самом коктейле. Erlang конечно чемпион по промышленному применению, но у него своя специфика, которая к сожалению слабо пересекается с большинством прикладных задач.

Я был бы осторожен на счет "большинства прикладных задач". Ты их, в конце концов не считал. Язык Scala тоже предназначен для решения узкого класса задач — написания бизнес-логики ERP систем. С моими задачами он пересекается весьма слабо. А вот Erlang пересекается гораздо лучше. Но пишу я все равно на С++ .

Здравствуйте, Quintanar, Вы писали:

G>>Язык Scala — промышленный до мозга кости, в этой области ничего не делается просто так, без мотивации — риски слишком велики. Которая описана и разжевана отдельным документом. Ты бы сначала почитал приведенные ссылки, что-ли.

Q>Одна формулировка- промышленный навевает тоску. Сомневаюсь я в перспективах "промышленных" языков, последние языки ставшие популярными были разработаны энтузиастами без каких-либо промышленных целей.

Это ты о чем — C, C++, Java, C#, VB ?...
Или все "последние языки" — это Perl?

Здравствуйте, Gaperton, Вы писали:

G>Вот смотри — так в Clean пишется массив квадратов индексов из 10 элементов:
G>{ n * n \\ n <- [0..10] }
G>Удобно. Можно так в Scala?

Так нельзя, можно так:

    for (val n <- List.range(0, 10)) yield n * n;

Я немного спутал мэтчинг и comprehensions,которые в Scala тоже есть.

G>А вот так в Erlang разбирается бинарный пакет:
G><< Version/int:8, "Scala", Lenght/int:16, Rest_of_data/binary >>
G>Обрати внимание — тип является частью паттерна при разборе последовательности. Как это быдет выглядеть в Scala?
В мои цели не входит реклама и пропаганда Scala с написанием примеров и сравнений, тем более что знаю я его даже несколько хуже чем Erlang. И кстати в будущем писать на нем ничего не планирую.

G>А "ленивый" список я в Scala реализовать смогу? Возможно, тебе этого не надо, а мне — дает массу интересных возможностей, которые и определяют некосметическую разницу между современными ФЯ и обычными языками.
Ленивых списков в Scala вроде бы нет, равно как и в доброй половине "современных ФЯ". Намек "тебе не надо" понятен. Чего я больше всего не люблю — претензий на элитарность. В форуме C++ тебе будут объяснять, что библиотеки boost это высшее достижение C++, доказывающее уникальные возможности языка. В форуме "Декларативное Программирование" теперь говорят, что ленивые списки определяют "некосметическую разницу".

G>То есть ты сам удивлен этим фактом, и не можешь его объяснить? Ну давай, колись тогда почему, раз это тебе интересно.
Нет я не удивлен этим фактом, объяснить пожалуй смогу, но не хочу. Если вкратце, то я вижу в Scala и ему подобных языках реальную альтернативу C# и Java.

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

G>Чем плох Lisp, например, в вариантах CLisp и CMU Lisp?
Если в плане метапрограммирования, то мне не нравятся макросы в любом виде. Я видел достаточно много "систем метапрограммирования" построенных на разного рода макросах и они не вызывают у меня положительных эмоций. Мне даже больше импонируют шаблоны C++, хотя сказать что я их люблю можно только с большой натяжкой.

Если как язык, то единственный минус — неудобно. Я имел несчастье познакомиться с Prolog раньше чем с Lisp, поэтому считаю, что Lisp отстой.

G>Язык Scala тоже предназначен для решения узкого класса задач — написания бизнес-логики ERP систем.
Ну если считать, что C# и Java предназначены для этого же класса задач, тогда да. Но на практике C# и Java используются как general purpose языки. А вообще все что касается бизнес-логики и ERP-, CRM- итд, то это чем я буду заниматься в последнюю очередь.

G>С моими задачами он пересекается весьма слабо. А вот Erlang пересекается гораздо лучше. Но пишу я все равно на С++ .
А с моими задачами ничего кроме C++ пока вообще не пересекается. У меня не стоит цели кому-то доказать, что тот или иной язык подходит для тех или иных задач лучше или хуже чем другие. Более того я вообще против настолько упрощенного подхода к языкам программирования — мол, язык X предназначен для решения Y класса задач, например написания Z каких-то там систем.

Здравствуйте, uw, Вы писали:

uw>Я немного спутал мэтчинг и comprehensions,которые в Scala тоже есть.
Это уже лучше. Вроде получается похоже на нормальный язык тогда. Хотя немного громоздко, но это дело привычки.

G>>А вот так в Erlang разбирается бинарный пакет:
G>><< Version/int:8, "Scala", Lenght/int:16, Rest_of_data/binary >>
G>>Обрати внимание — тип является частью паттерна при разборе последовательности. Как это быдет выглядеть в Scala?
uw>В мои цели не входит реклама и пропаганда Scala с написанием примеров и сравнений, тем более что знаю я его даже несколько хуже чем Erlang. И кстати в будущем писать на нем ничего не планирую.
Жаль. Если ты уже разобрался с языком, то мог бы момочь мне съэкономить немного времи, например . В мои цели не входит замешивание Scala с дерьмом. Простое любопытство.

G>>А "ленивый" список я в Scala реализовать смогу? Возможно, тебе этого не надо, а мне — дает массу интересных возможностей, которые и определяют некосметическую разницу между современными ФЯ и обычными языками.
uw>Ленивых списков в Scala вроде бы нет, равно как и в доброй половине "современных ФЯ". Намек "тебе не надо" понятен. Чего я больше всего не люблю — претензий на элитарность. В форуме C++ тебе будут объяснять, что библиотеки boost это высшее достижение C++, доказывающее уникальные возможности языка. В форуме "Декларативное Программирование" теперь говорят, что ленивые списки определяют "некосметическую разницу".

Намека никакого не было. Не понимаю, с каких это пор штатный механизм ФЯ — "ленивые" конструкторы данных являются у нас признаком элитарности? Без них вообще-то очень плохо — они необходимы для того, чтобы нормально структурировать функциональную программу, и на них, к слову, основаны многие чисто функциональные структуры данных и алгоритмы.

То, что ты принял за "отсутствие ленивых списков в доброй половине языков", является на самом деле строгой семантикой вызова по умолчанию , не более того. Мне не хочется переводить разговор в плоскость замера, но хочу обратить твое внимание на факт, что если ты чего-нибудь не понимаешь или не знаешь, то "элитарность" сабжа из этого совсем не следует.

Ленивые списки есть в OCaml, LazyML, Haskell, Miranda, Clean, и в Lisp. В Erlang их нет по одной единственной причине — это язык для написания real-time систем, и в нем нет конструкций с непредсказуемым временем выполнения, да и то — они в нем симулируются при большом желании посредством функций высокого порядка.

G>>То есть ты сам удивлен этим фактом, и не можешь его объяснить? Ну давай, колись тогда почему, раз это тебе интересно.
uw>Нет я не удивлен этим фактом, объяснить пожалуй смогу, но не хочу. Если вкратце, то я вижу в Scala и ему подобных языках реальную альтернативу C# и Java.

Напрасно не хочешь. Потому что любопытен не факт того, что ты готов на нем писать или видишь альтернативу, а причины этого желания . Факт мало кому интересен.

G>>По твоим прошлым постам мне кажется, что тебе интересно метапрограммирование.
uw>Мне было бы интересно устранить метапрограммирование как явление, сделав его частью обычного программирования, но это совсем другой разговор и никакого отношение к Scala это не имеет.
Я просто пытаюсь догадаться о причинах.

G>>Чем плох Lisp, например, в вариантах CLisp и CMU Lisp?
uw>Если в плане метапрограммирования, то мне не нравятся макросы в любом виде. Я видел достаточно много "систем метапрограммирования" построенных на разного рода макросах и они не вызывают у меня положительных эмоций. Мне даже больше импонируют шаблоны C++, хотя сказать что я их люблю можно только с большой натяжкой.
У "макросов лиспа" и "макросов" общее только слово в названии. Если тебе не нравится слово "макрос", тогда действительно говорить не о чем.

uw>Если как язык, то единственный минус — неудобно. Я имел несчастье познакомиться с Prolog раньше чем с Lisp, поэтому считаю, что Lisp отстой.
А. Ну понятно.

G>>Язык Scala тоже предназначен для решения узкого класса задач — написания бизнес-логики ERP систем.
uw>Ну если считать, что C# и Java предназначены для этого же класса задач, тогда да. Но на практике C# и Java используются как general purpose языки. А вообще все что касается бизнес-логики и ERP-, CRM- итд, то это чем я буду заниматься в последнюю очередь.

Если так считать — то да. Есть только один нюанс — С# с Java для этого совсем не предназначены, они изначально разработанны как general purpose языки исключая задачи системного программирования и soft real-time. Со всеми вытекающими.

G>>С моими задачами он пересекается весьма слабо. А вот Erlang пересекается гораздо лучше. Но пишу я все равно на С++ .
uw>А с моими задачами ничего кроме C++ пока вообще не пересекается. У меня не стоит цели кому-то доказать, что тот или иной язык подходит для тех или иных задач лучше или хуже чем другие.
А тебя никто в этом и не подозревает. Мне, например, просто любопытно, что это за язык Scala и почему он тебе так нравится.

uw>Более того я вообще против настолько упрощенного подхода к языкам программирования — мол, язык X предназначен для решения Y класса задач, например написания Z каких-то там систем.
Но это правда. Каждый язык рулит в своем классе задач , который может быть уже или шире.

Здравствуйте, Quintanar, Вы писали:

G>>Язык Scala — промышленный до мозга кости, в этой области ничего не делается просто так, без мотивации — риски слишком велики. Которая описана и разжевана отдельным документом. Ты бы сначала почитал приведенные ссылки, что-ли.
Q>Одна формулировка- промышленный навевает тоску. Сомневаюсь я в перспективах "промышленных" языков, последние языки ставшие популярными были разработаны энтузиастами без каких-либо промышленных целей.
Ну во первых, меня лично популярность волнует не так сильно, как тебя. Качество продукта и поддержки + наличие библиотек и средств разработки + удобство для задачи для меня гораздо важнее, чем осознание того, что твой язык самый популярный. С этой точки зрения я оцениваю и перспективы.

Что касательно языка Scala, то на сколько я понял, это встроенный язык их ERP-системы для написания бизнес-логики. Совершенно неважно, будет ли он применяться где-то еще, от этого Scala ни жарко ни холодно, им на это просто плевать. Так что я бы за перспективы этого языка сильно не переживал — они слабо зависят от того, что язык "промышленный".

Здравствуйте, uw, Вы писали:

Q>>Почему вы думаете, что на практике чаще используются массивы и хеши?
uw>Потому, что на практике чаще используются императивные языки.
Тавтология. Игра словами. На практике используется чаще всего то, что используется чаще всего.

uw>На мой взгляд беда функциональных языков это их весьма ограниченный набор структур данных и пуризм, переходящий всякие границы. Там где нужен side-effect free код, там он и должен быть, а где нужен быть побочный эффект, должен быть побочный эффект.
Все нормално там со структурами данных. Что касательно побочных эффектов — они допускаются и являются нормой в большинстве ФЯ. Side-effects запрещены только в Haskell и Clean, в которых при этом все равно можно без труда писать императивный по сути и виду код.

uw>Кстати интересно, что большинство новых разработок в функциональных языках касаются устранения накладных расходов, возникающих благодаря отсутствию эксплуатации побочного эффекта и overusing'у таких структур как списки. Скажем те же обычные списки хотят заменить на VList.
Это естественно, ничего особенно интересного и spectacular в этом нет. Многие из новых и старых разработок в ФЯ касаются технологии эффективного выполнения функциональных программ.

uw>Не говоря уже о том, что большинство современных ФЯ поддерживают как императивность так и побочные эффекты в той или иной форме. Это необходимость с которой придется свыкнуться, так как без нее нет эффективных программ.
В той или иной форме — все языки поддерживают императивность и побочные эффекты. Иначе они не смогли бы выполнять ввод-вывод. Так что все нормально, все с этим давно "свыклись". Тебе не надо никого в этом убеждать.

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

uw> Хороший пример — STL. Степанов сначала интересовался функциональными языками, но пришел к выводу, что побочный эффект является необходимым элементом программирования. В итоге мы имеем библиотеку STL, которая на 100% является императивной, но многие идеи которой были заимствованны из ФП. Та же специализация шаблонов C++ построена на term-rewriting и pattern-matching.
Единственное, что есть в STL похожего на механизмы ФЯ — это использование функций высокого порядка, и параметрических типов, что к функциональным языкам имеет опосредованное отношение. Все. Настоящей "функциональности", в том виде, как она подразумевается в ФЯ, в ней ноль, причем полный. Библиотека и вправду получилась хороша, но это вообще никак не доказывает и не опровергает твой тезис.

Здравствуйте, uw, Вы писали:

uw>Здравствуйте, Gaperton, Вы писали:

G>>Что касательно языка Scala, то на сколько я понял, это встроенный язык их ERP-системы для написания бизнес-логики. Совершенно неважно, будет ли он применяться где-то еще, от этого Scala ни жарко ни холодно, им на это просто плевать. Так что я бы за перспективы этого языка сильно не переживал — они слабо зависят от того, что язык "промышленный".
uw>Если ты сделал этот вывод путем выгугливания, то ты скорее ошибся. Это просто совпадение названия.
Серьезно?! Блин, ни хрена себе .

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

Здравствуйте, Gaperton, Вы писали:

G>Тавтология. Игра словами.
А я люблю играть со словами и ничего предосудительного в этом не нахожу.

G>Мне нравится выделенный оборот . Кто это забывает? С чего ты вообще это взял? Как это элементы функциональных языков могут оптимизировать императивный код? Что-то вообще непонятное ты говоришь.

Не могут оптимизировать, а могут помочь в оптимизации, в первую очередь компилятору, а во вторую программисту.
1. Функциональные программы — это композиция функций.
Из этого следует ->
— Бесплатный inline и intrinsic functions
— Значительно проще отследить использование констант и организовать constant folding и partial evaluation.
— Информация об отсутствие побочного эффекта позволяет не задумываться о внезапном изменении данных
— Упрощение параллелизации кода при помощи SIMD
Вот пример

Автор: uw
Дата: 09.07.04

того, как применение рекурсии "помогло" компилятору C++ соптимизировать операцию с константным массивом до константы. Цикл он к слову так оптимизировать не может, так как потребовалась бы прямая интерпретация.

2. Term-rewriting + patern-matching
Это вообще основа большинства оптимизаций, связанных с вычислительными задачами.

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

А если ты вообще не понимаешь о чем я говорю, пойди почитай диссертацию Todd Veldhuizen под названием Active Libraries and Universal Languages.

uw>> Хороший пример — STL. Степанов сначала интересовался функциональными языками, но пришел к выводу, что побочный эффект является необходимым элементом программирования. В итоге мы имеем библиотеку STL, которая на 100% является императивной, но многие идеи которой были заимствованны из ФП. Та же специализация шаблонов C++ построена на term-rewriting и pattern-matching.
G>Единственное, что есть в STL похожего на механизмы ФЯ -
Неважно, что в ней есть. Важно, что ФЯ были для STL перво-источником. Как эти идеи трансформировались и что в итоге получилось это другой вопрос.

Здравствуйте, uw, Вы писали:

uw>- Информация об отсутствие побочного эффекта позволяет не задумываться о внезапном изменении данных

Или наоборот контролировать ситуации вроде:

someStr.Replace("x", "Y");

одна из самых частых ошибок при програмировании на дотнете. Каждый месяц появляется орел который удивляется почему в подобном коде someStr остается не изменной.

uw>2. Term-rewriting + patern-matching
uw>Это вообще основа большинства оптимизаций, связанных с вычислительными задачами.

Скорее приятный синтаксический сахар. Однако в ФЯ patern-matching обычно связан как раз с работй со списками (строенными операциями).

uw>Кроме того задача метапрограммирования это в первую очередь оптимизация, причем не важно оптимизация по скорости или степени компактности кода. А парадигмы для метапрограммирования более подходящей чем ФП пока не существует.

Вот тут ты заблуждашся. Метапрограммирование — это модификация или порождение программы программой. Это возможно и в импиративном стиле. Даже иперативно это делать проще. Все же проще заменить пару ветков в АСТ чем выполнять трансформации генерирующие цликом новое АСТ.

uw>А если ты вообще не понимаешь о чем я говорю, пойди почитай диссертацию Todd Veldhuizen под названием Active Libraries and Universal Languages.

Думаю он понимает. Просто громного ненавидит все императивное и явно против расширения императивных языков функциональными возможностями. Ну, не нравятся они ему.

uw>Неважно, что в ней есть. Важно, что ФЯ были для STL перво-источником. Как эти идеи трансформировались и что в итоге получилось это другой вопрос.

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

Здравствуйте, Gaperton, Вы писали:

G>Там менеджер хипа старается располагать элементы одного списка подряд, чтобы при пробежке по списку работала предвыборка. Списки там на реальных алгоритмах не проигрывают по скорости массивам (мерял — чудо какое-то), а массивы в Clean не уступают по скорости массивам VC++ (меряли с WolfHound решетом эратосфена).

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

Что касается эротосфенов, то это все не очень показательно. И задача слишком изветная (под нее можно было и "закладку" сбацать), и суть ее вычислительная. Попробуй ради интереса например вот этот

Автор: McSeem2
Дата: 14.01.05

алгоритм на том же Clean реализовать.

Ну, и еще. Clean что-то никто в качестве идеального ФЯ не продвигает. Примеры обычно на Хаскеле или Окамле придятся, а тесты на Clean. Стало быть хороший оптимизатор только у некоторых реализаций Clean имеются. А жить то хочется сегодня и пользоваться нужно тем что нравится, а не тем что получится. Если есть нормальные массивы и приличная поддержка импиративности, то всегда можно состряпать реализацию наиболее узких мест в близком к идеальному виде. Ты же предлагаешь надеяться на чудиса оптимизации и уповать на комплитор.

Здравствуйте, Gaperton, Вы писали:

G>Вот смотри — так в Clean пишется массив квадратов индексов из 10 элементов:
G>{ n * n \\ n <- [0..10] }
G>Удобно. Можно так в Scala?

G>А вот так в Erlang разбирается бинарный пакет:
G><< Version/int:8, "Scala", Lenght/int:16, Rest_of_data/binary >>
G>Обрати внимание — тип является частью паттерна при разборе последовательности. Как это быдет выглядеть в Scala?
G>А "ленивый" список я в Scala реализовать смогу? Возможно, тебе этого не надо, а мне — дает массу интересных возможностей, которые и определяют некосметическую разницу между современными ФЯ и обычными языками.

И что в этих примерах функционального? А если можно будет так:

foreach (i in [0..10])
{
    ...
}

то — это не так круто?

Это прямейшая подмена понятий. За фичи ФЯ выдаются фичи из конкретных ФЯ. В чем проблема поиметь те же фичи даже в языках без намека на ФС?

Здравствуйте, Gaperton, Вы писали:

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

Здравствуйте, VladD2, Вы писали:

VD>Извиняюсь за вопрос, но почему вы все в разговоре постоянно используете английскую терминологию? Неужели "прозрачность по ссылкам" чем-то хуже чем "referential transparency".

А не всегда вспоминаю русский термин.

VD>Если серьезно, то программы разные бывают. Если ты ради удовольствия делаешь мелкие программки, то может тебе и не выжна их эффективность. Соглашусь даже, что во многих ГУИ-программах и т.п. эффективности современных процессоров хватает с запасом и не эффективность выполнения можн плевать. Но бываю же библиотеки или разные числодробильные и обрабатывающие окромные объемы данных алгоритмы. И тут список может сиграть не лучшую роль.

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

VD>Что же касется хэш-таблиц, то — это вообще очень эффективное средство. И не использовать их просто неразумно.

Естественно, эффективное. Но не может являться заменой списку.

VD>В общем, полностью согласен с uw. Фнциональный подход интересен и полезен во многих случаях но обходиться им всегда смысла не имеет. Для ООП просто нармально когда модифицируется состяние объекта. Ну, глупо подгонять пир под догмы парадигмы. Ну, не создается новое окно когда у него изменяются размеры.

ООП не свет в окошке. У него свои ограничения. Кроме того, отдельные ФЯ реализуют объектную модель, некоторые ее даже сильно расширяют.


VD>Или другой пример. Эта же программа использует алгоритм создания patch-а для создания дифференциального бэкапа. Этот алгоритм для повышения эффективности использует хэкштаблицу 64-битным хэшом. Табличка при создании diff-а на 4-х гигабайтных файлах получается огромной. Процесс жрет под гиг оперативки. И что вы мне прикажете делать без массива? Да на базе связанного списка этот бэкап умир бы или от нехвтаки памяти, или (что еще реальнее) от неимоверных тормозов. Объемы то не шуточные.

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

Здравствуйте, Quintanar, Вы писали:

Q>А Лисп не ФЯ. Он поддерживает императивный стиль на равне с функциональным.

Ну, тогда ФЯ не существует в природе, так как есть эксперементы по императивному программированию даже на Хаскеле.

Если серьезно, то Лисп не просто ФЯ. Это прородитель всех ФЯ. Ну, а то что у многих его диалектов есть императивные расширения, так это всего лишь приблизить язык к реальностям жизни.

Я думаю, что отнесение языка к ФЯ или ИЯ делается скорее на основании принятого по умолчания стиля.

Q> Что же касается PM, то его на Лиспе можно реализовать с помощью макросов — в книге On Lisp приведена одна из возможных реализаций.

Тогда поздравляю все так как ПМ можно реализовать везде.

Здравствуйте, Quintanar, Вы писали:

Q>А не всегда вспоминаю русский термин.

Проблема в том, что этот форум читают многие не кто не силен в терминалогии. Руский термин понятен сам по себе, а английский требует намного больших усилий в понимании.

Возможно стоит создать некий глосарий терминов.

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

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

Q>Естественно, эффективное. Но не может являться заменой списку.

Дык разные коллекции на то и разные, чтобы дополнять друг-друга, а не заменять. Хэш-таблица, бинарное дерево, массив, связанный список, и т.п. все они обладают совоими особенностями. Многие из них взаимозаменяемые, но в конкретных условиях всегда предпочтителен однин конкретный тип коллекции. Так зачем же мне ограничиваться только связанным списком?

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

Q>ООП не свет в окошке. У него свои ограничения.

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

Q>Кроме того, отдельные ФЯ реализуют объектную модель, некоторые ее даже сильно расширяют.

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

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

Q>А я и не предлагал использовать списки всегда и везде. Смотреть нужно по задаче, просто для утилитарных нужд они идеальны.

Ну, а тогда получается, что нужно внедрять все коллекции и стало быть без императивного стиля никуда не денешся. В общем, повторюсь, по-моему, будующее за гибридами. Важен сам факт понятия декларативности. А уж как там все это реализовано внутри — это дело десятое.

Здравствуйте, Gaperton, Вы писали:

G>Я твои письма не читаю давно, читать их не собираюсь, и отвечать тем более. Можешь не стараться.

Ты думашь весь мир крутится лично вокруг тебя?

Здравствуйте, VladD2, Вы писали:

VD>Если серьезно, то Лисп не просто ФЯ. Это прородитель всех ФЯ. Ну, а то что у многих его диалектов есть императивные расширения, так это всего лишь приблизить язык к реальностям жизни.

Лиспов много. Первый, самый простой может и был прародителем, а Common Lisp не просто имеет императивные расширения, они там у него поставлены во главу угла. Второй широко используемый диалект — Emacs Lisp тоже императивно ориентированный, что и не удивительно.

VD>Я думаю, что отнесение языка к ФЯ или ИЯ делается скорее на основании принятого по умолчания стиля.

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

Здравствуйте, VladD2, Вы писали:

VD>Возможно стоит создать некий глосарий терминов.

Возможно.

VD>Дык разные коллекции на то и разные, чтобы дополнять друг-друга, а не заменять. Хэш-таблица, бинарное дерево, массив, связанный список, и т.п. все они обладают совоими особенностями. Многие из них взаимозаменяемые, но в конкретных условиях всегда предпочтителен однин конкретный тип коллекции. Так зачем же мне ограничиваться только связанным списком?

Я и не предлагаю ограничиваться списком (речь была о том, что в Scala, претендующем на функциональность, их нет). Хотя и списки бывают разные, в том же Лиспе список гораздо более императивная конструкция — его можно замыкать на самого себя, модифицировать cons cells (нельзя сказать элементы). С таким списком и хештаблицей вообще ничего больше не нужно.

VD>Дык или они становятся гибридами, или начинаются "подгонки мира под себя" в том смысле, что появляются объекты порождающие свои клоны при каждой модификации. Это явно догматизм. Если это сделано как дополнительная фича, то замечательно. Но если это возводится в разряд концепции... Как раз эта Скала и интересна тем, что она не подавляет ООП и императивность в языке. Она просто предоставляет возможности эффективно программировать в функциональном стиле. Опять же соглашусь с uw — может это и не свет в окошке, но само направление очень правильное и за ним будущее.

Ни в OCaml, ни в Lisp копирование не производится, если нет на то особого желания, конечно.

VD>Кстати, для мнея было очень интересно как они разбирутся с операторами. Мне казалось кривым решением делать операторы экземплярными методами. Однако похоже это все же работает. Тому же шарпу очень нехватает подобного решения.

Это ты о чем?

Здравствуйте, Quintanar, Вы писали:

Q>Я и не предлагаю ограничиваться списком (речь была о том, что в Scala, претендующем на функциональность, их нет).

Кого нет в Скале? Скала предоставляет кучу реализаций списков плюс о всему она позволяет использовать коллекции базового рантайма.

Q> Хотя и списки бывают разные, в том же Лиспе список гораздо более императивная конструкция — его можно замыкать на самого себя, модифицировать cons cells (нельзя сказать элементы). С таким списком и хештаблицей вообще ничего больше не нужно.

Скажу больше Лиспы тоже бывают разные.

Q>Ни в OCaml, ни в Lisp копирование не производится, если нет на то особого желания, конечно.

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

VD>>Кстати, для мнея было очень интересно как они разбирутся с операторами. Мне казалось кривым решением делать операторы экземплярными методами. Однако похоже это все же работает. Тому же шарпу очень нехватает подобного решения.

Q>Это ты о чем?

Они декларируют, что любой метод может рассматриваться как оператор. Так:

list.Append(elem);

можно записать как:

list Append elem;

Так же они позволяют создавать методы с именами операторов. Так что любой оператор в Скале — это метод. На этом у низ основан неплохой обощенный (дженерик) и ООП подходы.

Здравствуйте, uw, Вы писали о Scala.

В пятницу я отправил Вам письмо с просьбой о помощи — вы получили его? Если да, ответьте, пожалуйста.

Здравствуйте, Quintanar.

В пятницу я отправил Вам письмо с просьбой о помощи — вы получили его? Если да, ответьте, пожалуйста.

Здравствуйте, Kupaev, Вы писали:

K>В пятницу я отправил Вам письмо с просьбой о помощи — вы получили его? Если да, ответьте, пожалуйста.

Даже если и получил, то не смогу его прочитать по техническим причинам. Если не трудно, перешлите его на akozyrev at mcst ru

Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, Kupaev, Вы писали:

K>>В пятницу я отправил Вам письмо с просьбой о помощи — вы получили его? Если да, ответьте, пожалуйста.

Q>Даже если и получил, то не смогу его прочитать по техническим причинам. Если не трудно, перешлите его на akozyrev at mcst ru

Done

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, uw, Вы писали:


А>Скажите, почему Scala это только компилятор для JVM? Почему Microsoft не может сделать компилятор со Scala в высокопроизводительный код C++?

Причем тут Microsoft, да и С++?

А>Только из-за сборщика мусора JVM? Но можно ведь в компилятор встроить счетчик ссылок, уже не 1979 год на дворе

Причем тут 1979-й год? В нем, что, нельзя было счетчик ссылок сделать?

ЗЫ

Ответ на вопрос — потому что не их игрушка.

Здравствуйте, uw, Вы писали:

uw>...
uw>Ленивых списков в Scala вроде бы нет, равно как и в доброй половине "современных ФЯ". Намек "тебе не надо" понятен. Чего я больше всего не люблю — претензий на элитарность. В форуме C++ тебе будут объяснять, что библиотеки boost это высшее достижение C++, доказывающее уникальные возможности языка. В форуме "Декларативное Программирование" теперь говорят, что ленивые списки определяют "некосметическую разницу".

scala.Stream

uw>...

Здравствуйте, uw, Вы писали:

uw>Здесь

uw>Интересно любое мнение по этому поводу.

Первое что хочется сказать — не надо здесь агитировать за советскую власть. Тут большая часть знакома (хотя бы поверхностно) со Скалой (да и с Немерле и даже с Бу).

uw>Я небезосновательно думаю, что примерно так будут выглядеть промышленные языки лет через пять. В принципе не важно будет ли это Scala или C# X.0, важна сама тенденция. И на мой взгляд, традиционные функциональные языки начинают отходить в прошлое, так и не успев стать языками промышленной разработки. Об этом говорит хотя бы то, что ocaml.org и haskell.org обновляются в последнее время крайне редко.

Они не то что не успели. Они в приципе не смогут стать языками для всех. Причем сразу по двум причинам:
1. Они слишком академичны и носят выраженный исследовательский характер. Когда приходилось делать выбор, то в их дизайне отдавали предпочтение концептуальной чистоте, а не практическому удобству.
2. Они слишком сложны и непривычны для большей части интеллектуального большинства.

uw>Что касается непосредственно Scala, то существует компилятор, с поддержкой Java и .NET. На мой взгляд неюзабельно, так как компилятор невероятно медленный, но сам язык на мой взгляд интереснее большинства существующих ОО функциональных языков.

Мне больше интересно, что у него с IDE?

ЗЫ

Согласен про тендецию. Что же касается пяти лет, то с момента создания Скалы и Немерле прошло уже примерно 5 лет. Но тенденции перехода на них не видать. Зато хорошо видно как меняются представление о языках программирования у брэндов (Страуструпа и Хейльсберга). Думаю с их тормознутостью им потребуется не менее 10-15 лет на создание языка нового поколения или на приведение имеющегося барахла в соответствие с этими тенденциями. Учитывая то, что успешность языка в немалой степени определяется следующими факторами:
1) наличием сильной компании или личности;
2) поддержкой современных дизайнеров и IDE;
3) агрессивным маркетингом,
я почти уверен, что и Скала, и Немерле и даже F# будут проигрывать в популярности Яве, Шарпу и С++.
Будет очень хорошо если новые языки достигнут уровня популярности Питона или Руби.

Как человек пытающийся популяризировать и развивать Немерле я вижу только один шанс — мимикрия под C#. Так чтобы файлы шарпа и немерле могли бы находиться в одном проекте. Это снимет многие проблемы (от совместимости с дизайнерами, до психологических проблем).

А вообще — да, если вложить в Скалу или Немерле много много деенег (в пиар и продуктизацию), то языки вроде Явы и Шарпа вымрут как динозавры. То какой смысл вкладывать деньги в убийц Явы и Шарпа тем кто разработал и популяризировал эти самые явы и шарпы? Плюс не надо забывать про амбиции разработчиков...

Здравствуйте, Quintanar, Вы писали:

Q>Так в чем, собственно, состоит его прогрессивность? В ОО?

Ну, ООП + ФП — это действительно удобно и почти ново. В ОКамле ООП явно не удался. В Скале он почти идеален.

Здравствуйте, Quintanar, Вы писали:

Q>В xml? Так это вообще бред, не понимаю зачем он вообще нужен.

Что до ХМЛ, то он стал стандартом в корпоративной разработке. Так что как бы он тебе не нравился, но его хорошая поддержка — это огромный плюс для большинства. Это конечно популизм со стороны разработчиков Скалы, так как ХМЛ не трудно отлично интегрировать в любой язык, но популизм очень правильный для языка.

Здравствуйте, Gaperton, Вы писали:

G>Для тех, кто не любит читать ссылки, объясню. Кратко — как известно, современные ФЯ весьма хороши в обработке древовидных структур данных, которые описываются рекурсивно. Мотивацией для добавления в язык возможностей, традиционных для ФЯ, послужила необходимость гладкой и простой работы с XML-данными (как в свое время необходимость разработки GUI стимулировала широкое внедрение ООП, на которое GUI ложится великолепно).

Вообще-то реальной мотивацией для скалы послужил дисер Одески по поводу алгоритма вывода типов для номинальных систем типов поддерживающих подтипы. Это тебе как "эксперту в философии программирования" который читает документацию в формате pdf должно быть хорошо известно.

Кстати, немерле так же развитие этой работы. Точнее сочетание развития этой работы (Москаль, улучшивший алгоритм предложенный Одесски, правда сумел только диплом на этом защитить ) плюс работа Скальски по макросам, которая стала развитием исследовательских работ на базе Template Haskell.

Так что о практическом значении этих языков их авторы только мечтали.

Здравствуйте, Gaperton, Вы писали:

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

+1
Вот только так думает меньшинство.

G>Что касательно языка Scala, то на сколько я понял, это встроенный язык их ERP-системы для написания бизнес-логики. Совершенно неважно, будет ли он применяться где-то еще, от этого Scala ни жарко ни холодно, им на это просто плевать. Так что я бы за перспективы этого языка сильно не переживал — они слабо зависят от того, что язык "промышленный".

-1
Откуда эта "информация"?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gaperton, Вы писали:

[cut]
VD>-1
VD>Откуда эта "информация"?

А к чему этот усиленный некропостинг, Влад
Тем более когда ответ рядом уже был дан больше 4 лет назад?

VladD2,

uw>>Интересно любое мнение по этому поводу.

VD>Первое что хочется сказать — не надо здесь агитировать за советскую власть. Тут большая часть знакома (хотя бы поверхностно) со Скалой (да и с Немерле и даже с Бу).

Второе, что хочется сказать, что сообщение топикстартера датируется 2005м годом, и насколько я помню uw больше не появляется на рсдн, и даже когда-то просил удалить свой профиль из бд.

Здравствуйте, VladD2, Вы писали:

VD>Мне больше интересно, что у него с IDE?

Плагины для Eclipse, IDEA и NetBeans: http://www.scala-lang.org/node/91

PS. На мой далекий от Java взгляд, перспективы у Scala стать новым мейнстримовым языком на JVM, гораздо выше, чем у Nemerle/F# на .NET. Поскольку Java сейчас производит впечатление умирающего языка (Java 7 все никак не могут выпустить на фоне поглощения Sun-а Oracle-ом), тогда как C# очень активно развивается.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Второе, что хочется сказать, что сообщение топикстартера датируется 2005м годом, и насколько я помню uw больше не появляется на рсдн, и даже когда-то просил удалить свой профиль из бд.

Да, да. Не заметил. Какой-то Веселый парень подсунул ссылку на протухшую тему.

ЗЫ

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

Здравствуйте, fixxer, Вы писали:

F>Под нетбинз есть вполне юзабельный плагин. http://wiki.netbeans.org/Scala

Ты им пользовался? Насколько он стабилен?

Здравствуйте, eao197, Вы писали:

E>Плагины для Eclipse, IDEA и NetBeans: http://www.scala-lang.org/node/91

Вопрос не в наличии, а в пригодности. Насколько они качественны и стабильны?

E>PS. На мой далекий от Java взгляд, перспективы у Scala стать новым мейнстримовым языком на JVM, гораздо выше, чем у Nemerle/F# на .NET. Поскольку Java сейчас производит впечатление умирающего языка (Java 7 все никак не могут выпустить на фоне поглощения Sun-а Oracle-ом), тогда как C# очень активно развивается.

+1

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

E>>Плагины для Eclipse, IDEA и NetBeans: http://www.scala-lang.org/node/91

VD>Вопрос не в наличии, а в пригодности. Насколько они качественны и стабильны?

Лично не пользовался. Судя по анонсам релизов Scala, плагин для Eclipse регулярно обновляется вслед за очередной версией Scala. И, вроде как в блогах Scala-разработчики пишут, что пользуются Eclips-овским плагином.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, fixxer, Вы писали:

F>>Под нетбинз есть вполне юзабельный плагин. http://wiki.netbeans.org/Scala

VD>Ты им пользовался? Насколько он стабилен?

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

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

Здравствуйте, uw, Вы писали:

uw>Здесь

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

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

Здравствуйте, chukichuki, Вы писали:

C>В целом, по мере использования сравнивал Скалу с Окамлом. Скала по моему личному мнению гораздо удобнее

можно раскрыть? и какой у тебя бакграунд в плане ооп/фп?