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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 перво-источником. Как эти идеи трансформировались и что в итоге получилось это другой вопрос.

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

Здравствуйте, 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>Там менеджер хипа старается располагать элементы одного списка подряд, чтобы при пробежке по списку работала предвыборка. Списки там на реальных алгоритмах не проигрывают по скорости массивам (мерял — чудо какое-то), а массивы в 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])
{
    ...
}

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

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

Здравствуйте, 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# и даже на Лиспе. Так что попадание в этот сегмент просто гарантирует рельную распространненость.

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

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

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


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

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

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

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

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

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

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

Здравствуйте, 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;

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

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

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

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