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

AVK>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Т.о. программирование превращается скорее в этакую "конфигурацию" софта. Тенденция такая, однако, намечается.
AVK>Не знаю откуда ты такую тенденцию взял, но почти все новые мейнстрим-языки сложнее своих предков.

Какие именно языки? Каких проще?
Java, когда появилась, была весьма примитивным языком, да и сейчас недалеко ушла.
C#, даже современный, по-прежнему как язык проще, чем C++.

AVK>Безусловно, область "конфигурации" тоже растет и развивается, но то, что конфигурировать, его ведь тоже кто то написать должен.

Бесспорно. Точно так же, как надо будет писать драйвера, выпускать новые версии операционных систем и т.д. Вот только это уже не мейнстрим задачи.

AVK>Вообще, развитие разработки софта идет пока в строгом соответствии с законом развития сложных систем — новый инструментарий постоянно закрывает области, где раньше требовалось рукопашное программирование, но оставшиеся незакрытые растут в объеме еще быстрее, да новые появляются.

А что ты называешь мейнстримом? Собственно, я бы сказал, что мейнстрим — это как раз *закрытые* области. Чисто количественно разработки, которая ведется в этих закрытых областях, гораздо больше, чем в "незакрытых" и еще только осваиваемых.
Если же для тебя мейнстрим — просто синоним промышленного программирования, то тогда твой тезис об ФЯ вообще непонятен. ФЯ уже используются в индустрии.

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

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

K>Т.е. если убрать отношения сабтайпинга между классом и реализуемым им интерфейсом и оставить только интерфейсы как констрейнты — нужны экзистенциальные типы и полиморфизм ранга 2.
K>Если убрать наследование вообще и оставить только имплементацию интерфейсов, то диспетчеризация будет статической ("интерфейсные" вызовы можно вовсе заинлайнить) для всех универсальных (forall) типов (как сейчас для struct и интерфейсов-констрейнтов) и динамической для всех экзистенциальных (exist). Т.е. какой-то оверхед от полиморфизма останется только в тех случаях, когда без него не обойтись. Устранять же всеобщую виртуальность вызовов в тех случаях, где она не нужна (почти везде) хоть и кое-как можно, но это весьма нетривиально.

Спасибо за ответ. Помедитировал над ним. Если я правильно понял — по сути это тот же возврат интерфейса: "IPet Get()". С той разницей, что возвращается таки не интерфейс, а неизвестный класс. Т.е. экзистенциальные типы — это такая языковая лазейка, чтобы работать с типами, а интерфейсы использовать только в качестве констрейнтов. Этакий "генерик-параметр на выход". Интересная концепция, жаль только, что применения в других местах языка ей пока не вижу — только для возврата из метода неизвестных типов.

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

ВВ>Java, когда появилась, была весьма примитивным языком,

Значительно сложнее С.

ВВ>да и сейчас недалеко ушла.

Тем не менее усложняется с каждым релизом.

ВВ>C#, даже современный, по-прежнему как язык проще, чем C++.

Он сложнее, просто интуитивнее.

ВВ>Бесспорно. Точно так же, как надо будет писать драйвера, выпускать новые версии операционных систем и т.д. Вот только это уже не мейнстрим задачи.

Докажи.

ВВ>А что ты называешь мейнстримом?

То, что потребляет основное количество денег на разработку.

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

ВВ>>Java, когда появилась, была весьма примитивным языком,
AVK>Значительно сложнее С.

Во-первых, не все так просто как кажется. Джава на момент появления была как C# 1.0 — минус ряд фич.
Си же не такой уж и простой на самом деле.

И Джава все-таки не Си противопоставлялась, а скорее С++.

ВВ>>да и сейчас недалеко ушла.
AVK>Тем не менее усложняется с каждым релизом.

Ну да, раз в 10 лет. "Предки" Джавы тоже с каждым релизом усложняются — примерно с той же скоростью к тому же.

ВВ>>C#, даже современный, по-прежнему как язык проще, чем C++.
AVK>Он сложнее, просто интуитивнее.

Я не думаю. Один факт того, что система типов в С++ является тьюринг полной, как бы вызывает сомнения в необходимости дальнейшего сравнения.
Нет, ты правда считаешь, что С# 4.0 как язык сложнее, чем С++11?

ВВ>>Бесспорно. Точно так же, как надо будет писать драйвера, выпускать новые версии операционных систем и т.д. Вот только это уже не мейнстрим задачи.
AVK>Докажи.

Ты вообще интересный человек. Сделал некое заявление, а я теперь тебе должен что-то доказывать. Внезапно оказывается, что теперь еще и совершенно непонятно, что же ты там имел в виду под мейнстримом.

Мне на самом деле все равно, что в твоих глазах является мейнстримом, а что не является. Но ты сказал, что ФЯ в мейнстриме не будет. Изволь тогда объяснить, где именно его не будет, чтобы не было спора о терминах.

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

Корпоративный сегмент.

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

ВВ>Ну да, раз в 10 лет. "Предки" Джавы тоже с каждым релизом усложняются — примерно с той же скоростью к тому же.

Это неважно. Главное — тенденция.

ВВ>Я не думаю.

Сравни размер спецификаций.

ВВ> Один факт того, что система типов в С++ является тьюринг полной, как бы вызывает сомнения в необходимости дальнейшего сравнения.

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

ВВ>>>Бесспорно. Точно так же, как надо будет писать драйвера, выпускать новые версии операционных систем и т.д. Вот только это уже не мейнстрим задачи.
AVK>>Докажи.

ВВ>Ты вообще интересный человек. Сделал некое заявление

Заявление сделал ты, а не я. Оно процитировано выше.

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

ВВ>Корпоративный сегмент.

В основном. Но и компании типа МС тоже серьезная доля.

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

AVK>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ну да, раз в 10 лет. "Предки" Джавы тоже с каждым релизом усложняются — примерно с той же скоростью к тому же.
AVK>Это неважно. Главное — тенденция.

Я указанной тобой тенденции не вижу.

ВВ>>Я не думаю.
AVK>Сравни размер спецификаций.

Спека шарпа — ок. 500 стр. Размер спеки С++11 — что-то около 1500 стр., насколько я помню. Немного больше

ВВ>> Один факт того, что система типов в С++ является тьюринг полной, как бы вызывает сомнения в необходимости дальнейшего сравнения.

AVK>Брейнфак тоже тьюринг полный. Что не делает его сложным. Плюсовые шаблоны строятся по сравнительно простым правилам, а то что они позволяют мозговыковыривательный код писать — это к сложности самого языка имеет опосредованное отношение.

Т.е. тьюринг полнота системы типов к сложности никакого отношения не имеет? А что же тогда имеет? Что такого сложного в C#?

ВВ>>>>Бесспорно. Точно так же, как надо будет писать драйвера, выпускать новые версии операционных систем и т.д. Вот только это уже не мейнстрим задачи.
AVK>>>Докажи.
ВВ>>Ты вообще интересный человек. Сделал некое заявление
AVK>Заявление сделал ты, а не я. Оно процитировано выше.

Повторюсь, мне неинтересно спорить о том, что такое мейнстрим. Если этот термин вызывает различные трактовки, не проще ли переформулировать свою изначальную мысль

Автор: AndrewVK
Дата: 17.07.12

?
Или это не наш путь, и мы теперь будем двадцать страниц спорить о мейнстриме?

ВВ>>>>А что ты называешь мейнстримом?
AVK>>>То, что потребляет основное количество денег на разработку.
ВВ>>Корпоративный сегмент.
AVK>В основном. Но и компании типа МС тоже серьезная доля.

Ну вот там и нужны в первую очередь "конфигураторы".

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

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

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

И самое смешное — большая часть рантайм-ошибок никогда не встретятся на практике. А стало быть усилия будут потрачены на практике.

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

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

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

ВВ>Спека шарпа — ок. 500 стр. Размер спеки С++11 — что-то около 1500 стр., насколько я помню. Немного больше

С++ 11 моложе шарпа значительно, так что это только подтверждает то, что я говорю.

AVK>>Заявление сделал ты, а не я. Оно процитировано выше.
ВВ>Повторюсь, мне неинтересно спорить о том, что такое мейнстрим.

Так не спорь.

ВВ> Если этот термин вызывает различные трактовки, не проще ли переформулировать свою изначальную мысль

Автор: AndrewVK
Дата: 17.07.12

?

Мне проще просто бросить с тобой общаться в очередной раз.

AVK>>В основном. Но и компании типа МС тоже серьезная доля.
ВВ>Ну вот там и нужны в первую очередь "конфигураторы".

Смотря что понимать под конфигураторами. Если мальчиков, которые подправляют готовые решения это одно, а если те, кто пишет сами прикладные решения, пусть и на готовой платформе — это совсем другое.

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

ВВ>>Спека шарпа — ок. 500 стр. Размер спеки С++11 — что-то около 1500 стр., насколько я помню. Немного больше
AVK>С++ 11 моложе шарпа значительно, так что это только подтверждает то, что я говорю.

Ну хорошо. Стандарт С++03 в 1.5 больше стандарта последнего С#. Но это, разумеется, тоже "только подтверждает" твои слова.

AVK>>>Заявление сделал ты, а не я. Оно процитировано выше.
ВВ>>Повторюсь, мне неинтересно спорить о том, что такое мейнстрим.
AVK>Так не спорь.

В следующий раз, пожалуй, так и поступлю.

ВВ>> Если этот термин вызывает различные трактовки, не проще ли переформулировать свою изначальную мысль

Автор: AndrewVK
Дата: 17.07.12

?
AVK>Мне проще просто бросить с тобой общаться в очередной раз.

Ну конечно, когда тебя просят уточнить свою мысль и сказать конкретно, в каких промышленных областях не будет ФЯ, то проще бросить общаться — ведь тут демагогией заниматься уже не получится.
Давай в следующий раз ты и не будешь начинать, ладно? Тогда, возможно, мне ответит тот, кому есть что сказать.

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

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

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

VD>Только пока есть динамические данные будут и ошибки времени выполнения.

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

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

Это все верно. Но это вопрос неразвитости технологии.
Кстати, уже сейчас есть такие штуки, как Ada SPARK, или Perfect Developer, где не так уж страшно все выглядит. Хотя, конечно, до мейнстрима еще очень далеко. Вот пара ссылок:
http://www.eschertech.com/product_documentation/LanguageIntroduction.htm
http://www.eschertech.com/tutorial/tutorials.php

VD>И самое смешное — большая часть рантайм-ошибок никогда не встретятся на практике. А стало быть усилия будут потрачены на практике.

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

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

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

К примеру, в коде

  number MyFunc(number arg)
  {
    return (arg + 1);
  }

нет никаких утверждений, но компилятор выводит их сразу несколько:
1) область определения arg не определена — функция может быть вызвана для любого типа числа (Int32, Int64, etc.);
2) результат функции больше аргумента на единицу (банально, но тем не менее — где может возникнуть переполнение, придется ставить проверку);
3) функция не имеет побочных эффектов.

В общем, идея примерно такая. ИМХО, в этом направлении все будет постепенно двигаться.

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

Тут ничего не могу сказать, не копенгаген в этом вопросе.

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

ARK>применения в других местах языка ей пока не вижу — только для возврата из метода неизвестных типов.

Если подумать, где еще используется сабтайпинг — то эти места очевидны. Гетерогенные списки, например. При сабтайпинге мы можем иметь массив IPet[], хранящий классы Cat и Dog. Если сабтайпинга нет — массив будет типа {exist T where T : IPet}[].

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

AVK>Гибриды. Т.е. языки с полноценной поддержкой и ООП и ФЯ.

Я считаю, что это фантастика. Не поверю в такое, пока не увижу язык с полноценной поддержкой и того и другого. Проблема всех гибридов в том, что они не могут просто сочетать "лучшее из двух миров". Всегда нужно выбирать, чем пожертвовать.
Во-первых, для ООП и ФЯ нужны разные системы типов. Их сочетание порождает мозгоразрывающие явления вроде системы типов Scala да еще и с обязательными сигнатурами типов повсюду, которые чуть попроще сигнатур Агды 2 (да и то не факт, что попроще).
Альтернатива разрыву мозга — "марсианское" ООП, вроде того, что в ОКамле (ничего плохого в нем, в принципе, нет, но мейнстримному ООП программисту оно также чуждо, как и ФП.)
Во-вторых, ФЯ и ООЯ требуют разных рантаймов и, в частности, разных (как минимум — настоек) сборщиков мусора.
Т.е. и на уровне дизайна языка, и на уровне реализации нужно сидеть на двух стульях — что не очень удобно.

AVK>Типа Scala или Kotlin.

Полноценной поддержки ФЯ в них и близко нет. Хотя создатели первого языка стараются изо всех сил. И уровень поддержки в них — несравнимый. В Scala приближается к ML с нормальными модулями (снизу), в Kotlin приближается к уровню C# (сверху). Попытка написать на скале что-то в ФЯ-стиле приводит к коду, по изяществу сопоставимому с упражнениями Александреску (см. Scalaz), кроме того, идиоматический ФП-код на скале адски тормозит. Создатели второго — даже и не стараются.

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

VD>На мой взгляд в чистом виде они никогда не попадут в мэйнстрим. Бессмысленно делать язык для программирования без побочных эффектов на в доску императивном компьютере.

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

VD>Многие задачи по смыслу императивны и эмуляция их на чем-то вроед монад приведет к усложнению, а не к упрощению.

По смыслу императивные задачи можно решать императивно — это не проблема. Любые императивные инструменты в чистых ФЯ доступны, но не наоборот.

VD>Но часто фишки ФП могут упростить задачу. Так что смесь ФП и МП будет только развиваться.

Ну я и не спорю с этим — будут развиваться. В языке с нормальной системой типов разницы между обычным и МП кодом вообще нет.

VD>Когда мэйнстрим полностью впитает ФП, то говорить о чистых ФЯ просто не придется.

Конечно впитает, а потом ООП фичи отомрут как устаревшие и мешающие прогрессу языков.

VD>Второй раз слышу это словосочетание. Гугль ничего не объясняет. Что это значит?

Total functional programming.

VD>Я ставлю на ДСЛ-и и МП. А ФП, ООП будут позволять упростить генерацию кода для них.

Не вижу, как ООП может упростить МП — по моему, может только усложнить.

VD>Паровые машины (Лисп) не предлагать. Не тот уровень юзабельности.

Уж Лисп я точно предлагать никогда не буду.

VD>Ты явно не из числа тех кого можно к мэйнстриму отнести. Тебе и еще кому-то нужны. Но людям в целом — нет. Уровень решения задач все равно крайне низкий.

Сейчас нет — завтра понадобится. Даже если и особое "мозголомство" потребуется (в чем я лично сомневаюсь) все равно перейдут, никуда не денутся. Строители мостов же не для удовольствия сопромат учат — их жизнь заставила.

VD>Мозголомство страшное. Не взлетит.

Мозголомство там с непривычки, разве что. Я, как человек ленивый и медленно соображающий — как раз за простоту ФП и люблю.

VD>А вот ФП-шные фишки в мэйнстрим впитаются. Лямбды уже тут. Паттерн-матчингу пока мэйнстрим сопротивляется, но в течеии лет 10 сдастся.

В случае ФП, лямбды и ПМ — это только вершина айсберга. Главная фишка тех же АлгТД — совсем не ПМ, а то, что они алгебраические — т.е. кучу полезного кода, который с ними работает можно просто вычислить автоматически, а не придумывать (превращает метапрограммирование из шаманства в более чем простое занятие), а промежуточные значения просто стереть без остатка — и также автоматически (помогает производительности). Те, что нельзя стереть, раз уж они не только промежуточные, а хранят разделяемый результат — можно автоматически "сплющить" из графа объектов в плоские структуры, уменьшив промахи мимо кеша, снизив нагрузку на ГЦ и т.д. Наивный прототип кода с ними можно преобразовать в более сложный, но эффективный (полуавтоматически, как решение уравнений во всяких Мейплах и Математиках), как ряд простых преобразований, а каждое преобразование — проверить на правильность автоматически. С объектами ничего из этого нельзя сделать в принципе. (Ну, "сплющивание" для простых случаев и в рантайме, а не статически — можно сделать)

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

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

ARK>>применения в других местах языка ей пока не вижу — только для возврата из метода неизвестных типов.

K>Если подумать, где еще используется сабтайпинг — то эти места очевидны. Гетерогенные списки, например. При сабтайпинге мы можем иметь массив IPet[], хранящий классы Cat и Dog. Если сабтайпинга нет — массив будет типа {exist T where T : IPet}[].

Кстати да, вы совершенно правы. Отличная идея.

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

ВВ>Мне кажется, тут следует вначале задать другой вопрос — а что *нужно* мейнстриму?

Мейнстриму нужны инструменты решения задач, на которые есть спрос.

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

"Доменный" язык — это просто библиотека с удобным интерфейсом. Нужны будут средства для их разработки.

ВВ>Т.о. программирование превращается скорее в этакую "конфигурацию" софта. Тенденция такая, однако, намечается.

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

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

K>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Мне кажется, тут следует вначале задать другой вопрос — а что *нужно* мейнстриму?
K>Мейнстриму нужны инструменты решения задач, на которые есть спрос.

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

ВВ>>Я вот не уверен, что мейнстриму нужны языки общего назначения в принципе. Мейнстриму, скорее, нужны крайне ограниченные "доменные" языки, заточенные под решение узкого круга специальных задач.
K>"Доменный" язык — это просто библиотека с удобным интерфейсом. Нужны будут средства для их разработки.

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

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

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

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

Например:
системные вещи
графика
разработка игр
финансы (ну тут почти пришли)
веб (?)
...

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

K>Я считаю, что это фантастика. Не поверю в такое, пока не увижу язык с полноценной поддержкой и того и другого. Проблема всех гибридов в том, что они не могут просто сочетать "лучшее из двух миров". Всегда нужно выбирать, чем пожертвовать.
K>Во-первых, для ООП и ФЯ нужны разные системы типов. Их сочетание порождает мозгоразрывающие явления вроде системы типов Scala да еще и с обязательными сигнатурами типов повсюду, которые чуть попроще сигнатур Агды 2 (да и то не факт, что попроще).
K>Альтернатива разрыву мозга — "марсианское" ООП, вроде того, что в ОКамле (ничего плохого в нем, в принципе, нет, но мейнстримному ООП программисту оно также чуждо, как и ФП.)
K>Во-вторых, ФЯ и ООЯ требуют разных рантаймов и, в частности, разных (как минимум — настоек) сборщиков мусора.
K>Т.е. и на уровне дизайна языка, и на уровне реализации нужно сидеть на двух стульях — что не очень удобно.

В каком-то смысле "гибридным" можно считать такой ФЯ, в котором есть средства, позволяющие в некотором смысле имитировать ООП.
Скажем, при наличии тайпклассов и экзистенциалов мы вполне можем получить рантайм полиморфизм, эквивалентный ООП.
Чем не гибрид?

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

ВВ>В каком-то смысле "гибридным" можно считать такой ФЯ, в котором есть средства, позволяющие в некотором смысле имитировать ООП.
ВВ>Скажем, при наличии тайпклассов и экзистенциалов мы вполне можем получить рантайм полиморфизм, эквивалентный ООП.
ВВ>Чем не гибрид?

Это будет упомянутое мной выше "марсианское" ООП.
Под гибридом же понимается, как я понимаю, ситуация: "хочу чтоб все осталось по-старому, только поверх добавились все фичи ФП". Это невозможно. Возможна ситуация "хочу чтоб все осталось по-старому, только поверх добавились бы кое-какие (очень немногие) фичи ФП". А дальше уже трейдофф между тем что остается по-старому и фичами ФП. Если принимаются все фичи ФП — по старому ничего не остается. Ну или остается кое-что, очень немногое.

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

ВВ>>В каком-то смысле "гибридным" можно считать такой ФЯ, в котором есть средства, позволяющие в некотором смысле имитировать ООП.
ВВ>>Скажем, при наличии тайпклассов и экзистенциалов мы вполне можем получить рантайм полиморфизм, эквивалентный ООП.
ВВ>>Чем не гибрид?

K>Это будет упомянутое мной выше "марсианское" ООП.
K>Под гибридом же понимается, как я понимаю, ситуация: "хочу чтоб все осталось по-старому, только поверх добавились все фичи ФП". Это невозможно. Возможна ситуация "хочу чтоб все осталось по-старому, только поверх добавились бы кое-какие (очень немногие) фичи ФП". А дальше уже трейдофф между тем что остается по-старому и фичами ФП. Если принимаются все фичи ФП — по старому ничего не остается. Ну или остается кое-что, очень немногое.

В общем понятно, что в языке, где сочетаются ФП и ООП, один из этих компонентов будет "марсианским". Или попросту неполноценным. Вот только ревнителям ООП языков это мешает считать их гибридными. Поэтому я за справделивость. Пусть тогда и Хаскелл будет гибридным — у него на это не меньше прав, чем у той же Скалы.

Так что, кто бы ни победил, победят "гибридные" языки

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

ВВ>В общем понятно, что в языке, где сочетаются ФП и ООП, один из этих компонентов будет "марсианским". Или попросту неполноценным. Вот только ревнителям ООП языков это мешает считать их гибридными. Поэтому я за справделивость. Пусть тогда и Хаскелл будет гибридным — у него на это не меньше прав, чем у той же Скалы.

ВВ>Так что, кто бы ни победил, победят "гибридные" языки

Рациональное зерно в этом есть, но если так рассуждать, то окажется что все языки гибридные и только и делают что побеждают другие гибридные языки. Но "гибриды" которые тут обсуждаются — обсуждаются не в первый раз и известно что именно под этим словом понимают те, кто его употребляют. А понимают они "мейнстримный ООЯ (база) с добавленными элементами ФП (надстройка)". Хаскель, очевидно, таковым не является, а Скала — является.