Здесь

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>При этом, отсутствуют встроенные в язык списки и, главное, 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 пересекается гораздо лучше. Но пишу я все равно на С++ .

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

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

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

Здравствуйте, 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, Вы писали:

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

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

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

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

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

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

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

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

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

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

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

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

G>Что касательно языка 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>В мои цели не входит замешивание Scala с дерьмом.
Правильно, в твои цели видимо входит замешивание меня с дерьмом. Просто ради развлечения.

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

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

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

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

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

Здравствуйте, 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, Вы писали:

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

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

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



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